Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.

Bug #1792932 reported by Jean-Baptiste Lallement on 2018-09-17
This bug affects 28 people
Affects Status Importance Assigned to Milestone
X.Org X server
xorg-server (Ubuntu)
Timo Aaltonen
Timo Aaltonen
Timo Aaltonen

Bug Description


Test Case:
Boot Ubuntu Cosmic Desktop 20180916 on Virtual Box

Actual Result
Black screen or dropped to the login screen if the user skips ubiquity-dm

Add nomodeset on the kernel command line or from the boot menu, press F6 then select nomodeset

Possibly a duplicate of bug 1432137

Backport a patch from 1.20.2

Regression potential:
None really, we've had this xserver version since 18.10 and in the HWE backport, this patch backport is for 18.04 stock xserver but should work the same. It just skips initializing glamor if the system is using software fallback.

ProblemType: Crash
DistroRelease: Ubuntu 18.10
Package: xserver-xorg-core 2:1.20.1-1ubuntu2
ProcVersionSignature: Ubuntu 4.18.0-7.8-generic 4.18.5
Uname: Linux 4.18.0-7-generic x86_64
ApportVersion: 2.20.10-0ubuntu9
Architecture: amd64
AssertionMessage: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
CasperVersion: 1.395
CompositorRunning: None
Date: Mon Sep 17 12:42:24 2018
DistUpgraded: Fresh install
DistroCodename: cosmic
DistroVariant: ubuntu
ExecutablePath: /usr/lib/xorg/Xorg
ExtraDebuggingInterest: Yes
GraphicsCard: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] (prog-if 00 [VGA controller])
LiveMediaBuild: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180916)
 Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: innotek GmbH VirtualBox
ProcCmdline: /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/999/gdm/Xauthority -background none -noreset -keeptty -verbose 3

ProcKernelCmdLine: file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd --- keyboard-configuration/layoutcode=fr keyboard-configuration/variantcode=oss
Signal: 6
SourcePackage: xorg-server
 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
 __GI_abort () at abort.c:79
 __assert_fail_base (fmt=0x7f60fa1e3858 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x563dbf96db7d "!global_keys[type].created", file=0x563dbf96db38 "../../../../dix/privates.c", line=384, function=<optimized out>) at assert.c:92
 __GI___assert_fail (assertion=0x563dbf96db7d "!global_keys[type].created", file=0x563dbf96db38 "../../../../dix/privates.c", line=384, function=0x563dbf96dde0 "dixRegisterPrivateKey") at assert.c:101
 dixRegisterPrivateKey ()
Title: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr: Virtual Machine VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.94-1
version.libgl1-mesa-dri: libgl1-mesa-dri 18.1.5-1ubuntu1
version.libgl1-mesa-glx: libgl1-mesa-glx 18.1.5-1ubuntu1
version.xserver-xorg-core: xserver-xorg-core 2:1.20.1-1ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1build1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1build1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-3

This is semi-related to another bug:
And by semi, I mean it's either completely related or completely not related, and I don't know which yet.

If I boot my computer with my AMD video card bound to a driver besides amdgpu (like vfio-pci for my Windows virtual machine), then unbind it from that driver, intending to bind to to amdgpu for Linux gaming...

EXPECTED BEHAVIOR: I can unbind, remove the card, rescan (echo 1 > /sys/bus/pci/rescan), then bind the card to amdgpu, using DRI3 and the DRI_PRIME variable for games. This is a process that some successfully do with the radeon driver on older AMD cards.

ACTUAL BEHAVIOR: At the moment that I rescan (echo 1 > /sys/bus/pci/rescan), X crashes and restarts, booting me back to the login screen, and something (I guess either the kernel or X) has automatically bound the card to amdgpu on its own, without me entering those echo commands (echo "<card's vendor ID>" "<card's device ID>" > /sys/bus/pci/drivers/amdgpu/new_id) to bind it.

DESIRED BEHAVIOR: I can get my card bound to amdgpu, whether it's automatic or by my own typed bind commands, WITHOUT a boot-me-to-login-screen X crash.

The X crash log is at
The crash, starting at [456.336], has no errors. It seems to be just reconfiguring the graphics because it noticed a new available card, and somehow that resulted in me being booted back to the login screen.
The log that was made after the crash, when I logged back in, is at

Please attach your dmesg output from after you load the amdgpu driver.

Created attachment 125758
dmesg log

Here's the full dmesg output. The moment amdgpu starts is [6156.280097], and that output seems to end around [6208.867655].

I should mention at this point, this behavior has happened to me on an R9 380 (Tonga) and my current R9 Fury (Fiji).

Since the Xorg log file ends abruptly, we'd probably need to see the Xorg stderr output. It should be captured in a display manager log file / the systemd journal / ...

BTW, for DRI3 PRIME there's no need for X to do anything with the card directly, so you can prevent it from trying and crashing with

Section "ServerFlags"
       Option "AutoAddGPU" "off"

in /etc/X11/xorg.conf as a workaround.

That's interesting. Turning AutoAddGPU off completely fixed the problem, and didn't work the way I expected. With it off, my computer still automatically binds the card to amdgpu as soon as I rescan, so I guess that's a quirk of the kernel or amdgpu, but X takes the card in with no crash. It works as seamlessly as it's supposed to, and I can once again use DRI_PRIME to access the card. I'll turn it back off to get the error output (because there is none when I'm using this perfectly fine workaround), which I figured out is not in my Xorg logs (, and upload that now.

Created attachment 125786

Here are the stderr logs. x-0.log.old is the session that crashed from trying to "AutoAdd" the AMD GPU, and x-0.log is the session that loaded after the crash with the GPU loaded.

I paid close attention to differences in these logs between when I had AutoAdd turned off or on in xorg.conf, and there are only 2 different lines: the obvious "using xorg.conf" line (because I just deleted the xorg.conf file when I wasn't turning AutoAdd off), and the line that the .old file ends in if it crashes: "Xorg: privates.c:385: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed."

Created attachment 125787

Can you:

* Start X with AutoAddGPU enabled
* Attach gdb to the Xorg process and continue its execution
* Reproduce the problem
* At the gdb prompt after SIGABRT, enter "bt full" and attach the resulting output here

See for some background information, in particular the "Debug support" section.

It looks like in Arch Linux, I'd have to recompile those packages myself to get debug symbols. At that point, I think it'd be easier to just do this in a LiveUSB of debian. If I have the same issue with this card in debian, would that debug info be as good as if I had done it in Arch?

(In reply to jimijames.bove from comment #8)
> If I have the same issue with this card in debian,
> would that debug info be as good as if I had done it in Arch?

Yeah, should be fine.

Alright, new problem. I have debian all set up to debug this. I even tested the whole debugging process without amdgpu running and it went swimmingly. But, as soon as I put in my 20-amdgpu.conf file, X crashes, because it can't grab my card from pci-stub, but in order to test this bug, I *need* to boot up the machine with the card bound to pci-stub. It's because for some reason, in Arch Linux, X is OK with loading amdgpu without finding a usable card, but in debian, not finding a card makes it freak out, even though Ignore is set to true. Here's the amdgpu part of the crash log from debian:

[ 4.716] (--) PCI:*(0:0:2:0) 1b36:0100:1af4:1100 rev 4, Mem @ 0x94000000/67108864, 0x90000000/67108864, 0x98248000/8192, I/O @ 0x0000c2a0/32, BIOS @ 0x????????/131072
[ 4.716] (--) PCI: (0:0:7:0) 1002:7300:174b:e331 rev 203, Mem @ 0x80000000/268435456, 0x98000000/2097152, 0x98200000/262144, I/O @ 0x0000c000/256, BIOS @ 0x????????/131072
[ 4.716] (II) LoadModule: "glx"
[ 4.716] (II) Loading /usr/lib/xorg/modules/extensions/
[ 4.717] (II) Module glx: vendor="X.Org Foundation"
[ 4.717] compiled for 1.18.4, module version = 1.0.0
[ 4.717] ABI class: X.Org Server Extension, version 9.0
[ 4.717] (==) AIGLX enabled
[ 4.717] (II) LoadModule: "amdgpu"
[ 4.717] (II) Loading /usr/lib/xorg/modules/drivers/
[ 4.717] (II) Module amdgpu: vendor="X.Org Foundation"
[ 4.717] compiled for 1.18.3, module version = 1.1.0
[ 4.717] Module class: X.Org Video Driver
[ 4.717] ABI class: X.Org Video Driver, version 20.0
[ 4.717] (II) AMDGPU: Driver for AMD Radeon chipsets: BONAIRE, BONAIRE, BONAIRE,
[ 4.718] (EE) No devices detected.
[ 4.718] (EE)
Fatal server error:
[ 4.718] (EE) no screens found(EE)

And here's my 20-amdgpu.conf file that works fine in Arch but not debian, given a card that's occupied by vfio-pci or pci-stub:

Section "Device"
    Identifier "Radeon"
    Driver "amdgpu"
    Option "DRI" "3"
    Option "Ignore" "true"

(In reply to jimijames.bove from comment #10)
> Section "Device"
> Identifier "Radeon"
> Driver "amdgpu"
> Option "DRI" "3"
> Option "Ignore" "true"
> EndSection

Option "Ignore" doesn't have any effect here, both according to the xorg.conf manpage and the xserver code.

I suspect the problem is that this Device section makes Xorg try to use the amdgpu driver for all GPUs, and not fall back to any other drivers. I'm not sure why this section would be necessary anyway; Xorg should automatically try to use the amdgpu driver (if it's installed correctly) for any GPUs controlled by the amdgpu kernel driver, and fall back to other drivers.

If the above doesn't help you overcome this issue, please attach the full Xorg log files from Arch and Debian.

I forgot to mention, the reason I need that conf file is I need to test this on DRI3, because on the default of DRI2, the crash did not occur, meaning it's either a problem with Arch and not debian, or a problem with DRI3. Is there a section besides "Device" that doesn't disable fallback but still enables DRI3?

DRI3 needs to be enabled for the primary GPU. The secondary GPU doesn't matter for that; in fact, as I mentioned in comment 3, Xorg doesn't need to use the secondary GPU directly at all with DRI3. It's all handled by Mesa.

Oh. I didn't know that. In that case, this got easier to test.

Also, the Ignore option is supposed to make X only use the card for features like DRI_PRIME and not try to use it for any screens, as referenced here: in this comment:

The Ignore option is precisely why I didn't expect X to crash upon loading the AMD card, and looking back at that link, I just realized that I've been doing it wrong this whole time and should have it in a 30- file instead of my 20- file. I'll test it again on my own Arch system with that set up properly and AutoAddGPU turned back on, then test it in debian on DRI3 but without that amdgpu conf file.

According to the xorg.conf manpage and the xserver code, Option "Ignore" only has an effect in "InputClass" and "Monitor" sections.

Note that since the crash happens when Xorg tries to use the GPU, testing with DRI3 and Xorg not using the GPU directly cannot trigger the crash.

But a crash happening anyway with DRI3 and Xorg not using the GPU directly is exactly the original issue I posted this bug report trying to fix. And I just finished testing without any of my own explicit options for amdgpu: no DRI3, no Ignore (and it the DRI_PRIME stuff I was doing still works fine, so you were right that those options had no point), and it's still crashing unless AutoAddGPU is turned off. So, I'll be grabbing that debug output in debian now.

(In reply to jimijames.bove from comment #17)
> But a crash happening anyway with DRI3 and Xorg not using the GPU directly
> is exactly the original issue I posted this bug report trying to fix.

The crash referenced in the original description of this report happens when Xorg tries to use (using the modesetting driver) the GPU controlled by the amdgpu kernel driver.

Sorry, I think I'm just confusing myself from not having a full grasp of the terminology.

Argh. I finally got X configured and running in debian, and now I can't get the card to bind to amdgpu no matter what I do. The normal method--a rescan--results in it going straight back to pci-stub. If I unbind, then rmmod pci-stub, then rescan, it still refuses to bind to amdgpu. I think I'll just have to compile X and amdgpu in Arch after all.

Created attachment 126211

Sorry that took so long. A whole lot of life stuff happened as soon as I decided to build it in Arch. Now that I have, it was actually really easy (I didn't know about the ABS until doing this). I ran the test once and got some output, but it seemed to want the debug symbols from glibc as well, so I also recompiled glibc with debug symbols and ran the test again. Here's both of those outputs.

The "Cannot access memory at address errors" are weird, because yes, they popped up as soon as I ran gdb, but they didn't happen again until the moment of the crash, and there was a good 10 minutes between when I opened gdb and actually ran the test.

The log with glibc is coming soon. I didn't realize glibc takes this long to compile.

OK, nevermind on that second debug report. Even though pacman tells me /lib64/ comes from glibc, reinstalling glibc with debug symbols (which DID make objdump --sym return plenty of symbols for /lib64/ did not change the output in any way. So, I don't know how to make gdb able to find debug symbols for /lib64/

Hi there! Same issue, same use case, same distro.

I'm using the radeon driver instead of amdgpu but the assert seems to be the same one anyway. I don't have the actual assert message, but I do have a backtrace that doesn't seem to have been posted here before:

0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139) [0x55cd08924e99]
1: /usr/lib/ (funlockfile+0x50) [0x7f6d28fb2e1f]
2: /usr/lib/ (gsignal+0x110) [0x7f6d28c1e860]
3: /usr/lib/ (abort+0x1c9) [0x7f6d28c1fec9]
4: /usr/lib/ (__assert_fail_base+0x14c) [0x7f6d28c170bc]
5: /usr/lib/ (__assert_fail+0x43) [0x7f6d28c17133]
6: /usr/lib/xorg-server/Xorg (dixRegisterPrivateKey+0x23f) [0x55cd087dd9ff]
7: /usr/lib/xorg/modules/ (glamor_init+0xca) [0x7f6d1ba9d3fa]
8: /usr/lib/xorg/modules/drivers/ (_init+0x39de) [0x7f6d1bcd2d2e]
9: /usr/lib/xorg-server/Xorg (AddGPUScreen+0xf0) [0x55cd087bf630]
10: /usr/lib/xorg-server/Xorg (xf86PlatformMatchDriver+0xa9c) [0x55cd0881f59c]
11: /usr/lib/xorg-server/Xorg (xf86PlatformDeviceCheckBusID+0x211) [0x55cd08824881]
12: /usr/lib/xorg-server/Xorg (config_fini+0x9bd) [0x55cd0882105d]
13: /usr/lib/xorg-server/Xorg (config_fini+0x1340) [0x55cd08822420]
14: /usr/lib/xorg-server/Xorg (OsCleanup+0x621) [0x55cd08925e01]
15: /usr/lib/xorg-server/Xorg (WaitForSomething+0x1fb) [0x55cd0891e70b]
16: /usr/lib/xorg-server/Xorg (SendErrorToClient+0x113) [0x55cd087bf023]
17: /usr/lib/xorg-server/Xorg (InitFonts+0x420) [0x55cd087c32a0]
18: /usr/lib/ (__libc_start_main+0xea) [0x7f6d28c0af4a]
19: /usr/lib/xorg-server/Xorg (_start+0x2a) [0x55cd087acf0a]

Followed by "Caught signal 6 (Aborted). Server aborting".

The assertion message in the attached (but not mine) x-0.log.old is:

>Xorg: privates.c:385: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.

BTW, useful stuff in the comments here regarding AutoAddGPU, the (useless) Ignore setting and DRI3 stuff! I think I learnt more from reading a couple of comments here than in the past four hours of fiddling.

Created attachment 138507
backtrace with debug symbols

I'm afraid I won't be able to help out with this anymore for I have no idea how long. I'm currently dealing with another bug in which DRI3 refuses to turn on for my NVidia GT 740, even though there's nothing wrong with DRI3, my hardware and conf files haven't changed, and downgrading my entire system back to a time before that other bug started happening does not make it go away. Because magic or something. Other nouveau users don't seem to have the issue besides one guy on reddit who's using a 730. Consequently, it's been months and I still haven't been able to find the cause. Until it's fixed, I can't test the entire premise that this bug report is based on--adding my AMD card to the current X server.

Created attachment 138508
naive assert fix

This turns the assert() into a return FALSE. Applies against 1.19.6+13+gd0d1a694f-1 (current stable in arch)

Probably not a good idea and probably not even following style correctly. Trivial enough but I surrender any copyright it might have (or license as CC0).

It stops the crash and I don't see any yelling in logs, but I might not have the correct debug level. Haven't checked what consequences it might have but other parts of the function return FALSE too, anyway.

Most noticeable is the fact that the monitor attached to the newly added GPU does not appear in xrandr, so having AutoAddGPU gets me nothing...

Jean-Baptiste Lallement (jibel) wrote :
information type: Private → Public
tags: removed: need-amd64-retrace
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xorg-server (Ubuntu):
status: New → Confirmed
tags: added: rms-cc-incoming
tags: added: rls-cc-incoming
removed: rms-cc-incoming
Timo Aaltonen (tjaalton) wrote :

could be a mesa bug which is fixed in 18.1.7/18.2.0-rc5+, please test the latter from


which has 18.2.0

Timo Aaltonen (tjaalton) on 2018-09-18
Changed in xorg-server (Ubuntu):
status: Confirmed → Incomplete
Daniel van Vugt (vanvugt) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug 1432137, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.

summary: - Xorg assert failure: Xorg: ../../../../dix/privates.c:384:
- dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
+ Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg:
+ ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion
+ `!global_keys[type].created' failed.
description: updated
Changed in xorg-server (Ubuntu):
importance: Undecided → High
assignee: nobody → Timo Aaltonen (tjaalton)
tags: added: rls-cc-tracking
removed: rls-cc-incoming
Jean-Baptiste Lallement (jibel) wrote :

ubiquity-dm then the session start with mesa from the canonical-x/x-staging PPA.

Changed in xorg-server (Ubuntu Cosmic):
status: Incomplete → Triaged
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Iain Lane (laney) wrote :

that mesa is now on the latest ISOs, and apparently doesn't fix it after all

Timo Aaltonen (tjaalton) wrote :

right, not this case which is a bit weird one

Booting up the live image desktop does this:
- vboxvideo.ko is not initialized when X starts
- X unloads modesetting and configures the vesa driver instead
- vboxvideo.ko is initialized later and xserver loads modesetting again
- DRI is initialized and at this point the server goes boom

Then the installer will load gdm and it works normally, because vboxvideo.ko is loaded. On the installed system the initrd probably has vboxvideo in it so it's loaded earlier, but I haven't confirmed this.

In any case, the xserver probably shouldn't crash like it does, I'll try filing it upstream.

Timo Aaltonen (tjaalton) wrote :

was filed upstream already, linked here

Judging by the duplicates it looks like this isn't specific to virtualbox. It's been happening for a few years.

summary: - Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg:
- ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion
- `!global_keys[type].created' failed.
+ Xorg assert failure: Xorg: ../../../../dix/privates.c:384:
+ dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
description: updated
tags: added: bionic xenial
description: updated
description: updated
summary: - Xorg assert failure: Xorg: ../../../../dix/privates.c:384:
- dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
+ Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg:
+ ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion
+ `!global_keys[type].created' failed.
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.20.1-3ubuntu2

xorg-server (2:1.20.1-3ubuntu2) cosmic; urgency=medium

  * dont-init-glamor-on-llvmpipe.diff: Glamor shouldn't be used on
    llvmpipe, as it might end up crashing the server on a racy bootup.
    (LP: #1792932)

 -- Timo Aaltonen <email address hidden> Tue, 02 Oct 2018 21:40:03 +0300

Changed in xorg-server (Ubuntu Cosmic):
status: Fix Committed → Fix Released
Adalbert Hanßen (melolontha) wrote :

I am using Xubuntu 16.04.3 LTS, my current Linux kernel is 4.4.0-116-generic x86_64.

I also get a similar error message:

Xorg.assert.failure:Xorg: ../../dix/privates.c:385: dixRegisterPrivateKey: Assertion ‘lglobal_keys[type].created‘ fails

(above it is c:384) The bug is told to be a duplicate of

But the error reporting software tells me that the bug is a duplicate of which also does not exist, but here it is a different one than told above.

BTW: Is there a way to catch the error report sent in. It is very tedious to retype what I can see when I inspect on what the error reporting software sends in.

According to

apt list --installed

I have no package xorg-server. I only have

xorg/xenial-updates,now 1:7.7+13ubuntu3.1 amd64 [installiert]
xorg-docs-core/xenial,xenial,now 1:1.7.1-1ubuntu1 all [installiert]
xorg-sgml-doctools/xenial,xenial,now 1:1.11-1 all [Installiert,automatisch]

Is there anything which I should install to get rid of the error.

-- GitLab Migration Automatic Message --

This bug has been migrated to's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance:

Changed in xorg-server:
importance: Unknown → Medium
Changed in xorg-server (Ubuntu Bionic):
status: New → Confirmed
importance: Undecided → High
summary: - Cosmic Desktop fails to boot in vbox: Xorg assert failure: Xorg:
+ Desktop fails to boot in vbox: Xorg assert failure: Xorg:
../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion
`!global_keys[type].created' failed.
Changed in xorg-server (Ubuntu Bionic):
assignee: nobody → Timo Aaltonen (tjaalton)
Gennady (pendolf) wrote :

Any fixes/updates for bionic?

Timo Aaltonen (tjaalton) wrote :

please test if the package on works (once it's built)

then I'll upload it for SRU

Changed in xorg-server (Ubuntu Bionic):
status: Confirmed → Incomplete
Robie Basak (racb) wrote :

This needs Regression Potential SRU information completed please.

Gennady (pendolf) wrote :

Can't reproduce bug at Bionic, may be after some packege updates it's gone.

Timo Aaltonen (tjaalton) on 2019-11-02
description: updated
description: updated
Timo Aaltonen (tjaalton) on 2019-11-02
description: updated

Hello Jean-Baptiste, or anyone else affected,

Accepted xorg-server into bionic-proposed. The package will build now and be available at in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in xorg-server (Ubuntu Bionic):
status: Incomplete → Fix Committed
tags: added: verification-needed verification-needed-bionic

All autopkgtests for the newly accepted xorg-server (2:1.19.6-1ubuntu4.4) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

kwindowsystem/5.44.0-0ubuntu1 (arm64)
kfind/4:17.12.3-0ubuntu1 (armhf)
gnome-photos/3.28.0-1 (s390x)
qbzr/0.23.2-3 (i386, amd64)
aptdaemon/1.1.1+bzr982-0ubuntu19.1 (armhf)
libkeduvocdocument/4:17.12.3-0ubuntu1 (armhf)
kstars/5:2.9.4-1ubuntu1 (armhf)
libkf5mailcommon/4:17.12.3-0ubuntu1 (arm64)
pytest-qt/2.3.1-1 (amd64)
bluez-qt/5.44.0-0ubuntu1 (armhf)
libkf5mailimporter/unknown (armhf)
firefox/70.0.1+build1-0ubuntu0.18.04.1 (armhf)
kservice/unknown (armhf)
python-ltfatpy/1.0.12-1 (ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].


Thank you!

Mathew Hodson (mhodson) on 2019-11-17
Changed in xorg-server:
importance: Medium → Unknown
Changed in xorg-server (Ubuntu Xenial):
importance: Undecided → High
Changed in xorg-server:
status: Unknown → New
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xorg-server (Ubuntu Xenial):
status: New → Confirmed

In bionic I couldn't verify the original bug because the HWE packages in 18.04.4 don't seem to be affected by this bug.

However, on 18.04.4 I uninstalled the HWE stack and replaced it by the packages in proposed and couldn't reproduce this issue. I didn't notice any other problem with the update.

Marking as verification-done for bionic

tags: added: verification-done-bionic
removed: verification-needed-bionic
tags: added: verification-done
removed: verification-needed

I also tried the packages from proposed on top of 18.04.0 on which I could reproduce the original issue and the packages from proposed fixed it. double verification done.

Timo Aaltonen (tjaalton) wrote :

thanks for testing!

I don't see how this update would regress qbzr autopkgtest (timeouts), but somehow it seeemingly did

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.19.6-1ubuntu4.4

xorg-server (2:1.19.6-1ubuntu4.4) bionic; urgency=medium

  * dont-init-glamor-on-llvmpipe.diff: Glamor shouldn't be used on
    llvmpipe, as it might end up crashing the server on a racy bootup.
    (LP: #1792932)

 -- Timo Aaltonen <email address hidden> Mon, 21 Oct 2019 17:26:17 +0300

Changed in xorg-server (Ubuntu Bionic):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for xorg-server has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Daniel van Vugt (vanvugt) wrote :

Continued in bug 1811023.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.