You are not logged in.
I noticed something worrying on my system:
$ df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme1n1p1 305560 305560 0 100% /boot
$ ls -l /boot
total 265180
drwxr-xr-x 5 root root 4096 Aug 21 07:15 EFI
drwxr-xr-x 6 root root 4096 Jan 8 2024 grub
-rwxr-xr-x 1 root root 115232768 Sep 24 17:56 initramfs-linux-fallback.img
-rwxr-xr-x 1 root root 127059759 Sep 24 17:55 initramfs-linux.img
-rwxr-xr-x 1 root root 13286400 Aug 12 19:02 intel-ucode.img
drwxr-xr-x 2 root root 4096 Jun 29 2022 'System Volume Information'
-rwxr-xr-x 1 root root 15946240 Sep 24 17:55 vmlinuz-linux
$ du -s /boot/*
26060 /boot/EFI
14324 /boot/grub
112532 /boot/initramfs-linux-fallback.img
124084 /boot/initramfs-linux.img
12976 /boot/intel-ucode.img
4 /boot/System Volume Information
15576 /boot/vmlinuz-linux
This is clearly my fault – I must have allocated too little space for /boot – but it is what it is. Now I'm worried than one day, a kernel upgrade won't work because of this and my system will become unbootable. What are my options (apart from reformatting the whole thing, which is something I'd prefer to avoid)?
This is what fdisk tells me:
$ sudo fdisk /dev/nvme1n1
Welcome to fdisk (util-linux 2.41.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.
Command (m for help): p
Disk /dev/nvme1n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors
Disk model: SAMSUNG MZVLB512HAJQ-000H1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: FCFC8A81-C4C5-4AB5-9DE9-187BCA71A0D3
Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 614399 612352 299M EFI System
/dev/nvme1n1p2 618496 651263 32768 16M Microsoft reserved
/dev/nvme1n1p3 651264 205041663 204390400 97.5G Microsoft basic data
/dev/nvme1n1p4 999149568 1000212479 1062912 519M Windows recovery environment
/dev/nvme1n1p5 205041664 999149567 794107904 378.7G Linux filesystem
Partition table entries are not in disk order.
I recall that (g)parted can move and resize partitions – is booting the system from a flash drive and doing that a viable option? (Of course, after making the backup of my data). I have another, larger disk installed – is using dd and bzip a good idea to make a backup of my main disk, just in case? Or maybe there's a way to reduce the size of initramfs-linux.img (or initramfs-linux-fallback.img)?
Offline
You can disable the initramfs fallback entirely. If there is ever an issue with the regular initramfs, you'll have to fix things from USB live.
If Linux is not encrypted and a standard filesystem that Grub supports, you might be able to use /boot on the rootfs (no dedicated /boot partition).
Otherwise you'd have to shrink, either p3 (Microsoft) or p5 (Linux) by a bit to eke out some space for a new, larger /boot partition (without moving anything else).
You can move all partitions around but that's where most things can go wrong. If gparted fails in this process, your data is no longer accessible.
Offline