This is with the replace existing partition option during the OpenMandriva installation.
Boost.Python error in job “Bootloader”
<div><strong><class 'FileExistsError'></strong></div><div>[Errno 17] File exists: '/tmp/calamares-root-4bcxneze/boot/efi/EFI/Boot/bootx64.efi'</div><div><br/>Traceback:</div><div><pre>File "/usr/lib64/calamares/modules/bootloader/main.py", line 777, in run
prepare_bootloader(fw_type)
File "/usr/lib64/calamares/modules/bootloader/main.py", line 748, in prepare_bootloader
install_grub(efi_directory, fw_type)
File "/usr/lib64/calamares/modules/bootloader/main.py", line 657, in install_grub
shutil.copy2(efi_file_source, efi_file_target)
File "/usr/lib64/python3.11/shutil.py", line 436, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/usr/lib64/python3.11/shutil.py", line 258, in copyfile
with open(dst, 'wb') as fdst:
^^^^^^^^^^^^^^^</pre></div>
I do not remember using the “Replace” partitioning. So I set up a test case with ext4 root partition. The computer is UEFI boot. This screen-shot shows how it should install:
And that installation was successful. So we need more information to troubleshoot your problem. Information on how to troubleshoot broken installation is here. In this case I would suggest to install from Konsole with this command:
$ pkexec calamares -d | tee /home/live/calamares-installation-log.txt
And post the created file calamares-installation-log.txt here.
Another question is file system type? Right now installing with f2fs results in boot loader not being installed. I suspect btrfs could also be a problem with installations of this type. ext4 is the OM default because it tends to be the most reliable and works in most use cases.
Note: The problem with f2fs is not anything wrong with f2fs. Calamares installs the operating system. Then something is not recognized and the boot loader does not install. An advanced user could install the boot loader usint chroot or ssh. This problem has the attention of our developers.
I’m using a Ryzen 9 3900x 12-core. It appears the same issue was reported 14-days ago too as a Installation issue by Zaivala.
I’ve got 13 different partitions with Linux installations using a common EFI partition for boot. All distros are configured with Grub but I’m typically using Refind as my boot manager. OpenMandriva has created two subdirectories in the EFI partition – “OpenMandriva_Lx_[GRUB]” and “openmandriva”. “openmandriva” contains grub.efi. "OpenMandriva_Lx_[GRUB] contains grubx64.efi. The error message submitted seems to indicate a file exists where it wasn’t expected to and you are not handling that error. Every distro seems to have their own way of doing things but they contain it to their own subdirectory. The only potential common one I see is called “Boot”. It contains:
We still need to see the calamares-installation-log.txt to get to the what and why of this. All of it.
Or perhaps “Manual partitioning” instead of “Replace” would work better in your setup. With “Manual partitioning” to reuse an existing root partition with the same fs type select to format. If you wanted to change the fs you need to delete the partition and create a new one with the new fs type.
My personal opinion and recommendation is for multi-booting OMLx with other operating systems use only ext4 or maybe xfs.
My first suggestion would be to try using Manual Partitioning instead of Replace a partition. Be sure to set mount point for /boot/efi and be sure that boot flag is selected for /boot/efi.
I understand that our script seems to have found a file that it thinks should not be there, but I do not understand the why of it. One guess is there is something about how Refind does things that we need to adjust for. If so we certainly want to fix that.
OpenMandriva contributor group is a very small group of part-time, unpaid, volunteers. You caught us when they are buried under a number of different things like day jobs, ect. Apologies for that.
OK this is me a user not a developer working through this and I see the file causing the problem is /boot/efi/EFI/Boot/bootx64.efi. That seems what "UEFI Fallback: True" is choking on. That can be changed to False on the ‘Live’ iso in /etc/calamares/modules/bootloader.conf on line 54.
On my hw UEFI boot occurs usually with /boot/efi/EFI/opemandriva/grubx64.efi. I think I remember sometimes seeing /boot/efi/EFI/'OpenMandriva_Lx_[GRUB]'/grubx64.efi used. But I am pretty sure something with bootx64.efi is not going to boot. I am going to test this on my desktop straight away.
I did the test on an existing test system on hw using a ROME iso. On the ‘Live’ iso I edited /etc/calamares/modules/bootloader.conf to say "UEFI Fallback: False". Used Replace a partition.
The difference in the calamares installation log is one line. Test system:
So @mlcarson this just might work for you. Apologies for the inconvenience. I do wonder if this is a bug that needs to be fixed or a peculiarity of Refind or your particular system? There are settings that need to be a certain way for most systems but need to be changed occasionally for some circumstances like this one.
