Avoid 32-bit libraries when IA32_EMULATION is off #2190
Labels
bug
Our bugs
Comments
|
From @aafeijoo-suse
|
|
So since this actually impacts even installing a distro kernel, and I had an example of both a good and a bad case in the form of a old initramfs images that had been installed before and while running a 64-bit only kernel, I did this: to just extract a file lists and compare them (that 'sed' part is to just make the different module paths compare the same, of course). In the above, the "old" is a good install that was done before I had turned off support for 32-bit compat mode, and "new" is the file list of a kernel install that had been done on the exact same system, just with a kernel that no lonegr ran 32-bit binaries. Interestingly, the difference is almost entirely that "new" is missing a lot of 64-bit libraries in /usr/lib64, so the diff starts out like this: and the snipped out part doesn't really get any more interesting. There are no actual 32-bit binary files in the good case, with the following returning an empty set of files: so the failure is not that some 32-bit binary was used, the failure really seems to be that just the existence of 32-bit binaries that were not used then ended up confusing some logic enough to not include various 64-bit libraries. Some fallout from the ldd failure does seem very likely. |
|
Just to clarify: everything works for me now, because I blew away all my old 32-bit binaries on this machine, so now when I run dracut on a kernel that doesn't have support for 32-bit compat more, it all works correctly. So this is not a high priority, but it was very confusing, and it might bite somebody else at some future point where people start deciding more widely that 32-bit compat support is no longer interesting. Having left-over 32-bit binaries that aren't actually used any more then causes this odd failure on installing a new kernel, when everything else seems to work just fine. |
Yes, I came to the same conclusion yesterday: This new initrd fails to boot the system. After manually removing |
|
Although the But dracut/src/install/dracut-install.c Lines 569 to 570 in 9fb64d9 So, is our bug. |
aafeijoo-suse
added a commit
to aafeijoo-suse/dracut
that referenced
this issue
Feb 9, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
3 tasks
aafeijoo-suse
added a commit
to aafeijoo-suse/dracut
that referenced
this issue
Feb 9, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
johannbg
pushed a commit
that referenced
this issue
Feb 13, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue #2190
aafeijoo-suse
added a commit
to aafeijoo-suse/dracut
that referenced
this issue
Jun 15, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
(cherry picked from commit 9a531ca)
aafeijoo-suse
added a commit
to aafeijoo-suse/dracut
that referenced
this issue
Jun 26, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
(cherry picked from commit 9a531ca)
bsc#1212662
aafeijoo-suse
added a commit
to aafeijoo-suse/dracut
that referenced
this issue
Jun 26, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
(cherry picked from commit 9a531ca)
bsc#1212662
This was referenced Jun 26, 2023
pvalena
pushed a commit
to pvalena/dracut
that referenced
this issue
Jul 23, 2023
…inary file"
When the kernel is compiled without IA32_EMULATION and the glibc 32-bit library
is installed on the system, `ldd` prints the following output:
```
> ldd /usr/lib64/libfido2.so.1.12.0
/bin/ldd: line 162: /lib/ld-linux.so.2: cannot execute binary file: Exec format error
linux-vdso.so.1 (0x00007ffd627fa000)
libcbor.so.0.9 => /lib64/libcbor.so.0.9 (0x00007f18d799f000)
libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f18d7400000)
libudev.so.1 => /lib64/libudev.so.1 (0x00007f18d7971000)
libhidapi-hidraw.so.0 => /lib64/libhidapi-hidraw.so.0 (0x00007f18d7968000)
libz.so.1 => /lib64/libz.so.1 (0x00007f18d794e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f18d7205000)
/lib64/ld-linux-x86-64.so.2 (0x00007f18d79f9000)
> echo $?
0
```
The `ldd` script uses the following code to resolve dependencies:
```
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2"
...
RTLD=
ret=1
for rtld in ${RTLDLIST}; do
if test -x $rtld; then
verify_out=`${rtld} --verify "$file"`
ret=$?
case $ret in
[02]) RTLD=${rtld}; break;;
esac
fi
done
```
So, if the 32-bit library fails, the 64-bit library may work, so don't stop
parsing the `ldd` output unconditionally when the message "cannot execute binary
file" is printed.
Fixes issue dracutdevs#2190
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When IA32_EMULATION is off on a 64-bit only x86-64 configuration, 32-bit binaries would likely break the boot process.
The exact configuration for this error is not yet confirmed, but "32-bit libraries that don't work end up also hiding 64-bit ones that do work" when binaries from the host are copied to the initramfs. Confirmed on F37, but distribution is likely irrelevant.
The text was updated successfully, but these errors were encountered: