Manual Partition with encrypted root

Support
1

I’m having a hard time installing Manjaro KDE 25.0 manual partition on this old computer. I can install it via the installer with no problem, and the systems boots fine, but I can’t make it boot though manually setting up the partitions. Obviously I’m missing a step with the new plasma system!

This is an old Dell OptiPlex 390 with two separate independent SSD hard drives with 8 Gib of Ram. I’m currently running the latest version of KDE Plasma v: 6.3.6 , Kernel: 6.12 on hard drive one.

I go to hard driver two, and I’m choosing manual partition. I don’t want to setup encryption for boot. Encryption is only set for root. I also know on the newer system I need to designate 10 MB FAT32 for boot, but this computer doesn’t have an efi system. The bios is legacy only, and the efi system is disabled. Therefore there are no mount point set up for /boot/efi.

This is how I’d installed Manjaro on this computer years ago, and they system works just fine.

**I’ve also tried both MBR and GPT

Size: 2800 MIB
File System: EXT4
Mount Point: /boot
Flags: boot**

**Size: 10 MB

File System: Unformatted
FS Label: bios-grub**
Flags: bios-grub

Size: 23664 MB
File System: EXT4
ENCRYPT
Mount Point: /
FS Label: root
Flags: root

I’ve tried several different combinations and I can’t make it to boot. This is more of a challenge and curiosity as to what am I doing wrong?

2

10 MB for /boot is way too little - give it at least ~500 MB

This is where the kernel and the initrd’s are stored which will take up way more than 10 MB

No need to worry about /boot/efi or anything about EFI if your system is BIOS only.
Just go with MBR instead of GPT if you only have two partitions anyway.

On reading again what you wrote:

your /boot partition is actually oversized

one fifth of that would be around 500 MB and plenty

You don’t need that 10 MB unformatted partition if your system is going to be BIOS only anyway

3

Well, that depends, although it doesn’t have to be 10 MiB.

If the system boots in legacy BIOS mode but the boot drive has a GPT layout, then you do need an unformatted partition of roughly 2 MiB for the core.img stage of grub. If on the other hand the partition layout is MS-DOS/MBR, then you don’t need it.

Only if you’re going to install one kernel. With two kernels and both the regular initramfs and the fallback initramfs for each, you quickly run into a storage deficit.

For newbies who want to use a separate /boot partition, 1 GiB is a safer choice. :wink:

3 Likes
4

I tried both GPT, and MBR method and designated 1000 MB unformatted to bios-grub, but it’s still not booting. I usually install two kernel (one for back up), and that’s why I gave boot 2800 MB. I remember one time there was an update on boot, and I wasn’t able to update, because I didn’t have enough space in boot. That’s why I usually give it enough space for boot. So what am I doing wrong here?

partitions

5

That’s about 995 MiB too much. :wink:

6

Are you saying 5 MiB is enough? If not what’s the right size for unfromatted?
Also should I used GPT, or MBR?

7

Actually, 2 MiB would already be enough, as I wrote higher up already. It only needs to hold the core.img of grub, and nothing else.

If your boot drive is larger than 2 TiB, then you need GPT. If it’s smaller, then you can choose either GPT or MBR. GPT is however more robust than MBR, and offers more possibilities.

In the event of MBR however, you don’t need the bios_grub partition, because then both the boot.img and core.img of grub will fit in the master boot record of the drive.

1 Like
8

Good news and bad news. I accidentally wiped out my good hard drive by mistake! :cry:
The good news it works now. I used MBR and 1800 MiB designated to boot. I’d like to have enough space for two LTS kernels. Was too much space designated to boot was causing the system not to boot?
What is the maximum space you should designate to boot to support several kernels?

boot-mbr
boot-mbr830×205 21.8 KB

I’m using 13%, so I guess 1.69 Gib is plenty to support several kernels.
boot size: 1.69 GiB used: 221.4 MiB (12.8%) fs: ext4 dev: /dev/sda1

9

No, that could not have been it. What may have happened — we don’t know whether it was MBR or GPT — was that you hadn’t set the boot flag on the bios_grub partition, in which case grub would have overwritten the boundary of the first partition.

Most people will incorporate /boot into the root filesystem itself and not bother with a separate /boot, but 1 GiB should be enough for a couple of kernels and their initramfs images, including the fallback images.

10

Thanks a lot. Now I have to install on two hard drives, but luckily it’s not my every day computer.

1 Like
11

Just keep the basics in mind… If the drive from which the computer boots is 2 TiB or larger, use GPT, create an unformatted bios_grub partition of about 2 MiB, and make sure it has the boot flag set. :wink:

12

You mentioned GPT more robust than MBR, so why not just sticking with GPT only? Also isn’t brtfs more advanced than EXT4? The default is brtfs when you try to install it manually.

13

The thing is that not all legacy BIOS versions can work with GPT, just as not all UEFI implementations can work with MBR. Therefore, the recommendation is “if the machine boots in UEFI mode, use GPT, and if it boots in legacy BIOS mode, use MBR.”

Yes, much more advanced. But it also comes with a bit of a learning curve. Everything is well-documented though.

Yes, the lead Manjaro developer chose to make btrfs the default as of Manjaro 25.0.

Technically there’s nothing wrong with that decision, but it happened quite suddenly, without any internal discussion, and as it turns out, it may not have been the best decision with the newbies in mind.

2 Likes
14

Something strange! I just tried to setup the hard drive that I wiped out by accident. I used the exact same setup as the previous hard drive. MBR, designated 1800 MiB to boot and the rest to root. The only thing different I used the btrfs instead of ext4, and it won’t boot. Is btrfs setup different than ext4?

15

Even more strange! I reformatted again, and chose the same set up.
MBR, ext4. Designated 1800 MiB to boot and the rest to root. Same as the other hard drive, but it won’t boot up!

boot-mbr2
boot-mbr2827×212 21.3 KB

Also, here’s how I have one of 4 main computers setup, and boots just fine. However, I don’t remember where that 2.49 MiB unallocated is coming from?

hd1
hd11180×290 41.9 KB

16

I am thinking you are mixing efi and mbr - those are like water and oil - they cannot mix.

Technically you have 3 options

  • BIOS/MBR (this option writes the loader at the MBR)
  • BIOS/GPT (this option requires a small 1MiB unformatted partition 0xEF02 - bios-boot or bios-grub flag)
  • EFI/GPT (this option requires a FAT32 formatted partition 0xEF00 - boot flag)

If you system boots in efi mode - you cannot boot from an mbr disk - you may be able to install - but no boot.

Some systems support BIOS / GPT and in such case you need a small unformatted partition of the type 0xEF02 - in the installer referred as the bios-boot flag.

The boot flag in the installer refers to EFI which is 0xEF00 and will therefore require a reasonable sized partition mounted /boot/efi

As you state

This should make it really simple to install - you don’t need to fiddle with manual parrtitioning. Simply select the disk and click install.

But then you add unencrypted boot and encrypted root.

  • Manual partitioning
  • Create new partition table (MBR or GPT) if you chose GPT make sure your firmware has support for it.

MBR

  • Create two partitions
    1. boot partition - enough size to hold kernels et.al. 512MiB is usually enough use ext4 for filesystem
    2. root partition - select the rest of disk and select ext4 - then tick the box encrypt - and enter your passphrase

When the partition table is MBR - select the target disk for grub.

GPT

If the system support BIOS/GPT you require 3 partitions

  • Create three partitions
    1. unformatted partition 1MiB to 32MiB (flag bios-boot or bios-grub)
    2. boot partition - as above
    3. root partition - as above

In the dropdown for bootloader select the target disk’s unformatted partition (if possible) otherwise select the target disk

That is all there is to it

EDIT: 2025-11-20T08:38:00Z

For the sake of clarity for myself I decided to test this using a virtual machine.

There is definitely something goofy with the installer in this scenario.

EDIT: 2025-11-20T09:49:00Z

After more digging - and log reading - (https://0x0.st/KOXd.txt) - I found that for a strange reason grub is not installed to /boot/grub nor is it installed to the mbr. The lines 935-943 in the log list

10:19:42 [6]: virtual void Calamares::JobThread::run()
    Starting job "grubcfg" ( 31 / 34 )
[PYTHON JOB]: Found gettext "en" in "/usr/share/locale/en"
10:19:43 [6]: virtual void Calamares::JobThread::run()
    Starting job "bootloader" ( 32 / 34 )
/usr/lib/calamares/modules/bootloader/main.py:392: SyntaxWarning: invalid escape sequence '\$'
  prefix, generator_name = re.match("(.*)\${([^}]*)}$", name).groups()
[PYTHON JOB]: Found gettext "en" in "/usr/share/locale/en"
WARNING: [PYTHON JOB]: "Non-EFI system, and no bootloader is set."

Later the the environment editor fails ( because the folder /boot/grub has not bee created )

    .. Running QList("grub-editenv", "-", "set", "menu_auto_hide=1", "boot_success=1")
    .. Target cmd: QList("grub-editenv", "-", "set", "menu_auto_hide=1", "boot_success=1") Exit code: 1 output:
grub-editenv: error: failed to get canonical path of `//boot/grub'.

I have yet to figure out why exactly this happens on an bios/mbr as well as bios/gpt systems.

To work around this strange behaviour one has to

  1. open the luks partition
  2. mount the /dev/mapper/<container> on /mnt
  3. mount the /dev/sdXy partition on /mnt/boot
  4. chroot into mnt
  5. run grub-install /dev/sdX
17

This is very strange! I reformatted the hard drive 2 using the MBR as you mentioned and success!

I reformatted the hard drive 1 again which I made to boot yesterday just for heck of it using the MBR method and it failed to boot. Then I used the GPT method as you mentioned and it failed again! Didn’t boot.

Then I tried GPT again without adding an unformatted partition and success. So hard drive 1 only boots with MBR, without unformatted partition, and hard driver 2 only works using the MBR! Maybe it has to do with the actual SSD hard drives being too old or something? Anyway, I really appreciate your detail input helping me to figure this out. :slightly_smiling_face:

18

Then, let’s mark the appropriate post (rather than your own) as the solution, shall we?

19

That’s what I thought I did!
:blush:

20

When having strange experiences in the installer session - one need to remember that certain parts of the disk is not rewritten when you repartition the disk and thus they may interfere with your new installation.

To make sure no remnants of boot loader code in the mbr or any initial partitions you will have to zero the first part of the disk.

First ensure all partition and disk layout information has been removed (sgdisk is provided by gptfdisk package - usually present on the install ISO)

sudo sgdisk --zap-all /dev/sdX

Then zero the first 512MiB of the disk

sudo dd if=/dev/zero of=/dev/sdX bs=1M count=512
2 Likes