@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.
The problem remains exclusive to host gx745. with today’s zypper dup adding latest LT kernel, meaning behavior doesn’t depend on either default or LT kernel:
I see nothing in /etc/dracut.conf.d/ that looks like could cause this, nor anything in /etc/sysconfig/*. /usr/etc/dracut* doesn’t exist. Nothing in /usr/lib/dracut/* looks suspicious. Any ideas where else I should be looking?
Only one host affected out of 31? That points more to a host-specific configuration difference than a kernel packaging issue. I’d start by comparing the affected host against one of the working systems… ls -l /etc/dracut.conf.d/
That’s been the first thing I look at every time I come back to this, but having been oblivious to the absence of 01-dist.conf in that directory on other installations, and having seen in it neither strings “initrd” nor “initramfs”, I never gave it more thought.
# pwd
/etc/dracut.conf.d
# ls -gGh 01-dist.conf
-rw-r--r-- 1 1.1K Mar 6 2022 01-dist.conf
# grep -v ^# 01-dist.conf
hostonly="yes"
hostonly_cmdline="no"
compress="xz -0 --check=crc32 --memlimit-compress=50%"
i18n_vars="/etc/sysconfig/language:RC_LANG-LANG,RC_LC_ALL-LC_ALL /etc/sysconfig/console:CONSOLE_UNICODEMAP-FONT_UNIMAP,CONSOLE_FONT-FONT,CONSOLE_SCREENMAP-FONT_MAP /etc/sysconfig/keyboard:KEYTABLE-KEYMAP"
omit_drivers+=" i2o_scsi "
# rpm -qf /etc/dracut.conf.d/01-dist.conf
file /etc/dracut.conf.d/01-dist.conf is not owned by any package
# cat /var/log/YaST2/config_diff_2016_04_08.log
Changed configuration files for dracut-044-5.1.x86_64.rpm:
rpm saved /etc/dracut.conf.d/01-dist.conf as /etc/dracut.conf.d/01-dist.conf.rpmsave, but it was impossible to determine the difference
#
Removing 01-dist.conf fixed this in installation of 7.0.10. So, out of seemingly nowhere, between 6.17.9 and 6.18.22 somewhere, this “4” year old file (probably touched needlessly by some update script, thus unchanged since who knows when), absent from (presumably all) other installations, containing nothing I recognize as having anything to do with initrd names, caused this significant change in behavior. What in that file could be responsible for the observed behavior? And, why was it present on only this one (with /root/inst-sys/ dating back to April 2015) out of many installations?
I can only speculate that newer dracut is treating the presence of a legacy custom configuration differently for some reason. Since the file is unpackaged, unique to the affected installation, and removing it restores the previous behaviour, it seems to be exposing a corner case that none of your other systems encounter.
