Okay. BIOS sees the NVME drive, but as you said, there is no bootloader in the efi part. I was looking at the CZ image from yesterday of the ext SSD (now that I am back in my internal MX session) and here is what the EFI part clone shows:
Device size: 535.8 MB = 1046493 Blocks
Space in use: 1.1 MB = 2093 Blocks
Free Space: 534.7 MB = 1044400 Blocks
Block size: 512 Byte
Total block 1046493
Syncing... OK!
Partclone successfully cloned the device (/dev/sda2) to the image (-)
>>> Time elapsed: 7.22 secs (~ .120 mins)
*****************************************************.
Finished saving /dev/sda2 as /home/partimag/2024-11-03-11-img-SanDisk_Ext_SSD-MX-Linux/sda2.vfat-ptcl-img.zst
I did, for the first time, use that fast method, .zst. and this is what I just restored to the internal EFI partition.
1.1 MB in use. Now here’s gparted display of the internal nvme drive:
Trying to mount nvme0n1p1 (which is EFI partition on NVME) I get
special device nvme0n1p1 does not exist
What does that mean? dmesg output really long, but since it had (1) after the above message, tried to find the error, but don’t see anything other than ACPI errors.
looking at the part about nvme:
nvme nvme0: pci function 10000:e1:00.0
[ 1.190551] pcieport 10000:e0:1d.0: can't derive routing for PCI INT A
[ 1.190554] nvme 10000:e1:00.0: PCI INT A: not connected
[ 1.192212] nvme nvme0: missing or invalid SUBNQN field.
[ 1.192325] nvme nvme0: Shutdown timeout set to 8 seconds
I hope that is normal.
If I use Thunar, nothing is in MX EFI, but we know that cannot be true or why would it have 1.1 MB used? There has to be something.
I typically mount EFi and ls, but not sure why I can’t mount.
Let me boot from the ext SSD MX and see if I can do it from there.
I just thought of something. I cannot boot directly from the ext SSD either. I have to use MX live session to find its grub menu and boot into it. That means that by copying the image of that EFI, I did nothing to advance the resolution. Sheesh…long day.
Okay, going back to CZ images and find the EFI from before moving partitions around. That should work for getting that partition correct; will still have to update grub, edit fstab again, but let’s at least see if that fixes BIOS seeing the bootable drive.
I restored just the MX EFI and BIOS added an identical-named entry for the internal drive. Neither boot. But here’s why I think:
So I don’t think I can just restore the EFI partition from the image before all of this transpired, without restoring other partitions. Because, remember before I got everything done to stop using Garuda grub and added it to the MX Grub, that is the image I am wanting to go back to. But that would not help if I don’t restore the whole disk, as the drive had (at that time)
p1 MX EFI (when it was smaller 256 MB)
p2 MX
p3 Garuda EFI (1028 MB)
p4 Garuda
p5 unallocated
very different from what the other parts are right now. Would you agree I need to restore the entire disk then?
And that will mean having to move/expand partitions again as I was running out of room on the MX drive.
I dont know?
I cant see any link between the content of efi partitions and what is on the rest of the disk.?
Before you take the drastic windback restore, try copying just the file BOOTX64.EFI (from any where you can find it) into /boot/efi/BOOT/.
You need to mount it , in rw mode, to copy into it of course.
That should let it boot with the efi bootloader, I think.
I think you may be able to rebuild the efi filesystem by hand. That is the first step… lets see how that goes first.
and
in your proposed fstab in reply#87 you had
UMASK=0077
on the efi entry
I think that gives permission only to the owner of the file
also why VFAT i thought it was fat32?
I thought of another option. I looked at my Timeshift snapshots and found one from Oct 27. Upon hitting restore, I checked the Advanced section and it actually resets the part 1 EFI as well as reinstalls/rebuilds grub. So I am going to try that first as it will supposedly set everything back to that date. I already made the CZ image of the entire drive from yesterday, so worst case we are back to square one.
Okay, Timeshift worked. I still have 2 entries for the internal NVMe drive in BIOS, but I chose the first one, set the second to boot next, and my original MX grub menu appeared (the one without Garuda on it). I booted from there to MX.
So now we have that back, system booting from internal drive and BIOS shows the entry.
I will have to go back and add Garuda to the grub and will surely have to live session that OS to get everything back working there.
So we did this without me having to redo all the partitions I had moved/resized and avoided being back to running out of space on the MX partition.
Should have thought of timeshift earlier, but I was tired last night.
Once I get Garuda running again, and add it to MX grub, will post results.
So my last restore of system via TS was for Oct 27, before I made Garuda appear on MX grub menu. That worked great.
Then I searched this thread to find the date that I successfully added Garuda to MX grub. That was Oct 28th. So I went back to TS and restored that day’s backup.
It rebooted right into MX without even going to grub. So went into BIOS and there was the entry I had been missing: mx
So I booted that entry and low and behold, my grub menu with Garuda appeared and I successfully booted Garuda. I thought I would have to live session it and update fstab, etc. after all the moving around of partitions, but TS took care of that.
Whew. So glad I did not have to redo all the symlinks, etc. to get that working again.
And all of this was completed after repartitioning, making EFI larger, moving Garuda to the last partition with added space from the former unallocated partition, as well as enlarging MX partition so that I have plenty of space now.
I have kept the ext SSD with just MX and its EFI partition which has these 2 timeshift snapshots on it. That way, as TS continues to make daily/weekly new snapshots, these will remain available to me via that drive.
Thanks @nevj for all of your help. I can safely say this issue is resolved.
Hi Sheila,
Well done.
In the end , I was not much help, but I learnt some.
Maybe I should be using TS… I have been doing the equivalent by rsyncing the whole OS onto a plugin sata disk while working on restoring MX. … It only takes 1 minute to rsync the whole root filesystem.
As someone said, “…nothing “magical” about timeshift. Basically it is just an rsync backup with very cleverly pre-programmed --include and --exclude statements.”
I also learned something about TS. When I was showing the files/folders to be re-created, I saw that you can sort by “All Files” “Created Files” or “Deleted Files” and that says to me I could have deselected the “Deleted Files” (which were game files) in order not to lose those, but I did not want to mess anything up the first try. So now, after making my back up of the drive, I can go back into TS and restore just those previously deleted folders/files. It does save one from having to sort through the missing items to restore them.
And as soon as I remove the older CZ iamges from ext drive, I am making a brand new one today of the whole disk.
