質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

89.72%

(急募)EBSを拡張したが、OSで認識されない[CentOS7]

解決済

回答 2

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 3,347

choitarou

score 110

お世話になっております。

AWSのEC2において、ルートボリュームを拡張しようと思い、
16Gから200Gに拡張し、EBSをEC2にアタッチしたところ、
OS側[CentOS7]では認識されていないようでした。


# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  200G  0 disk
|-xvda1 202:1    0   16G  0 part /
# df -h
ファイルシス    サイズ  使用  残り 使用% マウント位置
/dev/xvda1     16G  5.6G   11G   35% /

確認すると上記のようになっておりました。
そこでご質問なのですが、上記の状態から、
xvda1を200Gとするためにはどうすればよいでしょうか?

AWSの公式HPを見ると、「sudo xfs_growfs -d /mnt」
と書かれていましたが、このコマンドを打ってもなにも
おこらず、どうしていいかわからない状態です。

私は、このような設定については、完全に初心者の為
出来れば、詳細な手順を教えていただけると助かります。

お手数ですが、ご教授頂ければと思いますので、
よろしくお願い致します。


<追記>

# df -T
ファイルシス    タイプ        1K-ブロック     使用           使用可 使用% マウント位置
/dev/xvda1      xfs              16760596  2061180         14699416   13% /
devtmpfs        devtmpfs          8114976        0          8114976    0% /dev
tmpfs           tmpfs             8002468        0          8002468    0% /dev/shm
tmpfs           tmpfs             8002468    16664          7985804    1% /run
tmpfs           tmpfs             8002468        0          8002468    0% /sys/fs/cgroup
tmpfs           tmpfs             1600496        0          1600496    0% /run/user/1000
# xfs_growfs /
meta-data=/dev/xvda1             isize=256    agcount=8, agsize=524224 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=4192709, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • moonphase

    2016/11/16 12:03

    df -T コマンドを実行して、ファイルシステムTypeを質問に追記してください。

    キャンセル

回答 2

checkベストアンサー

+3

ファイルシステムタイプがxfsで、マウントポイント / のルートボリューム領域を拡張した後にOS側でもサイズの拡大を行う場合は次のコマンドを実行します。

# xfs_growfs /

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/11/16 14:34

    お手数をおかけしております。コマンド結果は以下となっております。

    # sudo fdisk -l

    Disk /dev/xvda: 107.4 GB, 107374182400 bytes, 209715200 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
    Disk label type: dos
    ディスク識別子: 0x000123f5

    デバイス ブート 始点 終点 ブロック Id システム
    /dev/xvda1 * 2048 33543719 16770836 83 Linux

    キャンセル

  • 2016/11/16 15:03

    終点がおかしいかな・・・。
    fdiskコマンドで修正できますが、必ず元のバックアップを作成してから実行してください。
    (AMIがあると思うので大丈夫とは思いますが)

    オンラインで実施できたか記憶にないですが、やってみましょう。

    ※ファイルシステムの情報を確認しておく(念のためメモしておいてください)
    # xfs_info /

    ※テーブル変更作業
    # fdisk /dev/xvda
    ...
    Command (m for help): p ※区画テーブルの表示(念のためこの内容もメモ)
    Command (m for help): d ※区画の削除
    Command (m for help): n ※区画の作成
    Select (default p): p ※プライマリを選択
    Partition number (1-n, default 1): 1 ※1を指定
    First sector (2048-nnnnnnnn, default 2048): そのままEnter
    Last sector, +sectors or +size{K,M,G} (2048-nnnnnnnn, default nnnnnnnn): そのままEnter

    Command (m for help): p ※区画テーブルの表示(念のためこの内容もメモ)
    Command (m for help): w ※テーブルの書き込み&終了

    ※OS再起動
    # reboot


    これで直ると思います。
    繰り返しとなりますが、必ず作業前にバックアップを取得をお願いします。

    キャンセル

  • 2016/11/16 15:33

    ご回答ありがとうございます。ご教授頂いた通り実施したら無事、ルートボリュームが拡張サイズに認識されました!何度もご教授頂きました、大変感謝しております。ありがとうございました!

    キャンセル

0

cloud-init が入っていれば、起動時にファイルシステムもリサイズ(拡張)してくれると思うのですが、AMI が違うのでしょうか。
AMI ami-eec1c380 (CentOS Linux 7 x86_64 HVM)の場合、以下のログ(cc_growpart → cc_resizefs 箇所)のとおり、8GB → 16GB にリサイズできました。 

# journalctl -u cloud-init --no-pager | grep -E 'grow|resize'
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Looking for modules ['cc_growpart', 'cloudinit.config.cc_growpart'] that have attributes ['handle']
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_growpart' due to: No module named cc_growpart
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Found cc_growpart with attributes ['handle'] in ['cloudinit.config.cc_growpart']
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Looking for modules ['cc_resizefs', 'cloudinit.config.cc_resizefs'] that have attributes ['handle']
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Failed at attempted import of 'cc_resizefs' due to: No module named cc_resizefs
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] importer.py[DEBUG]: Found cc_resizefs with attributes ['handle'] in ['cloudinit.config.cc_resizefs']
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] helpers.py[DEBUG]: Running config-growpart using lock (<cloudinit.helpers.DummyLock object at 0x2f38b10>)
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: {'ignore_growroot_disabled': False, 'mode': 'auto', 'devices': ['/']}
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--help'] with allowed return codes [0] (shell=False, capture=True)
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/xvda', '1'] with allowed return codes [0] (shell=False, capture=True)
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] util.py[DEBUG]: Running command ['growpart', '/dev/xvda', '1'] with allowed return codes [0] (shell=False, capture=True)
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] util.py[DEBUG]: resiz _devices took 0.496 seconds
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] cc_growpart.py[INFO]: '/' resized: changed (/dev/xvda, 1) from 8588886016 to 17173336064
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] helpers.py[DEBUG]: Running config-resizefs using lock (<cloudinit.helpers.DummyLock object at 0x2f38b90>)
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] cc_resizefs.py[DEBUG]: resize_info: dev=/dev/xvda1 mnt_point=/ path=/
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resizing / (xfs) using xfs_growfs /dev/xvda1
Nov 16 04:35:02 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] util.py[DEBUG]: Running command ('xfs_growfs', '/dev/xvda1') with allowed return codes [0] (shell=False, capture=True)
Nov 16 04:35:03 ip-192-168-132-89.localdomain cloud-init[1838]: [CLOUDINIT] cc_resizefs.py[DEBUG]: Resized root filesystem (type=xfs, val=True)

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/11/17 21:55

    もう一度、新規AMIから、同様にインスタンスを作成して、同じ手順でルートボリュームを拡張してみたところ、普通に拡張が認識されました。なので、私が、なんらかの設定を変更していることが原因で、拡張の認識がcloud-initで処理されなかったのだと思います。たしかに、cloud-initの設定は少し修正しているので、何か間違っているのだと思います。
    大変参考になりました、わざわざ、実施までしていただきまして感謝しております。ありがとうございました!

    キャンセル

  • 2016/11/18 10:01

    moonphase さんとのやりとりを拝見すると、パーティションの拡張に失敗していたようですね。
    現在の起動ログでは、cc_growpart 箇所で "no change necessary" と出ていますので、手動でパーティションを拡張した後のログだと思います。
    "jounalctl -b -1", "jounalctl -b -2" などと、過去の起動ログをさかのぼって調べると、cc_growpart で失敗したときのログが見つかると思います。
    "journalctl --list-boots" で起動日時がわかります。

    キャンセル

  • 2016/11/18 11:15

    ご教授頂きまして、大変ありがとうございます。
    なるほど、そのようなコマンドもあるのですね。参考になります。
    AWSを使用している為、またディスク拡張することもあると思いますので、
    次回このような現象が起こった際に、とても有効なご意見を頂き、
    感謝しております!

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 89.72%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる