Egregoros

@cjd Ubuntu's default partition setup allocates a 512MB /boot. You tell it "do what you want with the disk" and it'll do that. Then by default it turns on unattended-upgrades. Then it trickles new kernels to /boot but does not remove the old ones and updates the bootloader to boot the new kernel by default, which apparently occurs whether or not /boot is full. Then eventually the user reboots the machine. There are two options on the screen: new kernel, or new kernel plus safe mode. But the kernel it is configured to use does not represent a kernel that is actually on the disk, so it refuses to boot. Ubuntu renders itself impossible to boot. Ubuntu commits suicide if you don't intervene.

I do not know for certain whether this problem persists to the present day but it did occur for years. I don't know who is in charge of QA at Canonical but apparently no one is in charge of telling Ubuntu not to commit suicide.

@p @cjd about the boot partition, 512MB sounds a waste of space, but I think I must be confusing this with the EFI partition, because I made it of 16MB on /dev/sda2 because /dev/sda1 was suddenly "corrupted", and that amount of space was a lot.
Continuing about the topic, you *should* run sudo apt autoremove (or autoclean - I honestly don't remember the difference right now) - oh wait that doesn't remove old kernels I think...
it doesn't, because MX Linux comes with a tool for exactly that, remove old kernels from the boot partition... but isn't the partition where the BIOS checks first? I'm so confused right now.

Anyway, I will use this post to tell you I applied to a job at Canonical once and they made me have an interview with an AI that would skip questions if you wouldn't begin to reply after 3 seconds (each question) -it was so annoying that I let her keep asking to see what were the questions. Mostly about AppArmor and Snap.