Package Details: linux-amd 6.10.5-1

Git Clone URL: https://aur.archlinux.org/linux-amd.git (read-only, click to copy)
Package Base: linux-amd
Description: The Linux kernel and modules - With some improvement patches
Upstream URL: https://www.kernel.org/
Licenses: GPL-2.0-only
Provides: KSMBD-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Replaces: virtualbox-guest-modules-arch, wireguard-arch
Submitter: None
Maintainer: archdevlab
Last Packager: archdevlab
Votes: 33
Popularity: 1.19
First Submitted: 2019-11-10 15:20 (UTC)
Last Updated: 2024-08-21 00:22 (UTC)

Dependencies (31)

Required by (6)

Sources (21)

Pinned Comments

archdevlab commented on 2024-08-15 03:38 (UTC)

Hi

I have adopted this package and have updated it!

Thanks!

<deleted-account> commented on 2023-05-04 16:38 (UTC)

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

<deleted-account> commented on 2020-10-26 18:15 (UTC)

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

<deleted-account> commented on 2019-11-10 15:23 (UTC)

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

Latest Comments

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 37 Next › Last »

JP-Ellis commented on 2021-01-13 09:46 (UTC) (edited on 2021-01-13 10:20 (UTC) by JP-Ellis)

Thanks for creating thie PKGBUILD.

I am having an issue logging in when using this kernel, but both core/linux and extra/linux-zen kernel work fine. My user is managed by systemd-homed and it appears that the issue is with access to the .homedir file. Logging in as root still works fine. I have no idea though why permissions on the linux-amd kernel would be any different. Does anyone have an idea?

I'm thinking it might be something with fscrypt not being supported in the same way?

Actually, looking at the linux-amd config, it appears that fscrypt is disbled as the CONFIG_FS_ENCRYPTION is not set. I'm also noticing that the PKGBUILD has quite a few disparities from the upstream linux PKGBUILD (for example, it still is using a .install file even though I believe these are all handled by pacman hooks now).

Scimmia commented on 2020-12-10 16:42 (UTC)

Please see the warning here: https://wiki.archlinux.org/index.php/Kernel/Arch_Build_System#Modifying_the_PKGBUILD

<deleted-account> commented on 2020-10-31 11:25 (UTC)

I have added 'COMPRESSION="lzop"' in the mkinitcpio preset of this kernel. I find this balanced compression for the ramdisk alot faster for installing, and booting from it. Please check your preset file in /etc/mkinitcpio.d/ to make sure that this change is adopted (as there is probably a pacsave file created there instead). Also make sure you have lzop installed.

<deleted-account> commented on 2020-10-26 18:15 (UTC)

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

<deleted-account> commented on 2020-10-21 07:22 (UTC)

I am going to be honest with you: I have no idea. I do not have all the hardware lying around. Mostly if vanilla kernels work so should mine. I don't do anything too radical on this kernel.

dedguy21 commented on 2020-10-20 22:36 (UTC)

I just bought a new Dell G5 SE Ryzen 9 4900hs chip with Radeon 5600 gpu. Just wondering if this Kernel is compatible?

<deleted-account> commented on 2020-09-28 13:50 (UTC)

Well Im looking to keep this package for ZEN2 now for the time being. If ZEN3 comes out this package will become ZEN3 oriented, since this is supposed to target the newest amd hardware, but ill fork this package into a linux-amd-zen2 or something.

PS if you really want a ZEN1 pkg with the current linux version, you can always checkout "linux-raven-latest" on my repo. Its a hidden package I use for some of my machines that have ZEN1 -- But other than tat Im not really looking to maintain for zen1 hardware.

Maybe not useful for you, but just putting it out there.

gebau00a commented on 2020-09-27 05:51 (UTC) (edited on 2020-09-27 05:53 (UTC) by gebau00a)

I checked a little bit in the PKBUILD file and the config. I think you're in so far right, the config does not need to be adjusted. Only in the PKGBUILD, when you enforce the compiler flags, you could replace the znver2 with native. In this case, gcc would revert to the options possible for the processor, not the ones enfored. Kernel else runs smooth without changes to the config file.

Actually I still like to use the aur package so I do not need to manually update my kernel sources and all dkms dependencies all the time. Type of lazy solution for me ;-)

<deleted-account> commented on 2020-09-25 06:44 (UTC)

Uhm... This kernel is actually made for zen2. Where in the makefile would I change what? What kind of override are you thinking about? I'm willing to take a look at this.

As you might have noticed, I always stage the configfiles myself (you can see it is always updated each release in the sources), in the olddefconfig way (save for manual intervention if needed). So it already is flexible if I forget some things, but we are talking about the config that I want to push, the config I deem best for most people (best to my capabilities).

Advanced users with their own settings can surely script around this. With your knowledge, I'm guessing it won't be that hard to create a script that automaticly handles your preferences. I already learned that adapting this kernel to everyone's personal needs would be a never ending back and forth game to play (with me in the middle of it)... I mean: if you got your own config and so your own proper kernel,... then why use this kernel?

gebau00a commented on 2020-09-24 23:59 (UTC)

Whenever I update the kernel, I replace the optimizations for Zen generation 2 with Zen generation 1, both for the kernel config as well as the makefile. Thus i would suggest: In the makefile itself, replace the znver2 with native, so it would always be use the most efficient optimizations available. For the config file, as I come originally from Gentoo where it was standard ro reuse your old config and only adjust on new options, could the aur script be changed in a way to store the old config or use the one from /proc/config.gz?

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 37 Next › Last »