Yes. Should I do it again from within the current session?
Sheila
1 Like
No, once is enough
Did os-prober find garuda?
You still have 2 EFI partitions on that nmve disk.
Is the bios maybe looking at the wrong one?
Do they both have a boot flag set in gparted?
I thought you had them merged?
Which one did you mount?
1 Like
Yes, I stated earlier that I left the Garuda EFI on the drive just in case.
Model: Samsung SSD 970 EVO Plus 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 537MB 536MB fat32 primary boot, esp
2 537MB 699GB 698GB ext4 MX LINUX
5 699GB 1000GB 301GB btrfs
3 1000GB 1000GB 537MB fat32 EFI-SYSTEM2 msftdata
And I also said I used the correct MX Grub menu to try and boot to Garuda, but it failed. I imagine I will have to boot live Garuda session and fix UUIDs as the old info was what was copied into MX EFI.
From my current MX session:
myviolinsings@mx--acer:~
$ sudo os-prober
/dev/nvme0n1p5:Garuda Linux Bird of Prey (Soaring):Garuda:linux
Sheila
1 Like
In the MX Forum link I posted above, instructions were to rebuild/redo the EFI partition. Of course, I would not need to chroot as I am in the session:
OK, based on the given informations, something to fix:
Do LiveBoot from MX Live USB/ISO and Chroot-Rescue into the installed system:
Within chroot-terminal :
* First remove signed grub and shim- stuff ( we are in chroot so no need for sudo)
Code: Select all
apt purge grub-efi-amd64-signed shim-*
* Next tidy up directories on ESP both MX23 and mx
Code: Select all
rm -r /boot/efi/EFI/MX23
rm -r /boot/efi/EFI/mx
and also clean the BOOT directory on the ESP
Code: Select all
rm /boot/efi/EFI/BOOT/*
* Now we get rid of the remainings of the Boot-Repair attempts and restore MX grub defaults:
Code: Select all
rm -r /etc/grub.d
cp -a /usr/local/share/live-files/files/etc/grub.d /etc/
* And we do re-install grub-modules, grub-loader, and UEFI-bootloader entry onto ESP and NVRAM with
Code: Select all
grub-install --bootloader-id MX23 --recheck --force-extra-removable
* Also perhaps remove superfluous "mx" efi-entry in NVRAM with
Code: Select all
efibootmgr -v -B -b F
* Finally we rebuild the grub-menu with
Code: Select all
update-grub
That's it probably. Anything else to fix
Good luck.
Top
I would then have to redo the "add Garuda partā to the new EFI and add the symlinks, but I may have to do that again anyway.
Do you think this would fix BIOS?
Thanks,
Sheila
1 Like
Sorry missed that.
I think I would move it somewhere offlineā¦ like in a flash drive.
The bios might be looking at the wrong efi partition.
I am out of ideas, sorry.
The basic thing about the bios boot menu is that it only sees disjs containing bootable filesystems. That is why i asked about boot flags.
Your bios must contain a boot table entry for the nvme disk. If you click on that entry, it boots using the copy of grub from that diskā¦ you have 2 copies of grub (2 efi files) on that disk. That may be the problem.
I have no idea which efi partition the bios will get grub from. If it got the first one, it should bootā¦ if it got the garuda oneā¦ no idea?
So hide that second efi partition and see if it helps.
1 Like
And therein lies the problem. There is nothing BIOS except the USB Flash drive and the ext SSD from when I was booting from it.
As you can see in my above post, the Garuda EFI has āmsftdataā as the flag since I removed the boot/esp flags so that BIOS would not think it was the one to use.
You can see that the efibootmanager also does not have the nvme MX Grub as a bootable device
efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 2001,0000,2002,2003
Boot0000* HDD: Samsung SSD 970 EVO Plus 1TB PciRoot(0x0)/Pci(0xe,0x0)/NVMe(0x1,00-25-38-55-31-91-CD-CB)/HD(3,GPT,7a2ef150-919b-4cd5-8928-4d9f0c7d1f00,0x74606800,0x100000)RC
Boot0001* USB HDD: USB UsbWwid(781,55a9,0,0401ff142492a5b7cec6ee2c54aad572d6674ed1578b5235a734700dbd21e7abcf10000000000000000000008a196c8cff1c0d18a9558107632ed85)/HD(2,MBR,0xfc52a621,0x1d1e0000,0x10000)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RC
I will check in BIOS settings to see if there is anything else, but I am unaware of any setting for the NVME drive or SSD drive if it is not already showing up there.
Thanks,
Sheila
1 Like
I am thinking the same thing!!! MX is Debian based, Garuda is Arch based, the two do not deal or interact with grub in the same way, in other words, MX os-prober may not find the Garuda grub entry.
In order to get this right, I believe @Sheila_Flanagan is going to have to decide which distro she wants, either MX or Garuda and save her data and delete the one that can be rebuilt.
1 Like
I now see the NVME drive in BIOS. The older ext SSD is no longer there since I have rebooted without it attached.
At least that is something. But it obviously is not bootable. I will attempt to boot after removing the Garuda EFi, but I am confident that will not fix the BIOS boot issue.
After that, I am going to redo the MX EFI as instructed in the MX Forum from a post last week.
I have 2 backup copies of the EFIs if I need to revert.
Sheila
1 Like
Your bios eoll only see the nvme drive if it contains at least one filesystem with a boot flag.
Do you have a boot flag?
Go into gparted and check.
Put a boot flag on the first efi partition.
1 Like
OK, you got that far.
1 Like
Yes and it has a bootable EFI partition with the correct boot flags:
Number Start End Size File system Name Flags
1 1049kB 537MB 536MB fat32 primary boot, esp
But it still does not boot. That is why the only option I can think of is to redo the EFI partition from within the MX Linux session and see if that changes BIOS after reboot.
Thanks,
Sheila
1 Like
Can you tell what part of the boot sequence it gets to?
Do you get a grub menu? Does it find initrd?
Yes, I think you have to study what is in that EFI partition
When you reboot, have you done a cold bootā¦ ie complete power off?
I hope your bios is capable of booting from an nvme drive? ā¦ you did hsve it working before all this didnt you?
1 Like
That is the issue, I think. Even though I copied in Gparted from one partition to another (remember, the ext SSD with only MX Linux and its EFI partition was on it) something is not right. The efi folder of my MX is empty and comparing the 2 partitions, usage of space is not identical.
I cannot get through a boot sequence directly from the internal drive. What I have to do to get into my internal install of MX is to use the live session of MX from my USB drive and go to Boot Rescue>Grub Menus then IT finds my grub menu from the internal drive and I can boot into it from there.
I am having issues since I did not put the UUIDs into the fstab for my ext HDD where all of my CZ images are. I cannot view them in Thunar. Keeps saying having trouble mounting.
So am fixing that, but I am thinking instead of using GParted to copy a partition to another disk I should use CZ parts and put the image I made from the working ext SSD MX Linux onto the internal EFI partition and see if that fixes it.
I will update after.
Sheila
1 Like
The same internal NvME drive has been booting both MX and Garuda since I bought it and installed everything over a year ago. So that is not the issue. The laptop is relatively new, think itās about 2 years old.
I have not tried a cold boot, does that really make a difference? I will test that.
Thanks,
Sheila
2 Likes
That is certainly the issue.
Something went wrong in your copying
It has to have at least BOOT/BOOTX64.EFI
plus a directory for each OS containing grubx64.efi
It might make the bios reset a few things.
but I think your problem is the efi partition is emptyā¦ as you concluded.
you need to find a good copy of the esp, mount both espās , and use cp -r
1 Like
I know. I donāt understand how Gparted said it copied from one partition and pasted to another, but I will stick with CZ from now onāat least I have never had an issue with images.
I always have CZ check that the image is restorable when I setup the copy, but before restoring just the EFI partition from ext SSD that I made Saturday, I asked it to check again. So itās taking longer than normal. That efi partition got made in CZ in appx 3 min
So as soon as it finishes checking (about 7 min left), it will restore the EFI partition and I will try booting again.
Thanks,
Sheila
1 Like
I have never used gparted to copy.
Did it perhaps copy only the filesystem, and not the content?
1 Like
Is that possible? I thought it used CLI commands like cp and that it even included permissions, etc. if those are involved. I was trying to watch as it did its thing and saw certain commands I recognized, but I could be wrong.
But just seeing that there is a difference in used space between the two says something did not copy. And then when I saw the efi folder empty, I knew it had to have messed up in the copy/paste in Gparted.
I have plenty of images so I am not worried about it, I just feel like I am so close to getting it back. And I do have to go fix those symlinks for Garuda as I saw ābroken linksā in the folder as well.
Sheila
2 Likes
Okay, well that did not work. But I am not sure about the messages I got in CZ. Something about NvME0n1 not found in image, so created /tempā¦ and then it asked to restore that temp image to part 1 and as it quickly scanned after completion, there was something about missing disk sense??
I rebooted (cold boot) and the only boot options are the USB & internal SSD . I chose that and got the same
error: no such partition
Entering rescue modeā¦
grub rescue>
Let me boot into it from live session grub menu and see whatās what.
Sheila
1 Like
So now the bios cant see the nvme drive?.. that might be because there is no bootloader in the esp partition.
So it did recheck the disks on a cold boot.
You have to get that CZ stuff back
1 Like