Fresh 20.04 to 22.04 upgrade fails

[jacobgkau]

Fresh 20.04 to 22.04 upgrade fails

[jacobgkau]

I attempted to replicate this again today, running upgrade.sh manually. The script did not appear to fail. After it finished, /etc/os-release still said 20.04. After rebooting, I am in 22.04, and all packages are up-to-date, but pop-upgrade still offers to "upgrade" to 22.04 since /etc/os-release is wrong.

This feels like something is wrong with the pop-default-settings packaging causing those files not to be updated. However, a possible workaround might simply be force reinstalling the /etc/os-release/etc/lsb-release files as described here at the end of the upgrade.sh script.

[jacobgkau]

pop-os/default-settings#163 touched the conffiles configuration of pop-default-settings. I'm beginning to suspect this issue was caused by that PR.

[mmstick]

Perhaps it'll be fixed by renaming it back to conffiles from pop-default-settings.conffiles.

[jacobgkau]

I see in the upgrade.sh output where pop-upgrade is leaving the old pop-default-settings conf files by default:

Perhaps it'll be fixed by renaming it back to conffiles from pop-default-settings.conffiles.

I think the breaking change in pop-os/default-settings@7fcad35 might have been that we used to override dh_installdeb and copy our conffiles file over manually after the automatic version has been run. Without doing that, dh_installdeb is going to include any file under /etc by default, and we leave it there (by not copying over it.)

So maybe the naming doesn't matter so much as that override. (The new naming is correct if we want to have it use that and then add its auto-generated ones; doesn't matter so much if we use the "correct" name or not if we're overriding?)

[jacobgkau]

I'm working on this in a branch: https://github.com/pop-os/default-settings/tree/conffiles_jammy

[jacobgkau]

/etc/os-release is displaying correctly with the fix in pop-os/default-settings#165.