Re: HAMMER hosed?
Bill Hacker wrote: .or perhaps not.. Have 120 GB HDD sliced for: - FreeBSD - DFLY with hammerfs - OpenBSD - NetBSD FreeBSD installed last. Unfortunately, did not think to do the within-slice partitioning for FreeBSD with DragonFly's modern toolset (..once bitten..) Ergo, though I had FreeBSD NOT write bootblock or touch the MBR, it did munge the disklabel.. :-( The DFLY bootloader I was using now throws 'invalid partition' and DFLY liveCD disklabel reports 'Bad magic number' for that slice. I guess you used disklabel64? What you could try is overwriting the disklabel64 by a new one which is exactly the same. The contained hammer filesystem should not be destroyed in that case. Let us know if you need help figuring out how to do that. cheers simon
Re: HAMMER hosed?
Simon 'corecode' Schubert wrote: Bill Hacker wrote: .or perhaps not.. Have 120 GB HDD sliced for: - FreeBSD - DFLY with hammerfs - OpenBSD - NetBSD FreeBSD installed last. Unfortunately, did not think to do the within-slice partitioning for FreeBSD with DragonFly's modern toolset (..once bitten..) Ergo, though I had FreeBSD NOT write bootblock or touch the MBR, it did munge the disklabel.. :-( The DFLY bootloader I was using now throws 'invalid partition' and DFLY liveCD disklabel reports 'Bad magic number' for that slice. I guess you used disklabel64? What you could try is overwriting the disklabel64 by a new one which is exactly the same. The contained hammer filesystem should not be destroyed in that case. Let us know if you need help figuring out how to do that. cheers simon 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 Best, Bill
Re: HAMMER hosed?
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
Re: HAMMER hosed?
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: # sizeoffset 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 00 # (Cyl. 187233*- 232574) d:234441648 0 unused 00 # (Cyl. 0 - 232580) e: 6291047763 4.2BSD 00 0 # (Cyl. 0*- 62411*) f: 62910540 62910540 Linux Ext2 00 # (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: 62910540125821080 4.2BSD 2048 163841 c:2344416480 unused 0 0 DFLY won't read anything at all... :EB 3C 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ... 0018:12 00 02 00 00 00 00 00 00 00 00 00 00 16 1F 66 6A 00 51 50 06 53 31 C0 ...fj.QP.S1. 0030:88 F0 50 6A 10 89 E5 E8 C0 00 8D 66 10 CB FC 31 C9 8E C1 8E D9 8E D1 BC ..Pj...f...1 0048:00 7C 89 E6 BF 00 07 FE C5 F3 A5 BE EE 7D 80 FA 80 72 2C B6 01 E8 60 00 .|...}...r,...`. 0060:B9 01 00 BE AA 8E B6 01 80 7C 04 A5 75 07 E3 19 F6 04 80 75 14 83 C6 10 .|..u..u 0078:FE C6 80 FE 05 72 E9 49 E3 E1 BE A2 7D EB 4B 31 D2 89 16 00 09 B6 10 E8 .r.I}.K1 0090:2E 00 BB 00 90 8B 77 0A 01 DE BF 00 C0 B9 00 AE 29 F1 F3 A4 FA 49 74 14 ..w.)It. 00A8:E4 64 A8 02 75 F7 B0 D1 E6 64 E4 64 A8 02 75 FA B0 DF E6 60 FB E9 50 13 .d..ud.d..u`..P. 00C0:BB EC 8C 8B 44 08 8B
Re: HAMMER hosed?
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: # sizeoffset 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 00 # (Cyl. 187233*- 232574) d:234441648 0 unused 00 # (Cyl. 0 - 232580) e: 6291047763 4.2BSD 00 0 # (Cyl. 0*- 62411*) f: 62910540 62910540 Linux Ext2 00 # (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: 62910540125821080 4.2BSD 2048 163841 c:2344416480 unused 0 0 DFLY won't read anything at all... Forgot this one: === FreeBSD sees: FreeBSD sysinstal sees: ad0 slices: Offset SizeEndNamePTypeDescSubtypeFlags 0 6362-12unused0 63 62910225 62910287ad0s1 8freebsd165 62910540 62919539 252-12unused0 62910540 62910540 125821079ad0s2 8freebsd165 125821080 62910540 188731619ad0s3 4OpenBSD FFS166 188731620 45703980 234435599ad0s4 4NetBSD FFS169 234435600 6048 234441647-12unused0 ad0s2 partitions: ad0s2a/ 6144MB ad0s2d/usr12288MB ad0s2e/var 6144MB ad0s2f/home 3072MB ad0s2bswap 2048MB ad0s2g/tmp 1022MB
