CVS commit: src/usr.sbin/makefs
Christos Zoulas
Committed By: christos
Date: Sun May 22 21:51:40 UTC 2011
Modified Files:
src/usr.sbin/makefs: cd9660.c cd9660.h makefs.8
src/usr.sbin/makefs/cd9660: cd9660_eltorito.c
Log Message:
From Nathan Whitehorn (nwhitehorn at freebsd dot org):
Add code to generate bootable ISOs on Powermac and CHRP systems.
Synthesize some partition maps (APM and MBR, respectively) pointing
to (a) the whole disk, and (b) relevant El Torito boot images that
have been added by other code. These partition maps are a little
bit funny looking, but they seem to work. FreeBSD has been using
this successfully in their release generation on powerpc, as well
as generating all non-SPARC install media. SPARC support could
probably be added as an extension of this patch.
To generate a diff of this commit:
cvs rdiff -u -r1.28 -r1.29 src/usr.sbin/makefs/cd9660.c
cvs rdiff -u -r1.15 -r1.16 src/usr.sbin/makefs/cd9660.h
cvs rdiff -u -r1.32 -r1.33 src/usr.sbin/makefs/makefs.8
cvs rdiff -u -r1.14 -r1.15 src/usr.sbin/makefs/cd9660/cd9660_eltorito.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
David Young
> Module Name: src
> Committed By: christos
> Date: Sun May 22 21:51:40 UTC 2011
>
> Modified Files:
> src/usr.sbin/makefs: cd9660.c cd9660.h makefs.8
> src/usr.sbin/makefs/cd9660: cd9660_eltorito.c
>
> Log Message:
> From Nathan Whitehorn (nwhitehorn at freebsd dot org):
> Add code to generate bootable ISOs on Powermac and CHRP systems.
> Synthesize some partition maps (APM and MBR, respectively) pointing
> to (a) the whole disk, and (b) relevant El Torito boot images that
> have been added by other code. These partition maps are a little
> bit funny looking, but they seem to work. FreeBSD has been using
> this successfully in their release generation on powerpc, as well
> as generating all non-SPARC install media. SPARC support could
> probably be added as an extension of this patch.
This sounds like the job of fdisk or pdisk, not makefs.
Have you tested this on a Power Macintosh or CHRP system?
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Christos Zoulas
David Young <dyo...@pobox.com> wrote:
>On Sun, May 22, 2011 at 05:51:40PM -0400, Christos Zoulas wrote:
>> Committed By: christos
>> Date: Sun May 22 21:51:40 UTC 2011
>>
>> Modified Files:
>> src/usr.sbin/makefs: cd9660.c cd9660.h makefs.8
>> src/usr.sbin/makefs/cd9660: cd9660_eltorito.c
>>
>> Log Message:
>> From Nathan Whitehorn (nwhitehorn at freebsd dot org):
>> Add code to generate bootable ISOs on Powermac and CHRP systems.
>> Synthesize some partition maps (APM and MBR, respectively) pointing
>> to (a) the whole disk, and (b) relevant El Torito boot images that
>> have been added by other code. These partition maps are a little
>> bit funny looking, but they seem to work. FreeBSD has been using
>> this successfully in their release generation on powerpc, as well
>> as generating all non-SPARC install media. SPARC support could
>> probably be added as an extension of this patch.
>
There was similar code there already.
>Have you tested this on a Power Macintosh or CHRP system?
No I don't have any machines to test, but I think that there is
a large benefit of having the code synchronized between the two projeccts.
christos
David Young
> In article <20110523141...@ojctech.com>,
> David Young <dyo...@pobox.com> wrote:
> >This sounds like the job of fdisk or pdisk, not makefs.
>
> There was similar code there already.
Can you give an example?
Dave
--
David Young OJC Technologies
dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
--
Martin Husemann
Or are there more hfs/hybrid things missing?
I tend to like the sunlabel(8) approach better (a manipulation that neither
fits fdisk nor makefs) - but I don't understand the macppc side to know if
this is realy similar.
Martin
Izumi Tsutsui
> Or are there more hfs/hybrid things missing?
FreeBSD seems to have HFS image file:
http://www.freebsd.org/cgi/cvsweb.cgi/src/release/powerpc/hfs-boot.bz2.uu
so I'm afraid we still needs some tool to create HFS which has
at least one file for complete builds.
(for OF2 machines I think we also need some installboot support btw)
> I tend to like the sunlabel(8) approach better (a manipulation that neither
> fits fdisk nor makefs) - but I don't understand the macppc side to know if
> this is realy similar.
On creating HDD images, size of the image is first,
partitioning is next, and creating file system at last.
So we can use fdisk/pdisk first.
On creating CD/DVD images, a boot file (or image) is first,
creating ISO9660 is next (it includes absolute block numbers?),
then filling MD partition map as a part of boot file of the whole image.
It looks mandatory to make makefs(8) handle partition maps for CD images.
---
Izumi Tsutsui
Martin Husemann
> It looks mandatory to make makefs(8) handle partition maps for CD images.
I'm not sure I understand exactly what you mean and why makefs is the right
tool here. Postprocessing the image is fine (I'm sure you know how sgimips
works with the volume header, the sparc64 case is even simpler by just
postprocessing the image filling in the sun label.)
What is the content of the pre-generated HFS piece? Is it relatively static?
Izumi Tsutsui
> > It looks mandatory to make makefs(8) handle partition maps for CD images.
>
> I'm not sure I understand exactly what you mean and why makefs is the right
> tool here. Postprocessing the image is fine
I think the problem is that the final ISO9660 output including
embeded MD boot fs and partition maps still has to be iso9660 compliant.
There is no public space to store MD parameters for postprocessing
in output image, and I don't think we can simply use existing
fdisk/pdisk tools to fill embeded MD (MBR or APM etc) partitions
and iso9660 parameters. (but I could be wrong)
> (I'm sure you know how sgimips
> works with the volume header, the sparc64 case is even simpler by just
> postprocessing the image filling in the sun label.)
On sgimips case, sgimipscd.iso has SGI specific format
and it can't be mounted by non-SGI machines, IIRC.
(while we can mount hybrid mac68kcd.iso and macppccd.iso on i386)
No idea about sparc64, but maybe it works because
it appends MD bootfs at the end of iso9660 fs and
Sun's label which has offsets of the bootfs is small enough
to put it into unused part at the top of iso9660.
> What is the content of the pre-generated HFS piece? Is it relatively static?
I have not checked FreeBSD's one, but it may have at least ofwboot.elf
and one kernel, which should be updated during build.
---
Izumi Tsutsui
Martin Husemann
> On sgimips case, sgimipscd.iso has SGI specific format
> and it can't be mounted by non-SGI machines, IIRC.
> (while we can mount hybrid mac68kcd.iso and macppccd.iso on i386)
Indeed, and in this case I think support by an additional tool
like sgivol is fine.
> No idea about sparc64, but maybe it works because
> it appends MD bootfs at the end of iso9660 fs and
> Sun's label which has offsets of the bootfs is small enough
> to put it into unused part at the top of iso9660.
Exactly - it adds an ffs partition (with padding) behind the iso9660
part and uses a spare sector early in the image (ignored by iso9660)
to store the sun label. Here too it is fine to use a postprocessing tool
IMHO.
> > What is the content of the pre-generated HFS piece? Is it relatively static?
>
> I have not checked FreeBSD's one, but it may have at least ofwboot.elf
> and one kernel, which should be updated during build.
Ok, so this differs from both sparc64 and sgimips significantly. Now, what is
the purpose of the change starting this thread if it only does the minor step
but leaves out the complex one that realy fits well into makefs?
Martin
Izumi Tsutsui
> the purpose of the change starting this thread if it only does the minor step
> but leaves out the complex one that realy fits well into makefs?
Hmm.
Now I've checked macppccd.iso and FreeBSD's hfs-boot, and
it seems they have a small HFS behind of iso9660.
http://www.freebsd.org/cgi/cvsweb.cgi/src/release/powerpc/generate-hfs.sh?rev=1.1
(though I'm not sure if MacOS (for mac68k bootstrap) can mount FreeBSD's one)
Probably your question is now "why we have put emul-boot and ElTorito
boot support into makefs(8)?"
The answer might be that they were heavily tied to ISO9660 spec?
Other MD (Apple, CHRP, Acorn etc) formats as well?
(and Sun's format is simple enough to handle with shell script?)
---
Izumi Tsutsui
David Laight
> > > It looks mandatory to make makefs(8) handle partition maps for CD images.
> >
> > I'm not sure I understand exactly what you mean and why makefs is the right
> > tool here. Postprocessing the image is fine
>
> I think the problem is that the final ISO9660 output including
> embeded MD boot fs and partition maps still has to be iso9660 compliant.
> There is no public space to store MD parameters for postprocessing
Could the extra parameters be put into a file within the image?
Then the postprocessing phase would have the required data.
Or even in a separate file !
David
--
David Laight: da...@l8s.co.uk
Izumi Tsutsui
> > embeded MD boot fs and partition maps still has to be iso9660 compliant.
> > There is no public space to store MD parameters for postprocessing
> > in output image, ...
>
> Could the extra parameters be put into a file within the image?
> Then the postprocessing phase would have the required data.
>
> Or even in a separate file !
It might be possible, but I doubt fdisk(8) or pdisk(8)
can handle iso images as is.
(Especailly Apple partition map has variable sizes)
If we have to add some tweaks to fdisk/pdisk to handle ISO9660 quirks,
I'm not sure if it's realy worth to remove MBR/APM stuff from makefs(8),
which really knows about ISO9660 internal structures.
IMO current makefs(8) implementation is acceptable compromise.
---
Izumi Tsutsui
Izumi Tsutsui
Committed By: tsutsui
Date: Sun May 29 17:07:58 UTC 2011
Modified Files:
src/usr.sbin/makefs: cd9660.c
src/usr.sbin/makefs/cd9660: iso9660_rrip.c
Log Message:
Apply fixes for PR bin/44114 (makefs(8) -t cd9660 -o rockridge creates
corrupted cd9660fs):
- makefs/cd9660.c:
- cd9660_rrip_move_directory() should also update lenght[0] and
name_len[0] in dir->isoDirRecord
- makefs/cd9660/iso9660_rrip.c:
- cd9660_rrip_finalize_node() should check rr_real_parent in node->parent,
not in node itself in RRIP_PL case
- cd9660_rrip_initialize_node() should update only node passed as arg
so handle RRIP_PL in DOTDOT case
Fixes malformed dotdot entries in deep (more than 8 level) directories
moved into .rr_moved dir.
Should be pulled up to netbsd-5.
(no official ISO has such deep dirs, but cobalt restorecd is affected)
To generate a diff of this commit:
cvs rdiff -u -r1.29 -r1.30 src/usr.sbin/makefs/cd9660.c
cvs rdiff -u -r1.9 -r1.10 src/usr.sbin/makefs/cd9660/iso9660_rrip.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.