Introduction:
Back in March, I bought a new Dell XPS 13 that came with Ubuntu 20.04 pre-installed. Since version 20.10 had already been released, I immediately tried to upgrade it. That upgrade partially but not entirely succeeded. The way that I became aware that it was not entirely successful is that whenever I check for updates it tells me I am still running 20.04 and could upgrade to 20.10 (which does not work). The way in which this has become problematic for me is that I will never be offered the option to upgrade to 21.04 (or any later versions).
The current state of my system:
There is a lot of contradictory information on my system:
- /etc/lsb-release says that I am running 20.10.
- The hostnamectl program says that I am running 20.04.1 LTS.
- /etc/os-release says that I am running 20.04.1 LTS.
- /etc/issue says that I am running 20.10.
- The lsb_release program says that I am running 20.04.1 LTS.
- Whatever generates MOTDs says that I am running 20.10.
- /etc/apt/sources.list has all of its non-commented lines referring to groovy (the code name for 20.10).
The reason my original upgrade attempt failed:
The main.log from my original upgrade attempt ends with this line:
2021-03-05 21:29:16,691 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process “./xorg_fix_proprietary.py” (No such file or directory) (8))
Everything prior to that looks like it was successful. I'm not sure why it would not have been able to find that file, as the file exists in /usr/lib/python3/dist-packages/DistUpgrade/.
The reason my subsequent upgrade attempts fail:
There are no errors in the log file for subsequent attempts. Instead, we just get this:
2021-05-27 20:32:20,571 DEBUG abort called
That appears at the point in the log file where I would have otherwise gotten:
2021-03-05 21:16:54,953 DEBUG quirks: running StartUpgrade
What actually gets printed to the screen when running /usr/bin/do-release-upgrade is:
Calculating the changes
Calculating the changes
Restoring original system state
Aborting
While there is nothing in the log file saying so, I believe that the reason it is aborting is that it is sensing that the system has already been upgraded.
Debugging steps so far:
I've been digging through the files in /usr/lib/python3/dist-packages/DistUpgrade/ to try to find the information the output / logging is not giving me. It's become fairly clear that the process is being aborted because DistUpgradeController.calcDistUpgrade() is returning False. I've tried adding additional logging to that function to determine which return statement is firing, but the upgrade process doesn't seem to see / use my revised version of the file, even after I compiled it and confirmed that ./pycache had an updated file. So that seems like a dead end unless / until I can figure out how to get it to use my modified python files.
Another approach might be to determine what should have been done after the failed attempt to run xorg_fix_proprietary.py back in my original upgrade attempt, so that I could execute those steps manually. This leads me to the place in fullUpgrade() that calls postUpgrade(). It looks like the only part of the process that might have not run is this:
if os.path.exists("/var/lib/ubuntu-release-upgrader/release-upgrade-available"):
os.unlink("/var/lib/ubuntu-release-upgrader/release-upgrade-available")
But, in fact, that file does not exist on my system!
Possible next steps
I can imagine proceeding in one of the following ways:
- Figure out how to use my own modified versions of the DistUpgrade*.py files, and modify them to skip over the checks that are making my upgrade fail.
- Find some way to downgrade back to a 20.04 system so that I can try a fresh upgrade again.
- Manually make whatever changes are needed for my system to recognize that is is, in fact, running 20.10.
I'd appreciate any advice about which of those is least dangerous and how to proceed with it.
