From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NS7fV-0002ve-3W for mharc-grub-devel@gnu.org; Tue, 05 Jan 2010 06:33:45 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NS7fR-0002sN-Mv for grub-devel@gnu.org; Tue, 05 Jan 2010 06:33:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NS7fL-0002kn-SP for grub-devel@gnu.org; Tue, 05 Jan 2010 06:33:40 -0500 Received: from [199.232.76.173] (port=49829 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NS7fL-0002kT-0s for grub-devel@gnu.org; Tue, 05 Jan 2010 06:33:35 -0500 Received: from mail-bw0-f215.google.com ([209.85.218.215]:42895) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NS7fK-0000rs-Fg for grub-devel@gnu.org; Tue, 05 Jan 2010 06:33:34 -0500 Received: by bwz7 with SMTP id 7so10975577bwz.26 for ; Tue, 05 Jan 2010 03:33:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=wZPY3Cc0eK7Y1n6jimqyIanyodqfhubGaS3pNWc2E+8=; b=iKNfKO2HDY0o4vu8FYA+ksNvGQvWmxVq8wJM+1Qm8SKFEB3M2tANGfZASywF/zs2l1 JxnrgHnxiOxDbS3b3tZix1VX8cCsd2bTC/VmU+b//CfRJzlz2jQFa0NvIGTYSOetg2tt PoPsDDHUKMfjjj/H/+1QhEkH0OEMVQwNBXu/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=USFzT8o0znQGcwo+b79UUKOm1VPC5m6ad8ZSijEr8/nUhwALYG5fB8BCsQxCY/X4Hp UDAVvCb7//NulVGuIuyQyh4t+GQS7bpeb5rmDYe7KTVPF5H/UliCRjEjp/MFLOq318gW JvcqTPuSHqvnJZAzQa+b0nknQd48EmtFhACMc= Received: by 10.204.34.212 with SMTP id m20mr11519243bkd.55.1262691213148; Tue, 05 Jan 2010 03:33:33 -0800 (PST) Received: from debian.bg45.phnet (114-118.1-85.cust.bluewin.ch [85.1.118.114]) by mx.google.com with ESMTPS id 13sm5402581bwz.10.2010.01.05.03.33.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 05 Jan 2010 03:33:31 -0800 (PST) Message-ID: <4B432383.10604@gmail.com> Date: Tue, 05 Jan 2010 12:33:23 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <4B295EF3.6050401@gmail.com> <20100105110855.GD5847@riva.ucam.org> In-Reply-To: <20100105110855.GD5847@riva.ucam.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig471E4F93FC7E94A0A94DC983" X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Problems with grub-reboot/savedefault/default=saved X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2010 11:33:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig471E4F93FC7E94A0A94DC983 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Colin Watson wrote: >> 4: Even with the first grub-reboot fix the default is still not restor= ed=20 >> when grubenv is not writable ( /boot on lvm for example ). Since=20 >> grub-reboot can't work without a writable grubenv it's at least safer = to=20 >> boot into the "real" default instead of the "temporary" default. The=20 >> fourth patch sets default=3D$prev_saved_default if save_env fails.=20 >> Grub-reboot ( the utility ) should also complain when grubenv isn't=20 >> writable by grub. What is the best way to determine that grubenv likel= y is=20 >> or isn't writable by grub? >> =20 > > 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? > > =20 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. --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enig471E4F93FC7E94A0A94DC983 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAktDI4gACgkQNak7dOguQgmB4QD/dqJWprOJ6lNfAUX7PdOE3yLj 5pRNZYjqzctUgYxoVCUA/RtdtfkUc5N1PmM7rrXaylJO3fG61qzODEzP+m4LenQP =TSnD -----END PGP SIGNATURE----- --------------enig471E4F93FC7E94A0A94DC983--