From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1O3COJ-0007z4-Cx for mharc-grub-devel@gnu.org; Sat, 17 Apr 2010 14:05:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3COH-0007yV-PJ for grub-devel@gnu.org; Sat, 17 Apr 2010 14:05:13 -0400 Received: from [140.186.70.92] (port=44657 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3COG-0007wx-07 for grub-devel@gnu.org; Sat, 17 Apr 2010 14:05:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3COC-0006rH-9E for grub-devel@gnu.org; Sat, 17 Apr 2010 14:05:11 -0400 Received: from fg-out-1718.google.com ([72.14.220.155]:2910) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3COB-0006qk-Tw for grub-devel@gnu.org; Sat, 17 Apr 2010 14:05:08 -0400 Received: by fg-out-1718.google.com with SMTP id e12so928645fga.12 for ; Sat, 17 Apr 2010 11:05:06 -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=1QvLlkD3+zAgPzShbYOoo8HdFFqKIIYpsyUUgCOEmlA=; b=M4AX0K8PARDgKrf7jROsfHvmU53H4WrbDhBLI6uPOVlbdpucqKlzZPfxqhiWG3Lsk7 NoZgZwooKZ9o9z6Rb8mKnQvIVYE1Ja6h696n23MtcqytOrbAe+leCp/RjkdhHuTSfWyJ /ShgHCSLAr65oh375ElUZuGuxCFORlWnhhg+8= 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=TBBii8C1fmE+b/xkuxSAnYAZZR6JOwMrVjmcW2ZewICYeCCs5Ga1oIQW6bCvonoXT+ 3qoRw0DtYPS+LOwyo065swRg9pZrQ3AteAPZWUpDvTqz/K5RTC34HP2+7YLyWmew0LSG NPY+WtLeAdi7BWU4TAaOAFP8CDf91R1WJWrCw= Received: by 10.86.126.33 with SMTP id y33mr2477661fgc.51.1271527506613; Sat, 17 Apr 2010 11:05:06 -0700 (PDT) Received: from debian.bg45.phnet (52.115.63.81.cust.bluewin.ch [81.63.115.52]) by mx.google.com with ESMTPS id 3sm2264024fge.25.2010.04.17.11.05.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Apr 2010 11:05:06 -0700 (PDT) Message-ID: <4BC9F848.5070906@gmail.com> Date: Sat, 17 Apr 2010 20:04:56 +0200 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: <4BC9CBD1.8020008@gmail.com> <10640994327740@192.168.2.69> In-Reply-To: <10640994327740@192.168.2.69> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF2DDB8B800684482FD1F120A" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: How to prepare an ISO 9660 CD for booting via GRUB ? 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: Sat, 17 Apr 2010 18:05:14 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF2DDB8B800684482FD1F120A Content-Type: multipart/mixed; boundary="------------010909050503010608010108" This is a multi-part message in MIME format. --------------010909050503010608010108 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thomas Schmitt wrote: > Hi, > > Vladimir Serbinenko: > =20 >> efi booting [...] it's basically standard no-emul >> eltorito except: >> platform_id[0] =3D 0xef; >> =20 > > I assume you mean the Platform ID as of El Torito > specs about the Boot Catalog and its Validation > Entry. (Chapter 2, figure 2) > > That should be easy to test. > In libisofs/eltorito.c, there is a line > ve->platform_id[0] =3D 0; /* 0: 80x86, 1: PowerPC, 2: Mac */ > > =20 Yes. I attach the patch I used for dirty checks > A bit more work will be to make this controllable > by the libisofs API. > > =20 This is exactly why I asked you: I'm not familiar with these internals. > =20 >> No isolinux patching (could this one be disabled by default?) >> =20 > > You mean mkisofs -boot-info-table ? > (Code in libisofs/eltorito.c : > int patch_boot_image(uint8_t *buf, Ecma119Image *t, size_t imgsize) > ) > > Just yesterday i moved that setting from option > -b to option -boot-info-table, which was a noop. > So if you omit -boot-info-table then patching > should be disabled. > > =20 Thanks. >> load_sectors should be set to the size of whole >> image instead of just 4 sectors=20 >> =20 > > You mean mkisofs -boot-load-size ? > This is implemented in -as mkisofs emulation. > For a test you may set it manually. > Unit is 512 bytes. Default is 4. > > =20 Why not to determine it from file size by default? > =20 >> Can we have a --efi-boot option which will do this? >> =20 > > This shall then determine the -boot-load-size > from the size of the file ? > =20 Yes > Should be possible. > > But it seems more natural to state > > -b --efi-boot > > in comparison to traditional > > -b -boot-info-table > > =20 The problem is that I would like to have efi+bios cd with 2 eltorito entries: one with platformid=3D0 and another one with platformid=3D0xef. = It seems to me that it's unachievable with this syntax. > Whatever, except the small hardcoded change in > libisofs/eltorito.c > the currently uploaded xorriso-0.5.3 with time > stamp 2010.04.17.171232 should already be able > to produce such an ISO image. > If a missing option -boot-info-table causes > problems, then i will solve them soon. > > Please make a test. I can only check by od, > but have no idea how to prepare something that > would really boot. > > =20 Ok, I'll test it later today. > ------------------------------------------------ > > =20 >> On another note: can it be ensured that boot images and files boot/gru= b >> directory? I've come across a bug which seems to be triggered by image= s >> being after 2GiB mark on DVD. >> =20 > > There seem words missing around "directory". > > Do i get it right that you want the LBA of the > boot catalog and the boot image to be as low > as possible ? > > =20 Yes and also the offset to files from boot/grub and metadata to reach it too. > I will have to explore how i can achieve that. > > ------------------------------------------------ > > > Today i released libisofs-0.6.30. It will be the > fundament of libisoburn-0.5.4, which i plan to > release in the next few days, together with GNU > xorriso-0.5.4. > Then we can urge distribution maintainers to > update their packages. > > > The API change for adjustable Platform ID would > become part of libisofs-0.6.32 and xorriso-0.5.6. > > =20 Ok > ------------------------------------------------ > > > Have a nice day :) > > Thomas > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------010909050503010608010108 Content-Type: text/x-diff; name="xorriso_efi_dirty.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="xorriso_efi_dirty.diff" diff -ur xorriso-0.5.3/libisofs/eltorito.c xorriso-0.5.3-mod//libisofs/el= torito.c --- xorriso-0.5.3/libisofs/eltorito.c 2010-04-13 18:16:58.000000000 +0200= +++ xorriso-0.5.3-mod//libisofs/eltorito.c 2010-04-17 16:00:42.452627715 = +0200 @@ -552,7 +555,7 @@ struct el_torito_validation_entry *ve =3D (struct el_torito_validation_entry*)buf; ve->header_id[0] =3D 1; - ve->platform_id[0] =3D 0; /* 0: 80x86, 1: PowerPC, 2: Mac */ + ve->platform_id[0] =3D 0xef; /* 0: 80x86, 1: PowerPC, 2: Mac */ ve->key_byte1[0] =3D 0x55; ve->key_byte2[0] =3D 0xAA; =20 @@ -787,6 +790,8 @@ uint32_t checksum; size_t offset; =20 + return ISO_SUCCESS; + if (imgsize < 64) { return iso_msg_submit(t->image->id, ISO_ISOLINUX_CANT_PATCH, 0, "Isolinux image too small. We won't patch it."); --- xorriso-0.5.3/xorriso/xorriso.c 2010-04-13 18:16:58.000000000 +0200 +++ xorriso-0.5.3-mod//xorriso/xorriso.c 2010-04-17 15:25:22.649625656 +0= 200 @@ -4882,7 +4882,7 @@ m->boot_image_bin_form[0]=3D 0; m->boot_image_emul=3D 0; m->boot_image_cat_path[0]=3D 0; - m->boot_image_load_size=3D 4 * 512; /* hearsay out of libisofs/demo= /iso.c */ + m->boot_image_load_size=3D 2880 * 2 * 512; /* hearsay out of libiso= fs/demo/iso.c */ =20 #ifdef Xorriso_with_isohybriD m->boot_image_isohybrid=3D 1; --------------010909050503010608010108-- --------------enigF2DDB8B800684482FD1F120A 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 iF4EAREKAAYFAkvJ+E0ACgkQNak7dOguQgl+4QD/VaB0CIwrD2RXuDy85Bk97OfW hM/3HfE1EPULsTT3/hgA/id0zJOtKlYZ8za6UVMyzhPuL2cBfztdTYH6Yf8JZ/CV =REng -----END PGP SIGNATURE----- --------------enigF2DDB8B800684482FD1F120A--