Bookworm: Pi 4B

Last night in an idle moment I decided to perform a routine upgrade.
This involved the kernel.

Unfortunately after ten minutes the upgrade had not installed and after
terminating it the whole machine would no longer boot.

I downloaded the latest image of Raspios, and that booted, but the
kernel panicked halfway through.

I went back to the original image, installed that and it finally booted
again.

When I went to upgrade, a lot of packages were 'held back'. I guess
someone discovered the upgrade was a bricker.

Bastards. I was up all night rebuilding that Pi..

--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels

The Natural Philosopher <tnp@invalid.invalid> wrote:
> Bookworm: Pi 4B
>
> Last night in an idle moment I decided to perform a routine upgrade.
> This involved the kernel.
>
> Unfortunately after ten minutes the upgrade had not installed and after
> terminating it the whole machine would no longer boot.
>
> I downloaded the latest image of Raspios, and that booted, but the
> kernel panicked halfway through.
>
> I went back to the original image, installed that and it finally booted
> again.
>
> When I went to upgrade, a lot of packages were 'held back'. I guess
> someone discovered the upgrade was a bricker.
>
> Bastards. I was up all night rebuilding that Pi..
>
I'm running Bookworm on two Pi4s without any issues.

--
Chris Green
·

On 19/12/2023 13:35, Chris Green wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Bookworm: Pi 4B
>>
>> Last night in an idle moment I decided to perform a routine upgrade.
>> This involved the kernel.
>>
>> Unfortunately after ten minutes the upgrade had not installed and after
>> terminating it the whole machine would no longer boot.
>>
>> I downloaded the latest image of Raspios, and that booted, but the
>> kernel panicked halfway through.
>>
>> I went back to the original image, installed that and it finally booted
>> again.
>>
>> When I went to upgrade, a lot of packages were 'held back'. I guess
>> someone discovered the upgrade was a bricker.
>>
>> Bastards. I was up all night rebuilding that Pi..
>>
> 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

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

On 19/12/2023 14:12, The Natural Philosopher wrote:
> On 19/12/2023 13:35, Chris Green wrote:
>> The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> Bookworm: Pi 4B
>>>
>>> Last night in an idle moment I decided to perform a routine upgrade.
>>> This involved the kernel.
>>>
>>> Unfortunately after ten minutes the upgrade had not installed and after
>>> terminating it the whole machine would no longer boot.
>>>
>>> I downloaded the latest image of Raspios, and that booted, but the
>>> kernel panicked halfway through.
>>>
>>> I went back to the original image, installed that and it finally booted
>>> again.
>>>
>>> When I went to upgrade, a lot of packages were 'held back'. I guess
>>> someone discovered the upgrade was a bricker.
>>>
>>> Bastards. I was up all night rebuilding that Pi..
>>>
>> 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.
--
Cheers,
David
Web: https://www.satsignal.eu

On 19/12/2023 15:30, David Taylor wrote:
> 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

The Natural Philosopher <tnp@invalid.invalid> writes:
> Bookworm: Pi 4B
>
> Last night in an idle moment I decided to perform a routine
> upgrade. This involved the kernel.
>
> Unfortunately after ten minutes the upgrade had not installed and
> after terminating it the whole machine would no longer boot.
>
> I downloaded the latest image of Raspios, and that booted, but the
> kernel panicked halfway through.
>
> I went back to the original image, installed that and it finally
> booted again.
>
> When I went to upgrade, a lot of packages were 'held back'. I guess
> someone discovered the upgrade was a bricker.

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.

--
https://www.greenend.org.uk/rjk/

On 19/12/2023 21:07, druck wrote:
> 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

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!

--
Cheers,
David
Web: https://www.satsignal.eu

On 19/12/2023 23:29, Richard Kettlewell wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>> Bookworm: Pi 4B
>>
>> Last night in an idle moment I decided to perform a routine
>> upgrade. This involved the kernel.
>>
>> Unfortunately after ten minutes the upgrade had not installed and
>> after terminating it the whole machine would no longer boot.
>>
>> I downloaded the latest image of Raspios, and that booted, but the
>> kernel panicked halfway through.
>>
>> I went back to the original image, installed that and it finally
>> booted again.
>>
>> When I went to upgrade, a lot of packages were 'held back'. I guess
>> someone discovered the upgrade was a bricker.
>
> 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.
>
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.

--
“There are two ways to be fooled. One is to believe what isn’t true; the
other is to refuse to believe what is true.”

—Soren Kierkegaard

The Natural Philosopher wrote:

> But with induction, one never knows the truth. It is always speculation.

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.

The Natural Philosopher wrote:

> 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.

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.

On 20/12/2023 08:55, Deloptes wrote:
> The Natural Philosopher wrote:
>
>> But with induction, one never knows the truth. It is always speculation.
>
> No speculation in following
>
> 1. you never break an upgrade (problems preprogrammed)
??? Sorry...English pliz!

> 2. when you break an upgrade you never reboot (even more problems
> preprogrammed)
>
A computer that is bricked is less use than one that cannot be powered
on unless its has a reinstalled OS.

> you should have solved the issues beforehand and then reboot
>
How?

> 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.
>

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.

--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent
renewable energy.

On 20/12/2023 08:58, Deloptes wrote:
> The Natural Philosopher wrote:
>
>> 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.
>
> 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.
>
>
I did update / upgrade. Just a normal everyday upgrade.

--
For in reason, all government without the consent of the governed is the
very definition of slavery.

Jonathan Swift

On 20 Dec 2023 at 08:55:14 GMT, "Deloptes" <deloptes@gmail.com> wrote:

> you should have solved the issues beforehand and then reboot

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

> I am surprised you expected any other outcome.

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

--
Tim

On 20/12/2023 12:30, TimS wrote:
> On 20 Dec 2023 at 08:55:14 GMT, "Deloptes" <deloptes@gmail.com> wrote:
>
>> you should have solved the issues beforehand and then reboot
>
> There were no problems to be solved. Later, there were. But it was too late by
> then.
>
>> I am surprised you expected any other outcome.
>
> 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.

--
"Corbyn talks about equality, justice, opportunity, health care, peace,
community, compassion, investment, security, housing...."
"What kind of person is not interested in those things?"

"Jeremy Corbyn?"

Richard Kettlewell <invalid@invalid.invalid> wrote:
> 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.

Ubuntu is using 'held back' for phased updates:
https://ubuntu.com/server/docs/about-apt-upgrade-and-phased-updates

Are Debian or Raspberry Pi OS also using that mechanism?

Theo

On 20 Dec 2023 at 13:00:23 GMT, "The Natural Philosopher"
<tnp@invalid.invalid> wrote:

> On 20/12/2023 12:30, TimS wrote:
>> On 20 Dec 2023 at 08:55:14 GMT, "Deloptes" <deloptes@gmail.com> wrote:
>>
>>> you should have solved the issues beforehand and then reboot
>>
>> There were no problems to be solved. Later, there were. But it was too late by
>> then.
>>
>>> I am surprised you expected any other outcome.
>>
>> 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.

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.

--
Tim

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

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

Do you have experience with this type of material?

--
Jean-Pierre Kuypers

Theo <theom+news@chiark.greenend.org.uk> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> 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.
>
> Ubuntu is using 'held back' for phased updates:
> https://ubuntu.com/server/docs/about-apt-upgrade-and-phased-updates
>
> Are Debian or Raspberry Pi OS also using that mechanism?

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.

--
https://www.greenend.org.uk/rjk/

On 20/12/2023 13:00, The Natural Philosopher wrote:
> Linux is generally really really good about upgrades. Way better than
> Apple or Microsoft.

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.
--
Cheers,
David
Web: https://www.satsignal.eu

On 20/12/2023 13:46, TimS wrote:
> 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.

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.
--
Cheers,
David
Web: https://www.satsignal.eu

On 20 Dec 2023 at 15:11:23 GMT, "David Taylor"
<david-taylor@blueyonder.co.uk.invalid> wrote:

> On 20/12/2023 13:46, TimS wrote:
>> 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.
>
> 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.

I didn't say I didn't back up regularly. I said I didn't do a special backup
just because I'm updating the machine.

--
Tim

On 19/12/2023 12:52, The Natural Philosopher wrote:
> Bookworm: Pi 4B
>
> Last night in an idle moment I decided to perform a routine upgrade.
> This involved the kernel.
>
> Unfortunately after ten minutes the upgrade had not installed and after
> terminating it the whole machine would no longer boot.
>
> I downloaded the latest image of Raspios, and that booted, but the
> kernel panicked halfway through.
>
> I went back to the original image, installed that and it finally booted
> again.
>
> When I went to upgrade, a lot of packages were 'held back'. I guess
> someone discovered the upgrade was a bricker.
>
> Bastards. I was up all night rebuilding that Pi..
>

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 shitty 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.

mm0fmf <none@invalid.com> wrote:
> On 19/12/2023 12:52, The Natural Philosopher wrote:
> > Bookworm: Pi 4B
> >
> > Last night in an idle moment I decided to perform a routine upgrade.
> > This involved the kernel.
> >
> > Unfortunately after ten minutes the upgrade had not installed and after
> > terminating it the whole machine would no longer boot.
> >
> > I downloaded the latest image of Raspios, and that booted, but the
> > kernel panicked halfway through.
> >
> > I went back to the original image, installed that and it finally booted
> > again.
> >
> > When I went to upgrade, a lot of packages were 'held back'. I guess
> > someone discovered the upgrade was a bricker.
> >
> > Bastards. I was up all night rebuilding that Pi..
> >
>
> 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+
>
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.

--
Chris Green
·

On 20/12/2023 16:08, TimS wrote:
> I didn't say I didn't back up regularly. I said I didn't do a special backup
> just because I'm updating the machine.

Same here, Tim.
--
Cheers,
David
Web: https://www.satsignal.eu

The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 20/12/2023 12:30, TimS wrote:
>>
>> 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..

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).

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |