[ale] Remove systemd network handling

[Ed Cashin]

I don't think that interesting information about Linux distributions is
less interesting "a month later."

I'm glad I learned about the policy differences between Raspian and
Debian.  I have a Raspberry Pi and am better off for reading the response.

On Thu, Oct 14, 2021 at 11:43 PM Alex Carver via Ale <ale at ale.org> wrote:

> Why are we pulling this up almost a month later?
>
> Raspberry Pi OS installed and enabled a feature that was not in use
> prior to a system update.  No other users exist on the unit therefore I
> am confident I did not authorize a change on my own.
>
> Is it a bug?  Yes.  Reported and ignored.  I can't do anything about that.
>
> Do I believe the fault was systemd-networkd?  Yes because it was enabled
> by the upgrade process without issuing a warning that it was going to do
> so or I would have backed out those changes.  My gripe was two-fold:  an
> update caused systemd-networkd to be installed and enabled and
> systemd-networkd was terrible at maintaining the network connection that
> was previously stable.  That's one bug for each component.
>
> As for upgrades, Raspberry Pi documents the upgrade process but makes
> the same claims as many other distributions "make backups, we can't
> guarantee this will work", etc.  Considering I've upgraded a dozen Pis
> through several versions of Raspberry Pi OS.  This one happened to be
> the first one to get the buster update and once I saw what happened I
> was able to prevent the systemd-networkd installation on other units.
>
> So again, NO this is not on me.  I've already had experience with the
> upgrade paths previously and all were successful until this one.
>
> Now telling me I should have tried to fix it but somehow it's
> impractical is very insulting. I came here to ask how to remove
> systemd-networkd permanently precisely because I did perform root-cause
> and found that systemd-networkd was indeed the problem.   I didn't need
> its services therefore the fix is to remove it.  I don't need to try to
> debug why systemd-networkd wasn't working, that's for someone else that
> cares about it.
>
> The Pi has now been running for a month without a single network error
> since removing systemd-networkd.  That tells me my root-cause analysis
> was correct.  Trying to blame the hardware that I know works fine
> instead of accepting that your pet software might actually have a bug is
> deflection.  I couldn't run five days without the network dropping and
> now I've gone a month with zero issues so I just proved my hardware is
> fine.
>
> TYVM.
>
>
> On 2021-10-13 07:02, Solomon Peachy via Ale wrote:
> > On Fri, Sep 24, 2021 at 10:22:43PM -0700, Alex Carver via Ale wrote:
> >> To get security fixes and some library bug fixes I had to update.  It
> >> was not possible to stay with Stretch and get all the fixes I would have
> >> needed hence the upgrade to Buster.  Nowhere in the notes did it
> >> indicate it was going to automatically add systemd timers to fire off
> >> apt and do background system updates.
> >
> > To be fair, I recall Raspbian enabling automatic background apt metatada
> > updates by default.  Whether that was implemented using cron or systemd
> > timers is immaterial; the policy did not change, only the mechanism used
> > to implement it.
> >
> > Now Debian as a general rule tries very hard to respect user
> > configuration across updates but nothing is infalliable, that's why I
> > asked if you'd reported this bug.  Assuming it was due to a _Debian_
> > change as opposed to _Raspbian_ -- there are a bunch of subtle (and
> > not-so-subtle) differencs between them, least of which including the
> > core purpose of the distribution.
> >
> > But no [mainstream] linux distro I'm aware of automatically _applies_
> > updates without the user/admin/operator explicitly enabling/approving
> > it.  So again, if something automatically _updated_ in the background,
> > that's *because the operator explicitly turned it on*.
> >
> > Meanwhile, your primary gripe here is that Raspbian apparently changed
> > how their network interfaces were enabled/started/whatever, and it seems
> > systemd-network was implicated.  Yet systemd-networkd is _not_ enabled
> > by default in Debian Bullseye (or Buster) so if it was being used on
> > your unit, again, it's either due to a change that _Raspbian_ made or
> > because someone with root access turned it on.
> >
> > Or maybe Pottering did this in cahoots with Bill Gates using the 5G
> > COVID microchip and a backdoor in all Broadcom SoCs. (In a rare example
> > of the Illuminiati and Chinese Communist Party having aligned interests,
> > because the severe cutback in international flights due to COVID meant
> > they couldn't rely on the traditional chemtrail disperal methods)
> >
> >> I'm disappointed in you Solomon. DO NOT PIN THIS ON ME.  I was not given
> >> the option to keep my settings as they were, I would have not approved
> >> them and gone a different route if it had been disclosed.  Flippant
> >> suggestions of "don't change it" don't support the case that this change
> >> should have not done harm since your case is that systemd is better and
> >> this is objectively not the case in this instance where removing a
> >> portion fixed a problem.
> >
> > The Raspberry Pi folks have long recommended _against_ doing in-place
> > major upgrades from one OS release to the next, and have _never_
> > provided a supported upgrade path.  While yes, it generally works thanks
> > to the efforts of Debian, Raspbian-specific changes to Debian aren't
> > checked, and won't block releases.  This might be an example of one of
> > the consequences of undertaking this path.
> >
> > So, yes, this _is_ on you -- You chose to undertake a path that was not
> > supported by upstream, who made no particular promises that it could be
> > expected to work, on a critical production system without first doing a
> > shakedown run to make sure there weren't any issues.  Or maybe this was
> > the shakedown run.  Either way, bugs are to be expected because only
> > _you_ can test your own environment. You deal with them and move on.
> >
> > A useful data point here would be to install a from-scratch default
> > Raspbian loadout and see if it exhibited the same wonkiness.  If not,
> > it's due to administrator/operator changes, most likely the unsuppported
> > upgrade. If it _does_ show the same wonkiness, to me that still
> > indicates some sort of physical hardware/connectivity issue that might
> > not be handled properly, because the problem you're reporting is hardly
> > widespread -- these days they're cranking out something like a million
> > of these things every month.
> >
> >> I've reported it, it falls on deaf ears so not much I can do beyond
> that.
> >
> > Reporting it is the bare minimum.  But it's all Free Software, so you
> > could have tried to root-cause and fix the problem yourself -- but I
> > understand that's often (usually?) not practical for most folks.
> >
> >  - Solomon
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > https://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>


-- 
  Ed Cashin <ecashin at noserose.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20211015/d1eb2750/attachment.htm>