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

@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"

When using the localmodconfig option, it does not set CONFIG_NLS_CODEPAGE_437(This was causing problems with efi)

It should go without saying, if you change the config your "warranty" is voided. You're on your own as soon as you deviate from the defaults. There's a reason the prebuilt binary works, it uses the default configuration defined in the PKGBUILD.

it's also doing this CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/sbin/init", which is different from CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/usr/lib/systemd/systemd"

By default, /sbin/init is a symlink to /usr/lib/systemd/systemd.

I have now got it now to mount efi and get to graphical environment by manually setting config options. But still have problems with Network and mounting other filesystems. Still probably missing config options.

Your problems are self inflicted. If the defaults don't work, I'm happy to help, but you're turning off config options then surprised when things don't work.

I am not using the comment section as tech support. Please do not make insinuations.

Yes you are, you are asking for support for mistakes you're making. The issue is you think it's the PKGBUILD's fault when you're the one making alterations by not using the Liquorix config unaltered.

@Damentz

I am not using the comment section as tech support. Please do not make insinuations.

I am reporting problems with the package/build.

Here are more concrete examples:

When using the localmodconfig option, it does not set CONFIG_NLS_CODEPAGE_437(This was causing problems with efi)

The only drm related config it sets is CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y

it's also doing this CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/sbin/init"

which is different from CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/usr/lib/systemd/systemd"

I have now got it now to mount efi and get to graphical environment by manually setting config options. But still have problems with Network and mounting other filesystems. Still probably missing config options.

I have not encountered these issues with other kernels that I have compiled.

I will take note of Building in a clean environment. But I dont see how it affects the settings I mentioned.