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