All Activity

I flashed same image to a SD card and tried to boot from it. Following is the result of `grep mmcblk1p2 /var/log/syslog` 2025-09-17T09:52:44.015489+00:00 rock-5-itx armbian-resize-filesystem[947]: ### [resize2fs] Trying to resize ext4 filesystem on /dev/mmcblk1p2: 2025-09-17T09:52:44.015493+00:00 rock-5-itx armbian-resize-filesystem[947]: Running 'resize2fs /dev/mmcblk1p2' now... 2025-09-17T09:52:44.015508+00:00 rock-5-itx armbian-resize-filesystem[947]: Filesystem at /dev/mmcblk1p2 is mounted on /; on-line resizing required 2025-09-17T09:52:44.021891+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Quota mode: none. 2025-09-17T09:52:44.021891+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): unmounting filesystem. 2025-09-17T09:52:44.021893+00:00 rock-5-itx kernel: EXT4-fs (mmcblk1p2): mounted filesystem with writeback data mode. Quota mode: none. I will try booting from a different medium and running `fsck mmcblk1p2` too.

many thanks, JMCC but I couldn't, for the life of me get it to install. After trying to install whatever armhf .deb files I could, I got stuck with 3 missing deps. After more fiddling and basically copying every possible deb file to the apt cache, somehow I made it worse. I give up for today, it's been a couple of hours after my dayjob already. Wanted to use the tinkerboard a video streamer/lite computer for the bedroom but without acceleration for youtube, netflix and even my own movies, might as well get one of those crappy android sticks. I'm affraid that without some automagic script to run it all I'm lost this is what I succeded in getting: The following packages have unmet dependencies: media-buster-legacy-tinkerboard : Depends: qtmultimedia5-examples but it is not going to be installed Depends: qtgstreamer-plugins-qt5 but it is not going to be installed Depends: kodi-rk but it is not installable Depends: mpv-legacy but it is not installable Depends: librga2 but it is not installable

Sorry, it's working now.

Hi, In the documentation (https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-kernel-config) it says: "User provided kernel config: If the file userpatches/linux-$LINUXFAMILY-$BRANCH.config exists, it will be used instead of the default one from config." Is there a way to define only the desired changes to the kernel parameters?

Hi! Now https://github.armbian.com/configng not working from RU. W: Не удалось получить https://github.armbian.com/configng/dists/stable/InRelease Невозможно инициализировать соединение с github.armbian.com:443 (2606:50c0:8001::153). - connect (101: Сеть недоступна) Невозможно инициализировать соединение с github.armbian.com:443 (2606:50c0:8000::153). - connect (101: Сеть недоступна) Невозможно инициализировать соединение с github.armbian.com:443 (2606:50c0:8003::153). - connect (101: Сеть недоступна) Невозможно инициализировать соединение с github.armbian.com:443 (2606:50c0:8002::153). - connect (101: Сеть недоступна) Не удалось соединиться с github.armbian.com:443 (185.199.111.153): время ожидания для соединения истекло Не удалось соединиться с github.armbian.com:443 (185.199.110.153): время ожидания для соединения истекло Не удалось соединиться с github.armbian.com:443 (185.199.108.153): время ожидания для соединения истекло Не удалось соединиться с github.armbian.com:443 (185.199.109.153): время ожидания для соединения истекло Upgrade armbian-config is not possible. Is there any mirror of this repo?

@SteeMan That is actually a good question, to which I do not have the answer. Here's a picture of the chip itself: I have not been able to find any information on that particular chip, so it may as well be nand...

@Qvy Are you sure you actually have emmc and not the older plain nand? Android kernels have support for raw nand. That support never was put into mainline linux as emmc became the standard. A lot of older TV boxes used raw nand as that was cheaper at the time. And sometimes identical looking boxes will have different components. For example I have TX3 Mini boxes that some come with emmc and some come with nand. And only those with emmc are supported by mainline linux kernels.

I did not get display before but just tested again, and indeed I do! I'm very surprised about it. I know that I do not require eMMC to work but it is much more reliable imo, and I think it would be a more complete build if I could get it to work

OK. I think workaround is to re-download / re-install armbian.key from repository. As key was already changed.

You can run Armbian just fine only from SD card, I do that on a Beelink box, you do not NEED emmc to work. Did you get picture on the monitor?

Hello good people, it's update time! I have made a bit of progress but got stuck again. Here's what I did : I have tested the pads I found next to the SDCard and indeed, they were serial connections. With a little bit of brain power and luck, I figured out that the one with the square pad is GND, and both in the middle are tx/rx. Please don't judge my deskmat... Once that was done, I was able to connect to the serial port through a terminal and armbian surprizingly booted. I was able to test the 3 different DTBs that are supposedly compatible with my board and all of them booted, though with no luck of getting the eMMC working. I then got the idea to find the dtb of the original android install and got to work. I was able to extract a dtb.img file, which after some work, got 2 dtb files out of it, supposedly for both 1G/8G and 2G/16G versions of the board, the later being mine. Sadly it does not work as is, but I believe that it gives me enough information to keep going. But here's the road block, no matter my attempts yesterday at trying to get the correct code inside of the dtb file, nothing would get the emmc to work. Otherwise everything works fine, the armbian install for that board is not the cleanest but after fixing a few things, I was able to ssh into it through network and work on it from there. If there's a kind soul out there with dtb manipulation skills, I would be grateful to get help from you!

@Igor is the case, I upgraded from bookworm to trixie

this can easily be answered with a quick web search or AI request for "disadvantage of LPAE on armhf". As expected, one of the drawbacks is increased use of memory when the benefit of larger addressable memory applies only to few installations and in a limited way.

OK, this is the line that is problematic. You need to find out why sda2 is mounted read-only. Go through the logs, for example "sudo grep sda2 /var/log/syslog". If you can, boot from a different medium and fsck sda2.

Certainly worth a look. It is also probably worth comparing the Armbian commit from when I last had it working until now, but it will need to be when I have a bit more time, and me remembering just when I first started seeing these issues.

I wonder if it'd be worth having a look instead at the Odroid stock kernel image and the vanilla kernel of the base same version; see what quirks are needed. I will have a look and see if that diff is less overwhelming than the massive gap you're seeing.

Hi pcduino2user, glad you are finding it useful. Maybe CMA Buffer size needs to be lowered during the kernel, which actually appears to get ignore anyway once the board has fully booted and replaced with 96mb based on the reserve memory node within the A10 DTSI. This is definitely needed if trying to run a desktop although I wouldn't recommend running a desktop on the Pcduino2. There are still some minor issues that I would like to address in future but I don't have as much time as I used to. For example the pcduino2 is actually booting from the Pcduino1 DTS although this problem is more cosmetic than functional. Both the Pcduino1 and Pcduino2 share the same uboot defconfig file but the Pcduino2 has a USB2 VBUS pin defined within its DTS and physically connected on the PCB. This is normally pulled high by a resistor so does not cause any problems with USB power being enabled. The build framework allows us to configure the kernel but there must be a way to customize uboot more dynamically as well? Now certain Armbian board configuration files appear to contain configuration data for adjusting the dram speed as can be found in the cubieboard.csc so I wonder if a similar setup in the pcduino2 configuration file to override the default device tree property to use sun4i-a10-pcduino2.dts instead of sun4i-pcduino.dts. Given the closeness of hardware it does not seem worth creating a separate defconfig file. Ryzer

Hi @Nick A, the armbian in afiftyp board just see 2GB to, at least it was this way in 2024 when he sent me his boot log. My board is very similar to afiftyp board, except of a number near the QC sticker, that looks like a version number. afiftyp number is 2336 and the mine is 2333. The amout of memory chips is identical to (8 chips), but tha labels is a litle different, but I cant found the label meaning. I use your image since very old one, so I don't think it is about u-boot update, but I could try an older one. About Secure Boot, A patch that you give me solved it and it isn't a problem any more (thanks again for it). @afiftyp, if I'm wrong and you already solve your rom amount in armbian, please let us know and if you could, explain us what you did to solve it, thanks.

Hi Ryzer, hi Igor, I was out of town for a while, but recently I could try out the new Armbian release v25.8.1, which incorporates the changes made by Ryzer. I chose kernel version 6.15 and did get an HDMI output on a Dell 21,5" monitor. So I managed to configure the pcduino2 for its purpose and I am using it again after many years. Excellent! Thank you so much for all your efforts! Great to be back as an Armbian user. Just as a side note: I was first trying with my Dell UltraSharp 34" monitor and there the HDMI output still does not work. I does work with the old Armbian 5.38 version for pcduino2 from the archives and also with Raspberry Pi 3 using a recent version of Raspberry Pi OS. Anyway, this is just for information. I do not think it is worth investigating this issue.

Something like git clone https://github.com/armbian/build.git -b main cd build git remote add -f imx8mp-build https://github.com/OLIMEX/imx8mp-build.git git remote update git fetch origin git fetch imx8mp-build git checkout main git rebase imx8mp-build/bookworm # fix conflict vi VERSION git add VERSION git rebase --continue # fix conflict vi .github/dependabot.yml git add .github/dependabot.yml git rebase --continue git log

They certainly did fork armbian, apparently at tag v24.11.1 AKA dd379da888f7d114f9f954d94a7ebcf261d179e5 $ git merge-base dd379da888f7d114f9f954d94a7ebcf261d179e5 main 017549347bb8c278a067d1be14c2f1b3538690c2 Add the Olimex repo as a remote and then rebase the latest armbian/build HEAD to their HEAD.

Following is the output of "mount|grep ro" root@rock-5-itx:~# mount|grep ro proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) /dev/sda2 on / type ext4 (ro,relatime) cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=19056) ramfs on /run/credentials/systemd-resolved.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/systemd-networkd.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime) ramfs on /run/credentials/systemd-journald.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/getty@tty1.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) ramfs on /run/credentials/serial-getty@ttyFIQ0.service type ramfs (ro,nosuid,nodev,noexec,relatime,nosymfollow,mode=700) Following is the output of "lsblk" root@rock-5-itx:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 7.5G 0 disk ├─sda1 8:1 1 256M 0 part /boot/efi ├─sda2 8:2 1 7.2G 0 part / └─sda3 8:3 1 8M 0 part sdb 8:16 0 465.8G 0 disk ├─sdb1 8:17 0 1M 0 part ├─sdb2 8:18 0 512M 0 part ├─sdb3 8:19 0 16G 0 part └─sdb4 8:20 0 449.3G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk0 179:0 0 29.1G 0 disk mmcblk0boot0 179:32 0 4M 1 disk mmcblk0boot1 179:64 0 4M 1 disk zram0 253:0 0 11.6G 0 disk [SWAP] zram1 253:1 0 50M 0 disk zram2 253:2 0 0B 0 disk nvme0n1 259:0 0 1.9T 0 disk ├─nvme0n1p1 259:1 0 1G 0 part └─nvme0n1p2 259:2 0 1.9T 0 part

I uploaded an updated version of the package bundle, with MPV and a few other updates that I found laying around: https://mega.nz/file/ZmwDBL6b#pGgXVRnoC0jU6dwFJebBcLDXyTNqdkmw3qvsOLz5qUI

@Dann https://dl.armbian.com/rock-5b-plus/Noble_vendor_gnome verifies fine for me. Try https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz and https://netcup-03.armbian.com/dl/rock-5b-plus/archive/Armbian_25.5.1_Rock-5b-plus_noble_vendor_6.1.115_gnome_desktop.img.xz.sha

An update. I suspect that the issue (or at least 1 issue) is a regression in the handling of MMC (SD card driver in the kernel). I suspect this is a regression as this issue did not hit me on earlier builds. I set up a netconsole, and received the following stack trace: [ 216.236507] I/O error, dev mmcblk0, sector 849688 op 0x0:(READ) flags 0x84700 phys_seg 1 prio class 2 [ 216.524566] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131108 starting block 323201) [ 216.534718] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131109 starting block 323202) [ 216.544920] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131110 starting block 323203) [ 216.560591] EXT4-fs warning (device mmcblk0p2): ext4_end_bio:353: I/O error 10 writing to inode 131111 starting block 323204) [ 216.575914] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131108, error -5) [ 216.587187] Buffer I/O error on device mmcblk0p2, logical block 270977 [ 216.601434] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131109, error -5) [ 216.601564] ------------[ cut here ]------------ [ 216.608348] Buffer I/O error on device mmcblk0p2, logical block 270978 [ 216.608383] WARNING: CPU: 0 PID: 129 at drivers/mmc/host/meson-mx-sdio.c:446 meson_mx_mmc_irq_thread+0x168/0x174 [ 216.608467] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131110, error -5) [ 216.608485] Buffer I/O error on device mmcblk0p2, logical block 270979 [ 216.612894] Modules linked in: rpcsec_gss_krb5 [ 216.619667] EXT4-fs (mmcblk0p2): failed to convert unwritten extents to written extents -- potential data loss! (inode 131111, error -5) [ 216.629626] auth_rpcgss [ 216.629674] Buffer I/O error on device mmcblk0p2, logical block 270980 [ 216.629700] zram [ 216.632164] Aborting journal on device mmcblk0p2-8. [ 216.641941] zsmalloc [ 216.642033] JBD2: I/O error when updating journal superblock for mmcblk0p2-8. [ 216.648457] binfmt_misc [ 216.676718] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1639: inode #598: comm dpkg-reconfigur: reading directory lblock 0 [ 216.680959] evdev [ 216.681075] EXT4-fs (mmcblk0p2): I/O error while writing superblock [ 216.683223] snd_soc_meson_aiu snd_soc_meson_gx_sound_card snd_soc_hdmi_codec snd_soc_meson_card_utils snd_soc_meson_codec_glue snd_soc_core snd_pcm meson_ir snd_timer rc_core [ 216.683268] EXT4-fs (mmcblk0p2): Remounting filesystem read-only [ 216.683278] thermal_generic_adc snd meson_saradc soundcore cfg80211 rfkill efi_pstore pstore netconsole [ 216.744185] CPU: 0 UID: 0 PID: 129 Comm: irq/35-c1108c20 Not tainted 6.12.47-current-meson #3 [ 216.744207] Hardware name: Amlogic Meson platform [ 216.744212] Call trace: [ 216.744225] unwind_backtrace from show_stack+0x10/0x14 [ 216.744259] show_stack from dump_stack_lvl+0x50/0x64 [ 216.744275] dump_stack_lvl from __warn+0x80/0x11c [ 216.744294] __warn from warn_slowpath_fmt+0x17c/0x188 [ 216.744311] warn_slowpath_fmt from meson_mx_mmc_irq_thread+0x168/0x174 [ 216.744337] meson_mx_mmc_irq_thread from irq_thread_fn+0x1c/0x7c [ 216.744364] irq_thread_fn from irq_thread+0x134/0x224 [ 216.744378] irq_thread from kthread+0xe0/0xfc [ 216.744396] kthread from ret_from_fork+0x14/0x28 [ 216.744411] Exception stack(0xf1075fb0 to 0xf1075ff8) [ 216.744420] 5fa0: 00000000 00000000 00000000 00000000 [ 216.744428] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 216.744435] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 216.744458] ---[ end trace 0000000000000000 ]--- [ 217.163204] mmc0: new high speed SDHC card at address 0002 [ 217.163907] mmcblk0: mmc0:0002 Which suggests the SD card was connected and disconnected. I have already ruled out faulty SD card (happens on any SD card I use, as well as a thorough stress test on the current card prior to use). Further research tells me "The Amlogic Meson8b (S805) SoC’s MMC controller has known quirks." I switched to USB rootfs (external HDD), and I still get the same failure, but as it is just the boot partition being unmounted and remounted the system remains up. Ideally I would propose a patch to fix this, but I am not a kernel developer, and the changes between 3.10 and 6.12 are huge (as to be expected) so identifying what is required and where is non-trivial for me. For now, I am sticking with rootfs on USB as my interim fix, but I am going to keep netconsole up and monitor over the next couple of weeks to see if we hit another issue (when I tested this in the past, I was also getting failures with rootfs on an external USB stick, so I am not convinced I am completely out of the woods yet).