Desktop fails to boot in vbox: Xorg assert failure: Xorg: ../../../../dix/privates.c:384: dixRegisterPrivateKey: Assertion `!global_keys[type].created' failed.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
X.Org X server |
New
|
Unknown
|
|||
xorg-server (Ubuntu) |
Fix Released
|
High
|
Timo Aaltonen | ||
Xenial |
Confirmed
|
High
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Timo Aaltonen | ||
Cosmic |
Fix Released
|
High
|
Timo Aaltonen |
Bug Description
https:/
https:/
---
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
Workaround:
Add nomodeset on the kernel command line or from the boot menu, press F6 then select nomodeset
Possibly a duplicate of bug 1432137
Fix:
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
ProcVersionSign
Uname: Linux 4.18.0-7-generic x86_64
ApportVersion: 2.20.10-0ubuntu9
Architecture: amd64
AssertionMessage: Xorg: ../../.
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
ExtraDebuggingI
GraphicsCard: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef] (prog-if 00 [VGA controller])
LiveMediaBuild: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180916)
Lsusb:
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/
ProcEnviron:
ProcKernelCmdLine: file=/cdrom/
Signal: 6
SourcePackage: xorg-server
StacktraceTop:
__GI_raise (sig=sig@entry=6) at ../sysdeps/
__GI_abort () at abort.c:79
__assert_fail_base (fmt=0x7f60fa1e3858 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=
__GI___assert_fail (assertion=
dixRegisterPri
Title: Xorg assert failure: Xorg: ../../.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekG
dmi.product.family: Virtual Machine
dmi.product.name: VirtualBox
dmi.product.
dmi.sys.vendor: innotek GmbH
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.94-1
version.
version.
version.
version.
version.
version.
version.
tags: | removed: need-amd64-retrace |
tags: | added: rms-cc-incoming |
tags: |
added: rls-cc-incoming removed: rms-cc-incoming |
Changed in xorg-server (Ubuntu): | |
status: | Confirmed → Incomplete |
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 |
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. |
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) |
description: | updated |
description: | updated |
description: | updated |
Changed in xorg-server: | |
importance: | Medium → Unknown |
Changed in xorg-server (Ubuntu Xenial): | |
importance: | Undecided → High |
Changed in xorg-server: | |
status: | Unknown → New |
This is semi-related to another bug: https:/ /bugzilla. kernel. org/show_ bug.cgi? id=150731
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 https:/ /bugzilla. kernel. org/attachment. cgi?id= 228411 /bugzilla. kernel. org/attachment. cgi?id= 228421
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 https:/