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. >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
