Sender | Message | Time |
---|---|---|
15 Oct 2024 | ||
raboof | In reply to @katexochen:matrix.orginterestingly this returns no results on my NixOS installation (which doesn't use store optimization). Are those files hardlinked by store optimization? | 07:05:06 |
emily | oh, so even Linux users have optimization-based store corruption! | 07:05:14 |
raboof | In reply to @katexochen:matrix.org* 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 |
Paul Meyer (katexochen) | In reply to @raboof:matrix.org The one from above isn't:
| 07:09:42 |
Paul 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 | I get a ton of paths but it's all either .lock files or paths that I attempted to build once but cancelled | 07:15:52 |
atemu12 | You can tell by that the top-level path has an associated .lock file | 07:16:10 |
atemu12 | Does /nix/store/a3b4xpykc7x1gz7d5kvcw40qf0xlqg4n-python3.11-fabric-3.2.2.lock exist? | 07:16:24 |
Paul Meyer (katexochen) | In reply to @atemu12:matrix.orgYes it does | 07:24:34 |
atemu12 | Well then that path is not actually alive | 07:25:01 |
atemu12 | I believe | 07:25:08 |
atemu12 | It never went through normalisation | 07:25:30 |
atemu12 | "Alive" is perhaps the wrong term here. "Not actually realised yet from the perspective of Nix" would probably be more fitting | 07:26:42 |
atemu12 | If you nix-store --verify-path it, Nix should tell you that the path doesn't exist | 07:28:46 |
atemu12 | And indeed if you try to realise such a path, Nix will substitute or build it | 07:31:39 |
dish [Fox/It/She] changed their display name from Pyrox [ It/She/They/Xem ] to dish [Fox/It/She]. | 07:36:18 | |
Paul Meyer (katexochen) | In reply to @katexochen:matrix.org 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:
| 07:53:37 |
Paul Meyer (katexochen) | Not sure where to look next | 07:54:19 |
atemu12 | Look for what exactly? I'm not following. | 07:55:02 |
Paul Meyer (katexochen) | For an explanation how a writable file ended up in a realised derivation/in the image. | 07:59:02 |
Paul 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 |
Paul Meyer (katexochen) | This is what we are trying to debug (from an uki/repart nixos image):
| 08:02:31 |
atemu12 | I see | 08:11:22 |
atemu12 | What's that last line about btw? +-r--r--r-- | 08:11:40 |
atemu12 | Is it actually RW in the image? | 08:11:51 |
Paul Meyer (katexochen) | Last two lines are the diff between the two images (looks a bit confusing without color) | 08:20:16 |
atemu12 | Ahh that makes sense | 08:21:22 |
atemu12 | The path is writeable on the build system though, right? | 08:21:37 |
Paul 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 |
atemu12 | As mentioned before, there have been cases reported before where some system daemons remount /nix/store. I don't have the issue handy but I'm sure you can find it. Make sure you're not running any of those. | 08:32:52 |