Deleted EFI Folder , how to recover it or make a new one?

brother this is embarrassing

[parasetu@Pasec ~]$ sudo mount /dev/sdb10 /mnt
[sudo] password for parasetu: 
[parasetu@Pasec ~]$ 

    tar xfv ~/efi.tar -C /boot/efi
tar: /home/parasetu/efi.tar: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
[parasetu@Pasec ~]$ sudo tar xfv ~/efi.tar -C /boot/efi
[sudo] password for parasetu: 
tar: /home/parasetu/efi.tar: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
[parasetu@Pasec ~]$ sudo mount /dev/sdb10 /boot/efi
[parasetu@Pasec ~]$ sudo tar xfv ~/efi.tar -C /boot/efi
tar: /home/parasetu/efi.tar: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

:face_with_peeking_eye:
idk what else to do , been troubling you all from past 2 days

this:
~/efi.tar
is where your file is (or should be)

I don’t know why it is not there - it may be in /root
I haven’t kept track closely here.

If you are working from a live system and have rebooted in the meantime - the file will be nowhere
or perhaps in oblivion :sunglasses:
… you should know where you have put it

Also:
you have mounted /dev/sdb10 to /mnt
but it should be at /boot/efi - that is where the command expects it to be

I just saw that you did that in the end

but the .tar file is not where it should be
and thus the command fails

1 Like

UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device is formatted with a FAT12, FAT16 or FAT32 file system

EFI system partition - Wikipedia

As mentioned previously, all of the Linux filesystem drivers support all of the three File Allocation Table sizes, 12-bit, 16-bit, and 32-bit.

FAT filesystem and Linux - Wikipedia

No. The partition editor will refresh the device and it will show as the new filesystem.

Only software that’s already open and hasn’t detected the change will show the old filesystem. Unless of course it was mounted at the time.

EDIT:

I know why:

oh - o.k.
That explains it. :grimacing:
@Molski said that this step was optional …

File gone, contents no longer there, no way to restore it this way.

1 Like

Indeed, and it was a shared partition…

@anukul

It’s difficult to say with so many distros and EFI partitions. We don’t know exactly how everything is configured, or the boot priority.

Don’t turn your computer off, until this is fixed. If you do you may need a live USB to fix it. Create a live USB before you do anything else, just in case.

Assuming you’re running manjaro…I’d say the best course of action is to make sure that /dev/sdb10 is mounted at /boot/efi, then run sudo install-grub, this should install grub, and detect the other distro’s.

After that you may also need to fix endeavour.

EDIT:

If anyone has a better idea then please say so.

That was a lot of effort and problems with just creating and extracting a tarball. I’m reluctant to just say some commands to bring an old snapshot to your root, if you can’t at least try to understand what each step does. (And act accordingly with things like errors.) Plus, I will make assumptions like, that you know you cannot make a new filesystem on a currently mounted one. (But I guess you don’t?)

But since were on a post about your EFI partition, why don’t we clean it it up some more. I thought others found the FAT16 partition was for another OS. But if not? I noticed the layout is different than all my Manjaro installs.

Inside that EFI paritition, you’re missing a directory/file. I have:

[dev ~]# find /boot/efi
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/Manjaro
/boot/efi/EFI/Manjaro/grubx64.efi
/boot/efi/EFI/boot
/boot/efi/EFI/boot/bootx64.efi

When you create or extract a tarball, the v option just displays the files. So it should show the exact same files as shown with my find command.

I could of sworn Manjaro/grubx64.efi was always symlink to boot/bootx64.efi, but they are just copies for me now.

sha256sum /boot/efi/EFI/Manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi
cdabef3d29ccc6bca06e123baa76d72520c2702fdbbf7639c68f25693ceebb2e  /boot/efi/EFI/Manjaro/grubx64.efi
cdabef3d29ccc6bca06e123baa76d72520c2702fdbbf7639c68f25693ceebb2e  /boot/efi/EFI/boot/bootx64.efi

Same files. We can just copy it.

sudo mkdir /boot/efi/boot
sudo cp /boot/efi/EFI/Manjaro/grubx64.efi /boot/efi/EFI/boot/bootx64.efi

It shouldn’t be hurting anything, but you have had a (older) Windows OS take a **** in it. You may as well clean it up: sudo rm -r /boot/efi/\$RECYCLE.BIN /boot/efi/System\ Volume\ Information

With find /boot/efi you should see the same as mine above.

Then you can create the tarball. (the tar cfv command.)

Oh man , we are back to stage 0 , the pc went off and now again it didn’t boot up with manjaro , and that same boring garuda bootloader came up :)) well i guess its better to give up now :smiley:

image

all i feel like is FAT16 wasn’t kicking my b##t , why did i take the challenge , it was working fine.

I think it was mentioned:
you just need one (1) efi partition for all your systems.

Perhaps one of the other systems Grub bootloader might pick up your manjaro when you tell it to scan for other systems.

I’ll be watching and perhaps learning from here on.

well no doubt , that other systems grub bootloader is picking up manjaro , but the real issue , is the UUID was changed and on trying

i get nothing after mounting and it says no such directory exist and even tho @Molski has mentioned as to copy and paste it , i’m sure , i’ll need a ton of information to execute that only , so maybe take a leave , and if someday i get to understand it , i’ll execute it further :smiley:

Why is that an issue?

You know which partition.
You know how to get the UUID
lsblk -f

therefore you know what to adapt in /etc/fstab :man_shrugging:

it is like Lego …

but as I said: I’m out

In fact, UEFI firmware supports booting from a surprising amount of filesystems, provided that a specific driver is available.

okay people , so i tried fixing it again with live usb
so my efi partition was FAT32 , and flagged with boot and esp
then the first step that i did was mounted the root partition of Manjaro
next step was editing the /etc/fstab file and putting the new UUID
saving and exiting and then un-mounting ,all this i have understood now

now it was time to restore grub bootloader
so i did root and manjaro-chroot -a
which listed all my linux os and asked me to choose the number for manjaro , which i did
so i further tried pacman -Syu grub
but this command didn’t get executed as my system hasn’t been updated from long and it resulted in error , so i closed the terminal and restarted my comp
this time i got to login and access my manjaro
there i tried to install grub using sudo update grub which installed some 0.1 mb file
and to configure it , grub-mkconfig -o /boot/grub/grub.cfg

after a few restarts the system was working , even tho the manjaro grub bootloader didn’t load up on boot , and then i turned of computer and later came back removed the live usb and tried to boot into manjaro and now i’m welcomed by another error

Failed to stat resume device '/dev/disk/by-uuid/8eb80e10-0b17-4e68-8d79-e1c69a79
2054` : No such file or directory 
_ 

again i have booted with live usb and lsblk -f and realised now it’s something with swap memory of manjaro,i.e - sdb9

 lsblk -f                                                                                       ✔ 
NAME      FSTYPE   FSVER      LABEL            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0     squashfs 4.0                                                                    0   100% /run/miso/sfs/livefs
loop1     squashfs 4.0                                                                    0   100% /run/miso/sfs/mhwdfs
loop2     squashfs 4.0                                                                    0   100% /run/miso/sfs/desktopfs
loop3     squashfs 4.0                                                                    0   100% /run/miso/sfs/rootfs
sda                                                                                                
├─sda1                                                                                             
├─sda2    ntfs                Basic Softwares  0A241F40241F2E67                                    
├─sda3    ntfs                New Volume       A47C0DD47C0DA262                                    
└─sda4    ntfs                WD Recovered     9C30E37D30E35CB0                                    
sdb                                                                                                
├─sdb1    swap     1                           4ddeeafa-1e01-40b5-9acd-1964b5d7d904                
├─sdb2    ext4     1.0                         deaf8b37-bb62-4476-b25b-01cfa045338e                
├─sdb3    vfat     FAT32                       97D4-30D3                                           
├─sdb4    ext4     1.0                         427984c1-6f4d-4c2c-84da-d8455e70fd15                
├─sdb5    ext4     1.0                         965006b0-1683-4dd3-8e93-fd482161729d                
├─sdb7    ext4     1.0                         411dc37c-e651-4220-b380-d3306c59e042                
├─sdb8    ext4     1.0                         30fde1a2-8594-4a14-86fa-6cdad59bc450                
├─sdb9    swap     1                           8eb80e10-0b17-4e68-8d79-e1c69a792054                
├─sdb10   vfat     FAT32                       6E2B-F8D9                                           
├─sdb11   swap     1                           94829c5d-b261-4d3d-87c5-0f25511c93e2                
├─sdb12   vfat     FAT32      NO_LABEL         3B51-861D                                           
└─sdb13   ext4     1.0                         c4596ece-df47-4850-b449-a3d299717e9c                
sdc                                                                                                
└─sdc1    ntfs                My Passport      8AB462C7B462B57B                                    
sdd       iso9660  Joliet Ext MANJARO_KDE_2405 2024-07-30-08-30-25-00                     0   100% /run/miso/bootmnt
├─sdd1    iso9660  Joliet Ext MANJARO_KDE_2405 2024-07-30-08-30-25-00                              
└─sdd2    vfat     FAT12      MISO_EFI         0DE6-E8D4                                           
nvme0n1                                                                                            
├─nvme0n1p1
│         vfat     FAT32      ESP              ECD2-9948                                           
├─nvme0n1p2
│                                                                                                  
├─nvme0n1p3
│         ntfs                                 7442456342452B66                                    
├─nvme0n1p4
│         swap     1                           d324bf6e-b84b-4f82-8fa4-a90b4a84dd40                
├─nvme0n1p5
│         ext4     1.0                         3c057d72-e5fa-4534-a2b4-ff716922382e                
├─nvme0n1p6
│         ext4     1.0                         6b63debb-f5de-4218-8e24-27b1f0072975                
└─nvme0n1p7
          ntfs                DELLSUPPORT      522074D82074C50F  

On checking sdb9 from gparted , there is an option to turn on swapon , do i need to turn it on?

a similar issue was reported but i don’t see any answer to it

Idk , if posting links from other forums is allowed , but found something similar to my issue
https://www.linuxquestions.org/questions/debian-26/resume-could-not-stat-the-resume-device-file-573538/

in the discussion , they point out using hibernation as a cause , which would have resulted into some dummy storage on swap and its not accessible , in my case the pc went off due to power cut , does that mean , swap got corrupted and can i format and remake it just like efi and then change the UUID in /etc/fstab?

@dmt @soundofthunder @nachlese , can i anyone suggest me something on it ?

I sure can’t.

(I fixed the linebreak in the UUID in the quote)

Your system is looking for that partition and can’t find it
even though it clearly is there:

I have no ideas.
except:
perhaps it is not in /etc/fstab

Yes , that’s the problem , since there is no data on swap , can i re-partition it? or will that be risky and i should wait until someone answers?

Did you see this? Did you check this?

yes sir , i did it , it matches with the one lsblk -f

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=6E2B-F8D9                            /boot/efi      vfat    umask=0077 0 2
UUID=411dc37c-e651-4220-b380-d3306c59e042 /              ext4    defaults,noatime 0 1
UUID=30fde1a2-8594-4a14-86fa-6cdad59bc450 /home          ext4    defaults,noatime 0 2
UUID=8eb80e10-0b17-4e68-8d79-e1c69a792054 swap           swap    defaults,noatime 0 0

https://askubuntu.com/questions/411583/could-not-stat-the-resume-device-file
I don’t have much understanding about this , but if anyone has , please suggest if that’s what i have to do

Is the swap actually used?

swapon -s

top

will also show it in the 5-th line

no need to repartition - the partition is there

the line in /etc/fstab should read:
UUID=8eb80e10-0b17-4e68-8d79-e1c69a792054 none swap defaults 0 0

(noatime doesn’t make sense, since swap is not an actual file system)

but first check whether it is used

ah , how is that to be checked ? i’m currently in live usb ,and all the swap partitions have the option to turn them on as swapon in gparted , but , i don’t think it will be a valid solution to the problem ,

but last time it was the same and working

I just told you.
But I was under the assumption that you where using your actual system - not the live system.

no sir , it’s not accessible as the error is being shown as

Failed to stat resume device '/dev/disk/by-uuid/8eb80e10-0b17-4e68-8d79-e1c69a79
2054` : No such file or directory 

and do i have to first mnt manjaro root partition and then run swapon -s or directly in terminal ?