Timeline
Post
Remote status
Context
5
@lanodan@queer.hacktivis.me @volpeon@icy.wyvern.rip Just because Arch is terrible doesn't mean this applies to every other distro though.
@SuperDicq@minidisc.tokyo @lanodan@queer.hacktivis.me @volpeon@icy.wyvern.rip it does not have to do anything with arch itself. This can happen with every distro, if GRUB gets an update but fails or if the initcpio-Image was not build successfully.
The best way to avoid those issues is, by reading through the output of your package manager and ensuring that the installation of GRUB and the Initcpio process were successful.
@kitsune_yasu@waldbewohner.eu @lanodan@queer.hacktivis.me @volpeon@icy.wyvern.rip
This can happen with every distro, if GRUB gets an update but fails or if the initcpio-Image was not build successfully.I'm not that familiar with Arch, but it sounds extremely incompetent to me that Pacman would just continue updating and not fail if grub-install fails.
Debian, for example, has a transaction based package manager so that makes sure when failures like this happen the old stuff that was previously working is not overwritten. So that definitely sounds like a design flaw in Pacman.
@SuperDicq @lanodan @kitsune_yasu @volpeon pacman never does anything with a bootloader. There are two (three) main failure modes that pacman has:
- distro keyring not up to date, failing package authenticity check (archlinux-keyring needs to be updated first)
- pacman deletes initrds on transaction start meaning that if your system fails in the middle of an update, you not only have a system in an unknown state with half-extracted packages, but also no kernel to boot
- when using BTRFS, the free space check can fail because free space as reported by BTRFS isn't actually real and it doesn't use the specific btrfs library for getting free space
- distro keyring not up to date, failing package authenticity check (archlinux-keyring needs to be updated first)
- pacman deletes initrds on transaction start meaning that if your system fails in the middle of an update, you not only have a system in an unknown state with half-extracted packages, but also no kernel to boot
- when using BTRFS, the free space check can fail because free space as reported by BTRFS isn't actually real and it doesn't use the specific btrfs library for getting free space
@phnt @volpeon @SuperDicq @kitsune_yasu
> free space check
btrfs failing to account precisely for free space is wild to me, specially as a filesystem that people do actually use… but well it's also not that surprising given it's poor track record.
Also a free space check should only be considered advisory as a filesystem is highly concurrent. Write errors is what's needed to watch out for and upgrades should strive to failsafe when those happen. (but well, if you wipe initrds at the start, you've already failed).
> free space check
btrfs failing to account precisely for free space is wild to me, specially as a filesystem that people do actually use… but well it's also not that surprising given it's poor track record.
Also a free space check should only be considered advisory as a filesystem is highly concurrent. Write errors is what's needed to watch out for and upgrades should strive to failsafe when those happen. (but well, if you wipe initrds at the start, you've already failed).
Replies
0Fetching replies…