Tumbleweed Dracut broken

English Install/Boot/Login
1

When I update to kernel 5.18.1-1 or 5.18.2.1, Dracut locks up my system when creating the initrd file. I also tried installing the latest version of Tumbleweed to another partition, and the installation locked up the computer about 50% into the installation. I suspect the freeze is also occurring when creating the initrd file. The computer freezes at

*** Including module: kernel-modules ***

When I look in my /boot folder, everything for the kernel is created except for the initrd file I’ve done a search and can’t find anyone that has the same problem. The system runs file with the older kernel 5.17.4-1. I looked through log files and can’t see anything wrong (although I admit to being somewhat of a newbie in this). Thanks.

2

@MikeD:

If your system partition uses Btrfs, is there enough free disk space within that partition to allow dracut to write configuration?

 # btrfs filesystem df /

Also, if Btrfs, you may have to remove some of the snapshots provided that, they’re no longer needed …
Also, if Btrfs, you may have to perform some Btrfs housekeeping – “balance” and “scrub” …

3

I’m using ext4. Plenty of room in the partition.

4

Good news: Tumbleweed dracut isn’t broken at all on my systems as listed in the signature.

Bad news: Your system is broken I presume. Tell a little bit more about it. Polling for information isn’t fun at all.

5

Tell more about it. Tumbleweed is ok here on my side with latest snapshot.
Is your “update nvram entry” enable" ?
Have a look at it in yast2 boot loader.

How many kernel versions you have in tumbleweed?

6

I don’t see that setting in the boot loader. I have kernel 5.17.9-1 that works. I also have 5.18.1-1 and 5.18.2-1 kernels that have no initrd files. I have a 10 year old bios computer (not EFI). Intel Core I7, Gigabyte motherboard, 24 GB ram, Samsung 860 1 TB SSD. I have a number of other distros (Arch, Debian, KDENeon, Manjaro; all use KDE) in a multiboot system, logical partition, Grub2 bootloader, including Windows 10 on another SSD. No problems with the other distros. Tumbleweed had been installed many years and only now am I having problems with it.

7

Yes, it is okay here too.

Is your “update nvram entry” enable" ?

That option is only there for UEFI booting. It won’t be there for legacy booting.

I doubt that it is relevant to the problem. I disable NVRAM updates, but I am not having problems.

8

Yep, I had problem with the nvram enabled on UEFI, the boot loader can’t go through, when I disabled it, it did finished saving the boot loader.
I think it’s about a filled nvram problem if memory serves. It was not mentioned in the earlier post if he is in UEFI or legacy.

Also sometimes if the os contains so many kernels versions dracut cycles through all of those versions and take up a lot of time finishing the configuration.

9

This is true. I normally keep 3 kernels (the two most recent, and one from the previous series). At present that’s 5.18.2 and 5.18.1, as well as a 5.17 kernel. After a kernel install there will be 4 kernels until cleaned up on the next boot.

10

Roll back to the snapshot which works and redo what you have done since. This worked on one of my machines, when lvm (I never use it intentionally) messed with my drives and recovery from the mess was beyond my knowledge.

11

I can’t, I’m on ext4. Are older Tumbleweed snapshots available? I couldn’t find them. I probably should submit a bug report against dracut. I can’t even roll back dracut, as older versions aren’t available. As I said, I tried to install Tumbleweed on on another partition and dracut failed and froze the computer, so it’s not my original installation that’s at fault.

12

http://download.opensuse.org/history/

13

Thanks, unfortunately, that doesn’t go back far enough. The oldest version there is the one that I have installed (which is also the current version), which was last updated 5/12/22.

14

Hi Mike,

I observed a similar kind of problem you described.
For me it seems that my boot partition (on a dedicated partition, sda1) is not mounted automatically anymore. And everything started to go into the /boot directory which stores the files on the root partition, not on the boot partition. All the stuff went here is useless.

For me something somehow without my consent, without my knowledge modified my /etc/fstab on 2022.06.05, deleted the line responsible for mounting the /boot.

Probably I did a zypper dist-upgrade around that time.

I checked my old system hdd, fortunately I just replaced it before this problem happened, and yes, the following line is missing now:

UUID=71e75aee-baee-4f7b-b359-79e0331beaaf /boot                ext4       acl,user_xattr        1 2

(Now I corrected my fstab, uninstalled the 5.18 kernels, deleted all the garbage from the /boot directory on the root partition for a clean mount point, rebooted, checked if the /boot is properly mounted and yes, and installed the new kernel. Now everything works again.)

15

What I wanted to say is check if the /boot is properly mounted, check if everything is OK in /etc/fstab.