Re: Re: PWS 433au (Miata) recovery update
On Sun, Jan 27, 2019 at 12:25:52PM -0800, Alex Winbow wrote:
> I'm seeing this also, after installing using the Debian 8.0 installer
> and dist-upgrade'ing to unstable (using the SMP kernel trick to get past the
> GENERIC issue). My understanding is that it's not initramfs-tools that
> mounts all the (non-root) local filesystems, but systemd (which it looks
> like you've reported as a bug elsewhere). I was able to pseudo-fix this by
> changing the fs_passno field in /etc/fstab to '0'.
This tells us (or me, anyway) that systemd's logic for automatically
setting up and running "fsck.fstype" for local filesystems is broken.
I don't think the dynamic generation of services and dependencies for
handling local filesystems was part of the "special sauce" for systemd
versions prior to version 235-X, which was when things broke on my system.
Setting the fs_passno field to '0' (electing to not run file system
checks before mounting) will bite you eventually. It's annoying to have
to manually run "e2fsck -p" on three local filesystems (other than '/'
and '/usr') and mount them, but at least the boot process isn't so badly
broken I can't do it.
> Couple other things I found: in /etc/network/interfaces,
> "allow-hotplug eth0" doesn't seem to work nicely with systemd, but "auto
> eth0" does.
Hadn't dug into this enough to determine what's going on, but did notice
that running "ifup eth0" (static IP configuration) while in the emergency
shell was effective. It's interesting you mention "auto eth0" working,
because I've got an IPv6 tunnel interface designated "auto" that depends
on "eth0" being up to function properly, and "systemd" happily configures
the tunnel interface without "eth0" being present.
Have I mentioned today how much I detest "systemd"? :-)
This will get solved eventually, but it would get solved more quickly if
the case of multiple local filesystems was more common today.
--Bob
Reply to: