Arrggh! beware the upgrade...

Is this just 64bit Raspios stuff? I have 32bit Raspios Lite on a PiZeroW and have not had any of these problems. Currently Bookworm 12.1 and Kernel 6.1.21+

However, Debian Bookworm has been a bit s***ty on some AMD64 things. The latest was a recent upgrade to Bookworm 12.4 on the i5 laptop used for testing stuff that may break important machines. I did the update a few days back and failed to reboot and test it at the time. I did the update, finished doing other work and shut it down.

I booted it this morning and it took me a while to spot it hadn't connected to the Wifi here. Looking there were only Ethernet connections and Bluetooth PAN connections. I had to dig through dmesg to find the line complaining about enable_ini=N was breaking iwlwifi firmware loading. Sure I had an iwlwifi.conf file containing "options iwlwifi enable_ini=N" which was not causing a problem till the latest upgrade. It was needed in the past... I never put it there, something else did during install. The fix was to remove the .conf and Wifi came up as normal on the next boot.

I'm not sure who's at fault here... if something created the file when installing / updating iwlwifi drivers in the past then changing the iwlwifi driver should have at least warned about the file on the latest update. Perhaps it did and I ignored it. But Debian updates just seem to be a little iffy recently which I don't remember from the past. There again I'm a Debian newbie only using it since 2002.

As I said earlier in this thread I have two Pi 4s runnning as follows:-

Debian GNU/Linux 12 (bookworm) - Kernel: 6.1.21-v8+ aarch64

No problems with either.

Same here, Tim.

With Linux itself I think driver problems are the only issue I've had too (although a broken Ethernet driver on a headless system can be quite inconvenient), but the trouble usually comes with the application software that gets updated at the same time. Often new bugs are introduced that can be deal breakers, or even intentional changes to behaviour, features, or performance.

I always do a full backup before a major update, but with things that boot from SD cards like the RPis it's easy to clone the card and do the upgrade on one card while keeping the other in use until I've got all the issues on the new installation ironed out (or given up and switched distro entirely).

I do updates immediately after a regular backup. :-)

Let's face it, s*it happens. It's best to be ready just in case. Usually I find that Linux updates go slick as a whistle. But there have also been times when things have gone so wrong that it was faster to reformat the root partition, install the new release from scratch, and restore my backup. That's much less frustrating than losing everything.

It's a very good idea to do one before updating, as it involves an awful lot of writing to the SD card, and if it's getting close to its wear level limits, this could push it over into failure.

---druck

I notice they explain how to turn off phased updates so you always get the new potentially breaking packages, but I must have missed the bit on how to set it up so you never get randomly chosen to install these packages.

---druck

CTRL+C or reboot, or interrupt the power supply

often the system can be repaired easily when still running.

well depends on the situation, but it was about the kernel that did not install if I understood correctly

I use Borg since couple of years. I used it once to completely restore a firewall that lost it's disk and couple of times to extract files.

But a dd to an external drive or SD card is also easily doable. The need to do backup is proportional to the value of the system (the effort to configure it). I recently bought a couple of USB sticks 32-64GB for < $10,- each and few SD cards even cheaper. And they are good quality brands. I have one USB that I use as emergency tool and 2-3 SDs for experimenting and quick fix backup. This is where I use Borg to completely restore a system.

In any case there are so many ways to take precautions and it is even recommended in any documentation. Why bother everybody with this? But I do not mean to insult you. Just pick up some backup strategy that suits you best and look forward to do better next time.

I was responding to a comment that macOS upgrades were sub-optimal, not talking about Pi upgrades.

"Mac-OS" is, underneath, BSD. As such it gains, or loses, from the same issues as mainstream Linux/Unix insofar as 'packages/upgrades' go.

ON THE WHOLE I've not suffered much from PI 'upgrades'. They mostly follow the Debian lead. Yes, "held back" IS annoying ... but then we are also talking an OS in constant evolution (devolution maybe considering 'Worm') so SOME attention to keeping older apps running MUST be considered and 'held back' helps with this.

Linux/BSD always suffers from the "version curse". SO many writers tie their apps to VERY specific versions of other apps/code/drivers/etc and will REFUSE to work even with the slightest change of a library version (even though said libraries are almost always super-sets and WOULD support the same old stuff).

This is ONE area where Winders is actually BETTER. You can still run relatively ancient apps Without Complaint (esp if you have a pre-8/16 ban chip).

Not really MacOS is the Mach kernel, a POSIX userland derived mostly from FreeBSD, a proprietary GUI and package system.

There is a lot of variety among package systems in the unix world. They are not all equal.

Some package systems such as MacOS and FreeBSD use a central build system that ensures consistency across the entire package set. Others take contributed builds that do not.

Some.

I follow the technical press. The occurrence of updates breaking machines is common with Windows, and my experience with Apple was less than encouraging.

I think if you stay on the One True Apple path then things are probably OK, just don't install any third party apps....

Well you need to just ask. I get them from whatever is the default PIOS repository.

Coriolanus:/etc/apt$ more sources.list

deb

-free-firmware

And I downloaded my installations from the official PIOS site.

was the one that kernel panicked (twice) on boot.

But the one I had used before

Installed perfectly again.

It may all be something to do with this. But you are in a better position to judge that than I.

I believe you are correct in this, I have never seen any issues when following the OTAP but third party stuff is only tolerated not supported and it shows.

Which third party apps are you referring to? I've not had any obvious problems, not even for apps I've written myself. Apart from utilities, the only Apple app I use is Pages.

Well lets try to keep this discussion on-topic.

---druck

They prettied it up Real Nice ... but it's still BSD underneath.

There are rumors that Winders is headed in the same direction because what-is has become just a total Gordian Knot and they can't maintain it or predict interactions. It's why there are a bazillion security flaws they can never seem to deal with.

Yea ... but "contributed" isn't necessarily the issue. It's "dependencies". They are handled rather badly by Linux and also by BSD to a fair extent. Part of the problem is the programmers - they link their code to VERY VERY specific versions of libs, alas OTHER ones also do so - and their needs/requirements are not going to be the same all the time. If you don't have lib-XYZ version 8.33.04 then they freak. The Unix universe IS a bit more boring ... so fewer problems ... but still ....

The sad bit is that most of those libs are super-sets, still support all the old params, just add some new ones. They COULD be used as-is ... IF the apps/update system was a bit more savvy. I've noted the rise in apps now distributed as ".run" images - all the needed code fully included in the executable. They're bigger - but they work no matter what. No compile/link BS.

Any links to confirm that ?

How do you do that in practice ? When I link with say PostgreSQL's libpq which is the native lib for accessing the database as a client, I add '-lpq' to the link command.

That is it. How do I tie it to a specific version of the lib?

As with all the best options, I can't find it documented in the GCC manual, but I think it's something like "-l:libxyz.so.1.2.3" to specify an explicit shared object file to link against.

Ah OK, it's mentioned in the ld(1) man page, but not in the GCC manual. But gcc will also pass it through to ld, I think.

The complaint probably wasn't really about that though, rather about new versions of libraries changing their ABI and thereby forcing users to match library versions to the program they want to use. Really it's the fault of the library developers more than the application developers, although it might sometimes be fair to blame the latter for choosing to use unstable libraries in the first place. It's hardly a rare problem though, with OpenSSL being a prime example.

Also the Debian package manager can be unnecessarily picky about library versions sometimes, which I think is the trouble that a previous incarnation of 56g.1183 complained about at length once before.