Maybe a procedural misunderstanding.
You have already formatted sda1 to ext4, so, leaving it unformatted would mean it would still be formatted as ext4.
IIUC, you should delete partition sda1 and recreate it (at the same place). Then, modify flag to bios_grub leaving it unformatted.
You could repair the installation with the above advice. Make sure drive names are the same (sda has EnOS, or change bellow commands accordingly)
Boot to installer
Launch GParted
Delete sda1, recreate it and flag it as bios_grub and unformatted
Chroot to the existing installation
mkdir /mnt/repair
mount /dev/sda2 /mnt/repair
arch-chroot /mnt/repair
Oh, you mean EnOS ISOs? I had no idea.
Nevertheless, the advice was following the Arch Way, for repair an existing installation with failed bootloader installation. It should do the job, according to the userâs feedback.
Or we could identify the actual problem, and maybe help solve the ISOs problem.
Is there a web accessible discussion about the ISOs issue, so I can have a glance?
I didnât realize it was from an Arch install and no there is no accessible discussion about the issue. Itâs just come up over some time. It used to work using gpt disc with 8 mb unformatted and flagged bios_grub. But in recent changes to Calamares or some other package has caused it to not work. I donât know the reason why but itâs something that i canât figure out. Iâm not that deep into it as my knowledge isnât in the development. I just help with what knowledge i have and resources.
Edit: You could try it in vm and see what you get?
Itâs not the first time.
IMO Calamares is the worst developed Linux installer. I stopped trying to make it better very long time ago.
I am only interested to help people who are victims of this garbage software.
Whoever gets offended with my comments, donât. I am just a silly big-mouth guy.
I have not got it to work at all on vm. I just tried it again and it will not boot the installed system. I havenât tried on bare metal. I donât get it?
Thatâs just an extra feature of GParted, I guess. The partition has no file system, so relevant disk utilities wouldnât count it as with-content. It seems GParted likes to do more (knowing about the GPT/GRUB/Legacy case) and shows a file on an empty drive space (no FS), just for fun perfectionists.
So, if there is no problem, maybe @ricklinux has something different in his test beds . Maybe we can look into it in another topic?
Now I see a weird thing in your log (and images).
The bios_grub partition is reported as FSTYPE=vfat/FAT32 in lsblk output, and also has a proper FAT32 UUID assigned. That should not happenâŚ
I suggest you all compare utilities versions on System, VM, ISO, whatever is involved.
looks screwed indeedâŚ
Could because of it holds fat32 efi partition before on that place and is now âemptyâ so it will not reformat in this case? So output is simply wrong bet or reading data that is left there? (no clue) as fdisk shows it correctly.
Thank you all for your replies. Admittedly some of the technical aspects of what was discussed is beyond my capacity to understand, but I will attempt to do some of the steps outlined in some of the replies and report back on the results.
I was thinking that the issues that I am having could be a result of my BIOS. I did some research into my motherboard model and found a manual. Notably, the settings to switch certain things to legacy only (as seen in images in the manual) are not present when I open up the BIOS settings. This could be the result of the version installed currently is newer than what is shown on the manual (the manual dates to 2014, whereas the BIOS version installed is from 2015). It is - however - not the latest version, with the last update being from 2017. If all else fails I may try to update my BIOS (I hope nothing goes wrong with doing that).
I also considered secure boot being a problem, however that does not seem to be likely. Firstly it does not appear to be an option at all with the BIOS I have installed and secondly if I remember correctly when trying to install Linux onto a laptop with secure boot it would not even boot into the live environment, which is no issue on my computer.
Lastly would you all consider it be worth trying to boot into the live environment with NVIDIA drivers? I am not sure how related this is to the issue though, and I cannot select the boot option when booting into the live environment since no keyboard keys change the boot option selected (it works on my laptop though).
This does seem to be related. If this is the case, would potentially a different Linux distribution not have this issue (and thus possibly installing easier on my computer)?
WARNING: [PYTHON JOB]: âNon-EFI system, and no bootloader is set.â
Can you verify, or explain the GUI process and if there was an option to select a bootloader?
IIUC there should be no selection for a bootloader, since the only bootloader that is capable of handling BIOS Legacy boot, on GPT drives is The GRUB. The one and only!
Either Calamares is that dumb, or EnOS scripts may need some modifications.
If I remember correctly in Calamares I am given the option to select install GRUB or no bootloader, however GRUB is defaulted to on. I can verify this later today. If it is not installing despite being selected, would I have to install the bootloader manually?