You are not logged in.
$ df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 47M 47M 512 100% /boot
$ lsblk /dev/sda1
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda1 8:1 0 1G 0 part /boot
47MB vs 1GiB, i don't think it's filesystem's metadata (or is it?).
I'm on GPT UEFI 64-bit official kernel, /boot is FAT32 on /dev/sda1 which is of type "EFI System". I'm using GRUB2 as bootloader if that's relevant.
All partition tools (gparted / gdisk / etc) reports 1GB of space, but other tools like df and GNOME Monitor tells me it's 47MB.
It seems that the file system doesn't fully occupy the partition?
Resizing FAT32 is not supported by gparted (it does show it is 1GiB when resizing, so I tried shrinking it to 1000MB).
And I dare not try to backup and re-make the filesystem currently,
since I don't know if it has any magic connection with UEFI which may be silently removed when I make new filesystem on it.
So why is that and how can I enlarge it to at leat 500MB (in terms of df)?
Offline
How did you create the filesystem on /dev/sda1?
Please post your fstab
Check the filesystem integrity -- see fsck.fat()
Offline
How did you create the filesystem on /dev/sda1?
It was about 2 years ago, I don't quite remember how I did it, but I believe I followed the Arch Wiki Beginner's Guide of that time.
I think it was normal months ago, since I suddenly received a insufficient space notice on /boot by GNOME at that time.
I thought it was not a big problem since I only have 1 kernel, without considering about the cause.
Now I'm trying to install ck kernel, and found the problem.
Please post your fstab
It was automatically generated, and I didn't touch it manually:
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda2
UUID=9cd24ee4-fdcd-4738-b525-28aa29067b56 / ext4 rw,relatime,data=ordered 0 1
# /dev/sda1
UUID=A631-4E02 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
# /dev/sda5 LABEL=User_Data
UUID=00416020-3756-4884-aa6e-9e768b05d232 /home ext4 rw,relatime,data=ordered 0 2
Check the filesystem integrity -- see fsck.fat()
Isn't it done automatically on boot by systemd?
(I shutdown my computer every night.)
After fiddling around, I found this in gparted:
>>moderator edit: Removed large image. Please read Forum Etiquette: Pasting Pictures and Code. Thanks. --fsckd<<
So, yes, the filesystem doesn't fully occupy the partition.
But, when I do the "partition -> check" as it suggests, it failed to resize the filesystem. Console output:
======================
libparted : 3.2
======================
GNU Parted cannot resize this partition to this size. We're working on it!
Googling around suggest me to "upgrade to libparted 3.1" (I think that thread is quite old) or "re-make the filesystem".
So I did it. Seems UUID is changed by mkfs so I also modified fstab and did grub-install to ensure the bootloader is usable.
And now 1GiB space is fully occupied.
But I still wonder why it shrunk.
Last edited by fsckd (2015-08-01 13:11:17)
Offline
Head_on_a_Stick wrote:Check the filesystem integrity -- see fsck.fat()
Isn't it done automatically on boot by systemd?
(I shutdown my computer every night.)
If you want to check for errors in your filesystem you use fsck. It woiuld have told you if there were any errors found and you would have pasted the output here so that we could see what problems might have existed.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline