On 09/18/2010 06:22 PM, Sam Varshavchik wrote: > I just did a fresh F13 install on a server with a softraid setup that's > similar to a setup on a different existing server. The other server was > upgraded to F13, this one is a fresh install. Both servers, raid-wise, > look the same: two disks with RAID1 ext3 partitions. > > This is the mouthful that Anaconda dumped into menu.lst on an F13 fresh > install: > > kernel /vmlinuz-2.6.33.3-85.fc13.x86_64 ro > root=UUID=a9b80e40-3a79-4522-b8a8-ecb3960720b4 > rd_MD_UUID=b0cb9b26:be362a98:012cdf18:19de5ac1 > rd_MD_UUID=067004a2:11daf9c2:0cedca66:ac63c62d rd_NO_LUKS rd_NO_LVM > rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet > > When, previously, Anaconda updated the other server from F12 to F13, it > did not write any of the above rd_* parameters, just root=, and that's it. > > It's fairly obvious that rd_NO* says that I do not use the > similarly-named facilities, but I'm wondering what exactly happens by > specifying these parameters. The other server does not use LUKS, LVM, or > DM also, but it manages to boot just fine without these boot options. > > I'm not positive what rd_MD_UUID does, I'm guessing that this specifies > in which order /dev/md minor numbers should be assigned to the various > software volumes, by the kernel, at boot. This is obviously a good > thing, keeps /dev/md? from jumping around unexpectedly, for some reason, > but why did Anaconda did not do the same thing when I updated the other > existing server to F13? > > Anyone happens to know a useful link that describes these kernel boot > parameters, I'm curious, but Google only shows links to everyone else's > menu.lst that has the same keywords, and that's about it. Those aren't actually kernel parameters, so you won't find them in the kernel documentation. They control the actions of initramfs modules during boot. See the manpage for "dracut" (the initramfs builder) or https://fedoraproject.org/wiki/Dracut . The rd_NO_LUKS option can be important if you have a machine that needs to boot unattended and there's any possibility of someone leaving an external encrypted drive connected. Without one of the LUKS restriction options the boot would wait forever for the password to unlock that drive. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
