going

Maybe so: sudo chroot /mnt/ or sudo chroot /mnt/bin/bash or cd /mnt sudo chroot ./bin/bash

First, you need to mount your memory device in the /mnt folder. ls -l /mnt/bin/bash

My x86_64 work machine has openSUSE OS installed. I use QEMU KVM and Virtualbox Manager. I'm just installing an ubuntu server from the official website in this VM. The disk size for a VM is 55-60 GB. And already in this ubuntu VM, I'm cloning the armbian repository. In case of a VM malfunction, it is easy to restore it from a snapshot.

Download the device from the SD card. Mount the eMMC in /mnt. Post what is there: ls -al /mnt/boot ls -al /mnt/usr/lib/modules

Please let the community know which core your device is running on.

I think we need to remember this and publish it in the documentation in the section HOW TO KILL\DESTROY THE DEVICE CORRECTLY.

Did you download the device from the SD card? Is your broken space located on eMMC? If so, you will need to mount your eMMC. sudo mount /dev/mmcblk*** /mnt sudo mount --bind /proc /mnt/proc sudo mount --bind /sys /mnt/sys sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo chroot /mnt apt update; apt install linux-image-current-meson64 linux-dtb-current-meson64 exit sudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/sys sudo umount /mnt/proc

You can fix this using fsck. The errors will go away for a while. But with active I/O, they will return. This indicates that the SD card is very close to the end of its life cycle.

I've watched it. It looks like the OS has fallen asleep when the user is not doing anything. What kind of power supply is it now? And what is connected to the board besides the mouse and keyboard?

My guess: It can be a /boot/boot.cmd script. Source for sunxi64 config/bootscripts/boot-sun50i-next.cmd, for sunxi config/bootscripts/boot-sunxi.cmd The kernel command line parameters for the console and display are set in it. By default, in the settings file armbianEnv.txt It must be: console=both You can try to change console=display or any. Please keep me informed if you find an error in the script. P.S. In any case, the connection from the console service to other services seems strange to me. Maybe look in the system event log of the system in the order in which this happens during a crash?

I also noticed something similar when I was testing on bananapim64. I run without HDMI, only UART and Ethernet. The Ethernet starts working immediately, but the UART does not respond to the keyboard from the minicom. After a few minutes, everything magically starts working. These two boards of ours have not been tested for a long time. Perhaps something in u-boot needs to be fixed. Try to view the kernel messages by first adding debug level 10. sudo nano /boot/armbianEnv.tx verbosity=10 # sudo reboot sudo dmesg | grep -i ether Or something like that

I spent three days looking for a problem testing kernel variants on my bananapi-m64 (a64 core). I have no problem. Let's just test the new kernel: Orangepipc2-6.12-crust-mini + linux-image 6.12.4

You can try it. But you'd better wait. I'll do it on my own soon. Unfortunately, I have not found support in the 6.12 kernel for this device. drivers/gpu/drm/panel/Makefile:22:obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o drivers/gpu/drm/panel/Makefile:23:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o drivers/gpu/drm/panel/Makefile:24:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o drivers/gpu/drm/panel/Makefile:25:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9806E) += panel-ilitek-ili9806e.o drivers/gpu/drm/panel/Makefile:26:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o drivers/gpu/drm/panel/Makefile:27:obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o .... drivers/gpu/drm/tiny/Kconfig:123: If M is selected the module will be called ili9163. drivers/gpu/drm/tiny/Kconfig:135: If M is selected the module will be called ili9225. drivers/gpu/drm/tiny/Kconfig:148: If M is selected the module will be called ili9341. drivers/gpu/drm/tiny/Kconfig:162: If M is selected the module will be called ili9486. drivers/gpu/drm/tiny/Makefile:11:obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o drivers/gpu/drm/tiny/Makefile:12:obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o drivers/gpu/drm/tiny/Makefile:13:obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o drivers/gpu/drm/tiny/Makefile:14:obj-$(CONFIG_TINYDRM_ILI9486) += ili9486.o .... drivers/staging/fbtft/Makefile:13:obj-$(CONFIG_FB_TFT_ILI9163) += fb_ili9163.o drivers/staging/fbtft/Makefile:14:obj-$(CONFIG_FB_TFT_ILI9320) += fb_ili9320.o drivers/staging/fbtft/Makefile:15:obj-$(CONFIG_FB_TFT_ILI9325) += fb_ili9325.o drivers/staging/fbtft/Makefile:16:obj-$(CONFIG_FB_TFT_ILI9340) += fb_ili9340.o drivers/staging/fbtft/Makefile:17:obj-$(CONFIG_FB_TFT_ILI9341) += fb_ili9341.o drivers/staging/fbtft/Makefile:18:obj-$(CONFIG_FB_TFT_ILI9481) += fb_ili9481.o drivers/staging/fbtft/Makefile:19:obj-$(CONFIG_FB_TFT_ILI9486) += fb_ili9486.o .... Maybe if you find a kernel patch to support this device, then I'll add it to the build system and we'll check it out.

Your processor is h616, which means you'll have to turn on everyone for h6, h616

On which platform did you launch the build system?

I will ask for a little more detail about this problem. Perhaps the translation was inaccurate.

Are we discussing this particular NVME here? If so, then publish the diagnostics from smartctl. This will help shed some light on some issues. There are two unpleasant moments here. 1) An old and actively used disk with a large number of failed memory cells. The internal disk controller will redistribute the exhausted memory cells from those used at the time of the write operation. Which greatly reduces the recording speed. Disk manufacturers warn about this. 2) The internal disk controller works well only for a few file systems such as FAT, NTFS, ISO. I have two such devices, a SD card and an SSD drive from Samsung. On EXT4 and BTRFS file systems, the speed of read and write operations is greatly reduced. This is my personal experience and this case is for devices that were manufactured in 2008, 2010.

This is the first step. This means that some patches have a negative effect on older processors. They need to be detected and corrected. I'll assemble another core and call you. Will you be able to continue testing?

Test what you need on core 6.12. If you have any questions or suggestions, just create a new topic and call me.

If you want to participate in testing the intermediate version, then add this branch to your build system: armbian/build> git remote add -t test-6.12 The-going https://github.com/The-going/armbian-build armbian/build> git fetch The-going armbian/build> git checkout -b test-6.12 The-going/test-6.12 # exclude patches armbian/build> egrep '^-' patch/kernel/archive/sunxi-6.12/series.conf # If you need them, just remove the minus sign

Orangepipc2-6.12-crust-mini I have excluded patches for h6 and newer processors. Just for the test.

Tomorrow I will post the download link and we will test the new kernel 6.12 I'm glad your board is in order.

Why do you use a stress test for NVME? Do you want its resource to run out faster? You can find out the status\information using the smartctl program. Example: old disk sudo smartctl --all /dev/sda ... === START OF INFORMATION SECTION === Device Model: SSD 512GB Serial Number: YS202010005170AA ... ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) ... 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 117440512 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 2175044 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 6113508 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 1 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 22 194 Temperature_Celsius 0x0032 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 117242 ... a new disk sudo smartctl --all /dev/sdb ... === START OF INFORMATION SECTION === Device Model: SSD 128GB Serial Number: YS20211100077037 ... ATA Version is: ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) ... 175 Program_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 176 Erase_Fail_Count_Chip 0x0032 100 100 050 Old_age Always - 0 177 Wear_Leveling_Count 0x0032 100 100 050 Old_age Always - 33617462 178 Used_Rsvd_Blk_Cnt_Chip 0x0032 100 100 050 Old_age Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 050 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 050 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 050 Old_age Always - 19 194 Temperature_Celsius 0x0032 100 100 050 Old_age Always - 40 195 Hardware_ECC_Recovered 0x0032 100 100 050 Old_age Always - 0 ...

I would probably try to write some old\minimal image to a new 8-16 Gb SD card. And see if this behavior will be repeated. Something tells me that it's not about the equipment. Alternatively, I can assemble an image for you without using some Armbian patches that provide functionality for the new h6, h616, h618 processors and crust firmware.

10 - 20 minutes is enough. I've come across this kind of behavior. One of the possible reasons is the SD card from the manufacturer SAMSUNG. I have a "fast" SD card if it is formatted as FAT32. If I format it into any other file system, it starts to work very very slowly. The built-in SD card controller cannot cope. P.S. It seems the problem is not with the card. If you download another operating system and it works.