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

[Rich Freeman]

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