Login and terminal not available after failed upgrade and reboot

[tfitz (terry fitz)]

I’m running Fedora 29 on a Dell Optiflex. Kernel is 4.19.2-301.fc29.x86_64

Haven’t ran my PC for 6 months I performed a dnf update and dnfupgrade. I recall there were something like 2500 items to upgrade but less than half way through the PC freezes. I tried a few keystroke commands but then gave up and pulled the plug.

When I log back it I can de-encrypt my drive but then the screen shows the circular fedora symbol. Normally I press a key and it will allow me to enter my login password but it wasn’t happening.

I can see the boot screen (Windows key + space) and there are a number of failures. I tried to go to the terminal/shell by pressing Ctrl-Alt-F2 (Ctrl-Alt-F1 exits the terminal) but I only see a flashing horizontal bar and no key works. Back to the shell I took a picture of the repeating failures.

I also tried to install (at the grub menu) into the rescue option but the result is the same.

Please help!

[vgaetera (Vladislav Grigoryev)]

Change the target environment as described here.
Then connect to the internet with nmcli and try to resume the upgrade and fix the errors:

rpm --rebuilddb
dnf --refresh upgrade
dnf check all
dnf repoquery --duplicated
dnf repoquery --unsatisfied

The alternative way is to boot from LiveCD/USB and perform the recovery via chroot.

[tfitz (terry fitz)]

Thanks. With your instructions I was able to use a console! I performed rpm --rebuilddb ok but dnf --refresh upgrade threw the following error:

`/usr/lib64/pythong3.7/site-packages/hawkeye/__init__.py:344: DeprecationWarning: The class hawkey.Repo is deprecated. Please use dnf.repo.Repo instead. The class will be removed on 2019-12-31.`
`  warnings.warn(msg, DeprecationWarning)`

`Traceback (most recent call last):`
`  File "/usr/bin/dnf", line 58, in <module>`
`    main.user_main(sys.argv[1:], exit_code=True)`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 179, in user_main`
`    errcode = main(args)`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main`
`    return _main(base, args, cli_class, option_parser_class)`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main`
`    return cli_run(cli, base)`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run`
`   cli.run()`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1054, in run`
`    self._process_demands()`
`  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 785, in _process_demands`
`    load_available_repos=self.demands.available_repos)`
`  File "/usr/lib/python3.7/site-packages/dnf/base.py", line 380, in fill_sack`
`    self._sack = dnf.sack._build_sack(self)`
`  File "/usr/lib/python3.7/site-packages/dnf/sack.py", line 93, in _build_sack`
`    logfile=os.path.join(base.conf.logdir, dnf.const.LOG_HAWKEYE))`
`  File "/usr/lib/python3.7/site-packages/dnf/sack.py", line 64, in __init__`
`    self._moduleContainer = None`
`SystemError: Unable to parse ModuleContainer object`

I tried disabling all repo files stored in `/etc/yum.repos.d/ and the only difference is that the above deprecation warning is not shown.

[vgaetera (Vladislav Grigoryev)]

Is there any luck with the following commands?
Does this work?

dnf download dnf

In the worst case you can download the latest versions of installed packages with dnf or wget and install/reinstall them with rpm.

[tfitz (terry fitz)]

I tried
dnf download dnf
and the other commands you suggested in the previous post but the same error occurred as before. Surprised that the ModuleCotnainer object is not readable/parsable by python suggesting that I must have cut the cord halfway through a write operation causing it to be corrupted.

After the longest back up in (my) history, lasting 24hrs for 200GB (and some content didn’t even make it…) I decided to do a fresh install and jump directly to Fedora 30.

Thanks for your support though! Without it I would never have been able to make that backup.

[stridge (Stephen Tridgell)]

This seems to be a mismatch in version between dnf and libdnf. dnf v 4.2.5 removes the line causing an issue.