error while loading shared libraries: libaws-c-common.so.1

aureliaimmortalia commented

2025-05-23 22:01:51 +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|

aureliaimmortalia commented

2025-05-23 22:13:15 +00:00

Author

Received this error message on a fresh Fedora Server 42 install. FWIW, the disk partition layout was customized during install and is as follows:

NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda             8:0    0 232.9G  0 disk
├─sda1          8:1    0   600M  0 part /boot/efi
├─sda2          8:2    0     1G  0 part /boot
└─sda3          8:3    0 231.3G  0 part
  ├─root-root 252:0    0    30G  0 lvm  /
  ├─root-nix  252:1    0 101.3G  0 lvm  /nix
  ├─root-home 252:2    0    50G  0 lvm  /home
  └─root-var  252:3    0    50G  0 lvm  /var
zram0         251:0    0     8G  0 disk [SWAP]

In an effort to resolve the issue, the aws-c-common-devel package was installed but the error message persists.

Received this error message on a fresh Fedora Server 42 install. FWIW, the disk partition layout was customized during install and is as follows: ``` NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 232.9G 0 disk ├─sda1 8:1 0 600M 0 part /boot/efi ├─sda2 8:2 0 1G 0 part /boot └─sda3 8:3 0 231.3G 0 part ├─root-root 252:0 0 30G 0 lvm / ├─root-nix 252:1 0 101.3G 0 lvm /nix ├─root-home 252:2 0 50G 0 lvm /home └─root-var 252:3 0 50G 0 lvm /var zram0 251:0 0 8G 0 disk [SWAP] ``` In an effort to resolve the issue, the `aws-c-common-devel` package was installed but the error message persists.

aureliaimmortalia changed title from ~~<autogenerated-issue>~~ to error while loading shared libraries: libaws-c-common.so.1

2025-05-23 22:14:13 +00:00

lukaslangrock commented

2025-06-21 15:46:24 +00:00

Experiencing the same problem on RHEL 10 (Workstation) with 1:1 error message.

NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme3n1                                       259:4    0   1,8T  0 disk  
├─nvme3n1p1                                   259:5    0   600M  0 part  /boot/efi
├─nvme3n1p2                                   259:6    0     1G  0 part  /boot
└─nvme3n1p3                                   259:7    0   1,8T  0 part  
  └─luks-483019c3-4149-45d7-85b7-f94f8385c435 253:0    0   1,8T  0 crypt 
    └─rhel_sys-root                           253:1    0   1,8T  0 lvm   /
nvme0n1                                       259:8    0   1,8T  0 disk  
└─nvme0n1p1                                   259:9    0   1,8T  0 part  
  └─luks-8affcf4f-30d8-4249-b0c2-fc47b4877b03 253:2    0   1,8T  0 crypt 
    └─rhel_fs-home                            253:4    0   3,6T  0 lvm   /home
nvme2n1                                       259:10   0   1,8T  0 disk  
└─nvme2n1p1                                   259:11   0   1,8T  0 part  
  └─luks-983baa7a-d6c2-4b50-9f36-31aa226dcaf3 253:3    0   1,8T  0 crypt 
    └─rhel_fs-home                            253:4    0   3,6T  0 lvm   /home

, aws-c-common-devel also didn't help, but ldconfig -p shows the library is in fact installed:

libaws-c-common.so.1 (libc6,x86-64) => /lib64/libaws-c-common.so.1

Experiencing the same problem on RHEL 10 (Workstation) with 1:1 error message. ``` NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme3n1 259:4 0 1,8T 0 disk ├─nvme3n1p1 259:5 0 600M 0 part /boot/efi ├─nvme3n1p2 259:6 0 1G 0 part /boot └─nvme3n1p3 259:7 0 1,8T 0 part └─luks-483019c3-4149-45d7-85b7-f94f8385c435 253:0 0 1,8T 0 crypt └─rhel_sys-root 253:1 0 1,8T 0 lvm / nvme0n1 259:8 0 1,8T 0 disk └─nvme0n1p1 259:9 0 1,8T 0 part └─luks-8affcf4f-30d8-4249-b0c2-fc47b4877b03 253:2 0 1,8T 0 crypt └─rhel_fs-home 253:4 0 3,6T 0 lvm /home nvme2n1 259:10 0 1,8T 0 disk └─nvme2n1p1 259:11 0 1,8T 0 part └─luks-983baa7a-d6c2-4b50-9f36-31aa226dcaf3 253:3 0 1,8T 0 crypt └─rhel_fs-home 253:4 0 3,6T 0 lvm /home ``` , `aws-c-common-devel` also didn't help, but `ldconfig -p` shows the library is in fact installed: ``` libaws-c-common.so.1 (libc6,x86-64) => /lib64/libaws-c-common.so.1 ```

jade commented

2025-06-22 02:54:51 +00:00

Owner

Uhhhhhhhhh. That looks like we have RPATH being busted, as it should never be actually using system libraries and is supposed to provide its own. Needs further investigation I think.

Uhhhhhhhhh. That looks like we have RPATH being busted, as it should never be actually *using* system libraries and is supposed to provide its own. Needs further investigation I think.

sohamg commented

2025-08-12 17:36:32 +00:00

Hey, Just hit this right now on Centos Stream 10. I tried installing some aws libs from dnf but that didnt seem to help. If I were to guess its somehow not including this lib in the closure for lix when installing. Not including logs as they are the same as above.

Is there a hotfix known? Perhaps a static binary? Its a bit of a roadblock...

Hey, Just hit this right now on Centos Stream 10. I tried installing some aws libs from dnf but that didnt seem to help. If I were to guess its somehow not including this lib in the closure for lix when installing. Not including logs as they are the same as above. Is there a hotfix known? Perhaps a static binary? Its a bit of a roadblock...

sohamg commented

2025-08-12 17:41:12 +00:00

Okay I ran ldd on the nix-store binary fetched by the installer and it is infact a busted rpath

Whats surprising is that this is not the case for nix-store binary from the lix-module. I'm gonna try pointing the installer at the 2.93.1 version tarball and see if something changes

Okay I ran `ldd` on the nix-store binary fetched by the installer and it is infact a busted rpath ![image](/attachments/1e835e3e-9d2e-4239-9c2b-3fcddbdfa0ab) Whats surprising is that this is not the case for nix-store binary from the lix-module. I'm gonna try pointing the installer at the 2.93.1 version tarball and see if something changes

image.png

5.5 KiB

sohamg referenced this issue from lix-project/lix

2025-08-12 18:22:08 +00:00

Multiple Lix Releases have broken (impure) RPATHs #957

sohamg commented

2025-08-12 18:22:47 +00:00

Created above issue as this seems to be more than a broken installer problem.

alois31 commented

2025-08-13 07:11:11 +00:00

Member

It is in fact an installer problem. Some paths, like /nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27 which triggers the error, end up being symlinks to themselves. The reason appears to be that in the move loop

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

the source directory being read gets modified

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

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

triggering unspecified behaviour in the directory enumeration.

On XFS, this leads to several of the new entries (including 1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27) being returned. The installer is not prepared for that, removes the legitimate target and moving the backup symlink there instead, which now is a symlink pointing to itself instead of the desired directory.

It is in fact an installer problem. Some paths, like `/nix/store/1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27` which triggers the error, end up being symlinks to themselves. The reason appears to be that in the move loop https://git.lix.systems/lix-project/lix-installer/src/commit/e4048682396999c11069f99f9b323f1d4a333bbc/src/action/base/move_unpacked_nix.rs#L87-L91 the source directory being read gets modified https://git.lix.systems/lix-project/lix-installer/src/commit/e4048682396999c11069f99f9b323f1d4a333bbc/src/action/base/move_unpacked_nix.rs#L102-L105 https://git.lix.systems/lix-project/lix-installer/src/commit/e4048682396999c11069f99f9b323f1d4a333bbc/src/action/base/move_unpacked_nix.rs#L135-L138 triggering unspecified behaviour in the directory enumeration. On XFS, this leads to several of the new entries (including `1k1bnir265n7jpbmwinj8hiwygnwrw3s-aws-c-common-0.9.27`) being returned. The installer is not prepared for that, removes the legitimate target and moving the backup symlink there instead, which now is a symlink pointing to itself instead of the desired directory.

Rows
Columns

error while loading shared libraries: libaws-c-common.so.1 #47

Error

Metadata