This is just a question about manually partitioning gpt disk with legacy boot. Recently Ubuntu released 20.10 and I usually partition on my test machine mbr. But due to a bug in their installer you cannot create a disk mbr. They automatically partitioned it gpt with three partitions. One is bios-boot unformatted, one EFI fat32, and the balance ext 4 root.
I wanted to see how Manjaro does it compared to Ubuntu. I usually just use mbr. So I created an 8 mb partition as recommended unformatted bios-grub. No EFI partition was indicated, so the balance is
ext4 root.
Boots just fine and works perfectly.
But I noticed the unformatted went to ext4 when I checked it with gparted. The next time I deleted all the partitions using gparted on a live usb.
It did the same thing again. Like I wrote above it boots fine just wondering why it does not stay unformatted as created during the install?
Create the mbr parted disk upfront (e.g. by GParted) incl. your / partition etc. and use the manual partitioning step where you just assign existing (prepared) partitions. Make sure bootloader goes to mbr then.
Thanks for the reply. I understand why the bios-grub partition is needed for GPT partitioning. My question is about the prompt in calamares. It’s quite clear about the bios-grub partition being unformatted. Then formats it ext4 when finished. As I mentioned Ubuntu leaves it unformatted as intended. Calamares formats it ext4 when finished. That makes no sense to me.
Previously on this same disk I was testing Garuda KDE. It partitioned the disk MBR and formatted it btrfs. I had some issues with it not related to this post and decided to check out how Manjaro handles the GPT and legacy boot.
That time the bios-grub partition was set up the same. Unformatted. When I booted for the first time and took a look, that partition was btrfs. So it appeared that selecting unformatted is kind of a passive not active selection. It just left whatever was there previously. The root partition overwrote the btrfs with ext4 as I expected.
From an operational standpoint it doesn’t seem to matter, the system boots just fine legacy and with a GPT disk.
It just seems odd that calamares would behave in this manner.
There’s certainly no harm in creating biosgrub and efi partitions in case you decide to convert the OS to UEFI-boot mode later on. It’s what I do … actually I have separate /boot, /home and swap partitions too but this is entirely up to you.
Having separate /home might make it easier if you reinstall & want to keep your settings intact. I always use GPT now, whether it’s for a legacy or UEFI system. No issues so far.
I’ve got two computers and three monitors. The Asus Z77 has 7 SSD’s in it. One with Debian Buster, a couple of Manjaro’s, Linux Mint, Ubuntu 20.04 and Kubuntu 20.10. That’s the test machine. It has a UEFI issue or bug in the firmware that I discovered when switching to Linux Distros 2 years ago as Win7 went EOL. There are no more bios updates available from Asus.
The bug is if I install any Linux distribution UEFI it will boot fine unless I switch cables to another SSD, If I try to boot the MB will not even recognize the drive is present. Which makes testing different distributions impossible. I called the distributor who sold me the MB and ask about it and he told me it was quite common for Asus MB in 2013.
What I’ve discovered is there are certain combinations of Linux Distros and DE that do not work will on this machine with an Nvidia GPU. Even different flavors of Ubuntu don’t work well. Linux Mint was one of them. It was only recently I revisited the Nvidia problem and stumbled on a post that the fallback driver may be the problem. I uninstalled it. Been running well ever since. But I have no idea what the root cause is at this point. I’ve not had any issues with manjaro and different DE. Well, one. Deepin. It worked fine until the upgrade to 18. Video issues again.
The other machine is an Intel Nuc and it boots UEFI. Both machines sharing one KB and Mouse via Barrier. A third machine, another Nuc is in the family room that my wife uses. It boots UEFI as well. I’ve had the M.2 drives out of them before and its not been an issue.
I’ve got a Synology NAS where I store all our documents so nothing gets stored on the test machine disks that is not on the NAS.
With the manjaro test that I did yesterday, I tried to manually duplicate what Ubuntu did for 20.10. One bios-boot partition unformatted, an ESP partition Fat32 and the root ext4 with GPT. I was surprised to find no option for the ESP or EFI partition in the pull down menu. At that juncture I fully expected to see some sort of warning or fail to boot with only the bios-boot and root ext4 GPT partition. But it booted fine. Then I discovered the bios-boot did not remain unformatted and apparently it doesn’t matter. Not sure why ubuntu requires three partitions to work and manjaro does not.
There won’t be any option for an efi partition for legacy boot in the installer when booted in legacy mode, as far as I know. This partition will be left unused; I only create one for future-proofing reasons on legacy installs.
It doesn’t. It’s probably because the installer has had some legacy stuff removed. I’d guess that the efi partition doesn’t contain anything on that installation. It shouldn’t matter in any case.
I’m on Ubuntu 20.10 right now. I just did an update. sda1 bios_grub 1 Mb, sda2 fat32 boot/efi, sda3 root ext4. There were updates to the efi partition. I checked and its not empty. About 9 Mb. So they’re doing something different than Manjaro. Would be nice if someone wrote a nice description on what they’re doing. But I’m not hopeful because its been months for the partitioning bug and no one’s working on it.
Guess my next experiment will be to use my one undedicated SSD’s install 20.10 on it and see if it boots without the EFI partition.
I’d be interested to know what Ubuntu’s installer put in that efi partition. Perhaps it used that as the bios_grub instead? Not sure, but last Manjaro system I installed in legacy mode + GPT, I can not remember giving it a biosgrub partitin (didn’t know about this at the time) & it worked fine. Maybe the installer added one. This is with manual partitioning.
I’ll need to check what partitions are actually on that machine’s HDD (my housemate has it. I can check via SSH next time he’s using it).
Just after I posted this I decided to look at my NUC that is EFI boot. The EFI partition is exactly the same size as the legacy boot with bios-grub. I’ll do some digging tomorrow to see if anyone on Ubuntu forums knows about how this works. Obviously Manjaro took a different approach. Similar but not the same.
I took an hour and couldn’t find anything further on ubuntu relative to legacy boot and gpt.
So I did a manual install using and 8 Mb partition for bios-grub and a root partition.
Message appeared that grub install failed. Then installer crashed.
Then created the third EFI partition and it worked. Then the installer crashed but it booted just fine on restart.
So at this juncture I have no idea whether this is part of the installer bug or having three partitions is really intended for some reason. The only way to complete the install without any errors at all is to let ubuntu do the partitioning.
To finish the comparison of Manjaro and Ubuntu.
Manjaro only needs a bios-grub partition to implement GPT for legacy boot.
Ubuntu needs bios-grub, EFI, and the root partition to work.
One last thing. The bios-grub partition needs to be unformatted from everything I’ve read. But it does seem to work if its ext4 or btrfs. Selecting unformatted in the Manjaro installer is only passive. Whatever file system was there before will remain. Same thing for gparted. The only way I’ve found to keep that partition without a filesystem is to clear it using gparted. Then at completion it indicates unknown.
No. The respective installers did that during the partitioning process. In both cases, Ubuntu 20.10 and Manjaro Gnome, I only used their installers. In both cases they work fine but take different approaches. I’ve seen the reference to the numbers. But this only applies to gdisk 0xEF02 and other programs that require the GUID to be set directly.
The question came up yesterday from BR405 about the Ubuntu EFI being empty when used with GPT and legacy boot. I checked and they’re the same size 8.81 Mb out of 512 Mb with UEFI or Bios boot.
That’s why today I wanted to test whether Ubuntu would boot with it configured like Manjaro. One bios-grub partition and root. The result was Ubuntu couldn’t install grub.
Ubuntu configured with bios-grub, EFI, and root booted fine.
This all came up because there is a known bug, for months now, in the Ubuntu installer regarding legacy boot. A user can not partition MBR for legacy boot on version 20.10. Last I looked only five people have reported the bug. I suspect most users just let the installer partition automatically and other users may have newer hardware and boot UEFI only. No one is assigned to look into it. Not much I can do about it.
I have a couple of Manjaro distributions, Gnome and Cinnamon, on my test machine on separate disks. Two Ubuntu versions 20.04 with no such problem and 20.10. One Debian Buster. One Linux Mint. They are all legacy boot because UEFI on my system will not allow me to switch cables to another disk. If I go back to the original UEFI disk it is not recognized by the system because of a bug in the firmware. No updates available from Asus.
