On Mon, Oct 7, 2019 at 4:43 PM wrote:
>
>
>
> > On 10/7/19 12:33 PM, a...@clueserver.org wrote:
> >> If you use --allowerasing, the upgrade transaction works, but since
> >> that
> >> flag does not get passed to the upgrade after the reboot, the process
> >> fails because it tries to upgrade
> On 10/7/19 12:33 PM, a...@clueserver.org wrote:
>> If you use --allowerasing, the upgrade transaction works, but since
>> that
>> flag does not get passed to the upgrade after the reboot, the process
>> fails because it tries to upgrade those packages and they were never
>> downloaded.
>
>
On Mon, Oct 7, 2019 at 3:38 PM Samuel Sieb wrote:
>
> On 10/7/19 12:33 PM, a...@clueserver.org wrote:
> > If you use --allowerasing, the upgrade transaction works, but since that
> > flag does not get passed to the upgrade after the reboot, the process
> > fails because it tries to upgrade those
On 10/7/19 12:33 PM, a...@clueserver.org wrote:
If you use --allowerasing, the upgrade transaction works, but since that
flag does not get passed to the upgrade after the reboot, the process
fails because it tries to upgrade those packages and they were never
downloaded.
That is certainly not
On Thu, Oct 3, 2019 at 11:08 AM Rodger Etz wrote:
>
> Bugzilla Bug 1644439 looks identical, but was not investigated further as it
> seems the issue did not appear anymore and dnf has changed since reported.
I suggest reopening that bug and providing your updated information:
call trace, any
> On 10/7/19 10:51 AM, Alan wrote:
>> On Sat, 2019-10-05 at 13:37 +, Rodger Etz wrote:
>>> Thanks, Chris! I did so, but reboot did not create a debugdata dir.
>>> Therefore I have uploaded the dnf logs.
>>>
>>> From what I have seen so far, it still seems the best option to
>>> modify
On 10/7/19 10:51 AM, Alan wrote:
On Sat, 2019-10-05 at 13:37 +, Rodger Etz wrote:
Thanks, Chris! I did so, but reboot did not create a debugdata dir.
Therefore I have uploaded the dnf logs.
From what I have seen so far, it still seems the best option to
modify system-upgrade so it safes
On Sat, 2019-10-05 at 13:37 +, Rodger Etz wrote:
> Thanks, Chris! I did so, but reboot did not create a debugdata dir.
> Therefore I have uploaded the dnf logs.
>
> From what I have seen so far, it still seems the best option to
> modify system-upgrade so it safes the transaction before
No missing expected images.
Failed openQA tests: 7/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191006.n.1):
ID: 464337 Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/464337
ID: 464341 Test: x86_64 Server-dvd-iso
OLD: Fedora-31-20191006.n.1
NEW: Fedora-31-20191007.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 6
Dropped packages:0
Upgraded packages: 44
Downgraded packages: 1
Size of added packages: 56.99 MiB
Size of dropped packages:0 B
Size
On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote:
> As we discussed in today's blocker review meeting[1], I am presenting
> a draft proposal for the toggle keys. I am proposing this as a *final*
> criterion, but would not object to adding it as a beta criterion.
>
> == Keyboard toggle keys ==
Announcing the creation of a new nightly release validation test event
for Fedora 31 Branched 20191007.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki
OLD: Fedora-Rawhide-20191006.n.1
NEW: Fedora-Rawhide-20191007.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 26
Downgraded packages: 1
Size of added packages: 0 B
Size of dropped packages:0 B
Size
No missing expected images.
Compose FAILS proposed Rawhide gating check!
1 of 45 required tests failed, 2 results missing
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
14 matches
Mail list logo
