Won't boot after update: Failed to start dracut-emergency.service: Transaction is destructive.

Hi,

After zypper up this morning I can no longer boot my Tumbleweed installation.

This is the end of the output I get:


dracut-initqueue[315]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[315]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[315]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[315]: Warning: dracut-initqueue timeout - starting timeout scripts
(...)
dracut-initqueue[315]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[315]: Warning: Could not boot.
dracut-initqueue[315]: Warning: /dev/mapper/system-root does not exist
dracut-initqueue[315]: Warning: /dev/system/root does not exist
dracut-initqueue[315]: Failed to start dracut-emergency.service: Transaction is destructive.
dracut-initqueue[315]: See system logs and 'systemctl status dracut-emergency.service' for details.
dracut-initqueue[315]: Warning: Not all disks have been found.
dracut-initqueue[315]: Warning: You might want to regenerate your initramfs.

It’s Lenovo ThinkPad T470s and I have just one SSD in it. It’s dual boot with Win 10 and for OpenSUSE I use btrfs on an encrypted partition with a separate /boot. I will post my fdisk below.

I tried to boot a recovery live system and regenerate the initramfs but with no success - it still doesn’t boot and it fails in the same way.

I’m not sure what system logs I should check. Also, can I check ‘systemctl status dracut-emergency.service’ if I’m not able to boot? I can only boot a rescue system and chroot.

Any idea how to fix it or at least how to boot to an older btrfs snapshot? I thought that bootable snapshots will be available in GRUB but apparently not in my setup :-/

> sudo fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xef7fc9f1

Device         Boot     Start        End   Sectors   Size Id Type
/dev/nvme0n1p1           2048    1026047   1024000   500M  7 HPFS/NTFS/exFAT
/dev/nvme0n1p2 *      1026048  369666047 368640000 175.8G  7 HPFS/NTFS/exFAT
/dev/nvme0n1p3      369666048  370491391    825344   403M 83 Linux
/dev/nvme0n1p4      370491392 1000214527 629723136 300.3G 8e Linux LVM

/dev/nvme0n1p3 is /boot and I have root and swap in /dev/nvme0n1p4.

What other info I may provide to show the cause of my problem?

Any help is appreciated. Thanks in advance.

1 - zypper up on tumbleweed? perhaps chroot and try zypper dup? (maybe then dracut if not triggered)
2 - your saying at the initial grub screen where you get the option to boot tumbleweed you dont get several other options including ‘boot from snapshot’ (i cant remember exact wording)

1 - I tried this but it didn’t help - boot fails in the same way.

2- I only have different kernel versions in “Advanced options for openSUSE Tumbleweed”, nothing with snapshots.

  1. are you using BTRFS file system?? If not what?

  2. You DON’T use zypper up on TW you use zypper dup

  1. Yes, BTRFS. I mentioned this in my first post.

  2. If I used zypper up, the worst thing that could happen is that some packages are not updated, correct? Or could this be what broke my system? I tried to chroot from rescue live system and do zypper dup but it didn’t fix the booting issue.

im a little out my depth esp. with encrypted root, but…
1 - if you are on BTRFS AND have snapshots but dont have menu i would guess there is a way to manually set which snapshot to boot* (from live system?), try google. (no idea why you would not have the correct snapshot boot entry)
2 - last snapshot updated systemd, (IF zypper up is the cause) then perhaps you have just been unlucky in your ‘partial’ update.

*[snapper etc are just wrappers around basic btrfs functionality]

1 - I tried to google how to do it but wasn’t successful so far. I’ll keep trying though.
2 - If this was the case, shouldn’t zypper dup in the chroot have fixed it?

Thanks!

for 1, speaking loosely from from hazy recollections what btrfs boots to is essentially set by a pointer/link i.e. what ‘@’ points to. This is very easy to change from terminal. hopefully there is a grub cmd option or something. if your googling dont just include ‘opensuse’ (since everything btrfs is automated) youll often get the low down commands from people who implemented btrfs on e.g. ubuntu arch etc.

I’m not able to figure it out. I tried this: Btrfs - ArchWiki and added rootflags=subvol=/.snapshots/202 into the GRUB options (also tried rootflags=subvol=/.snapshots/202/snapshot) to try and boot into my latest snapshot but it fails in the same way.

As for the missing snapshots in GRUB menu, can it be because I have a separate /boot partition which is not BTRFS but EXT4? I thought this is necessary for encrypted setup so that GRUB can be loaded.

I’m not sure how to edit /etc/fstab before boot though.

Had the same issue yesterday after doing zypper dup on Tumbleweed. No BTRFS here, just ext4 and LVM on LUKS. Got things working after hacking modules.d/90crypt/module-setup.sh so that it does not parse crypttab contents and just copies the whole thing to initrd.

There are no backups of ramdisks that mkinitrd overwrites, so I have no idea how things looked like when everything was working :\

Something like this (I messed around a lot and maybe some more steps are needed)

  • At emergency prompt, unlock the LUKS partition manually with cryptsetup, LVM kicked in and my root was mounted in /sysroot automatically
  • Remount /sysroot read-write
  • Bind mount dev, proc, run, sys under /sysroot
  • chroot to /sysroot
  • Mount boot partition to /boot
  • Edit /usr/lib/dracut/modules.d/90crypt/module-setup.sh and add ‘cat /etc/crypttab > $initdir/etc/crypttab’ after ‘mark_hostonly /etc/crypttab’
  • mkinitrd to regenerate ramdisks
  • reboot and pray

Thanks for the effort but unfortunately this didn’t help.

Unless I find a miraculous solution soon, I will probably need to reinstall the laptop since I need to use it and can’t be without it much longer :frowning:

No other ideas anyone?

The relevant bug is https://bugzilla.opensuse.org/show_bug.cgi?id=1050299

Looks like you have to change the crypttab format too

Thanks! This actually worked.