TL;DR - maybe the reason is some bad interaction between Linux mount
with wrong -o ufstype=old with following BSD auto-fsck on boot?

Also thanks to ken and Otto for pointing out that you must write one of
"ro" or "rw".

In case it helps, here are detailed answers to the questions:


On Wed, 10 Jan 2024 22:42:00 +0100
Jan Stary <h...@stare.cz> wrote with subject
"Re: Partition completely wiped out, why?":

> On Jan 10 00:21:12, p...@jbechtel.de wrote:
> > Ten years ago I installed OpenBSD 5.[?] which included setting up a
OpenBSD 5.4, installed in June 2014, btw.

> > small partition of 2 GB, including the full OS with kernel,
> > programs, web-related data, etc..  
> 
> Why did you install everything in one small partition?

The rest of the 10 GB was mainly an existing ext3 GNU/Linux partition
(more detail below) which I wanted to re-use as data directory. That
approach didn't work because it was not mountable, so I just used the
tiny partition, planning to back-up the ext3 partition.

> 
> > 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
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


> 
> > (very helpful, this
> > post: https://bugzilla.kernel.org/show_bug.cgi?id=197733; looked
> > similar to mine few days ago)  
> 
> That says "unable to mount UFS",
> while yours was a perfectly fine system, AFAIU.

Sorry for misleading "helpful", just one neat shell command line to
identify UFS, first two output lines looked like mine. (helpful as in
"no need to read spec, think about byte ordering, guess lots of things,
...") 

> 
> > This weekend I installed OpenBSD 7.4.  
> 
> 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)

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  /
   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)

> 
> > Finally I reconstructed the partition table  
> 
> What partition table? You had one partition.

See above

> 
> > (fresh MBR pointing to the still intact disklabel)
> > 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.  
> 
> 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.

I tried to mount the partition in Rescue Linux. (not -o ro probably) I
guess this "succeeded" but when trying ls /mnt/ I got some 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

(For reference, GNU/Linux man mount says:

   Mount options for ufs
       ufstype=value
           UFS is a filesystem widely used in different operating
           systems. The problem are differences among implementations.
           Features of some implementations are undocumented, so its
           hard to recognize the type of ufs automatically. That’s
           why the user must specify the type of ufs by mount option.
           Possible values are:

           old
               Old format of ufs, this is the default, read only. (Don’t
               forget to give the -r option.)

           44bsd
               For filesystems created by a BSD-like system (NetBSD,
               FreeBSD, OpenBSD).

           ufs2
               Used in FreeBSD 5.x supported as read-write.
           
           ...
)

After mounting with right ufstype, I saw right data. (Probably this is
what I remember. Files in root directory looked well there)

In installation I went to manual disklabel edit. One of the steps there
was to assign the mount point /oldbsd5 there.

> 
> > 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.
> 
> > Then I deleted "rw,"  
> 
> Why?

Because I wanted to achieve "ro" and just wasn't sure whether this
would be sufficient (all others were marked rw) and wanted to give it a
try. 

> 
> > from fstab and maybe rebooted the system once or
> > twice. 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.

> 
> You cannot rm a mounted point, so if it was indeed mounted,
> "rm -rf /oldbsd5" wouldn't work. (But "rm -rf /oldbsd5/*" would.)
> 
> > Then
> > I found out (with df -h) that the partition is empty.  
> 
> Show the df -h output.

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/wd0a      662M   83.4M    546M    14%    /
/dev/wd0f      2.0G    854K    1.9G     1%    /home
/dev/wd0d      1.6G    1.4G    152M    91%    /usr
/dev/wd0e      3.2G    1.2G    1.9G    39%    /var
/dev/wd0j      1.7G    2.0K    1.6G     1%    /oldbsd5

> 
> > Really actually
> > empty, so theres no hidden file, no file, no lost+found, just
> > nothing.  
> 
> Show the fstab and the disklabel and output of mount -v

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)

(This is after manually mounting wd0j)

> 
> > The data, however, is still scattered on disk. I can see the lines
> > of known text files with grep.  
> 
> Grepping what, the /dev/sdXj ?

dd if=/dev/wd0j bs=1000000 | grep -A2 -E '^(Short [tT]|T)itle:'

> 
> > I also can see the signature at 0x455c, but
> > not any more at 0x255c. fsck doesn't find anything problematic.  
> 
> So what does fsck /oldbsd5 actually say?

# 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)

> 
> Is the partition actually mounted?

For dd+grep and fsck: no
For df: yes
Default: no (commented out in fstab)

> 
>       Jan
> 


So I hope that I didn't remember the intermediate Linux mounts in my
first mail didn't draw too much attention.

Best Regards
 Jonas

Reply via email to