Would a patch for mkinitrd be acceptable to get it to read options from a default file (say /etc/mkinitrd.conf), such that I could create such a file and not have to remember the exact set of options I need for my initrd to work with external USB and Firewire disks (see bug 103609 for the complete list of options I need)? I'm thinking of also adding an option to get it to ignore the contents of the file as well. What I'm undecided is whether to have the options in the file pre- or appended to those given in the command line. Comments? Ideally, the installer (and kickstart!) should enable us to configure this file too, but that would be a separate enhancement request :-)
They should be prepended to the command line so that command line options can override them. I'm not against such a patch, but I'm not likely to get to it anytime soon since it doesn't really help with configurations that we actually support.
Created attachment 95278 [details] Collection of patches for mkinitrd, one of which introduces /etc/sysconfig/mkinitrd This attachment contains not only a patch file that introduces /etc/sysconfig/mkinitrd as a means to add default settings to the mkinitrd program, but also --no-config-file and --config-file=pathname (so far undocumented) options to reset the list. This is patch mkinitrd.05-sysconfig-mkinitrd The other patches are broken-up versions of the patches i nbug 106926.
If the patch I just posted to bug 103821 is accepted, patch mkinitrd.04-aftermods-sbp2.patch is no longer needed, and 03-aftermods-support.patch could go with it. I don't particularly care about 02-insmod-k-usb-sleep, but 01-sbp2-rescan is absolutely necessary to be able to have a root filesystem (and/or volume groups or raid devices containing it) spanning across firewire hard disks, and 05-sysconfig-mkintird makes it far simpler to ugprade the kernel without the risk that the new initrd will be missing essential options.
It turns out that, if you load sbp2 after ohci1394, the odds that it will fail to log into the my external hard disk increase dramatically. This means I take back on the claim that paches 03 and 04 can be dropped. They should still go in. I've also come up with some improvements to the scsi bus scanning, by rewriting the relevant portions of rescan-scsi-bus.sh in C, such that the program can be added to the initrd filesystem, or to the installer image.
Created attachment 95373 [details] program that does the boot-time-equivalent of rescan-scsi-bus.sh
Created attachment 95374 [details] patch that improves on mkinitrd.01-sbp2-rescan.patch, using rescan-scsi-bus binary This patch, to be installed after the 5 patches in mkinitd-patches.tar.bz2 (or along with mkinitrd.01-sbp2-rescan.patch) makes the boot speedier, by removing the no-longer-needed sleep, and more flexible, by using a program that will be more flexible in that it will dynamically detect which scsi hosts to scan, instead of only rescanning those that were present at mkinitrd time.
Created attachment 95375 [details] program that does the boot-time-equivalent of rescan-scsi-bus.sh Oops, I'd posted an out-of-date version of the program, that was missing error checking after fopen :-(
All of the sbp2-related gunk can fortunately go away in FC2, but the patch mkinitrd.05-sysconfig-mkinitrd.patch, that enables seamless kernel upgrades (because you can create an /etc/sysconfig/mkinitrd that states what you need in initrd for it to boot), would still be very nice ot have. Any chance of integrating it, or at least commenting on the patch such that I can put it in an acceptable form? Thanks,
Some change in mkinitrd/modprobe/something alike in FC2test2 introduced a very interesting and welcome behavior for me. Entries that look like `alias scsi_hostadapter sbp2' or `alias scsi_hostadapter usb-storage' cause the aliased modules to be included in initrd, which is exactly what I needed. Someone might still like to change mkinitrd such that it could accept a default set of options, but the patch I wrote has probably been found too ugly to be included, and since my problem is solved, I won't rewrite it unless given some indication that there's interest in adding the feature. I'm now happy without it.
Yeah, not sure I'm comfortable with some of the implications of a mkinitrd.conf at this point.