ライブのUbuntuCDからシステムを起動しましたが、パッケージの問題を修正する必要があります。ハードドライブをマウントしました。今度は、通常どおりに起動したかのようにapt-getを実行します。つまり、apt-getの作業ディレクトリを変更して、ハードドライブで機能するようにします。以前にこれを行ったことがありますが、構文を思い出せません。私はそれがこのようないくつかの旗に過ぎなかったと思います：
apt-get --root-directory=/mnt/partition1 install....
しかし、「コマンドラインオプション...理解できません」しか表示されません。何か案は？
また、これは機能するはずです：
sudo apt-get -o Dir=/media/partitioni1 update
chroot / mnt / partition1
システムが複数のディスクパーティションを使用している場合、パッケージシステムを機能させるためにそれらのいくつかをマウントする必要がある場合があります（ハードディスクが生の物理バックアップに対して大きくなり始めた10年前に複数のパーティションのセットアップを停止しました）。
その場所に使用可能なDebianシステムがまだない場合、これは機能しません。– akostadinov
chrooting時にパッケージシステムを機能させることができない場合は、おそらくそれはめちゃくちゃになっていて、二度と信頼することはできません。私の経験では、パッケージシステムを復活させる努力が報われることはめったにありません。その場合でも、HDにアクセスし、データをバックアップして、クリーンな再インストールを実行できることを嬉しく思います。
他の回答からのいくつかの関連するコメント：
apt-get -o RootDir = / tmp / test_aptは、（ほぼ）すべてのパスを別のルートに設定します。実行中のシステムで、/ etc / apt、/ usr / lib / apt、およびmkdir -p usr/libなどをコピーした場合apt / archives/partialそして最後にvar/lib / dpkg / statusにタッチすると、aptはそのルートで動作します。オプション-oDebug:: NoLocking = 1を追加すると、root以外のユーザーとしても機能します。別のルートディレクトリ内にロックファイルを設定する方法が見つからなかったため、nolockオプションが必要です。– akostadinov
作業とは、パッケージの検索とダウンロード、およびそのような操作を使用することを意味します。いくつかの重要なパッケージがまだそこにない場合、実際にインストールすることはできません。debootstrapは、何らかの理由で実際に新しいルートにパッケージをインストールすることが目標である場合に役立ちます。– akostadinov
実行chroot /mnt/partition1すると、ファイルシステムのルートがである新しいシェルが開始されます/mnt/partition1。ハードドライブ上のがまだ正しく機能していると仮定すると、apt-getそこから続行できます。
dpkg --root=/mnt/partition1 -i mypackage.debchrootは必要ありませんが、パッケージを自分でダウンロードする必要があるオプションです。