パーティション番号を増やす方法

質問

特定のパーティションに割り当てられる
/dev/sda3
などの番号を、たとえば
/dev/sda2
などに減らすのはそれより番号の若いパーティションを削除すればいいだけですが、
/dev/sda8
などに増やす方法はありますでしょうか？

パーティションをクローン化する時は
クローン元とクローン先のパーティション番号を一致させておかないと問題が起きるようですので、
これができると fsarchiver などでパーティションをクローン化する時に便利なのですが。

どうぞご教授下さい。
よろしくお願いします。

回答No.5

yakan9 · ベストアンサー

> つまり、sda10 の中のOSには
> 「このパーティションの HDD における物理的な番地は sda5 である」

以前のLinuxには、確かにデバイス名、/dev/sda5 とかが、絶対的なものでした。
しかし、今のLinuxは、こうした問題をなくすために、UUIDという、パーティションを作成した時に、ランダムに命名させたものを使うようになってきてます。
UUID　と　デバイス名の対応は、blkid コマンドで分かります。
だんだん問題が別な方になってきているような気がしますけど。

お礼

ありがとうございます。
また以前にやったことと同じことを試してみました。
/dev/sda1
を
/dev/sda2
にクローンした後に、/dev/sda2 から起動しました。

# mkdir /media/usb1
# mount /dev/sda1 /media/usb1
# mousepad /test.txt
# blkid
/dev/sda2: UUID="3f255835-0b37-4fc4-8b4e-28b12548c285" TYPE="ext3"
/dev/sda1: UUID="3f255835-0b37-4fc4-8b4e-28b12548c285" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb1: UUID="FEE9-0C16" TYPE="vfat"
# diff / /media/usb1
Common subdirectories: /bin and /media/usb1/bin
Common subdirectories: /boot and /media/usb1/boot
Common subdirectories: /dev and /media/usb1/dev
Common subdirectories: /etc and /media/usb1/etc
Common subdirectories: /home and /media/usb1/home
Common subdirectories: /lib and /media/usb1/lib
Common subdirectories: /lost+found and /media/usb1/lost+found
Common subdirectories: /media and /media/usb1/media
Common subdirectories: /mnt and /media/usb1/mnt
Common subdirectories: /opt and /media/usb1/opt
Common subdirectories: /proc and /media/usb1/proc
Common subdirectories: /root and /media/usb1/root
Common subdirectories: /run and /media/usb1/run
Common subdirectories: /sbin and /media/usb1/sbin
Common subdirectories: /selinux and /media/usb1/selinux
Common subdirectories: /srv and /media/usb1/srv
Common subdirectories: /sys and /media/usb1/sys
Only in /: test.txt
Common subdirectories: /tmp and /media/usb1/tmp
Common subdirectories: /usr and /media/usb1/usr
Common subdirectories: /var and /media/usb1/var

このように、UUID は一致したのです（これは少し気になります）が、
/（/dev/sda2）においてファイルを作成しても
/media/usb1（/dev/sda1）に影響は与えませんでした。
少なくともここで試した範囲では。
以前に起こったと思った現象はただの思い違い、ということであればいいのですが。

回答No.7

yakan9

回答番号６のお礼欄を見ましたが、
パーティションのクローンと言う意味では、UUIDのユニークな識別は無理と思います。
パーティションのクローンと言う概念を追及していくことになると、多分、いろんな矛盾が出ると思います。

一般にパーティションの中のデータが入っているファイルをコピーするということの意味、
パーティションをクローン化して保存することの意味には違いがあること。

この違いを理解しておくこと、
クローン化して保存したものを利用して、パーティションを復元して、全く同じパーティションを作成してしまった時の矛盾が発生してしまうことの危険性。

その時の対応、
論理的なコピーと言うのは、「パーティションの中のデータが入っているファイルをコピーする」
と言う、ファイルの中のデータを保証すること、

物理的なコピーと言うのは、「パーティションをクローン化して保存する」
と言う、パーティションそのものののコピーと言うことの違いを理解しておくことかと思います。

この違いの中には、パーティションの管理情報と言う情報を正しく保存しているか、していないかの違いです。

パーティションの管理情報と言うのは、パーティションの中のファイルやフォルダの個々の情報、
すなわち、ファイル名、ファイルサイズ、作成年月日、更新日等のファイルやフォルダの一般的な情報を言います。

お礼

長く質問におつきあいいただきありがとうございます。

ここで回答いただいた内容は
回答番号６のお礼欄のどの内容を受けてかかれたのかが
私にはすぐに分からなかったのですが
> fsarhiver でなく dd だったかもしれませんが、
> そうだとしてもおそらく本質に違いは出ないでしょうね。
dd だとそれぞれのiノードがパーティションのどの番地に存在しているのかということを
対応づけるのに問題を生じさせる、ということかなと昨日思いました。（少し違うのかもですね）
fsarchiver あたりであればここらへんはうまくやってくれるはずです。

それと、やっと UUID の安全な書き換えに成功しました。
まず、最初は自分が適当に手でいじった英数字を UUID に使おうとしておりまして、
これが問題だったようです。
正しくは、次のように uuid コマンドを使って生成された英数字を使わないといけないようです。
今回は /dev/sde2 を変更しようとしました。

$ uuid
e2839094-a24b-11e4-9d7a-782bcbf8ce66
$ sudo tune2fs -U e2839094-a24b-11e4-9d7a-782bcbf8ce66 /dev/sde2
tune2fs 1.42.5 (29-Jul-2012)

そうすると、
Bad magic number...
というようなメッセージは出ずに、tune2fs による UUID の書き換えが一段階終了です。
次に、/etc/fstab の中を

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=e2839094-a24b-11e4-9d7a-782bcbf8ce66 / ext3 errors=remount-ro 0 1
# swap was on /dev/sda2 during installation
#UUID=81b10569-db62-4ea0-8c06-eb3722d9d9ea none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

というように手で書き換えて
$ sudo grub-install --root-directory=/media/sde1 /dev/sde
$ sudo update-grub --output=/media/sde1/boot/grub/grub.cfg /dev/sde
を行なってから再起動しましたが、きちんと起動しませんでした。

そこで、再度別の debian から起動して
grub2 をインストールしてある /dev/sde1 の
/boot/grub/grub.cfg
の中身の /dev/sde2 に対応する部分を見てみると

menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(/dev/sdb,msdos1)'
search --no-floppy --fs-uuid --set=root eab9a456-542c-4f4b-868b-4d93cd350e72
echo 'Loading Linux 3.2.0-4-amd64 ...'
linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=3f255835-0b37-4fc4-8b4e-28b12548c285 ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-3.2.0-4-amd64
}

というように、
linux /boot/vmlinuz-3.2.0-4-amd64 root=UUID=
の後が古い UUID のままになっておりました。
ここも新しい UUID に書き換えてから再起動すると、めでたく新しい UUID の元で起動に成功しました。

もし、クローン化により作ったパーティションでこれから何か問題が発生しましたら、
報告も兼ねてまた質問投稿いたします。

回答No.6

yakan9

> このように、UUID は一致したのです（これは少し気になります）が、
確かに、パーティション固有のUUIDでないと意味はなくなりますが、
クローン操作をしたということで、一致しても仕方がないのかも知れません。

> /（/dev/sda2）においてファイルを作成しても
> /media/usb1（/dev/sda1）に影響は与えませんでした。
> 少なくともここで試した範囲では。
> 以前に起こったと思った現象はただの思い違い、ということであればいいのですが。
その通りだと思います。
今回の場合、クローン操作のために、UUIDが一致したということで、
クローン操作でない場合は、UUIDは、パーティション固有の番号が付加されると思われます。

お礼

ありがとうございます。
No.3 のお礼に書きました現象が起こったと思った時に使用しましたのは
fsarhiver でなく dd だったかもしれませんが、
そうだとしてもおそらく本質に違いは出ないでしょうね。

debian 7.8 ですが、念のために UUID の変更を試しているところです。

$ sudo tune2fs -U "7g865264-3k70-8mr5-7s3k-35a47921o480" /dev/sde1
tune2fs 1.42.5 (29-Jul-2012)
tune2fs: Bad magic number in super-block while trying to open /dev/sde1
$ sudo tune2fs -U 7g865264-3k70-8mr5-7s3k-35a47921o480 /dev/sde1
tune2fs 1.42.5 (29-Jul-2012)
tune2fs: Bad magic number in super-block while trying to open /dev/sde1
Couldn't find valid filesystem superblock.
$ sudo uuid /dev/sde1
uuid:ERROR: invalid number of arguments
usage: uuid [-v version] [-m] [-n count] [-1] [-F format] [-o filename] [namespace name]
usage: uuid -d [-F format] [-o filename] [uuid]
$ sudo uuid -d 7g865264-3k70-8mr5-7s3k-35a47921o480 /dev/sde1
uuid:ERROR: invalid number of arguments
usage: uuid [-v version] [-m] [-n count] [-1] [-F format] [-o filename] [namespace name]
usage: uuid -d [-F format] [-o filename] [uuid]

元々の質問は
パーティションをクローン化する時は
クローン元とクローン先で
パーティション番号を一致させないといけない、
と思っていたことが大元にありました。
ですが、パーティション番号を一致させなくとも
クローン化した後に何の問題も発生しないならば、
パーティション番号を増やそうなどと
せずとも万事ＯＫということになります。

それと、今回は
基本パーティション → 基本パーティション
というようにクローンしましたが、
基本パーティション → 論理パーティション
論理パーティション → 基本パーティション
のようなクローン化も時間があれば試してみます。
MBR でなく GPT であれば、こういうことは気にしなくていいのですが。
MBR の HDD で作成したパーティションを GPT の HDD にクローンしても特に問題はないと思いますので、
新しい HDD や USB は全て GPT にするのも手かも。

回答No.4

yakan9

> 具体的にどういうことかよく分からないのですが、
> パーティション番号を増やすことはできなさそうですね。

その通りです。
パーティションは作りません。
必要なパーティションは、用意しておくという概念です。
器は確保しておき、変更しません。
器の中身を必要に応じて使い分けしていくということです。

クローン用の保存パーティションは、内蔵HDDには、確保しない方が、I/Oの読み込み、書き込みは、別にしておくと、効率が良くなり、処理スピードも上がります。
理由は、同じ内蔵HDDに作成すると、読み込むデバイスと、書き込むデバイスが同じ内蔵HDDだと、ヘッドの動きが激しく、所要時間もかかります。
保存先は、USB接続外付けHDDにすると、保存時は、内蔵HDDを読み、USB接続外付けHDDに書き込むと、効率は良いし、ヘッドの動きも少なくて処理時間も短縮します。
クローンの復旧時は、この逆でI/Oは、USB接続外付けHDDから読み込み、内蔵HDDに書き出します。
こうした、I/O動作は、よく理解しておくと、HDDの消耗度も少なくなると思います。

お礼

ありがとうございます。
> 必要なパーティションは、用意しておくという概念です。
> 器は確保しておき、変更しません。
> 器の中身を必要に応じて使い分けしていくということです。
No.5 の方からクローン時にパーティション番号を一致させなくても問題ないだろうという見解が出まして、
今回私が試してもそのような感じでしたので
このやり方で大丈夫なようです。

それと、クローン時には二度手間に思えても
一旦イメージファイルに保存してからクローン先にコピーしておりますので、
HDDの消耗については気にしなくて大丈夫だと思っております。

回答No.3

kteds

パーティション番号はパーティションテーブルの情報で管理されていることを理解すれば、
疑問は解消するはずです。
パーティションを変更すると（新規作成や削除など）変更情報はパーティションテーブルに書き込まれます。
この状態でのパーティション番号も再編成されます。
---
(1)削除するとパーティション番号も更新されているのは、変更後のパーティションテーブルで表示されているからです。
(2)新規追加の際に途中のパーティション番号を「欠番」にして、一足飛びに sda8 などとできないのは、パーティションテーブルによるパーティション管理に反するからです。
仮に欠番を認めると「欠番情報」を管理する仕組みが必要になり、却って煩雑になります。
(3)パーティションクローンを行なった場合は、パーティションのイメージだけをコピーします。
パーティションテーブルは元の情報とは異なりますのでコピーしてはいけません。
ディスククローンの場合は丸ごとコピーですので、パーティションテーブルもコピーしなければいけません。
---以上です。
なお、MBRシステムの場合のパーティションクローンの図解として添付画像を参照してください。
上図のデバイスのパーティション2番目を
下図のパーティション1番目にコピーしている状態を表しています。
2つのデバイス間のMBRおよびパーティションテーブル情報は異なりますので、
MBRのパーティションテーブルをコピーしてはいけません。
ディスククローンの場合はパーティションテーブルもコピーしなければいけません。

お礼

ありがとうございます。

たとえば sda8 のパーティション番号を減らしたければ
gParted で sda6 を削除すると sda7 になり
その後にそこに入っていたOSを起動すると
何の問題もなく使用できます。

しかし、たとえば sda5 の中身のOSを sda10 にクローンしてsda10 から再起動し、
sda10 の中にファイルを作ると
sda5 の中にファイルが作られている、
という現象が起こったように見えたことが以前にありました。
つまり、sda10 の中のOSには
「このパーティションの HDD における物理的な番地は sda5 である」
と書いてあるから、ということだとその時は推測したのですが。
これはその時にファイルマネージャーにおいて
どのパーティションをどこにマウントしている、
ということをきちんと把握できずに思い違いをしたのかもしれません・・・

回答No.2

486HA

パーティションに振られる番号は、最近の64 bit OS対応のuEFIマザーボードでない従来型の場合は、
１～３の基本パーティションはsda1～sda3になりますが、
以降は拡張パーティション(sda4）の中にsda5以降の論理パーティションを作成することになります。
特定のパーティション番号を割り当てるには、
実際には使用しない微小サイズのパーティションを幾つか作成して帳尻を合わせることで可能になります。

お礼

ありがとうございます。
これからパーティションを作成しよう、
っていう段階ならそのやり方でいいですね。

回答No.1

yakan9

> /dev/sda8
> などに増やす方法はありますでしょうか？

Linuxをインストールする際、パーティションを新規に作成すると、どうしてもそのソフトの規則に番号はふられると思います。
一般には、Linuxをインストールする場合、事前に、メモリの低い方から、パーティションを切っておき、
パーティション番号が狂わないように修復して使う方法を採用すると、パーティション番号は、常に固定します。

例えば下記のように、
Part-1 Windows
Part-2 Linux A /boot 200MB
Part-3 Linux A / 20GB
Part-4 Linux A swap 2GB
Part-5 Linux B /boot 200MB
Part-6 Linux B / 20GB
Part-7 Linux B swap 2GB
この、Linuxの一つで３パーティションを確保しておく方法を当方は使用しています。
swapパーティションを共有するのを嫌うVine Linuxのためにそれぞれ独立させておくことに慣れました。

お礼

ありがとうございます。

> 一般には、Linuxをインストールする場合、事前に、メモリの低い方から、パーティションを切っておき、
> パーティション番号が狂わないように修復して使う方法を採用すると、パーティション番号は、常に固定します。

具体的にどういうことかよく分からないのですが、
パーティション番号を増やすことはできなさそうですね。