Workaround worked but install still failed

Support
1

Hello,

  • OpenMandriva Lx version:
    Latest ISO from SourceForge – Rome

  • Desktop environment (KDE, LXQT…):
    Never got to that point

  • Description of the issue (screenshots if relevant):
    With past attempts at installing I never reached the Live execution as my screens turned black. I found working with other installs that removing my second monitor during the install process helped and that helped with this build as well.

So I finally got to see the live execution and went on to do the install.
Screens came up, the install application ran, I filled out my name, id, machine, pw’s and started the installation process. I had it replace my Mint partition with OpenMandriva. It was close to 3/5 done and I got the error window:

Installation Failed
Bad Main Script
Details:
Main script file /usr/lib64/calamares/modules/bootloader/main.py
Job bootloader raised an exception.

At this point everything stopped. The developer was too amateurish and failed to provide details of what the exception was and any relevant information to aid in debugging. And I am not interested in “try this version instead” stuff. It installs and blows away my OS drive and blows away my boot partition so that I cannot boot.

  • Relevant informations (hardware involved, software version, logs or output…):
    # MINISFORUM 795S7 Mini Tower Gaming PC AMD Ryzen 9 7945HX(16C/32T) Computer 32GB DDR5, 1TB PCIe4.0 SSD, 2TB PCIe4.0 SSD, 1x PCIe5.0x16, M.2 2230 Key E Slot, 2.5G LAN, HDMI+DP+USB-C Outputs with RTX 4060 Graphics
2

How are you writing the iso to your usb drive? What workaround did you find?

3

Can you try this?
Boot to live mode, open /etc/calamares/modules/bootloader.conf in kwrite, nano or any other editor, find the line InstallUEFIFallback and change true to false, then start up the installer and try installing as you normally would

Also how did you flash the image? I recommend using balenaetcher instead of ventoy or rufus

4

I used dd to create the USB. I seem to remember I was told to do that the last time I tried.

My workaround:

I normally have my DPI monitor and my HD monitor plugged into my NVidia card. That yields a black screen without any live execution. By unplugging my HD I found that the software booted into live execution which then allowed me to attempt an install.

5

Yes, I can try it. But shouldn’t a “working build” be able to handle all situations for installation without the need to edit a file critical to installing the operating system?

And in answer to your question: I used dd to write the USB.

6

I had issues with dd and Ventoy, 100% succes with Balena etcher.

7

Afaik this only happens on certain configurations and with certain conditions including mine, I’ve had a similar issue with OM failing to copy grubx64.efi to ESP since the file already existed, probs placed by my previous fedora installation

I give OM a break since it is more obscure, and the team and the community are way smaller, more papercuts and quirks to fix here and there.
Consider making a bug report on their github issue tracker if this gets resolved

8

can you recheck option UEFI

  • secure boot off
  • CSM off
  • fast boot off
  • no legacy
  • all disks on AHCI

can you please provide from boot USB live iso
open a kconsole

inxi -Fza 
sudo parted -l 
test -d /sys/firmware/efi & & echo UEFI || echo BIOS

and launch install with windows debug

sudo calamares -d
9

Well as I have reported I had no issues with the USB that I created. It worked just fine.

10

Well, as I said I encountered many anoying issues, including weird script errors with calamares at different stages of the process, with USBs created with DD and Ventoy, everything went totally fine as soon as I used Balena Etcher.

1 Like
11

I don’t use dd because I ran into a weird thing where it would say complete, but disk activity was clearly not done. I noticed it after several failed installs. I couldn’t find any other reports of it online, so I switched to BalenaEtcher and eventually ventoy.

Getting the live iso to boot does not necessarily mean that all is well.

As others have said, OpenMandriva has been a very small team for most of its life. They have had a very limited range of hardware and install situations to work with. Giving your full hardware list and detailed explanation of what you encounter can help them to get this solved on the back end, if it is possible. Although, it could still be the way the iso was written or bios settings.

1 Like
12

I used dd to create the bootable media and it work on 3 different laptop and on my gaming desktop you might want to try it this way

sudo dd if=/path/to/iso of=/dev/sdb bs=4M status=progress

of course chage the device “of” to the one that matches your sub device.

13

There is no way we could possibly test every single hardware configuration to provide something like this. Other distros also will not install flawlessly on some hardware. Exotic hardware configurations or existing partitions with unsupported filesystems will most likely cause issues like this.

1 Like