[Debburn-devel] Filesystem image creators and GRUB support
George Danchev
danchev at spnet.net
Sat Mar 6 13:48:51 UTC 2010
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>
More information about the Debburn-devel
mailing list