Jump to content


  • Posts

  • Joined

  • Last visited

  1. Great!!! I stuck on Kernel 5.4.88 for over two years. And now working sda sata ssd: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 223,6G 0 disk └─sda1 8:1 0 1G 0 part /mnt mmcblk0 179:0 0 28,9G 0 disk ├─mmcblk0p1 179:1 0 8G 0 part / └─mmcblk0p2 179:2 0 20,9G 0 part /platz zram0 254:0 0 483,6M 0 disk [SWAP] zram1 254:1 0 50M 0 disk /var/log
  2. I solved it by my own: I had to mount the boot directory of the sd card over the boot directory of the ssd. Therefore I added two lines to the /etc/fstab of my ssd: /dev/mmcblk0p1 /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind (had to create the directory /media/mmcboot first) Now the kernel loads in the right version. Kernel update works. Topic can be closed. Some information: root@pi-nas:~# uname -a Linux pi-nas 5.10.34-sunxi #21.05.1 SMP Thu May 6 20:13:21 UTC 2021 armv7l GNU/Linux root@pi-nas:~# ls /boot armbianEnv.txt boot.scr.bak System.map-5.10.34-sunxi armbian_first_run.txt.template config-5.10.34-sunxi uInitrd boot.bmp dtb uInitrd-5.10.34-sunxi boot.cmd dtb-5.10.34-sunxi vmlinuz-5.10.34-sunxi boot.cmd.bak dtb-5.4.20-sunxi zImage boot-desktop.png initrd.img-5.10.34-sunxi boot.scr overlay-user root@pi-nas:~# mount | grep boot /dev/mmcblk0p1 on /media/mmcboot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,x-gvfs-hide) /dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
  3. Interesting docs. I didn't know. Unfortunately I don't think anything fits for my problem except creating manual symlinks between the boot directory on sd card and ssd. But is this a solution that survives the mext kernel update? My problem is, the boot process uses the boot directory on sd card. The system uses the one on the ssd e.g. for storing updated kernel files. How can I point the boot directory from sd card to ssd?
  4. I didn't know about that before I did the manual way. I think I can't use it anymore because the target partition will be wiped. So I am looking for a manual way to fix my problem. Any ideas?
  5. System: armbian, BananaPi Pro, sd card, sata ssd, usb hdd I manually moved my existing armbian system from sd card to a sata ssd. Then I changed the rootdev in armbianEnv.txt to the ssd´s UUID. After reboot I thought everything was ok. Then after a system update I figured out that the kernel version differs from the installed kernel modules. I think the new kernel and the modules are installed in /boot at /dev/sda whereas the kernel still boots from /dev/mmcblk0p1. How can I fix this? Here some information: root@pi-nas:/mnt/boot# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 477G 0 disk ├─sda1 8:1 0 29,3G 0 part / ├─sda2 8:2 0 445,7G 0 part /home └─sda3 8:3 0 2G 0 part [SWAP] sdb 8:16 0 1,6T 0 disk └─sdb1 8:17 0 1,6T 0 part /share mmcblk0 179:0 0 7,3G 0 disk └─mmcblk0p1 179:1 0 1,3G 0 part root@pi-nas:~# mount /dev/mmcblk0p1 /mnt/ root@pi-nas:~# ls /mnt/boot/ armbianEnv.txt boot.scr overlay-user armbian_first_run.txt.template boot.scr.bak System.map-5.4.20-sunxi boot.bmp config-5.4.20-sunxi uInitrd boot.cmd dtb uInitrd-5.4.20-sunxi boot.cmd.bak dtb-5.4.20-sunxi vmlinuz-5.4.20-sunxi boot-desktop.png initrd.img-5.4.20-sunxi zImage root@pi-nas:~# cat /mnt/boot/armbianEnv.txt verbosity=1 logo=disabled console=both disp_mode=1920x1080p60 overlay_prefix=sun7i-a20 rootdev=UUID=f631e37b-e2e5-431a-aab0-cbbcc544528f rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@pi-nas:~# blkid /dev/sda1 /dev/sda1: UUID="f631e37b-e2e5-431a-aab0-cbbcc544528f" TYPE="ext4" PARTUUID="000a6123-01" root@pi-nas:~# ls /boot boot.scr dtb-5.10.34-sunxi uInitrd zImage config-5.10.34-sunxi initrd.img-5.10.34-sunxi uInitrd-5.10.34-sunxi dtb System.map-5.10.34-sunxi vmlinuz-5.10.34-sunxi root@pi-nas:~# uname -a Linux pi-nas 5.4.20-sunxi #20.02.1 SMP Mon Feb 17 02:09:41 CET 2020 armv7l GNU/Linux root@pi-nas:~# ls /lib/modules/ 5.10.34-sunxi
  • Create New...