Wow, yes, I did not see this. The dnf version mismatch is a biggie, I totally
agree.
Original-Nachricht
An 9. Okt. 2019, 00:53, Adam Williamson schrieb:
> On Tue, [2019-10-08](tel:20191008) at 12:08 +, Rodger Etz wrote:
>> Marek looked at it and confirmed my analysis. He al
On Tue, 2019-10-08 at 12:08 +, Rodger Etz wrote:
> Marek looked at it and confirmed my analysis. He also stated the
> issue will be solved.
I'm not sure either of you figured it out entirely, I'm digging into it
more ATM. But...
> So IMHO there is no point discussing dep issues of certain pac
Marek looked at it and confirmed my analysis. He also stated the issue will be
solved.
So IMHO there is no point discussing dep issues of certain packages, because
the issue is simply that options from download are not carried over to reboot.
If this is tixed, all will be fine.
If it is not fi
1758588 has been opened by me 4th Oct as mentioned earlier. Bug is still in New
state!?
Original-Nachricht
An 7. Okt. 2019, 23:53, Chris Murphy schrieb:
> On Mon, Oct 7, [2019](tel:2019) at 4:43 PM wrote:
>>
>>
>>
>> > On 10/7/19 12:33 PM, a...@clueserver.org wrote:
>> >> If y
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 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
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 p
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 t
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 lo
> 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
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 th
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 reboot
On Sat, Oct 5, 2019 at 7:37 AM 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 reboot
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 reboot and reboot reruns it
... or something similar.
Trying to f
I suggest trying --debugsolver with both the download and reboot
subcommands. 'man dnf system-upgrade' suggests --debugsolver should
work. I recommend taring the debugdata dir that will create, and
setting the filename and attachment description so it's clear whether
the tarball is for reboot or do
On Fri, 2019-10-04 at 00:31 -0700, Samuel Sieb wrote:
> On 10/3/19 11:30 PM, Rodger Etz wrote:
> > Yes, basically, saving the state is not implemented yet for --reboot and
> > would fix it.
> >
> > And it should be fixed, I agree. Although the conditon seems very rare
> > and existing for quite
Filed against dnf as suggested: 1758588
‐‐‐ Original Message ‐‐‐
On Friday, 4. October 2019 09:31, Samuel Sieb wrote:
> On 10/3/19 11:30 PM, Rodger Etz wrote:
>
> > Yes, basically, saving the state is not implemented yet for --reboot and
> > would fix it.
> > And it should be fixed, I
On 10/3/19 11:30 PM, Rodger Etz wrote:
Yes, basically, saving the state is not implemented yet for --reboot and
would fix it.
And it should be fixed, I agree. Although the conditon seems very rare
and existing for quite some time, system-upgrade should behave in a
deterministic way.
You sho
On 10/3/19 7:08 PM, Chris Murphy wrote:
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?
The options must get
Yes, basically, saving the state is not implemented yet for --reboot and would
fix it.
And it should be fixed, I agree. Although the conditon seems very rare and
existing for quite some time, system-upgrade should behave in a deterministic
way.
Original-Nachricht
An 4. Okt. 2
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 act
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
___
> 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 to
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 de
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= i
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 way,
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
> > > > and
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 dnf[139
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 Packages
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 11:23:19
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, Samuel
On 10/2/19 6:13 PM, Chris Murphy wrote:
"Error opening file for checksum" taken literally, to me, means the
file is there but fails RPM checksum. Similar to the above question I
wonder if '--rpmverbosity debug' can be passed to dnf for the reboot.
But if so, it should reveal if this really is an
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
> >> and try again.
> >>
> >> Oct 02 11:22:23 daimajin dnf[1390]: Transactio
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
and try again.
Oct 02 11:22:23 daimajin dnf[1390]: Transaction Summary
Oct 02 11:22:23 daimajin dnf[1390]:
=
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 dnf[1390]:
>
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 11:23:19 daimajin dnf[1390]: Package "plasma-desktop-5.16.4-
1.fc31.x86_64" from reposi
On Wed, 2019-10-02 at 15:23 -0600, Chris Murphy wrote:
> On Wed, Oct 2, 2019 at 3:02 PM Alan wrote:
> > I have a laptop (Lenovo W540) running Fedora 30. I have preped it
> > for
> > upgrade using dnf.
> >
> > I get to the reboot step is where it gets interesting.
> >
> > I reboot and enter the d
On 10/2/19 2:01 PM, Alan wrote:
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for
upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says
it is preparing and then before it installs anyth
On Wed, Oct 2, 2019 at 3:02 PM Alan wrote:
>
> I have a laptop (Lenovo W540) running Fedora 30. I have preped it for
> upgrade using dnf.
>
> I get to the reboot step is where it gets interesting.
>
> I reboot and enter the drive password. It goes into the install, says
> it is preparing and then
I have a laptop (Lenovo W540) running Fedora 30. I have preped it for
upgrade using dnf.
I get to the reboot step is where it gets interesting.
I reboot and enter the drive password. It goes into the install, says
it is preparing and then before it installs anything, it reboots.
Any idea what lo
On Tue, 2019-09-17 at 11:30 -0400, pmkel...@frontier.com wrote:
> Was the 0916 drop of F31 the one that became Beta 1.1? I am curious
> because I have been in the process of testing the 0916 drop. So far I
> haven't found any new problems, but RHBZ #1694782 still applies.
The candidate composes
Was the 0916 drop of F31 the one that became Beta 1.1? I am curious
because I have been in the process of testing the 0916 drop. So far I
haven't found any new problems, but RHBZ #1694782 still applies.
Have a Great Day!
Pat (tablepc)
__
44 matches
Mail list logo
