Arch Linux User Repository

Official binaries of linux-lqx, linux-lqx-headers, and linux-lqx-docs are now available: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#liquorix

Signing key import instructions: sudo pacman-key --keyserver hkps://keyserver.ubuntu.com --recv-keys 9AE4078033F8024D && sudo pacman-key --lsign-key 9AE4078033F8024D

@surfitux, if you can link me to a good template for me to start with, I can figure out how to incorporate into regular updates.

support fedora plz

@damentz, thank you, I managed to build it.

@crud, looks like I was wrong, CONFIG_PREEMPT_DYNAMIC exposes lazy preemption even if the system doesn't support it. Next update will include a "fix", but in the meantime you can turn off this feature unless you have a good reason to swap preempt methods at boot.

Related issue: https://github.com/zen-kernel/zen-kernel/issues/377

Use Preemptible Kernel (Low-Latency Desktop) (PREEMPT), but the error is related to Scheder Controlled Preemption Model (Preempt_lazy)

It actually sounds like you're enabling lazy preemption. Liquorix doesn't support it at the moment, pending an official port of Project-C to v6.13.

You can use the binary build listed in the pinned comment if you're having trouble building the kernel locally.

Someone managed to collect the kernel 6.13.5? I can't do it

ERROR: modpost: "preempt_model_lazy" [arch/x86/kvm/kvm.ko] undefined!
ERROR: modpost: "preempt_model_lazy" [fs/jbd2/jbd2.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:145: Module.symvers] Error 1
make[1]: *** [/media/files/linux_pkg/aur/linux-lqx/src/linux-6.13/Makefile:1932: modpost] Error 2
make: *** [Makefile:251: __sub-make] Error 2

Use Preemptible Kernel (Low-Latency Desktop) (PREEMPT), but the error is related to Scheder Controlled Preemption Model (Preempt_lazy)

@Damentz

Yes I read it. Yes i have it installed. And yes I have modprobed.db populated with modules. I have even used it with other kernels.

I am sorry I cannot take your condescending attitude anymore.

"Failure to read and follow the instructions ....." Seriously?

I know there's no guarantees and you're doing it for free. So don't take it to heart.

Let me reiterate before I leave this for good.

The ABS for the vanilla arch kernel, lts, rt etc etc work with the same process. This one does not.

@Arch_User, did you read the comments in full before using localmodcfg? Below are the sections that matter.

# Compile ONLY used modules to VASTLYreduce the number of modules built
# and the build time.
#
# To keep track of which modules are needed for your specific system/hardware,
# give module_db script a try: https://aur.archlinux.org/packages/modprobed-db
# This PKGBUILD read the database kept if it exists
#
# More at this wiki page ---> https://wiki.archlinux.org/index.php/Modprobed-db
_localmodcfg=

And

  ### Optionally load needed modules for the make localmodconfig
  # See https://aur.archlinux.org/packages/modprobed-db
  if [ -n "$_localmodcfg" ]; then
    if [ -f $HOME/.config/modprobed.db ]; then
      echo "Running Steven Rostedt's make localmodconfig now"
      make LSMOD=$HOME/.config/modprobed.db localmodconfig
    else
      echo "No modprobed.db data found"
      exit
    fi
  fi

Failure to read and follow the instructions will result in exactly what happened when you booted your kernel. This feature cannot be used properly without preparation on your end. And unfortunately, there's no real way to tell if you have, as a dangerously reduced set of modules and kernel features could be completely intentional depending on your use case.

At least I have the answer to the question of "What's the difference between the builds". The answer is "No difference (probably) if you ignore the options in the pkgbuild"

Correct, the defaults are used for the binary repository. All other features you see are for niche use cases and experimentation. They're a convenience if you know why you're using them and need them for any reason.

@damentz

Why does the the PKGBUILD have _localmodcfg= ?

If it's not meant to be used, why is it even there?

The PKGBUILD does not say anything about not using it either.

By default it tries to build over 6000 modules.

Is that the prefered method? The PKGBUILD should at least say so.

And as stated before, I tried many times before posting anything here.

Other than the patches/scripts, the PKGBUILD is very much the same for the default Arch kernel PKGBUILD from the ABS. Which works flawlessly.

I will try to build the "default" as you suggested. I will check in later.

And again no. I am not using this as tech support. I am talking about the options provided in the PKGBUILD that fail. If it wasnt obvious before, it should be now. I have been solving the problems on my own.

At least I have the answer to the question of "What's the difference between the builds". The answer is "No difference (probably) if you ignore the options in the pkgbuild"