Installed Ubuntu in BIOS mode, can't access BIOS anymore [closed]

Question

Just wait a minute before flagging this as off-topic. I can't believe this is not Ubuntu-related since everything happened just after my Ubuntu installation.

With this said I'll go on explaining what is happening:

I downloaded and installed the latest version of Ubuntu. I wanted a BIOS mode since I prefer this way and completed the installation process. Then I installed GNOME and rebooted. I lost access to my bios after all of this.

This is not the first time that has happened. It happened in the past and I solved switching boot partition in boot-repair using my secondary HDD but now I can't do that any more because I do not have a Windows partition on that drive.

This is my drive:

Disk /dev/sdb: 119,2 GiB, 128035676160 bytes, 250069680 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcaa3841c

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1  *     2048 250068991 250066944 119,2G 83 Linux

When I tried boot-repair, at the end of the process it said I had to make a 500mb partition at the beginning of the partition list so that grub could work properly but hey, here's another problem:

GParted stopped working. This is the error if I try to launch it:

Created symlink /run/systemd/system/-.mount → /dev/null.
Created symlink /run/systemd/system/mnt-Archive.mount → /dev/null.
Created symlink /run/systemd/system/mnt-Linux\x20Games.mount → /dev/null.
Created symlink /run/systemd/system/run-user-1000.mount → /dev/null.
Created symlink /run/systemd/system/tmp.mount → /dev/null.
/usr/sbin/gpartedbin: error while loading shared libraries: libgtkmm-2.4.so.1: cannot open shared object file: No such file or directory
Removed /run/systemd/system/-.mount.
Removed /run/systemd/system/mnt-Archive.mount.
Removed /run/systemd/system/mnt-Linux\x20Games.mount.
Removed /run/systemd/system/run-user-1000.mount.
Removed /run/systemd/system/tmp.mount.

I want to mention that:

• yes I'm sure I'm using the right button to enter the bios
• no there is no bios splash screen
• no, nothing happens if I spam the DEL key to enter the bios
• yes the key works fine
• yes I tried to unplug every drive
• yes I tried to reset CMOS
• yes I installed the OS in BIOS mode, I checked via terminal.

This is the output from boot-repair

This is the message alert saying that I need to make a partition to properly boot:

The boot files of [The OS now in use - Ubuntu 17.04] are far from the start of the disk. Your BIOS may not detect them. You may want to retry after creating a /boot partition (EXT4, >200MB, start of the disk). This can be performed via tools such as gParted. Then select this partition via the [Separate /boot partition:] option of [Boot Repair]. (https://help.ubuntu.com/community/BootPartition)

Answer 1

I've seen quite a few reports since the switch from BIOS to EFI about EFIs refusing to launch their setup utilities. I haven't tracked these closely enough to recognize patterns (say, does a specific firmware vendor or motherboard/computer brand have more problems than others?), but this definitely qualifies as a firmware bug, not an OS bug. That said, it may be triggered by changes made by the OS to firmware settings such as the boot order. The unusual thing in your case is that you've done a BIOS/CSM/legacy-mode install, which means that the OS installation should not have made such changes. My guess is that your change from EFI-mode to BIOS-mode booting in the firmware itself has caused the bug to manifest; or perhaps changing some other firmware setting did it.

There are several ways to work around this problem, such as:

• You can unplug your hard disk and boot the computer. This normally causes it to launch the setup utility.
• If you boot Ubuntu in EFI mode (say, the installer booted in this way), typing sudo systemctl reboot --firmware-setup in a shell should reboot into the firmware setup utility.
• Some EFI-mode (but not BIOS-mode) boot managers provide an option to boot into the firmware setup utility. GRUB has this functionality, but I'm not sure if it's enabled by default in Ubuntu, and as you're using the BIOS-mode version, this point is moot. You can, though, use my rEFInd boot manager on a USB flash drive or CD-R (there are download images for both on the page to which I've just linked). The option should appear on the second row of (smaller) icons. You can also use rEFInd to boot your regular installation to EFI mode to use systemctl, if you like.

Note that Boot Repair is very unlikely to solve the problem, since it's caused by issues in the firmware before GRUB (or anything else provided by Ubuntu) takes control of the computer.

Once you're in the setup utility, using the option to reset the firmware to its defaults is likely to fix the problem, but I can't promise that. Given your configuration, you'd need to either switch the CSM back on or add an EFI-mode boot loader to the disk to get booting again, and either procedure runs at least some risk of re-creating the problem.

As this is a firmware bug, looking for an update from the manufacturer is worth doing. If there is no update, I recommend you report the bug; manufacturers can't fix bugs if they don't know they exist.

Note that this case illustrates one advantage of booting in EFI mode: There are ways to get into the firmware setup utility from the boot manager or OS. EFI-mode booting is also usually a little bit faster, it's less restrictive on large (over-2TiB) disks, it supports Secure Boot, it's the native boot mode on modern hardware (meaning it's less likely to create confusion, as described on this page of mine), and it has some other minor advantages over BIOS-mode booting. For these reasons, I generally recommend EFI-mode installations on new hardware unless there's a compelling reason to do a BIOS-mode install.

You can safely ignore the complaint about boot files residing far from the start of the disk. That's been a recurring problem with BIOSes, with the definition of "far" changing over time. Your disk is only 119.2 GiB, with the caveat that you've shown output for /dev/sdb but not /dev/sda, so if /dev/sda is bigger and the boot loader is installed there, it could be an issue. On most modern computers, I'd expect the BIOS (or EFI's CSM) to be able to read up to 2 TiB, so any disk smaller than that should be OK.

I suspect that your GParted problems are unrelated to anything else, but they are troubling. They could indicate a disk that's failing -- but it's more likely random filesystem corruption, particularly if the computer has hung or completely crashed at any point. I strongly recommend you look into this, but as I suspect it's a separate issue from your main problem, I won't provide advice on this here.

Answer 2

I solved the issue like this:

1. Turn off PC.
2. Unplug the power cable.
3. Unplug videocard and ram
4. Unplug mobo battery
5. Use a screwdriver to reset CMOS
6. Press the power-on button to de-charge the motherboard
7. Re-plug mobo battery, power cable and video cable (to the motherboard)
8. Use only one stick of ram in the slot 1
9. Turn on PC and wait for the BIOS splash screen
10. If the BIOS shows up, turn off the PC, re-plug everything back and access the BIOS
11. If the BIOS does not show up repeat from 1. and wait 15-20 minutes before plugging everything back

It was indeed a partition issue when I first installed linux on my SSD. Somehow Ubuntu thought it was in UEFI mode even if I installed it in Legacy (BIOS) mode so it was looking for the boot partition with grub. When I clicked on 'Erase everything and Install' when I first installed Linux, the installer did not make additional partitions for Ubuntu (this because I indeed booted the installation drive in Legacy mode!).

I suggest to make a backup of your drive and make a clean install.

To prevent errors for the future use the custom installation mode not matter if you are installing in UEFI or Legacy (BIOS) mode:

1. Make a new partition table deleting all the previous partitions
2. Make an additional primary 500mb partition (from the freespace) flagged as 'EFI partition'
3. Allocate all the freespace (if you want you can leave more free space for a swapspace) to the OS formatting it as ext4 primary partition and using / as mounting point.
4. Set the drive where you made the 500mb efi partition as path where Ubuntu can install grub (example: if your drive is /dev/sda and your efi partition is /dev/sda2, still choose /dev/sda as partition!)
5. Click on the biggest partition you made from the list and finally click on Install.