From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OtJ5F-0000Eb-Ev for mharc-grub-devel@gnu.org; Wed, 08 Sep 2010 07:44:57 -0400 Received: from [140.186.70.92] (port=55841 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtJ5B-0000EV-H3 for grub-devel@gnu.org; Wed, 08 Sep 2010 07:44:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtJ59-0003Gk-4v for grub-devel@gnu.org; Wed, 08 Sep 2010 07:44:53 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:35951) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtJ58-0003GS-SM for grub-devel@gnu.org; Wed, 08 Sep 2010 07:44:51 -0400 Received: by fxm3 with SMTP id 3so4295172fxm.0 for ; Wed, 08 Sep 2010 04:44:49 -0700 (PDT) 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=avGpgLoz7gb1nWZwJsCxjStJcqlpzSCl6ilvXh1gAWc=; b=QJfhoWQmtZm5HWKY2vGNzJ7zSlh2LNk4Nttb+UYc03+tedapnJrslUoVV3PxV1jOdJ zs98y9OfTAWQO6dGuOJPEF16Ly2UCRLXWzr/pdIKFuikjVJ3KOPasGrsTn1VcBQ43cYG UTwfJ9NaAFZFvvy/jxbvBTiB/o7zodrLyLh5s= 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=EWnYMmCd5D6p2H09b0P1Rw57oL9+vUSV+EznQkyGLLwc3dOvPURQHAL7LDS/LwSv3G tI7Ia0n6AtYbNi22sewthcZzURgi0j4S5sFVjqQo/ZXdIeK3CK1o29k0QIoTSKJAHsqO 2kK2UYxanAgCo2vcdyFKVQTDq+VYGSQBqnVyI= Received: by 10.223.108.11 with SMTP id d11mr1046500fap.79.1283946289514; Wed, 08 Sep 2010 04:44:49 -0700 (PDT) Received: from debian.bg45.phnet (224-225.62-81.cust.bluewin.ch [81.62.225.224]) by mx.google.com with ESMTPS id f28sm3398882faa.0.2010.09.08.04.44.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 08 Sep 2010 04:44:48 -0700 (PDT) Message-ID: <4C877727.10209@gmail.com> Date: Wed, 08 Sep 2010 13:44:39 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6 MIME-Version: 1.0 To: grub-devel@gnu.org References: <4C7C0223.4000306@gmail.com> <20100908105933.GJ21862@riva.ucam.org> In-Reply-To: <20100908105933.GJ21862@riva.ucam.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigC0AEDD87818262A7CDE37DAB" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [RFT] install branch 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: Wed, 08 Sep 2010 11:44:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0AEDD87818262A7CDE37DAB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 09/08/2010 12:59 PM, Colin Watson wrote: > On Mon, Aug 30, 2010 at 09:10:27PM +0200, Vladimir '=CF=86-coder/phcode= r' Serbinenko wrote: > =20 >> Hello. I've just merged all 3 different grub-install's we have in our >> tree to a single grub-install. This work is available as bzr checkout >> under http://bzr.savannah.gnu.org/r/grub/branches/install/. I also >> merged the EFI work by Colin Watson. Can anyone with ieee1275 and efi >> systems test the install branch? >> =20 > I haven't managed to test this yet, but I see one error: with EFI, > install_device is set after it needs to be used. I think you need > something like the following patch. > > =20 You can commit it into install branch. > BTW, was there any particular reason you dropped the handling of > target_cpu=3Darm from my patch, or did I just add that after sending it= to > you or something? I know we don't support ARM yet much less ARM/UEFI, > but there seems no harm in listing all of the architectures from the > UEFI specification. > =20 EFI concept is pretty much against the spirit of free software. Even though some sources are released, the most important ones (initialisation routines and device drivers for real platforms) aren't. While ia64, i386 and amd64 are already in EFI territory enough for us to have to support them, supporting it on ARM, rather than free-software UBoot would be counter-productive. > =3D=3D=3D modified file 'util/grub-install.in' > --- util/grub-install.in 2010-09-06 21:03:25 +0000 > +++ util/grub-install.in 2010-09-08 00:37:34 +0000 > @@ -301,6 +301,95 @@ else > exit 1 > fi > =20 > +if [ x"$platform" =3D xefi ]; then > + # Get GRUB_DISTRIBUTOR. > + if test -f ${sysconfdir}/default/grub ; then > + . ${sysconfdir}/default/grub > + fi > + > + # Find the EFI System Partition. > + efidir=3D > + if test -d ${bootdir}/efi; then > + install_device=3D`$grub_mkdevicemap --device-map=3D/dev/stdout | $gru= b_probe --target=3Ddevice --device-map=3D/dev/stdin ${bootdir}/efi` > + # Is it a mount point? > + if test "x$install_device" !=3D "x`$grub_mkdevicemap --device-map=3D/= dev/stdout | $grub_probe --target=3Ddevice --device-map=3D/dev/stdin ${bo= otdir}`"; then > + efidir=3D${bootdir}/efi > + fi > + elif test -n "$rootdir" && test "x$rootdir" !=3D "x/"; then > + # The EFI System Partition may have been given directly using > + # --root-directory. > + install_device=3D`$grub_mkdevicemap --device-map=3D/dev/stdout | $gru= b_probe --target=3Ddevice --device-map=3D/dev/stdin ${rootdir}` > + # Is it a mount point? > + if test "x$install_device" !=3D "x`$grub_mkdevicemap --device-map=3D/= dev/stdout | $grub_probe --target=3Ddevice --device-map=3D/dev/stdin ${ro= otdir}/..`"; then > + efidir=3D${rootdir} > + fi > + fi > + =20 > + if test -n "$efidir"; then > + efi_fs=3D`$grub_probe --target=3Dfs --device-map=3D${device_map} ${ef= idir}` > + if test "x$efi_fs" =3D xfat; then :; else > + echo "${efidir} doesn't look like an EFI partition." 1>&2 > + efidir=3D > + fi > + fi > + =20 > + if test -n "$efidir"; then > + # The EFI specification requires that an EFI System Partition = must > + # contain an "EFI" subdirectory, and that OS loaders are store= d in > + # subdirectories below EFI. Vendors are expected to pick name= s that do > + # not collide with other vendors. To minimise collisions, we = use the > + # name of our distributor if possible. > + if test $removable =3D yes; then > + # The specification makes stricter requirements of removable= > + # devices, in order that only one image can be automatically loade= d > + # from them. The image must always reside under /EFI/BOOT, and it= > + # must have a specific file name depending on the architecture. > + efi_distributor=3DBOOT > + case "$target_cpu" in > + i386) > + efi_file=3DBOOTIA32.EFI ;; > + x86-64) > + efi_file=3DBOOTX64.EFI ;; > + # GRUB does not yet support these architectures, but they're defi= ned > + # by the specification so we include them here to ease future > + # expansion. > + ia64) > + efi_file=3DBOOTIA64.EFI ;; > + esac > + else > + efi_distributor=3D"$(echo "$GRUB_DISTRIBUTOR" | tr '[A-Z]' '[a-z]= ' | cut -d' ' -f1)" > + if test -z "$efi_distributor"; then > + efi_distributor=3Dgrub > + fi > + # It is convenient for each architecture to have a different > + # efi_file, so that different versions can be installed in parall= el. > + case "$target_cpu" in > + i386) > + efi_file=3Dgrubia32.efi ;; > + x86-64) > + efi_file=3Dgrubx64.efi ;; > + # GRUB does not yet support these architectures, but they're defined= > + # by the specification so we include them here to ease future > + # expansion. > + ia64) > + efi_file=3Dgrubia64.efi ;; > + *) > + efi_file=3Dgrub.efi ;; > + esac > + # TODO: We should also use efibootmgr, if available, to add a Boot= > + # entry for ourselves. > + fi > + efidir=3D"$efidir/EFI/$efi_distributor" > + mkdir -p "$efidir" || exit 1 > + else > + # We don't know what's going on. Fall back to traditional > + # (non-specification-compliant) behaviour. > + efidir=3D"$grubdir" > + efi_distributor=3D > + efi_file=3Dgrub.efi > + fi > +fi > + > # Create the GRUB directory if it is not present. > mkdir -p "$grubdir" || exit 1 > =20 > @@ -501,93 +590,8 @@ elif [ "${target_cpu}-${platform}" =3D "i3 > } > fi > elif [ x"$platform" =3D xefi ]; then > - # Get GRUB_DISTRIBUTOR. > - if test -f ${sysconfdir}/default/grub ; then > - . ${sysconfdir}/default/grub > - fi > - > - # Find the EFI System Partition. > - efidir=3D > - if test -d ${bootdir}/efi; then > - install_device=3D`$grub_mkdevicemap --device-map=3D/dev/stdout | $gru= b_probe --target=3Ddevice --device-map=3D/dev/stdin ${bootdir}/efi` > - # Is it a mount point? > - if test "x$install_device" !=3D "x`$grub_mkdevicemap --device-map=3D/= dev/stdout | $grub_probe --target=3Ddevice --device-map=3D/dev/stdin ${bo= otdir}`"; then > - efidir=3D${bootdir}/efi > - fi > - elif test -n "$rootdir" && test "x$rootdir" !=3D "x/"; then > - # The EFI System Partition may have been given directly using > - # --root-directory. > - install_device=3D`$grub_mkdevicemap --device-map=3D/dev/stdout | $gru= b_probe --target=3Ddevice --device-map=3D/dev/stdin ${rootdir}` > - # Is it a mount point? > - if test "x$install_device" !=3D "x`$grub_mkdevicemap --device-map=3D/= dev/stdout | $grub_probe --target=3Ddevice --device-map=3D/dev/stdin ${ro= otdir}/..`"; then > - efidir=3D${rootdir} > - fi > - fi > - =20 > - if test -n "$efidir"; then > - efi_fs=3D`$grub_probe --target=3Dfs --device-map=3D${device_map} ${ef= idir}` > - if test "x$efi_fs" =3D xfat; then :; else > - echo "${efidir} doesn't look like an EFI partition." 1>&2 > - efidir=3D > - fi > - fi > - =20 > - if test -n "$efidir"; then > - # The EFI specification requires that an EFI System Partition = must > - # contain an "EFI" subdirectory, and that OS loaders are store= d in > - # subdirectories below EFI. Vendors are expected to pick name= s that do > - # not collide with other vendors. To minimise collisions, we = use the > - # name of our distributor if possible. > - if test $removable =3D yes; then > - # The specification makes stricter requirements of removable= > - # devices, in order that only one image can be automatically loade= d > - # from them. The image must always reside under /EFI/BOOT, and it= > - # must have a specific file name depending on the architecture. > - efi_distributor=3DBOOT > - case "$target_cpu" in > - i386) > - efi_file=3DBOOTIA32.EFI ;; > - x86-64) > - efi_file=3DBOOTX64.EFI ;; > - # GRUB does not yet support these architectures, but they're defi= ned > - # by the specification so we include them here to ease future > - # expansion. > - ia64) > - efi_file=3DBOOTIA64.EFI ;; > - esac > - else > - efi_distributor=3D"$(echo "$GRUB_DISTRIBUTOR" | tr '[A-Z]' '[a-z]= ' | cut -d' ' -f1)" > - if test -z "$efi_distributor"; then > - efi_distributor=3Dgrub > - fi > - # It is convenient for each architecture to have a different > - # efi_file, so that different versions can be installed in parall= el. > - case "$target_cpu" in > - i386) > - efi_file=3Dgrubia32.efi ;; > - x86-64) > - efi_file=3Dgrubx64.efi ;; > - # GRUB does not yet support these architectures, but they're defined= > - # by the specification so we include them here to ease future > - # expansion. > - ia64) > - efi_file=3Dgrubia64.efi ;; > - *) > - efi_file=3Dgrub.efi ;; > - esac > - # TODO: We should also use efibootmgr, if available, to add a Boot= > - # entry for ourselves. > - fi > - efidir=3D"$efidir/EFI/$efi_distributor" > - mkdir -p "$efidir" || exit 1 > - else > - # We don't know what's going on. Fall back to traditional > - # (non-specification-compliant) behaviour. > - efidir=3D"$grubdir" > - efi_distributor=3D > - efi_file=3Dgrub.efi > - fi > cp ${grubdir}/core.${imgext} ${efidir}/${efi_file} > + > # Try to make this image bootable using the EFI Boot Manager, if a= vailable. > if test "$removable" =3D no && test -n "$efi_distributor" && \ > test -n "$efibootmgr"; then > @@ -619,7 +623,6 @@ elif [ x"$platform" =3D xefi ]; then > -L "$GRUB_DISTRIBUTOR" -l "\\EFI\\$efi_distributor\\$efi_file" > fi > fi > - > fi > =20 > echo "Installation finished. No error reported." > > Thanks, > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigC0AEDD87818262A7CDE37DAB 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/ iF4EAREKAAYFAkyHdy4ACgkQNak7dOguQgmbsQEAhnsuwRywuXSR+EmGAh+v+Ths Qd3JqBuz1TR5bexvMygA/2bJKHD6Xw4bmDdJiHMJXyndVYyKgi9PrTpPqj8lom4x =+x9/ -----END PGP SIGNATURE----- --------------enigC0AEDD87818262A7CDE37DAB--