每天进步一点点：在Amazon AWS的EBS卷上使用GPT分区方案
因为工作关系，需要在Amazon AWS的EBS卷上使用GPT分区方案，最初我想的比较简单，以为直接把MBR转换成GPT就中了。结果在测试机上一试，擦，连系统带数据都搞没了。
(图源 ：pixabay)
接下来就试了几种办法，无一例外的失败，最后想到的方案就是使用两个EBS卷：一个用作系统继续用MBR方案，另外一个做数据盘使用GPT方案。这样比直接使用一个EBS卷更加灵活方便，毕竟不用考虑启动分区等诸多问题。
首先创建个EC2实例，这个按自己的需求来就可以，使用的EBS卷不用很大，能装系统就行，唯一需要注意的就是要记录或者选择一下区域，新的EBS卷要建到同一个区域下。
附加GPT分区方案的EBS卷
接下来创建一个新的EBS卷，注意一下空间和区域：
创建完之后，我们就会多出来一个可用的EBS卷：
然后将其挂载到之前建立的EC2实例上：
之后使用sudo fdisk -l就会发现我们新挂载的EBS卷：
接下来我使用sudo fdisk /dev/xvdf的g指令来创建GPT分区表：
用w写入，看起来一切正常，再使用sudo fdisk -l查看实例上的两个EBS卷：
再用fdisk创建个新的分区并写入，之后是这个样子：
如果这时我们尝试将其mount到目录上：
sudo mkdir /home2
sudo mount /dev/xvdf1 /home2
就会出类似如下错误：
mount: /home2: wrong fs type, bad option, bad superblock on /dev/xvdf1, missing codepage or helper program, or other error.
原因是我们有磁盘有分区，但是分区上还没有文件系统呢（相当于Windows的还没格式化）。
创建文件系统 & 自动mount
解决之前的问题很简单，使用sudo mkfs.ext4 /dev/xvdf1创建文件系统后一切正常。
记录一下文件系统的UUID（如若忘记，可用使用sudo blkid找回。
然后为了避免我们每次都需要手工挂载，我们编辑一下fstab文件实现自动挂载：
sudo vi /etc/fstab
添加如下内容：
UUID=6e3fc6a2-b24c-43d6-befc-0b92a4297bfe /backup ext4 defaults 0 0
这样就一切OK啦。
扩容
在EBS上将空间调整喂100G以后，回到系统中，出现GPT PMBR size mismatch的问题：
使用w指令写入后，出现如下错误：
fdisk: failed to write disklabel: Invalid argument
使用sudo gdisk /dev/xvdf解决，早知如此，早使用gdisk就好了，哎：
然后扩容分区空间：
sudo growpart /dev/xvdf 1
提示如下：
CHANGED: partition=1 start=2048 old: size=20969439 end=20971487 new: size=209713119,end=209715167
再扩容文件系统：
sudo resize2fs /dev/xvdf1
再使用df -lh查看文件系统空间占用：
虽然搞不懂那5G空间哪里去了，不过貌似这样已经很完美了。
相关链接
Leave 每天进步一点点：在Amazon AWS的EBS卷上使用GPT分区方案 to:
Best Posts From oflyhigh
We have not curated any of oflyhigh's posts yet. But you can encourage our curation team to review posts by visiting them regularly and by referring other readers. Because we give priority to frequently read content.