Bug 1170344 - Tumbleweed 20200417+ (plymouth): kernel booting stop at "BTRFS info" output
Tumbleweed 20200417+ (plymouth): kernel booting stop at "BTRFS info" output
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Critical (vote)
: ---
Assigned To: Cliff Zhao
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-04-23 13:30 UTC by Hillwood Yang
Modified: 2020-05-04 16:26 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
dmesg.log (94.86 KB, text/x-log)
2020-04-23 13:32 UTC, Hillwood Yang
Details
hwinfo of my pc (1.14 MB, text/plain)
2020-04-24 12:55 UTC, Hillwood Yang
Details
hwinfo of my laptop (1.36 MB, text/plain)
2020-04-24 13:00 UTC, Hillwood Yang
Details
dmesg for my laptop (87.26 KB, text/plain)
2020-04-27 13:57 UTC, Hillwood Yang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hillwood Yang 2020-04-23 13:30:24 UTC
I Updated My PC and laptop to Tumbleweed 20200417, then these two systems could not boot, and there is not any error on screen. I tried to chroot to get the dmesg log, I got many BTRFS notices at the end. I find Btrfsprogs was updated before 10 days ago in Factory. I guess this is a bug for Btrfsprogs.
Comment 1 Hillwood Yang 2020-04-23 13:32:24 UTC
Created attachment 836620 [details]
dmesg.log

[  112.463605] BTRFS info (device sdb3): disk space caching is enabled
[  112.463608] BTRFS info (device sdb3): has skinny extents
[  112.475556] BTRFS info (device sdb3): enabling ssd optimizations
[  112.475974] BTRFS info (device sdb3): checking UUID tree
Comment 2 Hillwood Yang 2020-04-24 03:27:47 UTC
Sorry, this is not a bug of Btrfsprogs. I can not find the bug point.
Comment 3 Hillwood Yang 2020-04-24 12:55:34 UTC
Created attachment 836717 [details]
hwinfo of my pc
Comment 4 Hillwood Yang 2020-04-24 13:00:19 UTC
Created attachment 836719 [details]
hwinfo of my laptop
Comment 5 Alynx Zhou 2020-04-26 02:35:23 UTC
Hi, is this a kernel module bug? If not please reassign, thanks!
Comment 6 Hillwood Yang 2020-04-27 13:57:44 UTC
Created attachment 836858 [details]
dmesg for my laptop

This time it stop at "rfkill: input handler disabled"
Comment 7 Hillwood Yang 2020-04-27 13:59:58 UTC
(In reply to Hillwood Yang from comment #6)
> Created attachment 836858 [details]
> dmesg for my laptop
> 
> This time it stop at "rfkill: input handler disabled"

s/stop/stopped 
Comment 8 Takashi Iwai 2020-04-27 17:26:05 UTC
Supposing it's a kernel regression, can you rollback and check whether the old kernel works?
Comment 9 Hillwood Yang 2020-04-28 13:01:18 UTC
(In reply to Takashi Iwai from comment #8)
> Supposing it's a kernel regression, can you rollback and check whether the
> old kernel works?

I don't think this is a kernel bug, because it works fine after just updating kernel to 5.6.4.
And also the system can work after rollbacking to the version before 20200417.
Comment 10 Hillwood Yang 2020-05-04 08:00:03 UTC
(In reply to Takashi Iwai from comment #8)
> Supposing it's a kernel regression, can you rollback and check whether the
> old kernel works?

Confirm this is a LUKS issue. After I format the home partition without LUKS, the system works fine.
Comment 11 Takashi Iwai 2020-05-04 08:25:46 UTC
Then it might be the plymouth problem that was recently mentioned on opensuse-factory ML.
Comment 12 Hillwood Yang 2020-05-04 13:34:34 UTC
(In reply to Takashi Iwai from comment #11)
> Then it might be the plymouth problem that was recently mentioned on
> opensuse-factory ML.

You are right. Removing plymouth can workaround this issue.
Comment 13 Takashi Iwai 2020-05-04 16:26:09 UTC
OK, reassigned to plymouth package maintainer.