You are right.
To check, I created a clean partition image and performed newfs on that. Then I compared all changes (see attachment) from newfs to the hexedit view of wd0j. Despite of two, three tiny differences all newfs written zeroes 0x00 match the zeroes found in wd0j. Where newfs has written non-zero bytes, they match the bytes in wd0j and where they not match, the bytes on wd0j are non-zero as well (so different timestamp, randomized inode number, or so). So case is clear, I made an indirect newfs on that partition. My next step will be to replay the modified blocks, taking them from my ten-year-old backup, then, maybe using another superblock, mount them ro and see what I can still find .... but not today. For reference, here's a pseudo-record of today's session: jrpierce# echo 0123456789abcdef > test.img jrpierce# dd if=test.img of=test.img bs=16 count=$((512/16-1)) seek=1 31+0 records in 31+0 records out 496 bytes transferred in 0.000 secs (899504 bytes/sec) jrpierce# dd if=test.img of=test.img bs=512 count=$((4217312-614400-1)) seek=1 3602911+0 records in 3602911+0 records out 1844690432 bytes transferred in 378.954 secs (4867838 bytes/sec) jrpierce# ls -l test.img -rw-r--r-- 1 root wheel 1844690944 Jan 13 07:37 test.img jrpierce# hexdump test.img 0000000 3130 3332 3534 3736 3938 6261 6463 6665 * 6df3c000 jrpierce# disklabel -t wd0 >> /etc/disktab. jrpierce# vim /etc/disktab # [Rename disk] jrpierce# tail /etc/disktab diskrepresentation|ESDI/IDE disk|Automatically generated label:\ :dt=ESDI:se#512:ns#63:nt#255:nc#1305:sc#16065:su#20971520:\ :pa#1410976:oa#4217312:ta=4.2BSD:ba#16384:fa#2048:\ :pb#524288:ob#5628288:tb=swap:\ :pc#20971520:oc#0:\ :pd#3500480:od#17471040:td=4.2BSD:bd#16384:fd#2048:\ :pe#7000672:oe#6152576:te=4.2BSD:be#16384:fe#2048:\ :pf#4317792:of#13153248:tf=4.2BSD:bf#16384:ff#2048:\ :pi#593920:oi#20480:ti=unknown:\ :pj#3602912:oj#614400:tj=4.2BSD:bj#16384:fj#2048: jrpierce# newfs -T diskrepresentation ./test.img newfs: ./test.img: not a character-special device newfs: ./test.img: `g' partition is unavailable jrpierce# mv test.img test.imgj jrpierce# newfs -T diskrepresentation ./test.imgj newfs: ./test.imgj: not a character-special device ./test.imgj: 1759.2MB in 3602912 sectors of 512 bytes 9 cylinder groups of 202.50MB, 12960 blocks, 25920 inodes each super-block backups (for fsck -b #) at: 160, 414880, 829600, 1244320, 1659040, 2073760, 2488480, 2903200, 3317920, jrpierce# hexdump test.imgj > test.imgj.01_newfs jrpierce# vnconfig vnd0 test.imgj jrpierce# fsck_ffs -f vnd0c ** /dev/vnd0c (vnd0c) ** File system is already clean ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 871382 free (14 frags, 108921 blocks, 0.0% fragmentation) jrpierce# mount -t ffs -o rw,nodev,nosuid /dev/vnd0c /oldbsd5/ jrpierce# df -h /oldbsd5/ Filesystem Size Used Avail Capacity Mounted on /dev/vnd0c 1.7G 2.0K 1.6G 1% /oldbsd5 jrpierce# touch /oldbsd5/a jrpierce# rm /oldbsd5/a jrpierce# df -h /oldbsd5/ Filesystem Size Used Avail Capacity Mounted on /dev/vnd0c 1.7G 2.0K 1.6G 1% /oldbsd5 jrpierce# umount /oldbsd5/ jrpierce# fsck_ffs -f vnd0c ** /dev/vnd0c (vnd0c) ** File system is already clean ** Last Mounted on /oldbsd5 ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1 files, 1 used, 871382 free (14 frags, 108921 blocks, 0.0% fragmentation) jrpierce# vnconfig -u vnd0 jrpierce# hexdump test.imgj > test.imgj.02_touch_rm_a jrpierce# vnconfig vnd0 test.imgj jrpierce# scan_ffs -v vnd0c [takes some time] scan_ffs: read: Invalid argument jrpierce# vnconfig -u vnd0 jrpierce# On Thu, 11 Jan 2024 14:39:45 +0100 Jan Stary <h...@stare.cz> wrote with subject "Re: Partition completely wiped out, why?": > I don't suppose linux's mount of a wrong type > or obsd's autofsck would wipe the filesystem clean. > In a way, this sounds comforting, non-mentioning the possibility it could destruct the filesystem... > > > > OK, so here's an overview: > > > > old MBR table (read from one of the rare backups): > > Partition 1 20480s -> 614400s (290MiB) ext2 "bootpart" > > Partition 2 614400s -> 4333568s (1.8GiB) 0xA6 (OpenBSD) > > Partition 3 4333568s -> 20000768s (7.5GiB) ext4 "main_system" > > Partition 4 20000768s -> 20971520s (474MiB) Linux swap > > > > old disklabel (partition 2 of old MBR table, again from backup): > > Partition a 614400s -> 4217312s (1.7GiB) type 7 (4.2BSD) > > Partition b 4217312s -> 4333565s ( 57MiB) type 1 (swap) > > Partition c 0s -> 20971520s ( 10GiB) type 0 (unused) > > Partition i 20480s -> 614400s (209MiB) type 17 (unknown) > > Partition j 4333568s -> 20000768s (7.5GiB) type 17 (unknown) > > Partition k 20000768s -> 20971520s (474MiB) type 10 (other) > > To be sure: this is not what a fdisk or disklabel output looks like. > So where exactly is this coming from? This is a manual typed table, calculated from "disktype" output of another Linux machine which has the backup. > > Also, how did you end up having partitions i, j, k, > named like that? Is that what you did in your 5.4 install? Don't know. > > > > recent disklabel (partition 4) > > Partition b 4217312s -> 5628288s 4.2BSD / > > Surely partition 'a'. Are you typing these by hand? Yes. Yes. > Can you post the actual fdisk and disklabel output? jrpierce# fdisk wd0 Disk: wd0 geometry: 1305/255/63 [20971520 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start: size ] ------------------------------------------------------------------------------- 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused *3: A6 0 1 2 - 1305 106 17 [ 64: 20971456 ] OpenBSD jrpierce# disklabel wd0 # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: bla duid: 46153ffc7a4cc8b9 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 1305 total sectors: 20971520 boundstart: 64 boundend: 20971520 16 partitions: # size offset fstype [fsize bsize cpg] a: 1410976 4217312 4.2BSD 2048 16384 10936 # / b: 524288 5628288 swap # none c: 20971520 0 unused d: 3500480 17471040 4.2BSD 2048 16384 12960 # /usr e: 7000672 6152576 4.2BSD 2048 16384 12960 # /var f: 4317792 13153248 4.2BSD 2048 16384 12960 # /home i: 593920 20480 unknown j: 3602912 614400 4.2BSD 2048 16384 12960 jrpierce# > > > guess this "succeeded" but when trying ls /mnt/ I got some error. > > What error? > -1 EIO (Input/output error) (Eingabe-/Ausgabefehler) > > 1 files, 1 used, 871382 free (14 frags, 108921 blocks, 0.0% > > fragmentation) > > Then again, I don't know how 14 frags would exist > on a fresh filesystem. Or is that normal? Seems to be normal, see console log Best Regards Jonas
test.imgj.0x.tgz
Description: application/compressed-tar