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 <s...@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 s...@debian.org > instead of sending it to 903...@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 >
_______________________________________________ Pkg-utopia-maintainers mailing list Pkg-utopia-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers