@Kulfy Yep. :)

@Kulfy I don't actually know why it doesn't work in WSL though.

@Zanna Thanks! Is that ellipsis intended to suggest I do something? :)

@EliahKagan yep :D

@Zanna You may know this, but I figured I'd mention: what appears as layers in the output of git --log graph (made up of |, \, and / characters) is just edges of the graph. The edges are directed and face downward in the output of git log --graph. Commit B has an edge to commit A when A is a parent of B. It looks layer-like as a result of pushing the (visual representations of the) edges into a narrow vertical space at the left side of the output.

When --all is omitted, git log --graph shows the subgraph of just the commits that are ancestors of the current commit (including the current commit itself) and the edges from child to parent through which those ancestors are reachable.

@Zanna Although on the one hand the question is quite flawed in that it doesn't say specifically how the OP tried to upgrade or what went wrong when it did... in another way, it's kind of an awesome question since it seems to cover many of the cracks between the existing answers there.

I've begun to attempt to write an answer but I'm finding it tricky because I want it to be useful to future readers whose version numbers are different. (Also, the situation somewhat with the same version numbers changes as point releases or even just any updates are released, and especially when any of the various things we vaguely mean by "EOL" these days happens to a release. :) )

I recommend comparing the output of git log --graph and git log --graph --all to what gitg shows you for the same repository. It also shows the edges in a layer-like way, but with a bit more room to breathe. Also relevant:

@EliahKagan it's great when stuff like that happens

@EliahKagan I can imagine

@Zanna One of the things I'm trying to figure out is, when the upgrade is aborted due to errors, does that ever have the effect of attempting to stay on the release being upgraded from? I think it does not. It certainly didn't when I got that error. But I don't know for sure. I don't know if I should be saying something about that.

I've "figured it out," in the sense that I've decided to say something about that.

@EliahKagan so you get a half-upgraded system?

That's what I got, yes.

sorry user, it went wrong :(

It is possible for the upgrade be aborted in such a way that it rolls back. I've had that happen when running do-release-upgrade. (I should perhaps have mentioned that before, when I said that I've never had upgrades fail except when testing things in virtual machines. I don't consider that failure, but that's maybe a questionable view.) I have no idea what that looks like when one upgrades graphically, though. I rarely upgrade graphically, but the method I tested for this was graphical.

I think that once packages actually start being installed, it doesn't roll back. But I'm not actually sure about that.

It doesn't seem to be very well documented

Btw, I hadn't mentioned this before, but the third upgrade--the one from 18.04 LTS to 19.04--worked. That's just normal (because 18.10 is EOL and they aren't) but it's still a nice test that nothing seems to have broken horribly in the previous upgrades. Plus, it achieves the actual goal the OP asked for. I put screenshots related to the previous upgrades above, so I figure I may as well put the ones related to the third upgrade here, too.

Then when I move messages to the Island, they'll all be there for whoever is interested. I will try hard to find a good way to move them (while keeping everything making sense) because they--mostly the previous ones where the status of Natty feedback needs to be looked at--do seem like they may be making it harder to notice some of the messages are more on-topic (for the Downboat).

@EliahKagan yeah, it could still have gone wrong if something got mangled at an earlier stage

That's it; I didn't take screenshots of the actual upgrade process because it's totally normal and nothing went wrong. The only things I think will need explanation are why it's possible to skip 18.10 and how to make the Software Updater offer an upgrade from 18.04 LTS to a non-LTS release.

@Zanna Yes, and that was a more compelling confirmation that the package manager was working okay than just Firefox and LibreOffice working and sudo apt update && sudp apt upgrade showing the correct repositories and not giving any errors.

indeed :)

@EliahKagan Do you run deborphan (sudo apt install deborphan) to clean up leftover orphaned packages after a release upgrade? I do.

No, but for release upgrades that were aborted in the middle and manually completed, it sounds like a good idea!

I've noticed that deborphan has a positive effect on lagging.

I'd want to test it with the particular situation of that upgrade before including in the procedure I tested and intend to recommend there.

But it sounds better than just running sudo apt --purge autoremove and hoping it got rid of enough! :)

Do you mean you run it even after release upgrades that that are done through the Software Updater or do-release-upgrade and that succeed with no errors?

deborphan is completely granular. You can remove orphaned packages any way from removing them one at a time to removing them all at a time.

First I run any commands that were specifically recommended by the text console when upgrading the release. Next I run sudo apt update && sudo apt upgrade. Next I run sudo apt autoremove. Last of all I run deborphan.

← 147 messages moved from Raiders of the Lost Downboat