On Thu, Mar 26, 2020 at 07:38:33AM -0400, Neal Gompa wrote:
On Thu, Mar 26, 2020 at 7:33 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> On Thu, Mar 26, 2020 at 01:16:22PM +0200, Panu Matilainen wrote:
> > On 3/26/20 1:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
> > >On Mon, Mar 16, 2020 at 11:22:47AM -0400, Ben Cotton wrote:
> > >>=== Upgrading ===
> > >>* Ability to upgrade is not affected
> > >>* After upgrade completes, manual action (rpmdb --rebuilddb) will
> > >>probably be needed to convert to sqlite. Alternatively user can change
> > >>configuration to stay on BDB.
> > >
> > >Do I understand correctly:
> > >- without the manual step, users will remain on the old format
> > >- with the old format, in F33 everything will still work fine, but
> > > after upgrade to F34, the database will become read-only
> > >
> > >Why is an automatic 'rpmdb --rebuilddb' not part of upgrade plan?
> >
> > To repeat what I said in
https://pagure.io/fesco/issue/2360:
>
> Hi,
>
> thanks for quick answer and sorry for double-posting. I started
> reading the fesco ticket, then the change page, then the discussion
> here, and forgot to read the rest of the comment on the ticket.
> I also posted there, but I think it's better to discuss here.
> I'll copy my post from there here, sorry for the mess.
>
> > I left it open on purpose (note the "probably" in there) as there
> > would be any number of ways to achieve the rebuild with varying
> > degrees of automation and opt-out opportunities, depending on what
> > is actually desireable for Fedora.
> >
> > One possibility could be adding a rebuild step to dnf system-upgrade
> > plugin, rebuilding the db after distro upgrades is not a bad idea
> > regardless of db format changes (at least BDB performance would
> > gradually degrade unless rebuilt every now and then). That would
> > leave people doing the (unspeakable) distro-sync upgrade to deal
> > with database format manually, which might be just the right balance
> > of freedom. Or not, I dunno. Other possibilities include planting a
> > one-shot service that does the db rebuild on the next reboot and
> > decommissions itself afterwards in the rpm package itself. Other
> > variations certainly exist.
> >
> > Suggestions welcome, just as long as you don't suggest rebuilding
> > from rpm %posttrans :)
>
> Right. I realize %posttrans is not a good idea. But *some* mechanism
> is necessary, because without that the change will mostly be a noop
> for most users. So I think this needs to be decided somehow.
>
> Quoting from the FESCo ticket:
> About the various implementation options:
>
> - in dnf system-upgrade: this does not cover normal 'dnf
> --releasever=33 upgrade' upgrades (as you mentioned earlier), but it
> also does not cover packagekit upgrades. It'd also create a
> previous-release-blocker(s) and previous-previous-release-blockers(s),
> since the changes would need to be deployed in F32 and F31. Also
> note that the last time when the upgrade plugins run code is in
> upgrade phase between two reboots, and the plugin is running
> pre-upgrade code. This code would then invoke post-upgrade rpm. It's
> certainly doable, but seems a bit funky.
>
It could be a libdnf post-transaction plugin. That would apply to any
mechanism of system upgrade using libdnf, either through dnf or
PackageKit.
That sounds interesting...
> - a one-shot service: this is easier to implement, it just needs
to
> happen in one place. The hard part is making sure that the machine
> does not get reboot while the upgrade is happening. This is in
> particular a problem with VMs and containers. The rebuild should be
> wrapped with systemd-inhibit and other guards to make it hard to
> interrupt.
Wouldn't the systemd-inhibit plugin automatically ensure that a
rebuild action would block sleep/poweroff?
Unfortunately... not. From the man page: inhibitors "may be used to
block or delay system sleep and shutdown requests from the user, as
well as automatic idle handling of the OS."
Explicit non-interactive privileged requests override inhibitors [1,2].
This has been discussed, and I think there's general sentiment that we
should have an ability to inhibit "everything", but so far nobody has
pushed for a solution. A solution could be proritized if it turns out
to be required in Fedora.
[1]
https://github.com/systemd/systemd/issues/2680
[2]
https://github.com/systemd/systemd/issues/6644
> No matter how it wrapped, is the upgrade itself atomic? Having
the new
> db built under a temporary file name and then atomically rename(2)d
> into place would be ideal.
>
Since RPM 4.14, RPM creates a new directory, writes the database
content there, then renames the directory when it's done.
Does it use renameat2(RENAME_EXCHANGE)?
Zbyszek