[Bug 2710] Non-detection of module required for initrd image at install

[bugzilla-daemon at bugzilla.ubuntu.com]

Please do not reply to this email.  You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=2710
Ubuntu | linux





------- Additional Comments From cef at optus.net  2005-08-24 02:17 UTC -------
Re: Has this been tested against the breezy kernel 2.6.12-7.11?

I've not been able to test this on our machine as it's a production box and
therefore still running hoary. I may be able to arrange to replace the kernel
for a test on the box, but I can't update it to breezy yet. Perhaps someone in
ubuntu should contact 3ware and see if they can loan a developer a 3w_9xxx
(SATA) card for testing purposes?

>From what I understood, the initrd image that gets built with mkinitrd detects
at the build time of the image what modules are required for the rootfs. In
Warty and Hoary, this process checked /proc entries for the necessary device,
and as the .proc_name section of a struct was not defined, the relevant part of
the build process can not resolve which modules were necessary for the rootfs,
hence why it fails at boot, and also why adding the module name to
/etc/mkinitrd/modules worked for me.

Can someone answer the following questions (which will go a long way to figuring
out the status of this bug):
 1. Does Breezy now auto-detect block devices using sysfs at boot and
automatically load them (all done within the initrd that is, ie: before
attempting to mount the rootfs)? 
 2. If no to #1, does mkinitrd now parse sysfs (instead of, or in combination
with /proc) to figure out the root filesystem drivers at initrd build time?
 3. If no to #2, does the driver now have the .proc_name section in its struct
defined?

In theory, if the answer to any of these questions is yes, then it should be
fixed (excluding testing of course).

-- 
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.