В Tue, 15 Jul 2014 22:01:55 +0200 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@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. > > > >
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
