Hi, Just a query first off, why do I need to run dmesg under sudo for it to produce its output?
Could someone explain the systemd message below as to why they are coming out rather than the package being updated as specified in the message. The device non-existant errors and the lockd errors can be ignored as the device in question is my nas device which every so often seems to turn itself off logically rather than physically. Although having said this both the fstab nfs and cifs mount points for the device in question have actually been mounted. Is the nvidia API mismatch because the Xorg nvidia drivers were updated with the update I did and I haven't rebooted yet? Also could someone tell what I need to do to investigate the steam failure after the update, which I think updated libc.
[ 2128.005544] lockd: server 192.168.1.12 not responding, still trying [ 2142.534787] systemd-sysv-generator[23295]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 2142.534792] systemd-sysv-generator[23295]: Please update package to include a native systemd unit file. [ 2142.534794] systemd-sysv-generator[23295]: ! This compatibility logic is deprecated, expect removal soon. ! [ 2142.534813] systemd-sysv-generator[23295]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 2142.534815] systemd-sysv-generator[23295]: Please update package to include a native systemd unit file. [ 2142.534817] systemd-sysv-generator[23295]: ! This compatibility logic is deprecated, expect removal soon. ! [ 2142.536593] systemd-fstab-generator[23284]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device. [ 2142.539639] systemd-fstab-generator[23284]: Checking was requested for "//192.168.1.12/Volume_1", but it is not a device. [ 2144.206749] systemd-fstab-generator[23509]: Checking was requested for "192.168.1.12:/mnt/HD/HD_a2", but it is not a device. [ 2144.210249] systemd-sysv-generator[23520]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 2144.210254] systemd-sysv-generator[23520]: Please update package to include a native systemd unit file. [ 2144.210256] systemd-sysv-generator[23520]: ! This compatibility logic is deprecated, expect removal soon. ! [ 2144.210291] systemd-sysv-generator[23520]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file, automatically generating a unit file for compatibility. [ 2144.210294] systemd-sysv-generator[23520]: Please update package to include a native systemd unit file. [ 2144.210296] systemd-sysv-generator[23520]: ! This compatibility logic is deprecated, expect removal soon. ! [ 2144.211598] systemd-fstab-generator[23509]: Checking was requested for "//192.168.1.12/Volume_1", but it is not a device. [ 2397.125803] lockd: server 192.168.1.12 OK [ 2465.414749] lockd: server 192.168.1.12 not responding, still trying
[ 3055.581655] NVRM: API mismatch: the client has the version 570.124.04, but NVRM: this kernel module has the version 570.86.16. Please NVRM: make sure that this kernel module and all NVIDIA driver NVRM: components have the same version. [ 3055.633215] show_signal_msg: 9 callbacks suppressed [ 3055.633216] steam[32814]: segfault at 0 ip 00000000f7c6a503 sp 00000000ffab08a8 error 4 in libc.so.6[89503,f7be2000+160000] likely on CPU 1 (core 1, socket 0)
regards, Steve
Stephen Morris wrote:
Just a query first off, why do I need to run dmesg under sudo for it to produce its output?
In Fedora 39 (or there about), the CONFIG_SECURITY_DMESG_RESTRICT kernel config was changed. The commit in the Fedora kernel source tree provides some useful details¹:
Turn on SECURITY_DMESG_RESTRICT
It was requested by ProdSec that we enable SECURITY_DMESG_RESTRICT as this makes several security bugs more difficult to exploit. It should be noted that this just controls the default setting of kernel.dmesg_restrict sysctl and thus can be always set back to 0 at runtime. Users in the wheel group also have access to journalctl -k or sudo for dmesg access without giving it to every user on the system.
¹ https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c6
On 2025-03-16 15:23, Stephen Morris wrote:
Is the nvidia API mismatch because the Xorg nvidia drivers were updated with the update I did and I haven't rebooted yet?
[ 3055.581655] NVRM: API mismatch: the client has the version 570.124.04, but NVRM: this kernel module has the version 570.86.16. Please NVRM: make sure that this kernel module and all NVIDIA driver NVRM: components have the same version.
Yes, you're using the updated userspace drivers, but the kernel module is an older version.
On 17/3/25 17:42, Samuel Sieb wrote:
On 2025-03-16 15:23, Stephen Morris wrote:
Is the nvidia API mismatch because the Xorg nvidia drivers were updated with the update I did and I haven't rebooted yet?
[ 3055.581655] NVRM: API mismatch: the client has the version 570.124.04, but NVRM: this kernel module has the version 570.86.16. Please NVRM: make sure that this kernel module and all NVIDIA driver NVRM: components have the same version.
Yes, you're using the updated userspace drivers, but the kernel module is an older version.
Thanks Samuel, I didn't notice whether there was a compile of the equivalent nvidia kernel module as part of the update, but after posting this message I rebooted and the colour display from SDDM and KDE was pathetic. It looked like the brightness and contrast settings had been turned down. I did issue DMESG after the reboot and there were messages in there about the nvidia module tainting the kernel so I assume it was updated as well. Also a couple of reboots after this the colour display issues went back to normal, so I don't know why I got the issue on the first reboot after the update.
regards, Steve
On 17/3/25 09:38, Todd Zullinger wrote:
Stephen Morris wrote:
Just a query first off, why do I need to run dmesg under sudo for it to produce its output?
In Fedora 39 (or there about), the CONFIG_SECURITY_DMESG_RESTRICT kernel config was changed. The commit in the Fedora kernel source tree provides some useful details¹:
Turn on SECURITY_DMESG_RESTRICT It was requested by ProdSec that we enable SECURITY_DMESG_RESTRICT as this makes several security bugs more difficult to exploit. It should be noted that this just controls the default setting of kernel.dmesg_restrict sysctl and thus can be always set back to 0 at runtime. Users in the wheel group also have access to journalctl -k or sudo for dmesg access without giving it to every user on the system.¹ https://gitlab.com/cki-project/kernel-ark/-/commit/ed5ba266c6
Thanks Todd, it's been quite a while since I've used DMESG, but I don't remember ever having to use sudo with it, nor do I remember ever seeing the message about kernel buffer access being denied, but it just means I will now have to always remember to use sudo with it. Although logically it doesn't make sense to me, it is only a read so what damage can a read do, but then there are also folders under /etc that you can't issue an LS against without sudo, so I guess it's just the same thing.
regards, Steve
On Tue, 2025-03-18 at 08:43 +1100, Stephen Morris wrote:
Thanks Todd, it's been quite a while since I've used DMESG, but I don't remember ever having to use sudo with it, nor do I remember ever seeing the message about kernel buffer access being denied, but it just means I will now have to always remember to use sudo with it. Although logically it doesn't make sense to me, it is only a read so what damage can a read do, but then there are also folders under /etc that you can't issue an LS against without sudo, so I guess it's just the same thing.
It didn't need sudo in the past, but now it does. So you are remembering correctly.
Supposedly, it could show an ordinary user something they shouldn't know, hence the increased security, now.
On 18 Mar 2025, at 07:29, Tim via users users@lists.fedoraproject.org wrote:
Supposedly, it could show an ordinary user something they shouldn't know, hence the increased security, now.
As I understand the risk it is the presences of addresses in dmesg output of kernel internals that are required for attacking the kernel.
Barry
Tim:
Supposedly, it could show an ordinary user something they shouldn't know, hence the increased security, now.
Barry:
As I understand the risk it is the presences of addresses in dmesg output of kernel internals that are required for attacking the kernel.
I couldn't remember what it was.
And I suppose I should have said, more so than showing privileged info to ordinary *users*, that it could be handing such data to any malicious or compromised programs.
On 18/3/25 18:28, Tim via users wrote:
On Tue, 2025-03-18 at 08:43 +1100, Stephen Morris wrote:
Thanks Todd, it's been quite a while since I've used DMESG, but I don't remember ever having to use sudo with it, nor do I remember ever seeing the message about kernel buffer access being denied, but it just means I will now have to always remember to use sudo with it. Although logically it doesn't make sense to me, it is only a read so what damage can a read do, but then there are also folders under /etc that you can't issue an LS against without sudo, so I guess it's just the same thing.
It didn't need sudo in the past, but now it does. So you are remembering correctly.
Supposedly, it could show an ordinary user something they shouldn't know, hence the increased security, now.
It depends on what environment you are in, if you are in an organisational environment then it is possible that it may show something that is sensitive (although I work in an environment where there are areas of the organisation that work with data they consider to be sensitive enough that even organisation admins shouldn't have visibility of it, only they should), but in a home environment that level of sensitivity doesn't really apply.
regards, Steve
Tim:
Supposedly, it could show an ordinary user something they shouldn't know, hence the increased security, now.
Stephen Morris:
It depends on what environment you are in, if you are in an organisational environment then it is possible that it may show something that is sensitive (although I work in an environment where there are areas of the organisation that work with data they consider to be sensitive enough that even organisation admins shouldn't have visibility of it, only they should), but in a home environment that level of sensitivity doesn't really apply.
Upon reflection, I think it's more about limiting things that aren't really under your control (what some program can do behind the scenes). The user can always sudo to see that information, applications can't (not without your help).
Everywhere else applications are becoming more and more spyware in nature. At some stage they're going to try it on us, too. Better to nip it in the bud.
Look at web browsers, for instance. They spew out far more data about you than is necessary to do the job. Much of it is used to fingerprint and database you. That should have been nipped in the bud many years ago.
-
Barry -
Samuel Sieb -
Stephen Morris -
Tim -
Todd Zullinger