But it was my fault, for generating an initramfs without free space in /tmp, which caused it to fail.
I really don’t think that was your fault. A critical build process that’s not checking for resources and not failing gracefully and leaving the machine unbootable is not the user’s fault.
A build+install can fail for many reasons. It’s actually annoying how many critical system updates on Linux don’t use a staging process and a sudden power-off at the wrong time can leave the machine completely crippled.
Some distros have taken to doing a BTRFS snapshot before they start the upgrade but (a) they’re far and few in between and (b) that still doesn’t fix the upgrade process, it’s just sweeping the problem under the carpet.
I manually triggered it, and didn’t read the logs when it said it failed. That was my fault. If it fails, it will tell you. You still have the machine working until you reboot, so if you read the logs, you can clear /tmp and retry again, and the machine should be bootable again.
Linux lets you do anything, including stupid things. I’d say doing stupid things is the fastest way to learn about it, though.
The same issue would have happened even on Ubuntu, as it uses the same tools as Arch for generating the initramfs. I don’t consider it an Arch or Linux issue, just a user mistake. It won’t happen normally, unless you manually trigger it.
I’m starting to sound like a broken record but since nobody else has mentioned it yet: atomic/immutable distros often use something called rpm-ostree, which stages updates for the next boot. Updates are “atomic”, so you can’t end up with a corrupt partial update, even if you pull the power mid-update (in which case it will just stay on the current version). Everybody gets the same base image, so your OS won’t diverge over time and end up like some frankenstein mess that. It’s all super cool tech.
I really don’t think that was your fault. A critical build process that’s not checking for resources and not failing gracefully and leaving the machine unbootable is not the user’s fault.
A build+install can fail for many reasons. It’s actually annoying how many critical system updates on Linux don’t use a staging process and a sudden power-off at the wrong time can leave the machine completely crippled.
Some distros have taken to doing a BTRFS snapshot before they start the upgrade but (a) they’re far and few in between and (b) that still doesn’t fix the upgrade process, it’s just sweeping the problem under the carpet.
I manually triggered it, and didn’t read the logs when it said it failed. That was my fault. If it fails, it will tell you. You still have the machine working until you reboot, so if you read the logs, you can clear /tmp and retry again, and the machine should be bootable again.
Linux lets you do anything, including stupid things. I’d say doing stupid things is the fastest way to learn about it, though.
The same issue would have happened even on Ubuntu, as it uses the same tools as Arch for generating the initramfs. I don’t consider it an Arch or Linux issue, just a user mistake. It won’t happen normally, unless you manually trigger it.
I’m starting to sound like a broken record but since nobody else has mentioned it yet: atomic/immutable distros often use something called rpm-ostree, which stages updates for the next boot. Updates are “atomic”, so you can’t end up with a corrupt partial update, even if you pull the power mid-update (in which case it will just stay on the current version). Everybody gets the same base image, so your OS won’t diverge over time and end up like some frankenstein mess that. It’s all super cool tech.