Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #69133 > unrolled thread

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs Nicholas D Steeves <nsteeves@gmail.com> - 2021-01-13 04:00 +0100
    Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> - 2021-01-13 05:30 +0100
      Processed: Re: Bug#977647: 5.10.1 Debian kernel does not boot on  amd64 with btrfs rootfs "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-01-13 05:30 +0100

#69133 — Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

[Multipart message — attachments visible in raw view] — view raw

Hi,

Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp> writes:

> Hi Nicholas,
> Thank you very much for your attention!
>

You're welcome :-)

[snip]
> Boot failures themselves are unreliable...
>

This is the key to the most important issue.  To solve this bug, we will
need to figure out the steps to reproduce it, and it's not clear what
needs to be fixed (or how to fix it!) if no one can reproduce it.

>> If that's not possible,
>> see if you can get a copy from /var/log after rebooting with a working
>> kernel or when using a network disk.
>
> /var/log/kern.log does not have information of 5.10.1...
>
>> If that's not possible, and you
>> have good reflexes, you could try ctr+s or scroll-lock to pause the
>> kernel output at just the right moment,
>
> I found that once in ten times, booting succeeds and I got dmesg and /proc/mounts
> of 5.10.1 as attached...
>

Thank you.  The backtrace is from a crashing tpm driver, and not btrfs.
If you want to eliminate this as a possible factor, the tpm, tpm_tis,
and tpm_tis_core drivers can be blacklisted.

It's encouraging to hear that it fails 10% of the time, because that
means you'll be able to reproduce it without much trouble ;-) Please
finish reading this email, then enable network logging using the
document linked to in my previous email, because it sounds like your
system is probably hard locking before the logs are written to disk,
which means sending them to another computer is the most reliable way to
capture them.  For your convenience, here is the link again:
  https://wiki.debian.org/Rsyslog

>> Finally, what btrfs features (profiles, compression, layers of storage,
>> etc) are being used?
>
> Please have a look at attached file. Less usual one is compress-force=lzo.
> If I remember it correctly, all files are lzo-compressed.
>

P.S. I believe that btrfs compression is not yet ready for general use.
There's still at least one major bug per year that only occurs when it
is enabled.  If I remember correctly, Zygo on the linux-btrfs mailing
list is tracking its state, and he periodically posts "year in review"
and "current outstanding issues" reports.

At this point my two hypotheses are:

1. It's hardware specific, and the TPM crash is more significant than it
appears to be.
2. It may be that your btrfs volume has errors which 5.10 detects and
halts for, but which 5.9 is not aware of.  If you'd like to explore this
possibility, run "btrfs check" against the unmounted volume.  If it
finds errors *DO NOT* run "btrfs check --repair"; instead, send a copy
of the output to linux-btrfs asking for advice about what to do next,
and request to be CCed on replies.
3. Something else.

There's not really any substitute for logs, so I wish you success in
configuring network logging :-)

Regards,
Nicholas

[toc] | [next] | [standalone]

#69135

Control: tags -1 + moreinfo

Hi Nicholas, thanks again for your response.

In my new year holidays, I built the upstream (not Debian)
5.10.6 kernel and saw what happend. The situation got better,
* booting always succeeded (at least I did not observe it)
* tpm error persisted
* I did "systemctl poweroff" immediately after I got "login:".
  The shutdown behavior was very strange, many systemd services cannot be
  stopped cleanly and timeouts occurred many times. I cut the power line
  after waiting 5 minutes or so.

I'd like to see the situation again after the upstream version gets 5.10.10 or
so, because, for I now have very little (or no) trust on the upstream (not Debian)
kernel as

* arm64 kernel does not boot at all on raspberry pi 4B on USB MSD
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977694
* arm64 kernel did not boot on raspberry pi 4B on SD card,
  (all usual booting devices did not work). It seems fixed in upstream 5.10.6
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645
* wireless network does not work on raspberry pi 4B
  (this has not been reported as booting on my raspi has not been confirmed
  on any Debian kernel).

Simply, I am tired of seeing if 5.10.? kernel works normally or not on my machines.
I have seen little problem in Debian 5.9.* series.
Since 5.10 is LTS, maybe 5.10.10 or 5.10.20 will gets as good as 5.9.15.
I will stick to Debian 5.9.15 kernel on my amd64 notebook and raspi4b
for a while...

Best regards, Ryutaroh Matsumoto

[toc] | [prev] | [next] | [standalone]

#69136 — Processed: Re: Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

Processing control commands:

> tags -1 + moreinfo
Bug #977647 [linux-image-5.10.0-1-amd64] 5.10.4 Debian kernel does not boot on amd64 with btrfs rootfs
Added tag(s) moreinfo.

-- 
977647: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977647
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web