Raspberry Pi Kernel Changes

The upgraded kernel packages with latest bug fixes have been built/tested/pushed to the unstable branch. The newer kernel packages (alone with their header packages) are:


I keep forgetting to mention that the RPi people has now exposed the cpu thermal so that "sensors" will pick it up on the kernels 5.4 and up. Sensors will not pick it up on kernel 4.19 in case some one has a custom config like with conky that uses it and does kernel hopping.


This is a very nice addition. :slight_smile:

I did not update the config file, and am still using the old names. I am now stuck at an emergency shell. How do I fix this?

One way is use /boot/cmdline.txt.pacsave and and /boot/config.pacsave as your cmdline.txt and config.txt.

On RPI4 after stable update 2020-06-13, when dropped to emergency shell, the /boot/ dir is empty , I cannot find the mentioned files!?

When looking at the BOOT partition I can find the cmdline.txt, and it does have root=LABEL=ROOT_MNJRO in it. So that should be fine, no?

There will be nothing there until the boot fat32 partition gets mounted there.

That would be a No. From your post in the other thread your error indicates that you are running an older image before we changed to the label ROOT_MNJRO for the root partition.

As mentioned above in my post #1 in your situation there should be in the fat32 partition cmdline.txt.pacsave file with your old config which you can use. The only change is root=/dev/mmcblk0p2 to root=LABEL=ROOT_MNJRO if you are not booting from a usb drive.

So in the cmndline.txt file if you replace with root=/dev/mmcblk0p2 it should boot if you are booting from a sdcard.

The best thing to do as I mentioned in post #1 above if you want to continue to use the old image is to change the boot and root partition labels to BOOT_MNJRO and ROOT_MNJRO so you do not have to modify anything with future kernel upgrades each time. Using gparted on another computer might be an easy way to do it.

1 Like

Thanks Darksky,

that helped a lot, excellent. But in my case I had to change the ROOT partition name only, renaming the BOOT partition would result in a non boot again.


I believe I found the answer. With the BOOT_MNJRO partition label re-name then the /etc/fstab needs to be changed also:

[ray@pi4 ~]$ cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
LABEL=BOOT_MNJRO  /boot   vfat    defaults        0       0


If sudo lsblk -o name,mountpoint,label,size,uuid shows this:

mmcblk0                      29.8G 
├─mmcblk0p1 /boot      BOOT    94M E182-0FA0
└─mmcblk0p2 /          ROOT  29.7G 1d8c1793-1207-4d49-a217-2462b9cee6ad

Then the cmdline.txt should still contain "LABEL=ROOT_MNJR" ? Or should I rename my partition label?

If it was me I would rename the root partition label to ROOT_MNJR and be done with it so when future kernel upgrades are done you do not have to constantly mess with the cmdline.txt.

1 Like

what should i do when my headless pi 4 setup doesnt boot/connect through ssh anymore(after update)? i have 2 of the same pi, neither of them would boot/connect through ssh, theres just a solid light for both green and amber. and just a little bit of pulses on the cpu activity LED.
should i just take my sd card and get a clean install? or is there anyway to fix it?

You have not given much info but you mentioned "after update". I suspect it is the same issue as most others in this thread. Please read and see if it fixes your problem.

so maybe its in emergency shell? i can just rename the cmdline.txt.pacsave to cmdline.txt?

That is one of different options as stated in the above conversations.

Sorry for the short answer but I seem to be repeating myself over and over with people reporting the same issue in the same thread. Ten days ago I made the first post here trying to give a heads up on what the kernel change was to involve.

Hi, I was facing the same problem than @JustMe getting stuck at an emergency shell. I did what @Darksky mentioned of renaming cmndline.txt file with root=/dev/mmcblk0p2, so i can boot. That worked, thanks!. But now to not have problems in future kernel updates, i should rename the root partition label back to ROOT_MNJR? how can i do that, sorry I am noob here. Thanks.

Update: ok i managed to rename root partition, but boot partition cannot be renamed. In any case, everything seems to work fine. I hope with future updates nothing else breaks.

Would setting root by partition UUID be better than using the partition Label?

On my Raspberry Pi 4 I have used the the PINN installer to install both versions (KDE and Xfce) of Manjaro 20.04 side-by-side on the same 64GB SD card. https://github.com/procount/pinn

After the initial installs I can choose which OS to boot from the boot menu UI. The Manjaro /boot/cmdline.txt files reference the root filesystems by device paths in this initial install.

Then I upgraded each install to the 5.4 kernel:

sudo pacman -S linux-rpi4-next

This upgrade changes the /boot/cmdline.txt files to reference the root fs by partition Label.

The current PINN installer and OS chooser doesn't (yet?) understand naming conventions for the BOOT_MNJRO and ROOT_MNJRO partitions: https://github.com/procount/pinn/issues/395 so I manually renamed my partitions.

The partitions on my SD card look like this:

[pi@rpi-tv ~]$ lsblk -o name,label,fstype,uuid
├─mmcblk0p1  RECOVERY   vfat   008A-3DED
├─mmcblk0p5  SETTINGS   ext4   09bfced7-0530-4a7c-aa48-35b6bbd8b40e
├─mmcblk0p6  BOOT_MNJRO vfat   759B-B584
├─mmcblk0p7  ROOT_MNJRO ext4   e64889d4-b11a-44a3-b002-cd340f5fe90e
├─mmcblk0p8  BOOT_MNJRO vfat   8995-1E55
└─mmcblk0p9  ROOT_MNJRO ext4   79f87218-5acf-4c3a-8083-bfa1b9328d1c

When I boot and use the PINN UI to choose a version of Manjaro to start I (almost) always end up loading the second OS on the card (Xfce in my case), regardless of my choice.

I think that the PINN installer/boot chooser /could/ be updated to manage the appropriate command lines, but would it be more robust for the Manjaro /boot/cmdline.txt to reference the root and boot partitions by UUID?

I have updated /etc/fstab and the /boot/cmdline.txt files in my 2 installs to use UUID=XXXX everywhere, and everything now works as expected, but I think that this configuration is likely to be overwritten with each new kernel upgrade?

You can change it to anything you want if you use PINN but as you say you will have to make adjustments after a kernel upgrade.

We have it this way for ease of install and future kernel upgrades using our images involving the sdcard, MSD usb boot and kernel upgrades across different releases where things do not change over time; especially UUID's which can turn into a big hairball real fast.

I see how referencing root by Label enables a generic install image.

Are side-by-side installs intentionally ruled out - for example to run a test or unstable branch install next to a stable install on the same MSD?

That has never been a consideration. Very few people use dual boot. I have never tried it and probably never will. It is not that hard swapping out sdcards and re-power the device.

If we did start trying to reconfigure then could run in to different issues between the differen dual boot programs to make it work. There are not many of us dev's and we work long hours trying to keep up with what we do now.

Forum kindly sponsored by