Open mmstick opened 4 months ago
This will require that the updates currently in master_noble are released.
Is this no build available
error when forcing an upgrade normal? I don't remember that from testing previous releases pre-release.
The upgrade did continue, despite the message saying it was aborted.
Yes. Have updates for noble been released yet?
Ah, I see, the "no build available" thing is because there are no 24.04 published isos yet.
Updates for noble have been released now. After adding this branch in the 22.04 VM again, applying all updates, rebooting, and then running pop-upgrade release upgrade -f
, this time it seemed to think it was ready to reboot way earlier than it should have (it didn't do this when I tried last week):
The log doesn't look like it contains anything super useful (this was collected after rebooting): out.txt
Any idea why this is happening? I replicated it a second time, making sure there weren't any updates available (including for update-manager-core
and ubuntu-release-upgrader-core
). pop-upgrade still just downgraded those to the released versions (presumably because they weren't pinned and it reset the system's repos) and then told me to reboot.
I think those packages not being pinned during upgrades (and thus showing up in the output when testing pop-upgrade branches) was existing behavior, but the failure's new.
At least once I've seen all package sources updated to Noble, but the distro itself remained 22.04. This was on an Oryp7.
I have found, and continue to find, that I need to run the upgrade command (pop-upgrade release upgrade -f
) two to three times to actually kick an upgrade off. I added a few lines to the output for clarity but this shows a few reported errors.
On the first attempt, the release upgrade was aborted. On the second, the release upgrade kicked off, but the recovery upgrade was aborted.
Do you have logs from the pop-upgrade daemon?
May need to use env S76_TEST=1
to prevent it from upgrading to the version in the master repository.
What would the expected behaviour be on a system which does not have Cosmic installed/configured before the upgrade? It looks like the boot process after running upgrade hangs while attempted to start gdm?
It transitions to what is defined in the pop-desktop packaging for 24.04. The pop-de-cosmic metapackage replaces pop-de-gnome, so most gnome packages will be automatically removed on upgrade. Since cosmic-session provides cosmic-greeter, cosmic-greeter should be set up instead of gdm.
Here's what's in journalctl when the iso failed to install to the recovery partition, in case that helps determine the issue.