Public bug reported:
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.
** Affects: ubuntu-drivers-common (Ubuntu)
Importance: Undecided
Status: New
** Patch added: "fix_alternative_argument_order.patch"
https://bugs.launchpad.net/bugs/1575960/+attachment/4649621/+files/fix_alternative_argument_order.patch
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-drivers-common in Ubuntu.
https://bugs.launchpad.net/bugs/1575960
Title:
gpu-manager: get_alternative_link() NEVER checks for a correct
alternative
Status in ubuntu-drivers-common package in Ubuntu:
New
Bug 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1575960/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
