http://bugzilla.opensuse.org/show_bug.cgi?id=1142586
Bug ID: 1142586
Summary: LTO: gstreamer-plugins-base build fails on aarch64
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails here:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:ARM/gstr…
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1138813
Bug ID: 1138813
Summary: LTO: libsepol build fails
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails due to symbol versioning:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:…
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133278
Bug ID: 1133278
Summary: LTO: pulseaudio build fails
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails due to:
libtool: error: not configured to extract global symbols from dlpreopened
files
<artificial>:(.text+0x1643): undefined reference to
`lt__PROGRAM__LTX_preloaded_symbols'
<artificial>:(.text+0x164f): undefined reference to
`lt__PROGRAM__LTX_preloaded_symbols'
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1117095
Bug ID: 1117095
Summary: vc4: Failed to allocate from CMA, graphics freezes
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: aarch64
OS: openSUSE Factory
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-maintainers(a)forge.provo.novell.com
Reporter: jimc(a)math.ucla.edu
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
On a Raspberry Pi 3B (not plus) with OpenSuSE Tumbleweed
openSUSE-release-20181101-934.1.aarch64 and
kernel-default-4.18.15-1.2.aarch64. Kernel command line (/proc/cmdline):
BOOT_IMAGE=/boot/Image-4.18.15-1-default
root=UUID=38fbf451-5579-43d1-bdd2-84cfd886ad00
loglevel=3 splash=silent plymouth.enable=0 swiotlb=512 cma=300M
console=ttyS1,115200n8 console=tty resume=/dev/mmcblk0p3
/boot/efi/config.txt (minus comments):
kernel=u-boot.bin
gpu_mem=32
force_turbo=0
initial_turbo=30
over_voltage=0
enable_uart=1
avoid_warnings=1
dtoverlay=upstream +upstream-mmc +upstreame-aux-interrupt
include ubootconfig.txt
arm_control=0x200
include extraconfig.txt
dtparam=audio=on
dtoverlay=vc4-kms-v3d (similar symptom with vc4-fkms-v3d)
/etc/X11/xorg.conf.d/20-kms.conf says:
Section "Device"
Identifier "kms gfx"
Driver "modesetting"
#Option "AccelMethod" "none" [Commented out]
EndSection
/var/log/Xorg.0.log says:
modeset(0): [DRI2] DRI driver: vc4
AIGLX: Loaded and initialized vc4
GLX: Initialized DRI2 GL provider for screen 0
In this configuration, glmark2-0.0+git.20180608-1.1.aarch64
runs without freezing or crashing and gets an overall score of 74,
whereas with software rendering the score is 17, so GPU acceleration is
really happening.
>From the LightDM greeter I log in and start the default XFCE desktop.
I start various programs and eventually get the symptom complained about;
in the simplest case I start one xterm, one xload -update 2 (secs), and
xscreensaver-5.37-4.3.aarch64 is active, blanking the screen only, DPMS
off after 20 min. I let it incubate overnight.
At the start, CmaTotal (from /proc/meminfo) is 307200kB and CmaFree
is 206856 kB; CmaFree went up gradually to 241684 kB by the time the
screensaver shut off video (DPMS).
After 5 hours CmaFree was static at 234252 kB. With no change in CmaFree
this message appeared in syslog:
Nov 22 01:15:25 orion kernel: [34890.524661] [drm:vc4_bo_create [vc4]]
*ERROR* Failed to allocate from CMA:
Nov 22 01:15:25 orion kernel: [34890.524683] [drm] kernel: 8100kb BOs (1)
Nov 22 01:15:25 orion kernel: [34890.524691] [drm] V3D: 26904kb BOs
(121)
Nov 22 01:15:25 orion kernel: [34890.524699] [drm] V3D shader: 272kb BOs (65)
Nov 22 01:15:25 orion kernel: [34890.524706] [drm] dumb: 48kb BOs (3)
Nov 22 01:15:25 orion kernel: [34890.524713] [drm] binner: 16384kb BOs (1)
Nov 22 01:15:25 orion kernel: [34890.524721] [drm] total purged BO: 8kb BOs (2)
Nov 22 01:15:25 orion kernel: [34890.524741] vc4_v3d 3fc00000.v3d: Failed to
allocate memory for tile binning: -12. You may need to enable CMA or
give it more memory.
In other tests this message appears at the same time that graphics freezes.
When I woke up the screensaver, video came on, but the screen was black,
except the cursor was visible, confined within the screensaver's
authentication box. In other tests the screen content at the time of
freezing remains unchanging, but the cursor changes shape according to
what it's over, including not changing shape if the program (e.g. xterm)
owning the window was killed. Keystrokes directed to an xterm are
received and executed (with no visible effect on the screen), e.g.
"echo Test File > /tmp/testfile", and the file appears. I can do
"DISPLAY=:0 XAUTHORITY=/run/lightdm/root/:0 xwd -root > image.xwd"
and the image will be complete and will show the current windows, not
those at the time of freezing.
The same symptoms can be elicited quicker if I run Firefox or Chromium.
Heavy work in the browser did not seem to make the failure happen earlier;
the 2 tests (one after the other) were to scroll quickly through 1.16Mb of
text/html (no Javascript nor images), then 221 JPEG images in simple
HTML pages. The freeze typically happens when I am doing nothing on the
RPi, writing up notes on another machine. With either web browser, but
not in the simple test case, CmaFree declined in non-reproducible
patterns until the freeze occurred, and continued to decline to near
zero (like 3000kB). I believe that this "death spiral" behavior is
consequential damage from something freezing up, not the actual cause of
the freeze.
This is a known bug, though the exact symptoms seem to change with small
variations in the test conditions, and with one or another kernel commit
being excluded.
https://github.com/raspberrypi/linux/issues/2680 (2018-09-12, OP cbxbiker61)
He reports it began for him with approx. kernel 4.14.62 and someone else
reports that it's still there in 4.18.11. Jimc sees it in 4.18.15 .
Other forum and bug posters in various distros (Arch, Red Hat) report
various similar-sounding problems, starting around 2018-09-xx.
Could the SuSE distro managers please identify a combination of commits
that gives the best results in the OpenSuSE context and push out that
kernel, and keep an eye on progress in finding and killing the actual
bug that is causing these freezeups? Thank you.
I'm going to try to do the same thing, and I'll report back if I succeed,
not a sure thing given my limited skills with git.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1138833
Bug ID: 1138833
Summary: LTO: libxcrypt build fails
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails due to symbol versioning:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:…
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1156301
Bug ID: 1156301
Summary: Dovecot fails to build with LTO enabled in Tumbleweed
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: suse+build(a)de-korte.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Since enabling LTO in Tumbleweed, the dovecot23 package fails to build most of
the time with
[ 133s] libtool: link: gcc -std=gnu99 -O2 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -flto=auto -g -I/usr/lib64 -fpic
-DPIC -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-mfunction-return=thunk -mindirect-branch=thunk -Wall -W -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2
-Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2
-DOPENSSL_LOAD_CONF -flto=auto -o test-iostream-ssl test-iostream-ssl.o -pie
./.libs/libssl_iostream_openssl.so ./.libs/libssl_iostream.a
../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lssl -lcrypto -ldl
-Wl,-rpath
-Wl,/home/abuild/rpmbuild/BUILD/dovecot-2.3.8/src/lib-ssl-iostream/.libs
-Wl,-rpath -Wl,/usr/lib64/dovecot/modules
[ 136s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
test-iostream-ssl: hidden symbol `t_str_new' in
/tmp/test-iostream-ssl.X2QBZZ.ltrans0.ltrans.o is referenced by DSO
[ 136s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: final
link failed: bad value
[ 136s] collect2: error: ld returned 1 exit status
[ 136s] make[3]: *** [Makefile:637: test-iostream-ssl] Error 1
Without changing anything, the build completes, but this is a rare occurrence.
Disabling LTO solves the build problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1197954
Bug ID: 1197954
Summary: systemd-cryptsetup: Device root is still in use.
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: opensuse(a)mike.franken.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Starting with the Tumbleweed snapshot installed on March, 29th I got back an
old error
systemd-cryptsetup: Device root is still in use.
systemd-cryptsetup: Failed to deactivate: Device or resource busy
which shows up in the journal after switching root.
I am not sure, but I believe that the reason for this is
systemd[1]: plymouth-start.service: Unit process 394 (plymouthd) remains
running after unit stopped.
systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped
because of a failed condition check (ConditionPathExists=!/run/plymouth/pid).
which shows up in the journal just before the "in use" message.
So plymouth didn't stop and the encrypted filesystem couldn't be unmounted.
Before the last two snapshots the message looked like this:
systemd[1]: Condition check resulted in Dispatch Password Requests to Console
Directory Watch being skipped.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1178233
Bug ID: 1178233
Summary: zypper up does not report any updates in WSL after
longer pause
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.2
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: WSL
Assignee: sle-ms(a)suse.de
Reporter: lubos.kocman(a)suse.com
QA Contact: qa-c(a)suse.de
Found By: ---
Blocker: ---
I do have WSL images with Leap 15.2 and it seems that zypper doesn't register
outdated repodata cache.
Let's say that I'd start WSL image (bash session) once per two weeks, and if I
simply run "zypper up" after these two weeks zypper reports no update, until I
clean repodata
I didn't call refresh simply up && clean --all && up
and that worked fine. However I'd like to avoid situation when zypper simply
reports no update with sporadically WSL use and user gets to believe it.
My initial thought it's that this is caused by not having any services running
inside the "container", however Ludwig things something might be wrong with the
date/time inside the image.
--
You are receiving this mail because:
You are on the CC list for the bug.