Re: using isohybrid for usb bootable isos

2010-09-20 Thread Mateusz Poszwa
On Fri, 17 Sep 2010 21:58:40 +0200
Thomas Schmitt scdbac...@gmx.net wrote:

 I did read 
   http://atterer.org/jigdo/debian-jigdo-mini-howto#HOWJIGDOWORKS
 and believe to understand the principles.
 I assume that xorriso shall act like jigdo-file and produce
 at least the .template file. Is there a byte-by-byte specification
 of its format ?

Here you are:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/jigdo/jigdo/doc/TechDetails.txt?view=markup

-- 
Mateusz Poszwa


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100920130831.15af8...@debelianear



Re: using isohybrid for usb bootable isos

2010-09-17 Thread George Danchev
Joey Hess writes:

Hi,

 Steve McIntyre wrote:
  That itself is a minor pain, but not enough to make me complain about
  a useful feature. The *more* difficult thing is trying to make
  iso-hybrid work with jigdo: we make the .iso and .jigdo files directly
  in the same invocation of genisoimage, so anything we do to
  post-process the .iso files won't show up in the .jigdo
  equivalents. :-(
  
  I've been trying to find time for ages to either: (a) add iso-hybrid
  support directly into genisoimage, or (b) port the jigdo code from
  genisoimage to xorriso, which is the long-term plan. xorriso already
  includes the needed iso-hybrid support, but it'll take quite a lot of
  work to add jigdo code there.
 
 I take it it's not an easy option to have jidgo just run isohybrid?
 
 One problem with your long-term plan is that it would not allow adding
 on the firmware partition prior to generating the jidgo, as xorriso
 won't be doing that.

This fair concern of adding more optional partitions to the ISO at the right 
time deserves to be addressed better, indeed. Performing such task in the very 
first place (the image generator), would be faster and more self-contained than 
eventual post-processing, which is not meant to be ditched of course. 
Therefore I exchanged several mails with Thomas (xorriso upstream, also CC'ed) 
about adding such functionality to xorriso and here is how it currently looks 
like:

* the image file (this could be the requested second firmware partition) as 
given via option, would be written right after the space of the iso image.

* also a second partition entry would be written (optionally 3rd, and 4th 
resp.) right after the first one in the DOS partition table (which is part of 
the MBR), right after byte 462; these are the next 3*16 bytes, followed by 
0X55, 0xAA.

The following input is needed:

1) Hard disk file path of the additional images (second one, resp. third and 
fourth, if there are any, at all) I suggest:

--partition2=/path/to/img2 [--partition3, --partition4]

Please don't hesitate to suggest better options. This is not implemented, yet.

2) Partition type - byte 4 in partition entry.

a list could be obtained via: sfdisk -T | grep -i fat 

xorriso could have these predefined, but a sane/good default value like 0x0C 
(but I don't have a strong opinion on that default) would also be required, in 
case a --partition option is given only. Please don't hesitate to suggest a 
good default one, and give few pointers why. This is not implemented, yet.

3) Sectors per head (same like fdisk) - already available in xorriso.

4) Heads per cylinder (same like fdisk) - already available in xorriso.


To recap: 

a) Adding more partitions to the image (on the fly or by post-processing it), 
should not affect existing jigdo operations on so produced image. If you have 
any concerns it would break it, please explain why ;-)

b) Do you think that this plan for features of an image generator, would be 
helpful to debian-cd and d-i, when completed.

c) Feature, requests, suggestions (nitpicking included;-) are very welcome.

-- 
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu


signature.asc
Description: This is a digitally signed message part.


Re: using isohybrid for usb bootable isos

2010-09-17 Thread Joey Hess
George Danchev wrote:
 Therefore I exchanged several mails with Thomas (xorriso upstream, also 
 CC'ed) 
 about adding such functionality to xorriso and here is how it currently looks 
 like:

All looks very sane.

 * the image file (this could be the requested second firmware partition) as 
 given via option, would be written right after the space of the iso image.

Particularly nice as it saves an average of .5 mb.

 b) Do you think that this plan for features of an image generator, would be 
 helpful to debian-cd and d-i, when completed.

Assuming debian-cd does switch to xorriso, so after it supports jidgo;
yes, I think this would be helpful. And we could use it in d-i's own iso
generation earlier.

I would caution that my idea of adding a partition for firmware is
potentially half-baked. Especially since it's only easily accessible
when using a USB stick, not when using a CD. The same problem could be
solved more generally by eg, using multisession to append the firmware
to the iso. But that would require the user run a script; the firmware
parition does allow even a user limited to Windows and no extra programs
to add firmware to their USB stick.

-- 
see shy jo


signature.asc
Description: Digital signature


Re: using isohybrid for usb bootable isos

2010-09-17 Thread Thomas Schmitt
Hi,

i'm the developer of xorriso. (Cc me, please)

Joey Hess wrote:
 Assuming debian-cd does
 switch to xorriso, so after it supports jidgo

We should begin to write down an exact specification of the jigdo
files which xorriso shall produce during the run by which it
generates an ISO image. (Shall it generate a ready-to-mount image
at all ?)

I did read 
  http://atterer.org/jigdo/debian-jigdo-mini-howto#HOWJIGDOWORKS
and believe to understand the principles.
I assume that xorriso shall act like jigdo-file and produce
at least the .template file. Is there a byte-by-byte specification
of its format ?

What about the .jigdo file ? Is it prepared by a different tool ?
Shall xorriso produce parts of it ?
Or shall xorriso read it in order to learn which files are known ?


 I would caution that my idea of adding a partition for firmware is
 potentially half-baked.

It matches well the idea behind the partition table entries of
isohybrid and grub-mkrescue.
Both have their partition table to reserve the space of the ISO
image and to give partition editors a hint about the unused space
on the device.

So to populate the image with more partitions seems straightforward.


 The same problem could be
 solved more generally by eg, using multisession to append the firmware
 to the iso. But that would require the user run a script;

xorriso makes it quite easy to add sessions.
But it is not widely in use.

The size overhead of adding a session depends much on the number of
files in the resulting ISO image. Each session gets a new copy of
the whole directory tree. (E.g. 45000 files = 15 MB in my backup.)


 the firmware
 parition does allow even a user limited to Windows and no extra programs
 to add firmware to their USB stick

Yeah. People expect their USB sticks to have mountable partitions.
A flat stick with ISO image is sometimes frowned at.

Currently isohybrid and grub-mkrescue bear still quite unusual
partition layouts:
- isohybrid partition starts at block 0. I.e. there is no unclaimed
  space before the first partition.
- grub-mkrescue partition starts at block 1. This one is not mountable.

Your idea goes well with my current development work:
A partition with non-zero start block address but nevertheless
mountable. (Needs two superblocks and two directory trees.)

Put together i now imagine this partition layout:

 0 kB - 32 kB  Unclaimed space before partition. Playground for
   boot loaders.
32 kB -  X kB  First partition covering the rest of the ISO image
   up to the start of the appended FAT image
 X kB -  Z kB  Second partition covering the FAT image

The ISO image would believe to reach from 0 kB to Z kB.
So the FAT partition would be safe from partition editors and from
ISO multi-session.

The USB stick would appear on GNU/Linux as
  /dev/sdb   ISO filesystem. (This one is seen on CD, or when
 booting via isohybrid MBR or via GRUB MBR.)
  /dev/sdb1  ISO filesystem with same content
  /dev/sdb2  FAT filesystem

This brings some size overhead in comparison to simpler layouts.
But it should be quite self-explaining to any system and user.


Have a nice day :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/94312122832...@192.168.2.69



Re: using isohybrid for usb bootable isos

2010-09-17 Thread George Danchev
Thomas Schmitt writes:
 Hi,
 
 i'm the developer of xorriso. (Cc me, please)
 
 Joey Hess wrote:
  Assuming debian-cd does
  switch to xorriso, so after it supports jidgo
 
 We should begin to write down an exact specification of the jigdo
 files which xorriso shall produce during the run by which it
 generates an ISO image. (Shall it generate a ready-to-mount image
 at all ?)
 
 I did read
   http://atterer.org/jigdo/debian-jigdo-mini-howto#HOWJIGDOWORKS
 and believe to understand the principles.
 I assume that xorriso shall act like jigdo-file and produce
 at least the .template file. Is there a byte-by-byte specification
 of its format ?

I haven't seen such specification, however, this machinery is already written 
and in place. If you pull from cdrkit from svn you can get Steve's code 
addition to genisoimage. These files are self-contained, ignoring certain 
error-reporting related macros et all:

* md5.c (we have that already in libburnia)
* jte.c and jte.h (main routines, we should learn to use)
* endian.c and rsync.c (supporting routines)
* boot-alpha.c, boot-hppa.c, boot-mips.c boot-mispel.c - we can ignore these 
for now, but they add stuff specific to booting on these architectures, instead 
of post-process them later.

(so, Steve's code should serve us as specification;-)
 
 What about the .jigdo file ? Is it prepared by a different tool ?
 Shall xorriso produce parts of it ?
 Or shall xorriso read it in order to learn which files are known ?

image generator should output both *.template and .jigdo files. 

The whole thing starts with initializing the *.template by 
jte.c:write_template_header(), 

Then at all places where data is to be written to the iso image, same data are 
passed to jte.c:jtwrite() to be put into *.template or store an entry which 
hashsum is to be added later to the *.jigdo file (I haven't completely 
deciphered these actions, yet;-). 

When *.template is finished, it calls jte.c:write_jigdo_file() to write the 
entries (actually their hashsums) not present in template, to the *.jigdo file.


Rf: relevant jigdo options are:
(explained at http://www.einval.com/~steve/software/JTE/)

genisoimage -J -r -o /home/steve/test1.iso \
-jigdo-jigdo /home/steve/test1.jigdo \
-jigdo-template /home/steve/test1.template \
-jigdo-min-file-size 16384 \
-jigdo-ignore README* \
-jigdo-force-md5 /pool/ \
-jigdo-map Debian=/mirror/debian \
-md5-list /home/steve/md5.list \
/mirror/jigdo-test

-- 
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009172357.57038.danc...@spnet.net



Re: using isohybrid for usb bootable isos

2010-09-16 Thread Felipe Augusto van de Wiel (faw)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-09-2010 01:41, Christian PERRIER wrote:
 Quoting Joey Hess (jo...@debian.org):
 I've done some investigation of using isohybrid on an iso image (d-i
 alpha1 i386 netinst) to allow it to be booted from USB stick. Basically,
 postprocess the image with isohybrid, and write it direct to the usb
 stick. On the single machine I tried it on, that booted ok without any
 tweaking of isohybrid options.
 
 
 Impressive work (as usual...).

Indeed.


 I would be OK to commit all this but we first need a confirmation that
 someone will be handling the work on the installation guide side:
 calling for translation updates, monitoring I-G builds and releasing
 the new installation guide.
 
 CC'ing Felipe who, I think, is the best-suited person for this.

I think right now is a good time to get updates in.  I'm not
sure when the B1 is supposed to be released but I doubt we
will be able to synchronize it.

Personally, I would try to get updates until late September,
we will set a similar timeline for Release Notes.  I still
have to recheck a few things regarding D-I Guide and its
build/upload process, but I will be happy to help handling
it (at least for now).


Kind regards,
- -- 
Felipe Augusto van de Wiel (faw)
Debian. Freedom to code. Code to freedom!
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyRtQkACgkQCjAO0JDlykZHQQCffYgf/3ib/emP1eupigd/Gbht
HewAn3LYcqOD4vIwSe1jmJqrQdgtP++u
=pGwa
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c91b50a.4020...@debian.org



Re: using isohybrid for usb bootable isos

2010-09-14 Thread Christian PERRIER
Quoting Joey Hess (jo...@debian.org):
 I've done some investigation of using isohybrid on an iso image (d-i
 alpha1 i386 netinst) to allow it to be booted from USB stick. Basically,
 postprocess the image with isohybrid, and write it direct to the usb
 stick. On the single machine I tried it on, that booted ok without any
 tweaking of isohybrid options.


Impressive work (as usual...).

I would be OK to commit all this but we first need a confirmation that
someone will be handling the work on the installation guide side:
calling for translation updates, monitoring I-G builds and releasing
the new installation guide.

CC'ing Felipe who, I think, is the best-suited person for this.




signature.asc
Description: Digital signature


Re: using isohybrid for usb bootable isos

2010-09-14 Thread Steve McIntyre
On Mon, Sep 13, 2010 at 10:44:35PM -0400, Joey Hess wrote:
Joey Hess wrote:
 So ideally, debian-cd would add a small second partition to the iso file's
 partition table, and tack on a FAT filesystem. This could probably be done
 by running fdisk on the iso file after isohybrid.

I've attached a patch with a script, which I am checking into d-i for now,
that does that. 

This would add 6 to 7 mb to iso images it's used on, I don't know how Steve
feels about that. :)

Hey Joey,

That itself is a minor pain, but not enough to make me complain about
a useful feature. The *more* difficult thing is trying to make
iso-hybrid work with jigdo: we make the .iso and .jigdo files directly
in the same invocation of genisoimage, so anything we do to
post-process the .iso files won't show up in the .jigdo
equivalents. :-(

I've been trying to find time for ages to either: (a) add iso-hybrid
support directly into genisoimage, or (b) port the jigdo code from
genisoimage to xorriso, which is the long-term plan. xorriso already
includes the needed iso-hybrid support, but it'll take quite a lot of
work to add jigdo code there.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
When C++ is your hammer, everything looks like a thumb. -- Steven M. Haflich


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100914112456.ga18...@einval.com



Re: using isohybrid for usb bootable isos

2010-09-14 Thread Otavio Salvador
Hello,

On Tue, Sep 14, 2010 at 8:24 AM, Steve McIntyre st...@einval.com wrote:
 On Mon, Sep 13, 2010 at 10:44:35PM -0400, Joey Hess wrote:
Joey Hess wrote:
This would add 6 to 7 mb to iso images it's used on, I don't know how Steve
feels about that. :)

 That itself is a minor pain, but not enough to make me complain about
 a useful feature. The *more* difficult thing is trying to make
 iso-hybrid work with jigdo: we make the .iso and .jigdo files directly
 in the same invocation of genisoimage, so anything we do to
 post-process the .iso files won't show up in the .jigdo
 equivalents. :-(

The iso-hybrid is indeed a quite nice way to avoid a lot of hassle for
users regarting the usb image usage; having you comments in mind I
believe we could add it for netboot.iso images in d-i for now and try
to make it default for Wheeze since it looks like debian-cd tools does
demand a lot of work to it fit well on this.

What people think?

-- 
Otavio Salvador                  O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br


--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktimvh07jzymlcappu5d5+kogf2xo6ccwxpeys...@mail.gmail.com



Re: using isohybrid for usb bootable isos

2010-09-14 Thread Joey Hess
Steve McIntyre wrote:
 That itself is a minor pain, but not enough to make me complain about
 a useful feature. The *more* difficult thing is trying to make
 iso-hybrid work with jigdo: we make the .iso and .jigdo files directly
 in the same invocation of genisoimage, so anything we do to
 post-process the .iso files won't show up in the .jigdo
 equivalents. :-(
 
 I've been trying to find time for ages to either: (a) add iso-hybrid
 support directly into genisoimage, or (b) port the jigdo code from
 genisoimage to xorriso, which is the long-term plan. xorriso already
 includes the needed iso-hybrid support, but it'll take quite a lot of
 work to add jigdo code there.

I take it it's not an easy option to have jidgo just run isohybrid?

One problem with your long-term plan is that it would not allow adding
on the firmware partition prior to generating the jidgo, as xorriso
won't be doing that.

(I do wonder if it's worth spending scarce time on jidgo.)

-- 
see shy jo


signature.asc
Description: Digital signature


Re: using isohybrid for usb bootable isos

2010-09-14 Thread George Danchev
Joey Hess writes:
 Steve McIntyre wrote:
  That itself is a minor pain, but not enough to make me complain about
  a useful feature. The *more* difficult thing is trying to make
  iso-hybrid work with jigdo: we make the .iso and .jigdo files directly
  in the same invocation of genisoimage, so anything we do to
  post-process the .iso files won't show up in the .jigdo
  equivalents. :-(
  
  I've been trying to find time for ages to either: (a) add iso-hybrid
  support directly into genisoimage, or (b) port the jigdo code from
  genisoimage to xorriso, which is the long-term plan. xorriso already
  includes the needed iso-hybrid support, but it'll take quite a lot of
  work to add jigdo code there.
 
 I take it it's not an easy option to have jidgo just run isohybrid?

Actually, jigdo-file(1) is not involved with the creation of *.jigdo and 
*.template files, as it is replaced by Steve's JTE code (run inside 
genisoimage) which eventually could be changed isohybrid-wise. I don't know 
how doable and sane would be that, to be honest.

I agree that generating both representations (ISO and jigdo/templete) by 
reading the source data just once, does cut the read-IO about twice.

 One problem with your long-term plan is that it would not allow adding
 on the firmware partition prior to generating the jidgo, as xorriso
 won't be doing that.
 
 (I do wonder if it's worth spending scarce time on jidgo.)

Well, the jigdo representation efficiently upgrades (slightly) outdated iso-
images, you have downloaded a week or month ago. Nothing beats that with 
regard to the impact on saving time and bandwidth at the user's side, 
especially image testers and early adopters. Thus, I'd rather see it as more 
efficient approach to have that whole post-processing work just done once on a 
central site, many to reuse efficiently. This is currently even doable via 
xorriso (iso-hybrid support included) generating these images, which can then 
be given to jigdo-file to complete their jigdo representation.

Steve, this does not mean we have given up on porting JTE to xorriso. We are 
currently discussing that with Thomas as time permits, but identifying a 
proper design and eventually implement it takes its time.

-- 
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu


-- 
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009142133.29064.danc...@spnet.net



using isohybrid for usb bootable isos

2010-09-13 Thread Joey Hess
I've done some investigation of using isohybrid on an iso image (d-i
alpha1 i386 netinst) to allow it to be booted from USB stick. Basically,
postprocess the image with isohybrid, and write it direct to the usb
stick. On the single machine I tried it on, that booted ok without any
tweaking of isohybrid options.

So I think this would be a useful thing for debian-cd to do.
I assume it would probably conflict with eg, the boot sector magic
used for multiarch isos. If it were only done for i386/amd64 isos,
that would be enough to allow bypassing the complicated process to use
the d-i hd-media images on usb sticks. Does that make sense from a
debian-cd point of view?

From the d-i side, cdrom-detect needs to be able to mount the iso when
booted from usb stick. There is a cdrom-detect/try-usb that already
enables that, but it's not on by default. So far, only live-installer
has needed it. It should be very safe to move into the default codepath.

The second problem is that apt will try, and fail, to mount the CD
itself. apt-setup removed the apt.conf.d/00NoMountCDROM file. Basically,
it would need to somehow detect that the CD is on a USB stick, and avoid
doing that. It currently looks for /hd-media/ existing, which I made as
a workaround. Just checking that the cdrom is mounted from /dev/sd?1 might
do, or cdrom-detect could set a flag when it found it on a usb device
partition.

After working around those 2 problems, d-i successfully installed!
But, another issue is that the user needs to be able to drop firmware onto
the stick so that d-i can find it. Since isohybrid creates a partition
table, after writing the iso to the stick, the user can replug it and
see a first partition that is the iso image (so read-only). To add
firmware, they would have to add a second partition, which is harder
than the current process for usb sticks.

So ideally, debian-cd would add a small second partition to the iso file's
partition table, and tack on a FAT filesystem. This could probably be done
by running fdisk on the iso file after isohybrid.

d-i could also run isohybrid when generating the mini.iso and eliminate
the need for very complex manual setup of a netboot usb stick.
Firmware loading problems also apply there.

BTW, I don't think the hd-media images should be removed, they do allow
for use cases beyond simply installing from a USB stick.

- Forwarded message from Tanguy Ortolo tanguy+deb...@ortolo.eu -

Date: Thu, 9 Sep 2010 12:43:53 +0200
From: Tanguy Ortolo tanguy+deb...@ortolo.eu
To: debian-b...@lists.debian.org
Subject: Complicated installation from USB
Reply-To: debian-b...@lists.debian.org,
Tanguy Ortolo tanguy+deb...@ortolo.eu
User-Agent: Mutt/1.5.18 (2008-05-17)

Hello,

Debian has been installable from USB (or from any non-optical non-floppy
mass storage device, to be exact, but I shall use the term “USB stick” for
convenience) since some time.


Preparing installation optical disks or floppies is, or used to be easy,
and involves two operations, depending on the case:

wget cd.iso
wodim dev=/dev/cdrom cd.iso

wget floppy.img
dd if=floppy.img of=/dev/floppy


However, preparing an USB stick is not really easy:
wget hd-media.img
wget cd.iso
dd if=hd-media.img of=/dev/stick
mount /dev/stick /mnt
cp cd.iso /mnt
umount /mnt


The installation manual explains that in a non-straightforward way,
describing two methods, and giving only hints to find where to download
the two needed images. In addition, this procedure depends on *nix
tools, and is thus inapplicable for many user that start installing
Debian from a foreign system, which is a common case. Because of this
complication, I see many beginners failing at preparing USB images, if
not failing to install Debian at all because they do not have an optical
drive.

Could we consider providing ready-to-use hd-media images? Something that
would only need to be downloaded an written to a USB stick, as we do for
optical media? I see two ways to implement that:
* doing the copy of the CD image on the hd-media filesystem before
  making it available as an image;
* using the recent hybrid boot feature of SYSLINUX, that allow to build
  single images that are bootable either as El Torito optical media
  or as MBR on-optical media, if applicable to the Debian installer.

If there are specific reasons not to provide ready-to-use, but only
pieces of hd-media images, as we currently do, these reasons might be
worth being documented in the installation manual with a note such as:
“Note: this procedure is not as easy as the CD one, because [blah].”
That would avoid further messages such as this very one. :-)

Cheers, and thanks for the great piece of software that the Debian
installed is, by the way, to support so many architectures and media
types. :-)

-- 
 ,--.
: /` )   Tanguy Ortolo
| `-'Debian maintainer
 \_



- End forwarded message -
-- 
see shy jo


signature.asc
Description: Digital signature

Re: using isohybrid for usb bootable isos

2010-09-13 Thread Joey Hess
Joey Hess wrote:
 So ideally, debian-cd would add a small second partition to the iso file's
 partition table, and tack on a FAT filesystem. This could probably be done
 by running fdisk on the iso file after isohybrid.

I've attached a patch with a script, which I am checking into d-i for now,
that does that. 

This would add 6 to 7 mb to iso images it's used on, I don't know how Steve
feels about that. :)

-- 
see shy jo
#!/bin/sh
# Given an iso image, runs isohybrid on it to allow it to be booted from
# USB stick as well as CD. Then it adds a small second FAT partition, which
# the user can use to provide firmware files to the installer on the same
# USB stick.

# This needs to be big enough to hold the uncompressed firmware.tar.gz
# file. Currently that is 4.4M; add a few more to grow.
firmware_volume_size_M=6
# max size 11 chars:  --- 
firmware_volume_name=Firmware

iso=$1

if [ -z $iso ]; then
echo usage: $0 iso 2
exit 1
fi

set -e

isohybrid $iso

# Make the firmware volume.
tmpdir=$(mktemp -d)
firmware_volume_file=$tmpdir/fat
mkfs.msdos -n $firmware_volume_name -C $firmware_volume_file \
$(expr $firmware_volume_size_M \* 1024)

# Combine images. 
# XXX This wastes some space because isohybrid pads the iso to one
# megabyte. Could reuse that padding for the start of the firmware volume.
cat $firmware_volume_file  $iso
rm -r $tmpdir

# Now adjust the partition table of the hybrid iso.
# It has a first partition which is the iso; add a second partition for the
# firmware volume.
(

# Go into extended menu and set cylinders to 32. 
# This is the same number of cylinders (currently) used by isohybrid.
echo x
echo c
echo 32
echo r

# Make new partition #2
echo n
echo p
echo 2
echo 
echo +$firmware_volume_size_MM

# Pedantically, set partition type to 1: FAT 16
echo t
echo 2
echo 1

# Done!
echo w
) | fdisk $iso
From 9e4ab44eb5d43353769350872803cae71553eae5 Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Mon, 13 Sep 2010 22:07:36 -0400
Subject: [PATCH 1/2] create geniso_hybrid_plus_firware_partition script

This script makes a hybrid iso image with a second partition for firmware.
---
 installer/build/config/x86.cfg |2 +-
 .../util/geniso_hybrid_plus_firware_partition  |   62 
 2 files changed, 63 insertions(+), 1 deletions(-)
 create mode 100755 installer/build/util/geniso_hybrid_plus_firware_partition

diff --git a/installer/build/config/x86.cfg b/installer/build/config/x86.cfg
index 4a0a005..e9ef577 100644
--- a/installer/build/config/x86.cfg
+++ b/installer/build/config/x86.cfg
@@ -279,7 +279,7 @@ arch_miniiso: x86_syslinux
 		-no-emul-boot -boot-load-size 4 -boot-info-table \
 		-o $(TEMP_MINIISO) $(TEMP_CD_TREE)
 	
-	isohybrid $(TEMP_MINIISO)
+	geniso_hybrid_plus_firware_partition $(TEMP_MINIISO)
 
 # Netboot files
 .PHONY: arch_netboot_dir
diff --git a/installer/build/util/geniso_hybrid_plus_firware_partition b/installer/build/util/geniso_hybrid_plus_firware_partition
new file mode 100755
index 000..52cccf1
--- /dev/null
+++ b/installer/build/util/geniso_hybrid_plus_firware_partition
@@ -0,0 +1,62 @@
+#!/bin/sh
+# Given an iso image, runs isohybrid on it to allow it to be booted from
+# USB stick as well as CD. Then it adds a small second FAT partition, which
+# the user can use to provide firmware files to the installer on the same
+# USB stick.
+
+# This needs to be big enough to hold the uncompressed firmware.tar.gz
+# file. Currently that is 4.4M; add a few more to grow.
+firmware_volume_size_M=6
+# max size 11 chars:  --- 
+firmware_volume_name=Firmware
+
+iso=$1
+
+if [ -z $iso ]; then
+	echo usage: $0 iso 2
+	exit 1
+fi
+
+set -e
+
+isohybrid $iso
+
+# Make the firmware volume.
+tmpdir=$(mktemp -d)
+firmware_volume_file=$tmpdir/fat
+mkfs.msdos -n $firmware_volume_name -C $firmware_volume_file \
+	$(expr $firmware_volume_size_M \* 1024)
+
+# Combine images. 
+# XXX This wastes some space because isohybrid pads the iso to one
+# megabyte. Could reuse that padding for the start of the firmware volume.
+cat $firmware_volume_file  $iso
+rm -r $tmpdir
+
+# Now adjust the partition table of the hybrid iso.
+# It has a first partition which is the iso; add a second partition for the
+# firmware volume.
+(
+
+# Go into extended menu and set cylinders to 32. 
+# This is the same number of cylinders (currently) used by isohybrid.
+echo x
+echo c
+echo 32
+echo r
+
+# Make new partition #2
+echo n
+echo p
+echo 2
+echo 
+echo +$firmware_volume_size_MM
+
+# Pedantically, set partition type to 1: FAT 16
+echo t
+echo 2
+echo 1
+
+# Done!
+echo w
+) | fdisk $iso
-- 
1.7.1

From cff9c48f8e041e317186e91cce17d86181fd80a6 Mon Sep 17 00:00:00 2001
From: Joey Hess j...@kitenet.net
Date: Mon, 13 Sep 2010 22:32:40 -0400
Subject: [PATCH 2/2] add documentation for piggybacking formware onto hybrid mini.iso usb stick

---
 manual/en/install-methods/boot-usb-files.xml |   17 +++--