[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Force location of GRUB's boot and core images ?

From: Pascal Hambourg
Subject: Re: Force location of GRUB's boot and core images ?
Date: Wed, 12 Apr 2017 10:28:32 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.6.0

Le 10/04/2017 à 05:08, Andrei Borzenkov a écrit :
09.04.2017 23:32, Pascal Hambourg пишет:

Yes. IME, grub-install refuses embedding on a partition with an
unknown format, e.g. an empty partition. And I need embedding.

Can you tell me what your use case is, out of interest?

My current use case is to install a new GNU/Linux system entirely in an
encrypted (LUKS) partition on a disk which already contains an existing
GNU/Linux system. The existing boot loader is installed in the MBR and
must be left untouched. However it cannot boot the new system because
even /boot is encrypted. So I need to install GRUB with encryption
support as a secondary boot loader. Its boot and core images cannot be
installed in the encrypted partition.

Must /boot/grub be encrypted as well?

Not in this use case. But I do not see how putting /boot/grub on a separate unencrypted filesystem helps solving the embedding issue.

A more general use case is to install multiple instances of GRUB as
independent secondary boot loaders, and not store the core image as a
standard file using blocklists because it is not reliable.

You need to point some master bootloader to this partition, right? What
is your master bootloader?

At the moment it is GRUB.
But It may be any other boot loader with chainloading ability such as LILO, Syslinux or even DOS/Windows MBR. So I'd rather have a more generic solution which does not rely on GRUB as the primary boot loader. Otherwise I would not bother with embedding, since GRUB can safely load another GRUB core image from a plain file with the "multiboot" command.

If this is grub, you can create small grub
image which just loads grub from your encrypted partition and have
master grub load it.

I do not understand. What are you calling a "grub image" ?
Are you suggesting to chain three GRUB instances (the primary one, the small GRUB image and the one of the encrypted system) ?

The only intended use for the partition is to install GRUB, and I want
it as small as possible. Boot image + core image take less than 100 kB
and I'd rather avoid allocating a multi-GB btrfs partition for this.

To be honest, I've been exaggerating a bit btrfs minimum size requirements. After more thorough testing, it appears that mkfs.btrfs requires at least 16 MiB (with --mixed option on newer versions, 100 MiB otherwise).

If /boot/grub can remain unencrypted (after all, it does not really
contain anything core.img cannot) you can simply install it as

mount /dev/sda5 /mnt
grub-install --boot-directory=/mnt /dev/sda5

using something like ext2 or FAT.

Neither ext2 or FAT support embedding, so this suggestion requires using blocklists (and --force to allow it), which I'd rather avoid.

I insist on not using blocklists because I have been bitten once by block remapping of the core image file.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]