Arch Linux User Repository

GCC13.1 is mainlined in arch, so this means znver4 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver4 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver3 based hardware, please use linux-amd-znver3
If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

GCC11.1 is mainlined in arch, so this means znver3 support can kick off on this kernel. The graysky compile patches have been updated too.

This kernel now natively supports the znver3 arch, but this kernel will most likely keep working on all AMD ryzen hardware. It's better to be able to address certain small perks or issues per architecture now and in the future.

If you use znver2 based hardware, please use linux-amd-znver2
If you use raven based hardware, please use linux-amd-raven

Tired of compiling? Use this binary repo instead! Add this at the end of /etc/pacman.conf :

[linuxkernels]
Server = http://nhameh.ovh/$repo/$arch
SigLevel = Optional TrustAll

oh, ok well, just be advised I cannot give any support on dracut image generation on arch linux. (I use it on rhel but not here...)

My distro uses dracut by default. I just ignore the mkinitcpio msg.

I would advise to stop using dracut and start using the distrubution's way of making ramdisks, called mkinitcpio.

using dracut i got theis "error" it does not harm i bet ;)

>>> Updating module dependencies. Please wait ...
>>> Generating initial ramdisk, using mkinitcpio.  Please wait...
/tmp/alpm_4art4J/.INSTALL: line 24: mkinitcpio: command not found

only wanted to mention this may tehre is a way to omit this too.

From what I understand, and I could be wrong as I haven't ever build a package myself, so either ignore/forgive me or correct me, as long as you have included linux-amd.preset in backup= in the PKGBUILD, the current (= my edited linux-amd.preset without the fallback option) is being renamed and preserved as a .pacsave, (making it unuseable in this case) https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#.pacsave and in order to prevent the upgrade from overwriting my file I'm going to add its path to NoUpgrade=etc/mkinitcpio.d/linux-amd.preset in /etc/pacman.conf : "All files listed with a NoUpgrade directive will never be touched during a package install/upgrade, and the new files will be installed with a .pacnew extension."https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#Package_backup_files and I'll see from that point on. (iirc building and installing with the traditional way, makepkg -si, works fine, instead of pacman locally or using a helper, or I could try & error editing out that line from the PKGBUILD -as an educational process-)

According to your link, there should be by default imo a .pacnew situation, yet (I assume because of the inclusion in backup=) there is a .pacsave situation: "original = X, current = Y, new = X The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user." Thanks for all the work nonetheless.

@jansux2 see https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#Types_explained

Well first of all your current configuration will never get overwritten. I disabled the rescue as well in my file and it gets left alone.

I do not know why you are discussing pacman behaviour with me -- pacman is not maintained by me, please take up your issue with the archlinux core team.

Hi, replacing (an edited) linux-amd.preset with the default each time and keeping a .pacsave for the old version isn't suitable for the cases one doesn't want a fallback initramfs image (small ESP), could you provide a .pacnew instead?

Looks like they did the exact thing upstream, but a whole day later..... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.2.y

Building new version of the kernel... Which is exactly the same as this one....

Reverted the faulty git commits. How this kernel panic did not get spotted upstream is completely beyond me.