Re: [gentoo-user] Kernel does not boot after adding a new SATA drive

[gevisz]

2016-09-07 21:46 GMT+03:00 Rich Freeman <rich0@g.o>:
> On Wed, Sep 7, 2016 at 2:25 PM, gevisz <gevisz@×××××.com> wrote:
>>
>> 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?
>
> grub-mkconfig simply searches for a configurable list of filename
> specifications which your initramfs didn't match.  Since /boot could
> contain all sorts of files, with all sorts of naming conventions, it
> obviously would be very difficult to accomodate any possible naming
> convention.  We apparently do have it set up to search the filenames
> generated by the initramfs tools we actually use, so as long as you
> don't go renaming them you're probably fine.
>
> At boot time grub doesn't search for anything.  It simply reads the
> config file and does what it tells it.
>
>>
>> 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.
>>
>
> Grub is loading the kernel in your case.  The kernel just isn't
> mounting the root filesystem since there is no initramfs to tell it
> how to do that.  Grub has nothing to do with mounting root at boot
> time.
>
> Grub also loads the initramfs before it ever executes the kernel.  The
> kernel doesn't know how to load an initramfs from disk.  It expects it
> to be in RAM when it runs.
>
> The initramfs loaded by grub is just a cpio image that is copied into
> RAM, and I believe the address gets passed as a kernel command line
> argument (one you don't even see in grub, it appends it at runtime).
> The kernel creates a ramfs, extracts the cpio image into the ramfs,
> and executes init inside of it.  At that point the kernel is
> essentially done with booting the system, the initramfs can mount and
> pivot to a new root, or the whole system could just run off of an
> initramfs until it shuts down.  This is why the kernel developers have
> shunned kernel mounting logic/etc in favor of the initramfs; it moves
> more of the logic into userspace where it is easier to
> change/maintain/etc, and doesn't have to necessarily run with kernel
> privs either.  Heck, your initramfs could go out on the network, pull
> in another kernel image and initramfs, and kexec that (which I think
> is basically the design of coreboot which is a linux-based
> bootloader).
> --
> Rich
>

Yes, with initramfs, system boots even if I remove a (non-boot :) disk
or add another one. I reply a bit later because needed some time to
check all the possible situations. Thank you for the help!

Now the problem solved indeed.