I am getting back into debian after a few years due to the imminent phasing out of windows10. One of the problems I recall during my first iterations of running debian & windows in a dual boot (off of the same hard drive) was constant messing up of the bootloaders after an update of some kind either on windows or debian, but mainly due to something in windows.
So on this current iteration I decided to run both on separate hard drives. I put debian 12.5 on a SSD and windows10 on a standard
mechanical hard drive. My belief was that by doing this I would get no mess up's in the bootloaders. However I was wrong and after windows10 updated
it somehow messed up the bootloader of debian on the SSD which is pretty distrurbing not to mention frustrating - is there nothing windows cant mess with, even
when separated by hardware!!!
The way I have these 2 OS's setup to boot is in the BIOS using UEFI/GPT . I had to manually set which OS to boot by configuring it in the BIOS. The original installation of debian 12.5 bootloader was in: /boot/efi/EFI/Debian and it was setup to boot shimx64.efi as opposed to grubx64.efi
What I did afterwards to remedy this was use the debian Live CD in Rescue Mode to force a re-install of the bootloader (this ended up creating a separate
/boot/efi partition and installed the bootloaders on there)
This did work in that I could get back into debian however,it installed the relevant bootloader files in a new /boot/efi/EFI/boot
without shimx64.efi in this new folder (only grubx64.efi,mmx64.efi,fbx64.efi and a bunch of other files).
So what I want to do is to get debian to boot off of shimx64.efi in the original installation folder. I can still go into the BIOS and
add a boot option to boot debian using the file shimx64.efi but when I try to OK this I am unable to set it and it comes back with the error
"Boot name not found". However the files are definitely visible in the relevant folder.
Is there a way to repair the bootloader so that I can boot off of the original shimx64.efi file so that if any disruption occurs in future(such as a windows update or unplugging the power cable - this also messes up the booloader configuration oddly) I can hopefully setup the bootloaders as per the original installation as I dont feel this Rescue method has done it in the correct way, i.e. it shouldnt be creating a new folder, instead it should be repairing the original folder. So if anyon ehas any experience and knows how to fix this manually, that would be handy. Also I cant figure out why the BIOS is not able to 'see' the files in the /boot/efi folders when this wasn't the case initially, before the windows update borked it, such that the Rescue process couldn't fix this aspect either.
Just some useful info that might give somebody an idea
result of efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0008,0004,0005
Boot0000* debian HD(3,GPT,d11b4648-3200-ef42-8c24-19ae4cd5e1c0,0x800,0x1f4000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001* Windows Boot Manager HD(1,GPT,d91494bd-418b-445d-aed6-0ac26b651b41,0x800,0x1f4000)/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.}....................
Boot0004 Onboard NIC(IPV4) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(70b5e844c1d3,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0005 Onboard NIC(IPV6) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(70b5e844c1d3,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0008 UEFI: HL-DT-ST DVD+/-RW GU90N PciRoot(0x0)/Pci(0x17,0x0)/Sata(3,65535,0)/CDROM(1,0x6d7,0x2800)..BO
blkid
/dev/sdb3: BLOCK_SIZE="512" UUID="422805C72805BAC5" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="65be15e5-2d93-411e-a9d5-550f2858cf83"
/dev/sdb1: UUID="4CCA-FD8B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d91494bd-418b-445d-aed6-0ac26b651b41"
/dev/sr0: BLOCK_SIZE="2048" UUID="2024-02-10-11-07-25-00" LABEL="d-live 12.5.0 xf amd64" TYPE="iso9660" PTUUID="c7e6ef99" PTTYPE="dos"
/dev/sda2: UUID="3c0b7b5c-eb10-48b0-abb6-b85b4194a673" TYPE="swap" PARTUUID="476e13f8-2656-bf44-ad2e-5c710553b82b"
/dev/sda3: UUID="13E7-ABE2" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d11b4648-3200-ef42-8c24-19ae4cd5e1c0"
/dev/sda1: UUID="27cdda37-c7d0-4287-9167-fb9f20ab2097" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b186874e-0d5d-c248-8087-3ace6193b1d5"
/dev/sdb2: PARTLABEL="Microsoft reserved partition" PARTUUID="dd73115d-b0a4-42dc-a3b3-02ac62ea8393"
the output of efibootmgr show that SHIMX64.EFI is being loaded from within /boot/efi/EFI/DEBIAN but I am not sure if thsi is really ocurring otherwise why would I have needed to do the Rescue process to get it to work. The Rescue process, while it worked, has installed the bootloader files into the new folder above (/boot/efi/EFI/boot) so the loader must be pulling the files from within this location, no?
So on this current iteration I decided to run both on separate hard drives. I put debian 12.5 on a SSD and windows10 on a standard
mechanical hard drive. My belief was that by doing this I would get no mess up's in the bootloaders. However I was wrong and after windows10 updated
it somehow messed up the bootloader of debian on the SSD which is pretty distrurbing not to mention frustrating - is there nothing windows cant mess with, even
when separated by hardware!!!
The way I have these 2 OS's setup to boot is in the BIOS using UEFI/GPT . I had to manually set which OS to boot by configuring it in the BIOS. The original installation of debian 12.5 bootloader was in: /boot/efi/EFI/Debian and it was setup to boot shimx64.efi as opposed to grubx64.efi
What I did afterwards to remedy this was use the debian Live CD in Rescue Mode to force a re-install of the bootloader (this ended up creating a separate
/boot/efi partition and installed the bootloaders on there)
This did work in that I could get back into debian however,it installed the relevant bootloader files in a new /boot/efi/EFI/boot
without shimx64.efi in this new folder (only grubx64.efi,mmx64.efi,fbx64.efi and a bunch of other files).
So what I want to do is to get debian to boot off of shimx64.efi in the original installation folder. I can still go into the BIOS and
add a boot option to boot debian using the file shimx64.efi but when I try to OK this I am unable to set it and it comes back with the error
"Boot name not found". However the files are definitely visible in the relevant folder.
Is there a way to repair the bootloader so that I can boot off of the original shimx64.efi file so that if any disruption occurs in future(such as a windows update or unplugging the power cable - this also messes up the booloader configuration oddly) I can hopefully setup the bootloaders as per the original installation as I dont feel this Rescue method has done it in the correct way, i.e. it shouldnt be creating a new folder, instead it should be repairing the original folder. So if anyon ehas any experience and knows how to fix this manually, that would be handy. Also I cant figure out why the BIOS is not able to 'see' the files in the /boot/efi folders when this wasn't the case initially, before the windows update borked it, such that the Rescue process couldn't fix this aspect either.
Just some useful info that might give somebody an idea
result of efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0008,0004,0005
Boot0000* debian HD(3,GPT,d11b4648-3200-ef42-8c24-19ae4cd5e1c0,0x800,0x1f4000)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001* Windows Boot Manager HD(1,GPT,d91494bd-418b-445d-aed6-0ac26b651b41,0x800,0x1f4000)/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.}....................
Boot0004 Onboard NIC(IPV4) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(70b5e844c1d3,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0005 Onboard NIC(IPV6) PciRoot(0x0)/Pci(0x1f,0x6)/MAC(70b5e844c1d3,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0008 UEFI: HL-DT-ST DVD+/-RW GU90N PciRoot(0x0)/Pci(0x17,0x0)/Sata(3,65535,0)/CDROM(1,0x6d7,0x2800)..BO
blkid
/dev/sdb3: BLOCK_SIZE="512" UUID="422805C72805BAC5" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="65be15e5-2d93-411e-a9d5-550f2858cf83"
/dev/sdb1: UUID="4CCA-FD8B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="d91494bd-418b-445d-aed6-0ac26b651b41"
/dev/sr0: BLOCK_SIZE="2048" UUID="2024-02-10-11-07-25-00" LABEL="d-live 12.5.0 xf amd64" TYPE="iso9660" PTUUID="c7e6ef99" PTTYPE="dos"
/dev/sda2: UUID="3c0b7b5c-eb10-48b0-abb6-b85b4194a673" TYPE="swap" PARTUUID="476e13f8-2656-bf44-ad2e-5c710553b82b"
/dev/sda3: UUID="13E7-ABE2" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="d11b4648-3200-ef42-8c24-19ae4cd5e1c0"
/dev/sda1: UUID="27cdda37-c7d0-4287-9167-fb9f20ab2097" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b186874e-0d5d-c248-8087-3ace6193b1d5"
/dev/sdb2: PARTLABEL="Microsoft reserved partition" PARTUUID="dd73115d-b0a4-42dc-a3b3-02ac62ea8393"
the output of efibootmgr show that SHIMX64.EFI is being loaded from within /boot/efi/EFI/DEBIAN but I am not sure if thsi is really ocurring otherwise why would I have needed to do the Rescue process to get it to work. The Rescue process, while it worked, has installed the bootloader files into the new folder above (/boot/efi/EFI/boot) so the loader must be pulling the files from within this location, no?
