I’m trying to dual boot with Windows. I’m replacing a partition on which I previously had NixOs installed and then deleted that partition, and creating a new efi partition. But installation fails apparently when trying to create the new efi partition with this output : https://termbin.com/2wth
Outputs for lsblk
[liveuser@eos-2025.03.19 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 2.6G 1 loop /run/archiso/airootfs
sda 8:0 1 28.6G 0 disk
└─sda1 8:1 1 28.6G 0 part /run/archiso/bootmnt
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:5 0 260M 0 part
├─nvme0n1p2 259:6 0 16M 0 part
├─nvme0n1p3 259:7 0 377.7G 0 part
├─nvme0n1p4 259:8 0 1G 0 part
└─nvme0n1p5 259:9 0 98G 0 part
So this one?
No other disks in play?
Ok.. there is an existing ESP at /dev/nvme0n1p1.
It is also populated with windoze stuff.
And its having trouble accessing it as it is read-only.
Considering you are trying to create a new ESP (at ~nvme0n1p6) I dont know why its even touching the existing one. But it does seem to be the cause of the issue.
Use Manual partitioning (instead of “Replace a partition”) and point the installer to the new ESP (2 GB FAT32) and the new EXT4 partitions you have created for EndeavourOS.
If you want to use Grub, you need to mount ESP at /boot/efi and flag it boot.
If you want to use systemd-boot you need to mount the ESP at /efi and flag it boot.
Edited to add that for your EXT4 partition you choose the mountpoint /. No flag is needed.
Yeah I figured so too, thank you for the help anyways. Unless the devs can help me out here this probably means the end of my little Endeavour adventure
This is what i found concerning the error message.
However this topic is over a year old , and would mean that there is a longstanding bug in the main.py file of Calamares. Not sure the solution in the linked topic is stil working, or there is something else causing this error.
You rebooted after the failed first install?
you do set the boot flag on the EFI partition?
“job bootloader raised an exception.”
Must be something confused with the efi partition.
And the issue with the first try is basically something about fastboot not disabled and the EFI has a dirty bit caused by that.
Rebooted only after second failed install, and boot flag was set each time. Also I made sure fastboot was disabled before trying installation so that seems weird if that were the issue
Try removing the esp/boot flag from the the first ESP (using partitionmanager or gparted).
You can set it back afterwards because Windows needs that for its updates/upgrades.
Then do as you did before in Manual mode. You could maybe try to let it reformat those partitions as well.
but later there is a file missing that should has been written: ERROR: Error while running: FileNotFoundError: [Errno 2] No such file or directory: '/tmp/calamares-root-p2p24hmm/efi/loader/loader.conf'
It also calls proper detection for bootloader and the path it will use:
2025-05-04 - 14:04:54 [6]: The bootloader is "systemd-boot"
2025-05-04 - 14:04:54 [6]: virtual void PartitionViewStep::onActivate()
2025-05-04 - 14:04:54 [6]: The efi location is "/efi"
2025-05-04 - 14:35:23 [1]: ERROR: Error while running: FileNotFoundError: [Errno 2] No such file or directory: '/tmp/calamares-root-p2p24hmm/efi/loader/loader.conf'
At:
/usr/lib/calamares/modules/bootloader/main.py(268): create_loader
/usr/lib/calamares/modules/bootloader/main.py(565): install_systemd_boot
/usr/lib/calamares/modules/bootloader/main.py(900): prepare_bootloader
/usr/lib/calamares/modules/bootloader/main.py(936): run
2025-05-04 - 14:35:23 [1]: ERROR: Installation failed: "Bad main script file"
2025-05-04 - 14:35:23 [6]: .. - message: "Bad main script file"
2025-05-04 - 14:35:23 [6]: .. - details: Main script file /usr/lib/calamares/modules/bootloader/main.py for python job bootloader raised an exception.
it points out 4 lines in the script what looks to me like it simply fails completely, it does say “Bad main script file” but this will get logged also if the script is fine and something outside is not working properl.
I mean, it could be the ISO has a corruption, aka not properly synced, or using a tool to create install media that changed something on the file. In cases we see users using ventoy and ISO is not fully synced to the usb it can cause strange issues.
May also check efibootmgr from the live session in terminal to see if it properly boots in efi mode.
