Le 01/08/2016 à 21:15, Joe a écrit :
There are two chunks of storage for grub:
Actually three, or even four.
the files, stored in a normal filesystem and available under /boot,
Actually /boot/grub. GRUB does not store anything directly in /boot.
and the bootloader itself, which
generally lives in the drive MBR, but can also live in a partition. The
bootloader is machine code which is stored outside any filesystem.
The files in /boot/grub are also part of the bootloader. GRUB cannot
display its menu or boot any OS without them.
The first chunk is the "boot image" and must be stored into a MBR (whole
disk boot sector) or PBR (partition boot sector). As it must fit into a
512-sector size, all it does is load the next chuck using a hardcoded
block list.
If the boot image is in a PBR, the BIOS won't load it directly so it
must be chainloaded by another (primary) bootloader. The primary
bootloader can be a standard MBR boot code (MSDOS style) which just
loads and boot the PBR of the primary partition which has the "boot"
flag set, or another bootloader such as LILO or another GRUB instance
installed in the MBR.
The second chunk is the "core image". For historical technical reasons
its size is about 30 kB, sometimes a bit more. It has three possible
locations :
- on an MSDOS-partitionned disk, in the unallocated space between the
MBR and the first partition (MBR gap). This space used to be 31 KiB when
partitions were aligned on cylinder boundaries, but is now ~1 MB since
partitions are aligned on 1 MiB boundaries ;
- on a GPT-partitionned disk, in a dedicated unformatted "BIOS boot"
partition ;
- or as a regular file in a filesystem appearing as
/boot/grub/i386-pc/core.img (or /boot/grub/core.img with older versions
of GRUB such as the one in Wheezy). This option is not recommended as
the filesystem may move the blocks around and the location of the core
image is hardcoded into the boot image. Also this option is not possible
when /boot/grub is not on the same disk as the boot image or not on a
plain partition, e.g. on LVM, some software RAID levels, encrypted volume...
The first two locations (not in /boot/grub) are called "embedded".
Now, the confusion comes when you select the device to install GRUB.
Actually this only selects the location of the boot image, i.e. in an
MBR (if selecting a whole disk /dev/sdX) or a PBR (when selecting a
partition /dev/sdXN). The location of the core image will be chosen
automatically : embedded if possible, as a file otherwise.
Embedding is not possible if the core image is larger than the MBR gap
on an MSDOS disk, if there is no BIOS boot partition on a GPT disk, or
if the boot image is stored in a PBR.
In any case, AFAIK the boot image and the core image must be on the same
disk.
The third chunk is the files in /boot/grub. In order to be able to read
them, the core image will include the required modules to read the
partition table and filesystem and optionally software RAID, LVM if
needed. Not sure about encryption. I never managed to boot with
/boot/grub on an encrypted volume.
The fourth chunk is the kernel and initrd/initramfs files that GRUB
loads to boot an OS, as they are part of the boot process (but not part
of GRUB itself). It can be located anywhere GRUB with all its modules
can read. It is usually in /boot.
If the boot image fails to load the core image, you'll get an error and
can do nothing but reboot. This happens when the core image was not
embedded and either filesystem blocks were moved around or the partition
containing /boot/grub was deleted.
If the core image fails to find the modules in /boot/grub/i386-pc/, it
will drop into a rescue shell with limited capabilities, allowing to
display known devices and correct the $prefix variable. This typically
happens after the partition which contained /boot/grub has been deleted.
If it fails to find the /boot/grub/grub.cfg file, it will drop into a
full-featured shell (the same you start by pressing 'c' in the boot
menu) instead of displaying the boot menu.
So, what did you mean exactly by "install GRUB on its own partition" ?
