2016-09-07 21:46 GMT+03:00 Rich Freeman <ri...@gentoo.org>: > On Wed, Sep 7, 2016 at 2:25 PM, gevisz <gev...@gmail.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.
