When a BSD partition is mounted _read_only_ to / (suppose /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I receive a ``strange'' error message, and from that moment the mounted filesystem becomes unreadable.
This bug is observed on memstick images from both:
- 11.4-STABLE r369279 (built from source),
- 12.2-RELEASE as downloaded from official mirror.
I tested the following scenarios, when attempting to mount /dev/da0s2:
A- If the partition is mounted r/o from /dev/da0s2a, then mount(8) reports the ``strange'' message and the system becomes unstable (bug).
B- If the partition is mounted from /dev/ufs/label, then mount(8) reports "Operation not permitted" and the system remains stable. This is the expected behavior IMHO.
C- If the partition is mounted read_write, from any special device, then mount(8) reports:
- ``Operation not permitted'' if I try to mount the slice rw and the system remains stable (expected behavior);
- the ``strange'' error message, if I try to mount the slice ro, and the system remains stable (tolerable behavior).
The "strange error message" is "invalid argument" on 11.4-STABLE.
Steps to reproduce:
1- flash the memstick image into a USB pen drive
2- edit /boot/loader.conf on the memstick adding the following lines (needed to boot successfully on my test system, I am not sure they have any influence on this problem):
3- edit /etc/fstab on the memstick and change the root device from
/dev/da0s2a [or whatever device the USB pen drive will be assigned to]
4- boot the memstick and open a shell
5- # mount /dev/da0s2 /mnt
mount: /dev/da0s2: No such file or directory <--- strange message!
- the partition /dev/da0s2a is offset 16 blocks from the beginning of its containing slice /dev/da0s2, as per mkimg(1) default behavior.
- the problem should also appear on i386 (I can check thoroughly if necessary).
IMHO this is a form of foot-shooting and we can claim that root should be allowed to ruin their own system. But it's worth mentioning that there _is_ a safety check in place, that is only active when the partition is mounted from /dev/ufs/label instead of /dev/da0s2. This is counter-intuitive.
I remain available to give further information and/or conducting further tests.