Fedora 43 Boot partition fix for upgrading from Fedora 42

~$ df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  974M  503M  404M  56% /boot

Question, would it not be easier to live boot into fedora shrink the home partition by 1G or so to then resize the boot to 2 gig and then continue on like normal?

So my thought on doing this is boot to live do sudo gparted
grab the drive for me it is

nvme0n1     259:0    0   1.8T  0 disk 
├─nvme0n1p1 259:1    0   600M  0 part /boot/efi
├─nvme0n1p2 259:2    0     1G  0 part /boot
└─nvme0n1p3 259:3    0   1.8T  0 part /home

Then to be safe just run

sudo swapoff -a
sudo umount /dev/nvme0n1p2 /dev/nvme0n1p3

then go back into sudo gparted select /dev/nvme0n1p3 and Resize/Move make it 1G (1024MB) then select /dev/nvme0n1p2 allocate the new 1G. Then just boot normally.

Is there anything in here that I am missing or that you think wont work? Not sure why I would have to do a full clean install?
I hope that this helps others if no one finds an issue with it or can explain why this can’t work.

1 Like

You can certainly do that.
You may need btrfs tools if your home is btrfs,
and it wont work if your disk is encrypted.

You should definately give it a go.

Reinstall is suggested as it is easier to help newcomers that way rather than go through all the steps with them.

1 Like

You can also just leave it as is. You have about 50% of free space and if it should become tighter, you can always remove the rescue kernel, which I suspect 99% of users never use.

Reinstalling, as mentioned above, ain’t gonna help you as you still need to reshuffle /home.

In theory you can shrink about every file system except for xfs (and maybe ZFS). You can also shrink encrypted LVM LUKS containers, it’s just a little bit more involved.

3 Likes

Yes I figured that it would not work if it was encypted thats why i would think i would need to run sudo cryptsetup luksOpen /dev/nvme0n1p3 fedora-root

But i do see that for new users this would not be advisable. I just do not want to go through too much effort fixing issues that may come up with timeshift.

Yes i considered that and and also just using rpm -q kernel to make sure there are only the last 3 kernels and then cleaning and even limited it to the last 2 kernels.

sudo dnf remove $(dnf repoquery --installonly --latest-limit=2 -q)

Might not be advisable as a new user but figured if there was someone looking as the new version just came out they could look at the thread and try it if they are afraid to do a complete reinstall.

I would not reduce to 2 kernels, set it to 3 or 4 and you will be fine. Probably even 5 would work. Before reducing number of kernels, remove the rescue-kernel.

1 Like

Gotcha is there any reason to not do 2? is it for corruption issues or just freedom of mind?

It is incase you need to fallback to a working kernel.
There were lots of kernel problems in 6.16, lets hope for better luck with 6.17+

It was largely Nvidia users suffering from bloated kernels, for non-users such as me 5 kernels will be fine.

Gotcha waht about for a full Amd build have there been many issues? I am just happy to be daily driving a linux and seeing my ram useage under 10 percent at idle haha.

Not many, in fact I can’t remember one … maybe one :slight_smile:

Actually I remember one compatriot has some serious problem with a AMD dedicated card and 6.17.4 but I have not seen it replicated.

The fact that we don’t see many AMD users asking for help here is a great sign.

I run a 5700G and no problems at all, go for it, F43 is great.

Frankly I’m of the mind that /boot shouldn’t be a separate partition anymore. As long as your root fs is one supported by Grub (or other bootloader of choice), there’s no reason to have both a /boot and a /boot/efi partition. Just have /boot on your root filesystem, as odds are they’re on the same physical device anyway. I really need to get around to fixing this on my desktop, but none of my servers have separate boot partitions anymore, just the ESP partition.