-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/2020 20.16, Alex Christoph Bihlmaier wrote: | Am 09.02.20 um 19:45 schrieb Knurpht-openSUSE: |>> status of /: 223 GB size of / 88 MB used 100% usage. |>> |>> what's wrong here? A Leap install is working flawlessly with |>> the exact same partitioning. |>> |>> thal |> |> df and du cannot deal properly with btrfs. As, apparently, he was installing a new system, the partition should be formatted during the procedure and thus empty, but lets verify that by asking ;-) |> |> Show btrfs fi usage / | | i added btrfs fi usage output on: | https://kallisti.at/tmp/tw_install/ | | additionaly: when running "btrfs balance start /mnt" then /mnt has | plenty of space again. | | Seems like the installer is messing up things... Is the partition new, or was it in use previously? Meaning, did the install format the disk? - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXkBcHgAKCRC1MxgcbY1H 1RfXAJ9qpzOztIV+xZGClWCZcUclVxUERQCgg8Dj3XDiOEaS1zxL6trm223k/rM= =lhp8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 09.02.20 um 21:22 schrieb Alex Christoph Bihlmaier:

Am 09.02.20 um 20:23 schrieb Carlos E. R.:

...

|> Show btrfs fi usage / | | i added btrfs fi usage output on: | https://kallisti.at/tmp/tw_install/ | | additionaly: when running "btrfs balance start /mnt" then /mnt has | plenty of space again. | | Seems like the installer is messing up things...

Is the partition new, or was it in use previously? Meaning, did the install format the disk?

Yes - i ticked "Format filesystem" for / (btrfs).

With current TW snapshot 20200207, the installation works like a charm. Thanks! thal

On 11. 02. 20, 9:54, Carlos E. R. wrote:

On 10/02/2020 22.52, Alex Christoph Bihlmaier wrote: | Am 09.02.20 um 21:22 schrieb Alex Christoph Bihlmaier: |> Am 09.02.20 um 20:23 schrieb Carlos E. R.: |>> |> Show btrfs fi usage / | | i added btrfs fi usage output on: |>> | https://kallisti.at/tmp/tw_install/ | | additionaly: when |>> running "btrfs balance start /mnt" then /mnt has | plenty of |>> space again. | | Seems like the installer is messing up |>> things... |>> |>> Is the partition new, or was it in use previously? Meaning, did |>> the install format the disk? |> |> Yes - i ticked "Format filesystem" for / (btrfs). | | With current TW snapshot 20200207, the installation works like a | charm. Thanks! | | thal

Please report your experience in a Bug report, as Simon Lees suggested

But please read the full thread before doing so. -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/2020 21.12, Jon Brightwell wrote: | Known bug in the kernel | | https://patchwork.kernel.org/patch/11293419/ | https://www.spinics.net/lists/linux-btrfs/msg96011.html | | Running a balance is the current workaround. On a system that is being installed, thus not complete? - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXkB3CwAKCRC1MxgcbY1H 1SrwAJ0Q/FKhKdjjLunQAxnKiJtjhx5KVQCfc42NRJ3Dl6v8LfOT1E5nZ+esFk0= =vU/F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 10. 02. 20, 4:59, Andrei Borzenkov wrote:

09.02.2020 21:34, Alex Christoph Bihlmaier пишет:

...

Hello. Current TW install with openSUSE-Tumbleweed-NET-x86_64-Snapshot20200205-Media.iso fails miserably on an UEFI system (Ryzen 2nd gen).

It fails due to full disk during installation after only ~10 installed packages.

screenshot: https://kallisti.at/tmp/tumbleweed%20install%20-%20failed.jpg

status of /: 223 GB size of / 88 MB used 100% usage.

what's wrong here?

kernel bug in 5.4 and 5.5. Fixed in 5.4.18 and 5.5.2.

If you mean commit d55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 Author: Josef Bacik Date: Fri Jan 31 09:31:05 2020 -0500 btrfs: do not zero f_bavail if we have available space that is part of our kernel since 5.5.1. See: https://bugzilla.suse.com/show_bug.cgi?id=1162471 So it apparently does not help. thanks, -- js suse labs

Am 10.02.20 um 14:51 schrieb Andrei Borzenkov:

On Mon, Feb 10, 2020 at 10:16 AM Jiri Slaby wrote:

...

On 10. 02. 20, 4:59, Andrei Borzenkov wrote:

...

09.02.2020 21:34, Alex Christoph Bihlmaier пишет:

...

Hello. Current TW install with openSUSE-Tumbleweed-NET-x86_64-Snapshot20200205-Media.iso fails miserably on an UEFI system (Ryzen 2nd gen).

...

...

kernel bug in 5.4 and 5.5. Fixed in 5.4.18 and 5.5.2.

If you mean commit d55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 Author: Josef Bacik Date: Fri Jan 31 09:31:05 2020 -0500

btrfs: do not zero f_bavail if we have available space

that is part of our kernel since 5.5.1.

See: https://bugzilla.suse.com/show_bug.cgi?id=1162471

So it apparently does not help.

AFAIU 5.5.1 is included first in 20200207 snapshot.

Correct. https://lists.opensuse.org/opensuse-factory/2020-02/msg00240.html | kernel-source (5.4.14 -> 5.5.1) so 20200205 had a broken kernel wrt. btrfs. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2/11/20 7:00 PM, Carlos E. R. wrote:

On 10/02/2020 16.07, Stefan Seyfried wrote: | Am 10.02.20 um 14:51 schrieb Andrei Borzenkov: |> On Mon, Feb 10, 2020 at 10:16 AM Jiri Slaby |> wrote: |>> |>> On 10. 02. 20, 4:59, Andrei Borzenkov wrote: |>>> 09.02.2020 21:34, Alex Christoph Bihlmaier пишет: |>>>> Hello. Current TW install with |>>>> openSUSE-Tumbleweed-NET-x86_64-Snapshot20200205-Media.iso |>>>> fails miserably on an UEFI system (Ryzen 2nd gen). | |>>> kernel bug in 5.4 and 5.5. Fixed in 5.4.18 and 5.5.2. |>> |>> If you mean commit d55966c4279bfc6a0cf0b32bf13f5df228a1eeb6 |>> Author: Josef Bacik Date: Fri Jan 31 |>> 09:31:05 2020 -0500 |>> |>> btrfs: do not zero f_bavail if we have available space |>> |>> that is part of our kernel since 5.5.1. |>> |>> See: https://bugzilla.suse.com/show_bug.cgi?id=1162471 |>> |>> So it apparently does not help. |>> |> |> AFAIU 5.5.1 is included first in 20200207 snapshot. | | Correct. | https://lists.opensuse.org/opensuse-factory/2020-02/msg00240.html | | | kernel-source (5.4.14 -> 5.5.1) | | so 20200205 had a broken kernel wrt. btrfs.

How did not the automated testing find this problem? An image that could not be installed?

Given its the second report in two weeks i'd guess the bug is only happening in certain cases what those cases are we should narrow down in a bug report. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 2/11/20 8:08 PM, Jiri Slaby wrote:

On 11. 02. 20, 9:43, Simon Lees wrote:

...

...

How did not the automated testing find this problem? An image that could not be installed?

It did not hit openQA with 5.4 kernel at all. It hit it once in 5.5. And not in the kernel Staging project, but after 5.5 was accepted to TW, in an unrelated staging. So it is quite rare issue. If you can hit it reproducibly, you can test snapshots >= 20200207 to see if it's gone.

...

Given its the second report in two weeks i'd guess the bug is only happening in certain cases what those cases are we should narrow down in a bug report.

But please read the full thread before creating another bug.

I was probably using a version just before that when I was hitting it, unfortunately it was setting up my main work laptop so I can't now easily test it again because the laptop is too set up to wipe it again now. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B