[ale] Remove systemd network handling

[Alex Carver]

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
>