On Wed, Sep 7, 2016 at 7:57 AM, gevisz <[email protected]> wrote: > 2016-09-07 12:36 GMT+03:00 Rich Freeman <[email protected]>: >> On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <[email protected]> wrote: >>> >>> grub-mkconfig is not finding an initramfs, as evidenced by the lack of >>> an "initrd" in in grub.cfg. >>> >>> If it is unable to find an initramfs, it will always output >>> root=/dev/sdX instead of root=UUID=... >>> >> >> For whatever reason the three subsequent replies to this list ignored >> the actual explanation of the cause of the problems, which was this >> (not uncommon on this list it seems). >> >> When root=UUID=... was added manually to the command line, then the >> kernel refused to boot at all, because the kernel itself doesn't >> understand that syntax. > > Yes, when the "root=UUID=***" has been added manually to /etc/default/grub > in the wrong way, it appeared in the GRUB menu entry in the wrong way that > stopped GRUB from booting in any case...
It doesn't matter how you add root=UUID=* to the kernel command line. The kernel doesn't understand that syntax at all. Your initramfs probably does. When you don't use an initramfs (and you aren't using one, even if you think you are), the kernel reads the value of root= and mounts it as root. It doesn't understand the UUID syntax. When you do use an initramfs then the kernel ignores the root= setting, and the initramfs reads it and mounts root. Typically these do understand the UUID syntax, but of course that depends on what initramfs you're using. > >> So, the next question becomes, how are you generating an initramfs, >> and how is it named? Pasting the output of "ls /boot" might be >> helpful here. > > I generate initramfs by > # genkernel --install initramfs > and the rename it to match the name of the kernel, eg, > initramfs-4.4.6-gentoo > vmlinuz-4.4.6-gentoo And if you read /etc/grub.d/10_linux you'll see that the script doesn't look for an initramfs with the filename initramfs-<version>. It will accept initramfs-<version>.img or initramfs-genkernel-<version> It accepts 11 other variations of the filename, but not the one you picked. So, grub-mkconfig doesn't think you have an initramfs, so it generated a configuration file which: 1. Doesn't load an initramfs (so any attempt to stick a root=UUID=* option in there will fail). 2. Just references the device name for root that it finds, since that is the best it can do without an initramfs. > > But I think that this is unrelevant to the problem because of the following > explanation I have just posted. (If I am wrong here, please, let me know > and I will post all the conf files you will ask.) No need, your filenames likely solved the problem. Just tack a .img on the end of that initramfs and you should be good after running grub-mkconfig again. > > When I connected a new SATA disk to the SATA controller, the order of > hard disks during the boot time changed because the new disk "jumpt > in front" of the boot drive. As the result, the GRUB could not find the > boot partition by its UUID on the "wrong" non-boot drive and gave up, > without even trying to look for the boot partition by its UUID on other > hard drives! Grub doesn't look for boot partitions at all. Grub just reads the configuration file and loads the kernel (and optionally initramfs) that it finds in grub.cfg. In your case the grub.cfg didn't list an initramfs, so it didn't load one. The initramfs generated by genkernel will look for a drive by UUID, and as long as the device exists it will probably find it. Obviously if you're missing a kernel module needed to access the drive that would stop it. However, it doesn't care what order the devices are numbered in. > > So, the question remains: why not to desing the GRUB in such a way > that it could look for the boot partition by its UUID on any available > hard drives? > It already does this. It just doesn't do it when it doesn't think you're using an initramfs, because if it did it would make your system unbootable, since the kernel doesn't know anything about UUIDs. -- Rich
