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>
Attachment:
signature.asc
Description: This is a digitally signed message part.