Opensuse stopped booting (even from live usb), and there are btrfs errors

English Install/Boot/Login
21

Ok, I’ve opened a bug report.
Also, I’ve just discovered that if I wait for around 15 minutes of it being seemingly stuck, it’d continue with the boot process (at least the installation iso did).

22

It is usually considered a good habit to also post the link to your bug report here in such cases.

23

Here’s the bug link

https://bugzilla.opensuse.org/show_bug.cgi?id=1213783

24

I’ve found this: [TRACKING] Kernel 6.4 hang at boot TPM Bug Confirmed - #16 by Maddison - Linux - Framework Community

Sounds similar to the symptoms I got.

25

Does disabling TPM in BIOS help?
Does adding tpm_tis.interrupts=0 kernel parameter help?

26

According to the thread I linked to AFAIK, it’s not enough to have tpm disabled, it has to be hidden(?) I don’t think I have that option on my laptop. Secure boot is disabled, not sure what else I can change wity regards to tpm there…
I’ll try the kernel parameter when I get home.

27

Yes, the tpm_tis.interrupts=0 parameter did the trick.

28

What kernel version are you using? IIRC this should have been fixed in 6.4.4 and Tumbleweed is currently on 6.4.6.

29

I was using the July 28 iso for testing a clean install, and am now using tge latest version of everything, having done a zypper dup just a few hours ago.

30

I’ll try removing tpm_tis.interrupts=0 tomorrow, and see if the new kernel fixed it.

31

Removing tpm_tis.interrupts=0 reintroduces the hang, even for kernel 6.4.6-1

32

btrfs check ... looks at metadata only. You may want to check the filesystem for data corruption: Infamous Host erlangen - #4 by karlmistelberger

You may run a scrub:

erlangen:~ # btrfs scrub status /dev/sdb2
UUID:             61fc4107-d7da-4c0b-a1f4-d92aa6fc1d26
Scrub started:    Sat Jul 29 07:16:18 2023
Status:           finished
Duration:         3:15:57
Total to scrub:   1.17TiB
Rate:             103.43MiB/s
Error summary:    csum=2637
  Corrected:      0
  Uncorrectable:  2637
  Unverified:     0
erlangen:~ #

The above shows the drive is indeed unusable.

33

You are right. In 6.4 exception for the specific system was added. There is more generic patch that automatically detects interrupt malfunction and falls back to probing, but it probably will not be merged until 6.5.

Anyway, good job in finding the root cause.

1 Like
34

You have to specify the --repair option for btrfs check to actually try to repair anything. It only show errors otherwise. But the --repair options might be dangerous see btrfs-check: check or repair a btrfs filesystem - Linux Manuals (8) (systutorials.com) for more details