Re: Future of installing GRUB to LVM volumes (and loop devices)

[Jordan Uggla]

On Sat, May 16, 2015 at 7:10 AM, Sebastian Pipping
<address@hidden> wrote:
> On 16.05.2015 05:47, Jordan Uggla wrote:
>>> The setup is a single plain partition in an LVM volume.
>>>
>>> The following commands reproduce the setup (in RAM if /tmp is tmpfs).
>>> With a plain LVM volume, the error is the same tough.
>>>
>>>   # tmpfile="$(mktemp)"
>>>   # echo "${tmpfile}"
>>>   # truncate --size=$((100*1024**2)) "${tmpfile}"
>>>   # loop_device_2="$(losetup --show -f "${tmpfile}")"
>>>   # echo "${loop_device_2}"
>>>   # vgcreate vg "${loop_device_2}"
>>>   # lvcreate --name lv -l 100%free vg
>>>   # sleep 1
>>>
>>>   # parted /dev/vg/lv --script mklabel msdos
>>>   # parted /dev/vg/lv --script mkpart primary ext4 4m 100%
>>>   # sleep 1
>>>   # mkfs.ext4 /dev/mapper/vg-lv1
>>>   # mkdir /mnt/lv-root
>>>   # mount /dev/mapper/vg-lv1 /mnt/lv-root
>>>   # mkdir /mnt/lv-root/boot
>>>   # grub-install --boot-directory=/mnt/lv-root/boot /dev/mapper/vg-lv ;
>>
>> That is a nonsensical grub-install command.
>
> I do not approve of calling nonsense on me.  Don't do that.  Thanks.

I did not intend to insult you, and I'm sorry that my message did.
That said, without a device.map specifying that /dev/mapper/vg-lv will
be seen as a drive from the booting environment, that grub-install
command literally does not make sense. You are telling grub to prepare
an environment that cannot possibly work.

>
>
>> You're telling grub-install that you want grub's boot sector and
>> core.img to be installed to a device that cannot possibly be accessed
>> by your BIOS (unless you have a BIOS that understands LVM). It may be
>> that it should be failing with a better error message, or that there
>> is a better example of what should be working that isn't, but I would
>> never expect this command to work. I'm not even sure what semantics
>> you would expect from this command, and if it happened to do what you
>> wanted it to do in the past I can only imagine that that was a "lucky"
>> quirk of the implementation.
>
> The tempfile and loop device are for (1) not messing with any
> producution LVM volume group of the host system and (2) for being able
> to write to work with RAM rather than wasting disk cycles.
> If that looks wierd to you: it's for reproduction purposes.
> As I wrote above "With a plain LVM volume, the error is the same".

Note that I made no mention of the tempfile or the loop device. The
command makes just as little sense with a plain LVM volume. The part
that makes no sense is installing grub's boot sector to something that
is clearly an LVM volume (without a device.map clarifying that it will
look like a drive at boot).

>
> For the second half, the host BIOS does not have to be able to boot from
> that GRUB since I'm creating a virtual machine image here.  In the mail
> starting this thread I explained:

Using grub-install from a host to install grub for use in a VM (where
the devices involved will be exposed differently to the the VM than
they are to the host) is exactly what the device.map is for. For grub
to properly prepare such a setup (without getting lucky due to a quirk
of the implementation) grub-install needs to know how the devices will
be exposed to the VM.

>
>   "I have a case where grub-install is asked to install to an
>   LVM volume [1] that is later passed to Xen to boot a Xen guest.
>   Inside the Xen guest the LVM volume is seen as a regular hard disk.
>
>   [1] from inside a tool called grmldeboostrap [2], a wrapper around
>       deboostrap installing Debian to a given block device"

Please correct me if I am wrong, but it seemed like in earlier mails
it was said that this does work if you add a device.map entry like
"(hd0) /dev/mapper/vg-lv". If that is the case, then I don't see
anything wrong (except lack of documentation and poor error messages).

I think that "grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv" without a device.map should not be expected to
work.

I think that "grub-install --boot-directory=/mnt/lv-root/boot
/dev/mapper/vg-lv" with a device.map clarifying the usage of
/dev/mapper/vg-lv as a virtual drive should work.

If you disagree still, and think that the case without a device.map
should work, I ask how you think that grub should detect that this
device is intended to be used with a VM, and how that VM will expose
the device to the guest?

It's much more common in my experience that users pass non-drive
devices to grub-install (usually /dev/md0) because they are confused,
not because they are preparing a VM where that device will show up as
a drive. I do not think that it is good to always assume that a device
passed to grub-install will be exposed as drive at boot. I think to
make such an assumption, and have grub-install not error out, would
lead to users thinking that "grub-install /dev/mapper/vg-lv" or
"grub-install /dev/md0" on their non virtual machine setups had
succeeded, where it had actually silently broken their ability to
boot.

All of that said, we don't currently protect users from this in all
cases, and we certainly could to a much better job of reporting
helpful error messages, and providing further documentation in the
manual, to help users understand and correct the problem.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)