Subject: Re: CVS commit: basesrc/distrib/utils/mksunbootcd
To: John Nemeth <>
From: Luke Mewburn <>
List: current-users
Date: 10/11/2002 08:57:30
On Thu, Oct 10, 2002 at 10:41:48AM -0700, John Nemeth wrote:
  | On Mar 2, 10:10am, Luke Mewburn wrote:
  | } As far as we've been able to tell, the UltraSPARC PROM doesn't use the
  | } .slicemap file.  When you do "boot cdrom" on an UltraSPARC it just
  | } tries "boot cdrom:f" by default.  Or at least, as far as the people
  | } who tested the images that I built have found anyway, because my test
  | } images did not have a .slicemap file...
  |      So, what you are saying is that you just have to put the sun4u
  | boot code in the correct partition?

Yes, as far as we've been able to determine.

As I said, my test image did NOT have a slicemap file, and I created
it using the infrastructure in distrib/cdrom, which effectively does:
	mksunbootcd image sparc.fs sparc.fs sparc.fs /dev/null sparc64.fs
Which puts boot slices in b, c, d, and f.

  | I built a multi-boot image for myself (i386, sparc, sparc64). 
  | It had a .slicemap like this:
  | cat NetBSD-1.6/.slicemapfile
  | m       1       sun4
  | m       2       sun4c
  | m       3       sun4m
  | m       4       sun4d
  | m       5       sun4u
  | (Not sure why I included sun4d).  The makesunbootcd args matched (i.e.
  | four copies of sparcboot.fs followed by one copy of sparc64boot.fs).  I
  | test booted it on both my SparcStation 5 (sun4m) and my Ultra 1 (sun4u)
  | using just "boot cdrom" at the PROM prompt.  On the SS5 it came up with
  | a script based installer and on the U1 it came up with a sysinst
  | installer so I know both machines were booting different partitions.
  | Given that I had the sun4u code in the fifth partition, wouldn't that
  | have been cdrom:e?  If the U1 didn't use the .slicemap file, then how
  | did it find the appropriate partition?  (I suppose it might have just
  | used the last partition on the CD.)

The arguments for mksunbootcd are:
	image-to-modify	[slice1 [slice2 [slice3 [slice4 [slice5 [...]]]]]]

Since slice numbering starts at 0 (`a' in NetBSD parlance), slice5 == `f'.