Re: 3.8 snapshot bsd.rd installer clobbers MacOS partitions (or whatever is at sd0a ?)

On 9/18/05, Martin Reindl <[email protected]> wrote:
> Andrew Daugherity <[email protected]> wrote:
>
> > Summary: bsd.rd 3.8 snapshot installer overwrites the sd0a partition,
> > rather than asking which one to newfs/mount.  Also, disklabel does not
> > see the partition created by pdisk.
> >
> > Details: After reading about the "video address hack" option in the
> > Booter program, I discovered that 3.7 does indeed boot on my Quadra
> > 605; however, as has been reported by others, the ADB keyboard (Apple
> > Keyboard II) does not work with the RAMDISK kernel.  I managed to rig
> > up a serial console with a Mac modem cable + DB25/DB9 adapter + the
> > DB9 null-modem cable I use on i386 boxen, and proceeded with the
> > install, figuring I'd see if the keyboard worked in GENERIC after
> > installing.
>
> RAMDISK detects your hardware, so i really wonder why it doesn't work. Other
> 'Cuda' machines work. But then, an ADB overhaul is due anyway.
I finally got it installed; ADB keyboard does work in GENERIC. 
Incidentally, behavior is the same in 3.7 -- ADB works in GENERIC, but
does not in bsd.rd (RAMDISK).  As there was no bsd.rd prior to 3.7,
there's nothing earlier to test.  It's strange because the dmesg is
virtually identical (the "mrg: kernel has no ROM vectors for this
machine!" line only appears when booting to a serial console; the
bsd.rd prints the same mrg messages as GENERIC when booting to the
local keyboard/video, but as the keyboard doesn't work, I can't
capture *that* dmesg). GENERIC dmesg enclosed at end.

> If you wanted to replace NetBSD with OpenBSD, then you could have just reused
> the partitions and would have a working system now. Yes, disklabel was not
> invoked. Disklabel only gets invoked when there are no Mac OS headers on the
> disk, e.g. a 'blank' disk. But the booter cannot load kernels from there.
> So we got pdisk replacing disklabel here, and contrary to macppc, where you mark
> an OpenBSD partition and create slices _inside_ this partition, on mac68k the
> slices are supposed to be generated by pdisk. Currently the safest way to
> install is using slices generated by mkfs in Mac OS or reuse slices from NetBSD.

I had roughly 400MB each assigned to Debian and NetBSD, and both
partitions were full, so I decided to forget about Linux for now.

I think the bug is in pdisk (unless I egregiously misused it somehow),
as after running the patched Apple HD SC Setup to recreate the
partition, OpenBSD sees the disklabel correctly (incidentally, the
same way NetBSD did before I blew it away, with the Mac partition
moved to sd0d), and the installer newfs'd it ok:
=====
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: ST51080N
flags:
bytes/sector: 512
sectors/track: 109
tracks/cylinder: 4
sectors/cylinder: 436
cylinders: 4826
total sectors: 2109840
rpm: 5376
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0

6 partitions:
#             size        offset  fstype [fsize bsize  cpg]
  a:       1644288        465516  4.2BSD      0     0    0 # Cyl  1067*-  4838
  b:        137744        327772    swap                   # Cyl   751*-  1067*
  c:       2109840             0  unused      0     0      # Cyl     0 -  4839*
  d:        327676            96     HFS                   # Cyl     0*-   751*
  e:            36       2109804 unknown                   # Cyl  4839 -  4839*
  f:             5       2109835 unknown                   # Cyl  4839*-  4839*
=====
> > I verified the network works (it does, despite INSTALL.mac68k claiming
> > LC-PDS ethernet cards don't work), and then dropped to a shell to
> > examine the disklabel output (which is different than the partition
> > map, not even showing my OpenBSD partition!).  Complete serial console
> > log follows.
>
> That's good. You are probably the first one testing this after the nubus
> changes.
Aside from occasionally complaining on initialization, it works just
fine.  I don't know if this is worth noting in the ae(4) man page or
the FAQ, but some of these Asante cards have a hardware bug where they
only work attached to a 10Mbit-only hub.  When connected to a 100Mbit
switch (which autosenses 10Mb/half duplex with all my other 10Mbit
devices), it refuses to link up (under any OS).  I was about to trash
the card until I discovered this through some Googling and threw an
old hub in between it and my switch.

Andrew

====
OpenBSD 3.8 (GENERIC) #49: Sun Sep  4 10:37:17 EDT 2005
    [email protected]:/usr/src/sys/arch/mac68k/compile/GENERIC
Apple Macintosh Quadra 605, 68040 CPU+MMU+FPU, 4k on-chip physical I/D caches
real mem = 37748736 (36864K)
avail mem = 29061120 (28380K)
using 460 buffers containing 1884160 bytes (1840K) of memory
mrg: 'Quadra/Centris 605 ROMs' ROM glue, tracing off, debug off, silent traps
mrg: I/O map kludge for ROMs that use hardware addresses directly.
adb: bus subsystem
mrg: skipping egret setup
adb: calling ADBReInit
adb: using Cuda series hardware support
adb: cleanup: nothing returned
adb: ADBReInit complete
adb: mapped device (8) at 2
adb: 100 dpi mouse at 3
mainbus0 (root)
obio0 at mainbus0
adb0 at obio0 (ADB event device)
asc0 at obio0: Apple Sound Chip
intvid0 at obio0: DAFB: monitor sense 1
intvid0: 640 x 480, monochrome
grf0 at intvid0
ite at grf0 not configured
esp0 at obio0 (pseudo-DMA): NCR53C96, 16MHz, SCSI ID 7
scsibus0 at esp0: 8 targets
sd0 at scsibus0 targ 0 lun 0: <SEAGATE, ST51080N, 0913> SCSI2 0/direct fixed
sd0: 1030MB, 4826 cyl, 4 head, 109 sec, 512 bytes/sec, 2109840 sec total
zsc0 at obio0
zstty0 at zsc0 channel 0
zstty1 at zsc0 channel 1
nubus0 at mainbus0
ae0 at nubus0 slot e: address 00:00:94:6a:71:5c, type MacCon LC - A ,
32KB memory
root on sd0a swap on sd0b
ae0: length does not match next packet pointer
ae0: len 0000 nlen ff00 start 0c first 00 curr 3c next 00 stop 80
ae0: NIC memory corrupt - invalid packet length 65280
PRAM time does not appear to have been read correctly.
PRAM: 0x83da4f80, macos_boottime: 0x432f59c8.