Re: Environment block and LVM

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- 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 --]