Dual boot installation only boots into Windows

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)

  1. Boot to installer
  2. Launch GParted
  3. Delete sda1, recreate it and flag it as bios_grub and unformatted
  4. Chroot to the existing installation
mkdir /mnt/repair
mount /dev/sda2 /mnt/repair
arch-chroot /mnt/repair
  1. Install grub bootloader
grub-install --target=i386-pc --recheck --force /dev/sda
  1. Exit chroot
exit
  1. Reboot

I don’t think the installer will work with bios mbr on gpt unless you use erase disc.

Edit: I think it only works with dos disk and mbr.

I think you need vacations, or a break ASAP!
:rofl:
Or maybe it’s I who needs some break :beach_umbrella:

Not sure what you mean. All the testing showed that there is an issue with the installs on gpt disc in bios mode. I know because i did them. :slightly_smiling_face:

Edit: Try it yourself in vm if you like. :wink:

1 Like

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 will not start getting offended by @petsam ( i am not, i totally understand your point, and respect this)

But i must add that using GPT Partitionscheme on Legacy/Bios Boot is totally working with current installer.

I have done endless installations in VMs and on real Hardware.

Using manual partition Option:

  1. recreate drive using GPT
  2. create an 8MB empty partition flagged as bios-grub
  3. create RFS / using what ever works for linux ext4

log: https://0x0.st/X9jf.txt

only gparted shows the grub-core-image:

1 Like

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? :thinking:

Edit: Install log

https://0x0.st/X9jF.txt

Edit: Not doing anything different on vm using manual partition scheme.

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. :man_shrugging:

So, if there is no problem, maybe @ricklinux has something different in his test beds :man_shrugging: . Maybe we can look into it in another topic?

1 Like

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.

util-linux
gparted
fdisk
calamares
...
 Starting job "bootloader" ( 38 / 43 ) 
/usr/lib/calamares/modules/bootloader/main.py:401: SyntaxWarning: invalid escape sequence '\$'
  prefix, generator_name = re.match("(.*)\${([^}]*)}$", name).groups()

WARNING: [PYTHON JOB]: "Non-EFI system, and no bootloader is set." 

no bootloader is set

1 Like


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.

Rick has different output:

this seems to be realted to this :beetle:

Also we had no indication it will happen with GPT partition tables too on testing.
Could be also accidently sliding it off.

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)?

I just attempted to do this however sadly the same issue is still occurring. I shall try out the other methods posted below.

I attempted a manual install doing this, however to no avail. The installation GUI gave a message stating that GPT drives will require the 8 MiB bios_grub partition. Here is the installation log if you wish to look over it - https://privatebin.net/?abce8413d5bd08f4#9mXiXHj4twcMpAYp8Af3eGT76kj1vxzjje7xC4GAnPDj

Your logs say you have not selected a bootloader.

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. :person_shrugging:

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?