grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to prepare an ISO 9660 CD for booting via GRUB ?


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Date: Sat, 17 Apr 2010 20:04:56 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

Thomas Schmitt wrote:
> Hi,
>
> Vladimir Serbinenko:
>   
>> efi booting [...] it's basically standard no-emul
>> eltorito except:
>> platform_id[0] = 0xef;
>>     
>
> 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] = 0; /* 0: 80x86, 1: PowerPC, 2: Mac */
>
>   
Yes. I attach the patch I used for dirty checks
> A bit more work will be to make this controllable
> by the libisofs API.
>
>   
This is exactly why I asked you: I'm not familiar with these internals.
>   
>> No isolinux patching (could this one be disabled by default?)
>>     
>
> 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.
>
>   
Thanks.
>> load_sectors should be set to the size of whole
>> image instead of just 4 sectors 
>>     
>
> 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.
>
>   
Why not to determine it from file size by default?
>   
>> Can we have a --efi-boot <image> option which will do this?
>>     
>
> This shall then determine the -boot-load-size
> from the size of the <image> file ?
>   
Yes
> Should be possible.
>
> But it seems more natural to state
>
>   -b <image> --efi-boot
>
> in comparison to traditional
>
>   -b <image> -boot-info-table
>
>   
The problem is that I would like to have efi+bios cd with 2 eltorito
entries: one with platformid=0 and another one with platformid=0xef. 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.
>
>   
Ok, I'll test it later today.
> ------------------------------------------------
>
>   
>> On another note: can it be ensured that boot images and files boot/grub
>> directory? I've come across a bug which seems to be triggered by images
>> being after 2GiB mark on DVD.
>>     
>
> 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 ?
>
>   
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.
>
>   
Ok
> ------------------------------------------------
>
>
> Have a nice day :)
>
> Thomas
>
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

diff -ur xorriso-0.5.3/libisofs/eltorito.c 
xorriso-0.5.3-mod//libisofs/eltorito.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 =
         (struct el_torito_validation_entry*)buf;
     ve->header_id[0] = 1;
-    ve->platform_id[0] = 0; /* 0: 80x86, 1: PowerPC, 2: Mac */
+    ve->platform_id[0] = 0xef; /* 0: 80x86, 1: PowerPC, 2: Mac */
     ve->key_byte1[0] = 0x55;
     ve->key_byte2[0] = 0xAA;
 
@@ -787,6 +790,8 @@
     uint32_t checksum;
     size_t offset;
 
+    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 
+0200
@@ -4882,7 +4882,7 @@
  m->boot_image_bin_form[0]= 0;
  m->boot_image_emul= 0;
  m->boot_image_cat_path[0]= 0;
- m->boot_image_load_size= 4 * 512;     /* hearsay out of libisofs/demo/iso.c */
+ m->boot_image_load_size= 2880 * 2 * 512;     /* hearsay out of 
libisofs/demo/iso.c */
 
 #ifdef Xorriso_with_isohybriD
  m->boot_image_isohybrid= 1;

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]