HAMMER hosed?

Bill Hacker wbh at conducive.org
Fri Feb 13 20:31:09 PST 2009


Bill Hacker wrote:
Bill Hacker wrote:
Bill Hacker wrote:
Simon 'corecode' Schubert wrote:
Bill Hacker wrote:
Hi Simon, Thanks for the quick reply...

The install would have used whatever the default was as of the
DEVELOPMENT snapshot of just a few days ago.
DFLY was happy cooperating with the (at the time) DFLY, Slackware,
OpenBSD, NetBSD and each booted fine off the new DFLY bootloader.
FreeBSD 8- December snapshot was used to change the type of the second
slice, sub-partition it, then install itself to replace Linux.
Bad move, as along the way it screwed the hammerfs-bootable DFLY 
somehow.

fdisk sees what was expected.

The other three OS'en still boot and run nomally.

Selecting DFLY (F1) returns 'invalid partition'

What I get with either disklabel or disklabel64 off the DFLY
Live/Install CD is:
 'bad pack magic number'

Attempts to edit the label give:

'Operation not supported by device'

Now - IF I knew what bits or bytes to change and where, I'm happy 
to go
after it with a hex editor... or dd. or whatever.

But I had not made a disklabel copy, so ....
you could post the output of

dd if=/dev/adXXsYY count=4 | hd

for us to debug.  Alternatively, you can try killing the disklabel with

dd if=/dev/zero of=/dev/adXXsYY count=4

and then re-creating it.  it basically has to read:

a: * 0 HAMMER
b: $SWAPSIZE * swap
where swapsize is the value you entered in the installer.  The 
default value depends on your memory size and is 
2*next_power_of_2(your_memory_in_MB) MB.

cheers
 simon
I've gotten into disklabel -e mode with NetBSD.

Not going to change anything just yet, but rather write what it sees, 
do the same with OpenBSD and FreeBSD (perhaps even a Linux).

Will post those as well as the dd output 'shortly'.

Thanks,

Bill

dd output heme'd to readable is attached, as it would word-wrap to 
uselessness.

Other views below.

Thanks,

Bill

=========================================================================
NetBSD sees:
# /dev/rwd0d:
type: unknown
disk: Hitachi HTS5416
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 232581
total sectors: 234441648
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0           # microseconds
track-to-track seek: 0  # microseconds
drivedata: 0
16 partitions:
#   size    offset     fstype [fsize bsize cpg/sgs]
a:  8192016 188731620  4.2BSD  2048 16384   0  # (Cyl. 187233*- 195360*)
b:  2048256 196923636  swap                    # (Cyl. 195360*- 197392*)
c: 45703980 188731620  unused      0    0      # (Cyl. 187233*- 232574)
d:234441648         0  unused      0    0      # (Cyl.      0 - 232580)
e: 62910477        63  4.2BSD      0    0   0  # (Cyl.      0*-  62411*)
f: 62910540  62910540 Linux Ext2   0    0      # (Cyl.  62411*- 124822*)
g: 62910540 125821080 unknown                  # (Cyl. 124822*- 187233*)
h: 12288528 198971892  4.2BSD   2048 16384  0  # (Cyl. 197392*- 209583*)
i:  8192016 211260420  4.2BSD   2048 16384  0  # (Cyl. 209583*- 217710*)
j:  8192016 219452436  4.2BSD   2048 16384  0  # (Cyl. 217710*- 225837*)
k:  6791148 227644452  4.2BSD   2048 16384  0  # (Cyl. 225837*- 232574)
NOTES: The Linux Ext2 s/b type 165 / A5 FreeBSD, as it was so set then 
FreeBSD installed and tested from it.
=========================================================================

OpenBSD sees (not much it has not put its own prints on.. but it boots)

# /dev/rwd0c:
type: ESDI
disk: ad0s3
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 14593
total sectors: 234441648
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]
a:         62910540        125821080  4.2BSD   2048 16384    1
c:        234441648                0  unused      0     0
============================================================================ 

DFLY won't read anything at all...



Forgot this one:

=============================================================================== 

FreeBSD sees:

FreeBSD sysinstal sees:

ad0 slices:

Offset     Size    End    Name    PType    Desc        Subtype    Flags
0     63        62    -    12    unused        0
63      62910225  62910287    ad0s1     8    freebsd        165
62910540  62919539       252    -    12    unused        0
62910540  62910540 125821079    ad0s2     8    freebsd        165
125821080 62910540 188731619    ad0s3     4    OpenBSD FFS    166
188731620 45703980 234435599    ad0s4     4    NetBSD FFS    169
234435600     6048 234441647    -    12    unused        0
ad0s2 partitions:

ad0s2a    /     6144MB
ad0s2d    /usr    12288MB
ad0s2e    /var     6144MB
ad0s2f    /home     3072MB
ad0s2b    swap     2048MB
ad0s2g    /tmp     1022MB
=============================================================================== 

Resolved by read, edit, write-back with NetBSD, follwed by re-install of 
FreeBSD-7.1_RELENG replacing 8-CURRENT in ~/ad0s2, then DragonFlyBSD 
2.30-DEVELOPMENT 11 FEB 09 in ~/ad0s1, in that order.
All 4 BSD's now happy.

For future reference:

- ONE BSD implementation of disklabel 'sees' the entire device, though 
'through a glass, darkly' in some ways:

EG NetBSD: disklabel -r /dev/ad0

shows all identifiable slices, and *some* other OS's sub-partitions (at 
least w/r swap). This alos falsl down if/as/when the total of slices * 
subpartitions exceeds what netBSD thinks is the max...

- The other *BSD's 'see' only the disklabel in each slice ~/ad0s(n), 
ELSE none that is valid, or even 'present'.  Presumed they accurately 
report only the one they wrote themselves when installing. FreeBSD 4.x 
and DragonFly were the last two BSD AFAIK that were compatible in that 
reagrd.

Otherwise - for slices not marked as (one of) their own native fs 
type(s), they are either blind, return garbage, or report an error of 
some kind.

CAVEAT:

Observed fact, but I may be (very) wrong as to the 'why' of it.

Regards,

Bill







More information about the Users mailing list