Install fails on a freshly installed Fedora 42

chklauser commented

2025-10-10 20:24:39 +00:00

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|

👍 2

gmacon commented

2025-10-14 19:16:20 +00:00

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.

gmacon commented

2025-10-15 01:19:45 +00:00

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.

lix-bot commented

2025-10-15 02:11:08 +00:00

Member

This issue was mentioned on Gerrit on the following CLs:

commit message in cl/4366 ("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")

gmacon commented

2025-10-15 02:16:41 +00:00

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.

kfearsoff commented

2025-12-10 20:08:34 +00:00

Member

Please don't feel silly! You have done a very great job debugging this and digging through the code on your own. This is a job well done, and I won't let you beat up yourself over it!

We have been a bit messy with it, but the main branch contains this backport you've noticed. Once we release it to the website, I'll close this issue as resolved; in the meantime, you could compile lix-installer from the main branch and use it as-is.

Please don't feel silly! You have done a very great job debugging this and digging through the code on your own. This is a job well done, and I won't let you beat up yourself over it! We have been a bit messy with it, but the `main` branch contains this backport you've noticed. Once we release it to the website, I'll close this issue as resolved; in the meantime, you could compile lix-installer from the main branch and use it as-is.

kfearsoff added the

Status/Fixed On Main

label

2025-12-10 20:08:50 +00:00

kfearsoff referenced this issue

2025-12-10 20:29:43 +00:00

Error installing under Amazon Linux 2023 #49

Rows
Columns

Install fails on a freshly installed Fedora 42 #59

Error

Metadata