Moving Linux Kernel to 6.1

[PhilE]

That change happens when we promote the current kernel to stable, at which point we stop rebasing.

[jimbojones]

If I test out 6.1 by using

Code: Select all

sudo rpi-update next

when I'm currently on the standard Bullseye RaspberryPi 64-bit OS, using the latest stable kernel installed via apt, is there a way to easily switch back to stable? If you switch back, are all future kernel updates handled by apt again?

[RonR]

If I test out 6.1 by using

Code: Select all

sudo rpi-update next

when I'm currently on the standard Bullseye RaspberryPi 64-bit OS, using the latest stable kernel installed via apt, is there a way to easily switch back to stable? If you switch back, are all future kernel updates handled by apt again?

The following will undo the rpi-update and put you be back on the latest/current release:

Code: Select all

apt update
apt install --reinstall libraspberrypi0 libraspberrypi-{bin,dev,doc} raspberrypi-bootloader raspberrypi-kernel

[redvli]

If I test out 6.1 by using

Code: Select all

sudo rpi-update next

when I'm currently on the standard Bullseye RaspberryPi 64-bit OS, using the latest stable kernel installed via apt, is there a way to easily switch back to stable? If you switch back, are all future kernel updates handled by apt again?

A folder /boot.bak is created with the apt provided kernel.
So in case the 'test' leaves your Pi unbootable, copying back all files in /boot.bak to the boot partition is a way to get it up and running again. The rpi-update script doesn't handle initramfs or some other customization in config.txt for example, so make sure you know how to make a Pi bootable from backup(s).
And 'next' is not needed now that 6.1 is LTS, but double check that, I can't/don't use the rpi-update script.

[bensimmo]

it says on the first page next is no longer needed.

[dom]

it says on the first page next is no longer needed.

Indeed.
Just run "sudo rpi-update" for the latest updates. The next branch is dormant and will currently be out of date.

[dom]

The latest update changes a couple of defaults that may be significant:
1. Pi4 now defaults to preferring a 64-bit kernel when arm_64bit is not specified. You can use arm_64bit=0 to request the 32-bit kernel.
2. The default cma region on a Pi4 with 64-bit kernel is now 512M (up from 256M on 1GB Pi4 or 384M on 2-8GB Pi4).

The reason for this is the previous cma size can be limiting with 4k video decode and some camera use cases.
Especially when used with a (possibly dual) 4K desktop.

But setting cma too high with a 32-bit kernel causes issues with bounce buffers and the vmalloc heap that also needs to be in the bottom 1GB.

In general a switch to 64-bit kernel should be unnoticed. It works fine with a 32-bit OS.
It should improve performance of some kernel driver code.

As usual, report here if there are any issues from this change.

[bensimmo]

Seems an update to this version broke on of my Pi
Pi4 - Jellyfin ok
Pi3B+ - Buster OctoPi - ok


Reporting in case anyone else sees the same.

WeatherHat - 64bit RPiOS Bullseye* (all up to date as of today)
moved to 6.1.16-v8+ from ~6.1.14
3A+ & 3B
- "arm_64bit=1" boots but networking has vanished on 3A+ and then to fix on a 3B. WiFi just gone.[ both 3A+ & 3B
- remove arm_64 just dies during boot with errors on the screen I assuming it needs that line on 64bit OS, I forget?
Ethernet working on 3B so going to go back and try again tomorrow to confirm.


EDIT cleaned this up.
(moved back to 5.15 fine, ready for testing again tommorow)

[dom]

- "arm_64bit=1" boots but networking has vanished on 3A+ and then to fix on a 3B. WiFi just gone.[ both 3A+ & 3B
- remove arm_64 just dies during boot with errors on the screen I assuming it needs that line on 64bit OS, I forget?
Ethernet working on 3B so going to go back and try again tomorrow to confirm.

Yes, a 64-bit OS requires a 64-bit kernel.
A 32-bit OS can use a 32-bit or 64-bit kernel.

There appears to be an upstream wifi regrssion on 6.1.16
See: https://github.com/raspberrypi/linux/issues/5379

[PhilE]

To add to Dom's answer, if both the 32-bit and 64-bit kernel are present and arm_64bit is not set either way then a Pi 3 of any flavour will still prefer the 32-bit kernel; Pi 4s now prefer the 64-bit.

[DougieLawson]

I've got a bunch of RPi 1, 2 and 3. I don't have a RPi 4.

Lots of those are back on 6.1.14 because 6.1.16 did not boot correctly.

• B+ apollo 6.1.16+ #1636 Fri Mar 10 18:33:56 GMT 2023
• 3B challenger 6.1.14-v8+ #1633 SMP PREEMPT Thu Mar 2 11:09:44 GMT 2023
• 3A discovery 6.1.14-v8+ #1633 SMP PREEMPT Thu Mar 2 11:09:44 GMT 2023
• 2 eagle 6.1.14-v7+ #1633 SMP Thu Mar 2 11:02:03 GMT 2023
• 3B endeavour 6.1.14-v8+ #1633 SMP PREEMPT Thu Mar 2 11:09:44 GMT 2023
• Z falcon 6.1.14+ #1633 Thu Mar 2 10:58:45 GMT 2023
• 3B+ hitchhiker 6.1.16-v7+ #1636 SMP Fri Mar 10 18:37:13 GMT 2023
• ZW mercury 6.1.14+ #1633 Thu Mar 2 10:58:45 GMT 2023
• B odyssey 6.1.16+ #1636 Fri Mar 10 18:33:56 GMT 2023
• B pioneer 6.1.16+ #1636 Fri Mar 10 18:33:56 GMT 2023
• B saturn 6.1.16+ #1636 Fri Mar 10 18:33:56 GMT 2023
• 3B tranquility 6.1.14-v8+ #1633 SMP PREEMPT Thu Mar 2 11:09:44 GMT 2023
• 3A ulysses 6.1.14-v8+ #1633 SMP PREEMPT Thu Mar 2 11:09:44 GMT 2023
• A viking 6.1.16+ #1636 Fri Mar 10 18:33:56 GMT 2023

[RonR]

I've got a bunch of RPi 1, 2 and 3. I don't have a RPi 4.

Lots of those are back on 6.1.14 because 6.1.16 did not boot correctly.

Dougie,

I'm curious what you observed when they "did not boot correctly"?

FWIW, I just spun up a Raspberry Pi 2B (v1.1) on 5.15.84 and then updated it 6.1.16 (cross-compiled in-house, not via rpi-update) and it appears to boot and run as expected.

Linux raspberrypi 6.1.16-v7+ #1 SMP Sun Mar 12 17:42:44 CDT 2023 armv7l GNU/Linux

[DougieLawson]

They just sat there with the power LED (where applicable) lit.

I run rpi-update with WANT_32BIT=1 or WANT_64BIT=1 as appropriate. Most of my machines that can boot from a USB do boot from a USB.

[RonR]

They just sat there with the power LED (where applicable) lit.

I run rpi-update with WANT_32BIT=1 or WANT_64BIT=1 as appropriate. Most of my machines that can boot from a USB do boot from a USB.

Everything is normal here.

I assume your Raspberry Pi 2B is booting from an SD card? I can try it on a USB drive (using hybrid) if that's what you're running.

It appears rpi-update may be serving up a bad kernel and/or modules.

Edit to add:

No problems encountered on a Raspberry Pi 3B+.

No problems encountered on a Raspberry Pi 1B, whether booting from an SD card or a USB drive (using hybrid).

[rpdom]

They just sat there with the power LED (where applicable) lit.

I run rpi-update with WANT_32BIT=1 or WANT_64BIT=1 as appropriate. Most of my machines that can boot from a USB do boot from a USB.

Just tested on a 3A+ that has been running 64-bit bookworm for a few weeks on 6.1.14. Upgraded to 6.1.16 and it boots fine, but wifi doesn't work (presumably the regression dom mentioned).

I'm reverting to 6.1.14 for now or I might just add a wired adaptor. I'll be happy to test again when the wifi bug has been fixed.

[aBUGSworstnightmare]

A 3B updated to 6.1.16 lost Wifi connection
Also just updated a CM4 to 6.1.16. On that DUT the onboard Wifi can't connect to my router (configured for using external antenna) but a RT5572 Wireless Adapter connects without issues.

[PhilE]

That rpi-update has broken two things (that we know of):
1) Automatic setting of arm_64bit=1 when a Pi with a BCM2837 boots from an image where only kernel8.img is present.
2) WiFi connectivity, as a result of the upstream change previously discussed.

There's a firmware fix in the pipeline for 1), and a PR against rpi-6.1.y to merge an upstream patch that should resolve 2).

[dom]

That rpi-update has broken two things (that we know of):

rpi-update contains fixes for the two identified issues.

[rpdom]

rpi-update contains fixes for the two identified issues.

Thanks dom, that fixed the wifi problem for me. I hadn't encountered the other one.

[DougieLawson]

That rpi-update has broken two things (that we know of):

rpi-update contains fixes for the two identified issues.

Thank you both. I've got 6.1.19 running on all of my Raspberries now.

[bjlockie]

I was running 6.1.x but I rebooted and it is 5.15.84 again.
I've rebooted before and it stayed 6.1.x.
I need 6x for my mt7921au wifi to work.
I'm surprised 5.15 still works.
Is there something like grub to select the kernel?
I have to find my mt7612 USB to get wifi to work with the old kernel.
I boot from an nvme USB drive.

[6by9]

I was running 6.1.x but I rebooted and it is 5.15.84 again.
I need 6x for my mt7921au wifi to work.
I'm surprised 5.15 still works.
Is there something like grub to select the kernel?
I have to find my mt7612 USB to get wifi to work with the old kernel.
I boot from an nvme USB drive.

Did you run "apt update" "apt dist-upgrade"?
Apt and rpi-update have no co-ordination, therefore whichever last had an update will be applied.

[bjlockie]

Did you run "apt update" "apt dist-upgrade"?
Apt and rpi-update have no co-ordination, therefore whichever last had an update will be applied.

Yes I did.
Is there a way to prevent this from happening?

[6by9]

Did you run "apt update" "apt dist-upgrade"?
Apt and rpi-update have no co-ordination, therefore whichever last had an update will be applied.

Yes I did.
Is there a way to prevent this from happening?

Code: Select all

sudo apt-mark hold libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0
sudo apt-mark hold raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers

[dom]

The 6.1 kernel is now available from apt. Thanks for testing.