[unstable] Manjaro-architect beta testing



Another small thing I noticed, during base install kernel headers are not selected by default, is this right?


Just installed into luks partition again, installed bootloader and made grub the default bootloader, but won’t boot.

Which makes sense as grub is trying to read grub config from an encrypted partition that has not been decrypted, and I wasn’t prompted to decrytp it.

Waving the white flag on this one… NFI.


Thanks for trying!

Oberon suggested it as default for testing for the similar reason as base-devel is not installed by default: big package to install for quickly repeated testing installations. The official kernels have their modules precompiled anyway. For stable version I think base-devel should be selected by default, possibly also kernel headers. [quote=“sueridgepipe, post:463, topic:16010”]
What does this even do, and what difference does it make if os-prober explicitly does not allow a grub menu entry to be created from within a luks partition?

I don’t know, I just saw it somewhere and thought it might be related.


Makes perfect sense, just need to remember to change it when it eventually goes live.

Thanks for the suggestions anyway. I think I’ll install using Calmares into a brand new VM with only two partitions and then take a look at the resulting environment.

Anyone else with any luks know how, all suggestions welcome… :slight_smile:


LOL, even that bloody failed…

Simple UEFI GPT setup with $esp, root and swap. Chose to encypt root partition. Using 17.0 KDE RC1 ISO, will try again later with RC2 which was just released.

If I get the same error I’ll report it there.


If trying just for manjaro-architect, thus should be able to reliably install manjaro on encrypted root


I found this from the Internet:

Unfortunately os-prober is pretty rustic, it does not accept any kind of configuration (file or command line). Yet, it understand LUKS.

If you use LUKS instead of plain cryptsetup it will stop trying to interpret that partition (on the other hand, if the partition is open it will try to find and understand the loop device).

So if you open the crypted volumes before updating grub…

It makes sense, if the encrypted volume is not open, any script cannot get the necessary data to create boot entries


Found the same article


Suggestion, and eventual solution, was to hack the script so that luks is not ignored

Yet, if you really do not want to use LUKS you can simply hack os-prober and include your encrypted partition into the fs_type check. That check is performed inside /usr/share/os-prober/common.sh and is actually quite trivial

I have no idea how to do that.

Already tried that, first thing I tried actually.

$ sudo cryptsetup open --type luks /dev/sdb1 cryptroot
Enter passphrase for /dev/sdb1: 
$ lsblk
NAME                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb                           8:16   0    25G  0 disk  
├─sdb1                        8:17   0  15.2G  0 part  
│ └─cryptroot               254:1    0  15.2G  0 crypt
$ sudo blkid | grep mapper
/dev/mapper/manjaro--vg-manjaro--lv: UUID="305d5473-1bd1-4da0-9419-4259c2f823cf" TYPE="ext4"
/dev/mapper/cryptroot: UUID="840aa4f0-4b3d-42f5-8c19-6939375c1369" TYPE="ext4"

$ sudo update-grub
Found Manjaro Linux (16.10) on /dev/mapper/manjaro--vg-manjaro--lv

That is what I meant by one device mapped virtual partition (lvm) is os-probed successfully, and another device mapped device (decrypted luks) is not. Led me to the os-probe script.

The problem is os-prober, at least why there is no grub entry for the encypted partition installation.

Making the encrypted partition installation the default grub doesn’t prompt to decrypt at boot, thus grub config cannot be read and grub errors out to a shell.


Thanks for the data!


Chrysostomus: compliments for the work!!! I’m testing it and great: it work like a charms. Ok, surely not perfect, but great. :slight_smile:

Some notes:

  1. I used manjaro.architect to install KDE+open-rc on an external USB drive with the last stable update and

  2. I got some “noises” to understand how to install LUKS (512 Mbyte /boot partition and a / encrypted partition without LVM (I’ll try it in the next days). I discover that, if I redefine the partitions of the disk (delete partition and redefine the dimension, for example), before I MUST create a new partition table (GPT for me) using gparted.

  3. The final step are not required with openrc, shall be fine to disable the systemd option when installing openrc; ok, its a plus :slight_smile:

Anyway: I’ll continue to test and if I’ll get some problems I’ll report you.


Thinking a bit more I remembered this from earlier in the thread

Just did another install into the encrypted partition, including a default bootloader install, and same result

Checking the $esp partition

$ ll /boot/efi/EFI/boot
total 368
drwxr-xr-x 2 root root   4096 Feb 25 19:28 .
drwxr-xr-x 5 root root   4096 Feb 13 00:08 ..
-rwxr-xr-x 1 root root 122368 Feb 26 08:16 bootx64.efi
-rwxr-xr-x 1 root root 122368 Feb 19 10:14 bootx64.efi.sda2
$ ll /boot/efi/EFI/manjaro_grub
total 128
drwxr-xr-x 2 root root   4096 Feb 13 00:08 .
drwxr-xr-x 5 root root   4096 Feb 13 00:08 ..
-rwxr-xr-x 1 root root 122368 Feb 23 09:04 grubx64.efi

A manjaro-architect UEFI bootloader install should have replaced /boot/efi/EFI/manjaro_grub/grubx64.efi, it did not.

Making grub the default bootloader from within manjaro-architect should have replaced /boot/efi/EFI/boot/bootx64.efi, which it did.

So I think maybe manjaro-architect is doing an MBR grub install, and not a UEFI grub install, and replacing the VM’s default bootloader with MBR grub, which is causing

error: file '/boot/grub/x86_64-efi/normal.mod' not found

Double checked the encrypted partition is a GPT partition

lsblk identifies the partition type as crypt (ie luks), which is normal for de-drypted partitions

$ lsblk
NAME                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb                           8:16   0    25G  0 disk  
├─sdb1                        8:17   0  15.2G  0 part  
│ └─cryptroot               254:1    0  15.2G  0 crypt 
└─sdb2                        8:18   0   9.8G  0 part  

blkdid correctly identifies the file system as ext4, which is what I formatted with during install

$ sudo blkid |grep cryptroot
/dev/mapper/cryptroot: UUID="685cb7eb-5ed5-4f2f-aaef-41147e821505" TYPE="ext4" 

I mounted the $esp /dev/sda1 to /boot/efi during installation, so I just assumed manjaro-architect recognised the bootloader install as a UEFI bootloader install.

Flawed assumption when working with encrypted partitions?

How does manjaro-architect determine whether to install MBR or UEFI grub?


Of course my theory would be shot down in flames if in fact this error

error: file '/boot/grub/x86_64-efi/normal.mod' not found

could also be explained by grub attempting to read from an encrypted partition, but the fact grub is looking for normal.mod is what indicates to me that MBR grub was incorrectly installed.


That is weird. Whether or not grub is being installed in uefi mode should be clear in the messages it displays. If it asks you to mount esp, it is going to install in uefi mode. The bootloader copying is part of only the uefi install function, it doesn’t get executed if installation happens in bios mode.

If /boot/efi/EFI/manjaro_grub/grubx64.efi was not replaced, could it be that the grub-install failed?


If it failed it wasn’t captured. It also poses the question, what was /boot/efi/EFI/boot/bootx64.efi replaced with? Whatever grubx64.efi happened to be in /boot/efi/EFI/manjaro_grub at install time?

My MBR premise is based on @gohlip’s statement that normal.mod error indicates grub booting in MBR mode. If this error also occurs when there is no grub config present in a non encrypted partition, or grub config is inaccessible in an encrypted partition, then my speculative premise falls apart.

So, potentially the grub install failed and the default bootloader became the grubx64.efi from a previous install. Which could also explain the normal.mod error, if this can occur when grub config embedded in bootx64.efi is inaccessible for any reason, or doesn’t exist.

Make any sense?



Let’s sum up the current situation:

  1. your general grub can’t find your encrypted installation
  2. installing grub from your encrypted system seems to fail somehow.

When doing encrypted installation, could you post the contents (or relevant lines) of /mnt/etc/default/grub and /mnt/etc/mkinitcpio.conf?

And maybe also the grub.cfg of the new installation?


so what informative installer “logs”, and I do mean ALL logs, if any, are actually being captured here, and how deep do they go, for troubleshooting purposes, or is this a systemd imaginary thing, depending on … ?, what exact file are they written to.
-just asking.


They are also not pre-installed on the official Manjaro releases. Normally there is no need to use dkms modules since we provide the modules pre-compiled and packaged. So, most users will never need kernel headers…


so what informative installer “logs”, and I do mean ALL logs, if any, are actually being captured here, and how deep do they go, for troubleshooting purposes, or is this a systemd imaginary thing, depending on … ?, what exact file(s) are they written to.
-just asking.


They are written to /var/log/m-a.log. Ideally the log will contain the settings you choose and each step the installer makes. Which function was executed, what were the error messages created…
Logging functionality is not at all finished and there are many more places where we could and should capture those feedback messages.
For now the log is stored on the host system only - the live environment. So it will be lost with reboot. I would suggest though that at the end of installation we copy the file to target install, maybe readable only for root and with an option and a reminder to remove it at first boot if you don’t want to keep it.


Yes to 1), kind of for 2).

  1. booting grub from your encrypted system fails with normal.mod not found grub error.

Because of 1) I am trying to boot from encrypted install grub instead, which is not working, as explained above. Grub install failing for some reason is speculative given the manjaro_grub $esp grubx64.efi file timestamp.

Other current major bug is not being able to mount /dev/mapper partitions in manjaro-architect. Because of this I have to re-install everything everytime I want to test bootloader installation. See earlier posts for more details and screen grabs.


Just before the installation completes?

I’ll have a look at the m-a log too.


Is the uuid in the post with /boot/grub/grub.cfg the uuid of /dev/sda* or /dev/mapper/cryptroot?