<div dir="ltr"><div><div><div><div><div><div><div><div><div>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. <br><br></div>Trying an experiment, I set the default boot to the multi-user.target rather than the graphical.target.<br><br></div>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:<br><br></div>======[trimmed beginning]<br>[ 313.980] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080<br>[ 313.983] (--) NVIDIA(0): DPI set to (30, 30); computed from "UseEdidDpi" X config<br>[ 313.983] (--) NVIDIA(0): option<br>[ 313.983] (II) NVIDIA: Using 6144.00 MB of virtual memory for indirect memory<br>[ 313.983] (II) NVIDIA: access.<br>[ 314.011] (EE) NVIDIA(0): Failed to allocate software rendering cache surface: out of<br>[ 314.011] (EE) NVIDIA(0): memory.<br>[ 314.011] (EE) NVIDIA(0): *** Aborting ***<br>[ 314.015] (EE) <br>Fatal server error:<br>[ 314.015] (EE) NVIDIA: A GPU exception occurred during X server initialization(EE) <br>[ 314.015] (EE) <br>Please consult the The X.Org Foundation support <br> at <a href="http://wiki.x.org">http://wiki.x.org</a><br> for help. <br>[ 314.015] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.<br>[ 314.015] (EE) <br>[ 314.067] (EE) Server terminated with error (1). Closing log file.<br>======<br><br></div>I have seen this before and will have to go back to notes to revisit that. <br><br></div>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:<br><br>======<br>[01:18:25.569] (II) DAEMON: Initializing...<br>[01:18:25.572] (II) DAEMON: Starting...<br>[01:18:25.572] (II) DAEMON: Adding new display on vt 7 ...<br>[01:18:25.572] (II) DAEMON: Display server starting...<br>[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<br>[01:18:25.685] (EE) DAEMON: Display server failed to start. Exiting<br>[15:52:57.165] (II) DAEMON: Initializing...<br>[15:52:57.182] (II) DAEMON: Starting...<br>[15:52:57.182] (II) DAEMON: Logind interface found<br>[15:52:57.182] (II) DAEMON: Adding new display on vt 7 ...<br>[15:52:57.184] (II) DAEMON: Loading theme configuration from ""<br>[15:52:57.184] (II) DAEMON: Display server starting...<br>[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<br>[15:52:58.161] (EE) DAEMON: Failed to read display number from pipe<br>[15:52:58.162] (EE) DAEMON: Display server failed to start. Exiting<br><br>======<br><br></div>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. <br><br></div>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. <br><br></div>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:<br><br>Aug 09 15:38:30 nasty-1 systemd[1]: Listening on D-Bus System Message Bus Socket.<br>Aug 09 15:38:30 nasty-1 systemd[1]: Started D-Bus System Message Bus.<br>Aug 09 15:38:30 nasty-1 systemd[1]: Starting LVM2 D-Bus service...<br>Aug 09 15:38:31 nasty-1 NetworkManager[846]: <info> [1533843511.0813] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"<br>Aug 09 15:38:31 nasty-1 systemd[1]: Started LVM2 D-Bus service.<br>Aug 09 15:39:03 nasty-1 systemd[2247]: Starting D-Bus User Message Bus Socket.<br>Aug 09 15:39:03 nasty-1 systemd[2247]: Listening on D-Bus User Message Bus Socket.<br><br></div>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. <br><div><div><div><div><br></div><div>Regards, <br><br></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 29, 2018 at 7:12 AM Simon McVittie <<a href="mailto:smcv@debian.org">smcv@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Control: retitle -1 dbus-daemon does not start, perhaps related to having a separate /var<br>
<br>
On Sat, 28 Jul 2018 at 15:25:47 -0400, Thomas Hardman wrote:<br>
> I have /var on a "spinner" drive along with /home and /tmp, and / and /usr are<br>
> on two different partitions of an NVME/PCIe solid-state drive.<br>
> <br>
> /etc/fstab mounts these partitions from the "spinner" drive using UUID rather<br>
> than calling (for example) /dev/sda1 to mount on /var. Possibly irrelevant.<br>
> <br>
> Is it possible that somewhere in the process of mounting the spinner partition<br>
> for /var, the dbus directory with dbus.service and dbus.socket becomes<br>
> inaccessible and need to be recreated with `service dbus restart`?<br>
<br>
Aha. A separate /var mounted relatively late in boot is an unusual<br>
configuration: it is meant to be supported, but few developers test it,<br>
so I could well believe that it has regressed at some point.<br>
<br>
I'm going to ask some leading questions now, but please don't change<br>
your system configuration yet based on the answers you think I'm looking<br>
for to these questions: I might need to ask further questions for more<br>
diagnostics before settling on a solution.<br>
<br>
On your root partition (if you mount the root from an initrd, live-CD or<br>
similar recovery media), is /var/run a symbolic link to /run, or a real<br>
directory, or does it not exist at all?<br>
<br>
On your /var partition, is /var/run a symbolic link to /run, or is it a<br>
real directory?<br>
<br>
Does your /etc/fstab have an entry for /var/run?<br>
<br>
Please could you attach your entire /etc/fstab? If there's anything<br>
you consider to be sensitive in there, you can email it to <a href="mailto:smcv@debian.org" target="_blank">smcv@debian.org</a><br>
instead of sending it to <a href="mailto:903851@bugs.debian.org" target="_blank">903851@bugs.debian.org</a>, or censor it by replacing<br>
UUIDs, user-defined directory names etc. with xxxxx, yyyyy etc. in a<br>
consistent way.<br>
<br>
It would also be helpful if you could send /var/log/syslog entries<br>
for an entire bootup sequence (again, send it to me privately if you<br>
prefer, and it's OK to censor it but please make it obvious where you<br>
have done so).<br>
<br>
Thanks,<br>
smcv<br>
</blockquote></div>