[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with grub-reboot/savedefault/default=saved

From: Colin Watson
Subject: Re: Problems with grub-reboot/savedefault/default=saved
Date: Tue, 5 Jan 2010 11:48:20 +0000
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Jan 05, 2010 at 12:33:23PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko 
> 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

> 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                                       address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]