Hi Guys,
So, mkinitcpio-30 (on [testing]), uses zstd by default for initramfs images, since all our kernels now support it. I plan to move mkinitcpio in the next 24-48 hours but, since I anticipate some people holding back 5.4 kernels, I want to send the following news announcement (here [0] is the md I'm using, so feel free to help there):
---- All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing].
If, for any reason, you are using a kernel version prior to 5.9, make sure to change mkinitcpio.conf COMPRESSION to use one of the compressors supported, like gzip, otherwise you *will not* be able to boot images generated by mkinitcpio.
Regards, Giancarlo Razzolini
Giancarlo Razzolini via arch-dev-public arch-dev-public@lists.archlinux.org on Wed, 2021/02/17 10:51:
All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing].
You should name the version number, just to make sure the context is not lost after the move.
Em fevereiro 17, 2021 11:13 Christian Hesse escreveu:
Giancarlo Razzolini via arch-dev-public arch-dev-public@lists.archlinux.org on Wed, 2021/02/17 10:51:
All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing].
You should name the version number, just to make sure the context is not lost after the move. --
Good idea. I've reworked the text of the first paragraph to:
---- As linux-lts moved to the 5.10 version, all official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default with version 30, which is currently on [testing]. ----
You can also make changes to the md directly too, if you wish.
Regards, Giancarlo Razzolini
On Wed, Feb 17, 2021 at 11:40:58AM -0300, Giancarlo Razzolini via arch-dev-public wrote:
Em fevereiro 17, 2021 11:13 Christian Hesse escreveu:
Giancarlo Razzolini via arch-dev-public arch-dev-public@lists.archlinux.org on Wed, 2021/02/17 10:51:
All official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default on the version that is currently on [testing].
You should name the version number, just to make sure the context is not lost after the move. --
Good idea. I've reworked the text of the first paragraph to:
As linux-lts moved to the 5.10 version, all official kernels of Arch Linux now support zstd compressed initramfs images, so mkinitcpio is switching to zstd compressed images by default with version 30, which is currently on [testing].
Why the rush though? The kernels where released not even a day ago and why risk breaking peoples setup? Even if partial upgrading the kernel is not recommended it's a fairly common strategy.
I'd rather wait a good week for people to have completed the upgrades. I personally do this so I can chug along the testing repositories more easily and not have to reboot every day for my webcam to work.
zstd is nice, but not lets-break-a-common-upgrade-strategy nice.
Em fevereiro 17, 2021 12:05 Morten Linderud via arch-dev-public escreveu:
Why the rush though? The kernels where released not even a day ago and why risk breaking peoples setup? Even if partial upgrading the kernel is not recommended it's a fairly common strategy.
Hence the news entry?
I'd rather wait a good week for people to have completed the upgrades. I personally do this so I can chug along the testing repositories more easily and not have to reboot every day for my webcam to work.
It can be a week, a month, or even more before everyone using Arch has updated. This has the potential to affect only users running linux-lts on 5.4 or holding back linux on a version prior to 5.9, for some reason. Most users won't even be affected by this.
zstd is nice, but not lets-break-a-common-upgrade-strategy nice.
I can delay the update for an arbitrary number of days (a week?), but in the end it's arbitrary, without clear guidelines.
Regards, Giancarlo Razzolini
arch-dev-public@lists.archlinux.org