リモートUbuntuサーバーからデスクトップからインストールするために一連のアップグレード/変更を実行しました。Ubuntu 10.10はユニークですサーバーへのインストール12.04 LTS 正確
いくつかの問題を除いて、すべてがうまくいっており、これまで物理的なアプローチは不可能でした。次の目標は、LVMをバックエンドストレージとして使用してXENサーバーを作成することです。システムにLVMがありません。 12.04 LTSに達した後にLVMを追加しました。 XENマシンでリモートで作成する方法を知っており、以前も試したことがあります。しかし、新しい設定を開始する際に問題があります。
この箱を設置した人は、パーティショニングに注意を払っていないことがわかりました。システムはサーバーとして使用されましたが、デスクトップとしてインストールされましたが（この問題を解決しました）、次のパーティション化スキームが残りました。
Disk /dev/sda: 500.0 GB, 499999834112 bytes
...
Device Boot Start End Blocks Id System
/dev/sda1 * 1 58558 470361088 83 Linux
/dev/sda2 58558 60789 17916929 5 Extended
/dev/sda5 58558 60789 17916928 82 Linux swap / Solaris
そのため、巨大な17Gスワップパーティションを新しいブートパーティション（現在の/dev/sda2）、小さなスワップパーティション（/dev/sda3）、および新しいルートパーティション（lvs）に再構成しました。ディスク使用量を十分に小さい3GB程度に下げ、LVMの下に作成した新しいルートディレクトリにコピーしました。
現在、
Device Boot Start End Blocks Id System
/dev/sda1 2048 940724223 470361088 83 Linux
/dev/sda2 * 940724224 941748223 512000 83 Linux
/dev/sda3 941748224 943845375 1048576 82 Linux swap / Solaris
/dev/sda4 943845376 976562175 16358400 8e Linux LVM
/dev/sda1は古いブートパーティションマシンを/dev/sda2から起動したいです。違いは別々の/bootと/パーティションが必要であることです。ルートパーティションはLVMから呼び出されます。
# lvscan
ACTIVE '/dev/server20/root' [10.00 GiB] inherit
最後の目標は、/dev/sda1をLVM制御下に置きたいが、それを使用しない方法でシステムを起動する必要があることです。その時点からLVMが動作します。
上記のファイルシステム全体の変更に加えて、次の作業も行いました。
生成された論理ボリューム：
pvcreate /dev/sda4
vgcreate server20 /dev/sda4
lvcreate -L 10G -n root server20
mkfs.ext4 /dev/server20/root
インストールしてください：
mount /dev/server20/root /mnt/root/
mount /dev/sda2 /mnt/root/boot/
(cd / ; find . -xdev -print0 | rsync -xavz . /mnt/root/)
for i in /dev /run /dev/pts /proc /sys; do sudo mount -B $i /mnt/root$i; done
グラップアップデート：
chroot /mnt/root
echo "dm-mod" >> /etc/initramfs-tools/modules
echo "dm-mod" >> /etc/modules
grub-mkconfig (verified config file visually)
update-grub (no errors/warnings)
生成された/boot/grub/grub.cfgを確認しながら、ほとんどの内容が正しいことがわかりました。特に以下の内容がそうです。
insmod lvm
...
set root='(server20-root)'
search --no-floppy --fs-uuid --set=root 0bb92c24-8c02-4fa3-8f75-970076261b2f
...
menuentry 'Ubuntu, with Linux 3.2.0-38-generic' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
gfxmode $linux_gfx_mode
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root 891b3eaa-fb43-4a42-9789-a91c2a5ffb13
linux /vmlinuz-3.2.0-38-generic root=/dev/mapper/server20-root ro quiet
initrd /initrd.img-3.2.0-38-generic
}
...
その後、blkidを確認してください。
/dev/sda2: UUID="891b3eaa-fb43-4a42-9789-a91c2a5ffb13" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda4: UUID="IyDrfU-TOYT-rFXO-JknG-rwEK-Sm2A-mfKcIe" TYPE="LVM2_member"
/dev/mapper/server20-root: UUID="0bb92c24-8c02-4fa3-8f75-970076261b2f" TYPE="ext4"
/dev/sda1: UUID="888c061a-1d51-4516-aced-4bb21042d2f4" TYPE="ext4"
/dev/sda3: UUID="19efc041-eccd-42c9-94aa-5b6c88ffd5bb" TYPE="swap"
だから私がここで学んだのは、私のブートパーティションがmsdos2、つまり/ dev / sda2になるということです。 uuid は検索行でも参照されます。たとえルートと呼ばれていますが、他の設置と比較しました。これは、ルート/ブート分離がブートuuidであることを意味します（正しい仮定？）。
リンクされたディスクレイアウトを使って再起動できると思いましたが、そうではありません。 fdiskを使用して/dev/sda1および/dev/sda2ブート可能フラグを有効にしました。以前と同じように始まり、幸いなことに問題は発生しませんでした。
私のより深い問題は、chroot + update-grubの誤解によって引き起こされる可能性があります。実際、root / boot / dev / sda1で何をすべきかわかりません。 chrootバージョンのgrub.cfgを/ bootサブディレクトリにコピーする必要がありますか？
再起動後に実行した手順
switched off bootable flag on /dev/sda1
remounted everything again and performed all steps again plus an additional
grub-install /dev/sda (from the chroot)
/dev/sda1を無視しても十分ですか？ grubに関するすべての内容を読みましたが、同じディスクに2つのブートパーティションがあるときにブートプロセスがどのように機能するかについての答えを得ることはできません。 （他の場合も多い）grub-install --boot-directory=/mnt/boot。内部的にはどのように処理されますか？
この質問についてより良いタイトルを提案してください。私はこの質問が本当にひどいです。
また、これはMBRです。
dd if=/dev/sda of=mbr.bin bs=512 count=1
root@server20:/# file mbr.bin
mbr.bin: x86 boot sector;
partition 1: ID=0x83, starthead 32, startsector 2048, 940722176 sectors;
partition 2: ID=0x83, active, starthead 95, startsector 940724224, 1024000 sectors;
partition 3: ID=0x82, starthead 29, startsector 941748224, 2097152 sectors;
partition 4: ID=0x8e, starthead 167, startsector 943845376, 32716800 sectors, code offset 0x63
ベストアンサー1
再起動しようとしましたが、最後の手順3で問題が解決したようです。
using fdisk to switch off bootable flag for /dev/sda1
partprobe so the kernel knows about changes
remounted everything again on top of root at /mnt/root and performed:
grub-install /dev/sda (from the chroot)
update-grub
MBRダンプを見ると、今回は効果があったと信じられます。 LVMルートの使用を開始しました。ブートパーティションをマウントできなかったようですが、システムはマウントに成功しました。小さい/dev/sda1に戻り、同じプロセスを実行する必要がありました。