On Tue, Jan 05, 2010 at 12:33:23PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Colin Watson wrote: > > I don't understand why /boot on LVM should mean that grubenv is not > > writable. The point of grubenv is to be a short chunk of contiguous > > reserved disk space which can be written by GRUB without needing any > > special filesystem intelligence. Surely LVM doesn't split up those 1024 > > bytes into different physical extents? > > Consider a RAID-1 (mirror). Currently GRUB2 uses only one disk of the > mirror. It may even be possible that second disk is inaccessible through > currently loaded drivers. But writing would need to update all copies. > And what to do if second disk isn't accessible? Same problem is present > in other RAID levels too. > ZFS and btrfs have checksums. If you update a block you have to update > its checksum too, and checksum of block containg checksum and so on. So > at the end of the day the whole is more complicated that what we wanted. > And a mistake in writing code may lead to corruption of unrelated data.
I see. Perhaps in the short term we could have an extension to the test command to allow grub.cfg to determine whether grubenv is sanely writable? > IMO for long-term we need a better place for grubenv. I agree, although the question is where. If there were enough space in the embedding area then we could reserve a chunk of that, but aren't we generally pretty close to the limit there? -- Colin Watson [cjwat...@ubuntu.com] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
