(CCing the bug tracker)

Hi Ruther,

Thanks for all your work and help on this issue! Sorry for the delay - I needed to find a quiet time to reconfigure and watch what happens more
carefully.

Rutherther <ruthert...@ditigal.xyz> writes:

I am CCing you to get more information about the inconsistent ownership,
if you could help with that.

The most important questions are probably:
0. Are you sure the service actually ran after you reconfigured to root? It should definitely run after reboot, not sure if after reconfigure
  as the service already exists, it's just modified

To be honest, I had no understanding of how the change was taking place. I read about it briefly in the `guix pull --news --details` and may have briefly referred to the manual - I can't recall exactly. Possibly naive of
me.

I'll give it another shot now. I've set "privileged? #f" again and run
"system reconfigure". I see that it prints:

  ...
  building
  
/gnu/store/yyn762lwzra0nqrrwhgbwwlz2k0qyn0h-upgrade-shepherd-services.scm.drv...
  shepherd: Starting service host-name...
  shepherd: Service host-name started.
  shepherd: Service host-name running with value "Marseille".
  shepherd: Service host-name has been started.
  shepherd: Starting service user-homes...
  shepherd: Service user-homes has been started.
  shepherd: Starting service sysctl...
  shepherd: Service sysctl has been started.

Then appears to hang, though I now realise that it's busy updating
ownership. Unfortunately there is no feedback to the user or advice not to
interrupt the process. I watched the ownership in /gnu/store be
progressively updated to "guix-daemon".

It took about 5 mins, then quickly printed:

  shepherd: Service user-homes has been started.
  shepherd: Starting service guix-ownership...
  shepherd: Changing to unprivileged guix-daemon.
  shepherd: Service guix-ownership has been started.
  shepherd: Starting service x11-socket-directory...
  shepherd: Service x11-socket-directory has been started.
  shepherd: Service user-homes has been started.
  shepherd: Service tor is currently disabled.
  shepherd: Service user-homes has been started.
  ...

The message "Changing to unprivileged guix-daemon" needs to be visible before the work is done though. Is it possible that stdout is being
buffered?

1. Do you think you could've killed the service when it was running after you reconfigured back to privileged daemon, ie. by rebooting when
it was running?

Absolutely I could have killed it - to me it just looks like reconfigure had locked up for some reason. I'd probably forgotten that I even set the "privileged?" option, or didn't consider the pause might be related.

So yes, user error on my part, but reflecting on it, the mental model I have of Guix is that it's immune to issues such as power outages during upgrades. I realise now that this is a complex migration, so I appreciate
that there's some state to manage and it takes time.

Possibly the uprivileged transition might need to be either:

a. more obvious to the user, eg. red text and interactive: "The migration to the unprivileged daemon needs to update a very large number of files and must not be interrupted. Do not proceed on battery power. Proceed? (y/N)"

b. robust to being interrupted part way, such as starting the daemon as privileged unless the transition process ran successfully. Maybe that's not
technically feasible though - just a thought.

2. Do you know what folders had wrong owners?
  - Was everything under /var/guix fully owned by 971?
  - Was everything under /etc/guix fully owned by 971?
  - Was everything under store fully owned by 971?

Not everything, just some. I'm not 100% sure it was 971, but something like that - the ID of a user that didn't exist on the system (presumably because
I rolled back/reconfigured to "privileged? #t" again).

Now that it's run successfully, all of /gnu/store and /etc/guix are guix-daemon:guix-daemon. All of /var/guix is guix-daemon:guix-daemon except for files /var/guix/profiles and /var/guix/userpool, which are root:root.

I haven't rebooted yet, but if you don't hear back from me, assume that
worked fine.

Thanks again for all your work!

Ben



Reply via email to