Bug 950877

Similar problem with Tumbleweed (openSUSE-Tumbleweed-NET-x86_64-Snapshot20151012-Media.iso) - GNOME does not start (see screenshot).

Created attachment 652014 [details]
GNOME cannot start in Tumbleweed too

please attach the systemd journal

(journalctl)

I strongly syspect this to be a DUp of bug 939594

Created attachment 652119 [details]
dump of journalctl

I attached a text file created by using:
journalctl > journalctl_dump.txt
Hope this is what you were looking for.

The difference to bug 939594 is that it occurs already at the first attempt to start GNOME, i.e. the desktop never comes up.

Thanks...
it is indeed a different bug:

Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) Backtrace:
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 0: /usr/bin/Xorg (xorg_backtrace+0x48) [0x58b0c8]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 1: /usr/bin/Xorg (0x400000+0x18f2d9) [0x58f2d9]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 2: /lib64/libc.so.6 (0x7f1f40f55000+0x35200) [0x7f1f40f8a200]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 3: /usr/lib64/xorg/modules/drivers/vboxvideo_drv.so (0x7f1f3d007000+0x7829) [0x7f1f3d00e829]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 4: /usr/lib64/xorg/modules/drivers/vboxvideo_drv.so (0x7f1f3d007000+0x63fa) [0x7f1f3d00d3fa]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 5: /usr/bin/Xorg (InitOutput+0x9ef) [0x47e90f]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 6: /usr/bin/Xorg (0x400000+0x40dcb) [0x440dcb]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 7: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f1f40f76b05]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) 8: /usr/bin/Xorg (0x400000+0x2c5de) [0x42c5de]
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE)
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) Segmentation fault at address 0x0
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE)
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: Fatal server error:
Oct 19 13:12:46 linux-ignp /usr/lib/gdm/gdm-x-session[1083]: (EE) Caught signal 11 (Segmentation fault). Server aborting

the video driver simply crashes..

CC Larry.. this could as well be the virtualbox package, which actually brings the X-driver

Well, who takes care about the virtualbox X driverin virtualbox package?

(In reply to Stefan Dirsch from comment #8)
> Well, who takes care about the virtualbox X driverin virtualbox package?

That's the reason I already added Larry to CC; in this case he might actually be the appropriate assignee even

*** Bug 948383 has been marked as a duplicate of this bug. ***

Debian had a similar issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801524

they solved it a dependency to xserver-xorg-legacy

that package has as description:

>setuid root Xorg server wrapper
>
>This package provides a wrapper for the Xorg X server, which is necessary for >legacy drivers and non-Linux kernels.

WTF? I don't get this!

Ok. Understood. gdm no longer runs X as user root. But for UMS (user space modesetting) the X driver needs access to the hardware directly. So X drivers
like virtualbox, fbdev and vesa cannot work any longer. There are also other X drivers affected, which we still ship, but these are likely no longer in use.

@GNOME guys: X guys had a discussion about this and we want to make clear, that we won't go the Debian route with this crappy Xserver wrapper. It's up to gdm developers (how) to address that. In case you plan to address it at all. AFAIK the changes came from upstream (=RH) and likely they didn't address it at all.
Reassigning ...

@frustrated reporters: switch to another DM like lightdm (/etc/sysconfig/displaymanager:DISPLAYMANAGER (same package name to install).

I see - so running X as root is the chosen path for openSUSE then... glad we established that statement.

I installed lightdm and changed /etc/sysconfig/displaymanager as suggested in comment #14, but Gnome still did not work. Any other suggestions?

Any other proposed workarounds?

The same issue very likely happens on VMWare as well (anybody able to test?)

Fedora has a patch in the VMWare video driver for that purpose:
http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-vmware.git/tree/0002-Add-support-for-server-managed-fds.patch

(In reply to Larry Finger from comment #16)
> I installed lightdm and changed /etc/sysconfig/displaymanager as suggested
> in comment #14, but Gnome still did not work. Any other suggestions?
> 
> Any other proposed workarounds?

Bjorn just 'played' with this as well:
* using lightdm, gnome fires up
* using gdm, if X is setuid root, all works fine (as expected, as it then gets access to the devices).

So likely, porting the video driver to support server managed fds, as above patch by Redhat for Fedora, is really going to help

I doubt we get the virtualbox driver compatible to server managed fds in time...

so I suggest to add to the release notes that users should not use GDM inside virtualbox, but switch to lightdm in this case (GNOME itself is fine).

something along the lines (people, please chime in)

openSUSE Leap as guest in VirtualBox
====================================
If you're running openSUSE Leap as guest inside VirtualBox, you will have to use a different display-manager than GDM. GDM starts the X server in the user context (unlike all other known DMs at this moment). This is not compatible with the VirtualBox video driver and will result in crashes of the X Window System.

You can still use a full GNOME3 session

Switch to using lightdm by installing "lightdm" and activating it in /etc/sysconfig/displaymanager by setting DISPLAYMANAGER="lightdm".

(In reply to Dominique Leuenberger from comment #19)
> so I suggest to add to the release notes that users should not use GDM
> inside virtualbox, but switch to lightdm in this case (GNOME itself is fine).
> 

What about Live GNOME? Currently it is unusable as GUI never starts. Even worse, it constantly flickers between vts making doing anything useful near to impossible (tried TW Live GNOME couple of days ago on VB 5.0.6).

> so I suggest to add to the release notes that users should not use GDM
> inside virtualbox, but switch to lightdm in this case (GNOME itself is fine).

I believe that for most users (well, for me at least) it is pretty much irrelevant which display manager is in use.

But it gives a _very bad_ impression when you test the new release in VirtualBox, choose GNOME during the install (for being it is your primary choice of desktop environment), then the whole system renders practically unusable.

I would be very reluctant to switch to OpenSuse Leap/Tumbleweed after this experience.

(In reply to Alpár Jüttner from comment #21)
> But it gives a _very bad_ impression when you test the new release in
> VirtualBox, choose GNOME during the install (for being it is your primary
> choice of desktop environment), then the whole system renders practically
> unusable.

VirtualBox is certainly not the most preferred and error free virtualization environment... GNOME Boxes for example uses kvm/qemu below, which does not have that issue..

(In reply to Andrei Borzenkov from comment #20)
> (In reply to Dominique Leuenberger from comment #19)
> > so I suggest to add to the release notes that users should not use GDM
> > inside virtualbox, but switch to lightdm in this case (GNOME itself is fine).
> > 
> 
> What about Live GNOME? Currently it is unusable as GUI never starts. Even
> worse, it constantly flickers between vts making doing anything useful near
> to impossible (tried TW Live GNOME couple of days ago on VB 5.0.6).

LIVE GNOME? Does not exist on Leap hence no issue found

(In reply to Dominique Leuenberger from comment #22)
> 
> VirtualBox is certainly not the most preferred and error free virtualization
> environment... GNOME Boxes for example uses kvm/qemu below, which does not
> have that issue..

It may be true, but the vast majority of people still use VirtualBox, not qemu.

(In reply to Dominique Leuenberger from comment #23)
> 
> LIVE GNOME? Does not exist on Leap hence no issue found

Should I clone this bug for TW then?

(In reply to Andrei Borzenkov from comment #25)
> (In reply to Dominique Leuenberger from comment #23)
> > 
> > LIVE GNOME? Does not exist on Leap hence no issue found
> 
> Should I clone this bug for TW then?

It already exists, see bug 948383.
What's more, it is actually closed for being a duplicate of this bug.

(In reply to Stefan Dirsch from comment #14)
> @GNOME guys: X guys had a discussion about this and we want to make clear,
> that we won't go the Debian route with this crappy Xserver wrapper. It's up
> to gdm developers (how) to address that. In case you plan to address it at
> all. AFAIK the changes came from upstream (=RH) and likely they didn't
> address it at all.
> Reassigning ...
> 
> @frustrated reporters: switch to another DM like lightdm
> (/etc/sysconfig/displaymanager:DISPLAYMANAGER (same package name to install).

Fedora/RedHat also uses the suid wrapper around Xorg (even default installed).
Debian has it as an optional package (not installed by default)

openSUSE does not offer it at all..

the GNOME Team analysed what other distros do.

Fedora ships the SUID Wrapper for this case (fix installed)
Debian ships the SUID Wrapper in an extra package (pulled in on-demand if a package relies on it)

openSUSE's Xorg team wants X-running as non-root (we got rid of suid on Xorg a while back) but relies on the DM starting X as root.. and the X.org team sees more trouble in the SUID wrapper (provided as part of the Xorg server source code!) than other distros do (incl. Debian).

There are but two solutions to the problem:
a (short term): we also provide the suid wrapper, allowing virtualbox-guest-x11 to pull it in and start X as root (on demand, unless any other DM, we would still have X as user process in most cases, unless there are reasons not to do so)
b (long(er) term): the oracle virutalbox video driver is being fixed to support server handled fds and receive access to its devices by means of systemd-logind, just like the other drivers do.

FYI, I confirmed that lightdm works for GNOME in non-KMS mode.  Tested only on Leap, but I believe it's same for FACTORY.

(In reply to Dominique Leuenberger from comment #28)
> the GNOME Team analysed what other distros do.
> 
> Fedora ships the SUID Wrapper for this case (fix installed)

Interesting.

> openSUSE's Xorg team wants X-running as non-root (we got rid of suid on Xorg
> a while back) but relies on the DM starting X as root

This sounds like a misunderstanding/miscommunication. We're fine to go this path for TW, if usptream fixes the remaining issues with UMS drivers (not only virtualbox; vesa/fbdev - ourfallback drivers - are affected as well!). Since Leap is considered a stable product based on sle12, we need to run gdm as root again or replace gdm completely by lightdm.

> and the X.org team
> sees more trouble in the SUID wrapper (provided as part of the Xorg server
> source code!) than other distros do (incl. Debian).

Yes, the wrapper is no option for us. Reassigning back to GNOME team.

(In reply to Stefan Dirsch from comment #30)
 
> > openSUSE's Xorg team wants X-running as non-root (we got rid of suid on Xorg
> > a while back) but relies on the DM starting X as root
> 
> This sounds like a misunderstanding/miscommunication. We're fine to go this
> path for TW, if usptream fixes the remaining issues with UMS drivers (not
> only virtualbox; vesa/fbdev - ourfallback drivers - are affected as well!).
> Since Leap is considered a stable product based on sle12, we need to run gdm
> as root again or replace gdm completely by lightdm.

Neither the GNOME Stack nor the X-Stack bear any resemblance to SLE12SP1... SLE12 is way outdated in both areas.

But I see, the issue at hand is that GDM is dropping privileges to get X up as a user.. and that added security is not welcome (yet)

@coolo: are you fine with reverting to GDM 3.14.x ? Alternatively, gdm based systems will not work on platforms like virtualbox)

(In reply to Dominique Leuenberger from comment #31)
> 
> @coolo: are you fine with reverting to GDM 3.14.x ? Alternatively, gdm based
> systems will not work on platforms like virtualbox)

To clarify: this is not a blind shot: I did test this combination in my Leap virtualbox VM already. gdm 3.14.2 builds as-is on Leap and can just replace gdm 3.16.x for now.

The biggest difference is that it does not do the privilege drop before starting X, this circumventing this issue (but we should be happy we had 3.16: without it, that old xdm bug would never have been found/fixed)

This is an autogenerated message for OBS integration:
This bug (950877) was mentioned in
https://build.opensuse.org/request/show/340431 Leap:42.1 / gdm

Too bad that my time zone puts me behind on all this discussion, but I am certain that we wish to support installation of our products as guests in VirtualBox. VB has its warts, but it is familiar. Going from that starting point, it sounds as if we have a plan:

1. According to comment #33, the rollback to gdm 3.14.2 has already been submitted. If accepted, that takes care of the short-term requirements.

2. I have been in contact with Hans de Goede of Red Hat, who sent me a very nice outline of what needs to be done, and even offered to look at any code to help me debug it. In addition, I added a comment to Dimstar's ticket at VirtualBox. Perhaps they will affect a fix and save me the effort. :)

Please check https://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.1_dev&action=submit to verify that my wording is correct.

Bad Link. It should be https://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.1_dev.

(In reply to Larry Finger from comment #34)
> 1. According to comment #33, the rollback to gdm 3.14.2 has already been
> submitted. If accepted, that takes care of the short-term requirements.

This has happened: the next published Leap 42.1 FTP Tree will have gdm 3.14.2 again.

So the tasks the GNOME Team can do are completed.

I suggest to create new bugs per video driver that needs to be fixed and closing this one.

(removing coolo's needinfo: he accepted the gdm 3.14.2 revert into Leap, so he was obviously pro the suggestion)

(In reply to Larry Finger from comment #35)
> Please check
> https://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.
> 1_dev&action=submit to verify that my wording is correct.

it says "replace sddm with lightdm" - did you mean "gdm"? Also TaST is probably a typo.

(In reply to Andrei Borzenkov from comment #38)
> (In reply to Larry Finger from comment #35)
> > Please check
> > https://en.opensuse.org/index.php?title=openSUSE:Most_annoying_bugs_42.
> > 1_dev&action=submit to verify that my wording is correct.
> 
> it says "replace sddm with lightdm" - did you mean "gdm"? Also TaST is
> probably a typo.

I fixed both typos already
(cur | prev) 07:28, 23 October 2015‎ Dimstar (Talk | contribs)‎ m . . (1,037 bytes) (-1)‎ . . (→‎openSUSE 42.1 RC1) (undo)

Considering it's a wiki - you could have done the same

(In reply to Larry Finger from comment #34)
> Too bad that my time zone puts me behind on all this discussion, but I am
> certain that we wish to support installation of our products as guests in
> VirtualBox. VB has its warts, but it is familiar. 

Just one suggestion from my side with regards to supporting VMs:
I would put support for VirtualBox and VMware Player a top priority for every release. I think many users like me, who evaluate moving from Windows to Linux, will first test the installation in VirtualBox / VMware. If that is not working they will go away, as they will not trust it to work in a real environment, if it is not even working in something as "simple" (from an end-user point of view ;-))as a virtual environment.

Btw, the possibility to run Linux desktops in multiple VMs (without additional costs, which would be the case with Windows), was the main reason why I even started to evaluate migrating to Linux. I intend to separate the internet facing applications from e.g. the office suite or the image processing applications. If that is not working, then - at least for me - it would make no sense to switch to Linux.

And using GNOME Boxes instead is, as far as I understand, not really an option as the graphics performance is slower than that of a VM in VirtualBox, especially with multiple VMs running simultaneously. Missing functionality (seamless mode, shared folders, drag&dropetc.) are other reasons why Boxes is IMHO not an alternative to VirtualBox yet.

(In reply to Arnold Mesper from comment #40)
> Just one suggestion from my side with regards to supporting VMs:
> I would put support for VirtualBox and VMware Player a top priority for
> every release. I think many users like me, who evaluate moving from Windows
> to Linux, will first test the installation in VirtualBox / VMware. If that
> is not working they will go away, as they will not trust it to work in a
> real environment, if it is not even working in something as "simple" (from
> an end-user point of view ;-))as a virtual environment.

I understand the need for using VMs, and I had tested that Leap 42.1 worked in a VB VM using KDE. I had no way of knowing that the update of gdm to 3.16.x would break vboxvideo. At least this issue will be fixed for Leap GM and in a near-future Tumbleweed release.

BTW, if you are unhappy with the way I maintain VirtualBox, I would be more than happy to turn it over to you. :)

(In reply to Larry Finger from comment #41)
> (In reply to Arnold Mesper from comment #40)
> > Just one suggestion from my side with regards to supporting VMs:
> > I would put support for VirtualBox and VMware Player a top priority for
> > every release. I think many users like me, who evaluate moving from Windows
> > to Linux, will first test the installation in VirtualBox / VMware. If that
> > is not working they will go away, as they will not trust it to work in a
> > real environment, if it is not even working in something as "simple" (from
> > an end-user point of view ;-))as a virtual environment.
> 
> I understand the need for using VMs, and I had tested that Leap 42.1 worked
> in a VB VM using KDE. I had no way of knowing that the update of gdm to
> 3.16.x would break vboxvideo. At least this issue will be fixed for Leap GM
> and in a near-future Tumbleweed release.
> 
> BTW, if you are unhappy with the way I maintain VirtualBox, I would be more
> than happy to turn it over to you. :)

Larry, I appologize, if my suggestion was interpreted as rude critic as it wasn't intended to be. I just wanted to emphasize Alpárs comment #21. All you guys here do a great job - as an end-user, without technical skills, I highly appreciate and admire the efforts you put into delivering openSUSE!

The eminent issue for Leap 42.1 is resolved by a downgrade of gdm to 3.14.x, which results in X running as root - hence the drivers not having to care for logind integration.

(In reply to Dominique Leuenberger from comment #43)
> The eminent issue for Leap 42.1 is resolved [...]

Is this fix available in Tumbleweed, too?

(In reply to Alpár Jüttner from comment #44)
> (In reply to Dominique Leuenberger from comment #43)
> > The eminent issue for Leap 42.1 is resolved [...]
> 
> Is this fix available in Tumbleweed, too?

This is a LEAP bug fix - for TW, the downgrade of gdm is not yet executed.
The usefulness of TW inside  virtualbox is more questionable - if you use TW, it's likely not to 'just find out if it works'.

Just checked it with openSUSE-Leap-42.1-DVD-x86_64-Build0255-Media.iso - GNOME now starts. Thanks.

Thanks for that report.

Discovered this bug by chance.  At least regarding VirtualBox you might have speeded things up slightly by getting in touch with us (Larry did, but did not tell us about the bug).  Quick summary: our current plans are not to do server-managed FDs (we did actually test them) but to finish off our kernel mode-setting support and use that in combination with the modesetting driver.  Server-managed FDs would not help as our driver still pokes ports itself, and thus needs root rights anyway.