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
File "/usr/lib64/calamares/modules/bootloader/main.py", line 748, in prepare_bootloader
File "/usr/lib64/calamares/modules/bootloader/main.py", line 657, in install_grub
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:
Welcome @mlcarson to OpenMandriva and our forum.
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
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
ssh. This problem has the attention of our developers.
Just noticed this:
We are assuming you have a Zen cpu if you are using znver1.
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
Posted something relevant to this issue here.
The partition being replaced is an EXT4 partition so no issue there.
calamares-installation-log.txt (112 KB)
Thanks, I have a question posted for developers in the OpenMandriva Cooker matrix channel.
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
I have asked developers here.
This issue needs a bug report.
Anything I say would be guessing. Why does the log say:
[PYTHON JOB]: "Bootloader: grub (efi)"
.. Running ("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]: " .. installing 'bootx64.efi' fallback firmware"
[Errno 17] File exists: '/tmp/calamares-root-67irqaw_/boot/efi/EFI/Boot/bootx64.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.
Another suggestion coming in next post.
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:
2022-11-07 - 20:06:45 : [PYTHON JOB]: "UEFI Fallback: False"
2022-11-07 - 20:06:45 : .. Running ("grub2-mkconfig", "-o", "/boot/grub2/grub.cfg")
2022-11-07 - 20:06:51 : .. Finished. Exit code: 0 output:
Generating grub configuration file ...
Another recent ROME install:
2022-10-30 - 18:57:33 : [PYTHON JOB]: "UEFI Fallback: True"
2022-10-30 - 18:57:33 : [PYTHON JOB]: " .. installing 'bootx64.efi' fallback firmware"
2022-10-30 - 18:57:33 : .. Running ("grub2-mkconfig", "-o", "/boot/grub2/grub.cfg")
2022-10-30 - 18:57:37 : .. Finished. Exit code: 0 output:
Generating grub configuration file ...
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.
A quick how to is posted here.
Edit: This works on my desktop I hope it works for users with this issue. Please do let us know if this works or not.
Modifying the bootloader.conf file to set installEFIFallback to false worked.
Thanks for the work-around.