"Too many primary partitions" error on attempted dual-boot install

thomasafine · 2024-08-27 07:44:48

Hi,

I have an old Dell Mini 10v netbook with a Snow Leopard hackintosh install on it. This system as it works now use GUID partitioning, but boots from a legacy MBR block, which fires up the Chameleon bootloader, which starts OSX via the UEFI booting it was actually designed for.

Chameleon is also able to detect other bootable partitions on the same or different disks and offer me to boot them too, which I'm counting on to manage the actual dual booting.

Note that I've tried a live thumbdrive run of bunsenlabs on this hardware and everything worked perfectly (Screen, keyboard, trackpad, sound, USB ports, ethernet port, Wifi, didn't test bluetooth).

Instructions I've found on the web say that I can install Linux alongside this. My understanding is that you use grub-install to create a VBR instead of an MBR, and Chameleon can see this as a bootable partition, and will offer it as a choice, and if selected, will run the grub from the VBR. So the instructions are to install Snow Leopard first (which is great because it's already installed), and then install Linux (Ubuntu actually is what the instructions were for in this ten-year-old posting). In theory I can either make sure to skip installing grub on the MBR and manually add it to the later partition, or I can let the install wipe out the MBR and then fix it all later.

Which is all well and good, but the bunsenlabs install seems to be noticing the MBR, and not noticing that aside from that the disk is actually GUID partitioned. So I think I'm getting this error because it wants to do old school partitioning, but all but one of the four available partition slots in the MBR are already taken up. (The MBR plus an extra 38 blocks of type 0xEE that contains the startup part of the chameleon bootloader; an EFI partition; the OSX partition; and also one empty slot in the MBR partition table which is apparently insufficient for Linux needs. I get an error about "Too many primary partitions" When I go back and look at the partition table it wants to use, it's got:
• 3.1KB free space (which is the MBR+39 blocks for Chameleon bootloader)
• 209.7MG EFI partition (used by OSX for its more conventional "modern" UEFI booting)
• 90.3GB HFS+ partition for OSX
• 106.5kb free space (I guess to pad things out so Linux starts on some nice boundary?)
• 1.0MB biosgrub
• 69.6GB ext4 partition for bunsenlabs
• 96GB free space (which I don't understand at all, I wanted the whole rest of the disk for bunsenlabs)

So how do I make this install use the GUID partitioning, and ignore the MBR entirely? Or have I misunderstood what is going wrong here? And how do I manually make it use the entire free space, not just 69G?

There's no giant risk here because the disk I'm using is an SSD copy of the original hard drive from the netbook, and I can always recopy from original if I screw it up. But I'd prefer to not screw it up.

Zepher · 2024-08-27 23:40:07

As far as I know (and please wait for a far more knowledgeable member) In your current configuration, Linux only allows four(4) primary partitions... Period. Again (AFAIK) you're in an addition by subtraction kind of situation.

PackRat · 2024-08-28 00:53:17

This is a legacy BIOS system, but you put a GPT partition scheme on the harddrive?

Did you create these?

• 106.5kb free space (I guess to pad things out so Linux starts on some nice boundary?)
• 1.0MB biosgrub
• 69.6GB ext4 partition for bunsenlabs
• 96GB free space (which I don't understand at all, I wanted the whole rest of the disk for bunsenlabs)

If you can delete those from Snow Leopard and then create one partition out of all the free space, I think it will work.

You have a link to this article?

So the instructions are to install Snow Leopard first (which is great because it's already installed), and then install Linux (Ubuntu actually is what the instructions were for in this ten-year-old posting).

Bearded_Blunder · 2024-08-28 01:12:16

Unless I'm mistaken, the machine itself uses BIOS rather than UEFI & the fancy bootloader fools MacOS into thinking it's UEFI.
The disk will be GPT/GUID with a "protective" MBR.
Pretty much any OS installer you fire up is likely to boot in BIOS mode & be unable (incapable) of handling anything other than MBR automatically as a result, so the MBR is what it'll see & report.

Now there may be some workaround, & there may be clues to it in the instructions you said you're following, unfortunately you haven't linked those instructions, so nobody can look at them.

The bootloader itself you're using for the hackintosh is abandonware, I don't know if (when booting another OS) it does so also in emulated UEFI, or in native BIOS mode.

MBR allows 4 primary partitions (or 3 + one extended partition, in which multiple logical volumes can be created).

If you boot the live session, how does that see the disk? What does Gparted tell you about it? Can Gparted configure the disk to the layout you want from the live session?

The good news is Linux can handle a GPT boot disk on a BIOS system (unlike Windows), I'm not certain Debian Installer can though, which is what Bunsenlabs uses.

With an odd setup like that you may even have to resort to a manual (hands on command line) debootstrap install from the live session, rather than using the installer, assuming the live session sees the disk correctly & you can configure it how you need. Bear in mind you'll probably want a swap partition in addition to just an ext one for /

Last edited by Bearded_Blunder (2024-08-28 01:41:07)

thomasafine · 2024-08-28 03:02:11

PackRat wrote:

This is a legacy BIOS system, but you put a GPT partition scheme on the harddrive?

The native partitioning scheme was GPT. As part of the hackintosh process, I had to enable legacy BIOS booting. It does seem odd, given that Snow Leopard also used UEFI booting, but I suspect that this was a process that had been developed over time and it was the easiest way (then) to adapt the process to newer hardware. I think the Chameleon used for this particular netbook also did some funky kernel patching right before or during the Snow Leopard boot. Maybe this order somehow made it easier to patch the kernel during the boot.

Did you create these?

The partitions you quoted from my post are the additional partitions that the bunsenlabs installer wanted to create before the error. I assume. Because they were listed after the error, when I went back to one of the partitioning screens. It's perhaps useful info if I have to do some of this by hand.

If you can delete those from Snow Leopard and then create one partition out of all the free space, I think it will work.

This would destroy the existing Snow Leopard installation/booting that I want to keep.

You have a link to this article?

I'm apparently not allowed to post links. But it is at fabienne.us and the URL path is /2010/11/27/installing-dual-boot-os-x-and-ubuntu-on-a-dell-mini-10v/
But be warned some of the links there to sub-instructions are dead, and I had to go to archive.org to find them.

thomasafine · 2024-08-28 03:15:27

Bearded_Blunder wrote:

Unless I'm mistaken, the machine itself uses BIOS rather than UEFI & the fancy bootloader fools MacOS into thinking it's UEFI.

I think it's a little more complicated than that, as the machine by default does use UEFI, and had to be told to use legacy BIOS booting for the original hackintosh install.

With an odd setup like that you may even have to resort to a manual (hands on command line) debootstrap install from the live session, rather than using the installer, assuming the live session sees the disk correctly & you can configure it how you need. Bear in mind you'll probably want a swap partition in addition to just an ext one for /

Yeah at this point I'm just looking for good instructions to hand-install bunsenlabs ore debian generally. I think with the right tools I get get the disk partitioned the way it needs to be, and then see if I'm right that Chameleon will just recognize it and let me choose between Snow Leopard and Linux.

And yes, with only a gig of ram, I think a swap partition is probably a very good idea. It'll be on an SSD so it won't be quite as terrible as a spinning disk.

Bearded_Blunder · 2024-08-28 11:45:14

thomasafine wrote:

Bearded_Blunder wrote:
Unless I'm mistaken, the machine itself uses BIOS rather than UEFI & the fancy bootloader fools MacOS into thinking it's UEFI.
I think it's a little more complicated than that, as the machine by default does use UEFI, and had to be told to use legacy BIOS booting for the original hackintosh install.

Setting a UEFI system in CSM / BIOS mode has the same effect. The machine is now using BIOS.

Yeah at this point I'm just looking for good instructions to hand-install bunsenlabs ore debian generally. I think with the right tools I get get the disk partitioned the way it needs to be, and then see if I'm right that Chameleon will just recognize it and let me choose between Snow Leopard and Linux.

@Head_on_a_Stick wrote such a guide on here a long time ago for Installing Bunsenlabs Helium-Dev, obviously it's out of date & will need adapting to suit Bookworm/Boron. Important little details like the fact nonfree-firmware is now a separate component.

It can be done from the live session, which is part of why I asked if that saw the disk correctly, & the live session also has Gparted included, which gives you (hopefully) "the right tools" for sorting the partitioning, with a handy GUI to aid configuring the disk.

Debian also have generic instructions for installing using debootstrap, which HoaS adapted an older version of for his guide, the current Debian version of those instructions can be found here they assume some sort of running Linux system to install from for which the Bunsen live session will do, after which you could either run @johnraff's excellent netinstall script, or manually add the bunsen repos & install the metabackage.

I'm apparently not allowed to post links.

Ah yes, new member & not enough posts yet (I think the minimum is 5), an anti-spam measure to stop bots joining & instantly posting links to gawd knows what nonsense, advertising, & scams. Unfortunately it does sometimes interfere when people join to ask for help.

thomasafine · 2024-09-09 12:02:28

Success.

I didn't have to use the manual install instructions. I did need to manually partition the disk myself with gparted, while booted from usb live. I created a swap and a root partition, and formatted the root partition as ext4. I set the mount path for the root partition to /, not sure if that was an essential step or not. Once I had the appropriate Linux partitions set up for installation, the regular thumbdrive install process worked fine.

I did have to install grub to the partition boot record of the disk partition where linux was installed. Using chroot from the usb live system. You have to use force to do that, e.g. "grub-install /dev/sda4 --force", and there were lots of warnings about the disk devices not existing, but it ended up working. And then "update-grub". After that (and a VERY deep rabbit hole on getting Chameleon to see the Linux partition), it booted from the Chameleon menu.

There were some wrong directions I followed. I thought maybe I had to use grub-legacy, but I didn't. It wouldn't understand a GPT system anyway. And one source said that ext4 was a problem as the old Chameleon couldn't boot ext4 Linux. That turned out to be false (ish). But in the meantime I did create a separate /boot that was ext3, but I didn't end up using it at all.

The most serious problem, the deep rabbit hole, which is probably less relevant on this forum, is that Chameleon wouldn't recognize the Linux partition, because it was just very old code. Chameleon was using two criteria to identify Linux partitions, one was the ext2 filesystem magic number, which it turns out is identical to ext3 and ext4. But the other is the GPT GUID partition ID, and I guess it expected Linux to be installed in a partition labelled with a Windows GUID partition ID. I ended up hacking the Chameleon binary (/boot in the HFS+ filesystem) and replacing the Windows GUID parittion ID (which I don't need because I'm not booting Windows) with the Linux filesystem data GUID partition ID, after which Chameleon could see the Linux partition.

It was all quite an adventure.

#1 2024-08-27 07:44:48

"Too many primary partitions" error on attempted dual-boot install

#2 2024-08-27 23:40:07

Re: "Too many primary partitions" error on attempted dual-boot install

#3 2024-08-28 00:53:17

Re: "Too many primary partitions" error on attempted dual-boot install

#4 2024-08-28 01:12:16

Re: "Too many primary partitions" error on attempted dual-boot install

#5 2024-08-28 03:02:11

Re: "Too many primary partitions" error on attempted dual-boot install

#6 2024-08-28 03:15:27

Re: "Too many primary partitions" error on attempted dual-boot install

#7 2024-08-28 11:45:14

Re: "Too many primary partitions" error on attempted dual-boot install

#8 2024-09-09 12:02:28

Re: "Too many primary partitions" error on attempted dual-boot install

Board footer