Hi Pascal,
On 28/11/16 12:48, Pascal Hambourg wrote:
> 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.
One day I'll have to bite that bullet but that day has not come yet :-)
>
> 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
This is how I've done it (before using extlinux). I still have a few
servers on grub using this method.
>
> 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.
Yep. Haven't seen Windows mucking up the MBR with an update though - yet.
> 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.
Only keeping Windows on my workstation for video editing with Windows
running on the bare metal.
Never on the servers though.
>
>> /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.
For new servers I surely will be using more LVM and less partitions.
DOS/MBR partitions work fine for me though...
thanks,
Jan
