[SOLVED] Apologies, dumb question on changing Armbian Kernel Image

[AxelFoley]

Apologies, the links on how to change the Armbian boot kernel don't lead to any documentation.

I am wading through the u-boot documentation tree now, but somebody may have an answer to a simple question.

 

I manage to make my device unbootable by using armbian-config and selecting a development kernel vmlinuz-4.20.0-rockchip64

 

I have mounted the disk on a ubuntu laptop and I take it u-boot is similar to grub2 in that its not just a case of changing the symlinks

 

Image -> vmlinuz-4.4.167-rockchip64

Uinitrd -> uInitrd-4.4.167-rockchip64

 

you have to do a grub2-mkconfig command \ grub-update in order to boot strap the device ?

 

If I find the answer from the u-boot site ... I will post the answer. 

[AxelFoley]

decided to go through armbian-config for clues .to see what it does during a kernel change

 

... unfortunately in function other_kernel_version ()  it seems to rely on debian packages to trigger the commands i need  .... probably on a post install event.

 

so its back to the u-boot website

 

 

[AxelFoley]

debian preinst code;

 

#!/bin/bash

# Pass maintainer script parameters to hook scripts
export DEB_MAINT_PARAMS="$*"

# Tell initramfs builder whether it's wanted
export INITRD=Yes

test -d /etc/kernel/preinst.d && run-parts --arg="4.20.0-rockchip64" --arg="/boot/vmlinuz-4.20.0-rockchip64" /etc/kernel/preinst.d

# exit if we are running chroot
if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then exit 0; fi

check_and_unmount (){
    boot_device=$(mountpoint -d /boot)

    for file in /dev/* ; do
        CURRENT_DEVICE=$(printf "%d:%d" $(stat --printf="0x%t 0x%T" $file))
        if [[ "$CURRENT_DEVICE" = "$boot_device" ]]; then
            boot_partition=$file
            break
        fi
    done

    bootfstype=$(blkid -s TYPE -o value $boot_partition)
    if [ "$bootfstype" = "vfat" ]; then
        umount /boot
        rm -f /boot/System.map* /boot/config* /boot/vmlinuz* /boot/Image /boot/uImage
    fi
}
mountpoint -q /boot && check_and_unmount
exit 0

[AxelFoley]

debian postinst code;

 

#!/bin/bash

# Pass maintainer script parameters to hook scripts
export DEB_MAINT_PARAMS="$*"

# Tell initramfs builder whether it's wanted
export INITRD=Yes

test -d /etc/kernel/postinst.d && run-parts --arg="4.20.0-rockchip64" --arg="/boot/vmlinuz-4.20.0-rockchip64" /etc/kernel/postinst.d

if [ "$(grep nand /proc/partitions)" != "" ] && [ "$(grep mmc /proc/partitions)" = "" ]; then
    mkimage -A arm -O linux -T kernel -C none -a "0x40008000" -e "0x40008000" -n "Linux kernel" -d /boot/vmlinuz-4.20.0-rockchip64 /boot/uImage  > /dev/null 2>&1
    cp /boot/uImage /tmp/uImage
    sync
    mountpoint -q /boot || mount /boot
    cp /tmp/uImage /boot/uImage
    rm -f /boot/vmlinuz-4.20.0-rockchip64
else
    ln -sf vmlinuz-4.20.0-rockchip64 /boot/Image || mv /boot/vmlinuz-4.20.0-rockchip64 /boot/Image
fi
touch /boot/.next
exit 0

[AxelFoley]

Turned out that the armbian-config when installing BETA version 4.20.0-rockchip64 seem to change the naming convention of where

 

(what I assume is the firmware)

 

from  /boot/dtb-(version)-rockchip64

 

to /boot/rockchip64

 

and the old mainline kernel was deleted so although the kernel image was there and symlinked ... there was nothing under;

 

/boot/dtb   (symlink to)

/boot/dtb-4.4.167-rockchip64

 

I populated the missing directories from a working node and the eMMC was able to bootstrap the device.

 

would be good to know why the deb package touched .next however ?

 

[Mathias]

Thanks a lot for your posts! I actually had the same problem and ended up re-flashing my emmc... Now that my whole system is configured, I obviously don't want to overwrite it with a fresh new image. So, this means that if I backup /boot, I can play around with any BETA kernel and if my board gets bricked, I can just overwrite /boot with my backup to be able to boot again, right? (ie no need to run a special command like grub-update or similar for arm)

 

If somebody could confirm, that would be great!

Mathias

[martinayotte]

4 hours ago, Mathias said:

So, this means that if I backup /boot

/boot is not enough, you also need to backup /lib/modules/<kernel-version> ...

 

[Mathias]

Thanks! And this also means, that if I check and fix the symlinks in /boot just after upgrading the kernel to 4.20.0 with amrbian-config (ie making sure /boot/dtb points to /boot/dtb-4.20.0-rockchip64), I should be able to boot with kernel 4.20.0?!

[martinayotte]

1 hour ago, Mathias said:

And this also means, that if I check and fix the symlinks in /boot

Right ! But not only the symlink of dtb, but also the ones for Image and uInitrd.

[Mathias]

Thanks all for your help! So, to keep for the record:

 

0) before you play around with a new kernel, make sure you have a backup of /boot (I keep such a backup as /boot_bak directly on the system). Worst case, flash a new image on a usb stick and grab its /boot

 

1) in order to rescue a system where a new kernel does not boot:

     * in /boot, there are 3 symbolic links that must point to the right place: dtb, Image and uInitrd. The last two must point to the same version. For example, dtb -> dtb-4.4.174-rockchip64, Image -> vmlinuz-4.4.174-rockchip64, uInitrd -> uInitrd-4.4.174-rockchip64 (I could not find any version other than 4.4.174 for the dtb, so I've always kept the link pointing to it);

    * of course, you still need config-4.4.174-rockchip64, System.map-4.4.174-rockchip64 and your kernel, for example vmlinuz-4.4.174-rockchip64

    * you can keep several kernel version, just adjust the three symlinks mentioned above to point to the version you want to use for your next boot;

    * All these steps can obviously be done by mounting your sdcard or emmc on your computer.

 

2) Then boot/reboot your system

     * keep in mind that the rockpro64 is very unreliable when it's about starting... if the system does not boot, check if the ethernet leds came up or not, if the power led came up or not, etc Mine often does not even get the power led turning on! So try several time to press the power and/or reset buttons, plugin in/unplugging before you give up;

     * some kernels do not support hdmi output yet (actually, most of them beside the Rockship original patches). So don't despair if nothing comes on the screen... If you've added a dptx.bin firmware, it can be that the board does not boot if no screen is connected...

 

So far, I could not boot with the Armbian 4.20.0 kernels but everything works fine with the Ayufan kernels installed on Armbian (both 4.19 and 5.0 ). In this case, just copy the deb package from Ayufan that you want and install it with dpkg (dpkg -i {package name}). You will have to redo one of the mentioned symlinks, but other than that, everything works.

 

Mathias