4:26 a.m.
I tried to upgrade from F30 to F32 without doing updates first, and I got:
gnome-software[2045]: not handling error download-failed for action
refine: failed to refine distro upgrade: Failed to download gpg key for
repo 'fedora': Curl error (37): Couldn't read a file:// file for
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64 [Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64]
And I am thinking... well, if we could have gnome-software (maybe even
dnf) to update fedora-gpg-keys.noarch before trying to upgrade to the
next version, it would make it more likely to succeed.
6:01 a.m.
New subject: Could gnome-software update fedora-gpg-keys before upgrading to
next version?
On Thu, Apr 2, 2020 at 11:27 AM Paul Dufresne via devel <
devel(a)lists.fedoraproject.org> wrote:
I tried to upgrade from F30 to F32 without doing updates first, and I
got:
gnome-software[2045]: not handling error download-failed for action
refine: failed to refine distro upgrade: Failed to download gpg key for
repo 'fedora': Curl error (37): Couldn't read a file:// file for
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64 [Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64]
And I am thinking... well, if we could have gnome-software (maybe even
dnf) to update fedora-gpg-keys.noarch before trying to upgrade to the
next version, it would make it more likely to succeed.
This is not just about gpg keys, there are many packages which are
necessary to update first. Their list is dynamic, even during release
lifecycle. That's why dnf recommends people to first perform a system
update, and only then do a system upgrade. We failed to convince
gnome-software maintainer to do the same:
https://bugzilla.redhat.com/show_bug.cgi?id=1336435
9:08 a.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
Le 20-04-02 à 07 h 01, Kamil Paral a écrit :
We failed to convince gnome-software maintainer to do the same:
https://bugzilla.redhat.com/show_bug.cgi?id=1336435
Well, actually I am more on the opposite side of you on this.
I am more like not wanting to updates so many packages for current
version, knowing that they will be overridden in the upgrade to the next
version.
Actually, thinking a bit more about this, I guess distributing the keys
in a package might be wrong in the first place. I have rudimentary
knowledge of symmetrical encryption, but isn't it more like the
following for gpg for emails?:
Oh I need a key! Do I have it already? Yes... fine. No... download it
from the public repository. Is the new key signed with the a key I have?
If yes, add it to my list of keys. Else, probably should reject or ask
someone who knows better... the user of the computer maybe.
Well... there is the problem of the initial key... maybe if I have no
keys at all, I should accept the public key without asking.
12:30 p.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
On 4/2/20 7:08 AM, Paul Dufresne via devel wrote:
Le 20-04-02 à 07 h 01, Kamil Paral a écrit :
> We failed to convince gnome-software maintainer to do the same:
> https://bugzilla.redhat.com/show_bug.cgi?id=1336435
Well, actually I am more on the opposite side of you on this.
I am more like not wanting to updates so many packages for current
version, knowing that they will be overridden in the upgrade to the next
version.
The problem is that in the past there have been some packages that have
had to be updated first to successfully do the upgrade. As Kamil said,
the list can change at any time. The easiest way to ensure the upgrade
works is to make sure that your current version is up to date before
trying to upgrade to the new one. If you choose not to do that, then
you get to deal with any problems that result.
8:09 a.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
On Fri, 3 Apr 2020 at 07:48, Samuel Sieb <samuel(a)sieb.net> wrote:
The problem is that in the past there have been some packages that
have
had to be updated first to successfully do the upgrade.
So we list them with versions and do a deterministic check. Being told
over and over and again "you need to make sure everything is up to
date before upgrading" just isn't specific enough. e.g.
* Do flatpaks have to be up to date? What about firmware updates? Modules?
* Do we have to be running the latest kernel or just have it installed?
* Do packages in all repos have to be up to date, or just fedora-updates?
* If fedora-updates is explicitly disabled (e.g. updates come from a
corp repo), do we enable the Fedora one before upgrading?
* If the user has fedora-updates-testing enabled, does that have to
be up to date too? And rawhide?
* What if there are version locked packages in dnf.conf? Does that
prevent an upgrade?
* What if the user doesn't have new metadata, or new enough for some
repos that are only available on VPN for example?
Asking the user to download 2Gb of updates so that they can download
2Gb of upgrades is just bad. If we need a "fixed" rpm of a specific
version, we need to check for that version or newer. If we need to
check that a specific package is not installed, then we check that
package isn't installed.
/me the gnome-software maintainer, that actually cares that a
recommendation is actually possible to encode into code.
Richard.
11:40 a.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
On 4/3/20 6:09 AM, Richard Hughes wrote:
On Fri, 3 Apr 2020 at 07:48, Samuel Sieb <samuel(a)sieb.net>
wrote:
> The problem is that in the past there have been some packages that have
> had to be updated first to successfully do the upgrade.
So we list them with versions and do a deterministic check. Being told
over and over and again "you need to make sure everything is up to
date before upgrading" just isn't specific enough. e.g.
[...snip...]
Asking the user to download 2Gb of updates so that they can download
2Gb of upgrades is just bad. If we need a "fixed" rpm of a specific
version, we need to check for that version or newer. If we need to
check that a specific package is not installed, then we check that
package isn't installed.
/me the gnome-software maintainer, that actually cares that a
recommendation is actually possible to encode into code.
I understand that, but it's a very difficult problem. QA can't test
every possible random combination of updates, so only a fully up-to-date
system is tested for upgrades. Personally, I make sure dnf, systemd,
repos, and release are updated before doing an upgrade. That's worked
for me so far, but I'm capable of fixing things if something goes wrong.
Although now that offline upgrades are the default, it's a lot safer.
4:20 p.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
On Fri, Apr 3, 2020 at 10:41 AM Samuel Sieb <samuel(a)sieb.net> wrote:
On 4/3/20 6:09 AM, Richard Hughes wrote:
> On Fri, 3 Apr 2020 at 07:48, Samuel Sieb <samuel(a)sieb.net> wrote:
>> The problem is that in the past there have been some packages that have
>> had to be updated first to successfully do the upgrade.
>
> So we list them with versions and do a deterministic check. Being told
> over and over and again "you need to make sure everything is up to
> date before upgrading" just isn't specific enough. e.g.
[...snip...]
> Asking the user to download 2Gb of updates so that they can download
> 2Gb of upgrades is just bad. If we need a "fixed" rpm of a specific
> version, we need to check for that version or newer. If we need to
> check that a specific package is not installed, then we check that
> package isn't installed.
>
> /me the gnome-software maintainer, that actually cares that a
> recommendation is actually possible to encode into code.
I understand that, but it's a very difficult problem. QA can't test
every possible random combination of updates, so only a fully up-to-date
system is tested for upgrades. Personally, I make sure dnf, systemd,
repos, and release are updated before doing an upgrade. That's worked
for me so far, but I'm capable of fixing things if something goes wrong.
Although now that offline upgrades are the default, it's a lot safer.
This is one of those cases where everyone is correct.
Since offline update/upgrade mostly depends on the initramfs, I wonder
if that could become exclusive so that upgrades entirely (and only)
depend on the contents of the initramfs?
a. Compose already creates a no-host-only initramfs, found on all install media.
b. Clean installs create a no-host-only "rescue" initramfs, generated
locally. This isn't the same as (a).
e.g. Fedora 31 Workstation; ISO vs clean install, respectively
-rw-r--r--. 2 root root 57536044 Oct 23 17:21 initrd.img
-rw-------. 1 root root 83402982 Mar 17 22:31
initramfs-0-rescue-2d2b0efcba8442caaf742548b8b2e6ef.img
c. The compose built initramfs happens many times per day, and openQA
is testing all instances of it because that's the initramfs being used
for booting the ISO.
d. The locally generated rescue initramfs is not used or tested,
except by manual intervention by the user.
e. The locally generated rescue initramfs is not replaced on upgrades.
It becomes stale.
f. There's "Vague proposal: ship prebuilt initramfs images" time
inspecific.
But I wonder if we can fix all of these issues in one whack, and what
we'd actually test and require as the prerequisite for upgrade is a
particular kernel+initramfs combo. This would include dnf, PackageKit,
rpm, systemd of the proper tested versions as a single testable
"bundle".
Gotcha is, the kernel+initramfs continues to get bumped on Fedora n-1
and n-2, for weeks after release and those aren't tested. But we
already have that problem, and more, as those releases continue to
drift from what was tested in the last weeks of the release process.
So I still think a prebuilt initramfs would be a less fragile
approach, that also doesn't require the obvious downloading waste.
--
Chris Murphy
5 p.m.
New subject: Change the way to acquire the keys for package upgrades [changed]
Le 20-04-02 à 13 h 30, Samuel Sieb a écrit :
The problem is that in the past there have been some packages that
have had to be updated first to successfully do the upgrade. As Kamil
said, the list can change at any time. The easiest way to ensure the
upgrade works is to make sure that your current version is up to date
before trying to upgrade to the new one. If you choose not to do
that, then you get to deal with any problems that result.
I have tried to upgrade F31 (freshly installed, not updated) to F32
without problem.
I have tried to upgrade F32 (freshly installed, only upgraded
fedora-gpg-keys), and it work.
So refusing to fix a problem that we can only fix now before release,
for people who do not update (I think it would be better for them to
update, but I do care to help them anyway), that is upgrading from F32
to (F34 or F35) will not work, because we think there is a possibility
that it won't work is strange to me.
Note that there is a different way than changing gnome-software to fix
this future problem... that would be to include now the keys for F34
(maybe F35 too).
1485
days inactive
1486
days old
7 comments
5 participants
participants (5)
-
Chris Murphy -
Kamil Paral -
Paul Dufresne -
Richard Hughes -
Samuel Sieb