Triple Boot problem

TLDR: My BIOS no longer recognizes my Garuda partition, although the Garuda partition seems perfectly fine. Boot repair on a USB was unable to mount /boot/efi with ESP when I tried to fix this.

I originally was dual booting Windows 10 and Ubuntu, and I recently decided to try out Garuda dr460nized KDE on a third partition. Everything installed fine and worked fine.

Due to a relatively unrelated issue, I had a temporary config issue that ultimately led me to reboot the computer with the power button, (the screen was nothing but black upon logging in, but turning the computer off and on again with the power button fixed it). Afterward, everything worked fine (with Windows, Ubuntu, and Garuda), except that I noticed I was unable to access my BIOS with F2, which I had previously been able to do.

Ultimately, I ended up booting Windows in recovery mode. This allowed me to access the BIOS again, however BIOS only recognized the Windows and Ubuntu partitions. The Garuda partition seems fully intact, though. I can still access my files in Garuda from Ubuntu, and a USB with Garuda was able to see my Garuda partition and let me boot into it.

My goal is to fix my BIOS so that it sees my Garuda partition, so that I don't need a USB to access the Garuda grub menu. When I tried using the boot repair from a USB, it was unable to mount /boot/efi.

Any help would be appreciated. I'm relatively new to using Linux. I don't want to always have to boot garuda from a USB, nor do I want to have to reinstall the entire OS every time I need to use Windows recovery mode.

logging in means what? User login / BIOS login (if you'd set BIOS password) / ...? If you mean user login after booting into Garuda (from SDDM / TTY / ... ) then cannot create problems with BIOS.

This means you're BIOS got corrupted or updated. Have you recently updated BIOS? If that's done without completing, then this might happen. It may also be that you installed wrong version of BIOS. That's why you should specify what you did to make this happen. This is related to BIOS, not Garuda and Garuda can't fix it.

This problem happened to me too. Maybe this is from Garuda's side :man_shrugging:.

This is maybe related

When I tried to mount with sudo mount /dev/sda1 /mnt it didn't mount giving an error (I don't remember it but it was something with filesystem). But udisksctl mount -b /dev/sda1 mounted it successfully.
You may try just mounting the EFI partition with udisks and check if you have Garuda's entry.

you can contact your laptop/desktop manfacturer he may help you

To clarify, BIOS works fine now after booting into Windows recovery mode. It's just that Garuda is no longer visible in BIOS. BIOS only shows my Ubuntu and Windows partitions, as well as a USB if plugged in. However, using a USB, I'm still able to boot into my original Garuda partition by selecting "Detect EFI bootloaders" from the first Welcome to Garuda menu on the USB.

User login into Garuda. This occurred after I changed my /etc/profile in an attempt to get chinese input to work. I have no idea what the BIOS issue was originally from.

When I tried udisksctl mount -b /dev/nvme01p1 (the EFI partition) while running Garuda on the USB, it gave me an error saying something like it was unable to find that partition.

You can reboot to UEFI from Garuda.

System Settings => Starting => Desktop Session => (checkbox) Enter firmware setup on reboot

BIOS was not broken by Garuda. Only WinOS does this and also messing with default boot OS (which every OS does) without user confirmation.

You just need to confirm what is missing from $ESP and UEFI and re-install as necessary. (grub and/or efibootmgr)

Post actual info:

efibootmgr -v
cat /etc/fstab
ls -l "/boot/"*
ls -l "/boot/efi/"*
sudo sed -n '/initrd\|vmlinuz\|menuentry/p ' "/boot/grub/grub.cfg"
3 Likes

I ended up reinstalling Garuda. It worked for a bit, but then windows crashed at one point, and holding the power button caused windows recovery mode to kick in and mess with my BIOS again. Note that I had backed up my original EFI partition, but it seems Garuda boot repair only restores for MBR or PBR, and not ESP. Here are the results from running those commands from the installation USB.

efibootmgr -v

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 2002,2003,2001,0002,0000
Boot0000* ubuntu        HD(1,GPT,1047a211-8900-44b7-807f-60b7f59956ca,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)RC
Boot0001* USB HDD: KingstonDataTraveler 3.0     PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/HD(1,MBR,0x0,0x492f64,0x2000)RC
Boot0002* Windows Boot Manager  HD(1,GPT,1047a211-8900-44b7-807f-60b7f59956ca,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...-................
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

cat /etc/fstab

File: /etc/fstab
#
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
/dev/mapper/root-image /             auto      defaults           0      0

ls -l "/boot/"*

.rw-r--r--  41k root 28 Apr 07:31  /boot/amd-ucode.img
.rw-r--r--  54M root 20 May 14:44  /boot/initramfs-linux-zen-fallback.img
.rw-r--r--  29M root 20 May 14:44  /boot/initramfs-linux-zen.img
.rw-r--r-- 3.6M root 17 Feb 08:15  /boot/intel-ucode.img
.rw-r--r--  10M root  7 May 10:48  /boot/vmlinuz-linux-zen

/boot/memtest86+:
.rw-r--r-- 150k root 16 May  2020  memtest.bin

ls -l "/boot/efi/"*

fish: No matches for wildcard “"/boot/efi/"*”. See `help expand`.
ls -l "/boot/efi/"*
^

sudo sed -n '/initrd|vmlinuz|menuentry/p ' "/boot/grub/grub.cfg"

sed: can't read /boot/grub/grub.cfg: No such file or directory

I'm guessing you've heard the quote about insanity being the repetition of the same actions, yet expecting a different result. :rofl:

The reason we generally refrain from providing official support for dual booting with Windows is precisely for these issues. Windows is prone to breaking Linux installs. If you insist on installing Windows this is your cross to bear not ours.

Summary

Oh no, this isn't your system's, it's just your live USB's. To get your system's, you should enter it in garuda-chroot

Anyways,

This :point_up_2: is the thing that every Windows dualbooters should do. Hope you're able to restore it.

Wow, what a verdict!

Too many failures in a very short time. It seems it's either a PEBCAC, or a firmware (BIOS/UEFI) wrong setting/operation.

I suggest you troubleshoot slowly, as speed increases failure possibilities.

There are many strange things in your reports, so maybe it is not meant for you using Garuda in multiboot with WinOS. :man_shrugging:

4 Likes

@johngilbert2000 some of your statements just aren't making sense.

For one thing, Windows does NOT modify your BIOS; the only way it could, is if you're running a BIOS update from windows -- but it's the bios update modifying your bios, not windows.

My BIOS no longer recognizes my Garuda partition

The motherboard's BIOS recognizes hard drives, not partitions; the operating system(s) manages partitions.

Ultimately, I ended up booting Windows in recovery mode. This allowed me to access the BIOS again...

This is another statement that doesn't help to clarify the problem you're having. Windows has nothing to do with your BIOS, entering 'recovery mode' should have no impact on getting into your BIOS screen at boot to change settings.

Being able to get into your "F2" boot screen to view/change BIOS settings has NOTHING to do with Windows; BIOS settings are stored on the physical motherboard, not in Windows.

IMO: You're asking for trouble trying to run 3 OS's on one computer. Do you have two hard drives?

Installing a 2nd Linux using the same boot (EFI) partition might be causing some grub files to be overwritten; you may need to manually add Garuda's boot information grub.

How to Edit GRUB with GRUB Customizer:

DOES YOUR GRUB MENU GIVE YOU THE OPTION TO BOOT INTO Windows, Ubuntu, AND Geruda?

Windows, Ubuntu, or Garuda CANNOT modify your BIOS; only you can do that.

Windows recovery mode is for repairing windows, or to make it boot; nothing more -- not to repair Ubuntu or Garuda.

I wish you luck.

2 Likes

If you use grub-customizer, please, use the link above for help if necessary.

Summary

Grub-customizer - #38 by tbg

2 Likes

6e582ffbd2a8d2e89e6ffb33858ac5f97154bf5b

1 Like

why not use 2 or 3 hdds for each system and boot separate from each
best method

when you have uefi it is very difficult for linux to break the win10 uefi cause windows don't like other systems

and 3 partitions on one hdd is a desaster vor grub because win uefi makes a kill for that

1 Like

Thank you everyone for your replies. I think I'll just stick with Ubuntu and Windows dual booting for now, because that seems to not be giving me any issues. I will say Garuda was fun to play around with, and if/when I feel that I don't need Windows, I will probably switch to Garuda.

Yes, until I press and hold the power button for 10 seconds. Then Garuda disappears from the BIOS, and the only grub menu I can access is my original Ubuntu grub menu, which only contains Ubuntu and Windows. (Note, however, that if I boot from a Garuda installation USB, and select "Detect EFI bootloaders," then I can still select my original Garuda efi and access my original Garuda grub menu).

Well, when I press and hold the power button for 10 seconds, my BIOS reverts to factory settings. I had assumed that that was from Windows recovery mode, but I suppose I could be wrong. (For example, AHCI switches back to Optane without RAID, Windows Fast Boot and Secure Boot get turned on, Windows gets moved to the top of boot priority, and Garuda Linux disappears entirely in the BIOS, etc.). It would be nice if I knew how to turn off this behavior.

Unfortunately I do not have extra HDDs in this laptop, but I will keep that in mind for the next computer I buy.

Yeah...

It's easy. Don't do this.
You can select any installed OS using Quick Boot menu, that any UEFI/BIOS provide (you have to find the key combination). Have you read the User's manual?

3 Likes

Technically, doing a HARD reboot (holding the power button for 10 secs), should NOT ever reset your BIOS back to factory settings; I've never heard of that happening before.

A soft reboot is using your UI or terminal to reboot the computer normally. A hard reboot risks you loosing data and/or corrupting files; especially in Windows.

BIOS (Basic Input/Output System), is firmware that is -- literally -- physically mounted to your motherboard; it has nothing to do with your operating system.

If Garuda disappears from your boot options, that's your boot-loader (GRUB); or another problem -- not your BIOS.

A hard-reboot should not reset your BIOS. I'm not sure what's wrong, but something isn't making sense here.

Does your BIOS sometimes seem to reset back to defaults, even when you have not done a hard reboot? Hard reboot being, holding down the power button for about 10 secs until it powers off.

HDD:

You said you're using one physical HDD correct?

Are you using a GPT or MSDOS partition table?

If you have a single HDD, it's likely "sda" in your partition manager. Please check to see if you're using GPT or MSDOS parition table; if you don't know.

fdisk -l /dev/sda

This command will list your partition table and partitions, please post the results...
For reference: fdisk - ArchWiki

On with Triple-Booting:

I've nearly always used dual-booting OS's on computers, starting with Win95 and WinNT. But never triple booted.

This reference is meant to keep in mind that you're using Windows with two different versions of Linux, but the reference is regarding dual-booting with 2 Linuxes; so keep in mind you got Windows too.

Dual booting two Linux distros (2019)

As mentioned in the above link; between two Linuxes, you can share a /home partition between the two -- but not the root partition.

From personal experience, I would discourage you from using extended and logical partitions; if you're using a MS-DOS partition table. I've had problems with data loss when using logical partitions.

IMO: If you really enjoy testing out Garuda, you might want to replace Ubuntu with Garuda; at least it'd save you the headache of trying to triple-boot -- not to mention the excessive amount of partitions you'd have to use with 3 operating systems on one physical HDD.

Dead-set on triple-booting? Worst case: you could always install Garuda to a large USB drive or external HDD; with leaving room for making backups on a separate partition, if using an external HDD.

INFORMATION I NEED FROM YOU:

(1) The exact make and model # of your laptop (eg: Dell Inspiron 5735).

(2) BIOS version (you can get this from your BIOS screen (eg: F2); you're looking for the version #.

(3) Helpful to also have your hard drive model # if possible.

(4) the results from the fdisk list from above.

Thanks. @johngilbert2000

4 Likes

Is your boot order's first entry Garuda or Ubuntu? Can you select Garuda in BIOS/UEFI's boot order?

Ubuntu's GRUB entry is different than Garuda's, unless you create a common boot partition for all the Linux installs. Usually, unless you create a seperate boot partition, Ubuntu's /boot is stored in Ubuntu's partition and 'Garuda's /boot is in Garuda's partition, both are different. Why you don't see Garuda could be that you booted into Ubuntu's GRUB instead of Garuda's GRUB and Ubuntu doesn't know you've installed Garuda unless you let it know by update-grub after installing Garuda.

AFAIK, updating GRUB (update-grub) does not touch a single thing in the EFI partition, It only updates the /boot, not /boot/efi.

1 Like

What if my computer crashes? Aside from just leaving it on until the battery dies, the only way to turn it off in the event of a crash is a hard reboot, as far as I know.

Not sure if my computer came with a User manual that discussed BIOS stuff. If it did, it was all in Chinese, and I didn't bother reading it, because Chinese isn't my native language.

And yet it happens. For instance, before installing any Linux partitions, I switched my SATA mode from "Optane without RAID" to "AHCI" in the BIOS menu, but whenever I do a hard reboot, it switches it back to "Optane without RAID."

Only when I hard reboot.

Correct.

Typing fdisk -l in Ubuntu yields the following:

Disk /dev/loop0: 207.2 MiB, 217079808 bytes, 423984 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

...

Disk /dev/loop7: 51.4 MiB, 53522432 bytes, 104536 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


Disk /dev/nvme0n1: 476.96 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: KINGSTON RBUSNS8154P3512GJ1             
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: gpt
Disk identifier: 84DFC3C9-B29C-49B5-8813-8FB55E5B966D

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048     206847    204800   100M EFI System
/dev/nvme0n1p2    206848     239615     32768    16M Microsoft reserve
/dev/nvme0n1p3    239616  335335423 335095808 159.8G Microsoft basic d
/dev/nvme0n1p4 499175424  501272575   2097152     1G Windows recovery 
/dev/nvme0n1p5 501272576  507666431   6393856   3.1G Microsoft basic d
/dev/nvme0n1p6 507666432 1000214527 492548096 234.9G Linux filesystem
/dev/nvme0n1p7 335335424  499175423 163840000  78.1G Linux filesystem

Partition table entries are not in disk order.


Disk /dev/loop7: 51.4 MiB, 53522432 bytes, 104536 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

...

Disk /dev/loop17: 65.1 MiB, 68259840 bytes, 133320 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

So... GPT.

I originally wanted to try Garuda out in virtualbox to see if it would be a good replacement for Ubuntu, but Garuda doesn't work as well in virtualbox, so I put it on a smaller partition to play around with it (78.1 GB). These issues I encountered though didn't really inspire confidence.

If you're sure that this is a triple boot issue, I may consider replacing Ubuntu with Garuda.

Acer Swift 3 SF314-57G-55UK

v1.21

Some other info

Model Number:                       KINGSTON RBUSNS8154P3512GJ1
Serial Number:                      50026B7684422DA8
Firmware Version:                   E8FK12.3
PCI Vendor/Subsystem ID:            0x2646
IEEE OUI Identifier:                0x0026b7
Total NVM Capacity:                 512,110,190,592 [512 GB]
Unallocated NVM Capacity:           0
Controller ID:                      0
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            0026b7 684422da85

The boot order's first entry was Garuda, until it disappeared from the BIOS/UEFI's boot order menu from a hard reboot. Now it's just Ubuntu, followed by Windows. I will post a picture momentarily.

Not anymore.

Correct.

Didn't know I could update-grub like that. I'll try it out. Is there anything I should be aware of before running update-grub?

But yeah, it's booting into Ubuntu's grub now, because Garuda doesn't even show up in the BIOS boot order menu. The only way to access Garuda's grub is through a USB.

I'll post pictures momentarily.

Since you don't have a BIOS or EFI entry of Garuda, it's waste of trying this :confused:

Unfortunately the problem is with the BIOS itself. I don't know if it can be fixed. This kind of issue is out of the scope of Linux, as this is being done before Linux even starts.

Edit: Can you still boot into Garuda by booting it with the help of live USB?
Edit2: Hasn't this ever happened with Ubuntu (you forced power-off and Ubuntu vanished)? :thinking:

Yes, using "Detect EFI Bootloaders" with a Garuda installation USB

No, Ubuntu hasn't given me issues