Raspberry Pi Kernel Changes

Due to the new MSD boot feature the RPi folks added for the pi4 and in an effort to streamline where our images can be burned to a sdcard or a MSD boot drive or kernel upgradesdepending on how you are booting I have changed in /boot/cmdline.txt how the root partition is defined. Instead of using the root partition's blk device it now will use the root partition's LABEL. Credit: @mitchejj

Changed from:
 
root=/dev/mmcblk0p2
 
To:
  
root=LABEL=ROOT_MNJRO

Our later images have had partition LABEL's BOOT_MNJRO & ROOT_MNJRO for a while and if you are running with these LABEL's all should be ok unless you have some other custom root= or custom cmdline.txt perimeter added.

On older images with different partition LABEL's then you can run into an issue booting after a kernel upgrade and the boot= needs to be like you had it (before booting in to the new kernel) or rename your partition LABEL's and be done with it. Depending if you or upgrading an existing kernel (Your cmdline.txt may not be over written but the new one will be written as cmdline.txt.pacsave) or if you are testing another kernel version (Then your cmdline.txt will be saved as cmdline.txt.pacsave).

As always if you had a custom config.txt then you need to check it before rebooting the new kernel also.

You still will have to flash the pi4 eeprom before trying MSD boot.

This change will start today as soon as I get all of the new kernels pushed to the unstable branch and eventually they will move down through the branches to the stable branch. The RPi tree's updated to new versions 2 days ago. Their new kernel versions along with their headers are:

linux-rpi4-4.19.126-1
linux-rpi4-next-5.4.44-1
linux-rpi4-mainline-5.6.16-1

Sorry about this change but it is in the best interest going forward.

Ray

4 Likes

After the RPi people upgraded their kernel tree they have pushed some bug fixes I believe I should recompile and build new packages as they could be important.

When I get the new kernel packages built and tested to today I will push them to the unstable branch. The packages above will have the -2 extension.

Bug fixes:

KERNEL 4.19:
 
overlays: i2c-gpio: Avoid open-drain warnings
 
The i2c-gpio driver expects to use a GPIO in open-drain mode. Failure
to configure it in that way causes alarming warnings in the kernel log.
The BCM283x and BCM2711 GPIO blocks don't support open-drain mode, but
gpiolib can emulate it in software if configured correctly.
 
KERNELS 5.4 and 5.6:
 
overlays: Update upstream overlays after vc4-kms-v3d change
 
snd_bcm2835: disable HDMI audio when vc4 is used (#3640)
 
Things don't work too well when both the vc4 driver and the firmware
driver are trying to control the same audio output:
 
[  763.569406] bcm2835_audio bcm2835_audio: vchi message timeout, msg=5
 
Hence, when the vc4 HDMI driver is used, let it control audio. This is done
by introducing a new device tree property to the audio node, and
extending the vc4-kms-v3d overlays to set it appropriately.
 
vc4: cec: Restore cec physical address on reconnect
 
Currently we call cec_phys_addr_invalidate on a hotplug deassert.
That may be due to a TV power cycling, or an AVR being switched
on (and switching edid). This makes CEC unusable.
 
Set it back up again on the hotplug assert.

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:

linux-rpi4-4.19.126-2
linux-rpi4-headers-4.19.126-2
linux-rpi4-mainline-5.6.16-2
linux-rpi4-mainline-headers-5.6.16-2
linux-rpi4-next-5.4.44-2
linux-rpi4-next-headers-5.4.44-2

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.

sensors

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

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.

Interesting

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

Hi,

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

NAME        MOUNTPOINT LABEL  SIZE UUID
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
NAME         LABEL      FSTYPE UUID
mmcblk0                        
├─mmcblk0p1  RECOVERY   vfat   008A-3DED
├─mmcblk0p2                    
├─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.

Forum kindly sponsored by