GNU bug report logs - #78355
guix-ownership inconsistent state

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Package: guix; Reported by: Rutherther <rutherther@HIDDEN>; Done: Ludovic Courtès <ludo@HIDDEN>; Maintainer for guix is bug-guix@HIDDEN.

Message received at 78355-done <at> debbugs.gnu.org:


Received: (at 78355-done) by debbugs.gnu.org; 1 Jul 2025 22:29:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 01 18:29:02 2025
Received: from localhost ([127.0.0.1]:59356 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uWjTJ-00023H-JI
	for submit <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:29:02 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:46208)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uWjTF-000227-PH
 for 78355-done <at> debbugs.gnu.org; Tue, 01 Jul 2025 18:28:58 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uWjT9-0006nO-Pm; Tue, 01 Jul 2025 18:28:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=33GSnOao+twWdXyzfLDn7PTZSxPrLr9pIAvAcMPRgjE=; b=FSfEReS9869TGLbP0lJi
 sUD4nBj/Dj7cPQXhinte+5bJLzQilnt11ecNLyNxq9KnsJ6ywPaja1oFwUp0LYQNcn9eoG/Whf6EJ
 RVeZJJqxwvpReGFU8/q3s8MSSDTF4rc0SVdg9NseL0XzR9T2f4HupQJiBX2P0SjWLMCG7G9e1sDan
 BEYwM/h54CyorAfmNNeJKtmHEAftNDRc8A6ousTbI+a8WM5A6jqAsiSo+qrW9uXAbZAIm1EuUDIGJ
 zoirRgPYwqVCTGT7ftKB5LSsqnyRP572tpmw/6nrHLDqbboVoie0bo6olVJQmuu71t7ysqxrnbzHI
 bXeKUqdWG/RDaw==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87h60niu69.fsf@HIDDEN> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?=
 =?utf-8?Q?s?= message of "Tue, 10 Jun 2025 15:48:46 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <87h60niu69.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.1
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Tridi 13 Messidor an 233 de la =?utf-8?Q?R=C3=A9volu?=
 =?utf-8?Q?tion=2C?= jour de la =?utf-8?Q?Girofl=C3=A9e?=
Date: Tue, 01 Jul 2025 23:44:16 +0200
Message-ID: <87h5zvy4b3.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355-done
Cc: 78355-done <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Hi Rutherther,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Rutherther <rutherther@HIDDEN> writes:
>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Sorry for dropping the ball.  How about the patch below?

Pushed as c33bc8008090bafda228e475dedc71cd06f56e4f.

Thanks!

Ludo'.
Notification sent to Rutherther <rutherther@HIDDEN>:
bug acknowledged by developer. Full text available.
Reply sent to Ludovic Courtès <ludo@HIDDEN>:
You have taken responsibility. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 10 Jun 2025 13:49:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 09:49:23 2025
Received: from localhost ([127.0.0.1]:37756 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOzLs-0004KY-Pw
	for submit <at> debbugs.gnu.org; Tue, 10 Jun 2025 09:49:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51262)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uOzLn-0004Ih-7K
 for 78355 <at> debbugs.gnu.org; Tue, 10 Jun 2025 09:49:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uOzLh-0000WV-C4; Tue, 10 Jun 2025 09:49:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=OjfvUlS/ORqPCHU+6EbCuKDqf8pVOxl2a9H/ZqsT+Es=; b=CnmMgiLgN0SE6tJbSU36
 JzV0XMMuK3vmfOBFM2yCyAGFrGwyBewDsU1ijntVmXy+CHXwrU8ODme1mNYyG/i0JqL+lUjEhsZzS
 DQT8gJoUB+yzTdIkNAUsGCtqDOL4ffJ/+past6eDGMlDnvLBLU7HDjpSVjotociCOz5z/asLvh4tm
 ICOeuS6LBynf6wWxe2HQrSKy2/AkNMkkU/aIx/hKiujksTX06MwDGzugaBLpUO5Ru/X+ztzvBL7hL
 uZ9GUBvnlsdl/aN5ltoQ7SA9Et4YaLYJUur7eGZp02Y7rltqHJfKj8d5BZhGNozb3qS40oG9Y7Wgm
 Htu/0JXzjwx1sA==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87tt5sjx97.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sat, 10 May 2025 17:33:56 +0200")
References: <87tt5sjx97.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Duodi 22 Prairial an 233 de la =?utf-8?Q?R=C3=A9volu?=
 =?utf-8?Q?tion=2C?= jour de la Camomille
Date: Tue, 10 Jun 2025 15:48:46 +0200
Message-ID: <87h60niu69.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Rutherther,

Rutherther <rutherther@HIDDEN> writes:

> The guix-ownership service checks /gnu/store ownership to check if the
> whole store and all files important for the daemon (/etc/guix,
> /var/guix) are owned by the appropriate user.
>
> If the folder isn't owned by appropriate user, it moves to those steps:
> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
> itself as last step
> 2. Fix /var/guix
> 3. Fix /etc/guix
> 4. Fix /var/log/guix
>
> So from those laid out steps it should be obvious that if guix-ownership
> service somehow stops between steps 1 and 2, it will never recover
> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
> change owner as last.

Sorry for dropping the ball.  How about the patch below?

Note that it would only help if the user retries to change ownership in
the same direction after interrupting the service; ownership change
remains fundamentally non-atomic so it=E2=80=99s still possible to end up i=
n a
partially chown=E2=80=99d state, if one insists.

Thanks,
Ludo=E2=80=99.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline

diff --git a/gnu/services/base.scm b/gnu/services/base.scm
index edc6f45850..c2851ef1a9 100644
--- a/gnu/services/base.scm
+++ b/gnu/services/base.scm
@@ -1997,10 +1997,9 @@ (define (guix-ownership-change-program)
                              lstat))
 
          (define (claim-data-ownership uid gid)
-           (format #t "Changing file ownership for /gnu/store \
+           (format #t "Changing file ownership for ~a \
 and data directories to ~a:~a...~%"
-                   uid gid)
-           (change-ownership #$(%store-prefix) uid gid)
+                   #$(%store-prefix) uid gid)
            (let ((excluded '("." ".." "profiles" "userpool")))
              (for-each (lambda (directory)
                          (change-ownership (in-vicinity "/var/guix" directory)
@@ -2012,7 +2011,11 @@ (define (guix-ownership-change-program)
            (chown "/var/guix" uid gid)
            (change-ownership "/etc/guix" uid gid)
            (mkdir-p "/var/log/guix")
-           (change-ownership "/var/log/guix" uid gid))
+           (change-ownership "/var/log/guix" uid gid)
+
+           ;; Change the store last so that, if this service is interrupted,
+           ;; ownership appears as having yet to be changed.
+           (change-ownership #$(%store-prefix) uid gid))
 
          (match (command-line)
            ((_ (= string->number (? integer? uid))

--=-=-=--
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 30 May 2025 12:29:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 08:29:57 2025
Received: from localhost ([127.0.0.1]:47206 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uKys0-0000KG-ST
	for submit <at> debbugs.gnu.org; Fri, 30 May 2025 08:29:57 -0400
Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:56601)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ben@HIDDEN>) id 1uKyrx-0000Jb-Qi
 for 78355 <at> debbugs.gnu.org; Fri, 30 May 2025 08:29:54 -0400
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 957B81140195;
 Fri, 30 May 2025 08:29:48 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-08.internal (MEProxy); Fri, 30 May 2025 08:29:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sturm.com.au; h=
 cc:cc:content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm3; t=1748608188; x=1748694588; bh=cybazaI7XZ
 /Y81E0APv+SbEFy+KhaNVgo9kcpEmQNwo=; b=WXnlKl5aEb8RHmaFZb73/UnXGf
 /h1i+Vy0sIyuaWQMF4qa0bvOrB1rjrzrnpklKskGBYkB7/sKbb4g2apOYSqMIqnA
 /h6Kvh15w3t0OqRPtc/He4w+Dr49JxLUv66XFm5u28tOJnuMrMzly6In3eOXagy0
 FuWaDC9swwkQa0TkRFfI2F5A52RsWsDz+/7XRKon7SByrU5nfkQTWw0C7dmxQJtj
 ASbNHvGstZ866SBm1titW3Ij6Ge9nBOmQ0OytIoRsLmnyvMmeCiMCldpx2Glvrf1
 2GujaPnkS64ylkJ+lqfadADBGsmfdczc0VKnmESqMpLzzW8fnB+kFO8iOZZg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1748608188; x=1748694588; bh=cybazaI7XZ/Y81E0APv+SbEFy+KhaNVgo9k
 cpEmQNwo=; b=DvVNRV/KQsNeQbsuXFzsfEBT+wBvPUiRLt/VuAnvKBp8hSoht9O
 dbN30R/bPaqZGjQGuH5Fw6IruQvpNM6z68IWr9CPjcRVYs9Cxw27co1JRYt2pU9e
 YnAGLP4SYJy/nzVFA8bazt2ryY69cL49EYvfxeqxYMAsjCMgB/dURtbEoGhAjYBM
 wHEus5vtptvnRflElYrmFHtHlbc9nSrzX1EQiw+wd0/yRvP9JnCns7QK7YgNgzDi
 JD7e6ZYT3p7QTXI9cE6K3x2m+s9JlWEV6qY7gIGZwurGnCqc5l3ILXpWg3Wz2H9w
 AZjaemO0uL76iBv+RpOV/O8xExjSVC1JhWQ==
X-ME-Sender: <xms:vKQ5aLqNUlEGs1p3Co_uEAvfmeHErBMdWl4qnpK_et6vhdjmDGpDFw>
 <xme:vKQ5aFqQ6QbrlVIsTLLaNz3zJQ8Z_VrYkWfAHH-Ac6de1LAwAbqk6AuCyK-oe9erv
 2Jc8nxXx6e9izA>
X-ME-Received: <xmr:vKQ5aIOqe98utSAWtmy0h8k1HpyAimZbzRCgxlLUaZGMoJMOZusl3KZNBlh58YuJva_GfJcOzyv8KGZ89ojVsUA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvledtvdculddtuddrgeefvddrtd
 dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
 fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
 dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgf
 fffkgggtsehttdertddtredtnecuhfhrohhmpeeuvghnucfuthhurhhmfhgvlhhsuceosg
 gvnhesshhtuhhrmhdrtghomhdrrghuqeenucggtffrrghtthgvrhhnpeeifefhueetgfdv
 vefgvdehffeiieehkeekgeffjeetvdffkeduvdeghfefhfeileenucffohhmrghinhepgh
 hnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr
 ohhmpegsvghnsehsthhurhhmrdgtohhmrdgruhdpnhgspghrtghpthhtohepfedpmhhoug
 gvpehsmhhtphhouhhtpdhrtghpthhtohepjeekfeehheesuggvsggsuhhgshdrghhnuhdr
 ohhrghdprhgtphhtthhopehluhguohesghhnuhdrohhrghdprhgtphhtthhopehruhhthh
 gvrhhthhgvrhesughithhighgrlhdrgiihii
X-ME-Proxy: <xmx:vKQ5aO63gFJZJQGfhVd5zZd9GxYTIT1cbDX6I9gHxf3-M1oYozrw8g>
 <xmx:vKQ5aK7oufWzQGMFUfIfMThyP-dFhsOaCRJpDiFcVXyYpZtudjAz1Q>
 <xmx:vKQ5aGgCg4xudjmZuYyHGv0TYLaJIQo7dx0tDdKoxoTcMX2Ys69ylA>
 <xmx:vKQ5aM4Hb2ILWQPoUquJ2k4HkQ14H1v_z9Vw2iiqjtCo3Ro0QloZGA>
 <xmx:vKQ5aHSRsmY9rJIGJAzeBeepuWbguBMiTGUrX3s8zlr5gMJwwrQC_13r>
Feedback-ID: i7bb0428e:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 30 May 2025 08:29:46 -0400 (EDT)
Received: from Marseille (localhost [127.0.0.1])
 by localhost (OpenSMTPD) with ESMTP id 8f44b4fb;
 Fri, 30 May 2025 12:29:42 +0000 (UTC)
From: Ben Sturmfels <ben@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <874ix2qwcy.fsf@HIDDEN> (Ben Sturmfels's message of "Fri,
 30 May 2025 19:30:21 +1000")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
 <87msbeuy07.fsf@HIDDEN> <874ix2qwcy.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.0.92
Date: Fri, 30 May 2025 22:29:37 +1000
Message-ID: <874ix2uvri.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Ben Sturmfels <ben@HIDDEN> writes:

> 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.

After rebooting, I didn't get any WiFi, but that was expected due 
to
https://issues.guix.gnu.org/78047. I think this is primarily what 
was
causing me problems originally.

I ran `guix system roll-back`, which completed nearly 
instantly. After
rebooting I could see that the "guix-ownership" process was 
running in the
background busily changing ownership back to root:root. Once that 
was
completed I ran `sudo herd restart NetworkManager` which gave me 
WiFi
again.

All seems to be working as intended. I didn't test 
rebooting/interrupting
the guix-ownership process part way through. Ideally it would 
retry I
guess?

Regards,
Ben
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 30 May 2025 09:31:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri May 30 05:31:06 2025
Received: from localhost ([127.0.0.1]:45882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uKw4v-00016q-7T
	for submit <at> debbugs.gnu.org; Fri, 30 May 2025 05:31:06 -0400
Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:35321)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ben@HIDDEN>) id 1uKw4N-000146-Ej
 for 78355 <at> debbugs.gnu.org; Fri, 30 May 2025 05:30:32 -0400
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
 [10.202.2.45])
 by mailfhigh.stl.internal (Postfix) with ESMTP id 790A4254016F;
 Fri, 30 May 2025 05:30:25 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
 by phl-compute-05.internal (MEProxy); Fri, 30 May 2025 05:30:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sturm.com.au; h=
 cc:cc:content-type:content-type:date:date:from:from:in-reply-to
 :in-reply-to:message-id:mime-version:references:reply-to:subject
 :subject:to:to; s=fm3; t=1748597425; x=1748683825; bh=ZqUEXZ3Wyu
 5EHyFkJgbs7wz/efWxhrT0V0xSeRZv2ZQ=; b=ZjxNM5hHkCSwLLlOTMDYWO7XFd
 tb5tprngN+n6ar4ggAPBHHY0af/orzgQMNllhkqFNlwCo1avBJiMQ9alHDm7MCPU
 VYYXrgGWrEi/3H08YRRHrXb5Aa2GRPs9WeT0u8bLH8zEs/qLnWL+TqQVEkfgaJQp
 we/JQjza8GpKYv6uFUUKl5ndbkSBRWJR3ybIY/rRa2Rvqv43nNGPxUDeqUl73YL7
 MNMy88nNBx5Bz6H97ZR2pQ8IFM/E+bo/CwQLvowOp353EzNpoUWXsvj4gflkdwZk
 pkrGbc6Vao1uZ01J/NfcwgIhS0vJwMVyeHwv8gDdyZ1yBjEtomrsrU0EPGyA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=
 1748597425; x=1748683825; bh=ZqUEXZ3Wyu5EHyFkJgbs7wz/efWxhrT0V0x
 SeRZv2ZQ=; b=Fukkhi8wguoXqNhxvb8dEuBbNEMXf3OQCZGzRBYsoHncEDOQL0X
 bCwfJUiwbpP5PS0CHZRv7iLqKHpyGlfUPEeKSYhTsX7SOXiQ+iUiLp5/xV3A1qwa
 qutmDhD1L/PjozvNYLTfRD2TNCbn+zIIVoKZdh2A5Vzyi+FPViFpZZYIhTyzKlbU
 sWYBz2hSZbEXhCIa1scK6p5cJ+cauJKRqYOwsX8IkVwJ33eJrOLdoPdMPC1s7VdB
 rQA8nseXh5OWfHlVwxUpAo6b9U+vqLoQDplhTPDFSCei/t7H//NlhzIvfOGz4A6u
 Lg75VtX0s2GqZl7hCaNnsf5O+elMFZ1GRtw==
X-ME-Sender: <xms:sXo5aBmOgLXlrcthHcqMuzX6k7P7UzF3carbtqlTvtBBWCVu6UB2gA>
 <xme:sXo5aM0SabyK30P-7SXCmv0hZwTSVQTBGaYzUw9uPalouL_vXEb5xOxfn8OMfiAhq
 MYykJtO8OBbYuY>
X-ME-Received: <xmr:sXo5aHqH_bEZ-K00NnbtSbsiTJ5U7miZDPSYnTukFAASGWZVepYVwlT-Q6Wh>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvkeeiieculddtuddrgeefvddrtd
 dtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggft
 fghnshhusghstghrihgsvgdpuffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftd
 dtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgf
 fffkgggtsehttdertddtredtnecuhfhrohhmpeeuvghnucfuthhurhhmfhgvlhhsuceosg
 gvnhesshhtuhhrmhdrtghomhdrrghuqeenucggtffrrghtthgvrhhnpeehjeehudefgeeh
 feetvdeggfevlefhteegfeeigeefgeejvdejfeevuefgjeelieenucevlhhushhtvghruf
 hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsvghnsehsthhurhhmrdgtohhm
 rdgruhdpnhgspghrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh
 eplhhuughosehgnhhurdhorhhgpdhrtghpthhtoheprhhuthhhvghrthhhvghrseguihht
 ihhgrghlrdighiiipdhrtghpthhtohepjeekfeehheesuggvsggsuhhgshdrghhnuhdroh
 hrgh
X-ME-Proxy: <xmx:sXo5aBm3BYZN-f1trykw7exUkm9BjZ4JHn4adxaZcFop6vQmkZZWpA>
 <xmx:sXo5aP0vP-go25z2Qtc-CFp9WLeTX9TD-W5zT9pL7TGEvER-J9sy7A>
 <xmx:sXo5aAtZJ8zanSMMpTcAhLhrueDolhe57u539aRPehtl1T9XFJZoWw>
 <xmx:sXo5aDVdglnLmAdq4M0vCQD6tZLinwIFessApquasXwClUAQsINB4w>
 <xmx:sXo5aG-dHp5HiSqYOME29LnDEmv2jy-_c5BujHy-7I5zXl_YlgIiLGUP>
Feedback-ID: i7bb0428e:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
 30 May 2025 05:30:23 -0400 (EDT)
Received: from Marseille (localhost.lan [127.0.0.1])
 by localhost (OpenSMTPD) with ESMTP id aab3957b;
 Fri, 30 May 2025 09:30:21 +0000 (UTC)
From: Ben Sturmfels <ben@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87msbeuy07.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Thu, 15 May 2025 09:35:52 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
 <87msbeuy07.fsf@HIDDEN>
User-Agent: mu4e 1.12.11; emacs 30.0.92
Date: Fri, 30 May 2025 19:30:21 +1000
Message-ID: <874ix2qwcy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  (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. 
 Content analysis details:   (1.3 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
 query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [202.12.124.155 listed in sa-trusted.bondedsender.org]
 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
 query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [202.12.124.155 listed in bl.score.senderscore.com]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [202.12.124.155 listed in wl.mailspike.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [202.12.124.155 listed in list.dnswl.org]
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org, Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

(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 <rutherther@HIDDEN> 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
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 15 May 2025 08:33:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 04:33:20 2025
Received: from localhost ([127.0.0.1]:50882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFU1o-0005du-1s
	for submit <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:20 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:56652)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uFU1l-0005dU-5c
 for 78355 <at> debbugs.gnu.org; Thu, 15 May 2025 04:33:17 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uFU1e-00047I-Nm; Thu, 15 May 2025 04:33:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=edU64oEbDD8LrkXp/KSZ8xl64Nu6IOEr7xSF4+dhBFo=; b=af6NZsvdHU26bF0L8j1Q
 5x0kFMsEYo+n2Mhpyz9nprVPNByadtscNR+1sldB3r/EooGj6TAc7TDwdE8EM+ZVmXG0h4kNg+mqx
 /qSaqZ6p61fGIiCfgQDQNmBS7DPkNCtUM79LUpB8p+fh9sZBetjdr8uGKMe5ecNJNt9wiZmWDWK14
 dhepZZVo2tCB5nDgpUumozLJSTa8QeFl52frtFdtGu9kyaeDm7oqEoaZT7AysP6ghDiPINNnAGKQw
 HxAfni1Uh6gTyncIow1UmNzIqr4L3NP1F2oI2NZMWwdR711uZXBgN1msPMR69D1dB1hfXjASjhbpk
 az2HY58mQAZ3bg==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87msbeuy07.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Thu, 15 May 2025 09:35:52 +0200")
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
 <87msbeuy07.fsf@HIDDEN>
User-Agent: mu4e 1.12.9; emacs 29.4
X-URL: https://people.bordeaux.inria.fr/lcourtes/
X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4  0CFB 090B 1199 3D9A EBB5
X-OS: x86_64-pc-linux-gnu
X-Revolutionary-Date: Sextidi 26 =?utf-8?Q?Flor=C3=A9al?= an 233 de la
 =?utf-8?Q?R=C3=A9volution=2C?= jour du Fusain
Date: Thu, 15 May 2025 10:20:27 +0200
Message-ID: <87ecwqxp2s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Hi,

Rutherther <rutherther@HIDDEN> writes:

> I think it would at least be good if there was a script to do what
> guix-ownership does, but force it without the /gnu/store ownership
> check, to make it easier for users to recover. Maybe even an optional arg=
ument to
> guix-ownership, where you could `sudo herd start guix-ownership 1` and
> that would force the chown'ing?

There=E2=80=99s +/- a script in the manual (info "(guix) Build Environment
Setup").

>>
>> I don=E2=80=99t see any way around that but perhaps we should warn about=
 it more
>> clearly?
>
> That would definitely be great, I think you can easily oversee that the
> service has started. Now I am not sure if one-shot services are started
> after change when you reconfigure, if they are, I think it's going to be
> a common issue - people reconfigure & reboot! Meaning they will usually
> stop the service, or am I mistaken here?

The one-shot service is restarted upon reconfigure, but one also has to
restart guix-daemon in this case.

>> Doing /gnu/store last is a good idea because it reduces the window
>> during which the inconsistent state could go undetected.
>
> I think it completely removes it. Or why do you think not?

Yes, you=E2=80=99re right, as long as /gnu/store itself is done last.

Ludo=E2=80=99.
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 15 May 2025 07:36:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 03:36:08 2025
Received: from localhost ([127.0.0.1]:50558 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFT8R-0002mH-Jc
	for submit <at> debbugs.gnu.org; Thu, 15 May 2025 03:36:08 -0400
Received: from ditigal.xyz ([78.46.201.50]:38632 helo=mail.ditigal.xyz)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
 id 1uFT8N-0002lh-FB
 for 78355 <at> debbugs.gnu.org; Thu, 15 May 2025 03:36:04 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 8f4ffda0
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); 
 Thu, 15 May 2025 07:35:55 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
To: Ludovic =?utf-8?Q?Court=C3=A8s?= <ludo@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <874ixnyltm.fsf@HIDDEN>
References: <87tt5sjx97.fsf@HIDDEN> <874ixnyltm.fsf@HIDDEN>
Date: Thu, 15 May 2025 09:35:52 +0200
Message-ID: <87msbeuy07.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1747294555; h=from : to : cc
 : subject : in-reply-to : references : date : message-id :
 mime-version : content-type : content-transfer-encoding : from;
 bh=PSQE5fxFU4EW0P4eFXRrTcL74tpCBV6QaRg9M5D8k5w=;
 b=OvA6V7NkQLypnkew9e6UjdQMRNgAxx5quptk669ZzeKcfdZepEjHaSpG8gxSI8GwAR5N6
 Lg3vpWu3Ob2VWuJX4TXGpbNWCzz6uzAMZOaSd5JAZXCp51w9xsCey6ZarvoYwrNTgKSdLD/
 q7hasIYQEFmsoThsdnA1QSSeuUQxZS0=
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  Hi Ben,
 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 [...] 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
 The query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [78.46.201.50 listed in sa-accredit.habeas.com]
 0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
 query to Validity was blocked.  See
 https://knowledge.validity.com/hc/en-us/articles/20961730681243
 for more information.
 [78.46.201.50 listed in bl.score.senderscore.com]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org, Ben Sturmfels <ben@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi Ben, 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 [...] 
 
 Content analysis details:   (2.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  0.0 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
                             The query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [78.46.201.50 listed in sa-accredit.habeas.com]
  0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
                             query to Validity was blocked.  See
                             https://knowledge.validity.com/hc/en-us/articles/20961730681243
                              for more information.
                             [78.46.201.50 listed in bl.score.senderscore.com]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
  1.0 BULK_RE_SUSP_NTLD      Precedence bulk and RE: from a suspicious TLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager


Hi Ben,

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
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?
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?

Hi Ludo,

Ludovic Court=C3=A8s <ludo@HIDDEN> writes:

> Hi,
>
> Rutherther <rutherther@HIDDEN> writes:
>
>> There are reports from users with inconsistencies in ownership, it seems=
 that at
>> least /var/guix is sometimes left with wrong owner, but maybe even parts
>> of the store? I cannot verify that.
>
> Would be nice to get their reports here, otherwise we=E2=80=99re left
> speculating.

I am afraid we will be left speculating either way, that's why I chose
this approach. That is because none of the users I know of took time to
debug it and just fixed it. CCing Ben Sturmfels who
encountered it (see
https://lists.gnu.org/archive/html/help-guix/2025-05/msg00052.html).
For the other user I know of, I don't know their e-mail.

Note that on IRC I recommended the user to chown $USER /gnu/store
($USER just cause it's easiest, any non-root user would be fine) and
herd start guix-ownership and that fixed the issue. So the service
definitely is doing its job. See here https://logs.guix.gnu.org/guix/2025-0=
5-10.log#171215

>
>> The guix-ownership service checks /gnu/store ownership to check if the
>> whole store and all files important for the daemon (/etc/guix,
>> /var/guix) are owned by the appropriate user.
>>
>> If the folder isn't owned by appropriate user, it moves to those steps:
>> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
>> itself as last step
>> 2. Fix /var/guix
>> 3. Fix /etc/guix
>> 4. Fix /var/log/guix
>>
>> So from those laid out steps it should be obvious that if guix-ownership
>> service somehow stops between steps 1 and 2, it will never recover
>> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
>> change owner as last.
>
> Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99=
 is not
> interrupted during its work; manual intervention is needed to repair
> things if it is interrupted.

I think it would at least be good if there was a script to do what
guix-ownership does, but force it without the /gnu/store ownership
check, to make it easier for users to recover. Maybe even an optional argum=
ent to
guix-ownership, where you could `sudo herd start guix-ownership 1` and
that would force the chown'ing?

>
> I don=E2=80=99t see any way around that but perhaps we should warn about =
it more
> clearly?

That would definitely be great, I think you can easily oversee that the
service has started. Now I am not sure if one-shot services are started
after change when you reconfigure, if they are, I think it's going to be
a common issue - people reconfigure & reboot! Meaning they will usually
stop the service, or am I mistaken here?

>
>> On the other hand it feels much of a coincidence users would be
>> consistently hitting reboots between those steps. So maybe I am
>> overlooking another thing. I checked the file-system-fold, it goes to
>> /gnu/store as last, so that would mean putting step 1 after 4 should fix
>> that. Still, maybe only /gnu/store itself should be skipped instead of m=
oving
>> the step, and done as last, step 5 to ensure it's fine even if
>> file-system-fold somehow changed the ordering? Not sure how exactly it
>> should behave in that regard.
>
> Doing /gnu/store last is a good idea because it reduces the window
> during which the inconsistent state could go undetected.

I think it completely removes it. Or why do you think not?
If it really doesn't I think it would be good if we came up with an
approach that would remove this window. The best way to achieve no
inconsistence-window would be to just check all of the permissions, but
that's probably an overkill.
For example creating a 'stamp'
somewhere that says it was done, at the end, and checking if that stamp
file matches what we expect.

>
> Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but n=
ot
> before next week.
>
> Thanks,
> Ludo=E2=80=99.

Thanks
Rutherther
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at 78355 <at> debbugs.gnu.org:


Received: (at 78355) by debbugs.gnu.org; 14 May 2025 21:51:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed May 14 17:51:38 2025
Received: from localhost ([127.0.0.1]:46795 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uFK0n-0005nZ-Hw
	for submit <at> debbugs.gnu.org; Wed, 14 May 2025 17:51:38 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47084)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <ludo@HIDDEN>) id 1uFK0G-0005iF-AO
 for 78355 <at> debbugs.gnu.org; Wed, 14 May 2025 17:51:04 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ludo@HIDDEN>)
 id 1uFK0A-0007w6-QP; Wed, 14 May 2025 17:50:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
 From; bh=U/ASJiUfRTV28p5v/XXtxNjU6KAOpcKv4473gF8ftwQ=; b=OG/zT7paD5NdVB+2d4gy
 2BGXvZpO+Qg358QDSihWrnc8WgCEAMcKbGZSugXQnFaHH7Ewfd11ET29L3sw/blLcCplctpgKrAI3
 Q+Pi4mUvNYcGmn8e77BCSs6mSW7jGRSG1oth88efkzevS+EReJsIhQy1UiKzvhl2EuT31b/SvEcmb
 MqVAeZb2LIXDFOUDsFfU6A8skXqnlY5NDlo3Ciz3HhiqG7cWkO+aHDO/VpcI8u6f3a8DkVIFo6Jc2
 JD8RpcpIo1469ykS6Vkr8Cgkb8TEVEhiEsKVwwUv0jx4BskQPYVGcIIST+jEzIIThJ+Kp4dB1JOHB
 PKbypA0JgASNDg==;
From: =?utf-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>
To: Rutherther <rutherther@HIDDEN>
Subject: Re: bug#78355: guix-ownership inconsistent state
In-Reply-To: <87tt5sjx97.fsf@HIDDEN> (rutherther@HIDDEN's message of
 "Sat, 10 May 2025 17:33:56 +0200")
References: <87tt5sjx97.fsf@HIDDEN>
Date: Wed, 14 May 2025 22:33:09 +0200
Message-ID: <874ixnyltm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.3 (/)
X-Debbugs-Envelope-To: 78355
Cc: 78355 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Hi,

Rutherther <rutherther@HIDDEN> writes:

> There are reports from users with inconsistencies in ownership, it seems =
that at
> least /var/guix is sometimes left with wrong owner, but maybe even parts
> of the store? I cannot verify that.

Would be nice to get their reports here, otherwise we=E2=80=99re left
speculating.

> The guix-ownership service checks /gnu/store ownership to check if the
> whole store and all files important for the daemon (/etc/guix,
> /var/guix) are owned by the appropriate user.
>
> If the folder isn't owned by appropriate user, it moves to those steps:
> 1. Fix permissions in /gnu/store - first under it, then /gnu/store
> itself as last step
> 2. Fix /var/guix
> 3. Fix /etc/guix
> 4. Fix /var/log/guix
>
> So from those laid out steps it should be obvious that if guix-ownership
> service somehow stops between steps 1 and 2, it will never recover
> ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
> change owner as last.

Well, the fundamental assumption is that =E2=80=98guix-ownership=E2=80=99 i=
s not
interrupted during its work; manual intervention is needed to repair
things if it is interrupted.

I don=E2=80=99t see any way around that but perhaps we should warn about it=
 more
clearly?

> On the other hand it feels much of a coincidence users would be
> consistently hitting reboots between those steps. So maybe I am
> overlooking another thing. I checked the file-system-fold, it goes to
> /gnu/store as last, so that would mean putting step 1 after 4 should fix
> that. Still, maybe only /gnu/store itself should be skipped instead of mo=
ving
> the step, and done as last, step 5 to ensure it's fine even if
> file-system-fold somehow changed the ordering? Not sure how exactly it
> should behave in that regard.

Doing /gnu/store last is a good idea because it reduces the window
during which the inconsistent state could go undetected.

Feel free to propose a patch; otherwise I=E2=80=99ll give it a try, but not
before next week.

Thanks,
Ludo=E2=80=99.
Information forwarded to bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 10 May 2025 15:34:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 10 11:34:23 2025
Received: from localhost ([127.0.0.1]:48265 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uDmDX-00005u-2m
	for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:23 -0400
Received: from lists.gnu.org ([2001:470:142::17]:46910)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <rutherther@HIDDEN>)
 id 1uDmDU-00005K-Hx
 for submit <at> debbugs.gnu.org; Sat, 10 May 2025 11:34:21 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
 id 1uDmDG-000572-7K
 for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:07 -0400
Received: from ditigal.xyz ([2a01:4f8:1c1b:6a1c::] helo=mail.ditigal.xyz)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
 (Exim 4.90_1) (envelope-from <rutherther@HIDDEN>)
 id 1uDmDD-0003DM-CF
 for bug-guix@HIDDEN; Sat, 10 May 2025 11:34:05 -0400
Received: by cerebrum (OpenSMTPD) with ESMTPSA id 66d8be0f
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for <bug-guix@HIDDEN>;
 Sat, 10 May 2025 15:33:58 +0000 (UTC)
From: Rutherther <rutherther@HIDDEN>
To: bug-guix@HIDDEN
Subject: guix-ownership inconsistent state
X-Debbugs-Cc: ludo@HIDDEN
Date: Sat, 10 May 2025 17:33:56 +0200
Message-ID: <87tt5sjx97.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ditigal.xyz;
 i=@ditigal.xyz; q=dns/txt; s=20240917; t=1746891238; h=from : to :
 subject : date : message-id : mime-version : content-type : from;
 bh=lSlDEuauDctdro3L+96w0wMzsR2FNiLn9f7JIB0Prv0=;
 b=U9xGN6LZ3HryBxVYDA8jTv6sDpYiVaH4iurvZw8NUPLRTZYNUmKd4WRnfx26n9tzFQJ8h
 nLzfhXwCPbqqMSLquuQ095jCLC3gGAwdmC70DjVojSfznvxAzz0dmYfDQGgg+rIO/XRvGtw
 Gr8J8f/yJVSW8HxsDsWoEzBGHJtKTeQ=
Received-SPF: pass client-ip=2a01:4f8:1c1b:6a1c::;
 envelope-from=rutherther@HIDDEN; helo=mail.ditigal.xyz
X-Spam_score_int: 4
X-Spam_score: 0.4
X-Spam_bar: /
X-Spam_report: (0.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499,
 FROM_SUSPICIOUS_NTLD_FP=0.001, PDS_OTHER_BAD_TLD=1.999, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 3.4 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: There are reports from users with inconsistencies in
 ownership, 
 it seems that at least /var/guix is sometimes left with wrong owner, but
 maybe even parts of the store? I cannot verify that. The guix-ownership
 service
 checks /gnu/store ownership to check if the whole store and all files
 important
 for the daemon (/etc/guix, /var/guix) are owned by the appropriate user. 
 Content analysis details:   (3.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
 [URI: ditigal.xyz (xyz)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=rutherther%40ditigal.xyz; ip=2001%3A470%3A142%3A%3A17; r=debbugs.gnu.org]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
 0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
 0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.4 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  There are reports from users with inconsistencies in ownership,
    it seems that at least /var/guix is sometimes left with wrong owner, but
   maybe even parts of the store? I cannot verify that. The guix-ownership service
    checks /gnu/store ownership to check if the whole store and all files important
    for the daemon (/etc/guix, /var/guix) are owned by the appropriate user. 
 
 Content analysis details:   (2.4 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [2001:470:142:0:0:0:0:17 listed in]
                             [list.dnswl.org]
  2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                             [URI: ditigal.xyz (xyz)]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
  0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;id=rutherther%40ditigal.xyz;ip=2001%3A470%3A142%3A%3A17;r=debbugs.gnu.org]
  0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager


There are reports from users with inconsistencies in ownership, it seems that at
least /var/guix is sometimes left with wrong owner, but maybe even parts
of the store? I cannot verify that.

The guix-ownership service checks /gnu/store ownership to check if the
whole store and all files important for the daemon (/etc/guix,
/var/guix) are owned by the appropriate user.

If the folder isn't owned by appropriate user, it moves to those steps:
1. Fix permissions in /gnu/store - first under it, then /gnu/store
itself as last step
2. Fix /var/guix
3. Fix /etc/guix
4. Fix /var/log/guix

So from those laid out steps it should be obvious that if guix-ownership
service somehow stops between steps 1 and 2, it will never recover
ownerships of /var/guix, /etc/guix and /var/log/guix. /gnu/store should
change owner as last.

On the other hand it feels much of a coincidence users would be
consistently hitting reboots between those steps. So maybe I am
overlooking another thing. I checked the file-system-fold, it goes to
/gnu/store as last, so that would mean putting step 1 after 4 should fix
that. Still, maybe only /gnu/store itself should be skipped instead of moving
the step, and done as last, step 5 to ensure it's fine even if
file-system-fold somehow changed the ordering? Not sure how exactly it
should behave in that regard.

Regards
Rutherther
Acknowledgement sent to Rutherther <rutherther@HIDDEN>:
New bug report received and forwarded. Copy sent to ludo@HIDDEN, bug-guix@HIDDEN. Full text available.
Report forwarded to ludo@HIDDEN, bug-guix@HIDDEN:
bug#78355; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Tue, 1 Jul 2025 22:45:03 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.