Why did rsync hose my root file system when trying to merge in drivers?

Question

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 chrooted 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.

Answer 1

Well,

Looking at the command you show, you asked to copy everything from the folder you are/were to the root of the filesystem, recursively, in archive mode, with a progress bar and keeping partially-transferred files in the destination. If you had a bin directory under the directory you started in, then you copied a bin directory over another bin directory... And, if any of the files in the original bin directory had the same name as the files in the destination, the extant files in the destination got overwritten.

What directory were you in when you issued the rsync command? I wonder if you just copied part of the Android filesystem to the root of the linux drive. Remember that while Android uses the linux kernel, it is not compatible with most server/desktop/laptop linux systems. The architectures between the two are completely different (e.g. "x86[_64]" vs "arm[64]"). You can't take a module from Android, move it to a PC and expect it to work, generally.

From the output of trying to chroot, it does seem like you have corrupted the linux system, but that isn't that much of an issue. I would recommend just running the Ubuntu install script and point it directly at the sda/linux drive for install.

Lastly, the "Free blocks count wrong" message just means that when e2fsck ran, it saw some entries saying that certain blocks and inodes were supposed to be in use, but couldn't find anything using them so it re-added them to the Free list.

I hope that helps.