| 2016-04-29 13:26:29 |
Alberto Milone |
description |
I suppose this is a fairly significant bug, since it renders gpu-manager virtually useless.
I found it in ubuntu-drivers-common 0.4.17 (which is the current version in Ubuntu 16.04), and I do not know whether it is also present in other versions.
-- Symptoms --
For some reason, on my machine I frequently insert and remove my nvidia graphics adapter. My processor has an intel HD graphics adapter as well, so I rely on gpu-manager to detect my hardware configuration during boot, and update alternatives appropriately.
However, since I upgraded to Ubuntu 16.04, reconfiguring my hardware makes me unable to boot to desktop. However, reverting to previous hardware configuration solves the issue.
-- Analysis and proposed solution --
A quick check of symbolic links at /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf and similar confirms that when I change my hardware configuration, no changes are done to the targets of these links. Reading through gpu-manager.log I can see that it detects my hardware correctly, but it fails to configure alternatives, because:
Error: no alternative found for nvidia
Warning: no EGL alternative found for nvidia
Further investigation shows that the problem is with the get_alternative_link() function, as it always returns NULL, regardless of my current hardware configuration, and function arguments.
The get_alternative_link() function works by querying the list of available alternatives by running `update-alternatives` command with `--list` argument. The command is prepared by:
snprintf(command, sizeof(command),
"update-alternatives --list %s_%s_conf",
alternative_pattern, arch_path);
For example, when looking for "gl" alternatives for architecture "x86_64-linux-gnu", the resulting command will be:
update-alternatives --list gl_x86_64-linux-gnu_conf
This command always returns an empty list, and that is correct. The command is clearly malformed, the intention was to run another command, namely:
update-alternatives --list x86_64-linux-gnu_gl_conf
(note the order of "gl" vs "x86_64_linux_gnu")
Indeed the `snprintf` used to prepare the command has it's arguments swapped. Therefore I propose to substitute the mentioned source code with:
snprintf(command, sizeof(command),
"update-alternatives --list %s_%s_conf",
arch_path, alternative_pattern);
Applying the proposed change reliably fixes the bug symptoms I experienced.
-- Additional comment --
For your convenience, I attached to this bug report a patch file that applies the proposed solution; the patch is intended for ubuntu-drivers-common 0.4.17 source.
As far as I can tell, due to these swapped arguments gpu-manager always looks for unexisting alternatives, and therefore there is no scenario in which it would correctly configure alternatives. I suppose in this case gpu-manager always fails to serve its purpose. I find it astonishing that nobody noticed this issue yet. |
SRU Request:
[Impact]
The current code will prevent gpu-manager from getting the correct list of alternatives. This breaks the detection system.
[Test Case]
Install the nvidia driver and check that gpu-manager reconfigures the system properly. More specifically, there should be no "Error: no alternative found for nvidia" line in /var/log/gpu-manager.log if the driver was installed correctly.
[Regression Potential]
Low, it is a one line change and a pretty obvious fix.
__________________________________________________________________________
I suppose this is a fairly significant bug, since it renders gpu-manager virtually useless.
I found it in ubuntu-drivers-common 0.4.17 (which is the current version in Ubuntu 16.04), and I do not know whether it is also present in other versions.
-- Symptoms --
For some reason, on my machine I frequently insert and remove my nvidia graphics adapter. My processor has an intel HD graphics adapter as well, so I rely on gpu-manager to detect my hardware configuration during boot, and update alternatives appropriately.
However, since I upgraded to Ubuntu 16.04, reconfiguring my hardware makes me unable to boot to desktop. However, reverting to previous hardware configuration solves the issue.
-- Analysis and proposed solution --
A quick check of symbolic links at /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf and similar confirms that when I change my hardware configuration, no changes are done to the targets of these links. Reading through gpu-manager.log I can see that it detects my hardware correctly, but it fails to configure alternatives, because:
Error: no alternative found for nvidia
Warning: no EGL alternative found for nvidia
Further investigation shows that the problem is with the get_alternative_link() function, as it always returns NULL, regardless of my current hardware configuration, and function arguments.
The get_alternative_link() function works by querying the list of available alternatives by running `update-alternatives` command with `--list` argument. The command is prepared by:
snprintf(command, sizeof(command),
"update-alternatives --list %s_%s_conf",
alternative_pattern, arch_path);
For example, when looking for "gl" alternatives for architecture "x86_64-linux-gnu", the resulting command will be:
update-alternatives --list gl_x86_64-linux-gnu_conf
This command always returns an empty list, and that is correct. The command is clearly malformed, the intention was to run another command, namely:
update-alternatives --list x86_64-linux-gnu_gl_conf
(note the order of "gl" vs "x86_64_linux_gnu")
Indeed the `snprintf` used to prepare the command has it's arguments swapped. Therefore I propose to substitute the mentioned source code with:
snprintf(command, sizeof(command),
"update-alternatives --list %s_%s_conf",
arch_path, alternative_pattern);
Applying the proposed change reliably fixes the bug symptoms I experienced.
-- Additional comment --
For your convenience, I attached to this bug report a patch file that applies the proposed solution; the patch is intended for ubuntu-drivers-common 0.4.17 source.
As far as I can tell, due to these swapped arguments gpu-manager always looks for unexisting alternatives, and therefore there is no scenario in which it would correctly configure alternatives. I suppose in this case gpu-manager always fails to serve its purpose. I find it astonishing that nobody noticed this issue yet. |
|
