Ytdyklly

EDIT: I just tried gnome and gdm and it worked flawlessly. So something with the virtualbox packages and the SDDM package seems to not work.

At first this question looks like this one (Arch Linux stuck at boot (reached target Graphical Interface)), however, I can still change to a different TTY.

Anyways, the following used to work before, but results in a core dump of sddm since recently. Interestingly enough, systems I simply update, which used this install method, do still work, but new installations lead to the issues below.

When installing Arch Linux in VirtualBox with Windows 10 as host system, I use this minimum [non]working example that is based on the official Arch Installer guide and used to work:

parted



mklabel GPT

mkpart ESP fat32 1MiB 513MiB

mkpart primary ext4 513MiB 100%

set 1 boot on

quit



mkfs.ext4 /dev/sda2

mkfs.fat -F32 /dev/sda1



mount /dev/sda2 /mnt



mkdir -p /mnt/boot

mount /dev/sda1 /mnt/boot



pacstrap /mnt base base-devel 

              virtualbox-guest-modules-arch 

              virtualbox-guest-utils 

              sddm plasma



arch-chroot /mnt bootctl --path=/boot install



cat <<-END > /mnt/boot/loader/entries/arch.conf

title Arch Linux

linux /vmlinuz-linux

initrd /initramfs-linux.img

options root=PARTUUID=$( blkid -s PARTUUID -o value /dev/sda2 ) rw

END



cat <<-END > /mnt/boot/loader/loader.conf

default arch

timeout 4

editor  0

END



genfstab -pU /mnt >> /mnt/etc/fstab



arch-chroot /mnt systemctl enable sddm



arch-chroot /mnt useradd -m -G wheel -s /bin/bash bob

It hangs on "reached target Graphical interface" but I can still use ctrl+alt+F2 in contrast to this question (Arch Linux stuck at boot (reached target Graphical Interface)) and calling journalctl -b -p err yields:

And here with more info:

It seems that SDDM/KDE no longer pulls xorg-server packages automatically. So if one adds the xorg-server package it works.

Found solution here: https://github.com/sddm/sddm/issues/605#issuecomment-275938076

I had the same (or a very similar issue). It would stop at reached target graphical interface and I could switch tty. Fom there I could restart gdm and after a couple of tries it would start.

If you are using the proprietary nvidia graphics drivers with xorg you can use this solution. To fix this, open /etc/gdm/custom.conf and uncomment #WaylandEnable=false.

I had an issue with similar symptoms after migrating some disks to new hardware, but could see nothing fishy in the logs after enabling debug logging. The machine also had no dm software installed. I also noticed that some services weren't starting.

It turns out some of the target files under /etc (eg /etc/systemd/system/multi-user.target.wants/sshd.service were not symlinks as they are meant to be, and may have just had stale code in them. I fixed my issue by removing all non-symlink target files and recreating them with systemctl enable or just manually linking to the appropriate target under /usr/lib/systemd/ - The specific target that was causing my failure was a stale /etc/systemd/system/getty.target.wants/getty@tty1.service