Can I delete my EFI partition and allocate it to swap?

I broke my grub recently and fixed it by following the Manjaro repair instructions using a liveUSB. During the process, I got the following error after running grub-install:

Installing for x86_64-efi platform.
grub-install: error: failed to get canonical path of /efi.

I got around this by reallocating 1GB of swap space to create an EFI partition. I was rather surprised I got this error in the first place since I didn’t have an EFI partition in my initial install of Manjaro and everything seemed to be fine boot-wise. Nonetheless, I fixed my grub and now I’m left with a 1GB EFI partition that I’m not sure I really need. I only have Manjaro on this system and would like to reallocate this space back to my swap.

My question is, will I cause any problems by reallocating the EFI partition space to the swap space? My hypothesis currently is that I may break grub again since it seemed to require it for the repair. Assuming there are no problems with that then I would think it would be fine since I already messed with the swap partition before and got it working smoothly again after modifying /etc/fstab to include the new swap UUID.

Could you share the command you used to install grub?

Could you also please post the output of sudo inxi -Dazy , sudo blkid and cat /etc/fstab ?

From the very beginning where I messed up my grub: I added apparmor=1 and security=apparmor to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub trying to get AppArmor to work; I no longer care about it and got rid of it. Then I ran:

sudo grub-mkconfig -o /boot/grub/grub.cfg

This caused me to get a black screen on boot with a blinking cursor that never progressed even after 10+ min (keyboard completely unresponsive) after multiple hard reboots.

I then plugged in my liveUSB for Manjaro thinking I could mount my original partition, chroot into it, edit the /etc/default/grub to remove my bad parameters, and then run grub-mkconfig again. I had initially tried to just mount /dev/sda1 for this process but I would get an error everytime I ran grub-mkconfig saying the device wasn’t there (sorry I forgot the exact error). I got grub-mkconfig to run after mounting my /dev/sda1 along with /boot /proc /dev /sys but it didn’t seem to take when I tried to boot back into my original installation.

At that point I followed the Manjaro boot repair instructions and input the following in terminal after booting the liveUSB again.

sudo manjaro-chroot -a
grub-install /dev/sda1

My original Manjaro partition is on /dev/sda1 with swap on /dev/sda2

I then received the error in my original post. I tried googling to see why I would be getting this error in the first place if I didn’t have an EFI on my initial installation but didn’t find much info other than how to simply fix the error.

Then I started Gparted and resized my swap partition from 17.1 GB to 16.1 GB and created the 1 GB EFI partition with fat32 format. I wanted to do this reallocation with my main partition instead but Gparted would not let me resize it. I then entered grub-install again and it ran successfully. I then ran update-grub, rebooted, and got an error saying the hibernation device wasn’t available and a timeout on the swap device, which led to a long boot time that eventually booted to the desktop. Once at the desktop I opened a terminal and ran:

sudo blkid
subl /etc/fstab

and changed the UUID for swap to the current one found with blkid. This got rid of the errors on boot and the long boot time.

inxi -Dazy output:

Drives:
Local Storage: total: 953.87 GiB used: 133.61 GiB (14.0%)
SMART Message: Required tool smartctl not installed. Check --recommends
ID-1: /dev/sda vendor: A-Data model: SP610 size: 953.87 GiB block size:
physical: 512 B logical: 512 B speed: 6.0 Gb/s serial: rev: 5B
scheme: MBR

sudo blkid output:

/dev/sda1: UUID=“d04ac1c5-8fe7-4764-ad13-56e1fe0142aa” BLOCK_SIZE=“4096” TYPE=“ext4” PARTUUID=“fd48f9a4-01”
/dev/sda2: UUID=“014A-B468” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“fd48f9a4-02”
/dev/sda3: UUID=“c479dd99-2333-43df-a007-d36fa2f75d02” TYPE=“swap” PARTUUID=“fd48f9a4-03”

/etc/fstab output (sorry for the butchered formatting):
<file system> <mount point> <type> <options> <dump> <pass>

UUID=d04ac1c5-8fe7-4764-ad13-56e1fe0142aa / ext4 defaults,noatime 0 1
UUID=c479dd99-2333-43df-a007-d36fa2f75d02 swap swap defaults,noatime 0 2
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

As your Linux partition is a MBR partition creating a EFI partition is not something you will need to do, as you would also need to switch your partition format to GPT, which is possible yet bears some risks, to use it.
Since your main drive is only 1TB there is no downside to having a MBR partition-scheme.
So in essence, yes you can delete the EFI partition you created, no downsides involved.
And yes the problem you faced in the end was the result of changing the size of the swap partition, which changed the UUID aswell.
So when you resize the Swap partition again, remember to update the UUID in fstab. :smiley:

And next time you update your grub config, a simple sudo update-grub will be likely be enough. :sweat_smile:

And last but not least some information why grub-install /dev/sda1 failed.
TL.DR. You target drives with that command, not partitions.
https://wiki.archlinux.org/index.php/GRUB#Installation

Hope this helps to shed some light on some things for you. :smiley:

That is all very helpful. Thank you!

One last question. I am currently getting an error sometimes on boot saying:

error: failure to write sector {hexadecimal} to 'hd0'

I read online that changing the boot mode to legacy might fix this… however my boot mode was already in legacy+UEFI in BIOS so I changed it to UEFI. This seems to have fixed the error (will need to boot a few more times to be sure) and decreased boot time even further which is great. Does this change things at all? Is there a relationship between UEFI and my EFI partition at all? Sorry for my lack of knowledge on this.

Never had that error before, so don’t really know what would be causing it. One possible cause could be your SSD deteriorating and slowly getting older. They do have a writecycle max afterall.
But i can help with some more basic info on UEFI/EFI/GPT/MBR.