Re: Environment block and LVM

[Andrey Borzenkov <arvidjaar@gmail.com>]

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