Nanopc T4 - Upgraded to bullseye but still on 4.4 kernel
mrchrisster opened this issue · comments
I'm trying to update my kernel to use wireguard. I spend a good chunk of the day getting everything upgraded to bullseye but I'm not sure how to switch over to the new kernel.
dietpi-config -> update firmware didn't seem to do anything or produce an error. reboot did not help unfortunately.
root@nanopc:/boot# dpkg -l | grep linux
ii binutils-aarch64-linux-gnu 2.35.2-2 arm64 GNU binary utilities, for aarch64-linux-gnu target
ii console-setup-linux 1.205 all Linux specific part of console-setup
ii hfsprogs 540.1.linux3-4 arm64 mkfs and fsck for HFS and HFS+ file systems
ii libselinux1:arm64 3.1-3 arm64 SELinux runtime shared libraries
ii libselinux1-dev:arm64 3.1-3 arm64 SELinux development headers
ii libv4l-0:arm64 1.20.0-2 arm64 Collection of video4linux support libraries
ii libv4lconvert0:arm64 1.20.0-2 arm64 Video4linux frame format conversion library
ii linux-base 4.6 all Linux image base package
ii linux-headers-5.10.0-28-arm64 5.10.209-2 arm64 Header files for Linux 5.10.0-28-arm64
ii linux-headers-5.10.0-28-common 5.10.209-2 all Common header files for Linux 5.10.0-28
ii linux-headers-arm64 5.10.209-2 arm64 Header files for Linux arm64 configuration (meta-package)
ii linux-image-5.10.0-0.deb10.16-cloud-arm64 5.10.127-2~bpo10+1 arm64 Linux 5.10 for arm64 cloud (signed)
ii linux-image-5.10.0-28-cloud-arm64 5.10.209-2 arm64 Linux 5.10 for arm64 cloud (signed)
ii linux-image-cloud-arm64 5.10.209-2 arm64 Linux for arm64 cloud (meta-package)
ii linux-kbuild-5.10 5.10.209-2 arm64 Kbuild infrastructure for Linux 5.10
ii linux-libc-dev:arm64 5.10.209-2 arm64 Linux support headers for userspace development
ii util-linux 2.36.1-8+deb11u1 arm64 miscellaneous system utilities
root@nanopc:/boot#
root@nanopc:/boot# uname -a
Linux nanopc 4.4.126 #7 SMP Thu Jul 19 22:51:16 EST 2018 aarch64 GNU/Linux
root@nanopc:/boot#
root@nanopc:/boot# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@nanopc:/boot#
root@nanopc:/boot# ls -lah
total 74M
drwxr-xr-x 3 root root 4.0K Feb 13 19:23 .
drwxr-xr-x 24 root root 4.0K Dec 7 2022 ..
-rw-r--r-- 1 root root 110K Jul 28 2022 config-5.10.0-0.deb10.16-cloud-arm64
-rw-r--r-- 1 root root 111K Jan 31 13:14 config-5.10.0-28-cloud-arm64
drwxr-xr-x 4 root root 4.0K Feb 13 12:01 dietpi
-rwxr-xr-x 1 root root 6.0K Jun 9 2018 dietpi-README.md
-rwxr-xr-x 1 root root 11K Oct 9 2022 dietpi.txt
-rw-r--r-- 1 root root 15M Feb 13 11:33 initrd.img-5.10.0-0.deb10.16-cloud-arm64
-rw-r--r-- 1 root root 15M Feb 13 19:23 initrd.img-5.10.0-28-cloud-arm64
-rw-r--r-- 1 root root 83 Jul 28 2022 System.map-5.10.0-0.deb10.16-cloud-arm64
-rw-r--r-- 1 root root 83 Jan 31 13:14 System.map-5.10.0-28-cloud-arm64
-rw-r--r-- 1 root root 23M Jul 28 2022 vmlinuz-5.10.0-0.deb10.16-cloud-arm64
-rw-r--r-- 1 root root 23M Jan 31 13:14 vmlinuz-5.10.0-28-cloud-arm64
root@nanopc:/boot#
Hmm, you are running a very old image, it seems. We migrated our images to Armbian-based kernel packages some years ago. The kernel you tried to install Debian cannot work without modifying the boot environment/script as well. But uff, where the hack is this 4.4 kernel image, actually, and the boot script 😄?
Can you check this please:
df
lsblkThanks for getting back to me. I was thinking of just starting from scratch but this little guy has been such a trooper ever since I started using dietpi and I'd hate to start all over.
root@nanopc:/boot# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 14631928 11818968 2194828 85% /
devtmpfs 1974228 0 1974228 0% /dev
tmpfs 1975132 4 1975128 1% /dev/shm
tmpfs 790056 90256 699800 12% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 51200 20 51180 1% /var/log
tmpfs 1974272 12 1974260 1% /tmp
tmpfs 395024 24 395000 1% /run/user/0
/dev/nvme0n1p6 490846472 38186148 452643940 8% /mnt/nvme
root@nanopc:/boot#
root@nanopc:/boot# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 7.8M 0 rom
mmcblk1 179:0 0 14.6G 0 disk
├─mmcblk1p1 179:1 0 4M 0 part
├─mmcblk1p2 179:2 0 4M 0 part
├─mmcblk1p3 179:3 0 12M 0 part
├─mmcblk1p4 179:4 0 32M 0 part
├─mmcblk1p5 179:5 0 32M 0 part
└─mmcblk1p6 179:6 0 14.2G 0 part /
mmcblk1boot0 179:32 0 4M 1 disk
mmcblk1boot1 179:64 0 4M 1 disk
mmcblk1rpmb 179:96 0 4M 0 disk
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 4M 0 part
├─nvme0n1p2 259:2 0 4M 0 part
├─nvme0n1p3 259:3 0 12M 0 part
├─nvme0n1p4 259:4 0 32M 0 part
├─nvme0n1p5 259:5 0 32M 0 part
└─nvme0n1p6 259:6 0 476.6G 0 part /mnt/nvme
root@nanopc:/boot#
Hey Micha,
I bit the bullet and just started over from scretch with a fresh image. i compiled a new u-boot and flashed it to the location specified in the friendlyarm wiki docs but it crashed the system. in the end it's all good now with a fresh install
Ah, now I remember it was this multi-partition image, and the kernel was located on one of the other partition, but in raw format, hence no filesystem which could be mounted.
Coincidentally I was just about testing a migration of such system to Armbian-based kernel, but NanoPi R5S/R6S, which currently have the kernel similarly distributed. But a fresh image is definitely cleaner.
with a fresh image. i compiled a new u-boot and flashed it to the location specified in the friendlyarm
The Armbian bootloader packages ship with a script which flashes the bootloader correctly OOTB. But a kernel and boot script which tells the bootloader to load this kernel is required as well. And I guess the leading 5 partitions need to be removed, so that only the root partition is left, and the new bootloader does not overlap with one of the first partitions. As said, I'm just going to test this process now. But probably not relevant for you anymore, as you flashed a new image already.