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
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.
Removing fallback from /etc/mkinitpcio.d/linux.preset & /etc/lmkinitpcio.d/linux-hardened.preset PRESET which makes it like this and enabling lz4 compression reduced my time from 100 seconds to 20 seconds.
PRESETS=('default')
real 0m19.104s user 0m12.970s sys 0m7.856s
On 03/04/20 5:58 pm, Amin Vakil wrote:
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.
In case of Arch Linux when kernel updates it deletes all initramfs and vmlinuz related to that kernel just before the update.
Via: /usr/share/libalpm/hooks/60-mkinitcpio-remove.hook
So when there is update to linux as well as linux-lts and something happens while upgrade is running, none of the kernels will boot.
So best way is to, update each kernel separately. (I normally use pacman -Syu --ignore 'linux-lts*')
Amish.
Em abril 3, 2020 9:28 Amin Vakil escreveu:
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.
The fallback image does help. But if you keep an arch iso usb stick around, and make sure you update it every few months, you can disable the fallback.
Regards, Giancarlo Razzolini
arch-general@lists.archlinux.org