Dual Boot Oddity

Post Reply New Topic

This query is of a very technical nature, and will probably be of pretty restricted interest, but I'm hoping there'll be at least one or two members who can assist.

I've just installed a dual booting set up on an Acer E1-571 laptop, the operating systems being Windows 8.1 and Linux Mint 20.3 XFCE. I'm about a decade behind the times in these matters, and don't really understand stuff like UEFI firmware or GPT hard drives, so before proceeding I switched the laptop's system from UEFI to 'Legacy' mode (which I assumed would emulate a traditional BIOS environment), and changed the hard drive from a GPT partition table to MBR - the Windows 8.1 installer refused to work with a GPT disk anyway. The usual outcome with a dual boot system installed under BIOS and MBR is that the Linux OS takes control, and places its GRUB bootloader at the start of the MBR, replacing the Windows loader, and the GRUB then serves to boot either system.

What happened with my installation was rather different. A UEFI-type EFI boot partition with a FAT file system seems to have been created in the Windows system, presumably containing the Win 8.1 bootloader, and GRUB seems to be within the Linux main partition. Both operating systems will boot up fine, but from their own loaders - you need to select the dual boot menu manually via the F12 boot menu, rather than it appearing automatically on starting up the laptop. Starting up the machine without doing so boots up Windows by default.

So I don't seem to have either a traditional BIOS-type dual boot here, and probably not a UEFI-type one. Is this some sort of freak hybrid? I would have expected the Linux Mint installer, if it knew what it was doing, to have placed GRUB inside the EFI partition, replacing the Windows loader, but apparently this hasn't happened. Any takers?

It seems that my previous analysis might have been somewhat off the mark, not surprising as I'm undoubtedly a bit out of my depth here! The dual boot screen is actually generated by selecting usb boot from the F12 boot menu, but this only works when the usb drive containing the Linux Mint iso is inserted- this would suggest that GRUB is being supplied from the usb, and may not be present on the HDD. This seems even more bizarre to me....

Also, the 'Disks' utility on the Mint OS identifies the HDD as 'MBR', so what is an efi partition doing on it?

Is this making any sense to anyone?

it takes some reading and patience and trial and error to get dual booting right.

It sounds to me that GRUB is not properly installed - or not installed at all.

https://en.wikipedia.org/wiki/GNU_GRUB

https://www.gnu.org/software/grub/

Try searching with google for phrases like "installing grub" or "configuring grub" and "dual boot" and other combinations of those words.

If it were me I would also want to brush-up on booting and related topics. I have provided some links below.

https://en.wikipedia.org/wiki/Booting
https://en.wikipedia.org/wiki/BIOS
https://en.wikipedia.org/wiki/Bootloader
● First-stage boot loader
● Second-stage boot loader
https://en.wikipedia.org/wiki/Master_boot_record
https://en.wikipedia.org/wiki/Multi-booting
https://en.wikipedia.org/wiki/GParted
https://en.wikipedia.org/wiki/GNU_Parted
http://freshmeat.sourceforge.net/projects/grub4dos




Booting a IBM PC Clone - or laptop (everything that is not apple) works like this:
The hardware has a flashable ROM (which you might be able to update with special software) or a non-flashable ROM. Read Only Memory (ROM).
The ROM contains just enough to read one chunk of data off of the hard disk - this can contain just enough software to read a few more sectors off of the hard drive (call it 4) and then that will actually read the rest of the OS from disk and start the OS.
The OS might be Windows or it might be Linux or other.
In the Linux world there is something called GRUB. GRUB is what presents a menu lets you choose an OS at boot time.
GRUB is called a boot loaded - it fits into that first sector - and/or the first 4 sectors.
The problem is this: Generally a computer NEEDS an OS to read a disk - this is why there used to be "DOS" in "MS-DOS".
If your machine has a floppy and/or a hard disk and/or a usb-flash-drive (etc) there needs to be enough software someplace to know how to access that hardware before you can read ANYTHING from it. CPUs are stupid and need ROM and/or RAM to tell them what to do. CPUs can ONLY read/write to memory (ROM or RAM). The PC/Laptop hardware makes it possible to access the disk or USB hardware by something called "memory mapping". This means that the CPU thinks it is just reading or writing memory but it is really triggering actions and reading from some kind of media. Each kind of disk and disk drive controlling hardware has slightly different was of doing this and the devil is in the details. The software that "knows" how to access a disk (HD, Floppy, CD, USB-stick, etc) is called a driver, and usually a plugin-module for an operating system, or a build-in part of an operating system. So you have a chicken and egg problem: which comes first? How to you load an OS off of disk if you need an OS to read off of disk. The name "boot strapping" comes from the idea that someone might "lift himself up by his own boot straps" as if you could actually lean over grab the leather straps on your boots and by pulling lift yourself up off the ground. It is literally impossible - unless you are a very talented acrobat. But the idea is one that people like. If someone comes to America with nothing but the clothes on his back and manages to find or create work, save money and build a life for himself and his family we say, idiomatically, "he lifted himself up by his own boot-straps".
So the PC / Laptop has ROM which is memory that keeps its values when when the machine is turned off. When it turns on, the CPU starts reading ROM and executing instructions. These instructions are called BIOS (Basic Input/Output System) and are like a very small OS. The BIOS knows just enough to read the second stage boot loader from the hard disk. The second stage boot loader is GRUB (for Linux or most Dual Boot set ups) and it can read the rest of the OS (Linux or Windows) and then transfer control the the code that is part of the OS. The PC has managed to lifted itself up by his own boot-straps.

You current situation is that your F12 screen gives you a BIOS menu - you are asking the BIOS to display the menu and wait for you to hit some keys on the keyboard - or use the mouse (etc) before going on the the next stage or booting. If you don't hit the F12 then the BIOS continues to its default behavior which is loading the second stage boot loader from the MBR (Master Boot Record) on the Hard disk - which at this point contains the Windows equivalent of GRUB - NTLDR or BOOTMGR depending on which version of Windows is installed (probably BOOTMGR for Windows 8 - but I am not sure) and then that loads windows. If you have Linux on the Hard Disk at all the second stage boot loader doesn't know it exists, so it will not load.

Once GRUB is properly installed you at least have chance of gaving GRUB replace BOOTMGR or NTLDR and then it will present a menu and ask you is you want to boot Windows or Linux - but only if you have made room for Linux on your Hard Drive and installed it - to do this you need to search for "Shrinking Windows Partition" and "dual boot" also "gparted".

The situation you currently have is a good starting place - if you can boot to Linux from USB - you can use that Linux to complete the remaining steps for getting Dual Boot to work.

A word of warning - since your current system works - you might want to find a way to back up all the data on your Hard Drive before you go any further - that way if you make a mistake you can revert to Back-up and try again.

Last edited by Fenn on 03 Feb 2022, 11:11 am, edited 1 time in total.

You may also find this page helpful:

● How to Install Ubuntu and Windows 8 Through Windows 11 as a Dual Boot on your Dell Computer

Or this page:

● https://help.ubuntu.com/community/Grub2/Installing


I haven't done a dual boot in a while - but if you try something and want to ask more question with your new results - post to this thread with your update.

You might also consider "grub2win"

● Grub2win - Installing Grub2win
● https://sourceforge.net/projects/grub2w ... g-grub2win

● Grub2win - Discussion (Support Forum)
● https://sourceforge.net/p/grub2win/discussion/general/


● How To Resize Windows Partition (to make room for Linux)
● https://www.diskgenius.com/how-to/resiz ... ows-10.php

^ Thanks for those very comprehensive replies, some very interesting and detailed information there!

After some more experimentation, I think I've worked out most of what's been going on. I'm pretty sure now that on my first try, GRUB ended up being installed to the usb installation drive (and in the process, all the Linux isos were deleted from there - it was one of those multi-boot Ventoy drives). That explains why I could only get the dual-boot screen when selecting the usb at the boot menu, and why only Windows could be booted from a 'normal' start up (the Windows bootloader being left intact in the efi partition).

I then made a second attempt, this time installing Linux Mint from a dvd, to try to force it to install GRUB on the hard drive. This was successful - a dual boot menu was now shown with a standard start up from the power-on button, and both operating systems could be booted from it. This setup still had an efi partition, to which I assume GRUB had been installed in place of the Windows loader.

I then decided, for certain technical reasons, that I would run Linux Mint as a virtual machine within Windows 8.1, and when I reinstalled the latter system on the whole hdd, I got a very normal looking BIOS-MBR installation. This is the only bit which now puzzles me: why did the first two procedures produce a UEFI-type installation with an efi partition, whereas the third one didn't? After all, I was using the same laptop with a 'Legacy BIOS' setup, and a hard drive initialized to MBR in each of the installations.

I can only offer guesses. Looking at your first screenshot and its position in the drive - I think the Mint installer created that efi partition for you. It might have done so automatically. It does look a little like a bad script or someone who doesn't know what they are doing partitioned that drive. Why use an extended partition just to fill it up with one? Weird, though I suppose it could be forward thinking for unusual scenarios.

In the installer's defence (assuming you didn't tell it to) - it makes some sense to assume uefi capability might be necessary these days and it shouldn't cause any harm to have an unused efi partition on a computer using the old master boot record method - except for a small amount of lost space.

If it was the mint installer acting with or without your permission, then that's your answer. You only installed windows this time.

UEFI can be looked at as two different things. UEFI is "like BIOS but newer" and UEFI is where the "GPT" (GUID Partition Table) specification came from.

Some BIOS that is NOT UEFI still uses GPT. I imagine that GRUB could even add support for GPT without support being in the ROM in the BIOS or UEFI. Since GPT is "from UEFI" you might find some people (and software) calling it "UEFI".

https://en.wikipedia.org/wiki/GUID_Partition_Table

"The GUID Partition Table (GPT) is a standard for the layout of partition tables of a physical computer storage device, such as a hard disk drive or solid-state drive, using universally unique identifiers, which are also known as globally unique identifiers (GUIDs). Forming a part of the Unified Extensible Firmware Interface (UEFI) standard (Unified EFI Forum-proposed replacement for the PC BIOS), it is nevertheless also used for some BIOS systems, because of the limitations of master boot record (MBR) partition tables, which use 32 bits for logical block addressing (LBA) of traditional 512-byte disk sectors.

All modern personal computer operating systems support GPT. Some, including macOS and Microsoft Windows on the x86 architecture, support booting from GPT partitions only on systems with EFI firmware, but FreeBSD and most Linux distributions can boot from GPT partitions on systems with either the BIOS or the EFI firmware interface."

If you reinstalled Windows 8 then you have replaced GRUB with BOOTMGR and if GPT support was coming from GRUB (GPT is better than old MBR partition tables - it can handle larger partitions and more partitions - so it may be the default for some installers / partition managers ).

This page seems to verify my hunch about Grub2 supporting GPT:

http://lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT

I may have just restated what Mikah already said - but I think I added some more detail.

Thanks for the reply, Mikah.That's interesting - you seem to be suggesting that in the case of my first two installations, a redundant efi partition was created, with the bootloaders taking up residence in the MBR. The snapshot in my first post shows the efi partition as 0.2% full, but those are presumably some other sort of system files?

The 'Ubiquity' installer, as used by Mint, Ubuntu and similar Linux distros, seems to install logical partitions by default, and so requires an extended partition in the case you mentioned. This is unless the user selects the 'custom installation', in which case primary partitions can be created. Likewise, Ubiquity offers the user no choice in specifying where GRUB is to be installed, and so one is at its mercy in these situations. One or two other Debian-based distros, like antiX, do offer this choice.


And thanks again Fenn for all the information and links. Not sure I'd ever be able to get my head around all that though. I tend to proceed by trial and error when dealing with such matters, and usually get things eventually to work, without always knowing quite why....

I've installed probably twenty or thirty dual-boot systems in the past, and this is the first time I've ever seen an efi partition being created. That's because nearly all my hardware is pretty ancient, and the ten year old Acer laptop is one of only two machines (out of forty) to have uefi capability.

That's my guess, but it is just a guess. I haven't used Mint or the Ubiquity installer before or Windows 8 for that matter.



All sorts of stuff can be placed in there, it's a shame we can't mount it and investigate it now. What the 0.2% is I am not sure, though that sounds a bit empty for a normal efi partition to me.

I came across these after you mentioned the name of the installer:

https://www.reddit.com/r/Ubuntu/comment ... ed_an_efi/
https://www.kubuntuforums.net/forum/gen ... ikes-again

My guess might be correct. "User-friendly" installers making choices for you, assuming you won't mind.