Comment 6 for bug 1761997

Hi Brian,

Brian Murray wrote:
> + 2) rm /etc/cron.daily/mlocate (this'll ensure you get a conffile prompt)
> + 3) ssh to Ubuntu 16.04 system so the release upgrade is run in screen
> + 4) run do-release-upgrade -d
> + 5) wait for the conffile prompt from mlocate
> + 6) ssh to the Ubuntu 16.04 system being upgraded
> + 7) sudo -i
> + 8) run screen -rd
> +
> + With the version of screen in the release pocket you'll receive the
> + following error:
> +
> + root@clean-xenial-amd64:~# screen -rd
> + Directory '/run/screen' must have mode 777.

Thanks for the detailed explanations.

This sounds a little bit like screen being already unpacked, but not
yet configured. But there must be more than that…

Can you check what permissions /run/screen actually has at that point?

What I don't understand is: Since screen is already running at that
point, /run/screen should already exist with the proper permissions
from either /etc/tmpfiles.d/screen-cleanup.conf or from
/etc/init.d/screen-cleanup from 16.04's screen package. And according
to the changelog (in Debian at least), nothing in the maintainer
scripts changed between 4.3.1-2 and 4.6.2-1. And git log shows only
two commits since June 2015 (where /etc/tmpfiles.d/ support was
finalized), of which one just renames the files and the other one
replaces /var/run/ with /run/ — which both should be defacto noop with
regards to their logic.

Does any other package modify /run/'s permissions recursively during
dist-upgrade?

  Regards, Axel
--
 ,''`. | Axel Beckert <email address hidden>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
  `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE