Arch Linux, “hang” on “Reached target Graphical Interface”

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












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:



enter image description hereenter image description here



And here with more info:
enter image description hereenter image description here










share|improve this question



















  • 2




    unfortunately my VBox currently produces the same error...
    – GPMueller
    Dec 19 '16 at 19:55














up vote
1
down vote

favorite












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:



enter image description hereenter image description here



And here with more info:
enter image description hereenter image description here










share|improve this question



















  • 2




    unfortunately my VBox currently produces the same error...
    – GPMueller
    Dec 19 '16 at 19:55












up vote
1
down vote

favorite









up vote
1
down vote

favorite











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:



enter image description hereenter image description here



And here with more info:
enter image description hereenter image description here










share|improve this question















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:



enter image description hereenter image description here



And here with more info:
enter image description hereenter image description here







arch-linux desktop display-manager






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 13 '17 at 12:36









Community♦

1




1










asked Dec 18 '16 at 15:12









NOhs

12819




12819







  • 2




    unfortunately my VBox currently produces the same error...
    – GPMueller
    Dec 19 '16 at 19:55












  • 2




    unfortunately my VBox currently produces the same error...
    – GPMueller
    Dec 19 '16 at 19:55







2




2




unfortunately my VBox currently produces the same error...
– GPMueller
Dec 19 '16 at 19:55




unfortunately my VBox currently produces the same error...
– GPMueller
Dec 19 '16 at 19:55










2 Answers
2






active

oldest

votes

















up vote
2
down vote



accepted










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






share|improve this answer



























    up vote
    0
    down vote













    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.






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "106"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: false,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: null,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f331233%2farch-linux-hang-on-reached-target-graphical-interface%23new-answer', 'question_page');

      );

      Post as a guest






























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      2
      down vote



      accepted










      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






      share|improve this answer
























        up vote
        2
        down vote



        accepted










        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






        share|improve this answer






















          up vote
          2
          down vote



          accepted







          up vote
          2
          down vote



          accepted






          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






          share|improve this answer












          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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jan 30 '17 at 20:20









          NOhs

          12819




          12819






















              up vote
              0
              down vote













              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.






              share|improve this answer
























                up vote
                0
                down vote













                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.






                share|improve this answer






















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  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.






                  share|improve this answer












                  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.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Aug 31 at 14:59









                  Florens

                  11




                  11



























                       

                      draft saved


                      draft discarded















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f331233%2farch-linux-hang-on-reached-target-graphical-interface%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      How to check contact read email or not when send email to Individual?

                      Displaying single band from multi-band raster using QGIS

                      How many registers does an x86_64 CPU actually have?