GNU bug report logs - #77548
multiple packages fail check phases due to read-only file system root

Previous Next

Package: guix;

Reported by: keinflue <keinflue <at> posteo.net>

Date: Sat, 5 Apr 2025 12:20:02 UTC

Severity: important

Merged with 77570

Done: Ludovic Courtès <ludo <at> chbouib.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77548 in the body.
You can then email your comments to 77548 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#77548; Package guix. (Sat, 05 Apr 2025 12:20:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to keinflue <keinflue <at> posteo.net>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sat, 05 Apr 2025 12:20:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: keinflue <keinflue <at> posteo.net>
To: bug-guix <at> gnu.org
Cc: Ludo <ludo <at> gnu.org>
Subject: multiple packages fail check phases due to read-only file system root
Date: Sat, 05 Apr 2025 09:41:37 +0000
Hi everyone,

probably since commit 40f69b586a several packages including shepherd, go 
(bootstrap), ruby and scons fail their check phases.

They all fail with EROFS "read-only file system" errors. The pattern 
seems to be that these packages attempt to remove non-existent files 
under /, e.g. /does-not-exist for the pid-file.sh test case in shepherd. 
They expect the unlink/unlinkat syscall to fail with ENOENT, but the 
linux kernel produces EROFS if the file system is read-only, even if the 
file doesn't exist, and glibc does not modify this behavior for the C 
library functions.

On one hand this is probably not POSIX-conforming behavior of 
linux/glibc and there was a patch rectifying this in version 3.2 (commit 
e6bc45d65d) of the kernel, but that regressed with 3.6 (commit 
c30dabfe5d) from what I can tell.

On the the other hand, I do not think that attempting to delete 
arbitrary files on the file system root with the assumption that it will 
fail in specific ways is a good idea either and that the files do not 
actually exist is not a good idea either.

Not sure what the correct approach to fixing this would be.




Severity set to 'important' from 'normal' Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 08 Apr 2025 10:17:02 GMT) Full text and rfc822 format available.

Merged 77548 77570. Request was from Ludovic Courtès <ludo <at> gnu.org> to control <at> debbugs.gnu.org. (Tue, 08 Apr 2025 10:17:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 13 May 2025 11:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 35 days ago.

Previous Next


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