Templates fail to update due to buster "oldstable" status

[conorsch]

During a clean install in support of #717, I encountered this failure:

  ----------
            ID: update
      Function: pkg.uptodate
        Result: False
       Comment: E: Repository 'https://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
                E: Repository 'https://deb.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
       Started: 09:47:31.090662
      Duration: 5025.744 ms
       Changes:   
  ----------

That same error will bite us on the updater runs, blocking upgrades until resolved.

There's an option we can use to resolve: apt-get --allow-releaseinfo-change update but we'll need to make sure we can run that prior to any other apt commands.

[conorsch]

Working on this since I expect it's an issue in prod already. At a glance, might make sense to resolve issues #572 & #651, as well.

[eloquence]

I'm unable to observe any update issues with a running prod system:

[eloquence]

An sdw-admin --apply run on the same system completed without errors.

[conorsch]

@eloquence Well that's rather reassuring. However, I was able to reproduce this problem just now in a dev environment. The significant variable seems to be whether the TemplateVM RPM was freshly installed. Would appreciate if someone would try to repro with the following STR:

1. Checkout main branch on this repo, switch to dom0
2. make clone && make clean
3. sudo dnf remove qubes-template-securedrop-workstation-buster ; necessary because make clean doesn't remove TemplateVM
4. sudo dnf clean all
5. make dev

If provisioning completes successfully, great! If you see the error reported above, however, please document here.

[eloquence]

Sure, I can give that a try... 🕐 🕑 🕒

[eloquence]

I'm encountering #514 again on a fresh install, will see if rebooting resolves.

[eloquence]

After reboot, able to reproduce on fresh install. I also see the error (and an interactive prompt) when manually running apt update in the impacted templates.

[conorsch]

Huh, thanks for confirming, @eloquence. So it seems like the strongest correlation is the age of the apt cache: if it's months old (as a fresh TemplateVM RPM would be on first run), then the oldstable prompt raises an error. For machines that have regularly been running the updater, however, that didn't happen. I wonder why that is? Either way, it's definitely a problem for clean installs, so will continue to work on a fix.

[eloquence]

The good news is that it's fairly easy to work around: after entering 'Y' in response to the confirmation prompt (which appears after running sudo apt update) in the 3 impacted templates (securedrop-workstation-buster, sd-small-buster-template and sd-large-buster-template, I was able to complete the provisioning process, and the updater ran without errors. Of course still important to fix to avoid the need for that manual workaround.