Installing Manjaro Unencrypted boot and encrypted root

Try downloading and installing Manjaro minimal ISO.

I remembered in the past that some Manjaro full ISOs had the bug with this setup. Boot start failed after installation with my custom partition layout. But Manjaro minimal ISO had no issue.

I tried the minimal install. I even designated 10 MiB unformatted partition to bios-grub (as instructed), and still hangs after the update and a shut down. No big deal. I’ll test it again when the new ISO is available!

One small observation. I don’t know if this has anything to do with this or not.
I have to type the “/efi” manually when I select the free space of 512M for fat32, for the mount point “/boot/efi”. In other words, the “boot/efi” is not in the drop down. Only “/boot”.

Hi, I hope I’m not to late with my answer.
I’ve had the same problem and it not independet of using grub or systemd boot or on the size of /efi or /boot.
I’ve passed the the startup with deleting the ‘splash’ parameter from the kernel start parameters.
You can try it by pressing ‘e’ in grub or systemd boot. Then the parameters are presentet and you can edit them. (see Kernel parameters - ArchWiki for further information)
CU Schorsch


You don’t have the edit option when you manually setup the encryption. I see the “e” option only if you use the system encryption. How ever, I can hit the Esc key really fast to by pass the hanging. Then it goes to the login screen.

No - it is not - not for an EFI based system.

You can verify if you are using an efi based system if the following command is successful or not

ls /sys/firmware/efi/efivars

It is possible to use GPT on BIOS boot but not all system firmware is supporting it.

And there is no advantages nor benefits in doing so.

It is possible to configure a GPT partitioned disk device to be bootable whether you are using efi or bios - the only advantage is that you can move disk between systems that has firmware support GPT.

So being able to create a bios-boot partition like instructed by Calamares does not indicate a missing link.

The fact that your system has intermittent failures point more to hardware issue than an installer issue.

You should be aware that when using encryption on a manually partitioned systerm - how the aforementioned guide shows - it becomes difficult to manually implement suspend and hibernation.

When your power settings include suspend and hibernation settings - this will create weird issues - most likely states where you need to ensure RAM has be cleared - reboot the system twice holding the powerbutton the second time to ensure clearing variables telling the systems NVRAM to resume from hibernation.

That’s exciting for two reasons:

  1. Removing splash from the grub config will likely be a good workaround.

  2. You can further diagnose the issue by looking for errors in:

journalctl -b 0 --no-pager

Sorry, I’m not following this.
I’m assuming I have to login as root?
“# list boots” not found when I type it in the terminal.

Here’s another thought.
I can login bypassing the splash screen by hitting the Esc key as soon as I enter the encryption password. Then I can edit the grub in etc/default/grub.
Is there anything I can uncomment or delete editing the grub file in order to bypass the splash and then do a “sudo update-grub”?

Sorry I made it confusing, I’ve simplified it. It will show a lot of lines! The --no-pager is to ensure full lines show if posting the result, take it off to have nicer scrolling etc.

Login as normal user, not root.

Edit /etc/default/grub and remove the word splash in the line:

Then sudo update-grub as you said.


That fixed the problem! You lose the pretty looking encryption box but that definitely the worked around. Hopefully they can fix this issue in the future ISOs!

Thanks a lot! :slightly_smiling_face:

You’re welcome! although it just works around the problem … maybe try splash again after a future update.

Do you mean add the “splash” back on the line and update the grub again?

Yes, whenever you feel like experimenting. Or alternatively have a splash-shaped lump in the rug, haha

It actually saves you an extra second because it by passes the encryption box! :grinning:

That makes absolutely no sense to me.

Due to be an absolute nerd with electronic devices - I have use a fairly recent piece of hardware

  RAM: total: 15.5 GiB used: 1.78 GiB (11.5%)
  RAM Report: permissions: Unable to run dmidecode. Root privileges
  Info: quad core model: Intel Core i7-8550U bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 1675 min/max: 400/4000 cores: 1: 2000 2: 2000 3: 2000
    4: 704 5: 2000 6: 2000 7: 700 8: 2000

The splash screen is implemented with 22.1.0 iso. So it must be a combination of that addition and your hardware as I have not been able to replicate the issue.

I did find a post for a similar sounding problem on Arch: [SOLVED] Plymouth: not showing on boot or with --show-splash / Newbie Corner / Arch Linux Forums although its 3 years old, maybe still relevant

SOLUTION I am using EFISTUB and it turns out that the new kernel parameters set by efibootmgr weren’t taken into account… Just found out that I have to boot to the UEFI menu and lauch from there once, before the EFI entry is updated with the new parameters… so tried installing Plymouth again, and it now works perfectly

I’m unsure how to translate that into testable steps for Manjaro kde

The topic reference :arrow_up: is not relevant in this situation as the poster was using systemd-boot - whereas Manjaro uses GRUB.

This usage of systemd-boot can be deducted from the sd- entries in the HOOKS line.

1 Like

Yes, I’ve used the Manjaro How-to for changing to systemd-boot that was written by a famous an very active forum member :wink:
I made a first trial with the more modern ‘kernel-install’ approach and realized that the error did’nt disapear. Then I used the ‘manual’ way and switched the mkinitcpio hooks from ‘encrypt’ to ‘sd-encrypt’. So my boot procedure completly different now but the splash screen is not activated, jet.

’ This usage of systemd-boot can be deducted from the sd- entries in the HOOKS line.’
Please let me detail that:
Systemd-boot can can decrypt by using the ‘encrypt’ hook. There is no need to change to the ‘sd-boot’ hook. In this case the same decryption skripts are used that are called by grub. But when you change from ‘encrypt’ to ‘sd-encrypt’ then systemd starts the decryption. (I’ve repeated my installation a few times bevore I’ve learned that.)

I’d like to learn what you’re saying, but unfortunately I’m totally lost! Could you give me more specifics as how as you’re doing this?

@fhins I’m learning too, more reading material:

Boot process, how the pieces fit together

The systemd-boot tutorial mentioned by @Schorsch

similar issue with encrypted root, also bootsplash vs plymouth … this post and the following posts

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.