[Pkg-utopia-maintainers] Bug#903851: DBUS? Continuing Problems after migration to "testing"

[Thomas Hardman]

The saga continues. After several 'apt-get update ; apt-get dist-upgrade'
cycles, and taking advice to look in the logs, I found nothing that helped
me much.

Trying an experiment, I set the default boot to the multi-user.target
rather than the graphical.target.

The system, in that case, boots as expected, fully and without any obvious
error. Errors appear when trying 'startx' . Examining /var/log/Xorg.0.log,
as follow:

======[trimmed beginning]
[   313.980] (II) NVIDIA(0): Virtual screen size determined to be 1920 x
1080
[   313.983] (--) NVIDIA(0): DPI set to (30, 30); computed from
"UseEdidDpi" X config
[   313.983] (--) NVIDIA(0):     option
[   313.983] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect
memory
[   313.983] (II) NVIDIA:     access.
[   314.011] (EE) NVIDIA(0): Failed to allocate software rendering cache
surface: out of
[   314.011] (EE) NVIDIA(0):     memory.
[   314.011] (EE) NVIDIA(0):  *** Aborting ***
[   314.015] (EE)
Fatal server error:
[   314.015] (EE) NVIDIA: A GPU exception occurred during X server
initialization(EE)
[   314.015] (EE)
Please consult the The X.Org Foundation support
     at http://wiki.x.org
 for help.
[   314.015] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   314.015] (EE)
[   314.067] (EE) Server terminated with error (1). Closing log file.
======

I have seen this before and will have to go back to notes to revisit that.

Further: attempting to change runlevel with 'systemctl start
graphical.target' or simply to start the SDDM greeter with `sudo service
sddm start` results in the exact same screen flashing that characterized
failed boot in graphical.target unattended boot. Looking at
/var/log/sddm.log I see:

======
[01:18:25.569] (II) DAEMON: Initializing...
[01:18:25.572] (II) DAEMON: Starting...
[01:18:25.572] (II) DAEMON: Adding new display on vt 7 ...
[01:18:25.572] (II) DAEMON: Display server starting...
[01:18:25.572] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{052cc01f-c90c-4c2f-a993-00b37ef851ce} -background none
-noreset -displayfd 18 vt7
[01:18:25.685] (EE) DAEMON: Display server failed to start. Exiting
[15:52:57.165] (II) DAEMON: Initializing...
[15:52:57.182] (II) DAEMON: Starting...
[15:52:57.182] (II) DAEMON: Logind interface found
[15:52:57.182] (II) DAEMON: Adding new display on vt 7 ...
[15:52:57.184] (II) DAEMON: Loading theme configuration from ""
[15:52:57.184] (II) DAEMON: Display server starting...
[15:52:57.184] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -auth
/var/run/sddm/{6006e77c-79a4-4ad4-a791-85cea1e0e1e3} -background none
-noreset -displayfd 17 -seat seat0 vt7
[15:52:58.161] (EE) DAEMON: Failed to read display number from pipe
[15:52:58.162] (EE) DAEMON: Display server failed to start. Exiting

======

Very strangely, and this may be a pointer to a solution, although I cannot
start X from the commandline after an unattended standard boot into
multi-user.target, by booting into rescue mode and manually starting D-Bus
and invoking the graphic interface with `service dbus start ;  systemctl
start graphical.target` I get a working SDDM screen and can log in and use
Cinnamon, including applications such as Firefox ESR so that I can submit
this report from that machine.

So: I will characterize this as a bug with SDDM and/or X. Possibly SDDM
needs to be rebuilt against the latest nvidia drivers and libraries, I seem
to recall that may be one way to resolve that issue. I'll try that later,
but thought I should report this.

Incidentally, D-Bus may be only incidentally or peripherally involved.
Under the semi-successful boot to multi-user.target, I do find this
grepping in the journal.log:

Aug 09 15:38:30 nasty-1 systemd[1]: Listening on D-Bus System Message Bus
Socket.
Aug 09 15:38:30 nasty-1 systemd[1]: Started D-Bus System Message Bus.
Aug 09 15:38:30 nasty-1 systemd[1]: Starting LVM2 D-Bus service...
Aug 09 15:38:31 nasty-1 NetworkManager[846]: <info>  [1533843511.0813]
bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
Aug 09 15:38:31 nasty-1 systemd[1]: Started LVM2 D-Bus service.
Aug 09 15:39:03 nasty-1 systemd[2247]: Starting D-Bus User Message Bus
Socket.
Aug 09 15:39:03 nasty-1 systemd[2247]: Listening on D-Bus User Message Bus
Socket.

Thanks for your help, if I get this solved I'll let you know so this can be
closed or marked resolved as you deem fit.

Regards,



On Sun, Jul 29, 2018 at 7:12 AM Simon McVittie <smcv at debian.org> wrote:

> Control: retitle -1 dbus-daemon does not start, perhaps related to having
> a separate /var
>
> On Sat, 28 Jul 2018 at 15:25:47 -0400, Thomas Hardman wrote:
> > I have /var on a "spinner" drive along with /home and /tmp, and /  and
> /usr are
> > on two different partitions of an NVME/PCIe solid-state drive.
> >
> > /etc/fstab mounts these partitions from the "spinner" drive using UUID
> rather
> > than calling (for example) /dev/sda1 to mount on /var. Possibly
> irrelevant.
> >
> > Is it possible that somewhere in the process of mounting the spinner
> partition
> > for /var, the dbus directory with dbus.service and dbus.socket becomes
> > inaccessible and need to be recreated with `service dbus restart`?
>
> Aha. A separate /var mounted relatively late in boot is an unusual
> configuration: it is meant to be supported, but few developers test it,
> so I could well believe that it has regressed at some point.
>
> I'm going to ask some leading questions now, but please don't change
> your system configuration yet based on the answers you think I'm looking
> for to these questions: I might need to ask further questions for more
> diagnostics before settling on a solution.
>
> On your root partition (if you mount the root from an initrd, live-CD or
> similar recovery media), is /var/run a symbolic link to /run, or a real
> directory, or does it not exist at all?
>
> On your /var partition, is /var/run a symbolic link to /run, or is it a
> real directory?
>
> Does your /etc/fstab have an entry for /var/run?
>
> Please could you attach your entire /etc/fstab? If there's anything
> you consider to be sensitive in there, you can email it to smcv at debian.org
> instead of sending it to 903851 at bugs.debian.org, or censor it by replacing
> UUIDs, user-defined directory names etc. with xxxxx, yyyyy etc. in a
> consistent way.
>
> It would also be helpful if you could send /var/log/syslog entries
> for an entire bootup sequence (again, send it to me privately if you
> prefer, and it's OK to censor it but please make it obvious where you
> have done so).
>
> Thanks,
>     smcv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20180809/603c6372/attachment.html>