Manjaro KDE 17.0 (Beta3)

System Settings crashing bugs were resolved or me with Plasma 5.9.2 update, now in both unstable and testing.

An update after installing this ISO (installs Plasma 5.9.1) should fix these issues.

OK, been busy finally got some time to test this.

Have an installation testing VB VM, installed on an old USB drive, currently with 10 partitions that I use to test manjaro-archtitect and Calmares.

I want to re-install Manjaro KDE into sda10, so I chose to replace an existing partition, and here are the resulting Calmares generated actions.

The sda10 is partition being deleted and recreated? Why not just reformat it with mkfs, instead of deleting and recreating a partition of exactly the same size? Some users may have gone to a great deal of trouble to create their partitions via GParted, ensuring correct alignment and spacing between partitions, and this will be undone.

If Manjaro devs are adamant to retain this functionality then it would be more informative to the user to change the terminology used in the text from Replace Partition to Re-Create Partition.

I didn’t like that option so I went back a few steps to the Partition tab and selected Manual Editing of partions instead.

Selected sda10, set / mount point, chose to Format it, clicked Ok.

Click Edit again, and the Content radio button is back to Keep.

This behaviour was reported back in September 2016, but still occurs. The problem is that it looks like the selection is not persisting, so users repeat the same action by re-selecting Format. I did this three times, and Calmares generates 3 partition format actions.

This is not right, users should make their selection once, have it persist, and thus one format action results (if the final choice is to actually format).

What happens if format is accidently chosen? Currently the format action will always be generated and cannot be undone. Users would have to go back a couple of steps and start their manual partitioning again. Again, not ideal.

Testing the actually installation now… I like the new slide show feature, nice.


Installation completed, system boots successfully, kind of.

My current efi partition is sda1, but my customized grub.cfg (ie defines the grub menu) is on sda2. Testing 17.0 XFCE Beta 2 Calmares install previously on sda8 the bootloader in sda1 was replaced, and grub.cfb on sda8 became the default.

In order to remedy this I had to fix manually.

It happened again, this time grub.cfg on sda10 is now the machine default. Update-grub worked though, and all system partitions were found and correct in grub.cfg.

Is there no way to install a system using Calmares without the bootloader in /boot/efi/EFI/boot getting clobbered and changing the default grub.cfg boot partition?

Not mounting an efi partition generated an error, so not an option.

So, during the installation process in Calmares I mounted sda1 to /boot/efi and select to Keep Content, not Format the partition.

This then generates the following Calmares action

Set up fat32 partition on /dev/sda1 with mount point /boot/efi

Will this action always make this new install the default boot partition?

In manjaro-architect setting a new install to become the default bootloader is not the default, it is an action that has to be explicitly chosen. There should be a setting (ie checkbox) somewhere in Calmares with the same function. Fine to leave this existing functionality as default, but there needs to be a way to disable it.

Here you can see that the bootloader, bootx64.efi, was replaced during Calmares install. I kept a copy of the original sda2 grub bootloader file handy in case this happened again.

$ pwd
[manjaro@gellivara-kbeta3 boot]$ ll                                                            
total 368                                                                                          
drwxr-xr-x 2 root root   4096 Feb 13 15:34 .                                                       
drwxr-xr-x 5 root root   4096 Feb 13 00:08 ..                                                      
-rwxr-xr-x 1 root root 122368 Feb 17  2017 bootx64.efi                                               
-rwxr-xr-x 1 root root 122368 Feb 13 15:34 grubx64.efi.sda2   

I kept a copy of my orginal sda2 grub bootloader efi file just in case it happened again.

Calmares is a fantastic installer if you know all its little quirks, but for new users some of these quirks can be quite confusing, and in some cases lead to unexpected installation results.

Having said all that I think the Manjaro devs are doing a fantastic job, and all up Calmares has enormous potential.

EDIT : Same hibernation device resume UUID error on boot, in the Beta 2 thread multiple users reported it OOTB also.

ERROR: resume: no device specified for hibernation

From the Beta 2 thread…

1 Like

I can’t restore the grub bootloader of a previous installed manjaro with this beta 3 version, as it’s described in the WIKI. I can start (within console) sudo mhwd-chroot, but after this the grub-install /dev/sda fails with the error message, the directory of efi configuration isn’t found.

And the boot menue of ISO doesn’t allow to change (keyboard) language and screen resolution. There are only four entries (start free ISO, start nonfree ISO and two UEFI related entries). But there is no start menue to change the start parameters.

This command saved my butt couple of times. Give it a try.

sudo grub-mkconfig -o /boot/grub/grub.cfg

That’s been my impression as well. (I don’t use Calmares that often, because I haven’t had to reinstall).

I always use the manual partitioning mode, and i expect it to do exactly as I say.
I think I first ran into this because Calmares didn’t offer the choice of a separate partition for /home (which I believe should be a standard). Maybe that’s fixed now.

Same, my exposure to Calmares has been through testing these Beta ISO releases. Its been interesting contrasting Calmares with the new manjaro-architect cli installer.

Same, even more so after experimenting with the automatic partitioning modes.

It is.

Just noticed something, why is the boot screen so different for msdos legacy systems and uefi systems.

I have two VirtualBox VMs, one where efi is enabled and one where it is not.

Booting ISO into the efi disabled VM (ie msdos legacy mode) I get this attractive, feature rich menu screen

Booting ISO into the efi enabled VM (ie uefi mode) I get this unattractive, feature lacking text menu screen

Why is this?

As @sueridgepipe pointed out in the thread below, Calamares fails to install on the disk you select to install the bootloader on (always installs to /dev/sda, even when /dev/sdb was selected).

That managed to kill my windows boot sector on the other disk which I wanted to keep. My BIOS actually boots from /dev/sdb instead of /dev/sda, so the system was “unbootable” until I switched in the BIOS back to /dev/sda.

16.10 KDE ISO Calmares this was an issue.

17.0 KDE Beta 3 Calmares this issue is resolved. On an MBR msdos legacy machine I was able to install both OS and bootloader successfully onto sdb. In that specific test case both the W8.1 bootloader on sda and grub on sdb coexisted, booting from either was possible.

I take it all these were with UEFI and sda1 being the $esp is /boot/efi (not /boot). If so, there would not be any bootloader in sda1 in the first place. The original grub.cfg would still be in sda8 and the replacing grub.cfg will also be in sda8 (as you replaced the OS there).

As for bios-legacy boots, like jsamyth, I always use manual partitioning, and I too have not experienced any errors which device to put the bootloader. So perhaps if the user wants to set bootloader to another device, he should use manual partitioning?

The problem with calamares installer is that it lets installation to proceed on UEFI on msdos partitioned devices (and bios-legacy installation on gpt devices). Need to stress that both can be done and the installations will boot up, but there will be consequences of windows and non-similarly-installed linux OS’s not booting up. There should be a warning and ask if user wants to proceed.

As for the different screens, it has been noted and I used this many times to alert users to check if they booted up correctly (uefi or bios-legacy). Also note other linux distros also have different screens for uefi and bios-legacy, like shown here for Mageia.


All my installations are UEFI, both bare metal machines, and subsequently also VB VMs.

I am not seeing this, I wonder if this is a VBox EFI implementation quirk, or something introduced by manjaro-architect.

EFI enabled VB VM, GPT partitioned disk, $esp is /boot/efi, bootloader is in /boot/efi/EFI/boot

$ pwd
[manjaro-kde-full boot]$ ll
total 488
drwxr-xr-x 2 root root   4096 Feb 16 15:14 .
drwxr-xr-x 5 root root   4096 Feb 13 00:08 ..
-rwxr-xr-x 1 root root 122368 Feb 16 15:14 bootx64.efi
-rwxr-xr-x 1 root root 122368 Feb 13 03:33 bootx64.efi.sda8
-rwxr-xr-x 1 root root 122368 Feb 17 01:42 bootx64.efi.sda10
-rwxr-xr-x 1 root root 122368 Feb 13 15:34 bootx64.efi.sda2

Calmares install seems to replace /bootx64.efi with grub bootloader, note the different timestamps, I renamed the files to represent which partition installation created the file, and thus where the /boot/grub/grub.cfg is read from.

$ pwd
[manjaro-kde-full EFI]$ ll
total 20
drwxr-xr-x 5 root root 4096 Feb 13 00:08 .
drwxr-xr-x 3 root root 4096 Feb 17 21:42 ..
drwxr-xr-x 2 root root 4096 Feb 16 15:14 boot
drwxr-xr-x 2 root root 4096 Feb  5 20:24 Manjaro
drwxr-xr-x 2 root root 4096 Feb 13 00:08 manjaro_grub

manjaro-grub directory is introduced as part of the manjaro-architect install, or so I am told.

[manjaro-kde-full EFI]$ ll Manjaro
total 128
drwxr-xr-x 2 root root   4096 Feb  5 20:24 .
drwxr-xr-x 5 root root   4096 Feb 13 00:08 ..
-rwxr-xr-x 1 root root 122368 Feb 17 01:42 grubx64.efi

Note this file was created as a part of the sda10 installation, and replaced /bootx64.efi in the same installation.

So I am confused about what is meant to happen, what is actually happening, is this simply a VBox issue, or is has manjaro-architect played a role as most of these partitions were installed using manjaro-architect.

$ lsblk
sda       8:0    0 232.9G  0 disk 
├─sda1    8:1    0   300M  0 part /boot/efi
├─sda2    8:2    0  29.3G  0 part /
├─sda3    8:3    0   3.9G  0 part [SWAP]
├─sda4    8:4    0  29.3G  0 part 
├─sda5    8:5    0  29.3G  0 part 
├─sda6    8:6    0  29.3G  0 part 
├─sda7    8:7    0  29.3G  0 part 
├─sda8    8:8    0  29.3G  0 part 
├─sda9    8:9    0  27.4G  0 part 
└─sda10   8:10   0  25.6G  0 part 


So looks like VirtualBox may be the cause of all this boot loader clobbering. I gather then this is not how EFI booting process normally works?


First, I do not use VM. So I’m unsure if this is a VM thing - though unsure, I don’t think so.
All grub.cfg is always at /boot, never at /boot/efi, so if $esp is /boot/efi, grub.cfg will not be in $esp.
And when the OS gets replaced, so will the grub.cfg.

What may happen, I guess, is the following.

When there are multiple instances of Manjaro (or Ubuntu and LM or derivatives, for eg), the bootloader-id is the same (manjaro or ubuntu) and will be replaced by the newer one - and so would the directory ‘manjaro’ in your sda1 and the file ‘grubx64.efi’ inside it. [And so will boot up the new OS grub.cfg]

That normally won’t make any difference as grub.cfg anywhere (if installed per upstream) would boot up anything. You can also, if you like, create a new bootloader-id to allow different instances of Manjaro ‘grubx64.efi’ say, to co-exist.
And that would still be unnecessary unless, for whatever reason you want to have a customized grub.cfg for each Manjaro distro (which you can do anyway with the new).

Which brings to the following…

I am unsure what this sda2 means. Is this another Manjaro OS which is not replaced, existing and working?
If so, and you want this to be default again, just boot to this Manjaro OS and do a

sudo grub-install

It will become the default again. (ps: assuming this sda2 OS is gpt/uefi)

However, if this sda2 is a stand-alone (non-OS) partition where you want to have its grub.cfg as default at all times as I have done here with both uefi and bios-legacy systems, we can still manage by making a different bootloader-id for it.

Hope (both of us) becomes clearer on this issue.

1 Like

I have one VM with 10 partitions, and am doing some installation testing with both manjaro-architect and Calmares. There are 8 different versions of Manjaro installed onto different partitions, basically testing the installation of each DE, with $esp on /dev/sda1.

Sorry if this was unclear, was shorthand for /dev/sda2, which was my intitial installation partition using Calmares, and which contains a “master” customized grub.cfg that I use to boot into all the different installations. So no matter what I install onto which partition I would like grub to use the grub.cfg on /dev/sda2.

Each Calmares install creates its own grub.cfg on its root partition, in boot/grub, and the the installed grubx64.efi is seemingly “hardwired” to use this grub.cfg from the partition it was installed into. So the different bootx64.efi files with sda[n] I have renamed to indicate which partition they read their grub.cfg from.

Each manjaro-architect install does not install grub, unless explicitly instructed to, so only an empty grub.cfg is created.

This makes perfect sense and explains why I have one Manjaro directory beneath /boot/efi/EFI and why grub is replaced each time I install with Calmares.

Virtualbox does this as part of its EFI boot process

  • Move the bootloader to the default /EFI/BOOT/BOOTX64.EFI path;

which explains why /boot/efi/EFI/boot/bootx64.efi keeps getting clobbered. Virtualbox is doing it.

Unfortunately this doesn’t work in VirtualBox, which I discovered after a long night of testing.

Do not bother with the VirtualBox Boot Manager (accessible with F2 at boot): EFI entries added to it manually at boot or with efibootmgr will persist after a reboot but are lost when the VM is shut down.

grub-install works across reboots, but does not persist across shutdowns,

In hindsight this is probably why the VirtualBox “boot loader clobbering” functionality exists.

Anyway, thanks for taking the time, is helpful for someone to explain what should happen so I can deduce what VirtualBox is doing differently.

1 Like

Thanks too, for explaining what VirtualBox is doing.
It is clearer for me too.

I faced an issue. When I tried to run calamores it started and and disappeared immediately. Even After couple of reboot same problem consisted. When I tried to run it multiples time and finally it ran and was able to install Manjaro in system.

Lots of thanks for removing a lot of less used applications. Now Manjaro KDE takes even less space of vanilla arch install.

This is a minimal image. The 17.0-rc1 which released a few hours ago is a full image (2.1 GB).

I think I will settle with minimal image. It has almost everything I need. Other extra packages I can install manually :smile:

1 Like

The manjaro-chroot UI issue I saw in beta2 has been fixed in beta3. Thanks.


I didn’t test it yet or simply ignored it :wink: You can create a more useful log output by starting Calamares in Debug Mode with sudo -E calamares -d. Then you see what actually is done by Calamares. It is also good to report these issues to upstream. Then we can handle them fast.

1 Like

Forum kindly sponsored by Bytemark