I’ve had an issue for some time now where I’ve resized my bootloader from 100mb to 1GB, yet for some reason it doesn’t recognise the increased size. Any ideas? I’m using Systemd-boot currently, and I am able to provide any extra information if needed.
I assuming you mean you resized the EFI system partition - how did you do that? Is it possible the partition was resized but the filesystem wasn’t?
yes, the EFI file partition. I’m not quite sure what you mean, but I had resized the partition via GParted. I may well be making a silly mistake as I’m not used to working much with partitions or my bootloader.
Nah, that’s fine, gparted should have done both. Different problem then 
running a quick check it seems that it might need repairing. Should I try that or do I risk breaking my bootloader that way?
so quick update, I accidentally borked my boot entries so I had to go into a live environment, chroot into my system, and sort out the bootloader. It’s still showing as being smaller than it actually is, so the original issue isn’t fixed yet. Any help in resolving this is greatly appreciated.
Sorry, lost track of this thread Where exactly are you seeing the size of the bootloader shown?
where I check it seems to vary. on lsblk and cinnamon’s Disks GUI, it shows 1.1GB, however running df -h it shows the old size of 95MB, which seems accurate as when it is at that level I cannot nixos-rebuild. Also dw abt losing track of the thread, it happens sometimes, personally I’m just glad u answered eventually.
Ah, in that case file filesystem didn’t get resized for some reason - gparted should have done it though?
If you can unmount the efi partition from a running system you can run fatresize from the command line, alternatively I would imagine gparted would have a way to resize the filesystem if it’s smaller than the partition it’s in, but I can’t swear to it.
This random search result reminded me the resize may have failed if the filesystem has errors on it - not that unusual on FAT filesystems as they’re not journaled, so unexpected power loss can easily cause it. I would have expected gparted to check that before starting though?
So anyway, if you can’t get it to resize, try checking / repairing it with dosfsck or your favourite GUI utility. Then above link implies that Partition → Check menu option in gparted should detect the size mismatch and sort it?
I’ll have a look at both of those now, see if either of them work.
so I’ve run dosfsck and fatresize, dosfsck tells me that everything was fine aside from a dirty bit which should be fixed now, but fatresize refuses to recognise it as a FAT partition, despite being recognised by everything else as FAT32
Ah, I’ve just found this: Bug 649324 – failure to move / resize fat32 partitions less than 256 MB in size (newer: Gparted can't resize FAT32 volumes smaller than 256MB (#245) · Issues · GNOME / gparted · GitLab)
So you might have to copy the data off and reformat, slightly scary.
If you’ve got spare space on your disk, you should be able to create a new EFI ESP partition - it’s just fat32 with the special partition type set - and then change the partition type on the old one to disable it. That’s a little less destructive, in that it should be quicker to reverse from a live USB or whatever if something goes wrong. Bear in mind this advice comes with no warranty!
1 Like
well, ain’t that a swizz. Setting up a new bootloader partition should be fine, perhaps I’ll switch to GRUB as well anyways, while I’m at it.
1 Like
I don’t think I do have any encrypted partitions on either drive, so I should be fine. Since there’s a solution more or less now I’ll mark as solved.
2 Likes
This topic was automatically closed 3 hours after the last reply. New replies are no longer allowed.