Is *_kver=$(ls /usr/lib/modules) OK?

jebez · 2025-12-18 10:41:55

/etc/mkinitcpio.d/linux.preset

ALL_kver=$(ls /usr/lib/modules)
PRESETS=
_uki=/efi/efi/boot/bootx64.efi

See my config under.

I tested (well by

sudo mkinitcpio -P

, I not reinstalled my Arch Linux KDE) it works! /boot/vmlinuz-linux not even exists (I used a /etc/mkinitcpio.d/linux.preset like https://wiki.archlinux.org/title/Unifie … reset_file , with _kver=/boot/vmlinuz-linux).

Since in

man mkinitcpio

& https://wiki.archlinux.org/title/Unified_kernel_image there isn't the *_kver=$(ls /usr/lib/modules) technique, I wonder if it's OK? No problemo? If yes, need update, add this technique in this man page & this wiki page .

Last edited by jebez (2025-12-19 19:26:41)

Lone_Wolf · 2025-12-18 10:49:49

Moderator Note
Not an installation topic, moving to Kernel & Hardware.

V1del · 2025-12-18 11:08:23

It's a value that is irrelevant and will not be read. If you unset $PRESETS it will simply default to a "sane" set of standard values: https://gitlab.archlinux.org/archlinux/ … tcpio#L104 -- so yes unsetting PRESETS could be an option if you don't have/want to have any presets

But this would also mean that your _uki path won't get parsed so you'll likely break on the next actual kernel update because bootx64.efi isn't getting updated. So no for your usecase and assuming you are actually booting that boot64.efi you'd break

Last edited by V1del (2025-12-18 11:11:48)

jebez · 2025-12-18 11:26:46

Do you mean e.g.:

ALL_kver=$(ls /usr/lib/modules)
PRESETS=a
a_uki=/efi/efi/boot/bootx64.efi

? Well I like minimalism, the linux.preset of my 1st post works:

[a@archlinux ~]$ sudo mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: ''
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k 6.18.1-arch1-2 -U /efi/efi/boot/bootx64.efi
==> Starting build: '6.18.1-arch1-2'
  -> Running build hook: [base]
  -> Running build hook: [systemd]
  -> Running build hook: [autodetect]
findmnt: /etc/fstab: parse error at line 1 -- ignored
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
==> WARNING: Possibly missing firmware for module: 'nouveau'
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [sd-vconsole]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful
==> Creating unified kernel image: '/efi/efi/boot/bootx64.efi'
==> Unified kernel image generation successful

the 2nd line: Building image from preset: /etc/mkinitcpio.d/linux.preset: '' so empty counts as a preset name as "a" or whatever, you're wrong V1del.

Last edited by jebez (2025-12-19 08:19:35)

jebez · 2025-12-18 12:43:09

As https://bbs.archlinux.org/viewtopic.php?id=307447 see my previous post.

seth · 2025-12-18 14:46:31

1. don't parse ls
2. what happens if there're more than one kernels installed or stale residual modules?
3. $(pacman -Q linux | cut -d" " -f 2)
4. What are you trying to achieve here?

jebez · 2025-12-18 15:05:15

1. because of 2.?
2. the latest version? It would be nice.
3. oh an other way, now I hesitate...
4. well an UKI, see my config, my signature.

Feature request:
If no _kver in /etc/mkinitcpio.d/linux.preset , by default mkinitcpio takes the latest installed version of Linux (that can be later than the running kernel, after upgrade of Linux).

https://archlinux.org/packages/core/any/mkinitcpio/ , https://gitlab.archlinux.org/archlinux/ … mkinitcpio , but I'm still not registered to gitlab.archlinux.org ...

Last edited by jebez (2025-12-18 16:37:43)

loqs · 2025-12-18 16:33:21

In a shell script you can use globbing or `find` instead of trying to parse the output of `ls` which was not designed for that use case.

seth · 2025-12-18 20:56:36

If no _kver in /etc/mkinitcpio.d/linux.preset , by default mkinitcpio takes the latest installed version of Linux (that can be later than the running kernel, after upgrade of Linux).

https://man.archlinux.org/man/mkinitcpi … UT_PRESETS
Why would there be no *_kver in the preset and what is the "latest installed version of Linux" and how is that different from /boot/vmlinuz-linux ?

jebez · 2025-12-18 21:46:14

no *_kver in the preset: why not? If nothing, by default mkinitcpio takes the latest /usr/lib/modules/a_version .

Read entirely my 1st post:

jebez wrote:

/boot/vmlinuz-linux not even exists

seth · 2025-12-18 22:19:36

Yeah, sure, but you can direct that to any file…

why not?

Because then the file is underspecified and a user error (could be a typo) leads to hidden errors (and some kernel version is picked up for a completely different kernel)

jebez · 2025-12-18 22:32:14

I not understood... but as I said https://bbs.archlinux.org/viewtopic.php … 6#p2278626 I wanna create the feature request but same story: I'm still not registered to gitlab.archlinux.org ; argh!

dimich · 2025-12-18 23:05:04

I apologize for intrusion, I re-read the topic several times but didn't get what problem you are trying to solve. What is the goal?

jebez · 2025-12-18 23:16:40

See

man mkinitcpio

My question was if
/etc/mkinitcpio.d/linux.preset

ALL_kver=$(ls /usr/lib/modules)
PRESETS=
_uki=/efi/efi/boot/bootx64.efi

is OK, no problemo, since I've 1 kernel on my PC, 1 /usr/lib/modules/a_version : it's OK.

Now I wanna create the feature request to https://gitlab.archlinux.org/archlinux/ … mkinitcpio :
If no *_kver in /etc/mkinitcpio.d/linux.preset (*_kver is required), by default mkinitcpio takes the latest version of a linux* package, the linux* packages classified with linux in 1st, & why not e.g. ALL_kver=*-lts for the latest linux-lts .

But as https://bbs.archlinux.org/viewtopic.php … 2#p2277712 I'm still not registered at gitlab.archlinux.org , so I can't.

Last edited by jebez (2025-12-19 09:29:04)

Scimmia · 2025-12-18 23:29:51

The preset is generated from a template that has to work with *all* kernels. This will not work.

dimich · 2025-12-19 00:13:59

jebez wrote:

My question was if ... is OK, no problemo, since I've 1 kernel on my PC, 1 /usr/lib/modules/a_version : it's OK.

ALL_kver=$(ls /usr/lib/modules) is not ok. In addition to mentioned `ls` output parsing and multiple kernels installed, presets in a single /etc/mkinitcpio.d/* file allow to generate different images for the same kernel package. In particular, /etc/mkinitcpio.d/linux.preset is for kernel provided by linux package. For another kernel variant another preset file can be used.

In your /etc/mkinitcpio.d/linux.preset you can write whatever works for you, but why change mkinitcpio?

jebez wrote:

Now I wanna create the feature request to https://gitlab.archlinux.org/archlinux/ … mkinitcpio :
If no *_kver in /etc/mkinitcpio.d/linux.preset , by default mkinitcpio takes the latest /usr/lib/modules/a_version (*_kver is required).

What existing problem such feature is supposed to solve?

6.12.62-1-lts
6.17.11-hardened1-1-hardened
6.18.1-arch1-2
6.18.1-arch1-2-test

Which one is the latest?

jebez · 2025-12-19 08:40:01

ALL_kver=$(ls /usr/lib/modules) in my case is OK, but justly my feature request to throw in the nettles ALL_kver=$(ls /usr/lib/modules) .

Indeed, see my edited previous post.

seth · 2025-12-19 09:00:13

justly my feature request

Spoiler: this is not gonna happen for all the reasons mention in this thread.
You're turning aspects about your personal system into general assumptions.

And you've never addressed

seth wrote:

What are you trying to achieve here?

dimich wrote:

What existing problem such feature is supposed to solve?

Because this has nothing do do w/ UKIs at all.

jebez · 2025-12-19 09:06:26

My feature request to throw in the nettles ALL_kver=$(ls /usr/lib/modules) justly for all cases, not only mine, & I said I like minimalism so a /etc/mkinitcpio.d/linux.preset even minimal.

Last edited by jebez (2025-12-19 09:08:55)

seth · 2025-12-19 09:12:44

The preset /is/ minimal.
A preset w/o a kver simply doesn't cover any kernel
Turning that into it covering any random kernel, that might or not exist, serves no benefit and if you install a second kernel you'll now have edit one of them manually anyway.

jebez · 2025-12-19 09:24:17

See my again edited https://bbs.archlinux.org/viewtopic.php … 4#p2278714 .

seth · 2025-12-19 09:27:49

Referring to the same nonsense again and again doesn't make it less nonsensical and that's pretty much all I got left to say.

jebez · 2025-12-19 09:32:01

Again edited, I not understand your nonsense.

V1del · 2025-12-19 11:02:20

The thing is that that ls makes no sense in a general context, as soon as you have more than one kernel setting any form of _kver that way will be wrong anyway. Or is you goal a single preset that autogenerates multiple images based on an arbitrary identifier? Since you don't have multiple kernels and that's want you want to operate you can well just drop the _kver entirely, or just have it statically refer to the one version you already have anyway, why do you want a pseudo dynamic ls call there?

Last edited by V1del (2025-12-19 11:03:40)

jebez · 2025-12-19 11:42:30

In computer science, in general, when a setting is not set, there must be a default.

It's not the case for *_kver:
/etc/mkinitcpio.d/linux.preset

PRESETS=
_uki=/efi/efi/boot/bootx64.efi

[a@archlinux ~]$ sudo mkinitcpio -P
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: ''
==> WARNING: No kernel version specified. Skipping image ''

Yes I bet it's possible to do my feature request with

ls /usr/lib/modules|some commands

Last edited by jebez (2025-12-19 15:04:50)

Arch Linux

#1 2025-12-18 10:41:55

Is *_kver=$(ls /usr/lib/modules) OK?

#2 2025-12-18 10:49:49

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#3 2025-12-18 11:08:23

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#4 2025-12-18 11:26:46

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#5 2025-12-18 12:43:09

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#6 2025-12-18 14:46:31

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#7 2025-12-18 15:05:15

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#8 2025-12-18 16:33:21

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#9 2025-12-18 20:56:36

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#10 2025-12-18 21:46:14

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#11 2025-12-18 22:19:36

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#12 2025-12-18 22:32:14

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#13 2025-12-18 23:05:04

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#14 2025-12-18 23:16:40

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#15 2025-12-18 23:29:51

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#16 2025-12-19 00:13:59

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#17 2025-12-19 08:40:01

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#18 2025-12-19 09:00:13

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#19 2025-12-19 09:06:26

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#20 2025-12-19 09:12:44

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#21 2025-12-19 09:24:17

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#22 2025-12-19 09:27:49

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#23 2025-12-19 09:32:01

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#24 2025-12-19 11:02:20

Re: Is *_kver=$(ls /usr/lib/modules) OK?

#25 2025-12-19 11:42:30

Re: Is *_kver=$(ls /usr/lib/modules) OK?

Board footer