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
Re: PWS 433au (Miata) recovery update
On 1/27/19 22:53, Alex Winbow wrote: On Mon, 28 Jan 2019, Michael Cree wrote: samba build-depends on ceph [1] but ceph hasn't built on Alpha for some time [2]. Looks like dtp-relative relocation errors during linking in the build of ceph [3] is the reason. I have a theory that gcc is not taking the spec file listed in its invocation arguments in the correct order with other passed arguments thus we are not getting correct linking for some shared libraries in the repository. That leads to FTBFS in other packages with these dtp-relative relocation errors. I haven't explored my theory enough to make a bug report against gcc. Thanks, Michael. How can I help debug this? The alpha I'm bringing up will be a replacement server. Does anyone have an archive of "samba-common_4.7.3+dfsg-1_all.deb"? That seems like it may be missing piece for installing the older samba 4.7.3 for now on alpha (the binary packages still being present in the archive). snapshot.debian.org seems to still have it on: https://snapshot.debian.org/package/samba/2%3A4.7.3%2Bdfsg-1/#samba-common_2:3a:4.7.3:2b:dfsg-1 Direct download from: https://snapshot.debian.org/archive/debian/20171124T034111Z/pool/main/s/samba/samba-common_4.7.3%2Bdfsg-1_all.deb
Re: Re: PWS 433au (Miata) recovery update
On Mon, 28 Jan 2019, Michael Cree wrote: samba build-depends on ceph [1] but ceph hasn't built on Alpha for some time [2]. Looks like dtp-relative relocation errors during linking in the build of ceph [3] is the reason. I have a theory that gcc is not taking the spec file listed in its invocation arguments in the correct order with other passed arguments thus we are not getting correct linking for some shared libraries in the repository. That leads to FTBFS in other packages with these dtp-relative relocation errors. I haven't explored my theory enough to make a bug report against gcc. Thanks, Michael. How can I help debug this? The alpha I'm bringing up will be a replacement server. Does anyone have an archive of "samba-common_4.7.3+dfsg-1_all.deb"? That seems like it may be missing piece for installing the older samba 4.7.3 for now on alpha (the binary packages still being present in the archive). Thanks, -Alex
Re: Re: PWS 433au (Miata) recovery update
On Sun, Jan 27, 2019 at 12:25:52PM -0800, Alex Winbow wrote: > Samba isn't installable, and in fact I can't even build-dep to build > myself locally; looks like the dependency chain goes all the way back to a > specific version of libboost!?!? samba build-depends on ceph [1] but ceph hasn't built on Alpha for some time [2]. Looks like dtp-relative relocation errors during linking in the build of ceph [3] is the reason. I have a theory that gcc is not taking the spec file listed in its invocation arguments in the correct order with other passed arguments thus we are not getting correct linking for some shared libraries in the repository. That leads to FTBFS in other packages with these dtp-relative relocation errors. I haven't explored my theory enough to make a bug report against gcc. Cheers Michael. [1] https://buildd.debian.org/status/package.php?p=samba=sid [2] https://buildd.debian.org/status/package.php?p=ceph=sid [3] https://buildd.debian.org/status/fetch.php?pkg=ceph=alpha=12.2.10%2Bdfsg1-1=1546145667=0
Re: Re: PWS 433au (Miata) recovery update
Bob, 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'. Now, systemd happily mounts all the local filesystems at boot, and I no longer get dropped to the emergency shell. So, the trouble seems to be with running fsck on these fs, but I've no idea what the cause may be. Couple other things I found: in /etc/network/interfaces, "allow-hotplug eth0" doesn't seem to work nicely with systemd, but "auto eth0" does. Samba isn't installable, and in fact I can't even build-dep to build myself locally; looks like the dependency chain goes all the way back to a specific version of libboost!?!? Thanks, -Alex
