PSL

I tried to replicate this issue on i686 box running Debian Bookworm and it works there, no problem. 1) Create file for disk, 50GB # dd if=/dev/zero of=xfstest.bin bs=1M count=50000 2) Format disk with XFS # mkfs.xfs xfstest.bin 3) show XFS details # xfs_info xfstest.bin meta-data=/dev/loop0 isize=512 agcount=4, agsize=3276800 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 nrext64=0 data = bsize=4096 blocks=13107200, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=16384, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 4) mount FS, no issue here! # mount -o loop xfstest.bin /srv # # mount | grep xfs /root/xfstest.bin on /srv type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota) 5) check dmesg # dmesg | grep XFS [2992759.600513] SGI XFS with ACLs, security attributes, realtime, quota, no debug enabled [2992759.618175] XFS (loop0): Mounting V5 Filesystem [2992759.649994] XFS (loop0): Ending clean mount 6) system info, kernel is 6.1.0 # uname -a Linux worm 6.1.0-12-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1 (2023-09-07) i686 GNU/Linux # # dpkg -l | grep xfsprogs ii xfsprogs 6.1.0-1 i386 Utilities for managing the XFS filesystem So, I assume that issue is really the kernel 5.x that is delivered with Armbian for Odroid XU4 (HC1/HC2)...

Maybe kernel is old, it is 5.4 in this build. Other builds of Armbian have kernel 6.1.53 (like OrangePi ZERO or NanoPI NEO)...

I installed "Armbian 23.8.3 bookworm" to Odroid HC1. Installation was OK, it boots. Armbian is installed on microSDHC card. I wanted to format SATA drive with XFS but I cannot mount it. 1) I installed xfsprogs (apt install xfsprogs) $ dpkg -la | grep xfs ii xfsprogs 6.1.0-1 armhf Utilities for managing the XFS filesystem 2) I created GPT partition table on SATA drive and I created one partition, /dev/sdb1 # fdisk -l /dev/sdb Disk /dev/sdb: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: Generic Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: EF0AF689-AAD7-C443-B5AE-03EFFC99E02D Device Start End Sectors Size Type /dev/sdb1 2048 3907028991 3907026944 1.8T Linux filesystem 3) I formated partition with xfs: # mkfs.xfs /dev/sdb1 4) I checked partition with xfs_repair, no issues # xfs_repair /dev/sdb1 5) Info about filesystem: # xfs_info /dev/sdb1 meta-data=/dev/sdb1 isize=512 agcount=4, agsize=122094592 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 nrext64=0 data = bsize=4096 blocks=488378368, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=238466, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 6) The issue, I cannot mount the partition: # mount /dev/sdb1 /srv/ mount: /srv: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. # dmesg |grep XFS [ 7578.496569] SGI XFS with ACLs, security attributes, realtime, no debug enabled ... [ 7578.525167] XFS (sdb1): Superblock has unknown read-only compatible features (0x8) enabled. [ 7578.525175] XFS (sdb1): Attempted to mount read-only compatible filesystem read-write. [ 7578.525180] XFS (sdb1): Filesystem can only be safely mounted read only. [ 7578.525201] XFS (sdb1): SB validate failed with error -22. # uname -a Linux hc1 5.4.253-current-odroidxu4 #2 SMP PREEMPT Mon Aug 14 01:33:04 UTC 2023 armv7l GNU/Linux Any idea what is broken? Is it kernel??

I retested Android on eMMC, Nougat and Oreo and I cannot find any evidence that they modified firmware on Le Potato board. Application AIDA64 on Android reports that board is LePotato, no trace about Z28 PRO. I used better power supply today and I do not have problems with Android on eMMC, so the problems I had the last time and those looked like a problem with video driver were caused by weak power supply; Android Nougat runs from eMMC module in similar way like it runs from good microSDHC. I was able to test even Android Oreo but it has problem to exit application and return to home screen, I cannot do that with mouse. That is problem of user interface; I do not like that build... I tried to install fresh Armbian to LePotato board and it identifies as LePotato. I think that "Z28 PRO" id was a problem of Armbian, I probbably used different installation image file. Information about "Z28 PRO" is stored in several files in /etc directory, like /etc/armbian.txt

I just noticed that my Le Potato board identifies as "Z28 PRO". It is just a cosmetic problem but from a screenshot in this thread I see that it could be a bug... This is welcome message that I see when I connect with ssh client to the Le Potato board: _________ ___ ____ ____ ___ |__ /___ \( _ ) | _ \| _ \ / _ \ / / __) / _ \ | |_) | |_) | | | | / /_ / __/ (_) | | __/| _ <| |_| | /____|_____\___/ |_| |_| \_\\___/ Welcome to Armbian 20.08.7 Focal with Linux 5.8.13-meson64 No end-user support: community creations I have two LePotato boards. I just found that other one identifies as "Lepotato" and the message about end-user support is missing. I installed Armbian to these boards two weeks ago and I do not remember all details. I assume that I used the same install image for both boards but maybe I used different one (newer?), I am not sure. One of these boards had no HDMI output so I thought it was broken and I was not used it for several days, I used other board for experiments with Android. Once HDMI output was fixed (was it fixed by Android image?? I am not sure how I fixed it...) Once I have found that I do not like Android build (running from microSDHC card), I converted both boards to Armbian. I cannot explain how I installed "Z28 PRO" version to one of my boards but I see it is there... I used one board to experiment with eMMC module during weekend, I tried to run Android from eMMC but that was really not good so I removed eMMC module and I am back at Armbian that runs from microSDHC card. Maybe that Android modified some internal storage memory on LePotato board (in similar way how it fixed broken HDMI), that is the best explanation I have... I installed Android to eMMC module with some Amlogic tool running on Windows (USB A-A cable is connected to LePotato board with eMMC module). I tried Android 6.x and 7.x, version 6.x was working but it was slow and not reliable (some problem with video driver or eMMC driver??), version 7.x was not working at all... This is what I see on LePotato board that runs Armbian for two weeks (no experiments with Android on eMMC module): _ _ _ | | ___ _ __ ___ | |_ __ _| |_ ___ | | / _ \ | '_ \ / _ \| __/ _` | __/ _ \ | |__| __/ | |_) | (_) | || (_| | || (_) | |_____\___| | .__/ \___/ \__\__,_|\__\___/ |_| Welcome to Armbian 20.08.7 Focal with Linux 5.8.13-meson64 I am sorry, I put wrong information about Android versions in the previous post. I cannot fix that because I cannot edit that post anymore. I do not like this feature of this forum, I cannot fix my mistakes when I do not find those in just few minutes.... :-( So, Android 7.x (Nougat) running from eMMC module was working but had some serious problem with video driver or eMMC driver (whenever I moved mouse, screen lost synchronization and image was black for few seconds). Android 8.x (Oreo) was not working from eMMC module at all (just blank screen). I have 8GB eMMC module from Libre Computer (because no other eMMC module is compatible with Libre Computer board; I write this note because I was not aware about this fact and I hoped I could use eMMC module for Odroid boards (ODROID C2) but these have different connectors...).

I have two Le Potato boards (http://ix.io/2ykP http://ix.io/2ykN), I installed Armbian Focal on them. One of the board has defective HDMI (board from Kickstarter?), it has no HDMI output. Other board was ordered from Amazon, a year later. It has HDMI output but colors are not right (white is green, black is purple, etc, HDMI image is not nice but it is usable; it is interesting that when I use HDMI to VGA adapter, colors are right; when board runs in low resolution, colors are right on HDMI too. But when resolution is high, 1950x1200, then HDMI colors are wrong - I swapped HDMI cable without any effect - is this known video driver issue??). So because only one board have working HDMI, I used that board with working HDMI to install Armbian to microSDHC card and then moved microSDHC to the other board (that is working but HDMI is broken). In few minutes I noted that both boards have the same MAC address (Ethernet). I have found that the MAC address in file /boot/armbianEnv.txt is unique for each board but they have the same MAC address 96:93:89:FF:90:C3 (and that MAC address is not in file armbianEnv.txt). Is this a bug? I fixed that by editing "/etc/NetworkManager/system-connections/Wired connection 1.nmconnection", I replaced MAC address "96:93:89:FF:90:C3" with address from armbianEnv.txt. After reboot each board has unique MAC address (and gets different IP address from local DHCP server).

It is possible but ARMBIAN doesn't support this :-( (status of 2020-09) Ubuntu on Odroid C2 or ARM instances runing Ubuntu in Amazon AWS cloud support that. This is the trick: sudo dpkg --add-architecture armhf sudo apt-get update sudo apt-get install libc6:armhf libstdc++6:armhf Problem is that Armbian doesn't support armhf architecture (no packages in the repository). Well that is just one part of the problem. Other part is that ARM CPU has to support "armhf" instructions. Most of these low end CPUs used on SBCs support "armhf" but there are ARM chips for datacentres those support only "aach64". I am not sure but I think that kernel should should have support for "armhf" too. This topic is often discussed in Boinc community because most Boinc projects supports only "armhf" and have no tasks for "aarch64". It is interesting, it is 2020 and there are many arm64 computers in the world, arm64 code delivers better performance than "armhf" but Boinc projects ignore "arm64". Maybe it is because Raspbian for RPI was 32-bit OS and most SBCs in the World are RPI computers. On the other side, most devices running Android are 32-bit too. From my point of view, it is an issue that Armbian doesn't support "armhf" architecture.