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: Fri, 02 Apr 2010 13:51:14 +0200
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

Thomas Schmitt wrote:
> Hi,
>
> Drake Donahue wrote:
>   
>>>> mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
>>>> -boot-info-table -o grub.iso iso
>>>>         
>> run the script it generates the image, presuming on a linux system
>>     
>
> Regrettably i cannot spot stage2_eltorito on my
> SuSE 10.2 (which has such files but not eltorito)
> or on Debian 5.04 (where the GRUB installation
> has files like cdboot.img).
>
>   
stage2_eltorito is grub legacy. Please disregard this part
> The Debian system (where i am novice too) does
> have /usr/bin/grub-mkrescue which has the line
>   PACKAGE_VERSION=1.96
> It uses genisoimage and no --embedded-boot for
> a MBR-style image.
>
>   
1.96 is way too old. Please disregard.
> So my plan for development looks like this:
> - Use grub-mkrescue on Debian to produce a
>   bootable CD.
> - Examine it and check whether libisofs can
>   produce the same. Make necessary enhancements.
> - Substitute genisoimage in grub-mkrescue by
>   xorriso and produce bootable CD.
> - Upgrade Debian to GRUB 1.98 and try to produce
>   an image that boots from USB stick and from CD.
>
>   
From 1.96 to 1.98 grub-mkrescue was essentially rewritten. Supporting
1.96 (buggy, years old release) is basically a waste of time. Please use
either http://alpha.gnu.org/gnu/grub/grub-1.98.tar.gz or bzr checkout
from http://bzr.savannah.gnu.org/r/grub/trunk/grub/.
> This may last a few days. I have to dive into
> libisofs and check where we might be glued
> to ISOLINUX, inadvertedly.
> I will have to learn about GRUB installation
> and might need to cry for help.
>   
Feel free to ask. But please use current versions.
> When i can perform grub-mkrescue gestures, then
> i plan to enable hard-disk emulation so that
> others (Vladimir ?) can test that.
>
>   
It must be choseable whether to use emulation. By default no emulation
should be used (recent BIOSes have problems with emulation).
> Vladimir wrote about HFS:
>   
>> I have an imac g3 I could test it on. The only catch is that I have no
>> burner at home. But it should be manageable. I never looked deeply into
>> HFS but I think I can do it.
>>     
>
> If you have the time, then try to find specs for
> HFS 
http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-2.html
> and make a sketch how a HFS tree would
> be structured.
>   
Bad news are that it needs B* trees and isn't compatible with embedded
boot trick.
B* trees should be relatively easy to generate since we have to do it
only once and not maintain their structure over time.
> I would then prepare hooks in libisofs where
> a HFS tree can be generated and inserted into
> the emerging ISO image.
>
> Then we could put our knowledge together for
> the HFS tree generator.
> libisofs holds a tree model of nodes, from which
> the image trees get derived. Ideally, i would
> have made any needed preparations in the tree
> model, and you would know how to express it in
> HFS.
>   
Just being sorted is mostly enough. Trouble is that HFS uses its own way
of sorting.
>
>   
>>>>   --protective-msdos-label
>>>>         
>> 3) Put 0x80 (for bootable partition), 0, 2, 0 (C/H/S of the start), 0xcd
>> (partition type), [3 bytes of C/H/S end], 0x01, 0x00, 0x00, 0x00 (LBA
>> start in little endian), [LBA end in little endian] at 446-462
>>     
>
> What number of sectors/head and heads/cylinder
> to use ?
>
>   
63/255 as its what is reported on most harddisks. Most modern tools will
ignore this field altogether so putting just anything sane is enough
> me:
>   
>>> --protective-msdos-label without --embedded-boot ?)
>>>       
> Vladimir:
>   
>> Yes, for example to allow people dd images to USB sticks without a fear
>> of another OS willing to format the stick.
>>     
>
> So OSes would pop up dangerous dialogs if they
> see a USB stick without partition table ?
>
>   
I think they would, especially if they find no FS they expect to (fat).
> I would then have to write all zeros except the
> one slot in the partition table ?
>
>   
Basically you need a fake partition to avoid disk appear as unformatted
> ------------------------------------------------
>
> Curiosity to fill my lack of MBR knowledge:
>
>
> How does "0x01, 0x00, 0x00, 0x00 (LBA start" match
> with "0, 2, 0 (C/H/S of the start)" ?
> I see in isohybrid a similar addition of 1 to
> start sector. So it is obviously correct.
> But why ?
>
>   
Because sector value is 1-based.
> Isn't there any field where the number of sectors
> per head, and heads per cylinder is recorded ?
>   
No. In times when it was a hard property of disk it was deemed
unnecessary. When big disks appeared C/H/S was largely abandoned.
> Is there a convention to express this in
> "C/H/S end" ? isohybrid seems to do so:
>  heads-1 , sectors | high(cyls-1) , low(cyls-1)
> This gives in the sum the number of cyls.
> One could express that easier.
> Purpose could be to squeeze in the 1024th cylinder
> or to express heads/cyl and sectors/head.
>   
  /* The head of the start.  */
  grub_uint8_t start_head;

  /* (S | ((C >> 2) & 0xC0)) where S is the sector of the start and C
     is the cylinder of the start. Note that S is counted from one.  */
  grub_uint8_t start_sector;

  /* (C & 0xFF) where C is the cylinder of the start.  */
  grub_uint8_t start_cylinder;

It's pretty much historical.

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


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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