Re: Dual Boot
Le 27/11/2016 à 21:02, Jan Bakuwel a écrit :
On 26/11/16 11:01, Pascal Hambourg wrote:
When embedding is not possible, the core image is stored as a regular
file in /boot/grub. Then /boot/grub must be on the same drive as the
boot image. However blocklists are not reliable with files, because
the filesystem may move blocks containing a file around.
I find it extremely useful (to the point where it once literally saved
me from disaster which is a story beyond the context of this thread) to
have multiple OS-es installed on any machine. I've been doing that for
years and even with grub it has - so far - always worked fine. But I
hear you that that's not a guarantee, and thus I started using extlinux.
I think that I experienced that problem once (but not sure), and needed
to reinstall GRUB. To be honest, the chances that the blocs containing
the core image may be moved around are very thin if you have a separate
ext2 /boot partition, which is rarely modified.
Which brings me to the following question: what is the recommended way
to boot multiple OSes with grub, for example with a partition layout as
below. Or is there simply no sane way to do this with grub?
I would not pretend to know "the recommended way".
However I would recommend a few layouts for some configurations.
If EFI boot is an option, then install all systems for EFI boot (for
Windows this implies a GPT partition table on the boot disk). This way
all bootloaders can be installed in separate directories in the EFI
system partition without overwriting one another. You can define one of
them as the primary boot loader with higher boot priority in the EFI
boot list.
For BIOS boot, without Windows I would recommend to install a primary
GRUB in the MBR with embedding. Install secondary GRUBs in partitions
boot records, without embedding. Then you have several options :
- add all entries for Windows and other Linux system kernels in the main
GRUB menu, which can be done automatically with os-prober called by
update-grub. The drawback is that the main boot menu must be updated
everytime a secondary boot loader is updated.
- add entries to chainload the secondary boot loaders in the main GRUB
menu, so that the main boot menu does not have to be updated when a
secondary boot loader is updated. The "multiboot" command can be used to
load a secondary GRUB core image file, so the embedding requirement does
not apply here.
- include or load secondary GRUB config files in the main boot menu.
This does not work well with different versions of GRUB, so I do not
recommend it.
One must also decide whether to use the GRUB belonging to one of the
Linux systems or an independent GRUB as the main boot loader. Of course
there is less risk to damage an independent boot loader.
So my advice for a safe setup would be to :
- install the main GRUB in the MBR and its own partition for /boot/grub
- install each secondary GRUB in its OS partition
- chainload secondary GRUBs in the main GRUB's boot menu
Unfortunately with Windows the MBR is not a safe place because Windows
overwrites the MBR at installation and sometimes when updating, so be
prepared to restore a backup or reinstall GRUB. The boot record of the
main GRUB's partition is a safer place, but it prevents embedding, so
the risk of moving blocks comes back. However this partition should not
be mounted and modified often, so the risk is low.
/dev/sda1: boot/rescue system
/dev/sda2: Windows 7
/dev/sda3: Windows 10
/dev/sda5: /boot - Linux system 1
/dev/sda6: / - Linux system 1
/dev/sda7: /var - Linux system 1
/dev/sda8: /var/log - Linux system 1
/dev/sda9: /boot - Linux system 2
/dev/sda10: / - Linux system 2
/dev/sda11: /var - Linux system 2
/dev/sda12: /var/log - Linux system 2
/dev/sda13: swap
/dev/sda14: LVM
From the missing /dev/sda4, I guess it is an extended partition and
/dev/sda{5..14} are logical partitions in a DOS/MBR scheme. 10 logical
partition is quite a lot. The linked list extended partition structure
is quite fragile and rigid. A GPT partition table would be more robust,
but it requires to reinstall reinstall Windows in EFI mode, and of
course that the motherboard firmware is a UEFI. Otherwise, using LVM for
most filesystems and swap is an option to reduce the number of partitions.
Reply to: