Bug#892989: weird chars found in dpkg output
On 03/15/18 18:46, Michael Biebl wrote: With a UTF-8 locale (which you really should enable), systemctl will use '→', for a non-UTF8 locale, systemctl will fall back to '->' Sorry to say, but thats ridiculous. Shouldn't it work no matter what? Ain't that "if locale == xxx" just asking for troubles? ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#873613: systemd gets confused at shutdown time
If there is already a patch 6588, then would you mind to include it for Stretch? How does this patch affect the big problem (important services being shut down too early)? Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#873613: systemd gets confused at shutdown time
Package: systemd Version: 232-25+deb9u1 At shutdown time systemd just shows a message saying watchdog: watchdog0: watchdog did not stop! for 5 minutes :-(. If I boot without quiet, then systemd reveals that it gets confused by service dependencies, nfs mount points and probably some virtual block devices (mdadm, lvm2, crypt, etc). Basic problem seems to be indicated by the message nfs: server nfs-home not responding, timed out pretty late at shutdown time. 90 secs before it tried to unmount the local mount points. Apparently it ignored NFS completely. No wonder that it got stuck. Would you mind to check and fix for stretch? Thanx in advance Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#857270: systemd.link(5) should be included in udev
Package: udev Version: 232-18 Since systemd.link(5) applies to "non-systemd" systems as well, the man page should be moved to udev to make it available for all. See https://lists.debian.org/debian-user/2017/02/msg00936.html Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#856934: please improve "unknown error -1" message
Package: systemd Version: 215-17+deb8u6 Sometimes systemctl fails with systemctl: Failed to get D-Bus connection: Unknown error -1 Since dbus is some IPC mechanism systemctl should provide at least information about the peer it was trying to reach. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#818676: disable timeout for old-style run level scripts
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: systemd Version: 215-17+deb8u3 I have an old-style startup script that gets killed after 5min due to a timeout, even though it is just not finished yet. How can I tell systemd-sysv-generator to use TimeoutSec=0 for compatibility with Wheezy and earlier releases? Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW7XRrAAoJEAqeKp5m04HLccUH/0yKgxTetotqxMYf1uAec5Qs yG5bUwh5D1mYNK6p9vQX1j/ak8RwdyK480lUctqzZFUsn3Db9SfFIXqegWpa1X+S E5ZMHpGuMEvZoPt9EEo4WYPYiPJj7JIIQzNgEa32WmJq1gU+IpIMBbqxO9WDEWpE 4xElfJNQbIySXBexzB7n9sfB9F3NFUp+nrVIlNXzYgnOaGu8BhaNtG3MWO7M1Ck9 3b3IIxFJ7wS+wLb0tvsB6joLhjDHF52uDw/1oIBKJKgTUWXyl10ZzO874Y595mMr m2vst1XWODrxWJ47NzWYNokH+R/rNo/5vk4XoLUMcPHf2CKSZo1aMEzUxqvMfXQ= =nSvE -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#818358: journalctl has lost a huge part
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: systemd Version: 215-17+deb8u3 I've seen it several times that the journal does not include the very first steps at boot time. Sample: # journalctl -b | head -20 - -- Logs begin at Wed 2016-03-16 07:48:02 CET, end at Wed 2016-03-16 11:42:09 CET. -- Mar 16 09:50:11 lxc05.example.com systemd-journal[79]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available â current limit 3.1G). Mar 16 09:50:11 lxc05.example.com systemd-journal[79]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available â current limit 3.1G). Mar 16 09:50:11 lxc05.example.com systemd-journal[79]: Journal started Mar 16 09:50:11 lxc05.example.com anacron[60]: Anacron 2.3 started on 2016-03-16 Mar 16 09:50:11 lxc05.example.com anacron[60]: Normal exit (0 jobs run) Mar 16 09:50:11 lxc05.example.com cron[65]: (CRON) INFO (pidfile fd = 3) Mar 16 09:50:15 lxc05.example.com cron[65]: (CRON) INFO (Running @reboot jobs) Mar 16 09:50:24 lxc05.example.com ntpd[81]: ntpd 4.2.6p5@1.2349-o Wed Oct 28 20:16:08 UTC 2015 (1) Mar 16 09:50:25 lxc05.example.com systemd[1]: Started LSB: Start NTP daemon. Mar 16 09:50:27 lxc05.example.com ntpd[83]: proto: precision = 0.218 usec Mar 16 09:50:27 lxc05.example.com ntpd[83]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listen and drop on 1 v6wildcard :: UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listen normally on 2 lo 127.0.0.1 UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listen normally on 3 lo ::1 UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listen normally on 4 eth1 fe80::216:a8ff:fe3d:3edc UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listen normally on 5 eth0 fe80::216:17ff:fe4b:d246 UDP 123 Mar 16 09:50:31 lxc05.example.com ntpd[83]: peers refreshed Mar 16 09:50:31 lxc05.example.com ntpd[83]: Listening on routing socket on fd #22 for interface updates Mar 16 09:50:31 lxc05.example.com ntpd[83]: authreadkeys: file /etc/ntp/keys: No such file or directory It should have shown something like this: # journalctl -b | head -20 - -- Logs begin at Wed 2016-03-16 07:48:01 CET, end at Wed 2016-03-16 11:49:22 CET. -- Mar 16 09:49:33 lxc06.example.com systemd-journal[23]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available â current limit 3.1G). Mar 16 09:49:33 lxc06.example.com systemd-journal[23]: Runtime journal is using 8.0M (max allowed 3.1G, trying to leave 4.0G free of 31.4G available â current limit 3.1G). Mar 16 09:49:33 lxc06.example.com systemd-journal[23]: Journal started Mar 16 09:49:33 lxc06.example.com systemd[1]: Mounted Huge Pages File System. Mar 16 09:49:33 lxc06.example.com systemd[1]: Mounted Debug File System. Mar 16 09:49:33 lxc06.example.com systemd[1]: Mounted POSIX Message Queue File System. Mar 16 09:49:33 lxc06.example.com systemd[1]: Started Remount Root and Kernel File Systems. Mar 16 09:49:33 lxc06.example.com systemd[1]: Started Various fixups to make systemd work better on Debian. Mar 16 09:49:33 lxc06.example.com systemd[1]: Starting Load/Save Random Seed... Mar 16 09:49:33 lxc06.example.com systemd[1]: Starting Local File Systems (Pre). Mar 16 09:49:33 lxc06.example.com systemd[1]: Reached target Local File Systems (Pre). Mar 16 09:49:33 lxc06.example.com systemd[1]: Starting Local File Systems. Mar 16 09:49:33 lxc06.example.com systemd[1]: Reached target Local File Systems. Mar 16 09:49:33 lxc06.example.com systemd[1]: Starting Remote File Systems. Mar 16 09:49:36 lxc06.example.com systemd-journal[23]: Permanent journal is using 8.0M (max allowed 2.0G, trying to leave 4.0G free of 2.8T available â current limit 2.0G). Mar 16 09:49:56 lxc06.example.com systemd-journal[23]: Time spent on flushing to /var is 19.210500s for 15 entries. Mar 16 09:49:34 lxc06.example.com systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Mar 16 09:49:42 lxc06.example.com systemd[1]: Started Create Volatile Files and Directories. Mar 16 09:49:42 lxc06.example.com systemd[1]: Starting Update UTMP about System Boot/Shutdown... Both hosts are LXC container, identical setup, running on the same hardware and booted in parallel. Its essential to have a complete journal. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW6TvpAAoJEAqeKp5m04HLTvgIAJdnKee8dDo0IBWvFGP4cuXw RXWK3xj1gKbsSJE2evxOsoCmsJCSI/tun34UiKsAvhsu7FazOYGZJZfplGSbwU+U uRfm9cafKARhJFNt+SP9J8zs6hcgIyj7/wX4Q0DLvn+Hl79KFjB7oKgnfpBeQyR+ uas21V+2K408OyFUQMvXQ1XBCB3f0Pe8fPHFxILWnL58RJpKL2Q6iOVgDged/T5A 87W2d2ovms6rdLounp6S7Ad4aMAp9kIkvs/W0OI0z7JkSx8L9tqxyE3nGBX47rWB mztueupq5s6gZ4CGteKS3dAjvDaQnL3LBlRo7SW7b4ri7NmtNdbknTEO6HTcBLs= =Pnbp -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org
Bug#810310: systemd gets stuck at shutdown/reboot
Package: systemd Version: 228-3 Since the most recent upgrade of cryptsetup (2:1.7.0-1) systemd gets stuck at shutdown or reboot. Last message: stopping remaining crypto disks I waited for a minute, then I pulled the plug. systemd must not get stuck, no matter what. Please mail if I can help to track this down. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761812: systemd regression: tries to mount /export twice at boot time
Nope. Its gone away. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800315: Processed: Re: Bug#800315: gets stuck at boot time with "switching to bochsdrmfb from simple"
Hi Michael, Kernel is 3.16.7-ckt11-1+deb8u4 . Using systemd or sysvinit-core doesn't appear to matter here. See attached screenshot for systemd. The workaround (using -vga std on the kvm command line, as mentioned on the user list) did not work for me. I wonder why this report has been set to resolved? Please mail if I can help to track this down. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#800315: gets stuck at boot time with "switching to bochsdrmfb from simple"
Package: udev Version: 215-17+deb8u2 If I try to boot my USB stick image in kvm, then it gets stuck with a message fb: switching to bochsdrmfb from simple or fb: switching to cirrusdrmfb from simple Screenshot is attached. I waited 5 minutes for a login prompt or any other sign of life, then I killed the kvm session. For Wheezy there was no such problem. Regards Harri signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#799253: virtio ens3 network interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/18/15 07:38, Harald Dunkel wrote: > Hi Martin, > > On 09/18/15 04:36, Martin Pitt wrote: > >> Ah, I see. With the current naming system you have to disable the >> predictable names differerently now, either by booting with net.ifnames=0 or >> by creating an empty /etc/udev/rules.d/80-net-setup-link.rules or (more >> elegantly/reliably) set different name(s) in some >> /etc/systemd/network/*.link >> file (see man systemd.link). > > > I haven't tried it yet, but I could live with that. > Just for the record: If you go with the modified udev config file, then you have to rebuild initrd, too. # man systemd.link No manual entry for systemd.link Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV/QZnAAoJEAqeKp5m04HLPq0H/jR6GRuceHDFKGmh9pp7v7+N D5xx890jrltISUNiyO8+sV6jrxnJ9QIA2dSovGe8WRX75O83gdMY4s8r4k0IDxPV PuBggkPIOUB69l+Cc1sO5euBf3uYDkhUoknTHQcyEpSukBQ3kfUgW4DhW1rV24wP /1QHosnBPsqxeLldSvvgKzUxpB3HuSEJd1B7vX+f6eMPDcGT7dLRAIzHD9r35pwt bqj7IoxN5KF07UPIIexxHM7qxxfuxA36A5f2mcMk3iup7F2pqxoSAMeqYyF8v//U ZB4KdRAQ2NMe8esdlcXPHaT1IPr2ucnCJFETzDPcS8GrrcnPUU/QgILMPhnvXws= =iKYV -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#799253: virtio ens3 network interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: udev Version: 226-2 Since I upgraded my KVM host the NIC (virtio) is called "ens3" instead of "eth0". Looking at udev's changelog for 226-2 I had the impression that this is not supposed to happen. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV+oQRAAoJEAqeKp5m04HLGpUH/2oFkq5VSvyQ3z3BCJSr+ue4 cYC3HJMSWA3YbysbeP/vTLgmqoWqpI2B4oQITF3N1QgK0zyZYwT6hweSgl1288Qn UBDC1OgZIfef/5/76SuwPU+VcYvedXmMSnWlowdkEZ0hTzhVQm+WQgIec5m5o8qZ hbMMJawiWhel5DgzvK3p6/WaCRkjBXzvOPfYjp6XEoKxF5/cJovH7JoekmgYCqOS UodTp6V0P0tkykAcmuO07IfffoirQ5AT7ONU76ZqJCQT0b3oE5f6PCEVgUDN/MtW BtJRA4CaPDoOTjfI4naMh/ozH1yeWSWY21c9V44KCJryMfQp3hznC7PUsWWOvgc= =vMjb -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#799253: virtio ens3 network interface
On 09/17/15 15:38, Martin Pitt wrote: > > Okay, so you do have such a device indeed. I don't see what's wrong > then. Can you please run > > sh -x /var/lib/dpkg/info/udev.postinst configure 220-6 > > as root and copy the entire output? > Ah, I see. The udev.postinst script is hardware dependent and evaluated only once at upgrade time, breaking dpkg-reconfigure. The system in question is a bootable USB stick, supposed to run on all my hardware. I boot it in kvm only for maintenance (e.g. for the upgrade). This time the upgrade was done on a real laptop and booted in kvm later. Wouldn't it be more reasonable to add this virtio specific code unconditionally? There might be 2 or more real or virtual network interfaces at upgrade time, e.g. both e1000 and virtio. This shouldn't affect the outcome. My suggestion would be to add a debconf dialog to enable/disable the "network renaming code" (independent from the network interface driver). Using dpkg-reconfigure we would have the usual config interface for this feature, giving everybody a way to choose and to change later. > > Yes, that's a different case -- e1000 (and most other devices) got the > new names since 220-7 already, and there's a different upgrade > mechanism in place. This issue is specifically about virtio devices, > see the commit ref in the initial bug report. > I don't see why this is a different case. Using kvm the e1000 is as virtual as the virtio interface. And its affected by the same broken network configuration after the udev upgrade. ??? Regards Harri + update_hwdb + systemd-hwdb --usr update + addgroup --system input addgroup: The group `input' already exists as a system group. Exiting. + [ -z 220-6 ] + upgrade_fixes configure 220-6 + dpkg --compare-versions 220-6 lt 204-1 + dpkg --compare-versions 220-6 lt 226-1 + update-rc.d udev-finish remove + dpkg --compare-versions 220-6 lt-nl 220-7~ + [ ! -e /etc/udev/rules.d/70-persistent-net.rules ] + dpkg --compare-versions 220-6 lt-nl 226-2~ + [ ! -e /etc/systemd/network/50-virtio-kernel-names.link ] + ls -d /sys/bus/virtio/drivers/virtio_net/virtio0 + echo virtio network devices detected, disabling predictable interface names in /etc/systemd/network/50-virtio-kernel-names.link virtio network devices detected, disabling predictable interface names in /etc/systemd/network/50-virtio-kernel-names.link + mkdir -p /etc/systemd/network/ + cat + chrooted + stat -c %d/%i / + stat -Lc %d/%i /proc/1/root + [ 2050/2 = 2050/2 ] + return 1 + [ -e /etc/udev/kernel-upgrade ] + can_start_udevd + supported_kernel + uname -r + return 0 + [ ! -d /sys/class/ ] + ps --no-headers --format args ax + egrep -q ^\[ + grep -q [[:space:]]devtmpfs$ /proc/filesystems + [ -e /etc/udev/disabled ] + return 0 + handle_service_rename + dpkg --compare-versions lt 204-1 + [ -d /run/systemd/system ] + rm -f /run/systemd/system/systemd-udevd.service + rm -f /run/systemd/system/udev.service + [ -d /run/systemd/system ] + invoke-rc.d udev restart Stopping the hotplug events dispatcher: systemd-udevd. Starting the hotplug events dispatcher: systemd-udevd. + update_initramfs + [ -x /usr/sbin/update-initramfs -a -e /etc/initramfs-tools/initramfs.conf ] + update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.2.0 + [ -x /etc/init.d/udev ] + update-rc.d udev defaults + dpkg-maintscript-helper rm_conffile /etc/init.d/udev-mtab 204-1~ -- configure 220-6 dpkg-maintscript-helper: error: couldn't identify the package + dpkg-maintscript-helper rm_conffile /etc/udev/links.conf 204-9~ -- configure 220-6 dpkg-maintscript-helper: error: couldn't identify the package + dpkg-maintscript-helper rm_conffile /etc/init.d/udev-finish 226-1~ -- configure 220-6 dpkg-maintscript-helper: error: couldn't identify the package + dpkg-maintscript-helper rm_conffile /etc/init/udev-finish.conf 226-1~ -- configure 220-6 dpkg-maintscript-helper: error: couldn't identify the package + dpkg-maintscript-helper rm_conffile /etc/init/udev-fallback-graphics.conf 226-1~ -- configure 220-6 dpkg-maintscript-helper: error: couldn't identify the package + dpkg-maintscript-helper symlink_to_dir /usr/share/doc/udev libudev1 221-2~ -- configure 220-6 dpkg-maintscript-helper: error: environment variable DPKG_MAINTSCRIPT_NAME is required signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#799253: virtio ens3 network interface
Hi Martin, here is more information: root@usbpc:~# ls -al /etc/systemd/network ls: cannot access /etc/systemd/network: No such file or directory root@usbpc:~# grep udev /var/log/aptitude [UPGRADE] libudev1:amd64 220-6 -> 226-2 [UPGRADE] udev:amd64 220-6 -> 226-2 root@usbpc:~# ls -lR /sys/bus/virtio/drivers/virtio_net /sys/bus/virtio/drivers/virtio_net: total 0 --w--- 1 root root 4096 Sep 17 14:42 bind lrwxrwxrwx 1 root root0 Sep 17 14:42 module -> ../../../../module/virtio_net --w--- 1 root root 4096 Sep 17 14:42 uevent --w--- 1 root root 4096 Sep 17 14:42 unbind lrwxrwxrwx 1 root root0 Sep 17 14:42 virtio0 -> ../../../../devices/pci:00/:00:03.0/virtio0 udev.txt is attached. BTW, if I omit the "model=virtio" on the kvm command line and go with the default, then I get a virtual e1000 NIC. It is still named "ens3" instead of "eth0", so I doubt that this is a "virtio-only" problem. Hope this helps. Regards Harri P: /devices/LNXSYSTM:00 E: DEVPATH=/devices/LNXSYSTM:00 E: MODALIAS=acpi:LNXSYSTM: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00 E: DRIVER=button E: MODALIAS=acpi:LNXPWRBN: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 E: EV=3 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: KEY=10 0 E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw E: NAME="Power Button" E: PHYS="LNXPWRBN/button/input0" E: PRODUCT=19/0/1/0 E: PROP=0 E: SUBSYSTEM=input E: USEC_INITIALIZED=2386812 P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2/event1 N: input/event1 E: BACKSPACE=guess E: DEVNAME=/dev/input/event1 E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2/event1 E: ID_INPUT=1 E: ID_INPUT_KEY=1 E: ID_PATH=acpi-LNXPWRBN:00 E: ID_PATH_TAG=acpi-LNXPWRBN_00 E: MAJOR=13 E: MINOR=65 E: SUBSYSTEM=input E: TAGS=:power-switch: E: USEC_INITIALIZED=2439878 E: XKBLAYOUT=us E: XKBMODEL=pc101 E: XKBOPTIONS=terminate:ctrl_alt_bksp P: /devices/LNXSYSTM:00/LNXSYBUS:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00 E: MODALIAS=acpi:LNXSYBUS: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:00 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/LNXCPU:01 E: MODALIAS=acpi:LNXCPU: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0103:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0103:00 E: MODALIAS=acpi:PNP0103: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00 E: MODALIAS=acpi:PNP0A03: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:00 E: MODALIAS=acpi:PNP0A06: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:01 E: MODALIAS=acpi:PNP0A06: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:02 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:02 E: MODALIAS=acpi:PNP0A06: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:03 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0A06:03 E: MODALIAS=acpi:PNP0A06: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:00 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01 E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0303:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0303:00 E: MODALIAS=acpi:PNP0303: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0400:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0400:00 E: MODALIAS=acpi:PNP0400: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0501:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0501:00 E: MODALIAS=acpi:PNP0501: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0501:01 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0501:01 E: MODALIAS=acpi:PNP0501: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0700:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0700:00 E: MODALIAS=acpi:PNP0700: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0B00:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0B00:00 E: MODALIAS=acpi:PNP0B00: E: SUBSYSTEM=acpi P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0F13:00 E:
Bug#747258: system boot slowed down by bad /etc/crypttab
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think thats a misunderstanding. /etc/crypttab is not a systemd config file. It just provides information to cryptsetup about a set of encrypted block devices (online or offline). Thats all. There is neither a reason for systemd to assume that the source devices listed in crypttab have to be available at boot time, nor that the decoded block devices provide a file system, swap partition, physical volume or whatever. /etc/crypttab simply doesn't tell. For example it could be a list of your 20+ encrypted backup disks (USB, usually locked away in a secure place) and the corresponding secret files stored on an encrypted USB stick. *If* you have a block device, and *if* it provides one or more luks partitions, *then* you can look into /etc/crypttab for information about how it should be decrypted. Hope this helps. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV01ckAAoJEAqeKp5m04HLJgYIAIQUaTvmxKLQ+m9PkjgDkWaI w8dKxvmV/geG2BZsjTELCZjBYGJ3HJH2v7wugO5gSaRAhi2Bk0KTMrKAFM1G/XLQ fiVYScNBqEiQLO4oZil9WRmo7uz8m0s/OYTPVpBYoSe/Ci41QWGGztHYsmvYcqOR PN81EweAV5VABnZ+WylrTzglx/G9DnP3mbQOCv9mbG55Ty8Cln9UjHGaj7jHEf9r 63GKRMwyACFWKrb19pH5AziusXg2NbRRMFGGNcqQeDqsucq4YO0Zd4Z1SxEsu952 wM5MpySNWelMIAtF3gNoWomJKMgqgjwZQHpMSO9fhel9aGceMZ9qw8vG3EU/cZE= =C5MI -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#752055: ambiguous option name Type=forking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/05/15 09:35, m...@linux.it (Marco d'Itri) wrote: On May 04, Harald Dunkel ha...@afaics.de wrote: I know the difference between doing a fork(2) and creating a daemon. Instead of pointing to foreign documentation I would suggest to call it type=daemon, if systemd creates a daemon, This is part of the Systemd API and will not be changed for frivolous reasons. It will definitely not be changed as a Debian-specific patch. frivolous? :-) or to explain in the man page, why creating a daemon has been called forking, ignoring all the other man pages you have listed. It looks clear enough to me, but maybe you can persuade the upstream maintainers to accept a documentation patch. Probably you are right to stay compatible with upstream. I wouldn't like to make things worse. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVUyjxAAoJEAqeKp5m04HL/GkH/2sYq3i+VzrZm8UE7Vb7MXAC xEgZASbdLx3dE6ZEY7oKFpBF3LGp/b+E5BJ3g2zWtp+W5HUv7gEmV9ik1/9wxgAg 6hL3Md9g7cmckcsCLieTPxny/g11Oc0xWGo3Krd2oJbp83q2q5yH2C1Vr09hlTXV 99TVlrPkqNQ8yAv4PiPpVWmxU7yZ7r26fJybQBYhrXPVwrF7/TwybDkQAMIJqXUJ XXAga3JeUJTLR8OoW9+tKte9Abc/UDC8UJacC8HcziRBpDeds8wXAJSqkQQVffvn R825ycy6L4yKOq61vm7M9dgKafBjn9PXC+G9XgpUErgsjT55dQ8bwfa7ACBDtzo= =YaXZ -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#752055: ambiguous option name Type=forking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I know the difference between doing a fork(2) and creating a daemon. Instead of pointing to foreign documentation I would suggest to call it type=daemon, if systemd creates a daemon, or to explain in the man page, why creating a daemon has been called forking, ignoring all the other man pages you have listed. To reduce confusion and to keep a common terminology I would recommend option 1. Regards Harri -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVR9bBAAoJEAqeKp5m04HLFBcH/3XWAze++quHcn4QKjAnB3nQ XvQ8U2DLhbfulZ4diemPmPHfTO7JPCyQ67Oyt49LgJw2k4zHIqMPdfMNB5uw15Od vjrFvvHUxkvlt7cADUlyY2rTslM54kg1iv44urvSHEm4gpspSsWorm9DkmV2HmnO OXJ04sUehs8buTapRmgUR/o8boaW8IZU7W/h3CsCefr6EsVdSfsH8SWs9IPTx27y CWUzhQcqkj6j1TjlGJkjJ6Nsn9649muEaPGM483I778CJsLJ1FHuFrUzUi0MMXWv yqe6R+vO8GuesTGptqn0Cuyw9dqhbt1k65sXgLXzhEFzTnS9LHjLCxQA7YKK+mw= =bvMj -END PGP SIGNATURE- ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#761812: systemd regression: tries to mount /export twice at boot time
Package: systemd Version: 208-8 Sometimes systemd tries to mount /export twice at boot time, even though /etc/fstab contains just a single line for it. Since the second mount fails with already mounted the system ends up in interactive maintenance mode, asking for the root password and recommending to read a few thousand lines of journalctl output (not included here). This feels to happen about 1 of 20 reboots of my laptop. / and /export are partitions on an encrypted block device (sda2). Only /boot (sda1) is not encrypted. Here are the necessary tables: % cat /etc/fstab # file system mount point type options dumppass proc/proc proc defaults0 0 # /dev/mapper/vg00-root LABEL=root UUID=92325a57-aefb-4f62-ac31-e0f278c37151 / ext4 noatime 0 1 # /dev/sda1 LABEL=boot UUID=03251663-204e-471a-b093-bb0da815bf72 /boot ext4 noatime 0 2 # /dev/mapper/vg00-export LABEL=export UUID=6e56c46a-8868-4e9e-ad56-8c131dd45f61 /export ext4 noatime 0 2 # /dev/mapper/vg00-rootbak LABEL=rootbak UUID=4092c246-6d69-4071-ab10-f85e911ce352 noneext4 noatime 0 0 # /dev/mapper/vg00-swap LABEL=swap UUID=690457f1-4a9d-4bb6-b50c-296793491a7e noneswap defaults0 0 /dev/sr0/cdrom udf,iso9660 user,noauto,ro 0 0 % blkid | sort /dev/dm-2: LABEL=swap UUID=690457f1-4a9d-4bb6-b50c-296793491a7e TYPE=swap /dev/dm-3: LABEL=rootbak UUID=4092c246-6d69-4071-ab10-f85e911ce352 TYPE=ext4 /dev/mapper/pv00: UUID=JxB8iq-8Z3L-0OpU-Vh8O-0Bwt-ynuX-r4033k TYPE=LVM2_member /dev/mapper/vg00-export: LABEL=export UUID=6e56c46a-8868-4e9e-ad56-8c131dd45f61 TYPE=ext4 /dev/mapper/vg00-root: LABEL=root UUID=92325a57-aefb-4f62-ac31-e0f278c37151 TYPE=ext4 /dev/mapper/vg00-rootbak: LABEL=rootbak UUID=4092c246-6d69-4071-ab10-f85e911ce352 TYPE=ext4 /dev/mapper/vg00-swap: LABEL=swap UUID=690457f1-4a9d-4bb6-b50c-296793491a7e TYPE=swap /dev/sda1: LABEL=boot UUID=03251663-204e-471a-b093-bb0da815bf72 TYPE=ext4 /dev/sda2: UUID=ca74a47d-3110-4eb7-b412-416df77377b9 TYPE=crypto_LUKS /dev/sdb1: SEC_TYPE=msdos LABEL=ssdboot UUID=BE2B-D1AB TYPE=vfat % cat /etc/crypttab # target name source device key file options pv00 UUID=ca74a47d-3110-4eb7-b412-416df77377b9 none luks #pv01 UUID=a0388fed-8404-4e32-8e78-016441830df0 pv00 luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived Nothing unusual, AFAICS. Please mail if I can help to track this down. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
