lix-project/lix-installer
15
7
Fork 7
Code Issues 43 Code Review (Gerrit) Projects Activity

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

New issue
Open
opened 2025-05-23 22:01:51 +00:00 by aureliaimmortalia · 7 comments
aureliaimmortalia commented 2025-05-23 22:01:51 +00:00
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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
Copy link

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

image

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 commented 2025-08-12 18:22:47 +00:00
Copy link

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

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
Copy link

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

Lines 87 to 91 in e404868
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

Lines 102 to 105 in e404868
tokio::fs::rename(&entry.path(), &entry_dest)
.await
.map_err(|e| ActionErrorKind::Rename(entry.path(), entry_dest.to_owned(), e))
.map_err(Self::error)?;

Lines 135 to 138 in e404868
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.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
2.92.0
2.91.1
2.91.0-1
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 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#47
No description provided.