On Mar 18, 2005, at 3:09 PM, Rob Newberry wrote:

> 1) Does NetBSD REQUIRE a swap partition?
>
Technically, no.  Practically, yes or a swapfile.  Generally, programs 
don't work well
when malloc fails.  I remembering trying to handle the error, only to 
learn perror() etc, would call malloc.  My ibook g3 has 384 meg ram, 
and has no swap partition, but I added a 32meg swapfile just for some 
leeway.  It didn't seem to use any of it when compiling the kernel.  
What concerns me is dumps, could it possibly  dump to some driver 
partition or something.


> 2) What's the state of Apple UFS support in NetBSD-2.0 and/or later?  
> I'm trying to use
... I'd say good, but not w/o some quirks.

>  have a disk with NetBSD-2.0 installed on a Apple UFS partition.  From 
> OpenFirmware, I can load the NetBSD kernel from this UFS partition 
> with the following sequence:
>
> 	boot hd:,\ofwboot.xcf

This never works for me, on the first boot, but seems to somehow start 
working some time later, since its not reliable, I don't count on it 
and do boot
  hd:,\ofwboot.xcf hd:9,/netbsd

> 	<blah blah complaint>
> 	open /netbsd: No such file or directory
> 	open /netbsd.gz: No such file or directory
> 	open /netbsd.macppc: No such file or directory
> 	Boot:
>
> I then enter:
>
> 	hd:10,/netbsd

Weird,  whenever I get that , nothing I typed at boot prompt would 
work, and
I have to reset via holding down power.

> and the NetBSD kernel loads.
>
> Unfortunately, at the end of the process, I get stuck with the 
> following repeating sequence:
>
> 	cannot mount root, error = 69
> 	root device (default wd0a)
> 	dump device (default wd0b)
> 	file system (default generic)
> 	no file system for wd0 (dev = 0xa00 )
> 	cannot mount root, error = 69
> 	root device (default wd0a)
> 	dump device (default wd0b)
> 	file system (default generic)
> 	no file system for wd0 (dev = 0xa00 )
> 	cannot mount root, error = 69
> 	root device (default wd0a)
> 	dump device (default wd0b)
> 	file system (default generic)
> 	no file system for wd0 (dev = 0xa00 )
>
> I don't know what it's doing here.
>
Yet, that seems familiar... perhaps some kind of 'lossy compression' 
going on in some subconscious thread in my head -- but it does map into 
'not working' ;-]  Anyway.
I found my kernel was trying to mount my patch partition.

> Here's some more pieces of information, if they're helpful.  If I boot 
> from the NetBSD-2.0 CD, I can run the following:
>
> 	#disklabel wd0
> 	disklabel: Invalid signature in mbr record 0
> 	# /dev/rwd0c:
> 	type: ESDI
> 	disk: Maxtor 53073U6
> 	label: fictitious
> 	flags:
> 	bytes/sector: 512
> 	sectors/track: 63
> 	tracks/cylinder: 16
> 	sectors/cylinder: 1008
> 	cylinders: 59554
> 	total sectors: 60030432
> 	rpm: 3600
> 	interleave: 1
> 	trackskew: 0
> 	cylinderskew: 0
> 	headswitch: 0             #microseconds
> 	track-to-track seek: 0    #microseconds
> 	drivedata: 0
> 	8 partitions:
> 	#     size      offset     fstype [fsize bsize cpg/sgs]
> 	 a:   262144      1824    unknown                     # (Cyl.     1*- 
>  261*)

Cyl 261?  I thinking it's your patch partition...
Maybe try booting the install kernel, going to shell then do
for D in /dev/wd0? ;
do
    mount $D /mnt  && break
done
Or similiar... try all partitions and see which is what.  Then maybe 
fsck the 'em.


> 	 b: 19748032    263968  Apple UFS      0     0      0 # (Cyl.   
> 261*-19853*)
> 	 c: 60030432         0     unused      0     0        # (Cyl.     0 
> -59553)
> 	 d: 19748032  20274144        HFS                     # (Cyl. 
> 20113*-39704*)
> 	 e:   262144  20012000    unknown                     # (Cyl. 
> 19853*-20113*)
> 	 f:   262144  40022176    unknown                     # (Cyl. 
> 39704*-39964*)
> 	 g: 19746096  40284320        HFS                     # (Cyl. 
> 39964*-59553*)
>      h:       16  60030416    unknown                     # (Cyl. 
> 59553*-59553)
>
> 	# pdisk -l /dev/wd0c
> 	
> 	Partition map (with 512 byte blocks) on '/dev/wd0c'
> 	 #:                type name                    length   base     ( 
> size )
> 	 1: Apple_partition_map Apple                       63 @ 1
> 	 2:      Apple_Driver43*Macintosh                   56 @ 64
> 	 3:      Apple_Driver43*Macintosh                   56 @ 120
> 	 4:    Apple_Driver_ATA*Macintosh                   56 @ 176
> 	 5:    Apple_Driver_ATA*Macintosh                   56 @ 232
> 	 6:      Apple_FWDriver Macintosh                  512 @ 288
> 	 7:  Apple_Driver_IOKit Macintosh                  512 @ 800
> 	 8:       Apple_Patches Patch Partition            512 @ 1312
> 	 9:          Apple_Free                         262144 @ 1824     
> (128.0M)
> 	10:           Apple_UFS Apple_HFS_Untitled_2  19748032 @ 263968   (  
> 9.4G)
> 	11:          Apple_Free                         262144 @ 20012000 
> (128.0M)
> 	12:           Apple_HFS Apple_HFS_Untitled_3  19748032 @ 20274144 (  
> 9.4G)
> 	13:          Apple_Free                         262144 @ 40022176 
> (128.0M)
> 	14:           Apple_HFS Apple_HFS_Untitled_4  19746096 @ 40284320 (  
> 9.4G)
> 	15:          Apple_Free                             16 @ 60030416
>
Why all the Apple_Free's ?  It seem likes its a waste of space, might 
confused things
too.
  <...>
> Now, there are a few things I can think of that I need to see about 
> resolving.
>
> I suspect that at least part of the problem is that the "flags" and 
> mount point
I really need to look at the source... I remember being very 
frustrated, trying a few
things, similiar to what you describe, then suddenly it works, and a is 
a.. etc.
I think it ignore partitions under some number, and size, which is ok 
for most apple
stuff, but patch partition is big enough.. it's wierd.  Again, I 
remember trying
multiple times, telling myself I was going to write a patch to override 
its guesswork,
and allow me to just name partitions "a" and have that be "a" etc... 
but, again, but it all became moot, as it seemed to fix itself, after 
2nd boot