[opensuse-factory] 32bit apps on OS 13.2 64bit responses with Bad system call
History ------- A month ago /var and /tmp got lost by hdd crash. I did my best to recover the lost data by re-installing most of the packages, including aaa-base, aaa_base-extras, kernel etc., because a sufficient backup of this two dirs was not available :(. Since the hdd crash I notified that 32bit apps response with Bad system call, even if they were updated or re-installed. See the example of acroread below. What can I do else to solve this behaviour, apart from a completely fresh install? Every hint to solve this problem is highly appreciated. -- Kind Regards Peter Ragosch raven:~ # zypper in acroread acroread-browser-plugin Loading repository data... Reading installed packages... Resolving package dependencies... The following 5 NEW packages are going to be installed: acroread acroread-browser-plugin libidn11-32bit libopenssl0_9_8-32bit libpangox-1_0-0-32bit The following recommended package was automatically selected: acroread-browser-plugin 5 new packages to install. Overall download size: 38.4 MiB. Already cached: 0 B After the operation, additional 126.5 MiB will be used. Continue? [y/n/? shows all options] (y): y Retrieving package libopenssl0_9_8-32bit-0.9.8x-9.1.5.x86_64 (1/5), 586.2 KiB ( 1.8 MiB unpacked) Retrieving: libopenssl0_9_8-32bit-0.9.8x-9.1.5.x86_64.rpm ........................................[done] Retrieving package libpangox-1_0-0-32bit-0.0.2-6.1.3.x86_64 (2/5), 40.6 KiB (122.9 KiB unpacked) Retrieving: libpangox-1_0-0-32bit-0.0.2-6.1.3.x86_64.rpm .........................................[done] Retrieving package libidn11-32bit-1.31-3.3.1.x86_64 (3/5), 45.9 KiB (201.6 KiB unpacked) Retrieving: libidn11-32bit-1.31-3.3.1.x86_64.rpm .................................................[done] Retrieving package acroread-9.5.5-14.1.x86_64 (4/5), 37.6 MiB (124.2 MiB unpacked) Retrieving: acroread-9.5.5-14.1.x86_64.rpm ...........................................[done (3.0 MiB/s)] Retrieving package acroread-browser-plugin-9.5.5-14.1.x86_64 (5/5), 75.7 KiB (190.7 KiB unpacked) Retrieving: acroread-browser-plugin-9.5.5-14.1.x86_64.rpm ...........................[done (61.5 KiB/s)] Checking for file conflicts: .....................................................................[done] (1/5) Installing: libopenssl0_9_8-32bit-0.9.8x-9.1.5 .............................................[done] (2/5) Installing: libpangox-1_0-0-32bit-0.0.2-6.1.3 ..............................................[done] (3/5) Installing: libidn11-32bit-1.31-3.3.1 ......................................................[done] (4/5) Installing: acroread-9.5.5-14.1 ............................................................[done] (5/5) Installing: acroread-browser-plugin-9.5.5-14.1 .............................................[done] raven:~ # acroread Bad system call <-------- raven:~ # wine Bad system call <-------- raven:~ # wine64 Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit raven:~ # --[ hostinfo v0.55-2 ]---------------------------------------- Hostname: raven Current As Of: 08/12/15 11:59:08 Distribution: openSUSE 13.2 Service Pack: Kernel Version: 3.16.7-21-desktop Architecture: x86_64 IPv4 Address: None eth0 (static) Total/Free Memory: 32144/26888 MB Hard Disk: /dev/sda 2000 GB Hard Disk: /dev/sdb 3000 GB Hard Disk: /dev/sdc 240 GB Hard Disk: /dev/sdh 3000 GB Terminal: \l --------------------------------------------------------------- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thursday 01 of October 2015 17:28:31 Peter Ragosch wrote: ...
Since the hdd crash I notified that 32bit apps response with Bad system call, even if they were updated or re-installed. See the example of acroread below.
Try "rpm --verify" on all *-32bit packages (and reinstall where needed).
What can I do else to solve this behaviour, apart from a completely fresh install?
You can also try running the program under strace to see what syscall fails and how. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Fri, 02 Oct 2015 11:33:52 +0200 schrieb Michal Kubecek <mkubecek@suse.cz>:
On Thursday 01 of October 2015 17:28:31 Peter Ragosch wrote: ...
Since the hdd crash I notified that 32bit apps response with Bad system call, even if they were updated or re-installed. See the example of acroread below.
Try "rpm --verify" on all *-32bit packages (and reinstall where needed).
What can I do else to solve this behaviour, apart from a completely fresh install?
You can also try running the program under strace to see what syscall fails and how.
Michal Kubeček
Hi Michal, thanks for the hints. There are no missing 32bit package reported by zypper/rpm. But I'm unsure if this is really true. Since the crash some packages were reported as not installed by zypper, whilst the binaries were in path. I've updated such package asap I found them. May be there are more. strace shows for both 32bit apps the same: +++ killed by SIGSYS +++ see below. Any other idea? Kind Regards Peter Ragosch raven:~ # strace acroread execve("/usr/bin/acroread", ["acroread"], [/* 78 vars */]) = 0 brk(0) = 0x1eab000 [ --- many lines snipped --- ] access("/usr/bin/cp", R_OK) = 0 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa6ee9b99d0) = 8141 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {0x428a18, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, 8) = 0 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 8141 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, {0x428a18, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=8141, si_status=0, si_utime=0, si_stime=0} --- wait4(-1, 0x7fff16541340, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigreturn() = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 read(255, "\nif [ \"$1\" = \"-DEBUG\" ] ; then\n "..., 8192) = 548 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 stat("/usr/lib/Adobe/Reader9/Reader/intellinux/bin/acroread", {st_mode=S_IFREG|0755, st_size=24538404, ...}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, {SIG_IGN, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, 8) = 0 rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, {0x429da8, [], SA_RESTORER|SA_RESTART, 0x7fa6ede16200}, 8) = 0 execve("/usr/lib/Adobe/Reader9/Reader/intellinux/bin/acroread", ["/usr/lib/Adobe/Reader9/Reader/in"...], [/* 91 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call raven:~ # raven:~ # strace wine execve("/usr/bin/wine", ["wine"], [/* 78 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call raven:~ # -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Oct 2, 2015 at 4:42 PM, Peter Ragosch <peter.ragosch@kabelmail.de> wrote:
raven:~ # strace acroread
You need "strace -f" to continue tracing all child processes. /usr/bin/acroread itself is just a shell script and you need to trace actual binary. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 02 of October 2015 15:42:02 Peter Ragosch wrote:
There are no missing 32bit package reported by zypper/rpm. But I'm unsure if this is really true. Since the crash some packages were reported as not installed by zypper, whilst the binaries were in path. I've updated such package asap I found them. May be there are more.
The *-32bit packages (their files installed in the system) might be corrupted since the crash. That's why I suggested to run "rpm --verify" on them. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Fri, 02 Oct 2015 16:02:57 +0200 schrieb Michal Kubecek <mkubecek@suse.cz>:
On Friday 02 of October 2015 15:42:02 Peter Ragosch wrote:
There are no missing 32bit package reported by zypper/rpm. But I'm unsure if this is really true. Since the crash some packages were reported as not installed by zypper, whilst the binaries were in path. I've updated such package asap I found them. May be there are more.
The *-32bit packages (their files installed in the system) might be corrupted since the crash. That's why I suggested to run "rpm --verify" on them.
Michal Kubeček
@ Michal -------- OK, at least I did raven:~ # zypper se 32bit | grep "i |" >> 32bit.txt raven:~ # awk -F "|" '{print $2}' 32bit.txt >> 32bit_names.txt raven:~ # while read i; do rpm --verify $i; done < 32bit_names.txt .....L.... /usr/lib/libgmp.so.10 raven:~ # raven:~ # rpm -v --verify libgmp10-32bit .....L.... /usr/lib/libgmp.so.10 .......... /usr/lib/libgmp.so.10.1.3 raven:~ # ls -al /usr/lib/libgmp.so.10 lrwxrwxrwx 1 root root 16 Sep 27 10:09 /usr/lib/libgmp.so.10 -> libgmp.so.10.2.0 raven:~ # because raven:~ # rpm -q -f /usr/lib/libgmp.so.10.2.0 file /usr/lib/libgmp.so.10.2.0 is not owned by any package I don't know where it comes from, so I linked it back to version 10.1.3 raven:~ # rm /usr/lib/libgmp.so.10 raven:~ # ln -s /usr/lib/libgmp.so.10.1.3 /usr/lib/libgmp.so.10 raven:~ # libgmp was not the reason for the problem. @Andrei ------- Well, i did a strace -f on acroread and tried a compare of the output with one on a 13.1 machine. Interpreting the output is far beyond my skills. The strace -f wine output is much easier to understand, I think: On my 13.2 machine: raven:~ # strace -f wine execve("/usr/bin/wine", ["wine"], [/* 78 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call On the 13.2 machine: (only the first 5 lines) raven2:~ # strace -f wine execve("/usr/bin/wine", ["wine"], [/* 64 vars */]) = 0 [ Process PID=4401 runs in 32 bit mode. ] brk(0) = 0x7c287000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff779b000 readlink("/proc/self/exe", "/usr/bin/wine", 4096) = 13 Just after execve the first one is killed, but the second one is recognized as 32-bit binary. I guess the question of interest should be: Which "part" is responsible for the detection of a starting 32bit binary on a 64bit installation? Which "part" is switching the arch for the binary? Am I right? -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
02.10.2015 20:44, Peter Ragosch пишет:
The strace -f wine output is much easier to understand, I think: On my 13.2 machine: raven:~ # strace -f wine execve("/usr/bin/wine", ["wine"], [/* 78 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call
Yes, this really sounds like seccomp issue described in rhbz I mentioned earlier. Could you check /proc/self/status, field Seccomp, what value it has? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Fri, 2 Oct 2015 21:21:47 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
02.10.2015 20:44, Peter Ragosch пишет:
The strace -f wine output is much easier to understand, I think: On my 13.2 machine: raven:~ # strace -f wine execve("/usr/bin/wine", ["wine"], [/* 78 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call
Yes, this really sounds like seccomp issue described in rhbz I mentioned earlier. Could you check /proc/self/status, field Seccomp, what value it has?
raven:~ # cat /proc/self/status | grep -i seccomp Seccomp: 2 raven:~ # -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
03.10.2015 11:17, Peter Ragosch пишет:
Am Fri, 2 Oct 2015 21:21:47 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
02.10.2015 20:44, Peter Ragosch пишет:
The strace -f wine output is much easier to understand, I think: On my 13.2 machine: raven:~ # strace -f wine execve("/usr/bin/wine", ["wine"], [/* 78 vars */]) = 0 +++ killed by SIGSYS +++ Bad system call
Yes, this really sounds like seccomp issue described in rhbz I mentioned earlier. Could you check /proc/self/status, field Seccomp, what value it has?
raven:~ # cat /proc/self/status | grep -i seccomp Seccomp: 2 raven:~ #
Yes, you have seccomp enabled in mode 2. Unfortunately, I do not know if it is possible to fetch actual seccomp filter in use. Please read man systemd-system.conf. Check every file and directory mentioned in this page - does it have SystemCallAcritectures set and to which value. If there is none - something enables seccomp and you will find out what. Start with booting with init=/bin/sh. What value Seccomp has now? Boot into run level 1 - what value Seccomp has now? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sat, 3 Oct 2015 18:55:47 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
raven:~ # cat /proc/self/status | grep -i seccomp Seccomp: 2 raven:~ #
Yes, you have seccomp enabled in mode 2. Unfortunately, I do not know if it is possible to fetch actual seccomp filter in use.
Please read man systemd-system.conf. Check every file and directory mentioned in this page - does it have SystemCallAcritectures set and to which value. If there is none - something enables seccomp and you will find out what. Start with booting with init=/bin/sh. What value Seccomp has now? Boot into run level 1 - what value Seccomp has now?
Under /etc/systemd/ I found two files containing SystemCallArchitectures /etc/systemd/system.conf: SystemCallArchitectures=x86-64 other entries commented out /etc/systemd/user.conf: all entries commented out I found: SystemCallArchitectures= Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. So I guess "x86-64" is not correct in case 32bit code should be executable, too. It should be "x86 x86-64". Right? init=/bin/sh Seccomp: 2 init 1 to 5 Seccomp: 2 I think, I got the intention of SECure COMputing. (I'm not a programmer, only a user) But I can't see what is able to set the Seccomp mode, except it depends on the SystemCallArchitectures option. And if so, what has changed the option and why? On the other hand, is it secure to change the SystemCallArchitectures option simply to "x86 x86-64"? -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
03.10.2015 20:47, Peter Ragosch пишет:
Am Sat, 3 Oct 2015 18:55:47 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
raven:~ # cat /proc/self/status | grep -i seccomp Seccomp: 2 raven:~ #
Yes, you have seccomp enabled in mode 2. Unfortunately, I do not know if it is possible to fetch actual seccomp filter in use.
Please read man systemd-system.conf. Check every file and directory mentioned in this page - does it have SystemCallAcritectures set and to which value. If there is none - something enables seccomp and you will find out what. Start with booting with init=/bin/sh. What value Seccomp has now? Boot into run level 1 - what value Seccomp has now?
Under /etc/systemd/ I found two files containing SystemCallArchitectures
/etc/systemd/system.conf: SystemCallArchitectures=x86-64 other entries commented out
/etc/systemd/user.conf: all entries commented out
I found: SystemCallArchitectures= Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system.
So I guess "x86-64" is not correct in case 32bit code should be executable, too. It should be "x86 x86-64". Right?
Default is nothing (this line is commented out). This means - no seccomp filters at all installed by systemd. So comment it out.
init=/bin/sh Seccomp: 2
Well, it is probably got copied into initrd so every process now inherits filter. You need to also recreate initrd after commenting out SystemCallArchitectures.
init 1 to 5 Seccomp: 2
I think, I got the intention of SECure COMputing. (I'm not a programmer, only a user) But I can't see what is able to set the Seccomp mode, except it depends on the SystemCallArchitectures option. And if so, what has changed the option and why?
That I cannot answer. You can check modification time of this file and try to remember what happened at this point. But unless you had audit enabled unfortunately there is no way to know it for sure.
On the other hand, is it secure to change the SystemCallArchitectures option simply to "x86 x86-64"?
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sat, 3 Oct 2015 21:00:27 +0300 schrieb Andrei Borzenkov <arvidjaar@gmail.com>:
Well, it is probably got copied into initrd so every process now inherits filter. You need to also recreate initrd after commenting out SystemCallArchitectures.
I commented out line SystemCallArchitectures= raven:~ # edit /etc/systemd/system.conf: .... # SystemCallArchitectures= .... created a new initramfs raven:~ # /sbin/mkinitrd did a reboot checked seccomp status raven:~ # cat /proc/self/status | grep -i seccomp Seccomp: 0 that looks well! tested 32bit programs peter@raven:~> wine Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit peter@raven:~> acroread -> acroread window pop-up OK, 32bit apps are able to run! No "Bad system call" any more. Problem solved. Many thanks for your great help and patience, Andrei. A deliriously happy openSuSE user. Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-02 19:44, Peter Ragosch wrote:
because raven:~ # rpm -q -f /usr/lib/libgmp.so.10.2.0 file /usr/lib/libgmp.so.10.2.0 is not owned by any package
I don't know where it comes from, so I linked it back to version 10.1.3
I have 13.1, so different version, but: cer@Telcontar:~> rpm -qf /usr/lib/libgmp.so.10.1.2 libgmp10-32bit-5.1.2-2.1.2.x86_64 cer@Telcontar:~> -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am Fri, 2 Oct 2015 20:49:26 +0200 schrieb "Carlos E. R." <robin.listas@telefonica.net>:
I have 13.1, so different version, but:
cer@Telcontar:~> rpm -qf /usr/lib/libgmp.so.10.1.2 libgmp10-32bit-5.1.2-2.1.2.x86_64 cer@Telcontar:~>
raven:~ # rpm -qf /usr/lib/libgmp* libgmp10-32bit-5.1.3-3.1.2.x86_64 libgmp10-32bit-5.1.3-3.1.2.x86_64 file /usr/lib/libgmp.so.10.2.0 is not owned by any package raven:~ # -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-03 10:13, Peter Ragosch wrote:
Am Fri, 2 Oct 2015 20:49:26 +0200 schrieb "Carlos E. R." <>:
I have 13.1, so different version, but:
cer@Telcontar:~> rpm -qf /usr/lib/libgmp.so.10.1.2 libgmp10-32bit-5.1.2-2.1.2.x86_64 cer@Telcontar:~>
raven:~ # rpm -qf /usr/lib/libgmp* libgmp10-32bit-5.1.3-3.1.2.x86_64 libgmp10-32bit-5.1.3-3.1.2.x86_64 file /usr/lib/libgmp.so.10.2.0 is not owned by any package raven:~ #
In your case it is an orphan; so install the rpm again. It should be "libgmp10-32bit-5.1.3-3.1.2.x86_64.rpm" (or similar). - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYP3qIACgkQja8UbcUWM1yD5QD/V2v9el/c0s3Wz93KOJwLou+J WIXfcrYXRpSyvsG0pJwBAJE3mK/I4tCuTbI35QeT1si8l+kOH12h76RnVQhi6+Nk =9a8l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sat, 3 Oct 2015 15:56:50 +0200 schrieb "Carlos E. R." <robin.listas@telefonica.net>:
In your case it is an orphan; so install the rpm again. It should be "libgmp10-32bit-5.1.3-3.1.2.x86_64.rpm" (or similar).
done a re-install - now it's clean, even if the 32bit exec problem isn't solved by this. (1/1) Installing: libgmp10-32bit-5.1.3-3.1.2 raven:~ # ls -al /usr/lib/libgmp* lrwxrwxrwx 1 root root 16 Oct 3 17:55 /usr/lib/libgmp.so.10 -> libgmp.so.10.1.3 -rwxr-xr-x 1 root root 547768 Sep 25 2014 /usr/lib/libgmp.so.10.1.3 raven:~ # wine Bad system call raven:~ # Many thanks for your help, Carlos. PS: The solution was found by Andrei: comment out option SystemCallArchitectures= in /etc/systemd/system.conf and /etc/systemd/user.conf if set create new initramfs by using /sbin/mkinitrd reboot -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-10-04 10:36, Peter Ragosch wrote:
Am Sat, 3 Oct 2015 15:56:50 +0200 schrieb "Carlos E. R." <>:
In your case it is an orphan; so install the rpm again. It should be "libgmp10-32bit-5.1.3-3.1.2.x86_64.rpm" (or similar).
done a re-install - now it's clean, even if the 32bit exec problem isn't solved by this.
... Yes, I saw you solved your problem finally. Me, I had several crashes during updates (kernel panic), causing several unknown libraries in the system to be corrupted. Also the rpm database was corrupt, complicating repairs. I had to do a "rpm -Va '*'" to detect many of them. rpm --rebuilddb rpm -Va '*' | less -S rpm | sort | less -S (visually find duplicates) I'm unsure if any of this would help in your case. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlYRKccACgkQja8UbcUWM1wpSwD/W1eanTn3GfozrO2oRajW3FwW Yb9iip7Bpw0KsDvq4RYA/1R1WqszWoaAjnm66QE6omJmnlMFX4DOqmyMhFcU0hQ/ =jSji -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sun, 4 Oct 2015 15:29:43 +0200 schrieb "Carlos E. R." <robin.listas@telefonica.net>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-10-04 10:36, Peter Ragosch wrote:
Am Sat, 3 Oct 2015 15:56:50 +0200 schrieb "Carlos E. R." <>:
In your case it is an orphan; so install the rpm again. It should be "libgmp10-32bit-5.1.3-3.1.2.x86_64.rpm" (or similar).
done a re-install - now it's clean, even if the 32bit exec problem isn't solved by this.
...
Yes, I saw you solved your problem finally.
Me, I had several crashes during updates (kernel panic), causing several unknown libraries in the system to be corrupted. Also the rpm database was corrupt, complicating repairs.
I had to do a "rpm -Va '*'" to detect many of them.
rpm --rebuilddb rpm -Va '*' | less -S rpm | sort | less -S (visually find duplicates)
I understand - you are reflecting on my story about the hdd crash. Well, I hoped that I fixed everything regarding the packages intermediate. Only the two versions of libgmp10 were remaining and I had in mind that two different libraries could live side by side in the same place. Because I couldn't found any package dependency for the higher version, I decided first hand, it is not important, and second hand to spend no more time for that just now. The "Bad system call" problem was most urgent. But, nevertheless, thank you for spending your time. -- Mit freundlichen Grüßen Kind Regards Peter Ragosch -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Michal Kubecek -
Peter Ragosch