爲什麼在調整根EBS卷的大小後，EC2實例無法正確啓動？

我正在使用https://matt.berther.io/2015/02/03/how-to-resize-aws-ec2-ebs-volumes/和http://atodorov.org/blog/2014/02/07/aws-tip-shrinking-ebs-root-volume-size/上的說明移動到磁盤空間較小的EBS卷。在這兩種情況下，當我附上了收縮EBS卷（爲/ dev/xdva或/ dev/sda1的，既不作品），以EC2實例並啓動它，它會停止對自己與消息爲什麼在調整根EBS卷的大小後，EC2實例無法正確啓動？

State transition reason 
Client.InstanceInitiatedShutdown: Instance initiated shutdown

一些更多的修補程序，我發現新卷沒有BIOS啓動分區。因此，我使用gdisk創建一個，並將原始卷中的MBR（可運行並可用於啓動實例）複製到新卷中。現在這個實例並沒有終止，但是我不能SSH入新啓動的實例。

這種情況背後的原因是什麼？我如何從（日誌/ AWS控制檯等）獲取更多信息，解釋爲什麼會發生這種情況？

來源

2015-07-06 web_ninja

你的機器使用什麼操作系統？ AWS EC2 Console - > Syslog中是否有任何內容？ – Mircea

Amazon Linux和AWS EC2控制檯爲空。 –

問題出在BIOS啓動分區上。我能夠通過首先使用較小的EBS卷初始化一個實例來解決此問題。然後分離音量並將其附加到一個實例，以便用來從較大音量或較小音量中複製內容。這創建了一個實際上起作用的BIOS啓動分區。簡單地創建一個新的並複製啓動分區不起作用。

現在，按照這兩個鏈接中任何一個概述的步驟將有助於縮小根EBS的體積。

來源

2015-07-07 07:25:56

要縮小一個GPT進行分配的8GB下方引導EBS體積標準的圖像似乎使用可以執行以下操作：

源盤是/dev/xvdf（從https://matt.berther.io/2015/02/03/how-to-resize-aws-ec2-ebs-volumes/的dd方法的輕微變化），目標是/dev/xvdg

收縮源分區

$ sudo e2fsck -f /dev/xvdf1 
$ sudo resize2fs -M /dev/xvdf1

將PR INT類似

resize2fs 1.42.12 (29-Aug-2014) 
Resizing the filesystem on /dev/xvdf1 to 257491 (4k) blocks. 
The filesystem on /dev/xvdf1 is now 257491 (4k) blocks long.

我轉換這對MB，即257491 *一千○二十四分之四〜= 1006 MB

拷貝以上大小+略偏從設備到設備（！），不只是進行分區以分區，因爲這既包括分區表中的啓動分區
```
$ sudo dd if=/dev/xvdf of=/dev/xvdg bs=1M count=1100 
```

&數據現在使用gdisk來解決新的磁盤上的GPT分區

$ sudo gdisk /dev/xvdg

您將與大致

GPT fdisk (gdisk) version 0.8.10 

Warning! Disk size is smaller than the main header indicates! Loading 
secondary header from the last sector of the disk! You should use 'v' to 
verify disk integrity, and perhaps options on the experts' menu to repair 
the disk. 
Caution: invalid backup GPT header, but valid main header; regenerating 
backup header from main header.# 

Warning! One or more CRCs don't match. You should repair the disk! 

Partition table scan: 
    MBR: protective 
    BSD: not present 
    APM: not present 
    GPT: damaged 

**************************************************************************** 
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk 
verification and recovery are STRONGLY recommended. 
**************************************************************************** 

Command (? for help):

迎接下面是內gdisk鍵盤輸入。要解決這些問題，複製分區表中存在的數據分區需要調整大小以適應新磁盤。這意味着需要重新創建較小的屬性，並且需要設置屬性以匹配舊的分區定義。沒有測試它，所以它可能不備份表搬遷到磁盤的實際最終需要的，但我做到了，反正：

去額外的專家選項：x
移居備份數據結構盤的端：e
返回主菜單：m

我們固定分區大小

打印和（如果它們存在和其他非引導分區）指出分區1的某些屬性：
i
1
會顯示類似

Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) 
Partition unique GUID: DBA66894-D218-4D7E-A33E-A9EC9BF045DB 
First sector: 4096 (at 2.0 MiB) 
Last sector: 16777182 (at 8.0 GiB) 
Partition size: 16773087 sectors (8.0 GiB) 
Attribute flags: 0000000000000000 
Partition name: 'Linux'

現在刪除
d
1
並重新創建分區
n
1
輸入所需的參數。所有默認工作對我來說在這裏（=按回車鍵），有疑問時指從上述
- 第一個扇區= 4096
- 最後一個扇區=無論是新盤的實際最終分區信息 - 使用默認這裏
- 類型= 8300（Linux）的
新分區的默認名稱不匹配舊的。因此，將其更改爲原來的
c
1
Linux（見Partition name從上面）
改變接下來的事情是分區的GUID
x
c
1
DBA66894-D218-4D7E-A33E-A9EC9BF045DB（見Partition unique GUID，不是上面的分區引導代碼）

應該是這樣。返回主菜單&打印狀態
m
i
1
現在將打印

Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem) 
Partition unique GUID: DBA66894-D218-4D7E-A33E-A9EC9BF045DB 
First sector: 4096 (at 2.0 MiB) 
Last sector: 8388574 (at 4.0 GiB) 
Partition size: 8384479 sectors (4.0 GiB) 
Attribute flags: 0000000000000000 
Partition name: 'Linux'

唯一的變化應該是Partition size。

寫入到磁盤並退出
w
y

增長的文件系統，以配合整個（少量）的硬盤。第一步將其縮小到可適合的最小尺寸
```
$ sudo resize2fs -p /dev/xvdg1 
```
我們完成了。分離卷&快照。
可選步驟。爲AMI選擇適當的內核ID。

如果你正在處理PVM形象和接觸之後的情況下mount error登錄

內核恐慌 - 不同步：VFS：無法mount根

當你的實例沒有按沒有通過啓動檢查，您可能需要執行此額外步驟。

此錯誤的解決方案是在從快照創建映像期間爲您的PVM映像選擇適當的內核標識。可以獲得內核ID（AKI）的完整列表here。

爲您的圖像選擇適當的AKI，它們受到地區和體系結構的限制！

來源

2016-05-09 10:49:06 zapl

刪除/重新創建不影響實際數據？只有分區表？ – Suncatcher

@Suncatcher是的，分區表不知道文件系統中的數據，它只是需要知道文件系統在字節邊界方面的位置，然後重新創建該數據 – zapl

終於完成了！神聖的！三天失利:) – Suncatcher

爲什麼在調整根EBS卷的大小後，EC2實例無法正確啓動？

回答

相關問題