On Jan 11 01:35:20, p...@jbechtel.de wrote:
> TL;DR - maybe the reason is some bad interaction between Linux mount
> with wrong -o ufstype=old with following BSD auto-fsck on boot?
I don't suppose linux's mount of a wrong type
or obsd's autofsck would wipe the filesystem clean.
> > > What also may be noted is that the ufs magic 0x00011954 (or,
> > > 1954 0001, in hexdump switched 2-bytes) was present at position
> > > 0x255c and 0x455c and several times at larger offsets.
> >
> > Could these be copies of the superblock?
>
> How to find out? Does this help? # scan_ffs -v wd0j
man fsck says:
-b block#
Causes fsck to use the specified block as the location of
the superblock. Block 32 is usually an alternate super block.
So I'm guessing yes, these are copies of the superblock.
> block 32 id 5351628a,266db641 size 900728
> block 6624 id 6581,4040010 size 4
> block 414688 id 5351628a,266db641 size 900728
> block 829344 id 5351628a,266db641 size 900728
> block 1244000 id 5351628a,266db641 size 900728
> block 1255916 id 95be8,c4834800 size 50640872
> block 1658656 id 5351628a,266db641 size 900728
> block 2073312 id 5351628a,266db641 size 900728
> block 2487968 id 5351628a,266db641 size 900728
> block 2902624 id 5351628a,266db641 size 900728
> block 3317280 id 5351628a,266db641 size 900728
> scan_ffs: read: Invalid argument
> > Where? Into that same small partition?
> > On another disk in that same machine?
> > On other partitions on that same disk?
>
> 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?
Also, how did you end up having partitions i, j, k,
named like that? Is that what you did in your 5.4 install?
> recent MBR table:
> Partition 1 0s -> 0s 0x00 (unused)
> Partition 2 0s -> 0s 0x00 (unused)
> Partition 3 0s -> 0s 0x00 (unused)
> Partition 4 64s -> 20971520s ( 10GiB) 0xA6 (OpenBSD)
>
> recent disklabel (partition 4)
> Partition b 4217312s -> 5628288s 4.2BSD /
Surely partition 'a'. Are you typing these by hand?
Can you post the actual fdisk and disklabel output?
> Partition b 5628288s -> 6152576s swap none
> Partition c 0s -> 20971520s unused
> Partition d 17471040s -> 20971520s 4.2BSD /usr
> Partition e 6162576s -> 13153248s 4.2BSD /var
> Partition f 13153248s -> 17471040s 4.2BSD /home
> Partition i 20480s -> 614400s unknown
> Partition j 614400s -> 4217312s 4.2BSD (/oldbsd5)
>
> > > assigned a mount point to the old partition, "/oldbsd5", which
> > > worked on first boot. I just saw the usual files usr, mnt, ... when
> > > invoking "ls /oldbsd5", assumed it was working then.
Must have, if you could mount it and ls it.
> > To be clear: you installed 7.4 somewhere else
> > and just mounted the old small partition from
> > the new 7.4 install, seeing the old data.
>
> Uh-oh, good question. I try to recall.
Well, that's what you just said:
the old partition being wd0j of the new install,
being mountable and listable.
Are you sure you didn't simply rewrite it
during the 7.4 install? (Being in place, i.e.
within the same sectors, but newfs'd empty.)
> I tried to mount the partition in Rescue Linux. (not -o ro probably) I
When? After you saw it as empty under you new 7.4 install? Why?
> guess this "succeeded" but when trying ls /mnt/ I got some error.
What error?
> This failed because the UFS type selection defaulted wrong. Then I chose the
> right UFS type with -o ufstype=44bsd, maybe -o ufstype=44bsd,ro
> After mounting with right ufstype, I saw right data. (Probably this is
> what I remember. Files in root directory looked well there)
Well, could you also do the same from within your new 7.4 install?
(Why would you bring another OS into it?)
> In installation I went to manual disklabel edit. One of the steps there
> was to assign the mount point /oldbsd5 there.
Assigning a mount point does not mean the installer will not newfs it;
you assign a mount point to the fresh filestystems too ...
> > > Automatic fstab entry was
> > > [hash].j /oldbsd5 ffs rw,nodev,nosuid 1 2
> >
> > What do you mean by "automatic"?
> > Surely the installer didn't create an "/oldbsd5" mountpoint.
> ... Sure? I didn't either touch fstab.
I mean the installer: surely the installer didn't invent
the name "/oldbsd5". You assigned it manualy, as you say above;
and that's what ends up in fstab of course.
So, by "automatic", you mean "that's what the installer
put into fstab, after I said so in the disklabel edit"
(which is understandable), as opposed to some "automatic"
partitioning (which confused me).
> > > I'm pretty sure that I never made rm -rf on that directory.
> >
> > "Pretty sure," he said.
>
> So with "rm -rf" on command line before <enter> I definitely check the
> pwd/target dir.
I don't think you rm-rf'd your directory;
I suspect you simply newfs'd a new FS in its place.
> 46153ffc7a4cc8b9.b none swap sw
> 46153ffc7a4cc8b9.a / ffs rw 1 1
> 46153ffc7a4cc8b9.f /home ffs rw,nodev,nosuid 1 2
> #46153ffc7a4cc8b9.j /oldbsd5 ffs ro,nodev,nosuid 0 0 #(was rw,... 1 2)
> 46153ffc7a4cc8b9.d /usr ffs rw,wxallowed,nodev 1 2
> 46153ffc7a4cc8b9.e /var ffs rw,nosuid 1 2
>
> /dev/wd0a (46153ffc7a4cc8b9.a) on / type ffs (rw, local, ctime=Wed Jan
> 10 22:37:07 2024)
> /dev/wd0f (46153ffc7a4cc8b9.f) on /home type ffs (rw, local, nodev,
> nosuid, ctime=Wed Jan 10 22:36:25 2024)
> /dev/wd0d (46153ffc7a4cc8b9.d) on /usr type ffs (rw, local, nodev,
> wxallowed, ctime=Wed Jan 10 22:36:25 2024)
> /dev/wd0e (46153ffc7a4cc8b9.e) on /var type ffs (rw, local, nosuid,
> ctime=Wed Jan 10 22:36:25 2024)
> /dev/wd0j on /oldbsd5 type ffs (local, read-only, ctime=Thu Jan 11
> 01:02:36 2024)
> > > The data, however, is still scattered on disk. I can see the lines
> > > of known text files with grep.
newfs does not erase the individual data blocks;
those arte still there.
> > > I also can see the signature at 0x455c, but
> > > not any more at 0x255c.
That's another sign for me to suspect
it is not the same filesystem.
> # fsck -f /dev/wd0j
> ** /dev/rwd0j
> ** 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)
Then again, I don't know how 14 frags would exist
on a fresh filesystem. Or is that normal?
> > Is the partition actually mounted?
> Default: no (commented out in fstab)
It is probably less cubersome to use 'noauto'.
Jan
