Anyone read python :P
https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/plugins/system_upgrade.py
lines 567 through 578 suggest that there is some kind of state saving,
and allow erasing is one of them; so maybe the bug is that it's not
actually saving state, and isn't
Does anyone know if --allow-erasing needs to be passed to both
'download' and 'reboot' subcommands for this to work correctly?
Or does the download subcommand track options and apply them in the
rebooted offline/upgrade environment?
---
Chris Murphy
No missing expected images.
Failed openQA tests: 5/153 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-31-20191001.n.0):
ID: 462758 Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/462758
ID: 462828 Test: x86_64
OLD: Fedora-31-20191001.n.0
NEW: Fedora-31-20191003.n.1
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 35
Dropped packages:2
Upgraded packages: 98
Downgraded packages: 0
Size of added packages: 59.73 MiB
Size of dropped packages:327.71 KiB
> Yes, thanks.
>
> As the pkgs are pretty fundamental I prefer to keep them. I had bad
> eyperiences in the past with this approach. Before I go through dependency
> hell, I'd rather quickly reinstall the whole box.
> And as it is just a system-upgrade test for me, it can wait.
It still needs
Announcing the creation of a new nightly release validation test event
for Fedora 31 Branched 20191003.n.1. 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
Yes, thanks.
As the pkgs are pretty fundamental I prefer to keep them. I had bad eyperiences
in the past with this approach. Before I go through dependency hell, I'd rather
quickly reinstall the whole box.
And as it is just a system-upgrade test for me, it can wait.
Original-Nachricht
Rodger Etz composed on 2019-10-03 20:15 (UTC):
> Tried that, but it leads to dependency probs that cannot be solved by
> --allowerasing or --skip-broken.
Another thing I do when such problems arise is remove the offending packages,
upgrade, then add them back afterward. Typically this means dnf
Tried that, but it leads to dependency probs that cannot be solved by
--allowerasing or --skip-broken.
‐‐‐ Original Message ‐‐‐
On Thursday, 3. October 2019 21:45, Felix Miata wrote:
> Rodger Etz composed on 2019-10-03 19:11 (UTC):
>
> > So it seems Alan and myself have got some rare
Rodger Etz composed on 2019-10-03 19:11 (UTC):
> So it seems Alan and myself have got some rare dependency condition.
> Still need to find out what exactly triggers it and how to solve it.
> Will open a bug tomorrow, if nobody beats me to it.
Likely you can work around the problem via exclude=
In system-upgrade.pv there is a note in the run_upgrade function:
# NOTE: We *assume* that depsolving here will yield the same
# transaction as it did during the download, but we aren't doing
# anything to *ensure* that; if the metadata changed, or if depsolving
# is non-deterministic in some
On Wed, 2019-10-02 at 19:13 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 6:14 PM Samuel Sieb wrote:
> > On 10/2/19 5:03 PM, Chris Murphy wrote:
> > > On Wed, Oct 2, 2019 at 3:32 PM Alan wrote:
> > > > This is interesting... I am going to do a heavy clean of the
> > > > packages
> > > >
On Wed, 2019-10-02 at 18:03 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 3:32 PM Alan wrote:
> > This is interesting... I am going to do a heavy clean of the
> > packages
> > and try again.
> >
> > Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary
> > Oct 02 11:22:23 daimajin
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.
This is what I have found so far.
dnf system-upgrade -v reboot fails with the following errors:
2019-10-03T11:28:47Z INFO Downloading
On Wed, 2019-10-02 at 14:34 -0700, Samuel Sieb wrote:
> On 10/2/19 2:31 PM, Alan wrote:
> > Oct 02 11:23:19 daimajin dnf[1390]: Error opening file for
> > checksum:
> > /var/lib/dnf/system-upgrade/fedora-
> > 3589ee8a7ee1691d/packages/plasma-
> > desktop-5.16.4-1.fc31.x86_64.rpm
> > Oct 02
Following this test case
https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot
on KVM. I set up a static ip in the kernel arguments.
It boot, it reach the configuration page.
Here network doesn't work. The ip address is not in place (ip address
from command line).
So I go to the network
Yeah, I think this criteria fully and plausibly describes the requirement.
+1
Dne út 1. říj 2019 14:54 uživatel Kamil Paral napsal:
> On Mon, Sep 30, 2019 at 9:19 PM Ben Cotton wrote:
>
>> As we discussed in today's blocker review meeting[1], I am presenting
>> a draft proposal for the toggle
I am having the same issue but with different rpms. Cleaned the cache and
downloaded everything again several times but always identical issue.
Will post log entries and further analysis later when I am back at my desk.
‐‐‐ Original Message ‐‐‐
On Thursday, 3. October 2019 04:59,
18 matches
Mail list logo
