On Wed, Mar 03, 2021 at 08:53:10PM -0600, Robert G. (Doc) Savage via test wrote:
> Not sure if anyone here can address this minor problem, but here goes.
> For more than a week The top-level Fedora development repository at
> //dl.fedoraproject.org/fedora-linux-development/34 and /rawhide haven't
>
On Wed, Mar 3, 2021 at 5:34 PM Matthew Miller wrote:
>
> On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
> > It works at the block level. A block is read, checksum calculated and
> > compared to the previously recorded checksum for the block. It doesn't
> > know what it's reading, no
Not sure if anyone here can address this minor problem, but here goes.
For more than a week The top-level Fedora development repository at
//dl.fedoraproject.org/fedora-linux-development/34 and /rawhide haven't
been deleting the previous datetime versions of isos and other large
files. Example:
$
On 3/3/21 4:34 PM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
It depends on how the scrubbing works. I would have expected it to
be reading data at the filesystem level, not actually opening and
reading every file. That seems like a really bad thing to m
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote:
> It depends on how the scrubbing works. I would have expected it to
> be reading data at the filesystem level, not actually opening and
> reading every file. That seems like a really bad thing to me,
> resetting the atimes on every fil
On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote:
> It works at the block level. A block is read, checksum calculated and
> compared to the previously recorded checksum for the block. It doesn't
> know what it's reading, not even whether it's compressed or not. It
> just becomes a strea
On Wed, Mar 3, 2021 at 1:14 PM Samuel Sieb wrote:
>
> On 3/3/21 10:05 AM, Matthew Miller wrote:
> > On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
> >> From what I can tell scrubbing only reads data and compares to the stored
> >> checksum. Why would that wear out a SSD?
> >
> > If
On Wed, Mar 3, 2021 at 10:34 AM George R Goffe wrote:
>
> Chris,
>
> Here's the information you requested.
>
> I'm wondering just how this happened. One of the messages refers to "beyond
> end of device". I'm alarmed.
Don't panic.
But do keep your backups fresh, while you have the chance.
What
On Wed, 2021-03-03 at 07:23 +, Patrick Lang wrote:
> Hi All,
Hello Patrick. Welcome
I just sponsored you in the QA team.
This list will get updates on different testing related activities.
Subscribing the test-announce mailing list [0] could be useful as well.
You can start to test updates
On 3/3/21 10:05 AM, Matthew Miller wrote:
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
From what I can tell scrubbing only reads data and compares to the stored
checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. Bu
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote:
> From what I can tell scrubbing only reads data and compares to the stored
> checksum. Why would that wear out a SSD?
If you have atimes enabled, reading a file also makes a metadata write. But
I don't think it's that big a deal on mod
On Tue, Feb 23, 2021 at 3:26 PM pmkel...@frontier.com
wrote:
> I recall a long and detailed discussion on this list before F33 was
> released concerning what disk maintenance would be required with BTRFS.
> As I recall, the final word was along the lines the running Scrub and
> the other BTRFS ut
Chris,
Here's the information you requested.
I'm wondering just how this happened. One of the messages refers to "beyond end
of device". I'm alarmed.
Regards,
George...
[ 2017.474378] BTRFS info (device sda8): scrub: started on devid 1
[ 2101.646773] BTRFS warning (device sda8): checksum erro
No missing expected images.
Failed openQA tests: 1/16 (x86_64), 2/15 (aarch64)
Old failures (same test failed in Fedora-IoT-34-20210227.0):
ID: 798176 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/798176
ID: 798185 Test: aarch64 IoT-dvd
No missing expected images.
Failed openQA tests: 24/126 (aarch64), 17/187 (x86_64)
New failures (same test not failed in Fedora-34-20210302.n.1):
ID: 797974 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/797974
ID: 797981 Test: aarch64 Serv
OLD: Fedora-34-20210302.n.1
NEW: Fedora-34-20210303.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 1/16 (x86_64), 4/15 (aarch64)
Old failures (same test failed in Fedora-IoT-35-20210301.0):
ID: 797599 Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/797599
ID: 7976
No missing expected images.
Soft failed openQA tests: 1/7 (x86_64), 1/7 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-32-20210302.0):
ID: 797477 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
No missing expected images.
Compose FAILS proposed Rawhide gating check!
2 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 14/187 (x86_64), 14/126 (aarch64)
New failures (same test not failed in Fedora-Rawhide-20
I am not sure by 100%, but your problems can be connected with this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1931070.
But if so, you can try this:
- install Fedora Workstation (with Gnome)
- if it has installed successfully, install the KDE Plasma Group
- install the KDE Plasma us
20 matches
Mail list logo
