[Debburn-devel] Filesystem image creators and GRUB support

[George Danchev]

Thomas Schmitt writes:
> Hi,
> 
> George Danchev wrote:
> > 'embedded copy' bugs: 570156
> >
> > > > 16:21 < dkg0> what's the reason for not using genisoimage itself?
> > > > 16:22 < phcoder> dkg0: it doesn't allow choosing a stable UUID
> 
> From what is the UUID composed ?
> I assume it is derived from some image
> attributes like volume id.

at least uuidgen (from util-linux package) uses Ted T'so uuid library (same 
package shlibs/uuid/src/gen_uuid.c) to generate time-based and random-based 
(provided a decent PRNG exits) unique identifiers. There is also ossp-uuid 
implementation with a nice overview doc in it as well as 
http://en.wikipedia.org/wiki/Uuid

> > [bug] 570187
> > To start dealing with that properly, getting hfsutils
> > to export libhfs library would be the way to go, as also discussed on
> > irc. [...]
> > * libhfs is exported at some point, so it could be re-used with libisofs
> > and/or others interested parties.
> 
> I understand that mkisofs lets HFS and ISO 9660
> coexist in the same session on media. That would
> mean there are two "superblocks" and two trees
> with file names and file attributes.
> A similar relation as with ISO 9660 and Joliet.
> 
> A libhfs that is usable by libisofs would have
> to provide
> - The "superblock" plus specs where to place it
>   in the image data stream.
>   "superblock" means a block interval that is
>   embedded in the image stream and allows to find
>   the root of a file tree. Typically it has to be
>   stored at or near a particular address.
> - A single contiguous interval of blocks that
>   represents the HFS directory tree and all
>   attributes except data file contents.
> It could get as input a description of the tree
> of all file objects which shall show up in HFS.
> 
> There would be two passes. The first one
> determines the sizes of both block intervals.
> The second one produces them as data bytes.
> The size prediction has to be made without
> knowing any final block addresses.
> libisofs prescribes the exact start block
> addresses of both intervals at the second pass.
> 
> 
> Data file content is stored in block intervals
> named "extents". These extents may be referred
> freely by the various trees of an image.

That sounds rather complicated to be honest, however since people already 
requested libhfs to be exported: [1], we can file further wishlist bugs against 
that hfsutils to complement our use-case. I'm not currently sure whether 
hfsutils is suitable for what you described above.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437226

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