I switched to GPT it is a success with freebsd & UFS2, netbsd boots, fscks, and
read-writes ffsv2 alright). Booting is still done with legacy BIOS and
GRUB2/knetbsd but now with the additional BIOS boot partition, an alternative
to the Hybrid GPT trickery.
> | BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
> ALTERNATE
> fsck_ext2fs compares primary and alternate superblock. Apparently there is
> a difference, unfortunately it's not shown.
Now trying the same but with ext2 from gnu/linux, I got that issue
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST
ALTERNATE
ioctl (GCINFO): Inappropriate ioctl for device
/dev/rdk1: can't read disk label
So is that SUPER BLOCK issue truly reflecting what it says or is it simply
about the fsck_ext2fs not finding a label for the device?
In case the message is true, here is the difference in two columns for a
freshly built fs on gnu/linux. I am not sure I should rather downgrade to -r0
or in the contrary try to make dir_index work without failing, but let's say
that is the right way for now.
mkfs.ext2 -O ^dir_index /dev/sda2
The primary superblock is on the left, and the first available secondary
superblock on the right.
http://tmp.nethence.com/diff.y.superblock.txt
For the record, this is how I reached the superblocks. Checking block GROUP
size
tune2fs -l /dev/sda2 | egrep '^Block size' # 4096
tune2fs -l /dev/sda2 | egrep '^Blocks per group' # 32768
dumpe2fs /dev/sda2 | grep superblock | head
reading the ext2 primary and first backup superblocks (noticing `53 ef` at byte
`56` https://wiki.osdev.org/Ext2)
dd if=/dev/sda2 bs=1024 skip=1 count=1 2>/dev/null | hexdump -vC | less
dd if=/dev/sda2 bs=1024 skip=$((4*32768)) count=1 2>/dev/null | hexdump
-vC | less
dd if=/dev/sda2 bs=1024 skip=1 count=1 > primary
dd if=/dev/sda2 bs=1024 skip=$((4*32768)) count=1 > backup
diff -y <(xxd primary) <(xxd backup)
Similarly here is how the superblock look like after I've deployed netbsd/amd64
8.0 on it manually
http://tmp.nethence.com/diff.y.superblock2.txt
and this is the superblocks netbsd complains about at its first boot.
In the case the message is false and rather relates to labels
disklabel dk1
gives indeed
disklabel: ioctl DIOCGDINFO Inappropriate ioctl for device
> | /dev/rwd0e: NOT LABELED AS A EXT2 FILE SYSTEM (4.2BSD)
> It also verifies that the disklabel references it as an ext2 filesystem.
taking this into account although we're now talking about GPT/wedges.
when looking at `dmesg | grep ^dk` I see both wedges but with
type: <unknown>
although it should be dk0 type `bios` and dk1 type `linux-data`
I've tried to fix this manually with `gpt type -T linux-data -i 2 wd0` and
`dkctl wd0 makewedges` in vain. The former returns fine but no change happens,
while the latter only reports about removing/adding dk0, not dk1.
I did not re-check how the types are with the successful freebsd install PoC
with GPT and UFS2. fsck_ffs is not complaining at boot time.
--
Pierre-Philipp Braun
SNE Russia https://os3.su/
