On a computer I've been working on trying to get going for a LONG time now and still have not completely managed to do so, I tried the following, based on a suggestion from here:
How to copy-merge two directories?
as part of trying to merge a driver tree into the Linux system folders:
rsync -aP ./ /
where the current directory contains some etc
, bin
, etc. folders and I was hoping that, given this is mentioned as how you merge directories, it would just merge in the drivers and configs from those into the main system so I didn't have to painfully mkdir
and cp
from every little subdirectory. It ran, and seemed OK. then I typed ls
as usual to check the effects and got the dreaded
sh: ls: not found.
OOPS.
Now this "system", actually an attempt to load and get Ubuntu 20.04 working, was actually being babysit via a chroot
from an Android master install on the same machine, and I used the inner rsync
to do the merge - not sure if that is part of what happened. But weirdly, after exiting the chroot
and doing a ls
(now running Android's ls
) on the /bin
now as just a normal subdirectory, ls was still there! As was pretty much everything else you'd expect. But oddly now, I can't chroot
into it again, as the chroot
fails with
chroot: exec /bin/sh: No such file or directory
even though from outside the chroot
, I can clearly see /bin/sh
sitting there. But even weirder, though, is when I try to execute that ls
from outside the chroot
- note here I have the rootfs in question mounted on /mnt/hdd0
:
127|rk3588_firefly_itx_3588j:/mnt # hdd0/bin/sh
/system/bin/sh: hdd0/bin/sh: No such file or directory
And ls hdd0/bin/sh
:
rk3588_firefly_itx_3588j:/mnt # ls -l hdd0/bin/sh
lrwxrwxrwx 1 root root 4 2022-11-28 09:04 hdd0/bin/sh -> dash
What has happened to the file system?! Oh yeah by the way, yes dash
does exist:
rk3588_firefly_itx_3588j:/mnt # ls -l hdd0/bin/dash
-rwxr-xr-x 1 root root 137728 2019-07-18 18:15 hdd0/bin/dash
And yes, Android is okay; it was just the chroot
ed rootfs (which by the way is actually on an attached SSD, Android is on the board eMMC) that went sour. Oh yeah and note that this system, because it's still not road-ready, has no valuable data so this wasn't a big loss, but I'd like to see if I can recover the filesystem without reformatting the SSD and reloading. I did an e2fsck -f /dev/block/sda2
with some intriguing results:
rk3588_firefly_itx_3588j:/mnt # e2fsck -f /dev/block/sda2
e2fsck 1.45.4 (23-Sep-2019)
/dev/block/sda2: recovering journal
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
Free blocks count wrong (38957201, counted=38810171).
Fix<y>? y
yes
Free inodes count wrong (9920272, counted=9920042).
Fix<y>? yes
/dev/block/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/sda2: 16854/9936896 files (0.2% non-contiguous), 922966/39733137 blocks
Not sure what that "Free blocks count wrong" part implies or implied. But it did not cure the sick filesystem.
make menuconfig
on kv 5.15.30 (which is already considered "old" by Gentoo standards), I see 55 kernel configs directly pertaining to Rockchip support for things like Clock, PCIe, video (including a decoder driver), sound, ASoC support for boards using the RT5645/RT5650 codec or the MAX98090 codec, plus much more. If you get a chance, I would recommend trying out Gentoo's ARM64 Handbook with a current kernel and see. – B.Kaatz Nov 30 '22 at 02:20