rhinstaller / fedup Goto Github PK

Where possible (LVM, btrfs, etc.) we should offer to do a filesystem snapshot before the upgrade, and automatically revert to the upgrade if anything goes wrong during the upgrade itself.

Basically, when the system crashes, we should probably display an error message and tell the user how boned they are, and let them choose between a shell and rebooting.

More specifically - if the upgrade-prep service fails, we should:

• print a message about the failure
• log failure to /var/log/upgrade.log
• do the "root password for debugging or reboot" prompt
• reboot if no activity after ~60 sec

Pretty self-explainitory... With the addition of the --product switch for F21, it appears that fedup is blindly requiring it even in situations where it isn't needed/relevant.

[root@Fedora cbowles]# fedup --clean
usage: fedup <SOURCE> [options]
fedup: error:

This installation of Fedora does not belong to a product, so you
must provide the --product=PRODUCTNAME option to specify what product
you want to upgrade to. PRODUCTNAME should be one of:

 workstation: the default Fedora experience for laptops and desktops,
   powered by GNOME.
 server: the default Fedora experience for servers
 cloud: a base image for use on public and private clouds
 nonproduct: choose this if none of the above apply; in particular,
   choose this if you are using an alternate-desktop spin of Fedora

Selecting a product will also install its standard package-set in
addition to upgrading the packages already on your system. If you
prefer to maintain your current set of packages, select 'nonproduct'.

See https://fedoraproject.org/wiki/Upgrading for more information.

[root@Fedora cbowles]# fedup --clean --product=nonproduct
resetting bootloader config
removing boot images
removing downloaded packages
removing miscellaneous files

I've been thinking about how to protect against the F20 fedup 0.7/0.8 issue occurring again. Among other changes, one I thought of is this.

Could fedup, as the first thing it does before proceeding, check whether a newer version of itself is available in the stable updates repository, and recommend/require the user to update to that before proceeding?

This would at least prevent people running into this kind of issue once the 'correct' fedup reached stable.

Using gnome-terminal on Fedora 19, I was trying to update to Fedora 20, and got this message :

Traceback (most recent call last):
File "/bin/fedup", line 236, in
main(args)
File "/bin/fedup", line 159, in main
pkgs = download_packages(f)
File "/bin/fedup", line 65, in download_packages
updates = f.build_update_transaction(callback=output.DepsolveCallback(f))
File "/usr/lib/python2.7/site-packages/fedup/download.py", line 257, in build_update_transaction
(rv, msgs) = self.buildTransaction(unfinished_transactions_check=False)
File "/usr/lib/python2.7/site-packages/yum/init.py", line 1195, in buildTransaction
(rescode, restring) = self.resolveDeps()
File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 884, in resolveDeps
CheckDeps, checkinstalls, checkremoves, missing = self._resolveRequires(errors)
File "/usr/lib/python2.7/site-packages/yum/depsolve.py", line 986, in _resolveRequires
self.dsCallback.pkgAdded(txmbr.pkgtup, dscb_ts_state)
File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 113, in pkgAdded
self.progressbar.update(self.mode_counter['ud'])
File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 76, in update
self.tty.write("\r%s" % self)
File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 69, in str
return self.formatstr.format(self)
File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 61, in bar
barwidth = self.width - len(otherstuff.format(self)) - 2 # 2 brackets
File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 51, in width
return term.size.cols or 80 # fallback for stupid terminals
AttributeError: 'module' object has no attribute 'size'

instrepo doesn't seem to have the same failure/interrupt callbacks as normal yum, so it doesn't switch to a different mirror if the first mirror for instrepo fails.

(see e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1027573)

We need a --product flag that installs the right bits to get your F<=20 system to have a proper F=>21 product installed.

When users upgrade from an iso, we don't enable the network. Sure, you can do fedup --iso --network 20 but this confuses people. Plus It makes more sense for the default case to be "upgrade system including updates", but to allow the user to turn off updates (if needed).

That's closer to the anaconda behavior, and it's safer too.

To do this, we'll need some way of examining the .iso to determine its version, and then we can use that version in the implicit --network VERSION

If you have (e.g.) a NFS repo, its url will be file:///... and yum will consider those packages to be local, and thus we won't cache them in /var. So then when you try to upgrade, they're not there, and the upgrade fails.

We need to check whether local files are really local - i.e. located on media that's definitely going to be mounted when we reboot.

This ties into the mount stuff we need to do in issue #9.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=987106

Add a flag to make fedup download and install packages, even if they're older than what's already on the system.

• look into how yum does distro-sync
• figure out if we need to pass extra flags in system-upgrade-fedora.c

error: Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system-generators/system-upgrade-generator

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib/systemd/system-generators/system-upgrade-generator

How to reproduce:

$ make archive
$ rpmbuild -ta fedup-0.7.3.tar.xz

We need a way to tell fedup to install new (default) packages from existing, installed groups. Basically we'd reinstall each group that yum lists as installed. (see `yum.igroups for info about installed groups).

Also needed: an extra argument/option for whether to install 'mandatory' vs. 'default' packages in the group.

Hi,

I want to build my own instrepo for some custom cleanup work. I cloned your fedup-dracut repo, added my cleanup stuff in upgrade-cleanup.sh and generated rpms and installed on my Fedora 19. Then i generated a repo with updates.img and hosted it in a webserver.

Then i installed fedup in a F17 VM (sudo yum install fedup) and then tried to upgrade it to Fedora 19.

I encountered bunch of issues

1. Fedup's upgrade-prep.sh still looks for UPGRADEROOT variable from /run/initramfs/upgrade.conf (i monkey patched it, used the latest upgrade-prep.sh)
2. Then the upgrade hangs after running 'upgrade-prep.sh'

What version of fedup you would recommend for upgrading a F17 machine?

And what version fedup-dracut (code/rpm) i should use to generate the ramdisk/repo

Here is my boot log

http://paste.fedoraproject.org/55087/

Here is my grub.cfg

set timeout=5
serial --unit=0 --speed=9600
terminal --timeout=5 serial console

menuentry 'System Upgrade (fedup)' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-51e0c1c8-8c8c-4f4c-b9f3-b53a15a45413' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2' c46cf3c5-aa4d-4561-81ab-ccab8a2ef1f0
else
search --no-floppy --fs-uuid --set=root c46cf3c5-aa4d-4561-81ab-ccab8a2ef1f0
fi
echo 'Loading System Upgrade (fedup)'
linux /vmlinuz-fedup root=/dev/mapper/vg_root-lv_root ro rd.md=0 rd.dm=0 KEYTABLE=us SYSFONT=True rd.luks=0 rd.lvm.lv=vg_root/lv_root LANG=en_US.UTF-8 rhgb quiet upgrade systemd.unit=system-upgrade.ta
rget plymouth.splash=fedup rd.debug rd.shell systemd.log_level=debug console=tty0 console=ttyS0,9600 selinux=0
echo 'Loading initial ramdisk ...'
initrd /initramfs-fedup.img
}

People keep freaking out because they think their systems have hung and rebooting, thus totally hosing their systems.

We should put a shell on tty2 for the Power Users so they don't get all freaked out when selinux-policy-targeted takes a long time to install.

The message generated in upgrade.py for RPMPROB_REQUIRES looks kind of weird. For example:

WARNING: problems were encountered during transaction test:
broken dependencies
R python(abi) = 2.6 requires rhelup-0.7.3-0.el6.noarch

This might be dependent on the version of yum? I don't know. I don't know what that R is doing there either.

Another possible improvement in the wake of the F20 0.7/0.8 problem. It seems (though I don't think it's 100% proven yet) that fedup 0.7 would not work with an upgrade.img generated by fedup-dracut 0.8.

Would it be possible and desirable to implement some kind of cross-check between fedup and fedup-dracut, so fedup could bail and advise an update if it found it was too old for the upgrade.img on the mirror?

I'm leaving this vague and open-ended intentionally, as the details are very much dependent on what wwoods' expectations are of the deps between fedup and the initramfs. Just wanted to have a ticket recording the general idea.

There've been some significant changes to the way that fedup and fedup-dracut start the upgrade. Specifically we've switched to using a generator to start the upgrade rather than boot args, as per issue #24 - see commit 72d947a and b443c0d, and rhinstaller/fedup-dracut@b8cc454.

It seems like there might be problems using 0.8.0 fedup with older upgrade.img (see e.g. #35), but they should be compatible.

Need to investigate this and check whether it's actually a new problem or just some other problem manifesting, e.g.:

• https://bugzilla.redhat.com/896023 - hang with encrypted home
• https://bugzilla.redhat.com/958586 - hang when upgrading from F17

See: https://bugzilla.redhat.com/show_bug.cgi?id=984305

It appears that fedup (and/or fedup-dracut) may not be handling obsoletes properly. Need to:

• check fedup.log to see if fedup is downloading the right things
• check how RPM/yum handle removing obsoleted packages
• check upgrade.log to see if the obsoletes are getting handled as expected

How can we handle booting systems where upgrade.img is missing things like 3rd party dracut modules or kernel drivers?

Problem Background

fedup's current design uses a generic dracut-built upgrade.img to boot your system. We do this because we want to use the kernel / SELinux policy / etc. from the new release during the upgrade.

Dracut images are supposed to be generic enough to handle booting a system without needing any information other than what's in the boot arguments.

Unfortunately, there are a lot of cases where that doesn't work, and then systems don't boot because the generic initramfs is missing something. Most commonly were missing some of the host's config files. So commit c2cc421 added code to pull config files out of the host's current initramfs into upgrade.img, which fixes a lot of stuff. But... not everything.

The Actual Problem

RHBZ#1199517 is a real-world case where we're missing more than just a config file.

It's (apparently) possible to create a system that has its root on a bcache device. The bcache-tools package provides a dracut module that will set up the devices properly so you can find root. But the generic upgrade.img doesn't contain this module. So we can't find root, and thus can't start the upgrade. So the Big Questions are:

1. How can we identify what's needed to boot?
2. Once identified, how do we pull those things into our upgrade.img so that they'll actually work?

Some possible scenarios:

• Kernel modules: what if they require firmware?
• Dracut scripts: what if they require external binaries?
• Binaries: how do we get their libraries?
• Libraries: What if we need a modified version of an existing library/binary?

We should check to be sure that the packages listed in package.list all exist, and bail out if they don't.

This would help with e.g. https://bugzilla.redhat.com/show_bug.cgi?id=989263 where the packages are all missing because the user did weirdo mount junk.

There should be a way to specify the path to the GPG key for commandline-added repos.

When we're in text mode, the progress bar doesn't really show anything useful, and this can make it seem like the upgrade has hung or something. See e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1017201

We should automatically switch to the details view when in text mode.

There are some problems that have to be fixed before we reboot to start the upgrade; for example, replacing the KEYTABLE/KEYMAP boot argument with vconsole.keymap in Fedora 18.

fedup should supply a directory for such scripts to be run before reboot.

I'm using a fully updated F17 x86_64 install inside a VM - base GNOME install (defaults, no encrypted disks, LVM enabled) with git added to pull fedup from github.

After fedup-cli successfully completes and tells me to reboot, I reboot and attempt to boot 'System Upgrade' from the grub menu. When I do, I get the following error message before being dumped back to the grub menu:

Loading System Upgrade
error: file '/upgrade/vmlinuz' not found
Loading initial ramdisk ...
error: you need to load the kernel first.

Press any key to continue.

Looking at the grub entry made by fedup:

menuentry 'System Upgrade' --class fedora --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-19bf1c85-6b3c-4afb-be91-610460ca12f8' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  23c62b83-4245-46bf-9692-fe55cacc7e20
        else
          search --no-floppy --fs-uuid --set=root 23c62b83-4245-46bf-9692-fe55cacc7e20
        fi
        echo 'Loading System Upgrade'
        linux   /upgrade/vmlinuz root=/dev/mapper/vg_f17upgrade1-lv_root ro rd.lvm.lv=vg_f17upgrade1/lv_root rd.md=0 rd.dm=0 SYSFONT=True rd.lvm.lv=vg_f17upgrade1/lv_swap  KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet systemd.unit=system-upgrade.target
        echo 'Loading initial ramdisk ...'
        initrd /upgrade/upgrade.img
}

The contents of / (/dev/vg_f17upgrade1/lv_root):

[root@f17upgrade1 /]# ls -l
total 66
lrwxrwxrwx.   1 root root     7 Oct 24 14:38 bin -> usr/bin
dr-xr-xr-x.   5 root root  1024 Oct 24 15:41 boot
drwxr-xr-x.  18 root root  3180 Oct 24 16:52 dev
drwxr-xr-x. 127 root root 12288 Oct 24 16:52 etc
drwxr-xr-x.   3 root root  4096 Oct 24 14:54 home
lrwxrwxrwx.   1 root root     7 Oct 24 14:38 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 Oct 24 14:38 lib64 -> usr/lib64
drwx------.   2 root root 16384 Oct 24 14:37 lost+found
drwxr-xr-x.   2 root root    40 Oct 24 16:52 media
drwxr-xr-x.   2 root root  4096 Feb  3  2012 mnt
drwxr-xr-x.   2 root root  4096 Feb  3  2012 opt
dr-xr-xr-x. 151 root root     0 Oct 24 16:52 proc
dr-xr-x---.   5 root root  4096 Oct 24 16:53 root
drwxr-xr-x.  34 root root  1160 Oct 24 16:52 run
lrwxrwxrwx.   1 root root     8 Oct 24 14:38 sbin -> usr/sbin
drwxr-xr-x.   2 root root  4096 Feb  3  2012 srv
dr-xr-xr-x.  13 root root     0 Oct 24 16:52 sys
lrwxrwxrwx.   1 root root    23 Oct 24 16:40 system-upgrade -> /var/lib/fedora-upgrade
drwxrwxrwt.  22 root root  4096 Oct 24 16:54 tmp
drwxr-xr-x.   2 root root  4096 Oct 24 16:40 upgraderoot
drwxr-xr-x.  13 root root  4096 Oct 24 14:38 usr
drwxr-xr-x.  19 root root  4096 Oct 24 14:45 var

and the contents of /boot (/dev/vda1, ext4):

root@f17upgrade1 /]# ls -l boot/
total 49164
-rw-r--r--. 1 root root   115179 May  7 11:35 config-3.3.4-5.fc17.x86_64
-rw-r--r--. 1 root root   122022 Oct 16 21:00 config-3.6.2-4.fc17.x86_64
drwxr-xr-x. 2 root root     1024 Oct 24 15:24 grub
drwxr-xr-x. 6 root root     1024 Oct 24 16:56 grub2
-rw-r--r--. 1 root root 17403429 Oct 24 14:47 initramfs-3.3.4-5.fc17.x86_64.img
-rw-------. 1 root root 18263359 Oct 24 15:41 initramfs-3.6.2-4.fc17.x86_64.img
drwx------. 2 root root    12288 Oct 24 14:37 lost+found
-rw-------. 1 root root  2412391 May  7 11:35 System.map-3.3.4-5.fc17.x86_64
-rw-------. 1 root root  2504543 Oct 16 21:00 System.map-3.6.2-4.fc17.x86_64
-rwxr-xr-x. 1 root root  4662160 May  7 11:35 vmlinuz-3.3.4-5.fc17.x86_64
-rwxr-xr-x. 1 root root  4831808 Oct 16 21:00 vmlinuz-3.6.2-4.fc17.x86_64

Michael Scherer of Red Hat reports:
While trying to upgrade my F19 to F20 using fedup, I noticed that it use
a directory in /var/tmp/, with a fixed known name.
cachedir = '/var/tmp/fedora-upgrade'

One note, in fedup 0.8.0 (F20) the directory is now /var/tmp/system-upgrade
As per https://bugzilla.redhat.com/show_bug.cgi?id=1066679

Suggest you use Python mkdtemp():

http://kurt.seifried.org/2012/03/14/creating-temporary-files-securely/

Thanks.

https://bugzilla.redhat.com/show_bug.cgi?id=981180

fedup should probably refuse to upgrade the system if the arch listed in .treeinfo doesn't match the system.

Hi,

would it be possible to enhance fedup to output a list of packages to be downloaded with wget or similar and used by fedup to do the upgrade?

Would be nice for machines with limited connectivity.

It would make a lot more sense if we didn't touch your bootloader config automatically. Instead it should work kind of like git rebase --interactive:

# fedup --network 21
<chug chug chug, interrupted>
# fedup --status
Downloading data for 'fedup --network 21'.
Try 'fedup --continue' to continue upgrade, or 'fedup --abort' to clean up.
# fedup --continue
<chug chug>
All done. Use 'fedup --reboot' to start upgrade.
# fedup --reboot

Without /etc/mdadm.conf, you can't start some mdadm devices properly.

We need a way for package maintainers to mark these files so that they get automatically injected into the initramfs by fedup.

Examples:

• /etc/mdadm.conf
• /etc/mdadm/mdadm.conf - overwrites /etc/mdadm.conf
• /etc/lvm/lvm.conf - replaces old /etc/lvm.conf
• /etc/dasd.conf

cachedir and packagedir are hardcoded to /var/tmp/system-upgrade and /var/lib/system-upgrade; if the user doesn't have space on /var (but has plenty of space in, say, /home) they can't upgrade their system.

But: if we let the user decide where to put the data, we need to make sure that whatever filesystem the data is on gets mounted during upgrade-prep.

This will require some extra jiggery-pokery with mounts and such to allow e.g. USB keys to be used as cache/install source.

Since none of the existing repos contain install images, fedup has no idea where to get kernel/initrd.

This information exists in releases.txt, so we should probably grab that to figure things out..

commit 38d66bb merged the checksig branch, which added signature checking for packages, but we need to also check the signatures on the kernel/initrd.

The .treeinfo file contains SHA256 hashes for both images, so if we have a .treeinfo.signed that's signed with the Fedora key that's just as good as signing the files themselves.

To do this we need:

• .treeinfo.signed in instrepo
• a default gpgkey path for instrepo (like the default URL)
• code to import CLI-added (or default) GPG keys into fedup's keyring
• future keys shipped in previous releases (e.g. Fedora 20 keys in the fedora-release-19 package)
• --nogpgcheck argument for disabling GPG checking

It's not uncommon to see fedup do something like this during download:
(9/2157): LibRaw-0.15.4-1.fc20.x86_64.rpm
(16/2157): NetworkManager-openconnect-0.9.8.0-2.fc20.x86_64.rpm
...: zlib-devel-1.2.8-3.fc20.x86_64.rpm
Canna-libs-3.7p3-40.fc20.x86_64.rpm
[...]

Everything gets downloaded, but the order/numbering is wrong, and they stop being numbered when we hit the "last" one, and then the rest get downloaded. Weird!

This causes problems if, say, you install a kernel after running fedup (but before starting the upgrade).

Instead we should use a systemd generator to temporarily change the default unit if certain flag files exist - like systemd's SystemUpdates feature does.

Probably the flag file(s) should be written by the fedup initrd so the upgrade won't start unless you've booted our special image.

It's unclear whether there's any urgency to this (i.e. whether it's considered 'required' for F22 as part of https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF ), but it's gonna need to get done at some point, so may as well have a ticket for it.

For everything it currently uses yum for, fedup should use dnf instead, cos it's the new shiny. (As a side note, I believe it also makes #21 more viable).

wwoods posted a high-level assessment of what needs doing to devel@: https://lists.fedoraproject.org/pipermail/devel/2015-January/207152.html

After installing fedup, it is possible to run fedup-cli as a non-root user without using sudo. If this happens, all the packages are downloaded without issue but right after the upgrade transaction is tested, the following error message shows up:

testing upgrade transaction
rpm transaction 100% [=========================================================================================]
rpm install 100% [=============================================================================================]
setting up system for upgrade
Traceback (most recent call last):
  File "/usr/bin/fedup-cli", line 179, in <module>
    main(args)
  File "/usr/bin/fedup-cli", line 167, in main
    prep_upgrade(pkgs, bootloader=args.bootloader)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 211, in prep_upgrade
    link_pkgs(pkgs)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 141, in link_pkgs
    os.mkdir(packagedir, 0755)
OSError: [Errno 13] Permission denied: '/var/lib/fedora-upgrade'

I was able to re-run fedup-cli using sudo and it completed without issue.

fedup should probably check for privileges before starting in order to avoid this error

Fedup update failed when run with localized terminal LANG=fi_FI.UTF-8.

Fedup version:
fedup-0.9.2-1.fc21.noarch

Command:
sudo fedup --network 22

Tail of output:

warning: /var/cache/system-upgrade/rpmfusion-nonfree/packages/dropbox-2.10.0-2.fc22.noarch.rpm: Header V4 RSA/SHA1 Signature, key ID a6708da3: NOKEY
Importing GPG key 0xA6708DA3:
 Userid     : "RPM Fusion nonfree repository for Fedora (22) <[email protected]>"
 Fingerprint: bad2 40a4 79ff 87e7 791e 105f 27d7 7a09 a670 8da3
 Package    : rpmfusion-nonfree-release-21-1.noarch (@/rpmfusion-nonfree-release-21.noarch/21)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-nonfree-fedora-22
Traceback (most recent call last):
  File "/bin/fedup", line 291, in <module>
    main(args)
  File "/bin/fedup", line 201, in main
    pkgs = download_packages(f, add_install=args.add_install)
  File "/bin/fedup", line 85, in download_packages
    f.download_packages(updates, callback=output.DownloadCallback())
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 358, in download_packages
    self._checkSignatures(updates, callback)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 495, in _checkSignatures
    self.getKeyForPackage(po, fullaskcb=keycheck)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6192, in getKeyForPackage
    "timestamp": info['timestamp']})
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 494, in <lambda>
    keycheck = lambda info: self._GPGKeyCheck(info, callback)
  File "/usr/lib/python2.7/site-packages/fedup/download.py", line 513, in _GPGKeyCheck
    return callback.userconfirm()
  File "/usr/lib/python2.7/site-packages/fedup/textoutput.py", line 136, in userconfirm
    return YumOutput().userconfirm()
  File "/usr/share/yum-cli/output.py", line 980, in userconfirm
    choice = raw_input(prompt)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 6: ordinal not in range(128)

Workaround:
Run command

  export LANG=en

before fedup command.

If you do something like fedup --network 19, and then decide, whoops, I want to go to 20, we'll still use the cached metadata from the Fedora 19 versions of all the repos.

We need to invalidate the cached metadata whenever the user changes the version or the URL of --instrepo.

If the ISO provided with --iso isn't on a mount that's listed in /etc/fstab, we won't be able to find it when we reboot.

At the very least, we should refuse to continue with the upgrade in this case.

To handle this cleanly we probably need to poke around in /proc/mounts and/or /proc/self/mountinfo so we can set up the mount after reboot.

$ fedup --network 21
This installation of Fedora does not belong to a product, so you
must provide the --product=PRODUCTNAME option to specify what product
you want to upgrade to. PRODUCTNAME should be one of:

workstation: the default Fedora experience for laptops and desktops,
powered by GNOME.
server: the default Fedora experience for servers
cloud: a base image for use on public and private clouds
nonproduct: choose this if none of the above apply; in particular,
choose this if you are using an alternate-desktop spin of Fedora

Selecting a product will also install its standard package-set in
addition to upgrading the packages already on your system. If you
prefer to maintain your current set of packages, select 'nonproduct'.

See https://fedoraproject.org/wiki/Upgrading for more information.

so update it to something like "fedup --network 21 --product workstation"

It'd be really nice if there was a dracut module that pulled in the right stuff to make the plymouth 'label' plugin work. Then we could write text on the splash screen during the upgrade. That'd be nice, wouldn't it? So nice.

There is a typo in line 123 in callback.py

-       eelf.log.debug('restarting depsolve')
+       self.log.debug('restarting depsolve')