12.2 hangs, invalid disklabel, but from non-freebds partition?!

M

MySweetAvatar

MBR disk, 1TB, 4 apx equal partitions, at cyl boundaries coincident with 8k (16 sector) blocks
Grub 2 boot

slice 1: new freebsd 12.2 installation (partition id 165, 0xA5)
slice 2: new openbsd 6.x installation (partition id 166, 0xA6)
slice 4: new Linux with grub2 boot

Booting from the USB stick with FreeBSD 12.2 amd64 installer,
mount /dev/da0s1a /mnt
fails with diag
GEOM: diskid/DISK-...15*hexdigits...s2: invalid disklabel

From that "s2", I suspect it's complaining about the OpenBSD label on the 2nd partition.
? Advice?

Installer "disklabel" is happy to read or write da0s1 label.
installer "newfs -N" is happy to report fs parameters for the a, d - h FSs defined in
the disklabel.
installer "fsck /dev/da0s1a" reports CANNOT READ BLK: 487251392
and then gives the same GEOM diag, above, on exit;
but "dd" is happy to read or write that block, and adjacent blocks.

Boot via grub2 just hangs, at the initial "-" char (tried both the
chainboot and kfreebsd kernel boot options)

The installer was happy to create the 4.2bsd filesystems, and got to the end of install,
but it also gave an "invalid disklabel" diag.

Installer "disklabel" is also happy to read da0s2 (OpenBSD) disklabel, but is
confused with what it finds.

For da0s1 (FreeBSD), we have disklabel

# /dev/da0s1:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 16777216 0 4.2BSD 4096 32768 0
b: 16777216 16777216 swap
c: 488118960 0 unused 0 0 # "raw" part, don't edit
d: 16777216 33554432 4.2BSD 4096 32768 0
e: 16777216 50331648 4.2BSD 4096 32768 0
f: 67108864 67108864 4.2BSD 4096 32768 0
g: 67108864 134217728 4.2BSD 4096 32768 0
h: 286792368 201326592 4.2BSD 4096 32768 0

(Fragment size and block size were originally 0; I edited those to
match the params newfs -N showed, but same diag's and behaviour,
before and after.)

grub2 boot of OpenBSD is fine, with both chainboot and kernel boot methods.
 
Wild guess - other OS installation overwrote the MBR and possible even more blocks (grub) ? I'd go with s1 to be grub partition (~2gb), and then do the FreeBSD, OpenBSD, Linux. I'd be careful not to let installer touch the MBR. Most likely you can chainload BSDs and natively boot Linux.
 
I disabled the OpenBSD (s2) partition, setting id to 0.

The GEOM diagnostic disappears (from mount and fsck, using
installer USB stick).

GEOM really was complaining about a subsequent partition, one with
a non-freebsd partition id.

I'm currently re-installing FreeBSD, with the OpenBSD partition hidden.

(_martin, thanks for suggestions. The MBR is fine. There are 16 spare cylinders
before s1, so I don't yet suspect bootcode overwriting things)
MySweetAvatar said:
Booting from the USB stick with FreeBSD 12.2 amd64 installer,
mount /dev/da0s1a /mnt
fails with diag
GEOM: diskid/DISK-...15*hexdigits...s2: invalid disklabel

From that "s2", I suspect it's complaining about the OpenBSD label on the 2nd partition.
? Advice?
Click to expand...
 
Maybe running different BSDs on the same machine is a bad idea. They share too many in commons but also diverted heavily. This all created incompatibility. To save yourself from the headache, perhaps remove either FreeBSD or OpenBSD your choice but only keep just one of them.
 
Just our of curiosity I did this in my VM. I did the installation in this order: FreeBSD, OpenBSD, Debian. Partition as seen from Linux:

Code: 
Device     Boot     Start       End  Sectors  Size Id Type
/dev/sda1  *         2048   4196351  4194304    2G 83 Linux
/dev/sda2         4196352  88082431 83886080   40G a5 FreeBSD
/dev/sda3        88082432 109053951 20971520   10G a6 OpenBSD
/dev/sda4       109053952 187179007 78125056 37.3G 83 Linux
Where sda1 is /boot for Linux. I edited the grub config in /etc/grub.d/40_custom:
Code: 
menuentry FreeBSD {
    set root=(hd0,msdos2)
    chainloader (hd0,2)+1
}

menuentry OpenBSD {
    set root=(hd0,msdos3)
    chainloader (hd0,3)+1
}
Grub was installed on sector 0 as I wanted grub to be the main bootloader.

FreeBSD is complaining about invalid bsdlabel on OpenBSD partition:
Code: 
GEOM: ada0s3: invalid disklabel.
GEOM: diskid/DISK-00000000000000000001s3: invalid disklabel.
but no harm is done.
For comparison view from FreeBSD:
Code: 
root@multi:~ # gpart show
=>        63  1048575937  ada0  MBR  (500G)
          63        1985        - free -  (993K)
        2048     4194304     1  linux-data  [active]  (2.0G)
     4196352    83886080     2  freebsd  (40G)
    88082432    20971520     3  !166  (10G)
   109053952    78125056     4  linux-data  (37G)
   187179008   861396992        - free -  (411G)

EDIT: I forgot to mention I did manual partitioning in FreeBSD. I added first two partitions. I then bsdlabel the slice 2 manually (it has been some time since I did that!) and installed FreeBSD. I manually created the partition 3 in OpenBSD with the autocreation of "partitions" under slice3.
 
_martin said:
FreeBSD is complaining about invalid bsdlabel on OpenBSD partition:
Code: 
GEOM: ada0s3: invalid disklabel.
GEOM: diskid/DISK-00000000000000000001s3: invalid disklabel.
but no harm is done.
Click to expand...
When did that diag appear? During boot? In response to some command?

In contrast, I had installed OpenBSD before FreeBSD. The GEOM error also cropped up
during FreeBSD installation, and I believe the install process is corrupted... the
installer notes a failure and prompts for explicit no/yes whether to continue.

When I repeat install this week, I'll save the RAM-fs /tmp/install_log (or whatever its called).

I'm interested to test partition order, and partition adjacency/non-adjacency.

I am still surprised that FreeBSD scans a non-0xA5 partition and expects to see
a FreeBSD dialect disklabel.

Edit: Install of FreeBSD succeeds with OpenBSD partition hidden.
 
I would suggest using GPT instead of MBR. All recent and quite some older PCs should be able to handle it just fine. There's just no reason to stick to that ancient partitioning scheme any more.
 
MySweetAvatar During the FreeBSD boot. I'm assuming geom provider is scanning it and something doesn't add up there. But as that slice was created by native OpenBSD's installer I'm assuming this is expected behavior. No errors were reported on OpenBSD.
I still suggest to have grub's partition as a first one. My 2c.
Yes, I'd too would use GPT scheme but as OP was using MBR I used that one.
 
Thanks, SirDice and _martin .

one platform doesnt support GPT in BIOS (HP Compaq 6730B, circa 2008).

I'm reserving the 4th partition for another OS.

So, is MBR support in FreeBSD unmaintained?

I regret only being able to install in the first partition, and the GEOM errors
make it impossible to install without hiding OpenBSD.

For reference, partition order and adjacency do not affect the GEOM
error.

I am not convinced that the default installer works at all for an MBR, even
on the first partition... it seems to require a disklabel to have been already
left over... if I zero the start of partition, it seems impossible to create
a, b, d in bsdinstall partedit.

(The HP 6730B was their first try at GPT support, but implemented as an
off-ROM kludge, the BIOS is redirected to a binary blob on the hard disk in
a Windows boot partition)
 
It's fully supported, works just fine on all OS versions you've mentioned. It's an old one with its limitations, that's it.

That was my point of demo I did above -- you don't need to hide anything. Everything works just fine. I did suggest you to put grub on the first partition to make sure you have grub managing all the boots. Grub may require some additional sectors after sector 0, it's good to keep some padding there (I left 2048 sectors).
Make sure no other installer touches MBR (if it does you could boot rescue linux and fix that). I also let each OS create its own partition (except grub partition that I created in FreeBSD).
Grub would be my choice of bootloader because frankly I think it's one of the best there is. It's very versatile and I can navigate around with it. It could very well be FreBSD's bootloader can handle this too. I actually don't know, last time I had multiboot on my FreeBSD it was 15-17y ears ago.

Side note: you kept referring to offsets in CHS .. of course those numbers are bogus and this form can't quite address disks nowadays (hell, it had problems in 90s). Make sure you slice all using LBA offsets and that they don't overlap. Different OSes could possibly handle these bogus CHS values on its own.
 
You must log in or register to reply here.
Back
Top