Solved Needed UUID in /etc/fstab but old hardware non-UEFI + many MBR partitions

I'm upgrading my machine by parts. Yesterday, I plugged its first SSD and now I have it along with to other SATA Hard Disks.

Problem: FreeBSD has now three choices to number the disk which has it installed.

Looking for /dev/ada1s1a in order to boot, it didn't exist and I fell into manual boot. ufs:/dev/ada0s1a. No luck. As the only remaining option was ufs:/dev/ada2s1a it worked, but soon to fall back on single-user mode for me to fsck broken stuff I presume broken by such confusion.

Everything back on pieces, reboot... into Ubuntu, so I can find it manually with GRUB but once started, wanted to chance absolute paths to UUIDs. Otherwise I'd have to GRUB Shell everytime just to ls and see which hd has 7 or 8 partitions (for it has Ubuntu installed in the same disk and BSD labels and slices are listed as partitions).

Yet worse: suppose I do get the right number with GRUB Shell, how to feed BSD boot process with it? It must be from the inside (after chainloading) but before reaching the mount root part, which will always look for /dev/ada1s1a which worked fine with only two disks, but adding a third one already messed up and I feel it to become quite frequent unless I use UUID or something alike.

Problem is: I have all these partitions and OSes already there... under MBR scheme not to be easily converted to GPT so to use gptid. Furthermore, old motherboard is BIOS-only, which is wisely known as problematic when combined with GPT partitioning.

What can I do?
 
What can I do?
You can label the disks, and set the label name in /etc/fstab, see handbook 18.7. Labeling Disk Devices, Example 18.1. Labeling Partitions on the Boot Disk . You can choose any name for the labels.

Problem is: I have all these partitions and OSes already there... under MBR scheme not to be easily converted to GPT so to use gptid.

For UFS there are ufsid's. Information in the above mentioned handbook chapter.

Furthermore, old motherboard is BIOS-only, which is wisely known as problematic when combined with GPT partitioning.

Where did you get that information? I have a old ( 2011, BIOS only ) machine, using exclusively GPT partition schemes from the beginning.
 
Thanks. The swap is "Type Linux"/"ext4" (partition ID = 0x8300) but removing it from /etc/fstab and swapon once logged in is enough a workaround for me. It has no fs too. Not a problem at all.

Where did you get that information? I have a old ( 2011, BIOS only ) machine, using exclusively GPT partition schemes from the beginning.
Why, mine is exactly 2011 too. February 2011. AMD Phenom II X4 925. I've read plenty of stuff regarding such issues, mostly related to overwriting thus corrupting GPT tables with bootloaders or so.

Whatever the case, it's probably in the past now. The closer to a BIOS nowadays is UEFI's CSM i.e. Legacy Mode. And even if there were mobos "UEFI-less", old-styled BIOS only, they would probably had come to terms with GPT and these early issues.

Anyway, thanks again for the help. I have yet to try it but mark the thread as solved.
 
Back
Top