Package: systemd
Version: 221-1
Severity: wishlist
File: /bin/systemctl
Can't anything bad be detected when given e.g.,
# systemctl disable .servicez ; echo $?
0
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.ali
OK. I opened https://github.com/systemd/systemd/issues/504 .
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
X-Debbugs-cc: rcc...@packages.debian.org, syst...@packages.debian.org
Package: sysv-rc-conf
Version: 0.99-7
Severity: wishlist
Shouldn't some kind of Conflict or Breaks or warning be made for
packages such as sysv-rc-conf and rcconf, which might no longer work
100% as intended, after systemd is in
Package: systemd
Severity: important
Version: 226-3
Please first mount /var before trying to read / write to it! !
# journalctl |grep /var
Sep 27 16:16:57 jidanni2 resolvconf[168]: mkdir: cannot create directory
'/var/run': Read-only file system
Sep 27 16:16:57 jidanni2 resolvconf[168]: /etc/res
Package: systemd
Version: 228-2
Severity: wishlist
Double messages upon disable:
# systemctl disable mysql
Synchronizing state of mysql.service with SysV init with
/lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install disable mysql
insserv: warning: current start runle
Package: systemd
Version: 228-2
Starting today "A stop job is running" now take 10 times as many minutes
than before. 10 or 15 minutes instead of 1.5 minutes. Yes the counter
says ../15 minutes.
Maybe it has something to do with linux-image-4.2.0-1-686-pae, which is
the only relevant package I in
I see, each one has a potentially different time:
# systemctl show dictd -p TimeoutStopUSec
TimeoutStopUSec=5min
However you should still have the "A stop job is running" message:
1) prefix itself with the name of the package (systemd) making the
message.
2) mention how to abort (four fingers plac
Actually it seems a "Failed to fork: Cannot allocate memory" triggered it.
Stopped LSB: No Display Manager.
Stopping ACPI event daemon...
Closed Load/Save RF Kill Switch Status /dev/rfkill Watch.
Deactivating swap /dev/sda12...
Stopped target Sound Card.
Stopping Session c1 of user jidanni.
Starti
Package: systemd
Version: 228-2
Severity: wishlist
File: /usr/share/man/man1/systemctl.1.gz
$ man systemctl # seen with emacs' M-x man:
...ConsistsOf=, Wants=, BindsTo= dependencies. If no unit is
specified, default.target is implied.
By default, only target units a
Package: systemd
Version: 228-2
Severity: wishlist
File: /usr/share/man/man1/systemctl.1.gz
No way to order output. No matter which of
systemctl show \* -p Id -p TimeoutStopUSec
systemctl show \* -p TimeoutStopUSec -p Id
systemctl show \* -p TimeoutStopUSec -p Names
systemctl show \* -p Names -
Gasp, I finally found the culprits,
systemctl show \* -p TimeoutStopUSec -p Id|perl -e '
use strict;
use warnings FATAL => q(all);
my %h;
while (<>) {
chomp;
if ( !length ) {
printf "%s|%s\n", @h{ q(TimeoutStopUSec), q(Id) };
undef %h;
}
elsif (/(.*)=(.*)/) { $h{$1}
Package: systemd
Version: 228-2
Severity: wishlist
File: /usr/share/man/man1/systemctl.1.gz
We read:
--runtime is passed, in which case the settings only apply until
the next reboot. The syntax of the property assignment follows
closely the syntax of assignments in
Package: systemd
Version: 228-2
Severity: minor
are looking for computer-parsable output, use show instead. By
default, this function only shows 10 lines of output and ellipsizes
lines to fit in the terminal window. This can be changes with
s/ changes / changed /
And alas
# systemctl set-property dictd.service TimeoutStopUSec=89sec
Unknown assignment TimeoutStopUSec=89sec.
one cannot change them except by editing each of e.g., /etc/init.d/dictd
individually.
Also Unknown assignment should be Readonly value.
___
Package: systemd
Version: 228-2+b1
Severity: minor
If there are any "(checking 2 filesystems)" type messages to the console
upon boot, the progress will always just show 0.0%.
checking one filesystem messages work fine, but if it is checking more
than one, then progress percentages stay at 0.0% t
Package: systemd
Version: 228-2+b1
Severity: wishlist
Rather than at poweroff just saying "a stop job is running for session
c1 of user jidanni", you should also say what is the culprit behind all
of this.
I.e., the message should also mention which package is involved.
The user is helpless to f
Package: systemd
Version: 233-8
Severity: minor
$ journalctl -f
Please don't write
6月 22 19:10:47 jidanni2 systemd[1]:
dev-serial-by\x2dpath-pci\x2d:00:1d.1\x2dusb\x2d0:2:1.0\x2dport0.device:
Changed dead -> plugged
6月 22 19:10:47 jidanni2 systemd[1]:
dev-serial-by\x2did-usb\x2dSemiTech
It turns out just plain dash works fine.
$ echo systemctl status
dev-disk-by\x2dpath-pci\x2d:00:1f.1\x2data\x2d1.device|sed s/x2/-/g|sh -x
+ systemctl status dev-disk-by-dpath-pci-d:00:1f.1-data-d1.device
● dev-disk-by-dpath-pci-d:00:1f.1-data-d1.device
Loaded: loaded
Active: in
Well
$ systemctl status AA.device
● AA.device
Loaded: loaded
Active: inactive (dead)
if the user doesn't carefully replace \ with \\ he will get the dead
message anyway. Wouldn't it be more accurate to say that that device
could not be found?
___
P
Also systemd is the only program to do such escaping in journalctl. If
every other program followed that lead, journalctl would become unreadable.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.aliot
Perhaps the escapes are to avoid a situation that only happens 1% of the
time. So maybe there could be a different way to write that case...
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debi
By the way, the user might think he got it wright when there is plenty
of output,
$ systemctl show 'Xdev-disk-by\x2dpartuuid-000ed2c3\x2d05.device'|wc
34 35 848
But in fact he can get even more...
$ systemctl show 'dev-disk-by\x2dpartuuid-000ed2c3\x2d05.device'|wc
40 51
Package: systemd-coredump
Version: 234-2
Severity: wishlist
File: /usr/share/man/man1/coredumpctl.1.gz
Man page says
It's worth noting that different restrictions apply to data saved
in the journal and core dump files saved in
/var/lib/systemd/coredump, see overvi
> "MB" == Michael Biebl writes:
MB> coredumpctl afaik uses the journal to look up coredump entries.
MB> Do the coredumps show up in the journal?
It seems so:
/var/log/syslog.6.gz:Aug 9 00:04:56 jidanni6 systemd-coredump[1801]: Process
1797 (epiphany) of user 1000 dumped core...
MB> Have y
# journalctl |grep -c 'Processing coredump'
2
# coredumpctl --no-legend | wc -l
2
# ls /var/lib/systemd/coredump/ | wc -l
12
So on the coredumpctl, after
It's worth noting that different restrictions apply to data saved
in the journal and core dump files saved in
Yes mine do get cleaned out eventually by cron etc.
I'm just unhappy about
NAME
coredumpctl - Retrieve and process saved core dumps and metadata
-1
Show information of a single core dump only, instead of listing all
known core dumps.
Package: initramfs-tools
Version: 0.130
Severity: wishlist
Showing the user warnings like
systemd-udevd[68]: hwdb.bin does not exist, please run systemd-hwdb update
in journalctl is bad, because according to e.g.,
https://bbs.archlinux.org/viewtopic.php?id=189536
there is nothing he can do about i
It is a good thing you contacted me before I powered off, else the
message would have been lost, as it only appears in journalctl.
# zgrep hwdb.bin /var/log/* /var/log/*/*
# dmesg|grep hwdb.bin
# journalctl|grep -C 3 hwdb.bin
Sep 27 16:22:47 jidanni6 kernel: x86/mm: Checked W+X mappings: passed, n
MB> How exactly did you disable the service? If I install the nftables
MB> package I get no such message.
All I know is on my machines I have it disabled,
I think by some '$ systemctrl disable' command I used years ago.
And I only start and stop it via my modem controller script
(no point in havin
Package: udev
Version: 228-3
Severity: grave
Package installation Race Condition? Also filed bug 809743.
Unpacking libpam-systemd:i386 (228-3) over (228-2+b1) ...
dpkg: considering deconfiguration of ifupdown, which would be broken by
installation of systemd ...
dpkg: yes, will deconfigure ifupd
> "MB" == Michael Biebl writes:
MB> We can't unfortunately fix the existing udev.prerm of older versions,
MB> only make sure the new one no longer has the problem.
Well all I know is the user will get himself into my above state, which
takes a
# dpkg -i /var/cache/apt/archives/*_228-2+b1_i38
# su - nobody
No directory, logging in with HOME=/
nobody@jidanni6:/$ < /dev/null > /dev/null COLUMNS=80 man systemctl
:807: warning [p 10, 2.8i, div `3tbd1,1', 0.8i]: can't break
line
:807: warning [p 10, 2.8i, div `3tbd1,1', 1.2i]: can't break
line
:817: warning [p 10, 2.8i, div `3tbd3,1', 1.0
After an install or an enable, the next disable will be good, but a
second and subsequent disable will have the repeated lines.
# systemctl disable haveged
Synchronizing state of haveged.service with SysV init with
/lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install d
reopen 769370
retitle 769370 Trying to run as user instance, but $XDG_RUNTIME_DIR is not set
found 769370 228-4+b1
thanks
Now I am getting
$ systemd --test
Trying to run as user instance, but $XDG_RUNTIME_DIR is not set.
Had to use
$ XDG_RUNTIME_DIR=/tmp systemd --test
Maybe the man page at --te
> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> It seems that the example output in list-sockets is longer than 80 columns.
ZJ> But is this an actual issue? less displays this just fine
ZJ> (wrapping the long lines by default), and can be easily
ZJ> switched to "truncate" them with -+s+ENTE
>>>>> "ZJ" == Zbigniew Jędrzejewski-Szmek writes:
ZJ> On Sat, Jan 30, 2016 at 08:36:04AM +0800, 積丹尼 Dan Jacobson wrote:
>> It would be best to just reengineer your table not to generate the errors.
ZJ> It's the output of an actual command, and the value
Package: systemd
Version: 229-1
Severity: wishlist
At shutdown the screen pauses for many minutes with the last message being
"Stopped raise network interfaces"
upon which I went to the washroom. When I returned the computer had
already finally shutdown.
I suspect that the problem lies with wha
$ cat /etc/fstab
/dev/cdrom5 /cdrom iso9660 defaults,ro,user,noauto 0 0
/dev/sr0 /mnt/usb/cdrom iso9660 defaults,user,noauto 0 0
UUID=-006F /mnt/usb/s1mp3 vfat
iocharset=ascii,shortname=mixed,noauto,noatime,nodiratime,user,fmask=133,uid=jidanni,gid=jidanni
0 0
UUID=1d11e0e3-26d7-42be-89d2-00f
Package: systemd
Version: 230-2
User sees a failure message:
Setting up systemd (230-2) ...
Installing new version of config file /etc/systemd/logind.conf ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Failed to enable unit: Unit /run/systemd/generator/tmp.mo
> "MB" == Michael Biebl writes:
MB> Can you attach your /etc/fstab please and the file /run/systemd/was-enabled.
MB> Is there a file /etc/systemd/system/tmp.mount (or was in the past)?
UUID=355d426a-cbfc-4faf-91d6-4f9405199517 /home auto defaults,commit=111 0 2
UUID=34610b6a-70a3-48d9-b135-9
> "MB" == Michael Biebl writes:
> P.S., because I have /home and /var on their own partitions,
> I get red messages about not being able to unmount them upon shutdown.
MB> Having a separate /home and /var is apsolutely fine. I use that myself
MB> on a couple of systems
I meant /tmp and /ho
> "MB" == Michael Biebl writes:
MB> Why don't you just use "systemctl halt" then? I will shut down your
MB> system but not actually power it off. Very useful if you want to read
MB> the messages on shutdown.
OK. But then how to poweroff when finished reading the messages?
Physically yank the
Package: systemd
Version: 230-2
Severity: wishlist
In https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
one sees it is quite possible to save a /shutdown-log.txt .
Alas the method there does not work on Debian. No /shutdown-log.txt is
produced.
Please:
1. Make it work on Debian.
> "MB" == Michael Biebl writes:
MB> The upstream documentation assumes you have a merged-usr setup.
MB> If you change the paths to use /lib instead of /usr/lib (i.e.
MB> /lib/systemd/system-shutdown/debug.sh), it should work. Can you confirm?
OK indeed it does. (However there seem to be some
Package: systemd
Version: 230-2
Here we see fsck is apparently run _before_ unmounting file systems.
And maybe that is why we see
Failed unmounting /home?
Also there is a Failed unmounting /tmp I can send if you are interested.
# ls -lR /dev/disk/|grep 9405199517
lrwxrwxrwx 1 root root 10 06-09
The problem doesn't happen on every shutdown, but most. So maybe there
is a race condition involved.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-syst
Package: systemd
Version: 230-7
Setting up systemd (230-7) ...
addgroup: The group `systemd-journal' already exists as a system group. Exiting.
Failed to start systemd-networkd-resolvconf-update.path: Unit
systemd-networkd-resolvconf-update.path not found.
___
Package: systemd
Version: 231-4
Doing
Setting up systemd (231-4) ...
addgroup: The group `systemd-journal' already exists as a system group.
Exiting.
while nodm is running knocks the user into a black screen.
To recover: CTRL ALT F1, then login, then do chvt 7... perhaps some
users won
Package: udev
Version: 231-6
Severity: wishlist
Perhaps on upgrade instead of saying
addgroup: The group `input' already exists as a system group. Exiting.
say nothing, and instead just say
Adding group `input'.
if adding.
That way you need only make one message once,
instead of a
Maybe instead test if the group exists via other means, and then only if
it doesn't, use addgroup to add it.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo
severity 843251 grave
thanks
Yes i386.
And you know what?
the user cannot ever boot his computer ever again, even from grub
menus' "(recovery mode)".
ER> I can confirm this behaviour. Be care to reboot:
ER> If booting with systemd you will be pulled in maintenance mode.
No you (I) will never get
found 826297 232-3
retitle 826297 really should document the Debian way to create /shutdown-log.txt
thanks
Many Debian users will read
https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingshutdownproblems
and scratch their heads about why no /shutdown-log.txt is produced.
Therefore,
> "MB" == Michael Biebl writes:
MB> With merged-usr this will be obsolete
OK. What should I mention in the patch do deal with both cases, pre
merged-usr and post merged-usr? Or maybe I can make one sized fits all
instructions?
___
Pkg-systemd-main
Package: systemd
Version: 232-3
File: /bin/systemctl
Do you see how users might be alarmed if they see:
# systemctl enable mysql
Synchronizing state of mysql.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable mysql
insserv
--- README.Debian 2016-11-19 07:17:12.657166692 +0800
+++ README.Debian.NEW 2016-11-19 07:25:48.293169579 +0800
@@ -45,6 +45,16 @@
and then get more detailed information with "systemctl status -l foo.service"
to get a service "foo"'s status and recent logging.
+To make a /shutdown-log.t
OK but also mention there any long term bad effects if one leaves the
shutdown log producing setup there all the time.
(Also it would be cleaner if one could just enable / disable this...
Oh, but that would need to write things to grub.)
___
Pkg-systemd
Package: systemd
Version: 232-7
Severity: wishlist
Maybe only print Time has been changed log message once
12月 25 08:24:48 jidanni3 ntpd[2504]: Soliciting pool server
2001:b030:131b:ff00::1
12月 25 08:23:52 jidanni3 systemd[1146]: Time has been changed
12月 25 08:23:52 jidanni3 systemd[1]: Time has
> "MB" == Michael Biebl writes:
MB> Why would anyone want to install insserv manually under systemd in
MB> stretch? It's no longer needed and should not be pulled in by other
MB> packages.
Then please add a Breaks or Conflicts or something, as there are a
thousand ways it could get installed
Also when I want to remove insserv, aptitude asks
Remove the following packages:
1) initscripts [2.88dsf-59.8 (now, unstable)]
2) sysv-rc [2.88dsf-59.8 (now, unstable)]
3) sysv-rc-conf [0.99-7 (now, unstable)]
Which seems dangerous...
http://unix.stackexchange.com/questions/21415
MB> No, removing the above packages is totally safe in stretch (when using
MB> systemd)
(the only names I can remember are experimental, sid, testing, and stable.)
MB> Actually, you can run
MB> apt purge sysv-rc initscripts insserv startpar
MB> and I would recommend that to anyone upgrading to st
Package: systemd
Version: 232-12
As you see in Bug#852194, systemd is failing to log its output at boot time.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinf
Yes, barely left on the screen during boot, and not available in journalctl
-xb, was a message telling me to run
"systemctl status systemd-modules-load.service".
Anyway Bug#852152 has some more of my logs attached.
CH> So, wild guess... race condition between journald starting and services
start
Package: systemd
I saw this error. All I could find was Bug#238688 .
Preparing to unpack .../systemd_208-5_i386.deb ...
Unpacking systemd (208-5) over (208-3) ...
Processing triggers for dbus (1.8.6-1) ...
/usr/sbin/invoke-rc.d: line 288: /sbin/runlevel: No such file or directory
[ ok ] system me
> "MB" == Michael Biebl writes:
MB> Please provide a complete apt log.
Start-Date: 2014-07-11 01:47:04
Install: systemd-sysv:i386 (208-5)
Upgrade: libsystemd-daemon0:i386 (208-3, 208-5), systemd:i386 (208-3, 208-5),
libsystemd-login0:i386 (208-3, 208-5), libpam-systemd:i386 (208-3, 208-5),
> "MB" == Michael Biebl writes:
MB> Which version of the sysvinit package is installed?
sysvinit:
Installed: 2.88dsf-55.2
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi
OK what anybody used to do in /etc/rc.local can all be now often also be
done instead via making a non-symlinked
/etc/systemd/system/getty.target.wants/getty@tty1.service and changing
# ExecStart=-/sbin/agetty --noclear %I
ExecStart=-/sbin/agetty --noclear --autologin root %I
# Restart=always
Rest
That is now nice to know but I already worked all night on my solution
which is now perfect except for the cosmetic issue of leaving a dead
tty1. OK thanks anyway. I'll ask them at
https://plus.google.com/107326194379039522045/posts/4Lk6mpsmhAT
___
Pkg-s
Package: systemd
Version: 208-6
Severity: minor
File: /usr/share/man/man1/systemctl.1.gz
http://www.freedesktop.org/software/systemd/man/systemctl.html
says
$SYSTEMD_LESS
Override the default options passed to less ("FRSXMK").
No wonder!
Bug: this is missing from the Debian man page.
__
Package: systemd
Version: 208-8
File: /lib/systemd/system/rescue.service
Consider what happens when the user sees this message,
ExecStartPre=-/bin/echo -e 'Welcome to rescue mode! Type "systemctl default" or
^D to enter default mode.\\nType "journalctl -xb" to view system logs. Type
"systemctl r
Package: systemd
Version: 208-8
File: /lib/systemd/system/rescue.service
I notice when typing "reboot" from the rescue (etc.?) shell that one
gets the shell prompt back right away, and thinks 'well that didn't
work,' and goes on typing commands... and then after a few seconds,
mid-command, finds i
Package: systemd
Version: 214-1
Installing new version of config file /etc/systemd/logind.conf ...
ln -s '/lib/systemd/system/getty@.service'
'/etc/systemd/system/getty.target.wants/getty@tty1.service'
ln -s '/lib/systemd/system/remote-fs.target'
'/etc/systemd/system/multi-user.target.wants/remo
Package: systemd
Version: 214-1
What should I do about
Preparing to unpack .../systemd_214-1_i386.deb ...
Unpacking systemd (214-1) over (208-7) ...
dpkg: warning: unable to delete old directory
'/etc/systemd/system/multi-user.target.wants': Directory not empty
Which contains
lrwxrwxrwx 1 roo
Package: systemd
Preparing to unpack .../acpid_1%3a2.0.23-1_i386.deb ...
Unpacking acpid (1:2.0.23-1) over (1:2.0.22-3) ...
dpkg: warning: unable to delete old directory
'/etc/systemd/system/sockets.target.wants': Directory not empty
Preparing to unpack .../apt-show-versions_0.22.4_all.deb ...
Un
Package: systemd
Version: 214-1
Severity: minor
File: /usr/share/man/man5/systemd.service.5.gz
Here is my emacs log:
Please wait: formatting the 5 systemd.service man page...
5 systemd.service man page formatted
Invoking man 8 systemctl in the background
error in process sentinel: Man-bgproc-senti
Package: systemd
Version: 214-1
File: /bin/systemctl
# systemctl enable dictd; echo $?
Synchronizing state for dictd.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d dictd defaults
Executing /usr/sbin/update-rc.d dictd enable
0
# systemctl is-enabled dictd; echo $?
Failed
Package: systemd
Version: 214-1
Severity: wishlist
File: /usr/share/man/man1/systemctl.1.gz
# systemctl snapshot
snapshot-1.snapshot
# ls
#
Mention on the man page,
and when running the command,
where the file ends up.
Indeed it is not even mentioned on
# man systemd.snapshot
Or at least add
> "MB" == Michael Biebl writes:
>> # systemctl is-enabled dictd; echo $?
>> Failed to get unit file state for dictd.service: No such file or directory
>> 1
MB> The issue here is, that dictd only provides a SysV init script and
MB> update-rc.d does not provide an interface to query if a servic
Yes, any explaining why it didn't work messages wouldn't get understood
anyway (by me.) So just give the user what he wants to know in the first place.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.
Package: systemd
Version: 215-4
Severity: minor
Why the \x2d in one 'slice' but not the other?
$ journalctl
9月 23 10:24:06 jidanni2 systemd[1]: Starting system-systemd\x2dfsck.slice.
9月 23 10:24:06 jidanni2 systemd[1]: Created slice system-systemd\x2dfsck.slice.
9月 23 10:24:06 jidanni2 systemd[
Package: systemd
Version: 215-5+b1
Severity: wishlist
Please print error messages for systemctl disable
# systemctl disable sshd
# systemctl disable sshdd
# systemctl disable sshddd
# systemctl disable ssh
# systemctl disable ssh; echo $?
0
#
__
Package: systemd
Version: 215-5+b1
File: /usr/share/man/man1/systemd.1.gz
The user sees:
OPTIONS
The following options are understood:
--test
Determine startup sequence, dump it and exit. This is an option
useful for debugging only.
The user tries:
$ systemd
Package: systemd
Version: 217-1
Severity: minor
User sees alarming "Failed" message upon upgrade:
Setting up systemd (217-1) ...
Installing new version of config file
/etc/dbus-1/system.d/org.freedesktop.machine1.conf ...
Installing new version of config file
/etc/dbus-1/system.d/org.freedeskto
Package: systemd
Version: 217-2
Severity: grave
Could not start nodm with systemd 217-1 or 217-2.
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-system
Using 217-2 says nodm is masked.
Had to revert to 215-7 to get it to work.
Give it a try and tell me what happens.
# nodm configuration
# Set NODM_ENABLED to something different than 'false' to enable nodm
NODM_ENABLED=true
# User to autologin for
NODM_USER=jidanni
# First vt to try when looking
84 matches
Mail list logo
