Running Sphinx v3.5.1
/bin/sh: line 1: git: command not found
making output directory… done
WARNING: html_static_path entry ‘_static’ does not exist

Theme error:
sphinx_rtd_theme is no longer a hard dependency since version 1.4.0. Please install it manually.(pip install sphinx_rtd_theme)
{’code2docs’: {}, ‘docs2code’: {}}
make: *** [Makefile:24: html] Error 2

If I remember correctly, then some Spinx schemes need yarn to build, so they are no longer
buildable.
This means all packages needing that theme for documentation purposes are failing.

Maybe buildable without documentation for now?

no task description

:: removing user-manager breaks dependency ‘user-manager’ required by plasma-meta

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano U3400@800MHz
stepping : 10
cpu MHz : 798.016
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vnmi vpid ida
vmx flags : vnmi tsc_offset vtpr
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 1596.53
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

Other machine, also with via processor:

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA C7-D Processor 1800MHz
stepping : 0
cpu MHz : 1596.326
cache size : 128 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 3193.67
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 32 bits virtual
power management:

All the __builtin_cpu_supports() and __builtin_cpu_is() tests fail. Thus, pacman thinks, it’s not capable of sse2 and installs i686 packages instead of pentium4 ones.

Should we complain at gcc upstream? How does the kernel compile this line in /proc/cpuinfo? What checks does it perform?

looks, like the new devtools do not strip packages anymore - maybe it was only an intermediate version, that lacked automatic stripping.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 18.05.2019
Last edited by Andreas Baumann - 16.08.2019
 FS#75  - openjdk8/10/11/12 break with march=pentium4 optimization

This blocks ant, needed for building libreoffice.
Closed by Andreas Baumann
16.08.2019 13:55
Reason for closing: Fixed
Additional comments about closing:

fixed for 8, 10, 11 and 12. Not for 7.

  Comments (34)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 18.05.2019 18:18

mmh. java is fine.

java -version
openjdk version “1.8.0_212” OpenJDK Runtime Environment (build 1.8.0_212-b01)
OpenJDK Server VM (build 25.212-b01, mixed mode)

javac
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=124, tid=0xf6dc1b40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.124
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid124.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

ant
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=155, tid=0xf6d4fb40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.155
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid155.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x897c76]
V [libjvm.so+0x36392a]
V [libjvm.so+0x71341f] JVM_handle_linux_signal+0x6bf
V [libjvm.so+0x70507f]
C [linux-gate.so.1+0×950] __kernel_rt_sigreturn+0×0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.System.nanoTime()J+0
j java.net.URLClassLoader.defineClass(Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+0
j java.net.URLClassLoader.access$100(Ljava/net/URLClassLoader;Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+3
j java.net.URLClassLoader$1.run()Ljava/lang/Class;+43
j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70
j sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+81
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
v ~StubRoutines::call_stub
j com.sun.tools.javac.main.Main.(Ljava/lang/String;Ljava/io/PrintWriter;)V+5
j com.sun.tools.javac.main.Main.(Ljava/lang/String;)V+13
j com.sun.tools.javac.Main.compile([Ljava/lang/String;)I+6
j com.sun.tools.javac.Main.main([Ljava/lang/String;)V+1
v ~StubRoutines::call_stub
Admin
Andreas Baumann commented on 18.05.2019 18:19

well. Java errors, hard to debug..
Admin
Andreas Baumann commented on 18.05.2019 18:21

Installing the i686 version in the pentium4 chroot also segfaults..
Admin
Andreas Baumann commented on 18.05.2019 18:25

Java 686 doesn’t segfault on a real i686 installed system. So, I fear, some library in pentium4
is causing java to segfault.
Admin
Andreas Baumann commented on 18.05.2019 18:36

Event: 0.057 Thread 0xf6b07c00 Exception <a> (0xd7b86ea0) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cp
Event: 0.057 Thread 0xf6b07c00 Exception </a><a> (0xd7b87170) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cpp, line 4012]
Event: 0.231 Thread 0xf6b07c00 Exception </a><a> (0xd7cc0498) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jvm.cpp, line 1502]

mmh. this sounds quite internal..
</a>
Admin
Andreas Baumann commented on 18.05.2019 18:50

pentium$:
javac -version
javac 11.0.3

why is libreoffice built with java 8?
Admin
Andreas Baumann commented on 18.05.2019 19:00

weird: on my pentium4 test machine with jdk 8 and 11 installed, I can switch to java 8
and everything is fine.
Admin
Andreas Baumann commented on 18.05.2019 19:03

I remember issues with shared libraries and the way the Jvm is bootstrapping. For
instance not having a /proc causes trouble of this sort. But we have a /proc
(we are using arch-chroot and a bind mount point).
Admin
Andreas Baumann commented on 18.05.2019 19:07

using java 11 and javac 11 on pentium4 works..
Admin
Andreas Baumann commented on 18.05.2019 19:08

..and now we get to “find the 10 differences in this picture”. Admin
Andreas Baumann commented on 18.05.2019 19:14

The only thing I can think of is a different kernel (with more protection enabled):

https://bugs.openjdk.java.net/browse/JDK-8023956 https://bugs.openjdk.java.net/browse/JDK-8181068

This cries for building it on a real Pentium4 or on a properly emulated one, not
in a chroot.
Admin
Erich Eckner commented on 22.05.2019 04:34

&gt; using java 11 and javac 11 on pentium4 works..

why not simply pin the java version to 11, then?
Admin
Andreas Baumann commented on 06.06.2019 18:19

When installing the i686 version of glibc and openjdk8 there is no segfault!
So this sounds more like a new glibc and optimization triggering something in java..
Admin
Andreas Baumann commented on 07.06.2019 16:54

Actually also original SUN java 7 segfaults with this glibc.
Rebuilding glibc didn’t help. So I’m pretty sure it’s some protection thingy
getting into the way of old Java JDKs (because they always pushed their limits
and did funny tricks in the past).
Luke commented on 18.06.2019 18:27

Erich Eckner,
Ant is still broken with pentium4 build of java 11 (i686 works).

$ archlinux-java status
Available Java environments:

java-11-openjdk (default)

Admin
Andreas Baumann commented on 19.06.2019 17:57

19:40 &lt; slacka123&gt; should use “-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign” instead?
19:54 &lt; slacka123&gt; Yes, it does - https://bugs.documentfoundation.org/show_bug.cgi?id=108619
19:54 &lt; phrik&gt; Title: 108619 – (32bitjavacrash) Java Crash on x86 in jfw_plugin_startJavaVirtualMachine

             w/ recent linux kernels (at bugs.documentfoundation.org)

19:55 &lt; slacka123&gt; Fedora 30 also needs that kernel parameter, “stack_guard_gap=1” to run/build

                 LibreOffice and other java apps

… 19:56 &lt; slacka123&gt; but i686 arch32 also needs it

from the chat protocol: https://mirror.archlinux32.org/irc-logs/%23archlinux32/2019-06-19.html#19:39:59 Admin
Andreas Baumann commented on 21.06.2019 08:29

See: https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc.spec Admin
Andreas Baumann commented on 21.06.2019 12:23

Thanks slacka123 for the hint. This seems to solve the java/javac crashes.

It’s fixed now in staging and will soon hop into testing.
Admin
Andreas Baumann commented on 11.08.2019 06:03

The segfaults persist through all pentium4 versions of the openjdk.
Additionally now also the 7 version of i686 and pentium4 are segfaulting.
Admin
Andreas Baumann commented on 11.08.2019 07:11

jkd7 also cannot find libattr:

https://patchwork.openembedded.org/patch/110857/ Admin
Andreas Baumann commented on 11.08.2019 07:13

On 64-bit it complains about ant:

error: target not found: apache-ant&gt;=1.8.1

flagged out-of-date upstream, unusable currently for bootstrapping.
Admin
Andreas Baumann commented on 11.08.2019 07:56

https://bugs.archlinux.org/task/63430 Admin
Andreas Baumann commented on 11.08.2019 07:56

configure: Found potential Boot JDK using java© in PATH
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/java-penjdk)
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default-runtime)
configure: Potential Boot JDK found at /usr/lib/jvm/default-runtime is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default)
configure: Potential Boot JDK found at /usr/lib/jvm/default is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Could not find a valid Boot JDK.
configure: This might be fixed by explicitely setting –with-boot-jdk
configure: error: Cannot continue
configure exiting with result code 1
Admin
Andreas Baumann commented on 11.08.2019 18:02

building on i686 (where openjdk8 still works) and using makepkg.conf with pentium4
cflags gives a package with wrong architecture though, but running in a pentium4
chroot if installed.

Though when I try to rebuild it with the ‘cross-compiled’ package in a pentium4
chroot, I get:

checking headful support… include support for both headful and headless
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: error: The path given by –with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1

Inside I have a hs_err_pid3361.log showing again the darn SI_KERNEL SIGSEGV.

This problem is over my head (and skills).
Admin
Andreas Baumann commented on 12.08.2019 15:26

This sounds interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533

related question: is -march=pentium4 changing the stack layout?
Admin
Andreas Baumann commented on 12.08.2019 15:28

Should we force stack alignment globally for all libraries which could potentially be
called from java with -mstack-alignment=16? This could break havock on other software..
Admin
Andreas Baumann commented on 12.08.2019 15:28

Also interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533 Admin
Andreas Baumann commented on 12.08.2019 15:30

Also: -mincoming-stack-boundary=2

https://bugs.gentoo.org/attachment.cgi?id=522650&amp;action=diff Admin
Andreas Baumann commented on 12.08.2019 16:00

So -mstackrealign in the glibc flags helps to realign the stack, so that 4 and 16 byte stacks
can coexist, but Java generates it’s own executable code, which doesn’t respect that?
Why should -mincoming-stack-boundary=2 help then?
I’ll test again a double compilation via working i686 chroot to pentium4 (with -mincoming-stack-boundary=2 in the PKGBUILD of javapenjdk), then see if it can rebuild itself in a pentium4
chroot.
Admin
Andreas Baumann commented on 13.08.2019 04:48

Apparently this helps, thanks to the Gentoo guys. Admin
Andreas Baumann commented on 13.08.2019 05:05

Now to jdk10, jdk11 and jdk12 (weirdly enough there is no jdk9?).
Admin
Andreas Baumann commented on 15.08.2019 07:32

a working JDK8 for pentium4 hit staging. now for the other versions..
Admin
Andreas Baumann commented on 15.08.2019 11:40

This helps against GOT/PLT errors:

if test ${CARCH} = i686 -o ${CARCH} = pentium4; then
  echo "Removing '-fno-plt' from CFLAGS and CXXFLAGS to prevent build fail with th
  _CFLAGS=${CFLAGS/-fno-plt/}
  _CXXFLAGS=${CXXFLAGS/-fno-plt/}
fi

Admin
Andreas Baumann commented on 15.08.2019 12:03

Finished building targets ‘images docs’ in configuration ‘linux-x86-normal-server-release’ find: &lt;80&gt;&lt;98&gt;../jdk10u-jdk-10.0.2+13/build/linux-i386-normal-server-release/images&lt;80&gt;&lt;99&gt;: No such file or directory
ESC[1mESC[31m==&gt; ERROR:ESC[m^OESC[1m A failure occurred in build().ESC[m^O
ESC[1m Aborting…ESC[m^O
==&gt; ERROR: Build failed, check /var/lib/archbuild/staging-i686/abaumann/build
(END)

needs:

case “${CARCH}” in

x86_64) _JARCH='x86_64';;
i486|i686|pentium4)   _JARCH='x86';;

esac

Google Cache

26.11.2017 - In file included from ./arch/x86/include/asm/page.h:75:0, from ./arch/x86/include/asm/thread_info.h:11, from ./include/linux/thread_info.h:37, …

Attached to Project: Archlinux32
Opened by Markus Schaaf - 22.10.2019
 FS#92  - nfs mounts with sec=krb5 fail with ‘stale file handle’ for everyone but root

rpc.gssd bug due to missing syscall (setgroups). See https://bugzilla.linux-nfs.org/show_bug.cgi?id=340 `journalctl –unit=rpc-gssd.service` shows:

WARNING: unable to drop supplimentary groups!
WARNING: failed to change identity: Function not implemented

Until a fixed upstream release, use
$ cat abs/packages/nfs-utils/trunk/setgroups32.patch
— nfs-utils-2.4.1/utils/gssd/gssd_proc.c.orig 2019-10-22 11:26:48.059877484 +0200
+++ nfs-utils-2.4.1/utils/gssd/gssd_proc.c 2019-10-22 11:28:03.874553996 +0200
@@ -437,7 +437,7 @@

    int res;

    /* drop list of supplimentary groups first */

- if (syscall(SYS_setgroups, 0, 0) != 0) {
+ if (syscall(SYS_setgroups32, 0, 0) != 0) {

            printerr(0, "WARNING: unable to drop supplimentary groups!");
            return errno;
    }

Google Cache

newsboat: error while loading shared libraries: libjson-c.so.4: cannot open shared object file: No such file or directory

Attached to Project: Archlinux32
Opened by Andreas Baumann - 14.09.2019
Last edited by Andreas Baumann - 14.09.2019
 FS#86  - newsboat contains SSE2 instuctions

shell&gt; newsboat

Program received signal SIGILL, Illegal instruction.
0x005f5cd9 in ?? ()
=&gt; 0x005f5cd9: f2 0f 10 06 movsd (%esi),%xmm0
(gdb) bt
#0 0x005f5cd9 in ?? ()
#1 0x005f40fa in ?? ()
#2 0x005f3f3b in ?? ()
#3 0x0072e9fd in ?? ()
#4 0×00661600 in ?? ()
#5 0×00659435 in ?? ()
#6 0x0061fe88 in ?? ()
#7 0x0065770c in ?? ()
#8 0x005ea416 in ?? ()
#9 0x0044ca68 in ?? ()
#10 0xb76f9859 in __libc_start_main () from /usr/lib/libc.so.6
#11 0x0044da75 in ?? ()

This actually looks like glibc got a SSE2 infection on i686.

Google Cache

Checking PKGBUILD
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.9/site-packages/namcap.py", line 247, in <module>
    process_pkgbuild(package, active_modules)
  File "/usr/lib/python3.9/site-packages/namcap.py", line 153, in process_pkgbuild
    name = "PKGBUILD (" + pkginfo["name"] + ")"
  File "/usr/lib/python3.9/site-packages/Namcap/package.py", line 128, in __getitem__
    return self._data[self.canonical_varname(key)]
KeyError: 'name'
==> Running checkpkg
error: no targets specified (use -h for help)
==> WARNING: Skipped checkpkg due to missing repo packages

:: installing mutter (3.38.1-1.1) breaks dependency ‘libmutter-6.so=0-32’ required by gnome-shell

double free or corruption (out)
/usr/bin/mkinitcpio: line 557:  2387 Aborted                 (core dumped) MKINITCPIO_PROCESS_PRESET="$preset_name" "$0" "${preset_cmd[@]}"
error: command failed to execute correctly

Maybe also the age of the machine, the CMOS, the RAM, the moon, the universe could be
at fault here..

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 02.02.2018
Last edited by Andreas Baumann - 03.02.2018
 FS#27  - man breaks on gdbm sobump

man
man: error while loading shared libraries: libgdbm.so.4: cannot open shared object file: No such file or directory

either you must link against libgdbm_compat.so.4 or against libgdbm.5
Closed by Andreas Baumann
03.02.2018 07:47
Reason for closing: Fixed
Additional comments about closing:

fixed in man-db-2.7.6.1-3.1, installing that package from testing as temporary is the better
solution than adding a symlink you make forget to delete..

  Comments (4)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 02.02.2018 17:50

temporary workaround: ln -fs libgdbm_compat.so.4 /usr/lib/libgdbm.so.4
Admin
Andreas Baumann commented on 02.02.2018 17:53

weird: Archlinux has:

/usr/bin/man is owned by man-db 2.7.6.1-3
gdbm 1.14.1-1

Archlinux 32 has:

man-db 2.7.6.1-3.0
gdbm 1.14.1-1.0

This seems to be pretty much the same version.
Admin
Erich Eckner commented on 02.02.2018 18:15

it’s amazing what packages we managed to break I scheduled man-db for a rebuild
Admin
Andreas Baumann commented on 02.02.2018 20:38

man-db is rebuilding on my slave. *fingers crossed*

Google Cache

Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/sphinx/config.py", line 326, in eval_config_file
    execfile_(filename, namespace)
  File "/usr/lib/python3.9/site-packages/sphinx/util/pycompat.py", line 88, in execfile_
    exec(code, _globals)
  File "/build/llvm/src/llvm-11.0.1.src/docs/conf.py", line 40, in <module>
    import recommonmark
ModuleNotFoundError: No module named 'recommonmark'

This seems to be a problem of either update-archlinux32-package in devops or of the (commented) code path in the PKGBUILD which gets executed by this script.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 20.01.2019
 FS#60  - lightdm gtk greeter fails

Jan 10 12:55:01 arch32-staging systemd-coredump[894]: Process 892 (lightdm-gtk-gre) of user 620 dumped core.

                                                    
                                                    Stack trace of thread 892:
                                                    #0  0x00000000b712bb25 n/a (libglib-2.0.so.0)
                                                    #1  0x00000000b7120230 g_log_default_handler (libglib-2.0.so.0)
                                                    #2  0x00000000b712bd7d g_logv (libglib-2.0.so.0)
                                                    #3  0x00000000b712bf55 g_log (libglib-2.0.so.0)
                                                    #4  0x00000000b711267a g_thread_new (libglib-2.0.so.0)
                                                    #5  0x00000000b7132a1e n/a (libglib-2.0.so.0)
                                                    #6  0x00000000b7132a7a n/a (libglib-2.0.so.0)
                                                    #7  0x00000000b70e78d7 g_unix_signal_source_new (libglib-2.0.so.0)
                                                    #8  0x00000000b70ea3ef g_unix_signal_add_full (libglib-2.0.so.0)
                                                    #9  0x00000000b70ea463 g_unix_signal_add (libglib-2.0.so.0)
                                                    #10 0x00000000004dc145 main (lightdm-gtk-greeter)
                                                    #11 0x00000000b6c87a49 __libc_start_main (libc.so.6)
                                                    #12 0x00000000004de7f5 _start (lightdm-gtk-greeter)

Closed by Andreas Baumann
20.01.2019 16:04
Reason for closing: Fixed
Additional comments about closing:

hotfixed in lightdm-1:1.28.0-1.3

  Comments (12)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 19.01.2019 07:49

So, this happens when registering a signal handler: g_unix_signal_add.

Usually this points into the direction of ABI mismatches..
Admin
Andreas Baumann commented on 19.01.2019 08:07

[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter
[+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log
[+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter

the logfile is empty.

So, the question is, why doesn’t the greeter start and segfault.
Admin
Andreas Baumann commented on 19.01.2019 09:19

rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).

Now the stacktrace looks like:

#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
554 G_BREAKPOINT ();
(gdb) bt
#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
#1 0xb716d230 in g_log_default_handler

  (log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111

#2 0xb7178d7d in g_logv

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350

#3 0xb7178f55 in g_log

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413

#4 0xb715f67a in g_thread_new (name=0xb720d0b2 “gmain”, func=0xb7180b70 , data=0×0)

  at ../glib/glib/gthread.c:830

#5 0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888
#6 0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum

  at ../glib/glib/gmain.c:5224

#7 0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332
#8 0xb71348d7 in g_unix_signal_source_new (signum=15, signum

  at ../glib/glib/glib-unix.c:222

#9 0xb71373ef in g_unix_signal_add_full

  (priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
  at ../glib/glib/glib-unix.c:252

#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0×1)
–Type for more, q to quit, c to continue without paging–

  at ../glib/glib/glib-unix.c:283

#11 0×00490145 in main (argc=, argv at lightdm-gtk-greeter.c:2768

Admin
Andreas Baumann commented on 19.01.2019 09:44

creating thread ‘gmain’: Error creating thread: Resource temporarily unavailable

This is the interesting one. Why should creating a thread run out of resources? And which
resources?
Admin
Andreas Baumann commented on 19.01.2019 09:47

This is not by any chance an unhandled EAGAIN?
Admin
Andreas Baumann commented on 19.01.2019 10:04

[pid 6607] execve(”/usr/bin/core_perl/plymouth”, [”plymouth”, “–ping”], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)

this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every
Linux distribution has a plymouth, so I hope, this is actually optional..
The -ping indicates, that plymouth is started with ping, to see whether it is around.
It doesn’t seem to have something to do with our problem though..

There is a strace entry showing the greeter gets started:

[pid 6616] execve(”/usr/bin/lightdm-gtk-greeter”, [”/usr/bin/lightdm-gtk-greeter”], 0xf61510 /* 15 vars */) = 0

later the sighandler tries to open a new thread:

825 GThread *thread;
826
827 thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &amp;error);
828
829 if G_UNLIKELY (thread == NULL)
830 g_error (”creating thread ‘%s’: %s”, name ? name : ““, error-&gt;message);
831
832 return thread;

So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would
explain the startup issues..

There is also a suspicious:

[pid 6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)

So, I check the rlimit settings used by systemd for login session..
Admin
Andreas Baumann commented on 20.01.2019 09:21

Sounds related:

https://github.com/abrt/faf/issues/212 Admin
Andreas Baumann commented on 20.01.2019 10:37

mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?
Admin
Andreas Baumann commented on 20.01.2019 10:55

aha. the mmap works there.
Admin
Andreas Baumann commented on 20.01.2019 13:54

lightdm-gtk-greeter.c

mlockall (MCL_CURRENT | MCL_FUTURE);

commenting that out lets the mmap2 succeed.

As we deal with passwords, just disabling the locking is maybe not the best idea.

Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560
didn’t help at all.
Admin
Andreas Baumann commented on 20.01.2019 13:58

Locking the whole greeter with all GTK inside is maybe also not the wisest idea..
Admin
Andreas Baumann commented on 20.01.2019 14:03

LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.

Google Cache

no task description

Attached to Project: Archlinux32
Opened by Swift Geek - 16.03.2018
Last edited by Andreas Baumann - 26.03.2018
 FS#31  - librsvg fails with invalid opcode on 2.42.1 and newer

traps: gtk3-demo[365] trap invalid opcode ip:aedd3e15 sp:bffc64c0 error:0 in librsvg-2.so.2.42.3[aed27000+11a000]

Downgrading to 2.40.19 seems to help.
https://archive.archlinux32.org/repos/2017/11/01/extra/os/i686/librsvg-2:2.40.19-1-i686.pkg.tar.xz

This could be related to machine not having SSE2 (Pentium III-M Tualin)

Related bbs thread: https://bbs.archlinux32.org/viewtopic.php?id=1369 Closed by Andreas Baumann
26.03.2018 15:02
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Paul Gover commented on 26.03.2018 11:03

For me, librsvg-2:2.42.3-1.2 fixes the problem

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 30.05.2019
 FS#77  - librsvg doesn’t rebuild

1. -&gt; /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:5

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ----------------------------- previous definition of the type `P1024` here

2112 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `P1024` redefined here
   |
   = note: `P1024` must be defined only once in the type namespace of this module

error[E0428]: the name `N1024` is defined multiple times

1. -&gt; /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:35

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ----------------------------- previous definition of the type `N1024` here

2112 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `N1024` redefined here
   |
   = note: `N1024` must be defined only once in the type namespace of this module

error: aborting due to 3 previous errors

For more information about this error, try `rustc –explain E0428`.
error: Could not compile `typenum`.

Caused by:

process didn't exit successfully: `rustc --crate-name typenum /build/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.10.0/src/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=3 -C debuginfo=2 -C metadata=045a2ce7f5cfaab5 -C extra-filename=-045a2ce7f5cfaab5 --out-dir /build/librsvg/src/librsvg/target/release/deps -L dependency=/build/librsvg/src/librsvg/target/release/deps --cap-lints allow -C target-cpu=pentium3 -C target-feature=-sse2` (exit code: 1)

warning: build failed, waiting for other jobs to finish… error: build failed
make[2]: * [Makefile:1934: /build/librsvg/src/librsvg/target/release/librsvg_internals.a] Error 101
make[2]: Leaving directory ‘/build/librsvg/src/librsvg’ make[1]: * [Makefile:1438: all-recursive] Error 1
make[1]: Leaving directory ‘/build/librsvg/src/librsvg’ make: *** [Makefile:931: all] Error 2

The same error with typenum as when bootstrapping rust in stage 2.

librsvg is very important as it blocks tons of other stuff (so why
again was it written in Rust?!)

I might have seen a Debian patch for it, but Debian goes a “complete
Rust micro-packaging” way, not sure whether we can apply it here?

  Comments (1)
  Related Tasks (0/0)

Levi commented on 30.05.2019 18:26

Since it looks to me like it’s redefining P1024 and N1024 the same, can’t you just eliminate one of these definitions. Sure, it makes a patch you’d have to maintain henceforth until they fix this upstream, and I don’t understand what kind of preprocessing is ending up with this particular duplication, but deleting a line is about the simplest patch you could maintain.

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 04.01.2018
Last edited by Erich Eckner - 26.01.2018
 FS#23  - libretro* packages failing, seem unsupported for 32-bit Intel/Linux

This affects the following packages:
- libretro-citra (unsuported architecture in dynarmic submodule)
- libretro-parallel-n64: tons of assembly errors
- libretro-ppsspp: linking issues with ffmpeg
- libretro-mupen64plus: direct GOT relocation R_386_GOT32X against _ZN9PluginAPI3getEv PluginAPI::get()

blacklisting all.
Closed by Erich Eckner
26.01.2018 17:08
Reason for closing: Won’t fix
Additional comments about closing:

blacklisted

  Comments (0)

Google Cache

Attached to Project: Archlinux32
Opened by Raphael Scholer - 25.05.2019
 FS#76  - libreoffice-fresh needs to be rebuild against icu

  Comments (1)
  Related Tasks (0/0)

Levi commented on 25.05.2019 18:22

This bug is already captured 90% by https://bugs.archlinux32.org/index.php?do=details&amp;task_id=72 (see my comment underneath it), although to be fair I noted it against libreoffice-stable since that’s what I use.

Google Cache

Attached to Project: Archlinux32
Opened by Raphael Scholer - 11.11.2018
Last edited by Erich Eckner - 14.11.2018
 FS#56  - libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it

libreoffice-fresh seems not to be build against packages in [extra], but rather against packages in [*testing].

Running libreoffice produces the following error message:

/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: liborcus-0.14.so.0: cannot open shared object file: No such file or directory

extra/liborcus is 0.13.4-3.1
testing/liborcus is 0.14.1-1.0
Closed by Erich Eckner
14.11.2018 18:05
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 12.11.2018 10:37

I moved liborcus and libixion from testing to extra - now it should work.

Google Cache

-- Installing: /build/libproxy/pkg/libproxy/usr/include/proxy.h
-- Installing: /build/libproxy/pkg/libproxy/usr/bin/proxy
mv: cannot stat '/build/libproxy/pkg/libproxy/usr/lib/libproxy/*/modules/pacrunner_webkit.so': No such file or directory
==> ERROR: A failure occurred in package_libproxy().
    Aborting...

libhandy0: /usr/share/vala/vapi/libhandy-0.0.deps exists in filesystem (owned by libhandy)
libhandy0: /usr/share/vala/vapi/libhandy-0.0.vapi exists in filesystem (owned by libhandy)

Attached to Project: Archlinux32
Opened by Andreas Baumann - 15.11.2018
Last edited by Andreas Baumann - 31.01.2019
 FS#57  - libc fails on AMD-K6

pacstrap /test base
LD_LIBRARY_PATH=/test/usr/lib gdb –args /test/bin/bash results in:

Program terminated with signal SIGILL, Illegal instruction.
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
(gdb) bt
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
#1 0xb75bd41f in setlocale () from /test/usr/lib/libc.so.6
#2 0x0076b7f2 in ?? ()
#3 0x0053acf6 in ?? ()
#4 0xb75b3a31 in __libc_start_main () from /test/usr/lib/libc.so.6
#5 0x0053e561 in ?? ()

So, getting the exact failing opcode is hard.

2.28-5.0 was ok,
2.28-5.2 is not.

So it’s something we changed or something changed on one of the i486 build slaves.

Happens only on the AMD-K6, all other machines with CPUs with limited special instruction
sets (Pentium-S, AMD Geode) are working fine.
Closed by Andreas Baumann
31.01.2019 13:50
Reason for closing: Fixed
Additional comments about closing:

works with glibc-2.28-5.5-i486

  Comments (11)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 10.01.2019 08:27

happens on a Pentium-S now too.
Pentium-II is still fine, so is AMD Geode..
Admin
Andreas Baumann commented on 24.01.2019 10:10

Finally got around to tackle this one
installing a minimal chroot with:

pacstrap /test bash

Then debugging the chroot call:

gdb –args /usr/bin/chroot /test

yields:

Dump of assembler code for function memcpy:

 0xb7ff22f0 <+0>:     test   %al,%al
 0xb7ff22f2 <+2>:     jne    0xb7ff22e8
 0xb7ff22f4 <+4>:     xor    %eax,%eax
 0xb7ff22f6 <+6>:     ret    
 0xb7ff22f7 <+7>:     mov    $0x1,%eax
 0xb7ff22fc <+12>:    mov    $0xffffffff,%ecx

&gt; 0xb7ff2301 &lt;+17&gt;: cmovb %ecx,%eax

 0xb7ff2304 <+20>:    ret    

End of assembler dump.

So, we got cmov creeping in.

/proc/cpuinfo tells us that neither early Pentiums nor AMD K6 had a CMOV opcode.

Now the trick question is, why is it creeping into the C library?

Is the C library compiled with the wrong flags?
Is the gcc assuming that every CPU has a CMOV instruction? Are flags wrong there
or is CMOV suddenly the default?
Admin
Andreas Baumann commented on 24.01.2019 10:39

Checking in glibc: this is the offending opcode

i686/strcmp.S: cmovbl %ecx, %eax

L(neq): movl $1, %eax

      movl    $-1, %ecx
      cmovbl  %ecx, %eax

Now the question is, why does glibc think it’s ok to use i686 optimizations
when compiling with -march-i486.
Admin
Andreas Baumann commented on 24.01.2019 11:09

Not found an obvious reason, retriggering rebuild on known-good (hopefully) i486 build slave.
Admin
Andreas Baumann commented on 24.01.2019 20:44

config.log shows me i686 as build host. This is guessed with config.guess.
Manually executing config.guess on the build machine results in i486-pc-linux-gnu.
setarch i486 ./config.guess results in i686-pc-linux-gnu.
setarch i486 uname -m results in i686.

This breaks every build on i486!

/usr/bin/setarch is owned by util-linux 2.33.1-2.3 and is is completly broken!

And of course, it’s used in setarch “${arch}” mkarchroot in staging-i486-build.

So the consequenses are:
- devtools32 must NOT use setarch anywhere in the *i486* files
- the whole i486 toolchain and all packages have to be rebuilt (basically from the stage of last bootstrapping, every package above could contain bad opcodes!).

The irony is, that building just with makepkg on a emulated i486 virtual machine works
fine, using the devtools breaks things..
Admin
Andreas Baumann commented on 24.01.2019 21:11

Actually, thinking about it: I should try to patch setarch in coreutils for i486.
So we don’t have to fork devtools32 too much from upstream..

binutils and gcc have an explicit host and build flags, so they should be fine.
Maybe rebuilding just glibc with a fixed setarch is sufficient.
Admin
Andreas Baumann commented on 24.01.2019 21:15

If we are unlucky, utsname information in setarch.c is wrong and it’s not
a coreutils problem..
Admin
Andreas Baumann commented on 25.01.2019 08:05

The man page of setarch documents the bug:

The execution domains currently only affects the output of uname -m. For example, on an AMD64 sys-

     tem, running setarch i386 program will cause program to see i686 instead of x86_64 as  the  machine
     type.  It also allows to set various personality options.  The default program is /bin/sh.

So, we are not allowed to fix this, as other programs may rely on the bug.

So, fixing the devtools32 it is… Admin
Andreas Baumann commented on 25.01.2019 09:15

setarch bug reported here:

https://github.com/karelzak/util-linux/issues/707

and here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506632

uname -p reports unknown, this explains why config.guess relies
on uname -m to guess the CPU.

We came to those possible solutions:
- fix setarch.c (rather let it report something different than what the kernel is providing)
- add flags to devtools32 to switch off setarch usage (means, we can no longer build i486 on x86_64 slaves)
- add –build=i486-pc-linux-gnu in every configure call necessary
- go with the CLFS uname hack
- hack setarch of the host machine
Admin
Andreas Baumann commented on 27.01.2019 16:05

The CLFS uname hack solution.

http://trac.clfs.org/ticket/146

http://clfs.org/view/svn/ppc/chroot/before-chroot.html Admin
Andreas Baumann commented on 27.01.2019 18:04

wget http://clfs.org/files/extras/uname_hack-20080713.tar.bz2

PKGBUILD of linux:
_srcver=4.20.4-arch1
pkgver=${_srcver//-/.}
pkgrel=1.0
make modules_prepare

make -C /root/linux/src/archlinux-linux SUBDIRS=$PWD uname_hack_fake_machine=i486

insmod uname_hack.ko

setarch i486 uname -m
i686
setarch i486 ./config.guess
i686-pc-linux-gnu

Ok, the uname hack no longer works, or setarch doesn’t rely on this module information.

Google Cache

resolving dependencies...
warning: cannot resolve "libpulse.so=0-32", a dependency of "libao"
warning: cannot resolve "libpulse-simple.so=0-32", a dependency of "libao"
:: The following package cannot be upgraded due to unresolvable dependencies:
      libao

:: Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libpulse.so=0-32' required by libao
:: unable to satisfy dependency 'libpulse-simple.so=0-32' required by libao

12.04.2018 - io_queue_run.os: In function `io_queue_run’: io_queue_run.c:(.text+0×71): undefined reference to `__stack_chk_fail_local’ io_getevents.os: In …

01.05.2019 - Program terminated with signal SIGSEGV, Segmentation fault. #0 0xb30d3329 in getenv () from /usr/lib/libc.so.6 (gdb) bt #0 0xb30d3329 in …

Feb 12 11:57:48 arch32-testing-pentium4 audit[9829]: USER_LOGIN pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:48 arch32-testing-pentium4 kernel: audit: type=1112 audit(1613127468.816:104): pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:55 arch32-testing-pentium4 kaccess[9880]: Xlib XKB extension major= 1  minor= 0
Feb 12 11:57:56 arch32-testing-pentium4 kaccess[9880]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:57:58 arch32-testing-pentium4 kaccess[9880]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"
Feb 12 11:58:00 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"

re.so.8 error messages, re.so.9 is in stable

and then segfaults in libQt5WebEngineCore

Attached to Project: Archlinux32
Opened by Andreas Baumann - 13.07.2019
 FS#83  - kdeinit5 is filling the systemd journal with nonsensical messages

Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()

225 root      20   0  359832 225172 224128 S  24.5  29.5   0:45.52 systemd-journal 

Upstream too? Or is it fast enough if one core is dedicated to output
nonsensical output.. :-&gt;

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 07.07.2019
 FS#81  - KDE/Plasma crashes on startup (i686)

Application: ksplashqml (ksplashqml), signal: Aborted
Using host libthread_db library “/usr/lib/libthread_db.so.1”.
[Current thread is 1 (Thread 0xb21d5900 (LWP 427))]

Thread 3 (Thread 0xaa75cb40 (LWP 429)):
#0 0xb4b95418 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#1 0xb4b959f7 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0xb4b95be6 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3 0xb6e75ce5 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5
#4 0xb6e18ef5 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5
#5 0xb6c5fe1a in QThread::exec() () from /usr/lib/libQt5Core.so.5
#6 0xb66317c3 in ?? () from /usr/lib/libQt5Qml.so.5
#7 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#8 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#9 0xb697c25a in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0xb1a18b40 (LWP 428)):
#0 0xb7f6a82d in kernel_vsyscall ()
#1 0xb6972873 in poll () from /usr/lib/libc.so.6
#2 0xb550c6ce in ?? () from /usr/lib/libxcb.so.1
#3 0xb550e864 in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#4 0xb1bad3da in ?? () from /usr/lib/libQt5XcbQpa.so.5
#5 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#6 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#7 0xb697c25a in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0xb21d5900 (LWP 427)):
[KCrash Handler]
#6 0xb7f6a82d in kernel_vsyscall ()
#7 0xb68c4376 in raise () from /usr/lib/libc.so.6
#8 0xb68ae299 in abort () from /usr/lib/libc.so.6
#9 0xb6c1f873 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5
#10 0xb6387c44 in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5
#11 0xb64298d6 in QJSEngine::QJSEngine(QJSEnginePrivate&amp;, QObject*) () from /usr/lib/libQt5Qml.so.5
#12 0xb6575fcd in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5
#13 0xb6888bc4 in KDeclarative::QmlObjectSharedEngine::QmlObjectSharedEngine(QObject*) () from /usr/lib/libKF5Declarative.so.5
#14 0xb7f0fb00 in KQuickAddons::QuickViewSharedEngine::QuickViewSharedEngine(QWindow*) () from /usr/lib/libKF5QuickAddons.so.5
#15 0x0040a29b in ?? ()
#16 0x00408e7a in ?? ()
#17 0x004095a2 in ?? ()
#18 0x004081de in ?? ()
#19 0xb68af7b9 in __libc_start_main () from /usr/lib/libc.so.6
#20 0x004082e5 in _start ()
[Inferior 1 (process 427) detached]

Google Cache

07.07.2019 -  FS#80  - kate refuses to build due to some broken shared library dependencies. /usr/bin/ld: warning: libgit2.so.27, needed by …

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.05.2018
Last edited by Andreas Baumann - 23.01.2019
 FS#37  - ISO 2018.05.01 is not bootable with qemu or Virtualbox

I tried the i686 image. Booting leads to kernel panic.
Adding an explicit init=/lib/systemd/systemd parameter also panics.

qemu-system-i386 -cdrom archlinux-2018.05.01-i686.iso

It also panics in Virtualbox.

The same ISO works with libvirtd though.
Closed by Andreas Baumann
23.01.2019 18:29
Reason for closing: Fixed
Additional comments about closing:

works

  Comments (6)
  Related Tasks (0/0)

Admin
Tyzoid commented on 10.05.2018 10:49

i686 iso works fine in virtualbox on both a windows and linux host from my testing.
Admin
Tyzoid commented on 10.05.2018 11:04

Issue confirmed on qemu-system-i386 and qemu-system-x86_64. archlinux-2018.04.01-i686.iso fails to boot correctly as well.

Screenshot of the issue on i386 qemu: https://i.imgur.com/KRt21gI.png Screenshot of the issue on x86_64 qemu: https://i.imgur.com/wozM2hb.png Admin
Andreas Baumann commented on 11.05.2018 09:02

So /lib/systemd/systemd is either not found or cannot be executed, maybe because of a wrong
shared library dependency? I doubt it has to do with the kernel itself, as the log message
indicates the initial ram disk has been loaded.
Admin
Andreas Baumann commented on 16.06.2018 18:35

The write error indicates that the ramdisk could not be extracted.

So, if I start qemu with:

qemu-system-i386 -enable-kvm -cpu pentium3 -m 2048 -cdrom archlinux-2018.06.01-i686.iso

it works.

The default in qemu is 128MB Admin
Andreas Baumann commented on 16.06.2018 18:48

Sadly this is not the cause for VirtualBox, there it still fails even with 2048MB memory.
Admin
Andreas Baumann commented on 23.01.2019 18:18

The 2019.01.04 ISO works with Virtualbox 6.0.0.

Google Cache

root@arch32-stable-pentium4 ~]# iotop
No module named 'iotop'
To run an uninstalled copy of iotop,
launch iotop.py in the top directory

iotop is a Python script, presumably some Python modules are missing.

Seen with trojita:
Cannot mix incompatible Qt library (version 0x50d02) with this library (version 0x50d01)

+ exec setarch i486 systemd-nspawn -q -D /var/lib/archbuild/staging-i486/root -E PATH=/usr/local/sbin:/usr/local/bin:/usr/bin –register=no –keep-unit –as-pid2 –bind=/var/cache/archbuild32 pacman -Syuu –noconfirm
error: failed to initialize alpm library

Configuring attoparsec-0.13.2.4...
Error:
    The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used.
installed package tasty-1.3.1 is broken due to missing package ansi-terminal-0.11-2SXi8ZhU18i2uWLidRUotS, async-2.2.2-K8T9LglWxlG5HgD5vvGjbo, optparse-applicative-0.16.1.0-JDPEASK1GJS1Nsq2qjjZCq
installed package tasty-quickcheck-0.10.1.2 is broken due to missing package QuickCheck-2.14.2-io0WylueSG4seqSTUQCKM, optparse-applicative-0.16