segv

Thank you balbes150, mcb777 and dbsharpe for your help. Short version: My X96 Max is now happily running the 5.9.0 kernel. Long version: I still had the SD card that I used for my initial Armbian tests. It had Armbian_20.05.4_Arm-64_bullseye_current_5.7.0-rc5_20200516.img I changed the dtb in uEnv.txt from meson-g12a-x96-max-no-cvbs.dtb (which no longer exists) to meson-g12a-x96-max.dtb I booted the SD card and did an apt update/upgrade directly from kernel 5.7.0-rc5 to 5.9.0 It rebooted fine. I then did a dd of the BOOT partition from the SD card to my SSD. My box then rebooted correctly from the SSD. Conclusion: The main problem was that the dtb in the old example uEnv.txt is no longer included in the new dtb directory.

I just uncommented the line with meson-g12a-x96-max-no-cvbs.dtb in the example uEnv.txt file. I chose this because it was already present and it matches my needs: I have an X96 Max and I want HDMI not CVBS. Unfortunately this dtb is no longer present in the dtb directory which probably explains the failure. I changed to meson-g12a-x96-max.dtb and it now at least tries to boot. Unfortunately it now says "LABEL=ROOTFS does not exist" :-( I don't see why it would have disappeared but I shall try to debug this tomorrow. Edit: The label does exist. I am wondering whether USB is broken in 5.9.0 as I had a similar symptom a long time ago before USB was operational. Or maybe there is just a missing module.

As I wrote Concerning the media: to be more complete the SSD is a QMOX 240 GB and the enclosure is a Sabrent EC-UASP and, as I implied, it is running on the USB3 port. Concerning the settings: nothing concerning the boot process has changed (except for automatic modifications by "apt upgrade") since I installed Armbian Bullseye on the 16th of May with the appropriate DTB for my box. It had been running perfectly for five months and I have previously had "apt upgrade" kernel updates without problems. I agree with mcb777 that it was the latest linux-image-current-arm-64 package with kernel 5.9.0 which broke it. Looking at the contents of the BOOT partition it seems that much has been changed not only by this "apt upgrade" but also by previous ones. I don't want to reinstall everything so I shall try to fix the BOOT partition and if this fails I shall try overwriting it with the BOOT partition from a recent version. However any pointers to the likely cause would be most welcome ;-) I am convinced that there is a real problem with this deb package which must be corrected :-(

First a big thank you to balbes150 for his excellent work. I have been running Debian Bullseye on an X96 Max (S905X2) for several months and it has proved very stable. It boots from an SSD in an external USB3 enclosure. Kernel updates up to 5.7.16 have gone smoothly. Unfortunately today an "apt upgrade" seems to have attempted to install the 5.9.0 kernel and the box no longer reboots. There is nothing on the display and I can no longer ssh into the box. However, rather surprisingly to me, the front panel display counts up the minutes. I haven't tried to debug the problem. Does anyone have the same problem or, even better, a solution? TIA

I think you get these symptoms if the Ethernet interface declared in the device tree doesn't match that used on your device (100Mbps vs 1Gbps).

Thank you, this confirms what I wrote in my first post. However the solutions I proposed enable eth1 and DHCP automatically and avoid having to issue commands manually at each reboot.

Great! I have never tried any of the 0.7.x versions. It is good to know that they work too. But I don't understand why 0.6.x versions didn't work for you.

The 0.6.x images will not boot from a micro-SD card. If you want to run 0.6.x from a micro-SD card you need to take partitions 1 to 5 from 0.5.15 and only partitions 6 and 7 from 0.6.x. However I do not recommend this as I found that the micro-SD card soon gets corrupted and will no longer boot. See my remarks in my first post. However it is possible that whatever caused this data corruption has been corrected in later 0.6.x images.

The script is here: https://github.com/ayufan-rock64/linux-build/blob/0-6-stable/package/root/usr/local/sbin/enable_dtoverlay

I am away on holiday at the moment but I shall post ayufan's enable_dtoverlay script when I return. However IIRC it requires a kernel with device tree overlays enabled.

I have completely rewritten my first post with detailed instructions on how to install Ayufan's Armbian Ubuntu without needing a separate PC.

I don't have a real ROCK64, just a Scishion V88 Piano so the ROCK64 DAC board isn't relevant for me. To enable eth1 during each reboot add the following command to /etc/rc.local enable_dtoverlay eth1 ethernet@ff550000 okay Alternatively you can do this manually each time from a shell with sudo. In both cases you will first need to install the device-tree-compiler package. You may also have to configure DHCP on eth1 by executing the following commands in a shell as root (sudo -s):- # cd /etc/network/interfaces.d # sed s/eth0/eth1/ eth0 > eth1 # reboot (For some unknown reason "service networking restart" wasn't always sufficient for me.)

I have mainly been running it headless recently. (Note that the minimal versions also have a console display on HDMI which I sometimes use.) I have tried the Mate desktop from time to time but I have generally had some stability problems with it. Concerning video: I have only tried YouTube videos which are fluid but with some freezes. The freezes were fairly frequent on some versions but I think recent versions may be better. I have never tried audio: my HDMI monitor doesn't have audio and I haven't tried the S/PDIF. I am also very interested in running Kodi but I haven't tried it. Indeed my ultimate aim is to use it as a general purpose TV box with a Ubuntu desktop including Kodi and Tvheadend for DVB.

Starting from 0.6.27 ayufan has disabled eth1 in his Rock64 images, so internal Ethernet no longer works on the V88 Piano. Thanks to Igor and Xalius I found that this command will re-enable it on the running kernel: "sudo enable_dtoverlay eth1 ethernet@ff550000 okay" Update: I think the best solution is to add "enable_dtoverlay eth1 ethernet@ff550000 okay" to /etc/rc.local I also added "enable_dtoverlay eth0 ethernet@ff540000 disabled" to disable the Gigabit interface which is not used on these boxes. Before upgrading to >= 0.6.27 do a "sudo apt-get install device-tree-compiler" while you still have Ethernet as the enable_dtoverlay script needs it.

Thank you, Virverus, for this information. I shall try sometime but as I prefer wired Ethernet, Wi-Fi is not a priority for me.