Installation from USB fails with bootloader script exception

Support
, ,
1

Hello,

  • OpenMandriva Lx version:

  • 20241225.3523-plasma6.x86_64

  • Desktop environment (KDE, LXQT…):
    KDE

  • Description of the issue (screenshots if relevant):

  • Installation fails: "Bad main script file. Details: “Main script file /usr/lib64/calamares/modules/bootloader/main.py for python job bootloader raised an exception.”

  • Relevant informations (hardware involved, software version, logs or output…):
    MSI z170m Mortar (MS-7972) i7-7700K 16GB RAM
    Operating System: OpenMandriva ROME 24.12
    KDE Plasma Version: 6.2.4
    KDE Frameworks Version: 6.9.0
    Qt Version: 6.8.1
    Kernel Version: 6.12.6-desktop-1omv2490 (64-bit)
    Graphics Platform: Wayland
    Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
    Memory: 15.6 GiB of RAM
    Graphics Processor: AMD Radeon RX 6700 XT
    Manufacturer: Acidanthera
    Product Name: iMac18,3
    System Version: 1.0

Not sure where it got iMac18,3 from but that looks like remnants of a years old hackintosh info? This is booting from a FRESHLY formatted USB stick (dd, which I resorted to after the same error occured after using balenaetcher) though. I did verify the hash of the downloaded file. Although I did have to chainload it as the UEFI version of OpenMandriva doesn’t show on the boot menu.

If you want logs or other info let me know.

(I did try to attach a screenshot but it’s not allowed.)

2

Hello,

Try now

3

I’ll do so next time I re-attempt installation (it was saved on the Live folder, which of course is volatile storage).

EDIT: Oh, and I can pick up the install from os-prober on the other Linux distros I have on the machine and boot using their grub bootloader. It saves an error to a text file on boot and suggests to put it on a USB to post it. Except, only the initramfs (I think?) filesystem is loaded, and mount isn’t part of the toolset so I can’t really do anything with the file.

4

What to do if there is a problem installing OMLx

You can attach the calamares-installation-log.txt to your post here or in a bug report.

On some pc’s you have to enable UEFI or not in BIOS, ofc I have no clue about Apple stuff. But the Grub2 Menu is not supposed to have UEFI or Legacy boot choice that is dynamically configured somehow. Beyond that this would be question for developers.

5

UEFI is set to hybrid (so I can choose either UEFI or non from any boot device) and UEFI shows up just fine when the USB disk has Ventoy installed or another distro’s installation iso. OpenMandriva after formatting the USB with the iso (dd) shows in the USB disk as file format iso9660 (I assume that’s correct?) so it could be that the BIOS doesn’t recognize the filesystem as it’s not technically an optical drive, and thus doesn’t read the EFI folder?? Eh, screw it, I’m going to boot Windows and use Rufus and see if that makes a difference.

EDIT: @ben79 Where is that log file? Catfish search of the install partition didn’t find it.

6

First at the top of the page there is a “Big Fat Warning” might be worthwhile to scroll through that. Then read:

ROME Release Notes

ROME Errata

Forum Resources Index

7

On the iso in /home/live

You should have run the command pkexec calamares -d 2>&1 | tee /home/live/calamares-installation-log.txt

This part pkexec calamares -d starts the Calamares installer in debug mode.

This 2>&1 | tee writes the file calamares-installation-log.txt in /home/live

You should easily find that file if you open Dolphin file manager.

8

If you set that to use dd it might work. If you read Release Notes you will see where it says not to use Rufus.

1 Like
9

If you use Rufus, you have to write it in dd mode. If you use Ventoy, you have to do this:

10

So, I actually did do that, before all of this (flashing with balenaetcher & dd) and did have to open the Konsole terminal to keep squashfs.img present. However, since it was known to have issues and had a workaround, I didn’t mention it, as it did the same thing as balenaetcher & dd writing the image directly to the flash drive. I’m going to try something else here in a minute, we’ll see how it goes.

11

cough Any particular reason the installation iso doesn’t have /boot/grub/x86_64-efi/? Is it unnecessary somehow?
Both Manjaro and MX Linux do, and, if I understand correctly, this is where grub loads its modules during boot, and, x86_64-efi would be the standard EFI modules for any modern system, whereas i386-pc would be the modules for legacy boot. There is only i386-pc in the OpenMandriva grub folder (i386-pc is also in MX & Mandriva).
So:
i386-pc : Manjaro, MX, OpenMandriva
i386-efi : MX
x86_64-efi : Manjaro, MX

Would this be related to the problem or not really?

12

Ok, did some checking, and if you guys are using similar repos, the correct package to have for x86_64-efi is grub-efi-amd64-bin – I can see the grub2 package, and for my system, it is NOT installed (because grub2 is legacy boot, AFAIK), and instead I have grub-efi-amd64-bin
Now if we go here: Show - Product ROME plasma6.wayland x86_64 - - Openmandriva ABF
And have a look at iso_build.log, do a CTRL+F for grub, all there is is grub2 and grub2-editor.

For grub-efi-amd64-bin, here is the info:

Blockquote
Package: grub-efi-amd64-bin

Version: 2.06-13+deb12u1

State: installed

Automatically installed: yes

Multi-Arch: foreign

Priority: optional

Section: admin

Maintainer: GRUB Maintainers pkg-grub-devel@alioth-lists.debian.net

Architecture: amd64

Uncompressed Size: 18.7 M

Depends: grub-common (= 2.06-13+deb12u1)

Recommends: grub-efi-amd64-signed, efibootmgr

Conflicts: grub-efi-amd64-bin:i386

Replaces: grub-common (<= 1.97~beta2-1), grub-efi-amd64 (< 1.99-1), grub2 (< 2.06-13+deb12u1), grub-common:i386 (<= 1.97~beta2-1), grub-efi-amd64:i386 (< 1.99-1), grub2:i386 (< 2.06-13+deb12u1)

Provides: grub-efi-amd64-bin:i386 (= 2.06-13+deb12u1)

Provided by: grub-efi-amd64-bin:i386 (2.06-13+deb12u1)

Description: GRand Unified Bootloader, version 2 (EFI-AMD64 modules)

GRUB is a portable, powerful bootloader. This version of GRUB is based on a cleaner design than its predecessors, and provides the following new features:

  • Scripting in grub.cfg using BASH-like syntax.

  • Support for modern partition maps such as GPT.

  • Modular generation of grub.cfg via update-grub. Packages providing GRUB add-ons can plug in their own script rules and trigger updates by invoking update-grub.

This package contains GRUB modules that have been built for use with the EFI-AMD64 > architecture, as used by Intel Macs (unless a BIOS interface has been activated). It can be installed in parallel with other flavours, but will not automatically install GRUB as the active boot loader nor automatically update grub.cfg on upgrade unless grub-efi-amd64 is also installed.

Homepage: GNU GRUB - GNU Project - Free Software Foundation (FSF)

Need to get 0 B of archives. After unpacking 0 B will be used.

For Grub2, we have:

Package: grub2

Version: 2.06-13+deb12u1

State: not installed

Multi-Arch: foreign

Priority: optional

Section: admin

Maintainer: GRUB Maintainers pkg-grub-devel@alioth-lists.debian.net

Architecture: amd64

Uncompressed Size: 12.3 k

Depends: grub-pc (= 2.06-13+deb12u1), grub-common (= 2.06-13+deb12u1)

Conflicts: grub2:i386

Provides: grub2:i386 (= 2.06-13+deb12u1)

Provided by: grub2:i386 (2.06-13+deb12u1)

Description: GRand Unified Bootloader, version 2 (dummy package)

This is a dummy transitional package to handle GRUB 2 upgrades. It can be safely removed.

Homepage: GNU GRUB - GNU Project - Free Software Foundation (FSF)

Tags: admin::boot, role::dummy

Need to get 2,364 B of archives. After unpacking 12.3 kB will be used.

Looks like that’s just grub-pc:

Package: grub-pc

Version: 2.06-13+deb12u1

State: installed

Automatically installed: no

Multi-Arch: foreign

Priority: optional

Section: admin

Maintainer: GRUB Maintainers pkg-grub-devel@alioth-lists.debian.net

Architecture: amd64

Uncompressed Size: 564 k

Depends: debconf (>= 0.5) | debconf-2.0, grub-common (= 2.06-13+deb12u1), grub2-common (= 2.06-13+deb12u1), grub-pc-bin (= 2.06-13+deb12u1), ucf

Conflicts: grub (< 0.97-54), grub-coreboot, grub-efi-amd64, grub-efi-ia32:i386, grub-efi-ia32, grub-ieee1275, grub-legacy, grub-xen, grub-legacy:i386, grub-coreboot:i386, grub-efi-amd64:i386, grub-ieee1275:i386, grub-pc:i386, grub-xen:i386

Replaces: grub, grub-common (<= 1.97~beta2-1), grub-coreboot, grub-efi-amd64, grub-efi-ia32:i386, grub-efi-ia32, grub-ieee1275, grub-legacy, grub2 (< 2.06-13+deb12u1), grub-legacy:i386, grub-common:i386 (<= 1.97~beta2-1), grub-coreboot:i386, grub-efi-amd64:i386, grub-ieee1275:i386, grub2:i386 (< 2.06-13+deb12u1)

Provides: grub-pc:i386 (= 2.06-13+deb12u1)

Provided by: grub-pc:i386 (2.06-13+deb12u1)

Description: GRand Unified Bootloader, version 2 (PC/BIOS version)

GRUB is a portable, powerful bootloader. This version of GRUB is based on a cleaner design than its predecessors, and provides the following new features:

Need to get 0 B of archives. After unpacking 0 B will be used.

However, I’m assuming, if this was actually an issue, others who were trying to boot EFI from the OpenMandriva installer would have noticed it?

I just don’t know how I can boot other installers with EFI just fine but not OpenMandriva… /puzzled

13

@0x6A7232 Not my field so not sure if related. Also I’m lost with all these very technical bits :slight_smile:

See:
https://wiki.openmandriva.org/en/distribution/releases/rome/notes#installing-from-usb

When you see the menu, select the entry matching your USB drive.
Among others, you will see entries along the lines of

USB some Flash Drive
UEFI USB some Flash Drive

If you have a UEFI/EFI computer be sure to select the one mentioning ‘UEFI’ and boot that, otherwise the Calamares installer will present only legacy bios options for installation.

14

Oh, for Pete’s sake.

So I created a new MX Linux Live USB to double-check my memory on this issue.

Huh, that’s weird. Can’t see the UEFI boot option any more. And I know I’ve done this, because I’ve installed MX and Manjaro using the UEFI boot option…

Go into BIOS settings, everything is as it should be. Try multiple things, found this nifty little script to tell if you booted from BIOS or EFI: test -d /sys/firmware/efi && echo efi || echo bios~ = yup, I’m in BIOS. Cannot get the UEFI option for the USB (which always shows up, have done this multiple times).

Finally figured it out (gee thanks, MSI): Go into BIOS, flip “UEFI + Legacy” to “UEFI”, flip it back to “UEFI + Legacy”, then change the boot order of one of the selections in the fixed boot order to UEFI USB key xyz, save settings, now it magically works (mind you the boot order was previously set to include UEFI USB key).

So this appears to be a bug in my system BIOS??

Anyways, I’m off to flash OpenMandriva and see if it shows up now (99.99999% chance it does considering what I just went through testing the MX Live USB).

1 Like
15

@rugyada Ok, now I’m booting in UEFI mode, and have an error message with the bootloader install script. I’ll follow @ben79’s directions and get the install log.

System reports it booted in EFI mode, so that’s at least clear now.

1 Like
16

Ok, got the log file:
calamares-installation-log.txt (134.5 KB)

17

First is secure boot enabled in BIOS/Firmware? That will not work with OMLx.

For OMLx grub2 is the boot-loader for UEFI or Legacy boot, no OM does not always do things like other distros, this is an example of that. What other distros call file names or packages is not relevant. OM definitely does not share repositories with any other distro our packaging is unique to OpenMandriva Lx.

Starting job "bootloader" ( 30 / 34 ) 
[PYTHON JOB]: Found gettext "en_US.UTF-8" in "/usr/share/locale/en_US.UTF-8" 
[PYTHON JOB]: "Bootloader: grub (efi)" 
    .. Running QList("grub2-install", "--target=x86_64-efi", "--efi-directory=/boot/efi", "--bootloader-id=OpenMandriva_Lx_[GRUB]", "--force") 
    .. Finished. Exit code: 0 output:
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'

Log shows installation of the system and boot-loader are successful and then there is an unfamiliar error. I can guess, only a guess, that the installer can not write somthing because you are useing the Windows Boot Manager. I am asking developers about this. Do you see any entry for OMLx in Windows Boot Manager?

18

Also in your installation log are a lot of these errors:

chcon: failed to get security context of '/': Operation not supported
    .. Running QList("mount", "-t", "ext4", "-o", "defaults,noatime,discard", "/dev/sde2", "/tmp/calamares-root-3cw0t75q/") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/boot/efi': Operation not supported
    .. Running QList("mount", "-t", "vfat", "-o", "defaults,noatime,umask=0077", "/dev/sde1", "/tmp/calamares-root-3cw0t75q/boot/efi") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/dev': Operation not supported
    .. Running QList("mount", "-o", "bind", "/dev", "/tmp/calamares-root-3cw0t75q/dev") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/proc': Operation not supported
    .. Running QList("mount", "-t", "proc", "-o", "defaults,noatime", "proc", "/tmp/calamares-root-3cw0t75q/proc") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/run': Operation not supported
    .. Running QList("mount", "-t", "tmpfs", "-o", "defaults,noatime", "tmpfs", "/tmp/calamares-root-3cw0t75q/run") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/run/udev': Operation not supported
    .. Running QList("mount", "-o", "bind", "/run/udev", "/tmp/calamares-root-3cw0t75q/run/udev") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/sys': Operation not supported
    .. Running QList("mount", "-t", "sysfs", "-o", "defaults,noatime", "sys", "/tmp/calamares-root-3cw0t75q/sys") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync") 
chcon: failed to get security context of '/sys/firmware/efi/efivars': Operation not supported
    .. Running QList("mount", "-t", "efivarfs", "-o", "defaults,noatime", "efivarfs", "/tmp/calamares-root-3cw0t75q/sys/firmware/efi/efivars") 
    .. Running QList("udevadm", "settle") 
    .. Running QList("sync")

An OM dev told me that is selinux cruft which we do not do Edit: In a default install. I would have no idea how selinux gets used by our iso ‘Live’ environment.

19

Secure Boot is not enabled.
I have Windows 10 but it is not booted by default, and is booted via grub when used (although of course it is possible to directly boot it from the UEFI boot menu, same as with MX and Manjaro)
Note that only one of the Windows Boot Manager options in UEFI work correctly and I’m not sure what the other 2 are or if that makes any difference.

I can try to load up Windows Boot Manager but if I recall correctly, I have to boot Windows, then hit Restart whilst holding shift to even get it to appear (if selected in GRUB or via UEFI it will just directly boot Windows 10, no boot menu). I’ll do that now.

$ efibootmgr
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0002,000C,0011,0003,0004,0016,0001,0018,0019,0008,000E,0017
Boot0000* MX Linux
Boot0001* Hard Drive
Boot0002* Manjaro Linux
Boot0003* OpenMandriva_Lx_[GRUB]
Boot0004* mx
Boot0008  Windows Boot Manager
Boot000C* Windows Boot Manager
Boot000E  Windows Boot Manager
Boot0011* UEFI OS
Boot0016* USB HDD
Boot0017  UEFI: Mass Storage Device 1.00, Partition 1
Boot0018* USB KEY
Boot0019* UEFI: A-DATA USB Flash Drive 0.00
joshua@mx-Linux-KP9USMC:~
$
20

Here’s the Win 10 boot menu. As you can see, apparently all EFI boot options are listed as ‘devices’, however, I have never used this method to boot anything (no idea if it would even work).

20250119_034715
20250119_0347151920×1081 59.5 KB

20250119_034726
20250119_0347261920×1081 60.8 KB

20250119_034734
20250119_0347341920×1081 55.5 KB

20250119_074307
20250119_0743071920×1081 67.1 KB

20250119_074317
20250119_0743171920×1081 51.8 KB