ドライバをマージしようとしたときにrsyncが私のルートファイルシステムをホースに接続するのはなぜですか?

ドライバをマージしようとしたときにrsyncが私のルートファイルシステムをホースに接続するのはなぜですか?

コンピュータで長い間試してみたがまだ理解していない場合は、ここにある提案に基づいて次のことを試しました。

2つのディレクトリをコピーしてマージする方法は?

ドライバツリーをLinuxシステムフォルダにマージする試みの一環として:

rsync -aP ./ /

現在のディレクトリにはいくつかなどのフォルダが含まれています。etcこれがディレクトリをマージする方法を考えると、ドライバと設定を基本システムにマージして、それぞれの小さなサブディレクトリに苦しむ必要がないことを願っていますbin。実行され、かなりよさそうだ。その後、効果を確認するためにいつものように入力し、ひどい結果が出ました。mkdircpls

sh: ls: not found.

こんな。

これで、実際にUbuntu 20.04をロードして動作させようとしているこの「システム」は、内部的にマージするために使用するのと同じコンピュータのネイティブchrootAndroidインストールを介して実際にホストされますrsync。何が起こっているのかわからない。ところで奇妙な点はchrootls(現在Android実行中ls)を終了し、通常の/binサブディレクトリとして実行した後、まだそこにいます!ほとんどすべてから期待できるように。しかし、奇妙なことは今私ですできない chrootchroot失敗して再入力してください

chroot: exec /bin/sh: No such file or directory

外でも私がどこに座っているのかchrootはっきりわかった。しかし、もっと奇妙なことは/bin/sh私ですls外部-chroot問題のrootfsが次の場所にインストールされています/mnt/hdd0

127|rk3588_firefly_itx_3588j:/mnt # hdd0/bin/sh
/system/bin/sh: hdd0/bin/sh: No such file or directory

そして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

ファイルシステムで何が起こりましたか? !ああ、はい、そうdashです。存在します。

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

はい、Androidは大丈夫です。chrooted rootfs(実際に接続されたSSDにあり、AndroidはオンボードeMMCにあります)が問題です。ああ、はい、このシステムはまだ走行準備ができていないので貴重なデータがないので大きな損失ではありませんが、SSDを再フォーマットして再フォーマットしなくてもできるかどうかを確認したいと思います。マウント中にファイルシステムを回復します。私はe2fsck -f /dev/block/sda2いくつかの興味深い結果を得ました。

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

「利用可能なブロック数エラー」の部分が何を意味するのか、それとも暗示しているのかはわかりません。しかし、やったいいえ病気のファイルシステムを治療します。

答え1

素晴らしい、

表示されるコマンドを見ると、進行状況バーを使用して現在のフォルダ内のすべてのアイテムをアーカイブモードのファイルシステムルートに再帰的にコピーし、部分的に転送されたファイルをターゲットに残すように要求しています。bin起動したディレクトリの下にディレクトリがある場合は、binあるディレクトリをbin別のディレクトリにコピーします。ソースディレクトリのファイルがターゲットのファイルと同じ名前でbinある場合は、そのディレクトリの現在のディレクトリAファイルのターゲットを上書きしました。

コマンドを実行したrsyncときにどのディレクトリにありましたか?私はAndroidファイルシステムの一部をLinuxドライブのルートにコピーしたのだろうか? AndroidはLinuxカーネルを使用しますが、ほとんどのサーバー/デスクトップ/ノートブックLinuxシステムと互換性がありません。 2つの間のアーキテクチャはまったく異なります(例:「x86 [_64]」と「arm [64]」)。一般的に言えば、AndroidからモジュールをインポートしてPCに移動して動作することを期待することはできません。

試みの結果によれば、chrootLinuxシステムが破損しているように見えますが、大きな問題ではありません。 Ubuntuインストールスクリプトを実行し、それをsda / linuxドライブに直接指定してインストールすることをお勧めします。

最後に、「空きブロック数エラー」メッセージは、実行時に特定のブロックとe2fsckinodeが使用中でなければならないことを示すいくつかの項目を見ましたが、それを使用している項目が見つからず、再び空きブロックに追加したことを意味します。リスト。

これが役に立つことを願っています。

関連情報