I don't have access to the machine with the logs right now, but the problem was that the openafs-client was refusing to start because the cache size exceeded 95% of the root partition size -- I had hard-coded a certain cache size, which was too big for a chromebook with only around 13GB of space.
I tried to correct the cache size programmatically the same way I specified the initial valuie, by using debconf-set-selections, followed by dpkg-reconfigure openafs-client. But it appears that the dpkg-reconfigure refused to take the new value, and reverted the cache value as seen by debconf-get-selections, and the openafs-client continued to complain about the cache size. The logs for these commands were attached in my original report. In the end I resolved it by omitting the non-interactive flag to dpkg-reconfigure and going through all the prompts manually, providing the correct cache size manually. Ernesto On Fri, Mar 6, 2026 at 11:48 AM Benjamin Kaduk <[email protected]> wrote: > tags 1129767 moreinfo > thanks > > Hi Ernesto, > > Can you say a bit more about how you triggered this scenario? > Also the `systemctl status openafs-client` output would be helpful. > > The openafs-client maintainers scripts are using debhelper for the systemd > interactions (and use `set -e`) so it's not immediately obvious what might > be failing. > > I'm also not seeing a great way to get deb-systemd-invoke to tell us what > the actual failed command was -- Colin, do you have any tips there? > > Thanks, > > Ben >
