As it's true for pretty much all update process for pretty much every OS in the world, things can break if the update is interrupted.

I meant as other linux distros keep multiple kernel versions, if something happens during kernel update you can always boot to another kernel which I've done on CentOS servers before when update has broken during kernel update.

For my particular setup, running `mkinitcpio -P` yields those times:

real 1m8.320s user 0m24.742s sys 0m12.806s

---

Half of the time mkinitcpio was waiting for disk I/O. Most likely `find`, but that?s only mu guess.

As my Arch is on SSD I suppose hard drive is not a bottleneck.

Even while it's unlikely that only mkinitcpio suffers from a damaged HDD and even while smartctl not necessarily does show issues of a already damaged aged HDD, I would run smartctl and take a look, if it shows something fishy.

Good point, I've checked and my SSD is OK.

change the COMPRESSION variable to lz4 ou lzop in your /etc/mkinitcpio.conf : it will considerably reduce the compression time.

Great suggestion, I've compared with gzip and it's really considerably faster. (Four images are built, linux (default, fallback), linux-hardened (default, fallback))

gzip: real 1m42.140s user 1m22.717s sys 0m23.493s

lz4: real 1m1.120s user 0m44.310s sys 0m21.785s

cat (without compression): real 0m59.477s user 0m43.050s sys 0m21.946s

To sum it up I will enable lz4 compression to benefit from both reduced time and saving space. Also I'm planning to read wiki on how to safely disable fallback. I'm using LVM on LUKS method and I suppose fallback image cannot boot my Arch, so it doesn't help in case of an accident.

Thank you all