Installing 7.2.1 version of SlowRoll, I am discovering the following “unpleasant” behavior on an HP Envy x360 Convertible laptop. This system has Secure Boot off, and an older BIOS that is very “tired” so I do not want to enable NVRAM writes.
So the install completes successfuly, the /boot/efi/loader/entries entry for opensuse-7.2.1-7 kernel is created, referencing a linux-[GUID] and initrd-[GUID] files. Only one of these files exists in /boot/efi/opensuse-slowroll/7.2.7-1-default after installation. On another installation done within 24 hours of this machine (a Dell Latitude 9410) with the same install media (0901) both files are created.
Only diference was NVRAM writing was inhibited on the HP due to the worn-out UEFI chip.
Can anyone help me figure out a workaround? I tried using a rescue media and chroot followed by dracut -f and manually copying the file from /boot to /boot/efi/opensuse-slowroll/7.2.7.1-default/ but this seems to result in kernel panic involving bad root device. Any help MUCH appreciated!
The bad root device panic you reported suggests that the kernel and initrd may not be a matching set…or maybe that the initrd was not generated with the correct root filesystem information?
As requested, HOWEVER, after freeing up some space on the ESP, the last install completed successfully.
Thanks for the peek in, @deano_ferrari … speaking of Ferrari, I feel like I just peeked into the engine compartment of a 1963 Ferrari 250 GTO … wonder why no install logs dropped me a hint into the space exhaustion of the efi partition?
Boot Loader Specification type#1 entry
title openSUSE Tumbleweed-Slowroll 20260901
version 7.2.7-1-default
sort-key opensuse-slowroll
options root=UUID=3b8e3dc9-7da1-4c47-b8b4-fa0ec3b37150
linux /opensuse-slowroll/7.2.7-1-default/linux-e13dc69435d5b91c3372b96b3b3cf8c7868a18e1
initrd /opensuse-slowroll/7.2.7-1-default/initrd-3d9e5aebd645dcfce8a14acaa19662a10f865347
localhost:~ # ls -l /boot/efi/opensuse-slowroll/7.2.7-1-default/
total 65368
-rwxr-xr-x 1 root root 49394367 Oct 3 2026 initrd-3d9e5aebd645dcfce8a14acaa19662a10f865347
-rwxr-xr-x 1 root root 17537392 Sep 22 04:02 linux-e13dc69435d5b91c3372b96b3b3cf8c7868a18e1
For anyone stumbling upon this or similar issues, there was a second issue most likely causing kernel panics I mentioned. A line was being inserted in the entries file with rdinit=vtoy/vtoy, probably because the source installation media was located on a Ventoy partition. Removing that from the .conf file, and also zypper rr *x* to remove the installer mount should keep this from happening again.
And here we go again: Ventoy. Forget about this install. It is Ventoy causing this (again and still). Create the USB with supported methods, i.e. Fedora Mediawriter, Impression, or plain dd.
From what I’ve experienced on my own system dracut invoked directly won’t copy to the correct location with systemd-boot, sdbootutil mkinitrd and then sdbootutil update-all-entries does.
OK so I didn’t read the docs saying ventoy needs to be taboo’ed. Is there any way short of reinstalling to prevent future kernel updates from writing that bit into the boot stanza in the systemd-boot?
Is this a known issue, I’ve been using Ventoy with almost every other install media, as well as OpenSUSE slowroll in the (not too distant) past. Any chance there’s a bug in the bits around systemd-boot, which is a relatively new thing with Tumbleweed installers?
@knurpht@almopensuse it’s not recommended to use anyway. From a security perspective is a pile of “fill in the blanks”. It’s already been discussed that it’s built with unverifiable binary blobs which could contain anything…
There must be some unique features of the ISO distributed on opensuse.org that interact poorly with Ventoy or unetbootin, since it’s the only Linux distro I’ve ever encountered that has a problem with those software packages after installation.
And possibly related to the switch from GRUB bootloader to systemd-boot? I never encountered this in previous GRUB-targeting installers.
The Ventoy issue was already explained countless times in different threads. Ventoy alters the installation medium and adds random boot parameters and other stuff. Some versions work, others don’t, others break…
Thus the openSUSE maintainers decided to flag Ventoy as unsupported. The openSUSE maintainers provide a working ISO. If some 3rd party tools alters the working ISO and add random code snippets which break the ISO, it is not the fault of openSUSE. Blame Ventoy.
OK thank you for the enlightening reply. I assume this will be a problem with other distros as well, as the gradual move to systemd-boot by the Linus-sphere completes, or possibly Ventoy and unetbootin will “catch up” by then. I believe (as a “home lab” type user) that security will continue to be a mix of using older “trusted” software/installers and migrating to newer ones when AI finds exploits in the older ones. Installers should be the first to be abandoned as the devs have done with Ventoy, as some of the “extra” bits could end up being malicious.
