I have a recently commissioned Radxa Rock-5B that I use as my PXE host. It has a number of iso images that are loopback mounted on directories like /var/www/html/mirrors/Fedora-44. I recently attempted an install of Fedora 44 on a VM and it crashed, complaining that it was unable to download a package from /var/www/html/mirrors/Fedora-44/Packages/p/parted-3.6-14.fc44.x86_64.rpm. I checked the directory on the Rock-5B and it was indeed missing but it was also giving me a lot of  output that looked like 

 

-r--r--r-- 1 root root   264876 Feb  2  2026 policycoreutils-3.10-1.fc44.x86_64.rpm
?????????? ? ?    ?           ?            ? policycoreutils-newrole-3.10-1.fc44.x86_64.rpm
all files from here are the same ???

 

I checked the sha256sum of the Fedora 44 iso against the one published on the website and it matches. I renamed the file and downloaded a fresh copy, just in case, same size, same sha256sum, same errors. I rebooted the Rock-5B to see if it was a transient problem but it was still broken on reboot. I copied the iso file to a different system running an older kernel and mounted it there and the content was correct and there were no errors and more importantly the parted-3.6 rpm file it complained about was present. I removed linux-image-bleedingedge-rockchip64 and rebooted into Linux rock-5b 6.18.53-current-rockchip64 and the problem was gone. 

 

It seems something about loopback mounting iso images is broken in 7.3.0-rc4. I have not tried a more recent bleedingedge version yet.

bleedingedge is not meant to be used as end-user but for developers only.

Use "current" if you prefer stability over breakage.

I was using 7.3.0 as it fixes the scheduler bug. I figured someone would want to know it was broken.

I think it is probably this https://lore.kernel.org/lkml/20260922054853.469681-1-matthias.goergens@gmail.com/

I get this:

root@rock5b:/local/s0/tmp# uname -a 
Linux rock5b 7.3.0-rc5-bleedingedge-rockchip64 #1 SMP PREEMPT Sun Sep 27 20:55:01 UTC 2026 aarch64 GNU/Linux
root@rock5b:/local/s0/tmp# losetup 
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                                   DIO LOG-SEC
/dev/loop0         0      0         0  0 /local/s0/tmp/debian-13.7.0-amd64-DVD-1.iso   0     512
root@rock5b:/local/s0/tmp# mount | grep loop0
/dev/loop0 on /local/s0/tmp/1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)
root@rock5b:/local/s0/tmp# find 1 | wc
   9461    9461  428610

So seems OK.

 

EDIT:

Now also looking into https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/fs/isofs/namei.c?h=v7.3-rc5I see this rc5 has the fix, so no surprise I can't reproduce.

Edited October 9Oct 9 by eselarm

Thanks for confirming it's fixed in a later version already. I see other problems being reported with rc6 so I'll stick with the older 6.18 for now, probably until 7.3.0 is released as current upstream.

Great that you found the report. Luckily it is 'high-level' SW issue, not a complex HW issue, like power or clocking w.r.t. devicetree etc. If you want to use very latest kernel, for many things running it in a VM works great. I cloned the Armbian installation from my NanoPi-R6C eMMC into a 16G .raw image file I think about almost 2 years ago and still use that to try 'risky' things, on the NanoPi-R6C itself, of course generic bootloader, but kernel can still be rockchip64. Even amazing that host runs rockchip64 4k pages bleedingedge while guest Armbian Trixie with Debian Sid 16k pages kernel.

 

What also works is let the ROCK5B use 6.1.115, so all HW video encoders at 8Kp60 speed available etc and then CPU-pin a VM at 0-3 to have a sort of quad-core C-A55 or 4-7 to have fast C-A76 engine. So as KVM then for example 8G RAM vanilla Debian Trixie (6.12 distro kernel) using 8T HDD block storage provided by the ROCK5B via LVM/LUKS. Although there it gets tricky as LVM caching needs manual options for blocksizes, so currently 16k pages is a showstopper or needs partial recreating the storage objects, something to think about carefully and emulate/simulate before real HW.

The 7.3.0 kernel fixes another problem I reported where the RK3588 only uses 7 cores out of 8 under heavy load which is why I installed it (first on rc3 then updated to rc4). I did notice that on upgrade from rc3 to rc4 the network performance dropped slightly but not enough to bother about. But iso9660 being broken is more problematic when this is my PXE host with loads of iso images on it so I can boot what I choose. I don't care about graphics as this is a headless box. ISO corruption is more annoying than a maximum 87.5% cpu usage so I'll go back to the -current- series for now. I'll wait for Linus to release 7.3.0 before I try again as it seems like a good choice since it's quite likely to be the next LTS candidate.