https://bugzilla.novell.com/show_bug.cgi?id=340342 Alexander Graf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |harbaugh@ncifcrf.gov -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c5 --- Comment #5 from Toni Harbaugh-Blackford 2007-11-17 20:05:41 MST --- Created an attachment (id=183818) --> (https://bugzilla.novell.com/attachment.cgi?id=183818) output of "bash -x /sbin/mkinitrd" captured via script -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c7 --- Comment #7 from Toni Harbaugh-Blackford 2007-11-17 20:15:06 MST --- A better solution may be to do a modinfo on each module to see if it has firmware, and then automatically put those that do in a separate env var for processing after udev. xnode3:~ # modinfo e1000 | grep '^firmware:' xnode3:~ # modinfo tg3 | grep '^firmware:' xnode3:~ # modinfo aic94xx | grep '^firmware:' firmware: aic94xx-seq.fw xnode3:~ # modinfo qla2xxx | grep '^firmware:' firmware: ql2400_fw.bin firmware: ql2322_fw.bin firmware: ql2300_fw.bin firmware: ql2200_fw.bin firmware: ql2100_fw.bin -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c9 Alexander Graf changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO Info Provider| |harbaugh@ncifcrf.gov --- Comment #9 from Alexander Graf 2007-11-18 05:47:03 MST --- Sorry, my bad. The new mkinitrd is supposed to get the system back to the state it was running on. Everything apart from that would be nice, but is not necessary. Furthermore mkinitrd is built to find out _everything_ itself, with the INITRD_MODULES variable being a leftover from previous versions and a means to hotfix things. So if you install your system to a usb drive, mkinitrd detects that the aic-controller does not get used and simply does not include it to its list of udev-enabled devices (from storage.sh to block.sh). The real problem you are facing here is, that when you install opensuse to your aic disk (which is not the case your log shows), mkinitrd finds the aic-controller as "important disk device". Sadly yast already put it into the INITRD_MODULES variable, so mkinitrd is forced to be legacy-compatible and load all the modules defined there before udev starts. Due to that udev sees the contoller als "loaded already" and does not load the firmware. There are 2 possible solutions to this: a) Run udev-trigger just after starting udev so it tries to resolve everything based on things that "are there at the point of running udev-trigger". I do not like this one as it's mostly useless for any case but this one and I want to get rid of INITRD_MODULES anyway. b) Remove the aic94xx entry from INITRD_MODULES and you should be fine. I personally prefer this one. Could you please check if it works? If so, we only have to tell the yast developers to remove the aic94xx entry from INITRD_MODULES (there is code available for these cases already). If not, send a bash -x output of that mkinitrd run please. The one thing I'm really open to is the modinfo aic94xx | grep '^firmware:' though. I hate the current code that's in use for copying the firmware files to the initrd. It is simply prone to break, as it hardcodes all cases "we care about". What if someone wants to diskless-boot and includes a wifi driver to the initrd that needs a firmware file as well? This case would work if the firmware files were to be identified dynamically. Thanks a lot for this pointer. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c11 --- Comment #11 from Toni Harbaugh-Blackford 2007-11-18 06:06:21 MST --- Created an attachment (id=183821) --> (https://bugzilla.novell.com/attachment.cgi?id=183821) bash -x mkinitrd *without* aic94xx in INITRD_MODULES leaving aic94xx out of INITRD_MODULES does NOT work. if aic94xx is not included in INITRD_MODULES, then the aic94xx module is NOT included in the initrd. Only the firmware itself is included: xnode3:/tmp # gunzip -cd /boot/initrdtest | cpio -it | grep aic94xx lib/firmware/aic94xx-seq.fw 22494 blocks -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c12 --- Comment #12 from Alexander Graf 2007-11-18 06:16:47 MST --- from the log: rootdev=/dev/disk/by-id/usb-WDC_WD25_WD-WCAR1003_888888D88CA8-0:0-part2 This means, the device you are running / on is located on a usb harddrive. The autodetection only works if / is actually located on the aic. My guess would be that you didn't chroot into the actual system on the aic though (see man mkinitrd for instructions on that). If you did run this from the aic system, your fstab is corrupt and the fallback protection mechanism in mkinitrd failed on you as well. This would be a really severe bug! Mkinitrd in 10.3 became _way_ smarter than it was in previous versions and than any other mkinitrd out there is. This of course leads to unexpected behavior. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c14 --- Comment #14 from Alexander Graf 2007-11-18 06:51:33 MST --- Well this explains why you can't run it from there :-). I'm sorry I didn't think of that earlier. Basically what you have to do is to get the system on your USB drive to work properly with the device as non-root-device. When you are able to access the device, copy the system over to the SAS disk, remove the aic94xx-entry from the INITRD_MODULES list and chroot into that following the description in the man-page. This should get you a working initrd for the SAS system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c16 --- Comment #16 from Toni Harbaugh-Blackford 2007-11-18 07:40:59 MST --- since Factory has moved on to kernel 2.6.24 and I have other problems with that (see bug 341290 - https://bugzilla.novell.com/show_bug.cgi?id=341290), I will wait to try this procedure until I can get 2.6.24 up and running. So go ahead and close this bug and if I have problems I'll open a new bug. Thanks, Toni -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c18 --- Comment #18 from Toni Harbaugh-Blackford 2007-11-18 08:55:44 MST --- I added the module by-hand to INITRD_MODULES; yast did not do it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=340342#c20 Toni Harbaugh-Blackford changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #20 from Toni Harbaugh-Blackford 2007-11-19 05:40:06 MST --- using the procedure above (chroot to new system *then* run mkninitrd) works to put the aic94xx module in the initrd, and firmware gets loaded properly at boot. Although there may be cases where people want to add a module to the initrd that is *not* required for boot, this is relatively rare and probably not worth modifying the mkinitrd stuff to handle. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.