Package Base Details: linux-ck

Git Clone URL: https://aur.archlinux.org/linux-ck.git (read-only, click to copy)
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 429
Popularity: 7.30
First Submitted: 2011-07-22 14:51
Last Updated: 2020-04-03 19:49

Packages (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 ... Next › Last »

nTia89 commented on 2019-11-08 08:05

Fixed! @sir_lucjan thank you, I tried again and now it compiles flawless. Maybe the reboot fixed the issue, since I upgraded some packages, including mkinitcpio, systemd and gcc...

sir_lucjan commented on 2019-11-07 22:15

mkinitcpio is not involved in the compilation of the kernel at all. It is used only to generate initramfs and it is also possible to do it with dracut.

nTia89 commented on 2019-11-07 18:16

With latest mkinitcpio-27-2, linux-ck compilation (in real it stops before...) stucks just after patching. No errors printed, just "failed in prepare()"

sir_lucjan commented on 2019-11-03 13:11

@toki1990

It's not a linux-ck problem, it's Manjaro. Due to recent updates in Arch Linux (kmod and mkinitcpio) hooks are no longer provided in kernel only in kmod (depmod-hook) and mkinitcpio (mkinitcpio-install and mkinitcpio remove). Unfortunately, at the moment, as a Manjaro user you will not install most of the current AUR kernels and the problem lies solely with your distribution, i.e. Manjaro.

toki1990 commented on 2019-11-03 13:02

I'm manjaro stable repo user. linux-ck 5.3.8-4 not booting. I'm tried linux-slim 5.3.8-2 custom kernel same problem. Xanmod 5.3.8-1 not doing this. Because problem is this:

"Updating linux-xanmod initcpios... ==> Building image from preset: /etc/mkinitcpio.d/linux-xanmod.preset: 'default' -> -k /boot/vmlinuz-linux-xanmod -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-xanmod.img ==> Starting build: 5.3.8-xanmod6-1-xanmod -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect]...."

Xanmod custom kernel doing this last of compilation. Linux-ck 5.3.8-4 not doing this.

graysky commented on 2019-11-01 20:46

@Superice - Yes, I am ignoring that particular change. For example, the substitution will make _srcver=5.3.8-arch1 in this case whereas this package will be 5.3.8-1-ck which is fine for me.

SuperIce97 commented on 2019-11-01 20:39

The pkgver and _srcver variables changed in the main linux package:

pkgver=5.3.8.1
_srcver=${pkgver%.*}-arch${pkgver##*.}

graysky commented on 2019-11-01 18:48

@sir_lucjan - Good catch, thanks. Fixed in 5.3.8-4.

sir_lucjan commented on 2019-11-01 18:09

@graysky

As far as I can see, you forgot to change one line.

-  echo "$_kernelname" > localversion.20-pkgname
+  echo "${pkgbase#linux}" > localversion.20-pkgname

air-g4p commented on 2019-10-31 13:36

@graysky,

It was interesting to see how much 'heat' my wireguard-dkms post generated, and perhaps several of us wireguard-dkms and -ck users have learned some important tips.

Bottom line = tldr version - no action is required provided that: the fou, ip_tunnel and wire modules are found within lsmod and/or modprobed-db list if you run modprobed-db.

Those 3 modules were NOT loaded within MY modprobed-db list, which was quite surprising, given that I have run wireguard-dkms and modprobed-db for a VERY LONG time!

However, once I re-ran: modprobed-db store, it found the three new modules.

Of course, during a subsequent, clean, rebuild of linux-ck, wireguard-dkms was successfully installed.

Thanks for your input graysky, and to the others who offered their comments.