Colin Watson wrote: >> 4: Even with the first grub-reboot fix the default is still not restored >> when grubenv is not writable ( /boot on lvm for example ). Since >> grub-reboot can't work without a writable grubenv it's at least safer to >> boot into the "real" default instead of the "temporary" default. The >> fourth patch sets default=$prev_saved_default if save_env fails. >> Grub-reboot ( the utility ) should also complain when grubenv isn't >> writable by grub. What is the best way to determine that grubenv likely is >> or isn't writable by grub? >> > > 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. IMO for long-term we need a better place for grubenv.
-- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
