yeah all others are working fine , just one is still unresponsive and that’s something with display drivers , and i won’t deny what you said , the thing is whatever new i learn or get to know , i simply try it out and it often ends up breaking up the system or causing massive trouble
sudo install-grub
WARNING: EFI directory not found! Grub couldn’t be installed.
so:
where is it?
You said you deleted it.
Of course it’s not there anymore if you did.
Make a new one.
It’s usually below the /boot directory.
Or
mount an existing one
i guess it was above it always first as sdb6 maybe after i deleted it and made it again it got sdb10
can the file system fat16 be a problem?
please: no screenshots
and:
I don’t know what that is supposed to convey
If it’s a separate partition, it needs to be mounted.
/etc/fstab
I’ll be leaving for good now.
Good luck learning!
You would think it would be fine, but I have never seen the EFI boot partition not be FAT32.
- Backup
sudo tar cfv ~/efi.tar /boot/efi - Make filesystem
sudo mkfs.fat -F 32 /dev/sdb10 - Restore
sudo tar xfv ~/efi.tar -C /boot/efi - (Optional) Clean up
sudo rm ~/efi.tar
That seems to be garuda’s EFI partition. As you can boot, I’d suggest leaving it as it is for now.
For information:
# this will show where things are mounted, amongst other things
lsblk
# show the / partition layout
ls /
# show what's in /boot
ls /boot
That’s how we learn, break the system…then fix it. You just need to start understanding how things work. That requires a fair amount of reading.
Manjaro Wiki
Garuda Wiki
Ubuntu Wiki
EndeavourOS Wiki
It should be fine and it seems to be working. It seems the EFI partition belongs to another distro, and it isn’t set up the same as Manjaro.
Are the last lsblk -f and cat /etc/fstab posted still current?
So that’s been fixed? The ones posted aren’t. So he can move on to fixing his kernel mess?
Probably, but it’s difficult to keep track. 
AFAIK OP can boot manjaro (and everything but garuda, but that’s a separate issue).
Hopefully the kernels are already sorted out by now. OP was told about them and was asking for clarification hours ago.
Hey Molski , somehow , last night , we were able to have manjaro Grub Bootloader , and luckily all the other distros are also working fine 
Thanks to everyone that helped.
Now , i wanna ask you if i do your steps , can i have some assurance that it won’t break it further ? like i don’t wanna risk it , also , I wanna sum up this post as its already reaching to a higher count of replies.
Thanks
@dmt , this i can assure you it is not , i just checked on Gparted
Garuda
sdb1 is linux-swap , sdb2 is its root , sdb3 is its efi ,sdb4 is home
Manjaro
sdb7 is its root ,sdb8 is home , sdb9 is linux-swap , sdb10 is its efi
EndeavourOS
sdb13 is its root ,sdb5is home , sdb11 is linux-swap , sdb12 is its efi
so nothing is clashing here and the rest ubantu and win10 is on nvme , so i think we guys have done the right thing ,
this was the last command that i ran after nachlese was hopeless of me
sudo mount /dev/sdb10 /boot/efi
followed by installing grub. and voila ,it worked
I’ve done it quite a few times, from Timeshift, Snapper, or just snapshots I made myself.
If you’re comfortable running commands where mistyping one character can destroy data, then it is very safe.
The first step is creating a snapshot, of the the one you choose, and it will become the new root volume. So you are not even changing really much. A simple delete of this this new snapshot, is essentially undoing all the new data block changes.
1 Like
haha ,i’m not doubting you , but its just wanted to be extra cautious , i just ran all the commands as listed by you and didn’t get any errors , but on viewing from gparted , it shows sdb10 to be still fat16 , do i need to restart for the changes to take place.
[parasetu@Pasec ~]$ sudo tar cfv ~/efi.tar /boot/efi
[sudo] password for parasetu:
tar: Removing leading `/' from member names
/boot/efi/
/boot/efi/System Volume Information/
/boot/efi/System Volume Information/WPSettings.dat
/boot/efi/System Volume Information/IndexerVolumeGuid
/boot/efi/$RECYCLE.BIN/
/boot/efi/$RECYCLE.BIN/desktop.ini
/boot/efi/EFI/
/boot/efi/EFI/manjaro/
/boot/efi/EFI/manjaro/grubx64.efi
[parasetu@Pasec ~]$ sudo mkfs.fat -F 32 /dev/sdb10
mkfs.fat 4.2 (2021-01-31)
mkfs.fat: /dev/sdb10 contains a mounted filesystem.
[parasetu@Pasec ~]$ sudo tar xfv ~/efi.tar -C /boot/efi
boot/efi/
boot/efi/System Volume Information/
boot/efi/System Volume Information/WPSettings.dat
boot/efi/System Volume Information/IndexerVolumeGuid
boot/efi/$RECYCLE.BIN/
boot/efi/$RECYCLE.BIN/desktop.ini
boot/efi/EFI/
boot/efi/EFI/manjaro/
boot/efi/EFI/manjaro/grubx64.efi
[parasetu@Pasec ~]$ sudo rm ~/efi.tar
Yes, it can be, and likely is a problem.
I’ll qualify that by asserting that FAT32 is the expected filesystem for an EFI System Partition (ESP).
While it absolutely is possible to have a fully functioning ESP with a variety of other filesystems, only FAT32 is expected and recognised by the vast majority of UEFI boot systems.
Very few systems will default to anything other than FAT32 without much manual intervention. FAT16 is extremely uncommon.
Yes.
even after the restart and running all the commands its still FAT16
how should i fix it then?
This command:
didn’t succeed - because the file system was mounted at the time:
make sure it is unmounted and try again
1 Like
so that means , i need to do it from liveUSB or from any other linux distro that i have , so that its unmounted , true ? and then i have to simply run out all the commands?
Not true, no.
If /boot/efi is on a separate partition, you can mount/unmount it any time you want.
But it may be easier for you to boot from usb and create the file system.
first step ist apparently to gather the contents:
You already did that. You have the .tar file
Then unmount the partition, change the file system, mount it again, before you restore the contents.
Don’t forget to mark it as “boot” and “esp”.
(I do not know how important that is - but I know that my efi partition has got these marks.)
gparted is a tool you can use as well for this - it should be on the USB
You don’t seem to understand the process described.
First it needed to be mounted - because you want to copy the contents off of it.
Then, to change the file system, it needs to be unmounted.
Then, to restore the contents, it needs to be mounted again.
1 Like
Okay , i opened gparted and unmounted dsb10(FAT16) it , to turn it into FAT32, there it asked me to format it and remake it ,which was a successful process , after that i flagged it as boot and it automatically selected esp . now as you said i will have to mount it again , but before mounting i did lsblk -f and realized again the UUID has changed 
now should i mount and run
of course it will have changed
But you don’t need the UUID to mount it again
What you will need to do is adapt /etc/fstab to have the new UUID for that partition
so that the mount will work when you reboot.
The UUID can also be changed and set to whatever, so you could set it to what it was before - but let’s not go there.
1 Like