OpenBSD, FreeBSD and NetBSD use another primary to allocate sub-partitions in it which are then recognized by Linux and assigned partition numbers which start after the number of the first extended partition. On the system where I have tested the Mageia 6 installer the last logical partition was /dev/sda7 within the extended partition sda3 while the BSD partitions out of primary sda2 started with sda8 (afaik). Now the Mageia installer gets irritated when it sees that Linux allocates more than 7 partitions. It claims that the partition table would be corrupt and wants to delete all data (yes) or at least 'fix' the issue (no) which would likely destroy my OpenBSD installation equally. It does not even offer a secure reboot option to exit the installer. My request would be to make th Mageia installer BSD-safe (I`d guess it would just need to ignore the partition count or any partitions beyond the last logical partition.). Some time ago I have been working successfully to let the Mageia installer recognize and boot OpenBSD; however this was when I installed OpenBSD after installing Mageia.
Created attachment 8382 [details] screenshot
Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx
Please try again the installer up to that error, and then: - plug a USB key - go to tty2 (alt+ctrl+F2) - run the "bug" command - attach (not paste) the report.bug file you'll find on the USB key here
Source RPM: drakx => drakx-installer-stage2Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
Created attachment 8384 [details] report.bug Unfortunately the undertaking of plugging an USB stick did not lead to success, neither on a current Mageia 5 nor on Mageia 6 sta1 though I remember this to have worked before. Possibly newer Linux kernels have a problem with the USB 1.1 support of that computer (PIV 3Ghz, 2GB RAM). Luckily the existing OpenBSD installation did in this case come to the rescue ...
You tested with a somewhat older cauldron but that doesn't matter here (drakx v17.46 vs 17.55). Humm, we only support full disk disklabels (this was added for supporting sparc workstations in the old days). We don't support yet disklabels nested in a MBR partition. It should work on GPT partitions as we rely on libparted there. I guess MBR embedded disklabels will be supported when we switched MBR to using libparted too
I doubt that OpenBSD would install into a GPT drive; up to now that was not possible. What else do you use for MBR/msdos-disklabels?
(In reply to Thierry Vignaud from comment #4) > You tested with a somewhat older cauldron but that doesn't matter here > (drakx v17.46 vs 17.55). > > Humm, we only support full disk disklabels (this was added for supporting > sparc workstations in the old days). > We don't support yet disklabels nested in a MBR partition. > > It should work on GPT partitions as we rely on libparted there. > I guess MBR embedded disklabels will be supported when we switched MBR to > using libparted too CC'ing pterjan, because he isn't a member of the mageiatools ml (yet).
Source RPM: drakx-installer-stage2 => drakx-installer-stage2, drakxtoolsKeywords: NEEDINFO => (none)CC: (none) => marja11, pterjan
CC: (none) => mageia