1TB HDにFreeBSDをインストールしたimg(ddで作成)があります。
今回は小さいディスク(500GB)を使用する必要があります。もちろん、同じイメージを復元しようとしても機能しませんが、パーティションテーブルとMBRを手動で調整しようとしても、システムが起動しません。
私がしたこと:
ddを実行した後、MBRを調整するためにsfdiskに直接移動しましたセクターを終了し、partedを使用してパーティションを縮小し、境界を修正しました。
私の計算では、パーティションがセクター2048で始まるとすると、500GBのディスクの場合、終了セクターを976771120(合計976773168)に設定するのが正しいです。
その場合、新しいパーティションは2048-> 976771120になり、新しいMBRもこのロジックを使用します。実際、私はFreeBSDブートマネージャーの第1段階に到達できますが、その後、ブートプロンプトでスタックします(エラー66)。たぶん私は次のブートローダーステージがどのように機能するかを知らないでしょう、おそらくFreeBSDを起動させるためにパーティションスキームとMBRを修正するだけでは十分ではありませんか?どこかで早期に読み取られたconfファイルがあり、それも修正する必要がありますか?プライマリOSではないので、トライアル/エラープロセス中です。ありがとう
編集:出力を追加しました。写真は申し訳ありませんが、私の唯一の選択です。実際のデータが本当に少ない(<2GB)ことを覚えていませんでした。
最初のディスク、500GBスキーム(機能していません)。 2番目のディスク、1TBの元のスキーム(動作中)。
まず、問題が発生した場合に備えて、バックアップコピーが必要です。それが何であれ、使用するファイルシステム用のツールが必要です。
まず、使用するファイルシステムのパーティションを論理的に縮小するプログラムが必要です。私は以前にntfsとext3でそのようなことを数回行いましたが、考え方はすべてのファイルシステムで同じです。
イメージはパーティション(_sda1.img
_)のイメージであると想定します。ディスク全体(_sda.img
_)の場合は、パーティションのみを「抽出」するか、(イメージ全体)を物理ディスク(1TB +)に配置します。それに取り組みます。後で、作業内容を新しい500GBディスクにコピーします。その理由は、ディスク全体のイメージの場合のように、サイズ変更プログラムがオフセットパーティションをサポートしていない可能性があるためです。
_your old disk (sda):
+--------+----------------+---...
| mbr... | sda1 (system) | sda2...
+--------+----------------+---...
_
1. ntfsresize
/_tune2fs
_/_whatever-fs-resizer
_を使用して、パーティションファイルシステムを縮小します(_/dev/sda1
_(物理ディスク上)/ _sda1.img
_(イメージ内)) 。これにより、(パーティションの)イメージ内のファイルシステムのサイズが縮小されます
2.ファイルシステムが新しいパーティション(_/dev/sdb
_)に収まるように、サイズ変更されたシステムパーティションと追加のメガバイトに収まる新しい(500GB)ディスク(_/dev/sdb1
_)に新しいパーティションテーブルを作成します。それにfdisk/cfdisk/(g)parted/whatever-you-like
を使用します。 _/dev/sdb1
_を起動可能にすることを忘れないでください。
技術的には、必要な量を正確に計算できますが、心配する必要はありません。リサイザーは、ファイルシステムのサイズを(_/dev/sdb1
_で)変更して、パーティション全体を埋めることができるはずです(これは後で使用します)。
3.サイズ変更した_sda1.img
_を新しい宛先_/dev/sdb1
_にコピーします(dd
またはcat
も:_$ cat sda1.img > /dev/sdb1
_)
4.ニーズに合わせて他のパーティションを_/dev/sdb2|3|4...
_フォーマットします。
5.仕事を楽しんでください。
古き良き方法で解決したいと思います。
newfs /dev/ada1s1
mount /dev/ada1s1 /mnt
cd /mnt
dump -0a -f - /dev/ada0s1 | restore -rf -
gpart bootcode -b /boot/mbr -p /boot/boot1 ada1
これにより、新しいファイルシステムが作成され、マウントされて宛先ディレクトリに入ります。これは、復元がそこで機能する必要があるためです。従来のバックアップツール(UFSでは失敗することはありません)を使用してファイルシステム全体をコピーします。最後のコマンドはブートコードを書き込みます。
免責事項:いくつかのパラメータが間違っている場合、それはもちろん壊滅的であるため、常にコマンドを確認してください!!ここで何が行われているのかを理解する必要があります。
それは私には少しマゾヒスティックに思えます。
個人的には、バックアップのためにdd
を実行していました。それから私はそれを縮小し、それを移動しようとする前にそれが機能することを確認します(縮小->再起動->チェック->最終dd)。
500GB未満のデータがあると思います。しかし、それがディスク上でどのように構成されているかはわかりません。
次に、sfdisk
とparted
を使用してパーティションを変更しましたか?しかし、ファイルシステムを保護するために何をしましたか?パーティションを単純に変更しても、ファイルシステム内のデータが並べ替えられたり、切り捨てられたファイルシステムのレイアウトが管理されたりすることはありません。
したがって、不足しているのはファイルシステムの処理です。 FreeBSDでは、通常、UFSまたはZFSを使用します。 UFSについては、 growfs(8) を調べる必要があります( FreeBSDでのUFS/rootパーティションのサイズ変更 を参照)。 ZFSを使用している場合、ボリュームマネージャーとファイルシステムを組み合わせたものであるため、すべてがまったく異なるボールゲームです。
したがって、直接の質問に答えられるようにするには、多くの追加情報が必要です。ただし、データにアクセスする方法に関する暗黙の質問ははるかに簡単です。新しいディスクにベアで起動可能なFreeBSDインストールをセットアップします。次に、データをコピーします。
ディスクのddイメージがある場合は、それをマウントできます。別のシステムでそれを行うか、ポータブルUSBディスク/ネットワークドライブを持っています。
したがって、/dev/ada0
の完全な元のコピーをada0.dd
として持っている場合は、イメージを仮想メモリディスクとして使用できます。
# mdconfig -a -t vnode -u 0 -f /home/realpclaudio/ada0.dd
これにより、/dev/md0
が得られます。これがフルディスクになります。
その後、すべてが良好に見えることを確認できます。
# fdisk /dev/md0
これは、古いディスクとまったく同じように見えるはずです。その後、データの確認を開始できますが、これはファイルシステムによって異なります。
UFSファイルシステムをディスクにマウントします。
# mount -t ufs -o ro /dev/md0s1a /mnt
これは、おそらく最初のスライスのルートファイルシステムです。さらにスライスがある場合は、それらをマウントすることもできます。
# mount -t ufs -o ro /dev/md0s1e /mnt/var
# mount -t ufs -o ro /dev/md0s1g /mnt/home
ZFSを使用している場合は、ZFSツールを使用してディスクを管理できます( zpool Administration を参照)。
# zpool import -o altroot=/mnt mypool
# zfs list