eselarm

This means to me that there is a power problem. That can be complex, with a backfeeding situation that exists with the CPU box but not with other computer. Might be electronically something damaged now, not impossible even if it worked for weeks. Might a different U-Boot that does incomplete initialization or does finally something correct but as a consequence that your setup does not work anymore. I see things initiated in the kernel log, but what is what is not clear to me. So maybe have a look at lsusb (with proper options) output. I must also say that USB connected storage is something I avoid. Wasted loads of time on it on RPI4, eventually made own power-supply, also battery fed now, that was main reason for own electronics actually. Else I could also have sold it, I have RK35xx devices now and use SATA from those and 12V based power.

It looks like the training of AI bots is getting to a stall. Anyway, a knowledgeable contributor does not feed the bots. Instead, they judge if the info from the bot can save their life. Will this bot come to my house with food for free and put it into my mouth. Asking the bot to give money first might look a good first thing to do, but it isn't. Even if real coins or paper and not bank transaction.

I now see that in your screenshot, a Windows filepath contains rk3588_sp... This Lyra has a rk3506B, that is a much different and only 32-bit SoC. So that seems not OK to me, so no surprise it does not work I think. But up to you to read documentation. And also I would not use Windows, the docs at luckfox assume Linux, so the commandline tool rkdeveloptool.\ I don't use Windows and also don't have this luckfox model, so cannot guess what is wrong actually.

File (.xz) less than 1M, it extracts to 1444M, only 836k content, rest is sparse. Only U-Boot is written It looks like. So clearly image generation failed.

I think there is something wrong with the whole chain from 'computer-RAM down to SD-card itself'. I state it like this because there can be many points where the root-cause is. An issue like this I have seen several times before, and I think I also have had it myself, but was several years ago. /dev/sdc means you use some USB attached mmc, so even if sequential reads and writes work fine, certain pseudo random scattered small blocks can maybe hit some corner-case in the whole Linux I/O in combination with out-of-spec hardware; can be power issue internally in the SD-card adapter, anything. Also the SD-card itself might do very strange things internally, you don't know, it is some micro-controller firmware. Even if not counterfeit or just fake. Check CID and/or post here maybe. So to avoid at least USB adapter issues, I have used my RPI4 that runs from USB3-SATA SSD as SD-card reader/writer for images for for example a nanopineo. So then in the RPi4 , it is /dev/mmcblk0 you operate on. My NanoPi-R6C runs from eMMC+NVME, so also there /dev/mmcblk0 is free to use for image writing. Advantage is also that those SBC native slots do support trim, so to also internally wipe SD-card I do 'sudo blkdiscard /dev/mmcblk0' sometimes first, than all is fast and freely available. This command actually failed on some details for some SD-card brand when in ROCK3A SD-card slot for some kernel version. Also A2 SD-card and faulty queuing can randomly corrupt things.

See https://wiki.luckfox.com/Luckfox-Lyra/Pinout and connect USB serial console cable You should see then what is going on and post that here.

See my 'dry' test: # cat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha 80ffb7486a9d9950c2613f42be520c4086d4a3b894da4fd46a07120ecd9ddb30 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz # sha256sum -c Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz: OK # xzcat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz > Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img # losetup --show -fP Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img /dev/loop0 # sudo fsck -f /dev/loop0p1 fsck from util-linux 2.41 e2fsck 1.47.2 (1-Jan-2025) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks # losetup -d loop0 So can't reproduce. I won't write it to real SD-card and then do the fsck. You can try this first, so via loop device. My computer is Armbian Trixie edge 6.18.0-rc7 NanoPi-R6C, .xz file downloaded on N100, so could also done it there, does not matter Ext4 is Ext4.

AFAIK this can mean the ROCK3C (and software running on it) failed on interpreting HDMI info from your specific HDMI monitor (too old, buggy, not according spec, strange timing, too new, maybe more). See things w.r.t. EDID. One can set a certain video= statement on the kernel cmdline, you need to read docs etc what the options are. Easier might be to use an newer kernel, rockchip64 edge kernel is 6.18.x, that one much better RK35xx support than the 6.12.x one in the image. See armbian-config for selecting edge/beta kernel. Or change sources.list yourself so that you can just do apt install linux-image-edge-rockchip64

I assume you are not blind and need some screen to see what data you enter into computers. I am not saying the N2+ is HDMI connected, but sure you do use some serial console cable and terminal program or ssh or maybe even telnet. But jokes aside, I think you do not get the point that it is you yourself who needs to get your own device working if you want Debian (because Armbian is busted according to you). I mean vanilla Debian, so only Debian packages that can be fetched via apt from Debian repositories. So that means no Armbian kernel+DeviceTree and no Armbian U-Boot. That is what I show you essentially. But read info on debian.org. Up to you to jump into the cold water and swim. You already figured out it is something with I2C busses/numbering, so that is DeviceTree and/or DeviceTree overlays. Vanilla Debian is roughly 1 year older than 25.11.1 Armbian Trixie, so if no-one who owns an N2+ (and is willing to do testing/trials for you) is reacting, you are the only. You can send your N2+ to me, maybe I can make it work, but I won't send it back as I need some sort of salary for the work done of course. Other option is Ubuntu Jammy image (with custom/vendor kernel) from odroid.com or so.

You can remove Xfce from an installation, via apt purge --autoremove options, may just by un-ticking it in tasksel, and systemctl set-default multi-user.target Done that kind of trick to get rid of RPi PiXel DE in the past when they had no -Lite images and/or I wanted to keep my rootfs while upgrading in-place to newer Debian main release. Same Actuallt recently for ROCK3A Armbian Bookworm cloned from NanoPi-R6C to Armbian Trixie just headless/CLI. My last run/config of a Armbian 25.11.1 image was with autologin root and doing 1st run config, the usual I know from Armbian. So the image you use is wrongly generated maybe, but the big question mark is what image? URL+sha256sum enables others to check/confirm without guessing and maybe picking a newer/different 'latest' image or so, else DIY.

Good that this is made default now for various boards. If a board/computer has no factory written bootloader, so only bootROM/maskROM, then this allows way more flexibility and also will get rid of endless topics and support issues that have their root cause in SD-card (failing, or worse fakes, fake brands, etc). As a scrub either done automatically or as support request on-demand/ad-hoc will tell. Also many operations can be done while the board/computer is kept running, no reboot needed. Like transferring rootfs OS from SD-card to NVME and many more great things. Like replacing an SD-card without reboot. Or rollback to know-good older snapshot after faulty update. I see I wrote some things about it here: https://forum.armbian.com/search/?q=CONFIG_CMD_BTRFS&quick=1 For boards/computers with factory written bootloader, so PCs with UEFI or BIOS or the strange Raspberries with their boot(EEP)ROM that need a 1st FAT, it is a different story. I figured out that for my computers that already use Btrfs for rootfs for years, even tiny/old RPi0/1, it is currently better alignment, so that I stick to heaving an extra boot partition still. It can be very small, I had defaulted to 40MiB some years ago for a single Linux OS VM (x86 or ARM), but just for some bootaa64.efi file that is already a lot. For RPi, 3MiB was enough, so you store only a bootcode.bin start* fixup* config.txt uboot.bin bootaa64.efi. But that extra boot partition is also easily very confusing, especially for RPi like methods where kernel+initramfs+DTB are copied. Also, I had Btrfs enabled U-Boot, an Ext4 bootpartition and Btrfs rootpartition while doing experiments (booting from Btrfs raid1 straight from U-Boot) on QEMU and AllwinnerH3. kernel+initramfs+DTB were accidentally read from Ext4 (/) instead of Btrfs (/boot) and more such confusion. So then I recompiled U-Boot without Ext4 (so only FAT,Btrfs), then fine. But generally I would keep Ext4 of course. With just 1 partition, then those issues are is avoided. Then simply 'U-Boot object' and 'rootfs object', where the latter can still be chosen Ext4. Btrfs U-Boot + rootfs also would make raw/flat images viable maybe. xz-compressed will certainly have smaller download file, but for full desktop variant images, there might be an overall advantage. If rootfs is written by Armbian build with let's say compress-force=zstd:9, only first MBR+bootloader sectors, the Btrfs metadata and some filesystem slack is not compressed. I think some statistics are needed first, maybe it is not worth the effort for mass-downloads also via torrents, mirrors, etc, but for own local builds I certainly see benefits. At least I force compress almost all newly written block-devices, so also a restore from backups. It can keep thin-provisioned volumes/images very small, also roughly halves the write-time for (slower/older) SD-cards.

Usually people switch off the HDMI monitor of the computer and and walk away. Or they put a mirror against the monitor and ask the person they see why they bought a computer that does not have Debian installed?. Why am I here? Do I need a CD-ROM drive to install from ISO myself? How do I enter the BIOS? Does it have BIOS? But there is hope. Aarch64 Debian13: root@odroidn2:/boot# apt install linux-image-arm64 root@odroidn2:/boot# ln -sf vmlinuz-6.12.57+deb13-arm64 Image reboot root@odroidn2:/boot# apt install u-boot-amlogic-binaries root@odroidn2:/boot# dpkg -L u-boot-amlogic-binaries | grep odroid-n2 /usr/lib/u-boot/odroid-n2 /usr/lib/u-boot/odroid-n2/u-boot.bin /usr/lib/u-boot/odroid-n2/uboot.elf /usr/share/doc/u-boot-amlogic-binaries/configs/config.odroid-n2.gz

I don't think so, then my Virtual Machine run would fail the same way as you describe, but it doesn't, it works fine. Of course it is the meson64 kernel running on top of KVM/virt machine, the RTC for example is emulated, while for your real N2+ is a specific Amlogic SoC kernel driver I assume, so there something could be wrong. Or what about clocking tree, there are many failures possible. I know for rockchip64 there were 2 RTC modules, at some point in time 1 was chosen over the other, so a change, could also introduce issues. You could browse kernel changes/patches And also what about an unknown bad/corrupted diskblock or so. I normally use Btrfs for rootfs, so easy to check for and detect corruption. So maybe re-image again. I am still not sure if I used the same image as you, but up to you to track that. You can do the same thing as I did to see if it is maybe a specific Amlogic driver issue; Run that image as VM on the same N2+, you need a network bridge with main eth port or else use NAT. Or you make it first efi bootable, then it can run easier in virt-manager GUI. N2+ is fast enough to run VMs, I even do that on ROCK3A (2GB RAM, 4x Cortex-A55). Or use standard Debian Trixie kernel on real N2+, not sure if that works good enough. Or remove/disable RTC kernel module. Or also remove fake-hwclock stuff if you haven't already done that. I did not do it for this VM run, but when real RTC+battery, I would remove or disable it.

I have the NanoPi-R6C and that came out of the box with an OpenWRT variant on eMMC. Indeed many partitions, but I think I managed to get it running somehow with Debian/Armbian rootfs on some higher partition number, I don't remember exactly. As long it can load boot.scr. Indeed eMMC is number 2, I guess they avoid potential confusion that is sometimes there with SBCs and various OSses swapping numbers for SD-card and eMMC. I had that once, no data loss but costed a lot of time. It is a bit similar to that on 6-SATA PC's, Debian might name the OS dev (SSD) /dev/sdb and a large HDD /dev/sda while Opensuse names OS always /dev/sda. So what do we do with 2-MMC SBC's ? I see my HP x86-64 dualrole computer/tablet uses /dev/mmcblk1 (its eMMC) for OS (Linuxes at least, Windows10 I don't remenber). The SD-card slot I have normally empty but uses /dev/mmcblk0 if card is inserted. It has UEFI and SecureBoot and TPM, so no choice actually like there is with opensource U-Boot. For NanoPi-R6C I have written Tianocore EDK2-UEFI to eMMC and appears as /dev/mmcblk1. I do not use the rest of the 32GB storage, but the UEFI binary comes with 1 partition, so easy to use the rest of the 32GB, but currently I need the much larger and faster NVME. And for emergency, if I insert an SD-card with newly generated rolling/edge image or so, it boots from that and is then /dev/mmcblk0. So this is IMO the preferred numbering, but I already had created some shell script code that can identify the boot partition and the root partition, but it is not too generic, only works if certain mounts are there which is what I have as I focus on EFI bootable and Btrfs with subvolumes ('nested' and default). So I would at least use 0 for SD. 1 for eMMC is fine. For the LEDs, on my NanoPi-R6C, I actually don't know, I never look at them. I think it is not correct with my installation (in-place upgraded and also other Linuxes), but I guess correct with current downloadable images. At least they were correct with the FriendlyElec OpenWRT that was pre-installed. I still can't get maskROM mode to work, so I am a bit paranoid on messing too much with data in the Rockchip loader area. I am not sure what happens if I put rubbish data or broken U-Boot there, can I still start from SD-card is the question. I might need to apply a fixed voltage between 9-20V as powersupply, but need to look in PCB schematics again first. For the Zero2, I see removable eMMC, so no risk or fear for 'hard-bricking'. Although I would check if maskROM works. For network, I assume it is the on-SoC port, so fixed off-the-shelf, so end0 is fine. For optional WLAN, I am not sure, likely some PCIe/HWtree named string, I have seen multiple altnames for 'wlo1', at least 'wlp1s0' or 'wlx<MACaddress>'. systemd-networkd should be able to handle those, NM can do all anyway.

I already see what the issue is: I have configured things in such a way that strange/new machines get served differently then known/existing ones. In addition, the known/existing ones need an extra setting in case of systemd-resolved. This makes a quick test with some random VM like this appear doing things wrong, but is actually expected. If I purge --autoremove netplan.io and put a symlink ln -sf /usr/lib/systemd/network/89-ethernet.network.example /etc/systemd/network/89-ethernet.network, there is working network again after reboot or restart service.