Install fails on a freshly installed Fedora 42 #59

Open
opened 2025-10-10 20:24:39 +00:00 by chklauser · 4 comments

Error

Error: 
   0: Install failure
   1: Error executing action
   2: Action `configure_nix` errored
   3: Action `setup_default_profile` errored
   4: Failed to execute command with status 127 `HOME="/root" "/nix/store/c47cym23n56kkss8z0ican8nynkf6cwk-lix-2.93.0/bin/nix-store" "--load-db"`, stdout: 
      stderr: /nix/store/c47cym23n56kkss8z0ican8nynkf6cwk-lix-2.93.0/bin/nix-store: error while loading shared libraries: libaws-c-common.so.1: cannot open shared object file: No such file or directory


Metadata

key value
version 0.17.1
os linux
arch x86_64
## Error ``` Error: 0: Install failure 1: Error executing action 2: Action `configure_nix` errored 3: Action `setup_default_profile` errored 4: Failed to execute command with status 127 `HOME="/root" "/nix/store/c47cym23n56kkss8z0ican8nynkf6cwk-lix-2.93.0/bin/nix-store" "--load-db"`, stdout: stderr: /nix/store/c47cym23n56kkss8z0ican8nynkf6cwk-lix-2.93.0/bin/nix-store: error while loading shared libraries: libaws-c-common.so.1: cannot open shared object file: No such file or directory ``` ## Metadata |key|value| |--|--| |**version**|0.17.1| |**os**|linux| |**arch**|x86_64|

I poked at this a little bit and found out that /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 is a symbolic link to itself:

$ stat /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27
  File: /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 -> /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27
  Size: 63        	Blocks: 0          IO Block: 4096   symbolic link
Device: fd00h/64768d	Inode: 537926143   Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:default_t:s0
Access: 2025-10-14 15:12:33.934077371 -0400
Modify: 2025-10-14 15:12:19.743199575 -0400
Change: 2025-10-14 15:12:19.851198645 -0400
 Birth: 2025-10-14 15:12:19.743199575 -0400

Edit:

The lix-2.93.0-x86_64-linux.tar.xz archive (SHA256 = f8847c5ee7e44ac2239652f92fe173175226df9b3db08710e5a2d943cfa5286a) looks correct to me.

Edit again:

I re-extracted that directory from the tarball, placed it in /nix/store, and then ran the install again, and it succeeded the second time.

I poked at this a little bit and found out that `/nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27` is a symbolic link to itself: ``` $ stat /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 File: /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 -> /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 Size: 63 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 537926143 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Context: unconfined_u:object_r:default_t:s0 Access: 2025-10-14 15:12:33.934077371 -0400 Modify: 2025-10-14 15:12:19.743199575 -0400 Change: 2025-10-14 15:12:19.851198645 -0400 Birth: 2025-10-14 15:12:19.743199575 -0400 ``` Edit: The `lix-2.93.0-x86_64-linux.tar.xz` archive (SHA256 = f8847c5ee7e44ac2239652f92fe173175226df9b3db08710e5a2d943cfa5286a) looks correct to me. Edit again: I re-extracted that directory from the tarball, placed it in `/nix/store`, and then ran the install again, and it succeeded the second time.

Having now looked at the code, I have a hypothesis about the reason for this failure, but it's weak because there's something I can't explain yet.

The MoveUnpackedNix action loops over the source store:

while let Some(entry) = src_store_listing
.next_entry()
.await
.map_err(|e| ActionErrorKind::ReadDir(src_store.clone(), e))
.map_err(Self::error)?
{

and then modifies that source directory while looping:

tokio::fs::symlink(&entry_dest, entry.path())
.await
.map_err(|e| ActionErrorKind::Symlink(entry_dest.to_owned(), entry.path(), e))
.map_err(Self::error)?;

I think that might be producing a sort of iterator invalidation error causing it to process the just-added symlink a second time, which would produce the symptom of a symlink pointing to itself in /nix/store.

The reason I'm uncertain is that I wouldn't expect this error to be deterministic, but both myself and @chklauser saw this on the same derivation, and I tried the install (from scratch) three times and it happened every time.

Having now looked at the code, I have a hypothesis about the reason for this failure, but it's weak because there's something I can't explain yet. The `MoveUnpackedNix` action loops over the source store: https://git.lix.systems/lix-project/lix-installer/src/commit/e4048682396999c11069f99f9b323f1d4a333bbc/src/action/base/move_unpacked_nix.rs#L87-L92 and then modifies that source directory while looping: https://git.lix.systems/lix-project/lix-installer/src/commit/e4048682396999c11069f99f9b323f1d4a333bbc/src/action/base/move_unpacked_nix.rs#L135-L138 I think that might be producing a sort of iterator invalidation error causing it to process the just-added symlink a second time, which would produce the symptom of a symlink pointing to itself in `/nix/store`. The reason I'm uncertain is that I wouldn't expect this error to be deterministic, but both myself and @chklauser saw this on the same derivation, and I tried the install (from scratch) three times and it happened every time.
Member

This issue was mentioned on Gerrit on the following CLs:

  • commit message in cl/4366 ("fix: avoid recursive symlinks")
<!-- GERRIT_LINKBOT: {"cls": [{"backlink": "https://gerrit.lix.systems/c/lix-installer/+/4366", "number": 4366, "kind": "commit message"}], "cl_meta": {"4366": {"change_title": "fix: avoid recursive symlinks"}}} --> This issue was mentioned on Gerrit on the following CLs: * commit message in [cl/4366](https://gerrit.lix.systems/c/lix-installer/+/4366) ("fix: avoid recursive symlinks")

I feel a little silly now. I wrote a fix based on my hypothesis, then opened a CL for it, and Gerrit helpfully tells me that it conflicts with cl/3352 fixing #49, which is the same root cause as this issue.

I feel a little silly now. I wrote a fix based on my hypothesis, then opened a CL for it, and Gerrit helpfully tells me that it conflicts with [cl/3352](https://gerrit.lix.systems/c/lix-installer/+/3352) fixing #49, which is the same root cause as this issue.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lix-project/lix-installer#59
No description provided.