si様、

情報が不十分で失礼しました。

換装作業は少し前に実施しましたので、完全には覚えて
いませんが、大まかには以下のような手順でした。
１．UbuntuインストールCDでPCを起動。
２．ddresque をインストールし、以下のコマンドを実行
$　sudo ddrescue -v /dev/sdbi /dev/sdc1
（このとき、sdb1 はこれまで使用していたUbuntu用
HDD, sdc1 は２ＴＢのHDDでした。）

> 最近は、Ubuntu9.10では対応できないかもしれないHDDが売られています。
当然そういうこともあるんですね…。
まったく想定していませんでした。
使用しました２ＴＢのＨＤＤは日立製です。箱入りでしたが
なぜかその箱にも取説にも正確な型式は記述されていません。
「DESKSTAR 3.5型大容量ハードディスクドライブ」
「7200RPM, 32MB Cache」との記載はあります。

tugiani による投稿:

なにが原因で空き容量が少ないのか、分かりません。

参考記事の後半部分(2/2)「パーティーションの拡張」を実施していないからでしょう。

zagan による投稿:

tugianiさん による投稿:

使用しました２ＴＢのＨＤＤは日立製です。箱入りでしたが
なぜかその箱にも取説にも正確な型式は記述されていません。

LiveCDで起動して「ディスク・ユーティリティー」でみると型番まで分かりますよ。

与えられた情報からですとDeskstar 7K2000かなと思いますが。

確認しました。
ATA Hitachi HDS72202
でした。

hmatsue による投稿:

作業は9.10(Karmic)のLiveCDかなにかで行ったのでしょうか。
雰囲気的にパーティションサイズはリサイズされているけども、ファイルシステムがリサイズされていないような気がします。
関連するのかどうかよくわかりませんが、気になるバグレポートとしては、
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/505719
があるようです。

hmatsue様、
コメント有難うございました。
ご指摘のとおり、Ubuntu 9.10 のライブCDで行いました。
ご指摘の resize2fs の -p オプションのバグについては
難しすぎて当方には理解できませんでした。

http://www.itmedia.co.jp/enterprise/art … ws019.htmlで実行されたことは元のHDDのクローンディスクを作成したことになります。
クローンディスクの作成は元のHDDと同じ容量でなおかつ内容も同じものが造られます。

60GBから2TBに容量アップしたので、ほとんどHDDは空いているはずです。　　←残りを未使用領域又は未割当としてくれるかどうか確認後実行されましたか
ところが、GPartedで確認すると、空き容量は7GBしかありませんでした。　 ←表示としては正常です。

確認ですが、Gpartedtでみられたとき、「未割当て」と表示されている部分は有りませんでしたか？？

uotora による投稿:

http://www.itmedia.co.jp/enterprise/art … ws019.htmlで実行されたことは元のHDDのクローンディスクを作成したことになります。
クローンディスクの作成は元のHDDと同じ容量でなおかつ内容も同じものが造られます。

60GBから2TBに容量アップしたので、ほとんどHDDは空いているはずです。　　←残りを未使用領域又は未割当としてくれるかどうか確認後実行されましたか
ところが、GPartedで確認すると、空き容量は7GBしかありませんでした。　 ←表示としては正常です。

確認ですが、Gpartedtでみられたとき、「未割当て」と表示されている部分は有りませんでしたか？？

uotora様、
そういうことだったのですか…。少し理解が進みました。
Gpartedtで「未割当て」と表示されている部分は有りませんでした。

デバイスを少し間違えました。
#3においては、
/dev/sda1と/dev/sdb1
ではなく
/dev/sdb1と/dev/sdc1
でしたね。

STGSAGWAN による投稿:

参考記事には
$ sudo ddrescue -v /dev/sda /dev/sdb
と書いてあるのに、#3をよく見たら、
$ sudo ddrescue -v /dev/sda1 /dev/sdb1
と独自のアレンジを加えてますね。

「/dev/sda1のサイズ ＜ /dev/sdb1のサイズ」の時に、上記の後者のコマンドを実施するとどうなるのか実験してみたところ、fdiskでは/dev/sdb1のサイズは正しい値が表示されますが、/dev/sdb1をマウントしてdfすると、/dev/sda1のサイズ分しか表示されなかったです。

STGSAGWAN様、
ご確認頂きありがとうございました。
ddrescue とはそういうコマンドなんですね！

tugiani による投稿:

STGSAGWAN による投稿:

参考記事には
$ sudo ddrescue -v /dev/sda /dev/sdb
と書いてあるのに、#3をよく見たら、
$ sudo ddrescue -v /dev/sda1 /dev/sdb1
と独自のアレンジを加えてますね。

「/dev/sda1のサイズ ＜ /dev/sdb1のサイズ」の時に、上記の後者のコマンドを実施するとどうなるのか実験してみたところ、fdiskでは/dev/sdb1のサイズは正しい値が表示されますが、/dev/sdb1をマウントしてdfすると、/dev/sda1のサイズ分しか表示されなかったです。

STGSAGWAN様、
ご確認頂きありがとうございました。
ddrescue とはそういうコマンドなんですね！

いえ、コマンド説明をしたつもりはなく、単に実験結果を提示しただけですよ。

さかのぼり、改めて＃１をみました、今回問題にされているドライブは/dev/sdbと思いますが、如何でしょうか？？　もし[Fdisk -l]の内容のままであれば問題有りです。
HDD全体をUbuntuに割当インストールした時は下記の様になるのが標準です。

ディスク /dev/sda: 32.3 GB, 32296140800 バイト

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sda1   *           1        3760    30193664   83  Linux
/dev/sda2            3760        3927     1342465    5  拡張領域
/dev/sda5            3760        3927     1342464   82  Linux スワップ / Solaris

Fdisk -lの結果から問題有りと指摘したのは、拡張領域と Linux スワップ / Solarisが存在しないからです。参考にされたURLの作者の意図はLinuxの後方に存在
する、スワップ領域を削除（削除すると未割り当て領域となる）し、後方にLinux領域を拡張させることだと思います。
当方には ddrescue -v の機能等解りませんが、今回の目的にはそぐわない気が致します。その前にコピー元のHDDの内容を　Fdisk -l で確認してください。
不幸ににもLinux スワップ / Solarisが存在しない場合は他の方法（Ubuntuのクリーンインストール等）を考えてください。
Linux スワップ は無くてもUbuntuは問題なく動作します。（誤解されないように）

2TBのHDDをパーティションを設け分割しWindows等と共有される場合は前の方をNtfs,FAT32等のファイルシステムのパーティションに設定しないと、ドライブ全体が
Windowsか認識されなくなります。全体をLinux（Ubuntu）で使用するのであればこのことは考慮する必要は有りません。

tugianiさん、まだ元となったディスクがそのまま残っているのでしたら、ddrescueをパーティション指定ではなくディスク指定でやり直すのが賢明です。
tugianiさんの行われた「sudo ddrescue -v /dev/sdb1 /dev/sdc1」はパーティションからパーティションへのコピーですので、現状ではスワップパーティションもなければ、MBRにブートローダーもありません。　ので、ここから動作するように構築するとなると、スワップパーティションを作成してfstabを編集し、更にMBRへのブートローダーのインストールまでも行わなければならないので、面倒です。（それも、作業前にコピー先となるディスクにパーティションを確保して準備していたのであれば可能、という話になる可能性もありえるかもしれません）

uotora による投稿:

参考にされたURLの作者の意図はLinuxの後方に存在
する、スワップ領域を削除（削除すると未割り当て領域となる）し、後方にLinux領域を拡張させることだと思います。

削除ではなく移動です。
削除してしまうとスワップパーティションを再作成しなければならなくなり、そうなるとUUIDが変わってしまいますので、fstabの編集なども行わなければならなくなります。　その作業を省くために削除ではなく移動という方法を採られています。
※ 尚、スワップパーティションにはデータがないので移動させても問題にはならないということであって、データの入ったパーティションを移動させる場合はデータの消失という最悪の自体を招く可能性があります。

現在の状況を推定すると、

1. /dev/sdb1から/dev/sdc1(今は/dev/sdb1として認識されている)に「パーティション」をコピーしたことにより、パーティションは/dev/sdc1のサイズ(2TB)になり、ファイルシステムは元々の/dev/sdb1のサイズになっている

2. /dev/sdbから/dev/sdcへのHDD全体のコピーであればMBRや、恐らく/dev/sdbにあったであろうswapパーティションもコピーされていた

3. 実際には/dev/sdb1から/dev/sdc1のコピーであったため現在の/dev/sdbにはパーティションがひとつしかない

4. よって/dev/sdbには現在swapパーティションが存在していない

5. Grubのインストール先が/dev/sdaのMBRであった場合、現在の設定でも/dev/sdb1に入っているUbuntuを起動できるかも知れない　←　現在の状況はいかがでしょうか

6. /dev/sdbにはルートパーティション(/dev/sdb1)しか存在しないため、メモリが十分でない場合、システムの実行に問題がでる可能性がある

7. メモリが十分あってもswapの存在でメモリの使用が効率的に行われる(らしい)

8. ハイバーネーション機能を使わないのであればSwapパーティションは必ずしも必要ではない(SwapFileでも対応可能)

9. 元々の/dev/sdbにはSwapパーティションがあったと想像されるが、現在の/dev/sdbにはSwapパーティションがないため、/etc/fstabの修正をした方がよいかも知れない

10. Swapパーティションなども含めてHDD全体をコピーするのであれば2のようにして作業をやり直した方が簡単かも

11. 現在/dev/sdbにあるUbuntuが起動できる状態でハイバネーションが必要ないのであれば/dev/sdb1のファイルシステムを拡張するのもありのような気がします。swapは必要に応じてswap fileを作成するとか。もう一度パーティションをリサイズして空き容量を作りだし、そこにSwapパーティションを作成して/etc/fstabを編集するぐらいなら、元々の/dev/sdbからHDDをコピーしなおした方が簡単だとは思います。

あたりかと思います。
# 認識のおかしなところ等々あればツッコミお願いします > 各位