From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1X78vV-0000eC-U3 for mharc-grub-devel@gnu.org; Tue, 15 Jul 2014 16:02:13 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X78vR-0000bE-AZ for grub-devel@gnu.org; Tue, 15 Jul 2014 16:02:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X78vQ-0000nM-Cf for grub-devel@gnu.org; Tue, 15 Jul 2014 16:02:09 -0400 Received: from mail-we0-x230.google.com ([2a00:1450:400c:c03::230]:45321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X78vQ-0000lz-5T for grub-devel@gnu.org; Tue, 15 Jul 2014 16:02:08 -0400 Received: by mail-we0-f176.google.com with SMTP id q58so2649017wes.7 for ; Tue, 15 Jul 2014 13:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=15TB37nPw3W3csRjkiO0GIoz4rLHWzCYud6mxue53i4=; b=hmpRsFeEuK00O7YbaQe1GUtJPKSHDdbi6Kj9b0gs7wk/JqZxkwWutz/Cfjtgz4+1Dr cEMPZOQWdoqpeothsuZyj7rZpK+GRbeoCC6e6t5qNeKSb3kjZq8nq7DAQZzbZ8pVBJBx n4Ye+WwWwAc617djDu7AR7a2MiuDE6HBTpoRZQS4cQO2mkdv9GkPsOGrtPjM7Lljz8k1 8j/GnuKftpJgMOaYW6AaB4rj2ul/TwLWDtokYZ+y7m2gDARsxGuyvN3TqbgPDNZvlEQV lY2mE8O+KsbrnYDQklnE7CAFRTWgKMhQB6/0MdK55Euv57jFC5tiXzIktD6BDQf4J+x8 W2dw== X-Received: by 10.194.87.134 with SMTP id ay6mr29123979wjb.84.1405454526768; Tue, 15 Jul 2014 13:02:06 -0700 (PDT) Received: from ?IPv6:2a02:1205:34e1:3c90:969f:b4ff:fedd:5bb? ([2a02:1205:34e1:3c90:969f:b4ff:fedd:5bb]) by mx.google.com with ESMTPSA id go4sm34703354wjc.39.2014.07.15.13.02.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jul 2014 13:02:05 -0700 (PDT) Message-ID: <53C588B3.8010706@gmail.com> Date: Tue, 15 Jul 2014 22:01:55 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: Environment block and LVM References: <1144594563.117221.1405322508517.JavaMail.zimbra@opinsys.fi> <616962202.117314.1405325936382.JavaMail.zimbra@opinsys.fi> <20140714120353.GA32372@riva.ucam.org> In-Reply-To: <20140714120353.GA32372@riva.ucam.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NCBucOIIWS2AFNAU7MWHGCIFdHSvFMcHU" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::230 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 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, 15 Jul 2014 20:02:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NCBucOIIWS2AFNAU7MWHGCIFdHSvFMcHU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14.07.2014 14:03, Colin Watson wrote: > On Mon, Jul 14, 2014 at 08:18:56AM +0000, Tuomas R=C3=A4s=C3=A4nen wrot= e: >> 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 a= nd >> it works by accident? >=20 > 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. >=20 > At least on checksumming filesystems and on RAID, the main reason for > not supporting this is that we have to be rather conservative about wha= t > 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. >=20 > 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. >=20 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 nee= d > 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. >=20 --NCBucOIIWS2AFNAU7MWHGCIFdHSvFMcHU 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 iF4EAREKAAYFAlPFiLsACgkQmBXlbbo5nOvQDgEAmgx2vi7fOOtDFkfAH9TU8KbV 6EKkOZyan1ziu0mSVA8BAJPhNl8cqFlJIVqii0jUxEcgDDp+IsTavxOmbJFFKYjS =kWB6 -----END PGP SIGNATURE----- --NCBucOIIWS2AFNAU7MWHGCIFdHSvFMcHU--