Installation from USB fails with bootloader script exception

ben79 · January 19, 2025, 2:41pm

First I want to say Welcome and that we appreciate your trying OMLx and we are very sorry you are having this problem. Apologies for not saying so sooner.

At this point I don’t know. I would suggest to talk to OM developers. OM-Chat is often the quickest way to do that.

Your boot order shows MX Linux as where you are booting from, have you run their update grub2 command and see if it picks up the OM partition.

Boot0003* OpenMandriva_Lx_[GRUB]

I am not sure what that is, if it is a system partition or not. The original error suggests that either your partition setup or how you are partitioning in the OM Calamares partitioner has presented it with a circumstance that the current grub2 script can not handle. We need to find out why that is so.

Output of fdisk -l and screen-shot of the partitioning set-up in the Calamares installer. But I still think this is over my head knowledge wise.

If you wish to continue working with us on this a bug report would be a good idea.

rugyada · January 19, 2025, 2:55pm

0x6A7232 · January 20, 2025, 5:57am

MX’s grub does indeed pick up on it (as does Manjaro’s), however loading fails with the error [FAILED] Failed to start initrd-switch-root.service - Switch Root (see pictures). Also,

fdisk -l

Disk /dev/loop0: 2.84 GiB, 3051421696 bytes, 5959808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1048576 bytes


Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 77D26F28-8DF3-5541-949D-8475660A6DA9

Device          Start        End    Sectors   Size Type
/dev/sda1        2048    1085440    1083393   529M Microsoft basic data
/dev/sda2     1323008 1758173183 1756850176 837.7G Microsoft basic data
/dev/sda3  1919184896 1953523711   34338816  16.4G Microsoft basic data


Disk /dev/sdb: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk model: WDC WD102KFBX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 09D1C4AC-BF03-4E85-8015-B6C30907A491

Device     Start         End     Sectors Size Type
/dev/sdb1   2048 17179871231 17179869184   8T Microsoft basic data


Disk /dev/sdc: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 1CED5C95-A7D4-4353-99A1-A444B3B28D35

Device         Start       End   Sectors   Size Type
/dev/sdc1       2048 488331591 488329544 232.9G Microsoft basic data
/dev/sdc2  488331592 488397127     65536    32M Microsoft basic data


Disk /dev/sdd: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors
Disk model: WDC WD102KFBX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 2538B0CF-E282-4449-8085-1D97E349BE68

Device           Start         End    Sectors  Size Type
/dev/sdd1         2048  8589936639 8589934592    4T Microsoft basic data
/dev/sdd2  17385390080 19532871679 2147481600 1024G Linux filesystem
/dev/sdd3  16311648256 17385390079 1073741824  512G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/sde: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: Samsung SSD 870
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 1597041C-221B-46D4-A6D9-7F8395010CFF

Device          Start        End   Sectors  Size Type
/dev/sde1        2048    1083391   1081344  528M EFI System
/dev/sde2  3894050816 4313481215 419430400  200G Linux filesystem
/dev/sde3     1083392  420513791 419430400  200G Linux filesystem
/dev/sde4  1729136640 2148567039 419430400  200G Linux filesystem
/dev/sde6  7679819776 7713636351  33816576 16.1G Linux swap
/dev/sde7  2148567040 2216329215  67762176 32.3G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/sdf: 3.76 GiB, 4040748544 bytes, 7892087 sectors
Disk model: USB Flash Drive
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 1048576 bytes
Disklabel type: dos
Disk identifier: 0xc771e703

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdf1  *          1 6296743 6296743    3G cd unknown
/dev/sdf2       6296744 6309907   13164  6.4M ef EFI (FAT-12/16/32)


Disk /dev/zram0: 7.79 GiB, 8369733632 bytes, 2043392 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
[live@omv-3523 ~]$

Images of partition layout also attached.

ben79 · January 20, 2025, 10:42pm

I apologize for not being able to help with this.

There is not point in me saying more on an issue where I clearly am not knowledgeable enough to help.

0x6A7232 · January 22, 2025, 11:33am

Does anyone know if there’s a way to make the bootloader python script output what it’s doing and where it throws the error? I think I managed to snag the script but I’m not sure where it’s having the issue.
main.py.txt (34.1 KB)

0x6A7232 · February 2, 2025, 7:56pm

Made a bug report here.

RogerS · February 9, 2025, 12:15am

I ran into the same issue when trying to install OpenMandriva ROME in a VM.

A workaround that worked for me was to edit /etc/calamares/modules/bootloader.conf and change efiBootLoader from “grub” to “systemd-boot”.

WilsonPhillips · February 9, 2025, 12:23am

Welcome! We are happy to see you.

ben79 · February 10, 2025, 2:00pm

Welcome @RogerS. That is an interesting suggestion.

I’ll be testing that myself.

Edit: I did test this in VBox and it works but system boots without any boot menu. Do not know if this will work on a multi-boot system. Maybe it will, just not sure.

RogerS · February 10, 2025, 8:50pm

If you do this, it will install systemd-boot instead of grub, and you’ll have to go into the UEFI boot menu to boot another OS.

I’ve since found that changing installEFIFallback to false in /etc/calamares/modules/bootloader.conf works too, and lets you install grub which lets you select which OS you want to boot from a grub menu.

What prompted me to try changing the installEFIFallback setting were these lines from calamares-installation-log.txt posted by @0x6A7232 :

[PYTHON JOB]: "UEFI Fallback: True" 
[PYTHON JOB]: "  .. installing 'bootx64.efi' fallback firmware" 
06:53:36 [1]: virtual JobResult Calamares::Python::Job::exec()
    ERROR: Error while running: FileExistsError: [Errno 17] File exists: '/tmp/calamares-root-3cw0t75q/boot/efi/EFI/BOOT/bootx64.efi'

The error only happens if I install another distro (for example Kubuntu) first, then install OpenMandriva alongside it. If I install OpenMandriva on its own, it installs fine without any workarounds needed.

ben79 · February 11, 2025, 2:37am

Thanks something else to test and you make some good suggestions for options for folks with installation issue with OM’s Calamares.

The changing installEFIFallback to false seems like it may well fit @0x6A7232 situation. In his calamares-installation-log we see:

Installing for x86_64-efi platform.
Installation finished. No error reported.
[PYTHON JOB]: "UEFI Fallback: True" 
[PYTHON JOB]: "  .. installing 'bootx64.efi' fallback firmware" 
06:53:36 [1]: virtual JobResult Calamares::Python::Job::exec()
    ERROR: Error while running: FileExistsError: [Errno 17] File exists: '/tmp/calamares-root-3cw0t75q/boot/efi/EFI/BOOT/bootx64.efi'

WilsonPhillips · February 11, 2025, 2:54pm

Apparently systemdboot can dual boot, but I have not tried to do this. I prefer to use the bios boot menu to select which OS I want to boot to.

On the other hand, systemdboot cannot handle btfrs snapshots and this is something that I find critical. OMLx is working on this right now.

0x6A7232 · February 15, 2025, 9:05pm

Guessing here, but if you take a look at this StackExchange answer, we see that EFI\boot\bootx64.efi is the fallback bootloader path, and it looks like since it already exists, instead of either failing successfully or prompting to overwrite / rename / etc, it causes a failure state of the bootloader installation script?

However, if you take a look at that page, the fallback is completely optional, and mostly used for booting OSes on removable devices, looks like Windows (of course) just installs a copy there, and grub will as well if it does not already exist, which seems to be the hangup here.

Anyways, I’ll try installEFIFallback to False and see if that works, but may I suggest an option to have a setting for “I already have a bootloader solution” with a helpful reminder of how to run sudo update-grub if selected?

0x6A7232 · February 15, 2025, 11:15pm

Setting installEFIFallback to false in /etc/calamares/modules/bootloader.conf (it’s at the bottom of the file) did the trick.

NB: if you save the file after already loading the OpenMandriva installer, it won’t work. At some point, either at startup or during the wizard, it reads the .conf file – it doesn’t just read it before final execution. Ask me how I know this.
Also, if you have been in this pickle already and have caught the failed OpenMandriva installation using your other OS’s update-grub, you’ll have to run it again to update with the successful installation settings, or you’ll get a crash at start if you use your old GRUB entry.

tl;dr: save the changes before opening the installer & run sudo update-grub again on any OS whose bootloader you want a working OpenMandriva entry on.

system · March 17, 2025, 11:15pm

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