2016-09-07 16:19 GMT+03:00 Rich Freeman <ri...@gentoo.org>:
> On Wed, Sep 7, 2016 at 7:57 AM, gevisz <gev...@gmail.com> wrote:
>> 2016-09-07 12:36 GMT+03:00 Rich Freeman <ri...@gentoo.org>:
>>> On Tue, Sep 6, 2016 at 11:36 PM, Mike Gilbert <flop...@gentoo.org> 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),
I have removed all my initramfs files from the /boot and found out
that the system boots anyway. So, you are right.
Before doing this I was sure that it is not the case because back in 2013,
when I first installed Gentoo, the system refused to boot until I created
ininramfs...
> 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.
I did this, and now have the following GRUB menu entry in /boot/grub/grub:
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class
gnu --class os $menuentry_id_option 'gnulinux-simple-44***' {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='hd2,msdos3'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos3
--hint-efi=hd2,msdos3 --hint-baremetal=ahci2,msdos3 44***
else
search --no-floppy --fs-uuid --set=root 44***
fi
echo 'Loading Linux 4.4.6-gentoo ...'
linux /boot/vmlinuz-4.4.6-gentoo root=UUID=44*** ro
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-4.4.6-gentoo.img
}
where, again, 44*** stands for the UUID of my root-boot partition.
So, here you are, again, right.
>> 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.
But, here, I cannot agree with you because of the following:
What you have just said implies that I had not had a problem
booting the system after adding a new drive had I used initramfs
correctly. Well, I do agree that, after loading the initramfs, the system
may find the kernel to load with the help of initramfs that understands
UUID. However, how the GRUB could find the initramfs in the first place,
if it could not find the kerner allocated in the same directory as the
initramfs itself?
Moreover, in the GRUB menu entry provided above, the initramfs loads
already after the kernel. So, using the initramfs should be irrelevant to
the question of finding the kernel to load by GRUB.
