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.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133233
Bug ID: 1133233
Summary: LTO: libaio 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: ---
The package delivers a static library and should use fat LTO objects:
https://en.opensuse.org/openSUSE:LTO#Static_libraries
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133277
Bug ID: 1133277
Summary: LTO: protobuf abuild 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:
[ 233s] + ../src/protoc --java_out=core/src/main/java -I../src
../src/google/protobuf/descriptor.proto
[ 233s] terminate called after throwing an instance of 'std::system_error'
[ 233s] what(): Unknown error -1
[ 233s] /var/tmp/rpm-tmp.IcJGkF: line 61: 9707 Aborted
../src/protoc --java_out=core/src/main/java -I../src
../src/google/protobuf/descriptor.proto
#0 0x00007ffff7e3fd8b in raise () from /lib64/libc.so.6
#1 0x00007ffff7e29549 in abort () from /lib64/libc.so.6
#2 0x00007ffff7aad63f in ?? () from /usr/lib64/libstdc++.so.6
#3 0x00007ffff7ab8f38 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00007ffff7ab8f83 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x00007ffff7ab91b4 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x00007ffff7ab0156 in std::__throw_system_error(int) () from
/usr/lib64/libstdc++.so.6
#7 0x00007ffff792741b in std::call_once<void (&)()> (__once=...,
__f=<optimized out>) at
/usr/include/c++/9/x86_64-suse-linux/bits/gthr-default.h:700
#8 0x00007ffff77fbb83 in global constructors keyed to
65535_0_bytestream.o.132584 () at ./google/protobuf/repeated_field.h:428
#9 0x00007ffff7fe276a in call_init.part () from /lib64/ld-linux-x86-64.so.2
#10 0x00007ffff7fe2866 in _dl_init () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff7fd40ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#12 0x0000000000000004 in ?? ()
#13 0x00007fffffffeb14 in ?? ()
#14 0x00007fffffffeb50 in ?? ()
#15 0x00007fffffffeb6e in ?? ()
#16 0x00007fffffffeb77 in ?? ()
#17 0x0000000000000000 in ?? ()
https://github.com/protocolbuffers/protobuf/issues/5923
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194809
Bug ID: 1194809
Summary: Possible password leak by windows stealing focus
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: GNOME
Assignee: gnome-bugs(a)suse.de
Reporter: martin.wilck(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Yesterday I lost (luckily only part of) an important password as follows:
I was running pidgin as IRC client. pidgin was configured to autoconnect to
some channels on irc.suse.de. I activated the SUSE VPN via the GNOME VPN panel.
I continued working in the terminal.
I ran a command in the terminal that required typing a password (as usual in
terminal applications, typing passwords provides no visual feedback like
"***"). I pressed "enter" and nothing happened. At this point I realized that
the 2nd half of the password had ended up in the pidgin window.
What happened? If an IRC server is unreachable, pidgin polls in the background
in a certain interval (a few minutes I think). When the server becomes
reachable, it connects to it, which causes the typical startup dialog &
messages ("You are connected to irc1.suse.de ....") to be displayed. At this
moment, the pidgin window pops up and grabs the keyboard focus. As the window
is relatively small and my screen is large, and I was looking at the keyboard
while typing (because I usually do when typing passwords), I didn't notice this
immediately, and typed part of the password to the pidgin window.
This is particularly nasty, because after establishing the VPN connection, the
window pops up after a non-deterministic time interval which is between a few
seconds and ~5 minutes. You can't "wait" for this to happen, and if you don't,
you're likely to forget that the connection process is going on in the
background.
Also, making matters worse, when the pidgin window pops up because of a message
in some chat, the focus isn't necessarily in the chat (tab in the pidgin
window) that caused the pop-up, but in some currently selected chat. In the
case at hand, I'd typed my password at to libera.chat's "NickServ" bot (which
didn't recongnize it as command, but might have logged what I typed).
For the time being, I've disabled the "auto-join" feature for all pidgin
channels on irc.suse.de. But I'm unsure if that actually helps, because I
believe that pidgin would try to connect to IRC accounts nonetheless, and if it
does, the typical login / connect dialogs might cause the window to pop up even
if no chats are configured to connect automatically.
See also
https://askubuntu.com/questions/1084032/how-to-prevent-new-windows-from-ste…
There someone suggests using
> gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict'
I've tried that setting on TW (GNOME 41.3) and saw no change in behavior.
A simple test is typing something like this in the terminal:
> $ gedit &
> $ abcdefg.... # continue typing
At some point, gedit will pop up and the text will end up in the gedit window.
Note that this happens with gedit but not e.g. with emacs or libreoffice
writer. So it depends on the application. Also, some applications (e.g. the ssh
and gpg askpass tools) use a different API that does this much better - the
entire screen gets locked and changes color, so that typing something at the
wrong window is practically impossible. This behavior would be inapparopriate
for an application like gedit, though.
The behavior of gedit and pidgin under GNOME is highly dangerous. I've reason
to believe that other Window Managers (or X in general) behave similarly.
--
You are receiving this mail because:
You are on the CC list for the bug.