From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NxdG7-0004hK-Pk for mharc-grub-devel@gnu.org; Fri, 02 Apr 2010 05:33:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxdFS-0004PO-I4 for grub-devel@gnu.org; Fri, 02 Apr 2010 05:33:06 -0400 Received: from [140.186.70.92] (port=54285 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxdFM-0004K5-Am for grub-devel@gnu.org; Fri, 02 Apr 2010 05:33:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxdFK-00054G-C7 for grub-devel@gnu.org; Fri, 02 Apr 2010 05:33:00 -0400 Received: from mail.gmx.net ([213.165.64.20]:53300) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NxdFJ-000543-Sc for grub-devel@gnu.org; Fri, 02 Apr 2010 05:32:58 -0400 Received: (qmail invoked by alias); 02 Apr 2010 09:32:50 -0000 Received: from 165.126.46.212.adsl.ncore.de (HELO 192.168.2.69) [212.46.126.165] by mail.gmx.net (mp008) with SMTP; 02 Apr 2010 11:32:50 +0200 X-Authenticated: #2145628 X-Provags-ID: V01U2FsdGVkX1+knl8QCfakVrWLmFEPZMPfIl8BAJPHkLNxTM3InM mrSuM7Uy0/Pc6Q Date: Fri, 02 Apr 2010 11:32:02 +0200 From: "Thomas Schmitt" To: grub-devel@gnu.org References: <4BB5218F.2000000@gmail.com> In-Reply-To: <4BB5218F.2000000@gmail.com> Message-Id: <105805073418349@192.168.2.69> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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: Fri, 02 Apr 2010 09:33:07 -0000 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). 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. 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. 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. When i can perform grub-mkrescue gestures, then i plan to enable hard-disk emulation so that others (Vladimir ?) can test that. 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 and make a sketch how a HFS tree would be structured. 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. This is of course a long term open ended endeavor. >>> --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 ? 32 sectors = 1 head, 64 heads = 1 cylinder would limit C/H/S size to 1 GB, due to the 10 bit limit of cylinder count. The partition table format would allow 63 (or 64 ?) sectors, 255 (or 256 ?) heads = ~ 8 GB. (isohybrid happily truncates C/H/S size to 1 GB and expresses the real size in "LBA end".) 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 would then have to write all zeros except the one slot in the partition table ? ------------------------------------------------ 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 ? Isn't there any field where the number of sectors per head, and heads per cylinder is recorded ? 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. ------------------------------------------------ Have a nice day :) Thomas