!LemuOOvbWqRXodtSsw:nixos.org

NixOS Reproducible Builds

476 Members
Report: https://reproducible.nixos.org Project progress: https://github.com/orgs/NixOS/projects/30102 Servers

Load older messages


SenderMessageTime
15 Oct 2024
@raboof:matrix.orgraboof
In reply to @katexochen:matrix.org

I can reproduce this using nixpkgs-review + remote builder with a commit that doesn't build. For example, running nixpkgs-review rev HEAD on https://github.com/katexochen/nixpkgs/tree/repro/azure-cli/2-65 will lead to the following on the configured remote builder:

$ ls -la /nix/store/*azure-cli* | grep nixbld
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root      nixbld    6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld  6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
right, so those files can have write permissions when they've been written to the store but then the build fails before the files were 'canonicalised'. If the build fails before completing then the derivation should not have been added to the store db, and thus should not be used by any other derivation yet, though, right? so that doesn't seem like it explains the problem you and Moritz Sanft saw yet?
07:02:19
@raboof:matrix.orgraboof
In reply to @katexochen:matrix.org
Grepping nix store for writable files returns a ton, both on my local system as well as on my remote builder:
find /nix/store -type f -perm -u+w ! -perm -g+w ! -perm -o+w
Those have also modified time stamps. 🤔
interestingly this returns no results on my NixOS installation (which doesn't use store optimization). Are those files hardlinked by store optimization?
07:05:06
@emilazy:matrix.orgemilyoh, so even Linux users have optimization-based store corruption!07:05:14
@raboof:matrix.orgraboof
In reply to @katexochen:matrix.org

I can reproduce this using nixpkgs-review + remote builder with a commit that doesn't build. For example, running nixpkgs-review rev HEAD on https://github.com/katexochen/nixpkgs/tree/repro/azure-cli/2-65 will lead to the following on the configured remote builder:

$ ls -la /nix/store/*azure-cli* | grep nixbld
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root      nixbld    6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld  6669116 Oct 14 18:01 ..
drwxrwxr-t 1 root nixbld 6669116 Oct 14 18:01 ..
* right, so those files can have write permissions when they've been written to the store but then the build fails before the files were 'canonicalised'? If the build fails before completing then the derivation should not have been added to the store db, and thus should not be used by any other derivation yet, though, right? so that doesn't seem like it explains the problem you and Moritz Sanft saw yet?
07:06:07
@katexochen:matrix.orgPaul Meyer (katexochen)
In reply to @raboof:matrix.org
interestingly this returns no results on my NixOS installation (which doesn't use store optimization). Are those files hardlinked by store optimization?

The one from above isn't:

$ find / -inum 189116731 2>/dev/null
/nix/store/a3b4xpykc7x1gz7d5kvcw40qf0xlqg4n-python3.11-fabric-3.2.2/lib/python3.11/site-packages/fabric-3.2.2.dist-info/top_level.txt
07:09:42
@katexochen:matrix.orgPaul Meyer (katexochen)No explanation how the writable file ended up in the image, no. I'd have to look deeper into the hardlink optimization. Maybe there is a race with creating the link under /nix/store/.links and the build failing? Then any file from a successful derivation could be hardlinked against a writable file.07:15:35
@atemu12:matrix.orgAtemuI get a ton of paths but it's all either .lock files or paths that I attempted to build once but cancelled07:15:52
@atemu12:matrix.orgAtemuYou can tell by that the top-level path has an associated .lock file07:16:10
@atemu12:matrix.orgAtemu Does /nix/store/a3b4xpykc7x1gz7d5kvcw40qf0xlqg4n-python3.11-fabric-3.2.2.lock exist? 07:16:24
@katexochen:matrix.orgPaul Meyer (katexochen)
In reply to @atemu12:matrix.org
Does /nix/store/a3b4xpykc7x1gz7d5kvcw40qf0xlqg4n-python3.11-fabric-3.2.2.lock exist?
Yes it does
07:24:34
@atemu12:matrix.orgAtemuWell then that path is not actually alive07:25:01
@atemu12:matrix.orgAtemuI believe07:25:08
@atemu12:matrix.orgAtemuIt never went through normalisation07:25:30
@atemu12:matrix.orgAtemu"Alive" is perhaps the wrong term here. "Not actually realised yet from the perspective of Nix" would probably be more fitting07:26:42
@atemu12:matrix.orgAtemu If you nix-store --verify-path it, Nix should tell you that the path doesn't exist 07:28:46
@atemu12:matrix.orgAtemuAnd indeed if you try to realise such a path, Nix will substitute or build it07:31:39
@pyrox:pyrox.devdish [Fox/It/She] changed their display name from Pyrox [ It/She/They/Xem ] to dish [Fox/It/She].07:36:18
@katexochen:matrix.orgPaul Meyer (katexochen)
In reply to @katexochen:matrix.org
No explanation how the writable file ended up in the image, no. I'd have to look deeper into the hardlink optimization. Maybe there is a race with creating the link under /nix/store/.links and the build failing? Then any file from a successful derivation could be hardlinked against a writable file.

I searched for writable files that are hardlinked into a derivation that doesn't have a .lock, and it seems like there is none, so my theory doesn't work out:

#!/usr/bin/env bash

while read -r file; do
    links=$(stat -c %h "$file")
    if [[ "$links" -le 1 ]]; then
        echo "No links for $file"
        continue
    fi
    inode=$(stat -c %i "$file")
    while read -r linkedFile; do
        if [[ "$linkedFile" == "$file" ]]; then
            continue
        fi
        linkedDrv=$(echo "$linkedFile" | cut -d'/' -f1-4)
        if [[ -e "${linkedDrv}.lock" ]]; then
            echo "Lock file exists for $linkedDrv"
            continue
        fi
        echo "$linkedFile"
    done < <(find /nix/store -type f -inum "$inode" 2>/dev/null)
done < <(find /nix/store -type f -perm -u+w ! -perm -g+w ! -perm -o+w 2>/dev/null)
07:53:37
@katexochen:matrix.orgPaul Meyer (katexochen)Not sure where to look next07:54:19
@atemu12:matrix.orgAtemuLook for what exactly? I'm not following.07:55:02
@katexochen:matrix.orgPaul Meyer (katexochen)For an explanation how a writable file ended up in a realised derivation/in the image.07:59:02
@katexochen:matrix.orgPaul Meyer (katexochen) * For an explanation how a writable file ended up in a realised derivation/in the image (on one system, and not on another)08:00:36
@katexochen:matrix.orgPaul Meyer (katexochen)

This is what we are trying to debug (from an uki/repart nixos image):

❯ diffoscope f*/initrd_0
--- f-btrfs/initrd_0
+++ f-ext/initrd_0
│┄ comprises of 1 embedded members
├── .cpio file embedded at offset 0
│ ├── file list
│ │ @@ -981,15 +981,15 @@
│ │  -r--r--r--   0        0        0     2274 1970-01-01 00:00:01.000000 ./nix/store/frngrlq2xa2szv4bx91jkymv0dy9akmx-kbd-2.6.4/share/keymaps/sun/sunt5-uk.map.gz
│ │  -r--r--r--   0        0        0     4926 1970-01-01 00:00:01.000000 ./nix/store/frngrlq2xa2szv4bx91jkymv0dy9akmx-kbd-2.6.4/share/keymaps/sun/sunt5-us-cz.map.gz
│ │  -r--r--r--   0        0        0     1706 1970-01-01 00:00:01.000000 ./nix/store/frngrlq2xa2szv4bx91jkymv0dy9akmx-kbd-2.6.4/share/keymaps/sun/sunt6-uk.map.gz
│ │  drwxr-xr-x   0        0        0        0 1970-01-01 00:00:01.000000 ./nix/store/fvsswlqh6pc2f5x9qvahm4qbjgjlp86j-linux-pam-1.6.1/
│ │  drwxr-xr-x   0        0        0        0 1970-01-01 00:00:01.000000 ./nix/store/fvsswlqh6pc2f5x9qvahm4qbjgjlp86j-linux-pam-1.6.1/lib/
│ │  lrwxrwxrwx   0        0        0       16 1970-01-01 00:00:01.000000 ./nix/store/fvsswlqh6pc2f5x9qvahm4qbjgjlp86j-linux-pam-1.6.1/lib/libpam.so.0 -> libpam.so.0.85.1
│ │  -rwxrwxrwx   0        0        0    67608 1970-01-01 00:00:01.000000 ./nix/store/fvsswlqh6pc2f5x9qvahm4qbjgjlp86j-linux-pam-1.6.1/lib/libpam.so.0.85.1
│ │ --rw-r--r--   0        0        0        0 1970-01-01 00:00:01.000000 ./nix/store/gq7vys7yw9gsrrk5jzp4qx1glc15hwlp-initrd-kmod-blacklist-ubuntu
│ │ +-r--r--r--   0        0        0        0 1970-01-01 00:00:01.000000 ./nix/store/gq7vys7yw9gsrrk5jzp4qx1glc15hwlp-initrd-kmod-blacklist-ubuntu
08:02:31
@atemu12:matrix.orgAtemuI see08:11:22
@atemu12:matrix.orgAtemu What's that last line about btw? +-r--r--r-- 08:11:40
@atemu12:matrix.orgAtemuIs it actually RW in the image?08:11:51
@katexochen:matrix.orgPaul Meyer (katexochen)Last two lines are the diff between the two images (looks a bit confusing without color) 08:20:16
@atemu12:matrix.orgAtemuAhh that makes sense08:21:22
@atemu12:matrix.orgAtemuThe path is writeable on the build system though, right?08:21:37
@katexochen:matrix.orgPaul Meyer (katexochen)Yes, I'm pretty sure it was writable on my local system. But I cleaned up that path and couldn't find a way to reproduce that yet.08:29:42

Show newer messages


Back to Room ListRoom Version: 6