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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1204067
Bug ID: 1204067
Summary: [Build 20220915] openQA test fails in grub_test since
upgrade of qemu-ovmf-x86_64 from 202008-150300.10.14.1
to 202202-150400.3.3
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
URL: https://openqa.opensuse.org/tests/2675825/modules/grub
_test/steps/15
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Bootloader
Assignee: screening-team-bugs(a)suse.de
Reporter: tina.mueller(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: openQA
Blocker: Yes
## Observation
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-nvme@uefi fails in
[grub_test](https://openqa.opensuse.org/tests/2675825/modules/grub_test/step…
## Test suite description
Maintainer: rbrown(a)suse.de; Basic installation test to confirm that installing
and booting to an nvme as your root disk works
## Reproducible
Fails since (at least) Build
[20220915](https://openqa.opensuse.org/tests/2675825) (current job)
## Expected result
Last good: [20220914](https://openqa.opensuse.org/tests/2663884) (or more
recent)
## Further details
Always latest result in this scenario:
[latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus…
We confirmed that the qemu-ovmf-x86_64 upgrade is the culprit, because after
downgrading again the test worked as expected.
We debugged the test and found out that after the installation in the test, the
reboot does show the boot menu of the installation medium again, instead of
offering to boot from hard disk, and selecting "Boot from Hard Disk" resulted
in showing the same installation medium menu again. Ejecting the CD before
reboot resulted in an error message:
BdsDxe: failed to load Boot0007 "opensuse-secureboot" from
HD(...)/\EFI\opensuse\shim.efi: Not found
We also have other tests failing, but in different ways, but this might still
be related.
The ticket for the mentioned failure can be found here:
https://progress.opensuse.org/issues/116704
Our workaround will be to downgrade all openQA workers and add a zypper lock.
--
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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1194723
Bug ID: 1194723
Summary: automatically add dkms module after kernel update
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: m.schenker(a)posteo.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Hi there,
for certain scenarios I sometimes rely on kernel modules added via dkms.
Initially installing them is as easy as the following.
cd module-folder
dkms install .
From other distributions I am used that the module gets re-added/rebuild during
a kernel update. However after a kernel update and reboot on Tumbleweed I just
receive a message like the following one.
modprobe: FATAL: Module vendor-reset not found in directory
/lib/modules/5.16.0-1-default
While the module still seems installed.
user@computer:~/vendor-reset> sudo dkms install .
Error! DKMS tree already contains: vendor-reset-0.1.1
You cannot add the same module/version combo more than once.
It is not available to the updated kernel.
There were two request for similar problems.
1. https://bugzilla.opensuse.org/show_bug.cgi?id=931175
Which resulted in a `don't care, won't fix
2. https://bugzilla.opensuse.org/show_bug.cgi?id=1184671
Which was ignored.
I have not created kernel modules myself, so if there is something that needs
to be done to the modules so they themselfs trigger an update I would be glad
for a nudge in the right direction.
However if there is something I would need to do in Tumbleweed I would be glad
for help as well.
I still see it as something that needs fixing since other Distributions, Arch,
Ubuntu handle this on their own.
Thank you!
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1089823
Bug ID: 1089823
Summary: YaST can silently fail to run snapper during
installation
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Installation
Assignee: yast2-maintainers(a)suse.de
Reporter: fvogt(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Created attachment 767377
--> http://bugzilla.suse.com/attachment.cgi?id=767377&action=edit
y2logs
Installation with the live media and snapshots enabled fails:
https://openqa.opensuse.org/tests/657353#step/await_install/21
This is because snapper is not installed in the installation system, so the
snapper installation-helper is missing.
So YaST needs to add a hard dependency there.
The bigger issue is that YaST didn't care that the binary is not present though
(found in y2log-3):
[libstorage] ActiongraphImpl.cc:584 Commit Action "Mounting /dev/vda2 at /"
[sid:59, first]
[libstorage] SystemCmd.cc:67 constructor
SystemCmd("/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'")
[libstorage] SystemCmd.cc:186 SystemCmd
Executing:"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:187 timestamp [295.985073], 2018-04-17 02:15:45 GMT,
2018-04-16 22:15:45 EDT
[libstorage] SystemCmd.cc:660 Adding Line 1 "/bin/sh:
/usr/lib/snapper/installation-helper: No such file or directory"
[libstorage] SystemCmd.cc:626 pid:4219 added lines:1 stderr:true
[libstorage] SystemCmd.cc:492 THROW: Command not found:
"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:416 stopwatch 0.010977s for
"/usr/lib/snapper/installation-helper --step '1' --device '/dev/vda2'
--description 'first root filesystem'"
[libstorage] SystemCmd.cc:436 system() Returns:127
[libstorage] SystemCmd.cc:678 stderr:/bin/sh:
/usr/lib/snapper/installation-helper: No such file or directory
[libstorage] SystemCmd.cc:67 constructor SystemCmd("/sbin/udevadm settle
--timeout=20")
As can be seen, YaST notices the error but ignores it. Similar output for step
2.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1191220
Bug ID: 1191220
Summary: New Let's Encrypt certificate cannot be verify in Mono
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
The following fails:
$ csharp -e 'new System.Net.WebClient ().DownloadString ("https://seznam.cz")'
System.Net.WebException: Error: TrustFailure (Authentication failed, see inner
exception.) ---> System.Security.Authentication.AuthenticationException:
Authentication failed, see inner exception. ---> Mono.Btls.MonoBtlsException:
Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
at
/home/abuild/rpmbuild/BUILD/mono-6.12.0.107/external/boringssl/ssl/handshake_client.c:1132
at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00048] in
<83dd749384734033afca92f4cfac782c>:0
at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake
(Mono.Net.Security.AsyncOperationStatus status, System.Boolean renegotiate)
[0x000da] in <83dd749384734033afca92f4cfac782c>:0
at (wrapper remoting-invoke-with-check)
Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake(Mono.Net.Security.AsyncOperationStatus,bool)
at Mono.Net.Security.AsyncHandshakeRequest.Run
(Mono.Net.Security.AsyncOperationStatus status) [0x00006] in
<83dd749384734033afca92f4cfac782c>:0
at Mono.Net.Security.AsyncProtocolRequest.ProcessOperation
(System.Threading.CancellationToken cancellationToken) [0x000fc] in
<83dd749384734033afca92f4cfac782c>:0
--- End of inner exception stack trace ---
at Mono.Net.Security.MobileAuthenticatedStream.ProcessAuthentication
(System.Boolean runSynchronously,
Mono.Net.Security.MonoSslAuthenticationOptions options,
System.Threading.CancellationToken cancellationToken) [0x00262] in
<83dd749384734033afca92f4cfac782c>:0
at Mono.Net.Security.MonoTlsStream.CreateStream
(System.Net.WebConnectionTunnel tunnel, System.Threading.CancellationToken
cancellationToken) [0x0016a] in <83dd749384734033afca92f4cfac782c>:0
at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation,
System.Boolean reused, System.Threading.CancellationToken cancellationToken)
[0x001ba] in <83dd749384734033afca92f4cfac782c>:0
--- End of inner exception stack trace ---
at System.Net.WebConnection.CreateStream (System.Net.WebOperation operation,
System.Boolean reused, System.Threading.CancellationToken cancellationToken)
[0x0021a] in <83dd749384734033afca92f4cfac782c>:0
at System.Net.WebConnection.InitConnection (System.Net.WebOperation
operation, System.Threading.CancellationToken cancellationToken) [0x00141] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.WebOperation.Run () [0x0009a] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.WebCompletionSource`1[T].WaitForCompletion () [0x00094] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.HttpWebRequest.RunWithTimeoutWorker[T]
(System.Threading.Tasks.Task`1[TResult] workerTask, System.Int32 timeout,
System.Action abort, System.Func`1[TResult] aborted,
System.Threading.CancellationTokenSource cts) [0x000f8] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.HttpWebRequest.GetResponse () [0x00016] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.WebClient.GetWebResponse (System.Net.WebRequest request)
[0x00000] in <83dd749384734033afca92f4cfac782c>:0
at System.Net.WebClient.DownloadBits (System.Net.WebRequest request,
System.IO.Stream writeStream) [0x000e6] in <83dd749384734033afca92f4cfac782c>:0
at System.Net.WebClient.DownloadDataInternal (System.Uri address,
System.Net.WebRequest& request) [0x00061] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.WebClient.DownloadString (System.Uri address) [0x00011] in
<83dd749384734033afca92f4cfac782c>:0
at System.Net.WebClient.DownloadString (System.String address) [0x00008] in
<83dd749384734033afca92f4cfac782c>:0
at <InteractiveExpressionClass>.Host (System.Object& $retval) [0x00006] in
<bab8bbbe52954fd79168395f7636506e>:0
at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object&
result, System.Boolean& result_set) [0x00038] in
<dc18f8c1f3e14d9a83758fe12bb22a10>:0
at Mono.CSharpShell.Evaluate (System.String input) [0x00000] in
<a01f5168c3824ddfb7cf74041d74890a>:0
It's discussed in the upstream issue: https://github.com/mono/mono/issues/12406
But I cannot fix it with:
sudo cert-sync /etc/ssl/certs/ca-certificates.crt
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133305
Bug ID: 1133305
Summary: LTO: multipath-tools 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.wilck(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
in the LTO staging project (openSUSE:Factory:Staging:N), libaio doesn't export
all symbols it used to export. In particular, io_cancel() and io_getevents()
are undefined:
apollon:/mnt/img/lib64 # nm -D libaio.so.1
0000000000000000 A LIBAIO_0.1
0000000000000000 A LIBAIO_0.4
U __stack_chk_fail
U io_cancel
0000000000001050 T io_destroy
U io_getevents
0000000000001110 T io_queue_init
0000000000001100 T io_queue_release
0000000000001080 T io_queue_run
0000000000001060 T io_setup
0000000000001070 T io_submit
This causes the multipath-tools build to fail. The failure is independent on
whether -flto=X is active while building multipath-tools itself.
> [ 50s] gcc -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -flto=4 -g -DBIN_DIR=\"/sbin\" -DLIB_STRING=\"lib64\" -DRUN_DIR=\"run\" -MMD -MP -fPIE -I../libmultipath -I../libmpathcmd main.o -o multipath -Wl,-z,relro -Wl,-z,now -pie -L../libmultipath -lmultipath -L../libmpathcmd -lmpathcmd -lpthread -ldevmapper -ldl -ludev -laio
> [ 50s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../libmultipath/libmultipath.so: undefined reference to `io_getevents'
> [ 50s] /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ../libmultipath/libmultipath.so: undefined reference to `io_cancel''
> [ 50s] collect2: error: ld returned 1 exit status
> [ 50s] make[1]: *** [Makefile:18: multipath] Error 1
--
You are receiving this mail because:
You are on the CC list for the bug.