0

I have an Arch dual boot system with Windows on my desktop PC (not a laptop). It's been while since I've last messed around with it and now I would like to "revive" it. One of the first things I went on to do was a global system update (pacman -Syu). But then I received this error:

error: Partition /boot too full: 4916 blocks needed, 3320 blocks free

So I checked my /boot partition and it turns out it only had 100MB, with 96MB being used already. I then tried to find out how I could increase its size and some posts recommended the classic GParted for it. I felt uneasy, as this is very delicate stuff, but, since I couldn't find other options, I decided to give it a go.

I then unallocated 1GB from my Arch partition, moved it two or three times upwards until it was near the /boot partition and finally merged the two. I cringed when GParted showed me this — sorry for the image quality, I had to downgrade it to upload it here —:

GParted Error

Strangely, both Windows and Arch recognize the new /boot's size as 1.1GB, despite the error. This is what I get from Arch when trying to update it again:

Arch Error

Why is this happening? Is there a solution? Is it because GParted cannot resize the /boot partition beyond a certain size? Is this documented somewhere?

(Everything in my system seems to be working just fine though.)

1 Answer 1

1

Is it because GParted cannot resize the /boot partition beyond a certain size? Is this documented somewhere?

libparted cannot resize FAT16/FAT32 partitions to certain sizes.

There is some code within libparted related to conversion between FAT16 and FAT32 – smaller partitions need to use FAT16, larger ones (2 GB and above) need to be converted to FAT32, and apparently there is a certain range in between where libparted just gets completely confused and its calculation code accepts neither FAT16 nor FAT32 for the requested size.

Nobody seems to have touched this code in the last 10 years since it was re-added.

Strangely, both Windows and Arch recognize the new /boot's size as 1.1GB, despite the error.

The partition that contains /boot has been resized to 1.1 GB, but the filesystem has not. The FAT filesystem structure that's in nvme0n1p2 is still "managing" only the same 100 MB of space as before – its file allocation table hasn't been increased to handle the newly available sectors, etc.

Is there a solution?

Back up all files from the partition, reformat it with mkfs.fat, copy the files back into it.

4
  • "Back up all files from the partition, reformat it with mkfs.fat, copy the files back into it." Could please be more specific about the steps here? Do you have a link to a more detailed post?
    – psygo
    Apr 21, 2022 at 19:47
  • What is the proper way of backing up the files of this type of partition? How do I reformat it to mkfs.fat? How do I copy file into this type of partition afterwards?
    – psygo
    Apr 21, 2022 at 22:23
  • Should I separate the last part of the answer into another question?
    – psygo
    Apr 23, 2022 at 18:49
  • I've continued the overall problem here.
    – psygo
    Apr 24, 2022 at 21:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .