Garuda renamed my hard drive in UEFI after install and now can't boot it

Hi, kinda lot to explain here

Basically I naively attempted to install Garuda Linux on my HDD, replacing an old Ubuntu partition at the start of the disk. There is another partition on the disk as well, a Windows 7 one.

Anyway it all failed as the installer was running in UEFI mode whereas the disk is MBR formatted and there is no EFI partition there or anything like that. I think the installer created a boot/efi folder on my other Windows 7 install on another disk (an SSD) or something, but of course it does nothing.

So anyway fast-forward a whole bunch of research about MBR, GPT, UEFI, bootloaders, and all the rest of this stuff - I have since deleted the failed Garuda install. And in fact moved via Gparted my Windows 7 partition which I had on my SSD, to the HDD in place of the non-booting Garuda partition. So now I have two Windows 7 partitions on the HDD.

You see my SSD was MBR formated too, so my plan now is just to format it as GPT and install Garuda on it, with hopefully no more issues.

However there’s a problem, as the HDD which now hosts the 2 Windows partitions, is still named as ‘Garuda’ in the UEFI, and moreover - doesn’t boot. If I attempt to boot from the disk it just blinks and throws me back to the boot menu in less than a second. I tried reinstalling the MBR on it (via sudo dd if=mbr.bin of=/dev/sdb), I tried EasyBCD in an attempt to restore the MBR and bootloader on my HDD, I tried using boot-repair-disk to restore the MBR and bootloader, I tried to reinstall Windows 7 in the hope that it would do some magic. Nothing seems to work.

I don’t know what else to try. Perhaps installing Grub Legacy from the boot-repair-disk on my HDD, dunno if that’s even a possibility without a Linux install on the HDD to host supporting files on, but maybe. If that doesn’t work though then I’m out of ideas.

What could be the problem here?
Did the Garuda installer write to the NVRAM of the UEFI? If so then what can I do to revert it? Resetting the UEFI to defaults I’ve already tried too.
The problem doesn’t seem to be with the MBR, nor the lack of a Windows bootloader; both Windows partitions on the HDD have BCD folders.
The first Windows 7 partition on the HDD starts at sector 2048, there is 1 Megabyte free in front of it. Which I know is used to host a Grub image or something when you have a Grub install, but when you just have the MBR/Windows bootloader, could that space before the partition interfere with something?

First Happy holidays, Hope they are great.

Now please launch your Terminal, enter garuda-inxi, copy that text, then paste it here with 3 ~~~ above and below the text so it looks like the below. I’m assuming your motherboard is UEFI / MBR since you have both partition table types on your drives. Please correct me if I’m wrong. Since you attempted to reinstall Windows Can I safely assume you don’t care about the two copies you have installed? If that is the case I would just wipe all copies of your OS’s and start over using only UEFI and making sure the drive or drives you want your OS’s on have a GPT partition table. I would boot into your Garuda live key and delete the partitions using the partitioner in it and then once deleted go to Devices at the top of your partitioner and select create new partition table and then select GPT. If the fact that you have erroneous entries in your boot list in your BIOS you can now simply go to tools and select load optimal defaults, press F10, save and reboot.

Now as for reinstalling the OS or OS’s. If you want both Windows and Garuda then install Windows first it will now detect you have a GPT partition table and install appropriately for that partition Table. Then once you have installed Windows I’d go in Windows once do it’s updates, reboot into it to verify that the updates don’t have issues, if not reboot and boot into your live Garuda and when you get to the partitioning either select a separate drive from the Windows drive to install to or select install alongside and the partitioner will shrink the Windows partition and allow you to install Garuda right behind it. Now once Garuda is installed reboot and you should see the Garuda Grub menu with both Garuda and listed on it.

If you don’t care about Windows then just boot into your live Garuda and install.

System:
  Host: Unimatrix-Zero Kernel: 6.6.7-arch1-1 arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.27.10 Distro: XeroLinux
Machine:
  Type: Desktop System: ASUS product: N/A v: N/A serial: <superuser required>
  Mobo: ASUSTeK model: TUF GAMING B550-PLUS WIFI II v: Rev X.0x
    serial: <superuser required> UEFI: American Megatrends v: 3404
    date: 10/07/2023
CPU:
  Info: 8-core model: AMD Ryzen 7 5700X bits: 64 type: MT MCP cache: L2: 4 MiB
  Speed (MHz): avg: 2614 min/max: 2200/4662 cores: 1: 2200 2: 2200 3: 2869
    4: 2200 5: 2200 6: 2200 7: 2874 8: 2923 9: 2200 10: 3400 11: 2200 12: 2872
    13: 2874 14: 2874 15: 2874 16: 2873
Graphics:
  Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] driver: nvidia
    v: 545.29.06
  Display: x11 server: X.Org v: 21.1.10 with: Xwayland v: 23.2.3 driver: X:
    loaded: modesetting,nvidia unloaded: fbdev,vesa gpu: nvidia resolution:
    1: 2560x1080~60Hz 2: N/A
  API: EGL v: 1.5 drivers: kms_swrast,nvidia,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 545.29.06
    renderer: NVIDIA GeForce RTX 3060/PCIe/SSE2
  API: Vulkan v: 1.3.274 drivers: nvidia surfaces: xcb,xlib
Audio:
  Device-1: NVIDIA GA106 High Definition Audio driver: snd_hda_intel
  Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel
  API: ALSA v: k6.6.7-arch1-1 status: kernel-api
  Server-1: PipeWire v: 1.0.0 status: active
Network:
  Device-1: Realtek RTL8125 2.5GbE driver: r8169
  IF: enp6s0 state: up speed: 1000 Mbps duplex: full mac: c8:7f:54:71:15:6e
Drives:
  Local Storage: total: 26.89 TiB used: 15.92 TiB (59.2%)
  ID-1: /dev/nvme0n1 vendor: Crucial model: CT1000T500SSD8 size: 931.51 GiB
  ID-2: /dev/nvme1n1 vendor: Crucial model: CT500P3SSD8 size: 465.76 GiB
  ID-3: /dev/sda vendor: Seagate model: Expansion HDD size: 10.91 TiB
    type: USB
  ID-4: /dev/sdb vendor: Seagate model: Expansion HDD size: 7.28 TiB
    type: USB
  ID-5: /dev/sdc vendor: Seagate model: ST8000AS0002-1NA17Z size: 7.28 TiB
    type: USB
  ID-6: /dev/sdd vendor: SanDisk model: USB 3.2Gen1 size: 57.3 GiB type: USB
Partition:
  ID-1: / size: 232.8 GiB used: 23 GiB (9.9%) fs: btrfs dev: /dev/nvme0n1p3
  ID-2: /boot/efi size: 299.4 MiB used: 1.4 MiB (0.5%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-3: /home size: 232.8 GiB used: 23 GiB (9.9%) fs: btrfs
    dev: /dev/nvme0n1p3
  ID-4: /var/log size: 232.8 GiB used: 23 GiB (9.9%) fs: btrfs
    dev: /dev/nvme0n1p3
  ID-5: /var/tmp size: 232.8 GiB used: 23 GiB (9.9%) fs: btrfs
    dev: /dev/nvme0n1p3
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 36.0 C mobo: N/A gpu: nvidia temp: 30 C
  Fan Speeds (rpm): N/A gpu: nvidia fan: 0%
Info:
  Processes: 461 Uptime: 20h 34m Memory: total: 48 GiB available: 46.96 GiB
  used: 7.9 GiB (16.8%) Shell: Zsh inxi: 3.3.31
1 Like

About 2 weeks now of toothache and trying to install Garuda :expressionless:
I’ll get my tooth fixed, hopefully for the final time, on Wednesday, and it would sure be great if I could get on top of this Garuda thing by then too :slightly_smiling_face:

Well if you mean that my (laptop) motherboard supports both GPT and MBR partition types then that’s quite correct. It’s definitely an old motherboard though, the first generation to support the UEFI standard I think (running Phoenix SecureCore Tiano). It doesn’t support Secure Boot or any of that newer stuff. I do have the capability to boot into the EFI shell as well if there’s anything I can do to help things from there.

As I mentioned, I copied one of my Windows 7 partitions from my HDD to my SDD (after the attempt to install Garuda on the HDD failed), and I haven’t deleted the same partition from the SDD yet, so I have 2 copies of it and on the HDD copy is where I attempted to reinstall Windows, as an experiment. I’ll wipe that Windows reinstall and recopy from my SSD shortly.
I do care about both of the Windows partitions I have and would like to preserve them as is, if possible.

Here’s the garuda-inxi output when booting from my Live USB:

System:
Kernel: 6.5.9-zen2-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc available: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytable=us tz=UTC
misobasedir=garuda root=miso:LABEL=GARUDA_DR460NIZED_RAPTOR quiet
systemd.show_status=1 ibt=off driver=nonfree nouveau.modeset=0
i915.modeset=1 radeon.modeset=1
Desktop: KDE Plasma v: 5.27.9 tk: Qt v: 5.15.11 wm: kwin_x11 dm: SDDM
Distro: Garuda Linux base: Arch Linux
Machine:
Type: Laptop System: Intel product: HuronRiver Platform v: 0.1 serial: N/A
Chassis: type: 9 v: 0.1 serial: <filter>
Mobo: Intel model: Emerald Lake v: FAB1 serial: <filter> UEFI: Phoenix
v: 1.08_ date: 07/04/2011
Battery:
ID-1: BAT0 charge: 0% condition: N/A/47.5 Wh volts: 4.9 min: 10.8
model: TPS S10 type: Li-ion serial: N/A status: charging
CPU:
Info: model: Intel Core i5-2410M bits: 64 type: MT MCP arch: Sandy Bridge
gen: core 2 level: v2 built: 2010-12 process: Intel 32nm family: 6
model-id: 0x2A (42) stepping: 7 microcode: 0x2F
Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache:
L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB
L3: 3 MiB desc: 1x3 MiB
Speed (MHz): avg: 1161 high: 1866 min/max: 800/2900 base/boost: 2300/2300
scaling: driver: intel_cpufreq governor: schedutil volts: 1.2 V
ext-clock: 100 MHz cores: 1: 798 2: 1866 3: 1185 4: 798 bogomips: 18356
Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Vulnerabilities: <filter>
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel arch: Gen-6 code: Sandybridge process: Intel 32nm
built: 2011 ports: active: LVDS-1 empty: DP-1,HDMI-A-1,VGA-1
bus-ID: 00:02.0 chip-ID: 8086:0116 class-ID: 0300
Device-2: NVIDIA GF108M [GeForce GT 525M] driver: N/A alternate: nouveau
non-free: series: 390.xx+ status: legacy-active (EOL~late 2022) arch: Fermi
code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 2 speed: 5 GT/s
lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:0df5 class-ID: 0300
Device-3: Microdia Sonix USB 2.0 Camera driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-1.4:3
chip-ID: 0c45:62c0 class-ID: 0e02
Display: server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2
compositor: kwin_x11 driver: X: loaded: modesetting
alternate: fbdev,intel,vesa dri: crocus gpu: i915 display-ID: :0
screens: 1
Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.21x7.99")
s-diag: 414mm (16.31")
Monitor-1: LVDS-1 model: Lenovo 0x40b0 built: 2009 res: 1366x768 hz: 60
dpi: 101 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5")
ratio: 16:9 modes: 1366x768
API: EGL v: 1.5 hw: drv: intel crocus platforms: device: 0 drv: crocus
device: 1 drv: swrast surfaceless: drv: crocus x11: drv: crocus
inactive: gbm,wayland
API: OpenGL v: 4.5 compat-v: 3.3 vendor: intel mesa v: 23.2.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: Mesa Intel HD Graphics 3000 (SNB
GT2) device-ID: 8086:0116 memory: 1.46 GiB unified: yes
API: Vulkan Message: No Vulkan data available.
Audio:
Device-1: Intel 6 Series/C200 Series Family High Definition Audio
driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:1c20
class-ID: 0403
Device-2: NVIDIA GF108 High Definition Audio driver: snd_hda_intel
v: kernel pcie: gen: 2 speed: 5 GT/s lanes: 16 bus-ID: 01:00.1
chip-ID: 10de:0bea class-ID: 0403
API: ALSA v: k6.5.9-zen2-1-zen status: kernel-api tools: N/A
Server-1: PipeWire v: 0.3.83 status: n/a (root, process) with:
1: pipewire-pulse status: active 2: wireplumber status: active
3: pipewire-alsa type: plugin 4: pw-jack type: plugin
tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169 v: kernel
pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 3000 bus-ID: 02:00.0
chip-ID: 10ec:8136 class-ID: 0200
IF: enp2s0 state: down mac: <filter>
Device-2: Qualcomm Atheros AR9285 Wireless Network Adapter
vendor: AzureWave AW-NB037H 802.11bgn driver: ath9k v: kernel pcie: gen: 1
speed: 2.5 GT/s lanes: 1 bus-ID: 08:00.0 chip-ID: 168c:002b class-ID: 0280
IF: wlp8s0 state: down mac: <filter>
Bluetooth:
Device-1: IMC Networks Asus Integrated Bluetooth module [AR3011] driver: N/A
type: USB rev: 1.1 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-1.5:4
chip-ID: 13d3:3304 class-ID: e001
Drives:
Local Storage: total: 448.58 GiB used: 0 KiB (0.0%)
ID-1: /dev/sda maj-min: 8:0 vendor: Crucial model: M4-CT128M4SSD2
family: Micron RealSSD m4/C400/P400 size: 119.24 GiB block-size:
physical: 512 B logical: 512 B sata: 3.0 speed: 6.0 Gb/s tech: SSD
serial: <filter> fw-rev: 070H scheme: MBR
SMART: yes state: enabled health: PASSED on: 1y 222d 0h cycles: 3150
ID-2: /dev/sdb maj-min: 8:16 vendor: Samsung model: HN-M320MBB
family: SpinPoint M8 (AF) size: 298.09 GiB block-size: physical: 512 B
logical: 512 B sata: 3.0 speed: 3.0 Gb/s tech: HDD rpm: 5400
serial: <filter> fw-rev: 0001 temp: 29 C scheme: MBR
SMART: yes state: enabled health: PASSED on: 2y 43d 9h cycles: 4029
Old-Age: g-sense error rate: 9414 write error rate: 1 threshold: 1
ID-3: /dev/sdc maj-min: 8:32 vendor: Generic model: STORAGE DEVICE
size: 31.25 GiB block-size: physical: 512 B logical: 512 B type: USB
rev: 2.0 spd: 480 Mb/s lanes: 1 mode: 2.0 tech: N/A serial: <filter>
fw-rev: 0903 scheme: MBR
SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Partition:
Message: No partition data found.
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 7.67 GiB used: 0 KiB (0.0%) priority: 100
comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 4 dev: /dev/zram0
Sensors:
System Temperatures: cpu: 58.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Processes: 175 Uptime: 3m wakeups: 3 Memory: total: 8 GiB
available: 7.67 GiB used: 1.25 GiB (16.3%) igpu: 64 MiB Init: systemd v: 254
default: graphical tool: systemctl Compilers: gcc: 13.2.1 Packages:
pm: pacman pkgs: 1206 libs: 342 tools: octopi,paru Shell: garuda-inxi (sudo)
default: Bash v: 5.1.16 running-in: konsole inxi: 3.3.30
warning: database file for 'garuda' does not exist (use '-Sy' to download)
warning: database file for 'core' does not exist (use '-Sy' to download)
warning: database file for 'extra' does not exist (use '-Sy' to download)
warning: database file for 'community' does not exist (use '-Sy' to download)
warning: database file for 'multilib' does not exist (use '-Sy' to download)
warning: database file for 'chaotic-aur' does not exist (use '-Sy' to download)
Garuda (2.6.17-1):
System install date:     2023-12-25
Last full system update: 2023-10-29
Is partially upgraded:   No
Relevant software:       snapper NetworkManager dracut
Windows dual boot:       No/Undetected
Failed units:

Two questions to start with come to mind. First how big is the SSD? Second if it’s 256 gigs or more why not install your OS’s to it and use the HDD for something else?

My SSD is 128 Gb, so it would be great for a Garuda install while the HDD is 320 Gb and split between two partitions of Windows 7. I plan to use Garuda as my main OS from now on, so the extra speed of the SSD will come in handy.

1 Like

I ran boot-repair-disk and it also generates a report.
/dev/sda is my SSD, and /dev/sdb is my HDD (/dev/sdc is just my USB live disk)

Of interest is what I highlighted in bold, the section where the UEFI generates a report
Boot0005 appears to be my SDD
Boot000E is my HDD, and as we can see it’s called ‘Garuda’ in the UEFI (it lost its previous hardware name when I first attempted to install Garuda), and moreover it appears to look either for an EFI partition or a file EFI/Garuda/grubx64.efi, which of course does not exist. The disk is MBR formatted and I deleted my Garuda partition from the disk anyway.
Anyway this information appears to be saved in the NVRAM of the UEFI, rather than in the MBR or anywhere on disk (tell me if I’m wrong). Question is, how do I change it back to what it was? Or at least to something sensible that will allow the MBR and then Windows bootloader to be loaded?

boot-repair-4ppa2074                                              [20231225_2251]

============================= Boot Repair Summary ==============================




Default settings: ______________________________________________________________

The default repair of the Boot-Repair utility would not act on the MBR.
Additional repair would be performed: unhide-bootmenu-10s

User settings: _________________________________________________________________

grub-probe: error: cannot find a GRUB drive for /dev/sdc2.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdc2.  Check your device.map.
This will install an obsolete bootloader (GRUB Legacy). Please backup your data before this operation.
The settings chosen by the user will not act on the MBR.
Additional repair will be performed: unhide-bootmenu-10s



Boot successfully repaired.

You can now reboot your computer.


============================ Boot Info After Repair ============================

 => Windows is installed in the MBR of /dev/sda.
 => Windows is installed in the MBR of /dev/sdb.
 => Grub2 (v2.00) is installed in the MBR of /dev/sdc and looks at sector 34 
    of the same hard drive for core.img. core.img is at this location and 
    looks for (,2)/grub. It also embeds following components:
    
    modules
    ---------------------------------------------------------------------------
    offsetio extcmd macho elf file gettext boot bufio verifiers crypto 
    terminal normal datetime date mmap drivemap blocklist archelp newc 
    vga_text relocator video chain ntldr search_label search_fs_file 
    search_fs_uuid search keylayouts at_keyboard pci usb usb_keyboard gcry_md5 
    hashsum gcry_crc gzio xzio lzopio lspci fshelp ext2 xfs acpi reboot 
    iso9660 gcry_sha1 div udf exfat font diskfilter raid6rec zstd btrfs ventoy 
    read halt video_fb vbe linux linux16 test true sleep echo bitmap gfxterm 
    bitmap_scale trig video_colors gfxmenu videotest videoinfo functional_test 
    videotest_checksum video_cirrus video_bochs vga minicmd help configfile tr 
    biosdisk disk ls tar zfs squash4 pbkdf2 gcry_sha512 password_pbkdf2 
    all_video png jpeg part_gpt part_msdos fat ntfs loopback 
    gfxterm_background procfs gfxterm_menu smbios
    ---------------------------------------------------------------------------

sda1: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  Windows 7
    Boot files:        /bootmgr /Boot/BCD /Windows/System32/winload.exe

sdb1: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  Windows 7
    Boot files:        /bootmgr /Boot/BCD /Windows/System32/winload.exe

sdb2: __________________________________________________________________________

    File system:       ntfs
    Boot sector type:  NTFS
    Boot sector info:  No errors found in the Boot Parameter Block.
    Operating System:  Windows 7
    Boot files:        /bootmgr /Boot/BCD /Windows/System32/winload.exe

sdc1: __________________________________________________________________________

    File system:       exfat
    Boot sector type:  -
    Boot sector info: 
    Mounting failed:   mount: /mnt/BootInfo/sdc1: /dev/sdc1 already mounted or mount point busy.

sdc2: __________________________________________________________________________

    File system:       iso9660
    Boot sector type:  Unknown
    Boot sector info: 
    Operating System:  
    Boot files:        /boot/grub/grub.cfg


================================ 3 OS detected =================================

OS#1:   Windows 7 on sdb2
OS#2:   Windows 7 on sdb1
OS#3:   Windows 7 on sda1

**================================ Host/Hardware =================================**

**CPU architecture: 64-bit**
**Video: GF108M [GeForce GT 525M] 2nd Generation Core Processor Family Integrated Graphics Controller from NVIDIA Corporation Intel Corporation**
**Live-session OS is Linuxmint 64-bit (Linux Mint 21.2, victoria, x86_64)**

**===================================== UEFI =====================================**

**BIOS/UEFI firmware: 1.08_(0.1) from Phoenix Technologies Ltd.**
**The firmware is EFI-compatible, and is set in EFI-mode for this live-session.**
**SecureBoot disabled - This system doesn't support Secure Boot.**
**BootCurrent: 0006**
**Timeout: 0 seconds**
**BootOrder: 0006,0007,0003,0008,0005,000E,0009,000A**
**Boot0000  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)**
**Boot0001  Boot Menu	FvFile(86488440-41bb-42c7-93ac-450fbf7766bf)**
**Boot0002  Diagnostic Splash	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)**
**Boot0003* ATAPI CD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)**
**Boot0004* CD-ROM:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,be9d0102e211f3489efa0b983c96839b)**
**Boot0005* ATA HDD0:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)**
**Boot0006* USB HDD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)**
**Boot0007* USB CD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)**
**Boot0008* USB FDD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)**
**Boot0009* Internal Shell	FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)**
**Boot000A* PCI LAN:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)**
**Boot000B* IDER BOOT CDROM	PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)**
**Boot000C* IDER BOOT Floppy	PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)**
**Boot000D* ATA HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)**
**Boot000E* Garuda	HD(1,MBR,0xc10bb,0x800,0xee7b800)/File(\EFI\Garuda\grubx64.efi)**

**56da8d8bfe5726693f1e90df9a4cb54c   sdb2/Boot/bootx64.efi**
**56da8d8bfe5726693f1e90df9a4cb54c   sdb2/Microsoft/Boot/bootmgfw.efi**
**c9c88324a1e780dc9f3639b13c4fe3c8   sdb2/Microsoft/Boot/bootmgr.efi**

============================= Drive/Partition Info =============================

Disks info: ____________________________________________________________________

sdb	: notGPT,	no-BIOSboot,	has-noESP, 	not-usb,	not-mmc, has-os,	has-win,	2048 sectors * 512 bytes
sda	: notGPT,	no-BIOSboot,	has-noESP, 	not-usb,	not-mmc, has-os,	has-win,	2048 sectors * 512 bytes

Partitions info (1/3): _________________________________________________________

sdb2	: is-os,	64, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	no-grubenv,	noupdategrub,	end-after-100GB
sdb1	: is-os,	64, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	no-grubenv,	noupdategrub,	end-after-100GB
sda1	: is-os,	64, nopakmgr,	no-docgrub,	nogrub,	nogrubinstall,	no-grubenv,	noupdategrub,	end-after-100GB

Partitions info (2/3): _________________________________________________________

sdb2	: isnotESP,	part-has-no-fstab,	no-nt,	haswinload,	no-recov-nor-hid,	bootmgr,	is-winboot
sdb1	: isnotESP,	part-has-no-fstab,	no-nt,	haswinload,	no-recov-nor-hid,	bootmgr,	is-winboot
sda1	: isnotESP,	part-has-no-fstab,	no-nt,	haswinload,	no-recov-nor-hid,	bootmgr,	is-winboot

Partitions info (3/3): _________________________________________________________

sdb2	: not--sepboot,	no---boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	no--grub.d,	sdb
sdb1	: not--sepboot,	no---boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	no--grub.d,	sdb
sda1	: not--sepboot,	no---boot,	part-has-no-fstab,	not-sep-usr,	no---usr,	part-has-no-fstab,	no--grub.d,	sda

fdisk -l (filtered): ___________________________________________________________

Disk sda: 119.24 GiB, 128035676160 bytes, 250069680 sectors
Disk identifier: 0x000c10bb
     Boot Start       End   Sectors   Size Id Type
sda1  *     2048 250068991 250066944 119.2G  7 HPFS/NTFS/exFAT
Disk sdb: 298.09 GiB, 320072933376 bytes, 625142448 sectors
Disk identifier: 0x0000263a
     Boot     Start       End   Sectors   Size Id Type
sdb1  *         2048 317925375 317923328 151.6G  7 HPFS/NTFS/exFAT
sdb2       317925376 625137663 307212288 146.5G  7 HPFS/NTFS/exFAT
Disk sdc: 14.91 GiB, 16005464064 bytes, 31260672 sectors
Disk identifier: C716968A-3BC2-4A0A-A01E-33EB7176B4EA
        Start      End  Sectors  Size Type
sdc1      2048 31195095 31193048 14.9G Microsoft basic data
sdc2  31195096 31260631    65536   32M Microsoft basic data
Disk dm-0: 2.45 GiB, 2630877184 bytes, 5138432 sectors
Disk identifier: 0x14eb2669
      Boot Start     End Sectors  Size Id Type
dm-0p1 *        0 5138431 5138432  2.5G  0 Empty
dm-0p2        572    9067    8496  4.1M ef EFI (FAT-12/16/32)

parted -lm (filtered): _________________________________________________________

sda:128GB:scsi:512:512:msdos:ATA M4-CT128M4SSD2:;
1:1049kB:128GB:128GB:ntfs::boot;
sdb:320GB:scsi:512:512:msdos:ATA SAMSUNG HN-M320M:;
1:1049kB:163GB:163GB:ntfs::boot;
2:163GB:320GB:157GB:ntfs::;
sdc:16.0GB:scsi:512:512:gpt:SanDisk Cruzer Fit:;
1:1049kB:16.0GB:16.0GB::Ventoy:msftdata;
2:16.0GB:16.0GB:33.6MB:fat16:VTOYEFI:hidden, msftdata;

blkid (filtered): ______________________________________________________________

NAME   FSTYPE   UUID                                 PARTUUID                             LABEL                  PARTLABEL
sda                                                                                                              
└─sda1 ntfs     C68A6A958A6A8233                     000c10bb-01                                                 
sdb                                                                                                              
├─sdb1 ntfs     C68A6A958A6A8233                     0000263a-01                                                 
└─sdb2 ntfs     01CEB8305D78C560                     0000263a-02                                                 
sdc                                                                                                              
├─sdc1 exfat    4E21-0000                            35dca89d-65a4-4a0f-b5f6-ab3b4affd9dd Ventoy                 Ventoy
└─sdc2 iso9660  2023-12-23-05-05-55-00                                                    Boot-Repair-Disk 64bit 

Mount points (filtered): _______________________________________________________

                    Avail Use% Mounted on
/dev/mapper/ventoy      0 100% /cdrom
/dev/sda1           27.2G  77% /mnt/boot-sav/sda1
/dev/sdb1           59.5G  61% /mnt/boot-sav/sdb1
/dev/sdb2            6.5G  96% /mnt/boot-sav/sdb2

Mount options (filtered): ______________________________________________________

/dev/mapper/ventoy iso9660         ro,noatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8
/dev/sda1          fuseblk         rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
/dev/sdb1          fuseblk         rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096
/dev/sdb2          fuseblk         rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096

====================== sdc2/boot/grub/grub.cfg (filtered) ======================

Start Boot-Repair-Disk 64-bit
Start Boot-Repair-Disk 64-bit (compatibility mode)
UEFI Firmware Settings
Test memory

==================== sdc2: Location of files loaded by Grub ====================

           GiB - GB             File                                 Fragment(s)
            ?? = ??             boot/grub/grub.cfg                             1

======================== Unknown MBRs/Boot Sectors/etc =========================


/dev/sdc2: unknown GPT attributes
c000000000000001
Unknown BootLoader on sdc2

Yes, the Grub installation will add an NVRAM entry unless you run it with the --no-nvram flag.

You can delete it from the live environment with efibootmgr. With no arguments it will list all boot variables:

efibootmgr

To delete a boot variable, identify the entry you wish to modify with the -b flag and pass the -B flag to delete it.

sudo efibootmgr -b 0000 -B

You should be fine to go ahead with the installation with or without removing the old boot variable first.

Note: you will not be able to get Windows and Garuda on the same bootloader if one is installed in UEFI mode and the other is installed in legacy/BIOS mode. You will have to switch from one to the other in the BIOS every time. Additionally, you may need to disable CSM for one and re-enable for the other each time as well, depending on how your mobo is configured.

5 Likes

So I enter the command sudo efibootmgr -b 000E -B then in my case, and it will remove the Garuda entry from the UEFI NVRAM?

OK good, that’s what I’m looking for, but in that case how will the UEFI identify that HDD? Will the HDD revert to its default hardware name and boot procedure, or will it disappear from the boot menu altogether? If it disappears altogether, then how do I add it back to the boot menu?

Of course, I realize that, and that’s absolutely fine. Main thing is that both drives are bootable and can be switched between in the UEFI.

Nothing was renamed like you are thinking, just a boot variable was added. Usually the UEFI can hold many boot variables. It is no problem to have multiple for one device.

That said, if it is an old/defunct boot variable (i.e. doesn’t point to a valid bootloader configuration) I would just go ahead and delete it.

1 Like

Welp, I just deleted that boot variable, and now the SSD isn’t listed in the UEFI at all, I can’t even attempt to boot from it

Well actually it does show up as connected to Serial ATA Port 1 in the UEFI, it’s just not there in the boot menu

So what now, add a new variable?
How?

Run the installer. :smile:

A disk with no bootable entries should not show up in the boot menu, so you are describing the expected behavior.

1 Like

I don’t want to run the installer as I will install Garuda on my SSD, which currently has a Windows 7 partition on it (that I copied to the HDD too).

However prior to wiping that Windows 7 partition from the SSD I first want to check that I can boot it and the other one from the HDD.

And moreover how will installing Garuda on the SSD fix the HDD and its lack of an entry in the UEFI? (the HDD in the current configuration is MBR and has no Linux anything on it)

Sorry my bad, I meant HDD* here, that’s the drive which I can’t access in the boot menu. The SSD is fine.

The HDD has no UEFI-mode installations and no EFI partition so it’s a little different. If you can’t boot to it, check that CSM is turned on or that “UEFI only” mode is turned off in the BIOS settings.

2 Likes

I can’t boot to it as I just deleted its entry in the NVRAM, you said it yourself, and the previous entry it had in the NVRAM I presume was deleted or overwritten by Garuda when I first attempted to install it on the HDD 2 weeks ago (I since deleted that partition).

Going back to my post above Garuda renamed my hard drive in UEFI after install and now can't boot it - #6 by flamming_python
It looks like Boot000D could be its previous entry in the UEFI, before the Garuda installer added its own one to the NVRAM. However I don’t see that entry in the boot menu and can’t select it.

My UEFI is first-generation and doesn’t even have the option to boot as ‘UEFI only’ or ‘Legacy’, what it boots as is entirely dependent on what drive you select in the boot menu. If I boot from my Garuda Live USB it boots as UEFI/GPT, and If I boot from my Windows 7 partition on my MBR-formatted SSD then it boots in BIOS/MBR mode. If I was able to select the HDD in the boot menu, then there wouldn’t be a problem I presume.

The NVRAM entry is not the disk, nor is it representative of it. This is the NVRAM entry:

As you can see, it points to a Grub configuration file on the EFI partition.

Your idea that a boot variable was renamed is not correct.

It sounds like something that happened with this effort did not produce a bootable entry:


It looks like your USB stick is actually formatted GPT. If you need it to be in legacy/BIOS mode you could format it as MBR (Ventoy supports this).

1 Like

Yes I get it, the NVRAM is a memory chip on the motherboard, but I presume these NVRAM boot variables amount to instructions for the UEFI as to what devices are bootable and how they are booted.
Else what is the point of the same Garuda writing an entry to the NVRAM that details the EFI partition and the location of the .efi file within it?

I can access both of those Windows 7 partitions by booting in Garuda from the USB, browse their files, and chkdisk didn’t find errors in them, but point noted, it could be that when I actually get into the Windows bootloader on my HDD, it won’t be able to boot them.

However I’m puzzled as to how that can be the present issue, because the present issue is that I can’t even select the HDD from the UEFI to even attempt to boot from. So no MBR code being read, no Windows bootloader, nothing. There is no entry for the HDD in the UEFI boot menu, only for the SSD, and the USB pen drive and some other stuff such as the EFI shell and boot from network.

Even if I were to reformat my HDD, and reinstall Windows 7 on it, I still won’t be able to boot from it, because again, it doesn’t show up in the UEFI. Well unless the Windows install process adds a new boot variable to the NVRAM itself I suppose.

Indeed it is, and had I realized that the Garuda installer switches to MBR or GPT mode depending on how the Live USB is booted, and that I can switch how its booted by an option in Ventoy, then my initial attempt at installing Garuda onto my HDD might have been successful.

However now this is all a moot point, as my plan now is anyway to simply wipe the SSD, format it as GPT, and just install Garuda on it alone. Leaving the HDD to my Windows partitions. However before I do that I want to first be able to boot from my HDD and get to the Windows bootloader.

Stick in a Windows install ISO and click…oh, wait, you’re on Windows 7? Nevermind.

It would greatly benefit you to thoroughly read through several portions of the Arch Wiki regarding MBR vs GPT, EFI, Bootloaders, etc. Your presumptions are not supported. Maybe you have a clue under Windows; Linux not so much.

Secure your data. I know a Windows 10/11 installer ISO can repair Windows Boot/EFI entries. Something as ancient as Windows 7–who knows? :person_shrugging:

I don’t have a clue about anything

Everything I learned about partitions, partition-tables, BIOS, NVRAM, boot menus, boot loaders, and so on - I’ve learned in the past 2 weeks. So I’m sure that there is something I’m wrong about, but just telling me to read the Wiki doesn’t help - I’ve read about all this stuff countless times already and tried many things in an attempt to resolve my problem. Do be more specific.

To me it does stand to reason that the entries in the NVRAM act as instructions for the UEFI as to how to boot drives, else why are they there.
And that since the entry pertaining to my HDD is now missing, I’m not able to boot into it at all.

I guess this wouldn’t even be a Garuda specific problem. Were it not for the fact that before I first attempted to install Garuda, I was able to select my HDD in the UEFI menu and boot into it. And, now I’m not.
Washing your hands of the affair and saying ‘you’re on your own bro, Windows 7 is ancient’ is fine, I’m not paying anyone for technical support here, but at least in the interest of Garuda itself, which bills itself as something of an Arch for the masses - someone should probably look into this whole thing. And maybe add an option to the Boot recovery utility that’s already accessible from the Live USB, to like remove the Garuda-entered NVRAM entry and restore a default one that instructs the UEFI to just read the MBR (if it’s detected that the disk itself is formatted as MBR), or something.

I think this is how you have decided to “bill” Garuda, not how Garuda bills itself. From my perspective it is a community/hobby distro made by people who use it or contribute to it because they like it. You would probably be surprised how few active contributors there are.

As for your “someone should probably look into this whole thing” comment, you are still making it out like a bug or error happened, which I am not convinced of.

This comment makes me feel like you are still incorrectly associating the boot variables with the fact that Windows is not showing up in the BIOS boot menu. There is no use repeating myself over and over on this point, so what can I do but shrug? Let the record show that I am certain this is not the case.

By the way, efibootmgr is a utility that can be used in the live environment, as you already know.

Have you tried booting without the USB stick inserted?

2 Likes

Hey, you’re the boss. Just sharing what I thought.

So what is your proposition, as to why the HDD is no longer showing in the UEFI boot menu?

Yes and thank you for pointing me to it. I’m currently reading the documentation and browsing other forum posts about it. Unfortunately, everything I’ve seen seems to suggest that it can only write EFI/GPT boot entries, not ones for MBR/BIOS drives and partitions.

So I don’t know. I guess I’m kind of screwed. If I don’t think of a war to resolve this, I will have to convert my HDD to a GPT partition table, while somehow preserving the partitions and their data, I’ve heard that this is possible. Then I will have an EFI partition, and I can add the EFI entry to the NVRAM, and it should boot, at least as far as the bootloader. But I’m not sure if the Windows 7 installations will themselves boot in that case, as they were installed in MBR/Legacy mode.

Yes. Then I have only three options. SDD, EFI shell, and Network boot.