Re: using isohybrid for usb bootable isos
On Fri, 17 Sep 2010 21:58:40 +0200 "Thomas Schmitt" 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
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 -- 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
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
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
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 signature.asc Description: This is a digitally signed message part.
Re: using isohybrid for usb bootable isos
-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
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 -- 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
Re: using isohybrid for usb bootable isos
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
Hello, On Tue, Sep 14, 2010 at 8:24 AM, Steve McIntyre 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
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
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
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_M"M # 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 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_M"M + +# 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 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 ++
using isohybrid for usb bootable isos
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 - Date: Thu, 9 Sep 2010 12:43:53 +0200 From: Tanguy Ortolo To: debian-b...@lists.debian.org Subject: Complicated installation from USB Reply-To: debian-b...@lists.debian.org, Tanguy Ortolo 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
