Control: clone -1 -2 Control: reassign -1 alsa-utils Control: retitle -1 alsa-utils: udev rule should use /run, not /var/run Control: reassign -2 dnsmasq Control: retitle -2 dnsmaq: resolvconf snippet should use /run, not /var/run
On 27 September 2015 at 05:32, 積丹尼 Dan Jacobson <[email protected]> wrote: > 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/resolvconf/update.d/dnsmasq: > Error: Failed trying to create directory /var/run/dnsmasq The dnsmasq resolvconf script should use /run instead of /var/run if it wants to be able to run during early boot. > Sep 27 16:17:03 jidanni2 systemd-udevd[292]: Process '/usr/sbin/alsactl -E > HOME=/var/run/alsa restore 29' failed with exit code 99. > Sep 27 16:17:03 jidanni2 systemd-udevd[297]: Process '/usr/sbin/alsactl -E > HOME=/var/run/alsa restore 1' failed with exit code 99. > Sep 27 16:17:03 jidanni2 systemd-udevd[299]: Process '/usr/sbin/alsactl -E > HOME=/var/run/alsa restore 0' failed with exit code 99. The HOME directive should be changed to use /run/alsa instead of /var/run/alsa to be compatible with early boot (BTW, . > Sep 27 16:17:04 jidanni2 systemd[1]: Mounting /var... > Sep 27 16:17:04 jidanni2 systemd[1]: Mounted /var. > Sep 27 16:17:10 jidanni2 smartd[500]: Device: /dev/sda [SAT], state read from > /var/lib/smartmontools/smartd.FUJITSU_MHT2040AT-NN4GT531H3AR.ata.state > Sep 27 16:17:10 jidanni2 smartd[500]: Device: /dev/sda [SAT], state written > to /var/lib/smartmontools/smartd.FUJITSU_MHT2040AT-NN4GT531H3AR.ata.state > Sep 27 16:17:10 jidanni2 dnsmasq[540]: no servers found in > /var/run/dnsmasq/resolv.conf, will retry > > See how smartd works smoothly, while all the others are disrupted. Smartd is not started in early boot so it does not have this problem. > > Please don't assume that partitions are the same as on your computer. > Especially as when we made the partitions we were using the best > practices at the time. > > Please implement a simple check to prevent the above from happening. These things are running outside the scope of systemd, so systemd cannot ensure the requirements are met. I am reassigning to the offending packages so that the bugs can get fixed. > > By the way, my computer no longer has sound. Maybe due to this. Try running `udevadm trigger --subsystem-match=sound --action=change` to see if rerunning the restore script gives you sound again. Alternatively, there is one report that the latest pulseaudio 7 is not working for them (#800120) -- Saludos, Felipe Sateler _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
