Bug#800342: first mount /var, then write to it

[Felipe Sateler]

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 <jidanni at jidanni.org> 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