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 <[email protected]> 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
