Topics

RPi kernel upgrade problem


Basil Gunn
 

Until further notice please do not upgrade the kernel on your RPi.

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems

Run this to get your current kernel version:
uname -r

The following commands will upgrade your kernel.
Do NOT use them for a while:

apt-get dist-upgrade
apt full-upgrade

/Basil N7NIX


Thomas KF7RSF
 

Basil,

Will the command "sudo rpi-upgrade "commitID"" revert the kernel successfully if correct Commit ID hex value from GitHub is used for the 4.19.118 kernel release?
Thomas


Basil Gunn
 

Will the command "sudo rpi-upgrade "commitID"" revert the kernel
successfully if correct Commit ID hex value from GitHub is used for
the 4.19.118 kernel release?
I don't think so.

When I read the documentation for rpi-update
(https://github.com/Hexxeh/rpi-update) it distinguishes between kernel &
RPi firmware.

To upgrade/downgrade to a specific firmware revision, specify its Git
hash
I think that is only for RPi firmware and not the kernel and kernel
modules but I could be wrong.

I have a script somewhere that puts whatever kernel in the right
location. Files in /boot are not the only place that need updating and
it is not entirely safe to do that.

/Basil n7nix


Thomas KF7RSF
 

I had nothing to lose; facing re-burning and re-configuring the correct image, so I gave it a shot. I’ve previously used “rpi-upgrade commitID’ to both advance and to roll-back kernels in raspbian distributions.

So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2” with the hex string for the 4.19.118 kernel coming from the GitHub raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct kernel. All my prior configuration is intact, and the few apps already configured seem to run correctly.

I’ll let you know if I find anything broken.

Thomas Noel
KF7RSF

On Jul 29, 2020, at 5:42 PM, Basil Gunn <@basil860> wrote:


Will the command "sudo rpi-upgrade "commitID"" revert the kernel
successfully if correct Commit ID hex value from GitHub is used for
the 4.19.118 kernel release?
I don't think so.

When I read the documentation for rpi-update
(https://github.com/Hexxeh/rpi-update) it distinguishes between kernel &
RPi firmware.

To upgrade/downgrade to a specific firmware revision, specify its Git
hash
I think that is only for RPi firmware and not the kernel and kernel
modules but I could be wrong.

I have a script somewhere that puts whatever kernel in the right
location. Files in /boot are not the only place that need updating and
it is not entirely safe to do that.

/Basil n7nix



Basil Gunn
 

So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2”
with the hex string for the 4.19.118 kernel coming from the GitHub
raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct
kernel. All my prior configuration is intact, and the few apps already
configured seem to run correctly.
Thanks for that Thomas. Very good to know!

The following is from Anna NH6Z condensed from a couple of emails:

Removal of ADS1015 driver explained here:
https://www.spinics.net/lists/linux-hwmon/msg06097.html

The ads1015 driver name has changed to “ti_ads1015” and it’s now
loading “industrialio” and not “hwmon”. The upstream Linux guys
deprecated and removed the ads1015 driver from the hwmon subsystem as
being “redundant.” That means that the device tree is matching the
IIO (Industrial IO) driver now, and that’s getting loaded.

That means that the hwmon subsystem that lm-sensors uses to probe no
longer sees the device because there’s no driver.

There is a bridge from the iio subsystem to the hwmon subsystem (the
iio-hwmon driver), but it needs DT (Device Tree) support to be
instantiated.

The iio-hwmon driver is not shipped by default with Raspbian, so it’s
not fixable with merely a DT change. I have to get a fresh kernel and
modules compiled to test it out. When I can get it to work, I’ll PR the
whole thing and add the iio-hwmon driver to the bcm*_defconfig files for
RPi. That’ll get it in Raspbian for the next kernel release.

Dunno when I’m going to get to that, but I’ll push it out when I can.


Thomas KF7RSF via groups.io <tnoel=mac.com@groups.io> writes:

I had nothing to lose; facing re-burning and re-configuring the
correct image, so I gave it a shot. I’ve previously used “rpi-upgrade
commitID’ to both advance and to roll-back kernels in raspbian
distributions.

So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2”
with the hex string for the 4.19.118 kernel coming from the GitHub
raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct
kernel. All my prior configuration is intact, and the few apps already
configured seem to run correctly.

I’ll let you know if I find anything broken.

Thomas Noel
KF7RSF

On Jul 29, 2020, at 5:42 PM, Basil Gunn <@basil860> wrote:


Will the command "sudo rpi-upgrade "commitID"" revert the kernel
successfully if correct Commit ID hex value from GitHub is used for
the 4.19.118 kernel release?
I don't think so.

When I read the documentation for rpi-update
(https://github.com/Hexxeh/rpi-update) it distinguishes between kernel &
RPi firmware.

To upgrade/downgrade to a specific firmware revision, specify its Git
hash
I think that is only for RPi firmware and not the kernel and kernel
modules but I could be wrong.

I have a script somewhere that puts whatever kernel in the right
location. Files in /boot are not the only place that need updating and
it is not entirely safe to do that.

/Basil n7nix


Thomas KF7RSF
 

Nice to find what broke in new kernel. I can live with 4.19.118 until fixed.
Tom

On Jul 29, 2020, at 22:13, Basil Gunn <@basil860> wrote:


So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2”
with the hex string for the 4.19.118 kernel coming from the GitHub
raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct
kernel. All my prior configuration is intact, and the few apps already
configured seem to run correctly.
Thanks for that Thomas. Very good to know!

The following is from Anna NH6Z condensed from a couple of emails:

Removal of ADS1015 driver explained here:
https://www.spinics.net/lists/linux-hwmon/msg06097.html

The ads1015 driver name has changed to “ti_ads1015” and it’s now
loading “industrialio” and not “hwmon”. The upstream Linux guys
deprecated and removed the ads1015 driver from the hwmon subsystem as
being “redundant.” That means that the device tree is matching the
IIO (Industrial IO) driver now, and that’s getting loaded.

That means that the hwmon subsystem that lm-sensors uses to probe no
longer sees the device because there’s no driver.

There is a bridge from the iio subsystem to the hwmon subsystem (the
iio-hwmon driver), but it needs DT (Device Tree) support to be
instantiated.

The iio-hwmon driver is not shipped by default with Raspbian, so it’s
not fixable with merely a DT change. I have to get a fresh kernel and
modules compiled to test it out. When I can get it to work, I’ll PR the
whole thing and add the iio-hwmon driver to the bcm*_defconfig files for
RPi. That’ll get it in Raspbian for the next kernel release.

Dunno when I’m going to get to that, but I’ll push it out when I can.


Thomas KF7RSF via groups.io <tnoel=mac.com@groups.io> writes:

I had nothing to lose; facing re-burning and re-configuring the
correct image, so I gave it a shot. I’ve previously used “rpi-upgrade
commitID’ to both advance and to roll-back kernels in raspbian
distributions.

So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2”
with the hex string for the 4.19.118 kernel coming from the GitHub
raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct
kernel. All my prior configuration is intact, and the few apps already
configured seem to run correctly.

I’ll let you know if I find anything broken.

Thomas Noel
KF7RSF

On Jul 29, 2020, at 5:42 PM, Basil Gunn <@basil860> wrote:

Will the command "sudo rpi-upgrade "commitID"" revert the kernel
successfully if correct Commit ID hex value from GitHub is used for
the 4.19.118 kernel release?
I don't think so.

When I read the documentation for rpi-update
(https://github.com/Hexxeh/rpi-update) it distinguishes between kernel &
RPi firmware.

To upgrade/downgrade to a specific firmware revision, specify its Git
hash
I think that is only for RPi firmware and not the kernel and kernel
modules but I could be wrong.

I have a script somewhere that puts whatever kernel in the right
location. Files in /boot are not the only place that need updating and
it is not entirely safe to do that.

/Basil n7nix


J P Watters <kc9kko@...>
 

Basil,

Maybe we should add to the “Getting Started” adding that command to prevent kernel updates on a Draws SD Card Image? ie 
sudo apt-mark hold linux-image-$(uname -r)
 
On the NWDigitalRadio Getting Started for DRAWS it shows running two commands the I think will get us in trouble since they will upgrade the kernel. (apt-get update and apt-get dist-upd
I think that running the command 
sudo apt-mark hold linux-image-$(uname -r)
 
before any other commands, would prevent the kernel from being upgraded while obtaining all the others. 
 
And to remove that “HOLD” run the command 
 
sudo apt-mark unhold linux-image-$(uname -r)
 
My process is to write a SD card with the NWDR16.zip image. 
Boot from that card. 
Before acknowledging any dialog box. ie the update that auto runs.
Execute from a terminal window ( open a terminal session )
      the command   sudo apt-mark hold linux-image-$(uname -r)
Exit the terminal session.
 
Then proceed with the auto run update that was triggered.
 
Maybe we should add to the “Getting Started” adding that command to prevent kernel updates on a Draws SD Card Image?
 
..jpw J P Watters
KC9KKO
Morris, IL
 
 
 
 

 

 

Initial Configuration

Initial Config Summary

  • First boot:
    • Verify that required drivers for the DRAWS codec are loaded
    • Follow 'Welcome to Raspberry Pi' piwiz screens.
    • Update the configuration scripts
  • Second boot: run script: app_config.sh core
  • Third boot: Set your ALSA config
  • For packet turn on Direwolf & AX.25

Check for required drivers first

  • First open a console and type:

    aplay -l
  • You should see a line in the output that looks something like this:

    card 0: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 []
  • If you do not see udrc enumerated do not continue

Initial Config Detail

  • If you are running with an attached monitor you should see the Raspbian 'Welcome to Raspberry Pi' piwiz splash screen
    • Follow the screens as you would on any other Raspbian install.
    • When prompted to restart the RPi please do so.
Update configurations scripts
cd
cd n7nix
git pull

sudo su
apt-get update
apt-get dist-upgrade
# revert back to normal user
exit
Configure core functionality
  • Whether you want direwolf for packet functionality or run HF apps with the draws HAT do the following:
cd
cd n7nix/config
# Become root
sudo su
./app_config.sh core
  • The above script sets up the following:

    • iptables
    • RPi login password
    • RPi host name
    • mail host name
    • time zone
    • current time via chrony
    • AX.25
    • direwolf
    • systemd
  •  
 
 

On Jul 29, 2020, at 2:53 PM, Basil Gunn <basil@...> wrote:


Until further notice please do not upgrade the kernel on your RPi.

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems

Run this to get your current kernel version:
uname -r

The following commands will upgrade your kernel.
Do NOT use them for a while:

apt-get dist-upgrade
apt full-upgrade

/Basil N7NIX


Basil Gunn
 

Thanks J P. I think this is a good idea.
I am going to do a couple of verifications then change the 'Getting
Started Wiki' update section.

J P Watters via groups.io <kc9kko=mac.com@groups.io> writes:

Basil,

Maybe we should add to the“Getting Started” adding that command to prevent kernel updates on a Draws SD Card Image? ie sudo apt-mark hold linux-image-$ ( uname -r )

*On the NWDigitalRadio Getting Started for DRAWS it shows running two commands the I think will get us in trouble since they will upgrade the kernel. (apt-get update and apt-get dist-upd*
*I think that running the command*
sudo apt-mark hold linux-image-$ ( uname -r )

before any other commands, would preventthe kernel from being upgraded whileobtaining all the others.

And to remove that“HOLD” run the command

sudo apt-mark unhold linux-image-$ ( uname -r )

M y process is to write a SD card withthe NWDR16.zip image.
Boot from that card.
Beforeacknowledging any dialog box. ie the update that auto runs.
Execute from a terminal window ( open a terminalsession )
the command sudo apt-mark hold linux-image-$ ( uname -r )
Exittheterminal session.

Then proceed withthe auto run updatethat was triggered.

Maybe we should add to the“Getting Started” adding that command to prevent kernel updates on a Draws SD Card Image?

..jpw J P Watters
KC9KKO
Morris, IL












Initial Configuration
---------------------

Initial Config Summary

* First boot:

* Verify that required drivers for the DRAWS codec are loaded
* Follow 'Welcome to Raspberry Pi' piwiz screens.
* Update the configuration scripts



* Second boot: run script: app_config.sh core
* Third boot: Set your ALSA config
* For packet turn on Direwolf & AX.25


Check for required drivers first

*

First open a console and type:

aplay - l
*

You should see a line in the output that looks something like this:

card 0 : udrc [ udrc ], device 0 : bcm2835 - i2s - tlv320aic32x4 - hifi
tlv320aic32x4 - hifi - 0 []
*

If you do not see udrc enumerated do not continue



* Until the UDRC/DRAWS drivers are loaded the configuration scripts will
not succeed.
* Run the showudrc.sh script and post the console output to the UDRC
groups.io forum ( https://nw-digital-radio.groups.io/g/udrc/topics )





Initial Config Detail

* If you are running with an attached monitor you should see the Raspbian
'Welcome to Raspberry Pi' piwiz splash screen

* Follow the screens as you would on any other Raspbian install.
* When prompted to restart the RPi please do so.





Update configurations scripts cd
cd n7nix
git pull

sudo su
apt - get update
apt - get dist - upgrade
# revert back to normal user
exit Configure core functionality

* Whether you want direwolf for packet functionality or run HF apps with
the draws HAT do the following:


cd
cd n7nix / config
# Become root
sudo su
./ app_config. sh core

*

The above script sets up the following:



* iptables
* RPi login password
* RPi host name
* mail host name
* time zone
* current time via chrony
* AX.25
* direwolf
* systemd



*




On Jul 29, 2020, at 2:53 PM, Basil Gunn < @basil860 > wrote:


Until further notice please do not upgrade the kernel on your RPi.

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems

Run this to get your current kernel version:
uname -r

The following commands will upgrade your kernel.
Do NOT use them for a while:

apt-get dist-upgrade
apt full-upgrade

/Basil N7NIX



Basil Gunn
 

Nice to find what broke in new kernel. I can live with 4.19.118 until
fixed.
Just to be clear this isn't the only thing in the 5.4.51 kernel that is
broken.
https://www.raspberrypi.org/forums/viewtopic.php?t=280771&p=1701156

Tom
On Jul 29, 2020, at 22:13, Basil Gunn <@basil860> wrote:


So, I ran "sudo rpi-upgrade e1050e94821a70b2e4c72b318d6c6c968552e9a2”
with the hex string for the 4.19.118 kernel coming from the GitHub
raspbian kernel repository.

Ran with no reported errors, rebooted and “uname -a” reporting correct
kernel. All my prior configuration is intact, and the few apps already
configured seem to run correctly.
Thanks for that Thomas. Very good to know!


Basil Gunn
 

To put a hold on upgrading a Raspberry Pi kernel.

# verify current kernel
uname -r

# Should be 4.19.118 or older.

# Put a hold on some kernel packages:
sudo su
apt-mark hold libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0
apt-mark hold raspberrypi-bootloader raspberrypi-kernel raspberrypi-kernel-headers

# Verify hold is working:
apt-mark showhold

# should see this in console output

libraspberrypi-bin
libraspberrypi-dev
libraspberrypi-doc
libraspberrypi0
raspberrypi-bootloader
raspberrypi-kernel
raspberrypi-kernel-headers

After the hold is in place you can upgrade other packages without
upgrading the kernel.

apt-get update
apt-get upgrade

Reference this link:
https://github.com/nwdigitalradio/n7nix/blob/master/docs/DRAWS_CONFIG.md#placing-a-hold-on-kernel-upgrade

Image nwdr16.img.xz has the kernel hold in place
http://nwdig.net/downloads/


Basil Gunn <@basil860> writes:

Nice to find what broke in new kernel. I can live with 4.19.118 until
fixed.
Just to be clear this isn't the only thing in the 5.4.51 kernel that is
broken.
https://www.raspberrypi.org/forums/viewtopic.php?t=280771&p=1701156

Tom


Basil Gunn
 

From Anna:

The necessary changes to the default kernel are included in PR #3773
(https://github.com/raspberrypi/linux/pull/3773) to the RPi folk. There
are no upstream changes required. You should start seeing this in
kernel releases soon.

There are necessary changes to the /etc/sensors.d/draws file to make
everything work.
When we confirm that a new kernel is working, a new NWDR image will be
released with a compatible /etc/sensors.d/draws file.

/Basil N7NIX


Basil Gunn <@basil860> writes:

Until further notice please do not upgrade the kernel on your RPi.

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems

Run this to get your current kernel version:
uname -r

The following commands will upgrade your kernel.
Do NOT use them for a while:

apt-get dist-upgrade
apt full-upgrade

/Basil N7NIX


Paul Noa
 

Basil,

I just received 3 new DRAWS hats and after building my image using Raspbian Buster on a BalenaFIN and probably the second or third time I had done a shutdown for routine purposes I got a stack dump twice in a row.
Stack Dump1.jpg

I will point out that I was able to transmit and receive using Direwolf subsequent to this experience with no problems.

Is this why you have made the warning?  I will verify which LINUX Kernel I am running later ASAP.

Best regards,

Paul
W04BCZ


Paul Noa
 

Update the Kernel version is visible on the third line of my screenshot photo
ie. 5.4.51-v7

Paul,
 W04BCZ


Basil Gunn
 

the second or third time I had done a shutdown for routine purposes I
got a stack dump twice in a row. [image: Stack Dump1.jpg]
Is this why you have made the warning?
You are using kernel 5.4.51-v7+.

From previous message:

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems


Paul Noa
 

Basil,

As I am not running on an RPi I cannot use the NWDR image, I tried!  
I am running the standard Raspbian Buster download from Raspberry.org on a BalenaFIN board.

I would like to know when the updated kernel is available. Where or what site should I monitor to know this info?

Question, the sensor data to which Anna refers  (and can be seen with the Draws Manager also), is that specific to the DRAWS Hat or the RPi on which it is running?

On BalenaFIN and maybe RPi as well I use this:
cat /sys/class/thermal/thermal_zone0/temp   from the HostOS. 
Divide that number by 1000 (cpu_temp/1000) to get the CPU temp in C.

The FIN uses the CM3 Raspberry Compute Module on a carrier board, which I have positioned using standoffs to be on the metal case panel coupled with Heat sink paste.  I am getting on average 96 F with the above command. I was curious if the temp measurements in Draws Manager were on the Draws Hat or the RPi?

Best regards,

Paul
W04BCZ


Paul Noa
 

Unfortunately I did an apt-get update on this build!


Basil Gunn
 

As I am not running on an RPi I cannot use the NWDR image, I tried! I
am running the standard Raspbian Buster download from Raspberry.org on
a BalenaFIN board.
The NWDR image uses a standard Raspberry Pi OS image so it doesn't make sense
it doesn't boot on the BalenaFin board but the standard Raspbian Buster
download does. It really is the same thing.

I would like to know when the updated kernel is available. Where or
what site should I monitor to know this info?
The PR has been accepted by the the Raspberry Pi group so whenever they
release a new kernel. https://github.com/raspberrypi/linux/pull/3773

Question, the sensor data to which Anna refers (and can be seen with
the Draws Manager also), is that specific to the DRAWS Hat or the RPi
on which it is running?
Draws HAT.

On BalenaFIN and maybe RPi as well I use this:
cat /sys/class/thermal/thermal_zone0/temp from the HostOS.
Divide that number by 1000 (cpu_temp/1000) to get the CPU temp in C.
vcgencmd measure_temp

probably doesn't work on a BalenaFIN
https://www.raspberrypi.org/documentation/raspbian/applications/vcgencmd.md

The FIN uses the CM3 Raspberry Compute Module on a carrier board,
which I have positioned using standoffs to be on the metal case panel
coupled with Heat sink paste. I am getting on average 96 F with the
above command.

I was curious if the temp measurements in Draws Manager were on the
Draws Hat or the RPi?
Probably RPi. John would know.

Doc on how to hold or revert a kernel version.
https://github.com/nwdigitalradio/n7nix/blob/master/docs/DRAWS_CONFIG.md#placing-a-hold-on-kernel-upgrade

This issue might relate to the panic you are seeing:
https://github.com/raspberrypi/linux/issues/3757


 

RPI sensors.
 

> I was curious if the temp measurements in Draws Manager were on the
> Draws Hat or the RPi?

Probably RPi. John would know.




--
John D. Hays
Kingston, WA
K7VE

 


Basil Gunn
 

The lastest Raspberry Pi OS respository has Anna's fix to the driver
for the DRAWS sensors in kernel version: 5.4.51-v7l+ #1333

First determine your current kernel version for reference:

uname -a

If you previously put a hold on kernel updates then unhold them now:

sudo su
apt-mark unhold $(apt-mark showhold)

To verify there are no package holds pending run:

apt-mark showhold

It is now safe to:

sudo su
apt-get update
apt-get upgrade

Verify your kernel version, has it changed?:
uname -a

If your kernel was updated then run the following:

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

# Force a sensor config file update
sensor_update.sh -f

You will now have an updated /etc/sensors.d/draws file which is
dependent upon kernel version & DRAWS fab revision.

reboot

# After rebooting verify sensor readings:

sensors

If you are starting a new installation there is a new RPi image
release, nwdr17.img, which has the updated sensor driver and
DRAWS sensor configuration.

Do NOT run draws-manager web app as it needs some work to be
compatible with the new sensors driver. The NWDR17 image has the
draws-manager daemon disabled.

/Basil N7NIX

Basil Gunn <@basil860> writes:

Until further notice please do not upgrade the kernel on your RPi.

Linux kernel 4.19.118 is OK
Linux kernel 5.4.51 has MANY problems

Run this to get your current kernel version:
uname -r

The following commands will upgrade your kernel.
Do NOT use them for a while:

apt-get dist-upgrade
apt full-upgrade

/Basil N7NIX