(In reply to Giuseppe Ghibò from comment #0)

> This is a new and bug release in the 560.xx series. Bug fixes:

s/bug release/bug fix release/

Created attachment 14675 [details]
files list

files list

MGA9-64 Plasma, i5-7500, Nvidia Quadro K620 graphics, server and desktop kernels.

Updated nvidia-current first, and that was OK with both kernels, but...

When I attempted to use MCC to switch to the newfeature driver, I get a message that x11-driver-video-nvidia-newfeature cannot be installed due to unsatisfied libgbm.so.1.

So I didn't get very far.

CC: (none) => andrewsfarm

(In reply to Thomas Andrews from comment #3)
> MGA9-64 Plasma, i5-7500, Nvidia Quadro K620 graphics, server and desktop
> kernels.
> 
> Updated nvidia-current first, and that was OK with both kernels, but...
> 
> When I attempted to use MCC to switch to the newfeature driver, I get a
> message that x11-driver-video-nvidia-newfeature cannot be installed due to
> unsatisfied libgbm.so.1.
> 
> So I didn't get very far.

Looks like this need mesa packages in testing

Depends on: (none) => 33571

I see that as a possibility, after a bit of investigation.

But should it be needing that specific libgbm.so.1? The current tainted version of the package is installed, and the nvidia-current candidate was OK with it.

that libgbm.so.1 required should be in the 32bit repo (either core or tainted).

So in order to install the newfeature driver on a 64-bit system, you have to activate the 32-bit repos? It can't use the libgbm.so.1 that's a file in the lib64gbm1 (tainted or core) package?

That doesn't sound right.

I updated to the 64-bit core mesa packages, and tried installing the newfeature driver again without activating the 32-bit repos. Now it says it needs libdrm.so.2. There's one of them in the lib64drm2 package, installed in /usr/lib64, as is libgbm.so.1.

Could it be looking for these libraries in the wrong spot?

Have to figure out why it triggered a new dep of a 32bit library, at least for the non-full package, and eventually filter out the dependency from the main package, also because *-newfeature would be, at some point, the next *-current series. In the meanwhile see if adding 32bit repos would fix the problem.

After adding the 32-bit repos, XFdrake downloaded some 32-bit packages, but it happened too fast to see what they were. The newfeature driver installed successfully, and looks OK on a quick check after the reboot, except that autologin was again disabled, like it was the last time we tried a newfeature driver.

It's weird the autologin missed. Maybe crashed some process. We might try to collect some core, enabling core generation with:

sysctl -w kernel.core_uses_pid=0
sysctl -w kernel.core_pattern="/var/tmp/%e_%t_%s_uid%u.core"

[this is volatile, so next boot is disabled]

then try to see whether with autologin, some core, in /var/tmp/ is generated.

(In reply to Thomas Andrews from comment #10)

> it happened too fast to see what they were. The newfeature driver installed

journalctl -b | grep -e \\[RPM\\]

should show what happening on package installing (but I'm pretty sure there is some other "proper" journalctl option to see that info in a more fashioned way...).

(In reply to Giuseppe Ghibò from comment #11)
> It's weird the autologin missed. Maybe crashed some process. We might try to
> collect some core, enabling core generation with:
> 
> sysctl -w kernel.core_uses_pid=0
> sysctl -w kernel.core_pattern="/var/tmp/%e_%t_%s_uid%u.core"
> 
> [this is volatile, so next boot is disabled]
> 
> then try to see whether with autologin, some core, in /var/tmp/ is generated.

Oops, I forgot that at the autologin you won't have the console prompt where to type such commands, so we have to find another way...

Created attachment 14682 [details]
journal with autologin disabled

For what it's worth, a journal created within a few minutes of booting with autologin having been disabled

(In reply to Giuseppe Ghibò from comment #11)
> It's weird the autologin missed. Maybe crashed some process. We might try to
> collect some core, enabling core generation with:
> 
> sysctl -w kernel.core_uses_pid=0
> sysctl -w kernel.core_pattern="/var/tmp/%e_%t_%s_uid%u.core"
> 
> [this is volatile, so next boot is disabled]
> 
> then try to see whether with autologin, some core, in /var/tmp/ is generated.

While digging into this I found a sort of bug in our systemd package that made our core dump experience "incomplete". We had this line:

https://svnweb.mageia.org/packages/updates/9/systemd/current/SPECS/systemd.spec?revision=2087162&view=markup#l405

(ditto for cauldron) which we disabled proper systemd core dumps at some point (probably because at that time that feature was incomplete in systemd) and then remained as is our next releases. This feature has been perfectioned in systemd upstream so I think we should re-enable it in next systemd builds.

Anyway, for now to get coredumps just add a file /etc/sysctl.d/99-coredump.conf containing the lines:

kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit=16
fs.suid_dumpable=2

then reboot. If some program crashes it creates a core, and you can catch with

coredumpctl list