From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VPOSD-00063g-JZ for mharc-grub-devel@gnu.org; Thu, 26 Sep 2013 23:10:53 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPOS3-00062r-Fc for grub-devel@gnu.org; Thu, 26 Sep 2013 23:10:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VPORv-00039B-1w for grub-devel@gnu.org; Thu, 26 Sep 2013 23:10:43 -0400 Received: from mail-la0-x231.google.com ([2a00:1450:4010:c03::231]:37391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VPORu-000393-Q4 for grub-devel@gnu.org; Thu, 26 Sep 2013 23:10:34 -0400 Received: by mail-la0-f49.google.com with SMTP id ev20so1634960lab.8 for ; Thu, 26 Sep 2013 20:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type; bh=uKkXslc2gOLlHLzhG8/LyvzsApmHmLQYV83tPP5IaIw=; b=dfoivcaOpmyHuqDkbZ10xko7MV84T3YDhNVQzq1oXOvPzb1jkBbpjkCIzgj66mb2Dd BW0T0zKbnX5J/XvT1pQbIoF2KUHCxmXWBJAXjZ468VWRyl21dtLWlmm9R2D0TLcXUXE4 jdNZMB2G14ChJhp6EkAhyCYE3wBNziFdcjWItsXtEGznOBdiPAKvHpx/JOdALfhdt7bI n2nL+pIe6348zbvu8ebke2hU4BvJLwA9VkqrTTiZBPWcN4x7rFLubjOUH85QmBOIEyTm bv/HMU57C2pAuY7A1Qq9kZ10srfxU4ryE4Rqf4rvoZ8v2v3wIUbX7JJUWRq3bGUHItUL nFzg== X-Received: by 10.112.29.147 with SMTP id k19mr6696408lbh.9.1380251433839; Thu, 26 Sep 2013 20:10:33 -0700 (PDT) Received: from opensuse.site (ppp91-76-150-246.pppoe.mtu-net.ru. [91.76.150.246]) by mx.google.com with ESMTPSA id ao4sm4018914lac.1.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 26 Sep 2013 20:10:33 -0700 (PDT) Date: Fri, 27 Sep 2013 07:10:32 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: [RFC] grub-install C rewrite Message-ID: <20130927071032.13c85a56@opensuse.site> In-Reply-To: <524481D0.80206@gmail.com> References: <524431E6.60807@gmail.com> <20130926133504.GQ13097@csclub.uwaterloo.ca> <52443DA7.1030707@gmail.com> <20130926144400.GR13097@csclub.uwaterloo.ca> <524481D0.80206@gmail.com> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/zKRsCntiB4C/r9=2JO/Y2RP"; protocol="application/pgp-signature" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::231 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: Fri, 27 Sep 2013 03:10:52 -0000 --Sig_/zKRsCntiB4C/r9=2JO/Y2RP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =D0=92 Thu, 26 Sep 2013 20:49:52 +0200 Vladimir '=CF=86-coder/phcoder' Serbinenko =D0=BF=D0=B8= =D1=88=D0=B5=D1=82: > On 26.09.2013 16:44, Lennart Sorensen wrote: > >> windows is low priority and more of a bonus. The problems of handling > >> anything that looks like a list (e.g. list of devices where / resides = on > >> in case of btrfs) and code becoming hairy to handle those cases is > >> bigger reason. > >=20 > > Sure lists can be a hassle. > >=20 > > I didn't check lately, but does grub-install understand a list of devic= es > > to install to yet? > >=20 > > ie: grub-install /dev/sda /dev/sdb > >=20 > > After all if I have software raid, both those devices contain /boot and > > are valid to boot from. And since on things like IBM powerpc, > > grub-install likes to update the firmware with the list of boot devices, > > they do all have to be specified at once or you end up with the wrong > > list (which so far I have worked around by manually fixing the firmware > > settings after updating grub, which doesn't happen very often lately). > >=20 > > So calling grub-install for each device in turn (as I believe Debian > > does on x86 if you tell it multiple boot devices), does not actually > > give the correct result. > >=20 This will break in blocklist install because every time core.img is recreated, but I do not see why it should not work if embedding is possible. Challenge is to atomically detect whether this is possible or not for all devices before you have clobbered half of them. Although right now we first rewrite /boot/grub and then try to install; if installation fails, /boot/grub no more matches embedded core.img anyway. > This is interesting testcase which wasn't brought before. This would > potentially involve creating several core.img or forcing UUID when using > multiple devices. Again, pretty easy in C and hairy in bash due to list > handling. Why it would require separate core.img? core.img needs to know how access /boot/grub, and /boot/grub remains the same. Same with UUID. Or do I miss something here? >=20 > It's also possible to have options --dry-run (doesn't really do the > changes, except, perhaps, "mkdir -p") and --gen-script which would > generate a list of commands which when executed would do exactly as if > grub-install was run. So you can do > grub-install --dry-run --gen-script=3D/tmp/myinstall ... > > /tmp/myinstall > This has additional advantage of see which commands are really executed > without having to understand the whole command flow. >=20 That would definitely be useful irrespectively of which language is used to implement. In particular, this would allow to see list of modules required for a system. --Sig_/zKRsCntiB4C/r9=2JO/Y2RP Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJE9ygACgkQR6LMutpd94zgpgCfXYtXE0qbcpzTrqy1z5OP5HJi sKkAoIupbjXfxzbWILyNC8GVKHsjQldW =rEEk -----END PGP SIGNATURE----- --Sig_/zKRsCntiB4C/r9=2JO/Y2RP--