FS#50139 - [xorg-xdm] Fails to start on qemu with kvm acceleration

Attached to Project: Arch Linux
Opened by Alif (alive4ever) - Sunday, 24 July 2016, 15:03 GMT
Last edited by Doug Newgard (Scimmia) - Monday, 25 July 2016, 01:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
xdm service fails to start on qemu with kvm acceleration

Additional info:
* package version(s): xorg-xdm 1.1.11-6
* config and/or log files etc.: Attached


Steps to reproduce:
Install minimal bootable Arch Linux on a virtual qemu-harddisk, with 'base xorg-server xorg-xrdb xorg-xdm xorg-xinit xorg-twm xterm xorg-xclock grub' packages, with xdm.service enabled.

My own way is below:
Create a virtual disk, for example 'qemu-img create -f raw /tmp/disk.img 2G'
Create loop device from virtual disk, for example 'udisksctl loop-setup -f /tmp/disk.img'
Create basic Arch Linux partitions (root, swap, and boot) on the loop device, for example 'fdisk /dev/loop0'.
The partition will be mapped as /dev/loop0p1, /dev/loop0p2, and can be viewed by fdisk -l/partx 'partx /dev/loop0'
Create necessary filesystems on the newly created partitions on the loop device.
Mount the root and boot partitions.
Install basic bootable Arch Linux system and minimal Xorg server on the mounted partition 'pacstrap -c -i /mnt base xorg-server xorg-xrdb xorg-xdm xorg-xinit xorg-twm xterm xorg-xclock grub'
Create fstab entry based on UUID, i.e. 'genfstab -U /mnt >> /mnt/etc/fstab'.
Chroot to the mount point, configure root password, create a user, and configure ~/.xinitrc for the default user by copying example xinitrc from /etc/X11/xinit/xinitrc and chmod 700 ~/.xinitrc
Configure locale.
Configure ramdisk inside chroot, for example 'mkinitcpio -p linux'
Configure grub to make sure that the virtual disk is bootable, for example 'grub-install --target i386-pc /dev/loop0' 'grub-mkconfig -o /boot/grub/grub.cfg'
Enable the xorg-xdm service inside the chroot.
Exit chroot, unmount the partition (umount /mnt/boot /mnt) and detach the loop device (udisksctl loop-delete -b /dev/loop0'

Now start qemu with the virtual disk image as boot disk, i.e. 'qemu-system-x86_64 -m 512M -drive file=/tmp/disk.img,format=raw'. Use the fallback grub boot configuration. Without kvm acceleration, xdm is started properly.
Login to the vm and shutdown the vm.

After the vm has been shut down properly, relaunch qemu with kvm enabled, i.e. 'qemu-system-x86_64 -enable-kvm -m 512M -drive file=/tmp/disk.img,format=raw'. Also use the fallback grub configuration. The virtual machine starts so fast that xdm started before the Xorg being able to recognize the screen.

This task depends upon

Closed by  Doug Newgard (Scimmia)
Monday, 25 July 2016, 01:18 GMT
Reason for closing:  Not a bug
Additional comments about closing:  See last comments.
Comment by Alif (alive4ever) - Sunday, 24 July 2016, 15:38 GMT
Note: On KVM, xdm can be launched manually after logging in.
Comment by Doug Newgard (Scimmia) - Sunday, 24 July 2016, 16:11 GMT
What DDX is it using when you launch it manually?
Comment by Alif (alive4ever) - Monday, 25 July 2016, 00:09 GMT
It's using DISPLAY=:0

systemd starts xdm.service before bochsdrmfb (qemu vga) is properly initialized.

I managed to solve this problem by adding 1 second delay before starting xdm

/usr/lib/systemd/system/xdm.service

[Unit]
Description=X-Window Display Manager
After=systemd-user-sessions.service

[Service]
ExecStartPre=/usr/bin/sleep 1
ExecStart=/usr/bin/xdm -nodaemon
Type=notify
NotifyAccess=all

[Install]
Alias=display-manager.service

Note: This issue also applies to xdm-archlinux and delaying its startup by 1 second also gives enough time for kvm kernel to initialize bocshdrm properly.
Comment by Doug Newgard (Scimmia) - Monday, 25 July 2016, 01:17 GMT
No, which DDX, as in which X driver?

Edit: OK, this is the same problem people have with nvidia. The easiest thing is to configure it to load the module in the initramfs. Not really a bug.

Loading...