Arrggh! beware the upgrade...

I'm running Bookworm on two Pi4s without any issues.

The point is that about 4 hrs after all this happened the upgrade on the new install held back the kernel....upgrade So I just got caught. Between a bad upgrade and the powers that be blocking it.

And the latest bookworm image didn't boot either.

So something rotten in the state of Denmark, to be sure. So take care. I am sure it will all be fixed soon

I hope they fixed the nasty bug of making the Wi-Fi have power-save enabled by default. Kills the otherwise excellent time-keeping.

I don't know about the latest one, but this is staying on all my Pis until I find out otherwise. Turning power saving off greatly reduces the latency on all my monitoring tasks.

Create /etc/udev/rules.d/71-wifi_power_save_off.rules containing the following single line:-

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="brcmfmac", KERNEL=="wlan0", RUN="/sbin/iw dev wlan0 set power_save off"

---druck

Packages being _held_ back means the local administrator has blocked their upgrade with ‘apt-mark hold’ (or equivalent).

Packages being _kept_ back means that a package can’t be upgraded due to a dependency issue (e.g. because the administrator only asked for a partial upgrade, but the new version of the package depends on a package that isn’t installed).

Neither reflects any kind of upstream decision to block upgrades.

Yes, it does save power, and reduces the CPU load and temperature, but the penalty is too great. Thanks for posting an alternative method to using Network Manager. I've made a note!

I dont think I said that it did, just that the held back packages were the ones on the NEW (rolled back) installation that had borlkd the previous installation. Namely a new kernel.

And that the NEW downoad of Raspios kernel panicked during boot, and wouldnt boot.

So the course of events were

- kernel upgrade hangs, machine now unbootable

- installation of *latest* downloaded image fails, with kernel panic

- installation of *previous* image succeeds, but upgrading it shows a kernel package 'held back'

The inference being that there was a bad kernel image in the pipeline.

But with induction, one never knows the truth. It is always speculation. At best we can say its reasonable.

No speculation in following

1. you never break an upgrade (problems preprogrammed)
2. when you break an upgrade you never reboot (even more problems preprogrammed)

you should have solved the issues beforehand and then reboot

I am surprised you expected any other outcome. Better think of rescue strategy to avoid such outcomes - i.e. backup/restore or clone to another SD and try there first. I do it with borg and for the PI it is diskless anyway.

Not sure if you are aware of the upgrade process Usually upgrade should be done update, upgrade followed by dist-upgrade or just update + full-upgrade. This way the base packets get upgraded too.

??? Sorry...English pliz!

A computer that is bricked is less use than one that cannot be powered on unless its has a reinstalled OS.

How?

My rescue strategy for that unit was what I followed. There was nothing I couldn't afford to lose. It is at this point an experimental setup.

I did update / upgrade. Just a normal everyday upgrade.

There were no problems to be solved. Later, there were. But it was too late by then.

You mean, whenever an update/upgrade is done, you expect the computer to be broken afterwards?

LOL! The reason why I didnt is because it is only the second time its ever happened with linux, and the first time wasn't critical. The wifi stopped working, that's all. Simply went back to previous kernel..

Linux is generally really really good about upgrades. Way better than Apple or Microsoft.

Ubuntu is using 'held back' for phased updates:

Theo

Microsoft, perhaps, given the posts I've seen here about needing to take a backup first or of Windows erasing the disk first before doing the upgrade.

Apple stuff, by contrast, just works. I've never bothered doing a backup before installing an update, and never had a problem. Further, everything that was there before is there afterwards, including all users, system settings and even any micro-tweaks I might have done. If I've configured an apache startup file, that remains untouched.

When SWMBO's intel Mini was replaced with a new ARM M1 model, all I had to do was to tell the new Mini to migrate everything from the old one. Which it did and she sat down at the new one and started work. All her old apps worked as before.

The only exception is if some major feature (such as support for 32-bit apps) is removed, which happened when I installed a newer version of macOS this year, so I went from being 5 major versions behind, to 4. I was in any case ready for that.

In article (Dans l'article) <uluoh7$ibt0$ snipped-for-privacy@dont-email.me, The Natural Philosopher snipped-for-privacy@invalid.invalid wrote (écrivait) :

Do you have experience with this type of material?

Oh, that’s new. Confusing that they’ve used the same diagnostic. They could in principle use it, but none of the packages files I can see contain the header for it which suggests they aren’t. But I don’t know where TNP is getting his packages from.

Perhaps that's true in general, but not in my experience. I often find that programs need to be recompiled or (with the RPi) the serial port interface changes.

With Apple (iPad) it seems that support for OpenGL is being dropped, which means that a number of programs I have will cease to work Emerald and Sequoia). With Windows I'm pleased to find that backwards compatibility is much better

- software I wrote over 20 years ago for Windows XP still runs nicely.

As usual, you hear the posts about the problems, nothing from the very many users for whom updates are without issue. Backup up regularly is good practice with any OS.