Sebastian Plotz wrote: > Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton: >> But it won't boot very far. The kernel won't be able to mount its root >> partition unless you manually edit the grub.cfg or compile the kernel >> with an initramfs >> >> Andy > Yes, and it will work if you're using a separate boot partition ... > This means: GRUB can find the kernel (and the initrd, if used) when the > device of the boot partition has changed. > > After that, the kernel can mount the root partition (the device of the > root partition must not be changed). But it's important that a UUID will > be used for the boot partition in /etc/fstab. > > So we can say in the book: > > "The search lines are only meaningful if your are using a separate boot > partition and a UUID entry for this partition in /etc/fstab." > > ... or we simply remove this sentence from the book.
The booting process via GRUB is quite complex. The first thing it does is read the grub.cfg file. How does it do that? Normally it looks for /boot/grub/grub.cfg. The problem is that it doesn't know where /boot is located or the partition type. It has to probe for that. It then loads modules that are specified in the cfg file and those are also found on /boot/grub/. http://en.wikipedia.org/wiki/Disk_partitioning#Partitioning_schemes The Grand part of (GR)UB is that it can look at a variety of different layouts: network, serial port, usb drives/kbd, PS/2, CD drives, raid arrays, etc. These can be mixed and matched. At that point it can start interacting with the user. At the user's request, it then must find and load the kernel (or chainloader) image. The user must also pass parameters to the image unless the defaults are sufficient. The Linux kernel generally needs to be told what it's root partition is. To the best of my knowledge, it understands root=/dev/<device> and root=LABEL=label-name. For an ext filesystem, the command to manage the label is e2label or tune2fs. Other filesystems have different commands. I do not believe that linux has the ability to search for a UUID on a partition when mounting its root fs. I could be wrong about that. All this is beyond the scope of LFS. What I wrote was: "The search lines [int the example] are not meaningful for LFS systems as that command needs an initrd image for processing." I propose to rewrite that as: "The search lines [int the example] are not useful for a basic LFS system as the disk geometry is known. To use a UUID as the kernel's root partition in the command line requires an initrd." -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
