@mrmazda does the same happen when using the distribution tools like zypper?
zypper in <localdir>/kernel-longterm-6.12.74-1.2.x86_64.rpm
Bypassing distribution solutions may lead to such problems. As your systems are 100% non-standard, it will be hard for anybody to recreate your handcrafted system setups.
When did you last have a new kernel installed? A day or two ago I had no such problem with the very same old longterm kernel on a different installation. Is your most recent an initramfs.img rather than an initrd?
Haven’t tried yet. Hospital and rehab got me way behind. I’m still quite mentally and physically challenged.
zypper in <localdir>/kernel-longterm-6.12.74-1.2.x86_64.rpm
Next installation’s dup I’ll try, but I’ve been using rpm for kernels in part because it’s quieter and quicker, given I have them locked. Also, it’s a years’ old habit with local packages, a standout in grepping through bash history.
You got that right, e.g.: https://bugzilla.opensuse.org/show_bug.cgi?id=1246561 opened 2025-07-15
I suspect a bug any time zypper can do something rpm cannot. I’ve reported a number of bugs that got fixed over the years by being a maverick. Installations here except for the LAN server all exist for the purpose of attempting to recreate reported problems, and otherwise testing what works or not.
They don’t really deviate that much, unless you count absence of Gnome, snapshotting and/or btrfs. When Dimstar reports a new kernel, I fetch via script with wget to the LAN server’s release directory rather than it’s mirror cache, to preserve the mirror’s timestamp instead of zypper applying the download time. I can expect a number of installations to be getting any given kernel, and bandwidth thus is saved.
How much trouble would it be to try? Fetch a longterm kernel with zypper download-only on a system lacking any longterms, then install it with rpm.
The difference here IMO seems the change from initrd to initramfs in /boot/ means some script(s) must have needed a change that didn’t get done right.
test@twtestbox:~> LANG=C sudo zypper in --download-only kernel-longterm
Loading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is suggested, but will not be installed:
systemd-boot
The following 2 NEW packages are going to be installed:
kernel-longterm virtualbox-kmp-longterm
The following package requires a system reboot:
kernel-longterm
2 new packages to install.
Package download size: 197.2 MiB
Download only.
Note: --download-only is set, otherwise a system reboot would be required.
Backend: classic_rpmtrans --download-only
Continue? [y/n/v/...? shows all options] (y):
Preloading: virtualbox-kmp-longterm-7.2.6_k6.18.22_1-9.1.x86_64.rpm [done]
Preloading: kernel-longterm-6.18.22-1.1.x86_64.rpm [done]
Preload finished. [success (5.3 MiB/s) ] ........................................................................................................................................................................................................................[done]
Retrieving: kernel-longterm-6.18.22-1.1.x86_64 (Haupt-Repository (OSS)) (1/2), 196.7 MiB
Retrieving: virtualbox-kmp-longterm-7.2.6_k6.18.22_1-9.1.x86_64 (Haupt-Repository (OSS)) (2/2), 543.3 KiB
test@twtestbox:~>
# ls -l /boot/efi /boot/grub2
---------- 1 root root 0 Feb 10 2015 /boot/efi
---------- 1 root root 0 Feb 10 2015 /boot/grub2
#
This is MBR disk booting all installations from 13.1’s Grub Legacy, so has no use for efi or grub2 directories. We’ll see when I try another MBR installation after renaming those files…
Not counting OP host, I’ve dup’d 8 other TW hosts since OP. On 7 of them I also installed the LT 6.12.74 kernel, and on 3 I also or instead installed LT 6.18.2[2,3]. On none since did the kernel installation behavior match the OP host - IOW, no reproduction. OTOH, the OP differed from all others in creating /boot/initramfs-6.12.74-1-longterm.img instead of /boot/initrd-6.12.74-1-longterm. There are >20 more installations to catch up on, but I’m in no rush to get them all more current. All but one were last done in February or March, the other one my rarely used older iMac in December.
I’ve installed 6.12.74 on all TW installations it ever will be here, 31 in total, all via rpm directly, and none of the other 30 reproduced the aberration reported in OP here for host gx745. Various 6.18, 6.19 and 7.0 kernels were also installed on some, also without reproducing on any of them.
However, I just installed 6.19.12 on gx745, and again, initramfs instead of initrd was created for 6.19.12, just as occurred for 6.18.22 the day after OP.
To have 6.19.12 vmlinuz and initrd symlinks (used by my default 13.1’s Grub Legacy Gfxboot bootloader’s TW stanzas on all MBR booting systems except one), I had to create them. I’m out of ideas what to look at trying to find what config could be different on this one old host from the 20+ other TW installations booting in same manner, and those booting EFI.
