Environment block and LVM

Environment block and LVM

[Tuomas Räsänen]

Hi

The GRUB manual says:

> For safety reasons, this storage is only available when installed on a
> plain disk (no LVM or RAID), using a non-checksumming filesystem (no
> ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).

However, in our systems, load_env seems to load the environment block
from LVM without any problems. On the other hand, save_env fails.

Is load_env + LVM now supported or is there something weird going on and
it works by accident?

We are running GRUB 2.02~beta2 packaged by Debian (2.02~beta2-9 is the
complete package version number).

--
Tuomas

Re: Environment block and LVM

[Colin Watson]

On Mon, Jul 14, 2014 at 08:18:56AM +0000, Tuomas Räsänen wrote:
> The GRUB manual says:
> > For safety reasons, this storage is only available when installed on a
> > plain disk (no LVM or RAID), using a non-checksumming filesystem (no
> > ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).
> 
> However, in our systems, load_env seems to load the environment block
> from LVM without any problems. On the other hand, save_env fails.
> 
> Is load_env + LVM now supported or is there something weird going on and
> it works by accident?

This section of the manual is referring to the whole feature, including
saving.  It's true that load_env will work as long as GRUB is able to
understand the device and filesystem; but save_env has the constraints
above.

At least on checksumming filesystems and on RAID, the main reason for
not supporting this is that we have to be rather conservative about what
writes we do to avoid breaking things.  save_env is a very useful
feature, but it's not actually required to boot the system and so we
should only support it where it's safe.

In some other environments, the main reason we don't support this is
simply that it's a non-trivial amount of code that we haven't written
yet and that isn't needed for anything else.

I suspect that LVM falls into the second category rather than the first,
but Vladimir might overrule me.  If we did implement this, we would need
to be careful to ensure that the code is structured to make it very
difficult to make the mistake of writing to the wrong part of the disk
and to put suitable automatic tests in place, since we can't expect the
writing paths in GRUB to be exercised as frequently as the reading
paths.

-- 
Colin Watson                                       [cjwatson@ubuntu.com]

Re: Environment block and LVM

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

On 14.07.2014 14:03, Colin Watson wrote:
> On Mon, Jul 14, 2014 at 08:18:56AM +0000, Tuomas Räsänen wrote:
>> The GRUB manual says:
>>> For safety reasons, this storage is only available when installed on a
>>> plain disk (no LVM or RAID), using a non-checksumming filesystem (no
>>> ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).
>>
>> However, in our systems, load_env seems to load the environment block
>> from LVM without any problems. On the other hand, save_env fails.
>>
>> Is load_env + LVM now supported or is there something weird going on and
>> it works by accident?
> 
> This section of the manual is referring to the whole feature, including
> saving.  It's true that load_env will work as long as GRUB is able to
> understand the device and filesystem; but save_env has the constraints
> above.
> 
> At least on checksumming filesystems and on RAID, the main reason for
> not supporting this is that we have to be rather conservative about what
> writes we do to avoid breaking things.  save_env is a very useful
> feature, but it's not actually required to boot the system and so we
> should only support it where it's safe.
> 
> In some other environments, the main reason we don't support this is
> simply that it's a non-trivial amount of code that we haven't written
> yet and that isn't needed for anything else.
> 
LVM can have RAID inside of it. Or even worse: snapshots. If current
volume is snapshotted you shouldn't write to it. Only very small subset
of LVM features could be supported for writing. This would make it
confusing. I don't dismiss this possibility of writing to some LVM
subset but probably still not a good idea. I'd pretty much prefer using
LVM embedding zone for this.
> I suspect that LVM falls into the second category rather than the first,
> but Vladimir might overrule me.  If we did implement this, we would need
> to be careful to ensure that the code is structured to make it very
> difficult to make the mistake of writing to the wrong part of the disk
> and to put suitable automatic tests in place, since we can't expect the
> writing paths in GRUB to be exercised as frequently as the reading
> paths.
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]

Re: Environment block and LVM

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

В Tue, 15 Jul 2014 22:01:55 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

> On 14.07.2014 14:03, Colin Watson wrote:
> > On Mon, Jul 14, 2014 at 08:18:56AM +0000, Tuomas Räsänen wrote:
> >> The GRUB manual says:
> >>> For safety reasons, this storage is only available when installed on a
> >>> plain disk (no LVM or RAID), using a non-checksumming filesystem (no
> >>> ZFS), and using BIOS or EFI functions (no ATA, USB or IEEE1275).
> >>
> >> However, in our systems, load_env seems to load the environment block
> >> from LVM without any problems. On the other hand, save_env fails.
> >>
> >> Is load_env + LVM now supported or is there something weird going on and
> >> it works by accident?
> > 
> > This section of the manual is referring to the whole feature, including
> > saving.  It's true that load_env will work as long as GRUB is able to
> > understand the device and filesystem; but save_env has the constraints
> > above.
> > 
> > At least on checksumming filesystems and on RAID, the main reason for
> > not supporting this is that we have to be rather conservative about what
> > writes we do to avoid breaking things.  save_env is a very useful
> > feature, but it's not actually required to boot the system and so we
> > should only support it where it's safe.
> > 
> > In some other environments, the main reason we don't support this is
> > simply that it's a non-trivial amount of code that we haven't written
> > yet and that isn't needed for anything else.
> > 
> LVM can have RAID inside of it. Or even worse: snapshots. If current
> volume is snapshotted you shouldn't write to it. Only very small subset
> of LVM features could be supported for writing. This would make it
> confusing. I don't dismiss this possibility of writing to some LVM
> subset but probably still not a good idea. I'd pretty much prefer using
> LVM embedding zone for this.

It's not limited to LVM, we have pretty much the same problem with
btrfs, zfs or /boot on RAID, including fake RAID. Some common solution
is needed, but the main problem is how user space (grub-editenv) should
know where environment block is located.

> > I suspect that LVM falls into the second category rather than the first,
> > but Vladimir might overrule me.  If we did implement this, we would need
> > to be careful to ensure that the code is structured to make it very
> > difficult to make the mistake of writing to the wrong part of the disk
> > and to put suitable automatic tests in place, since we can't expect the
> > writing paths in GRUB to be exercised as frequently as the reading
> > paths.
> > 
> 
> 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]