Documentazione di Oracle Cloud Infrastructure

Recupero di un volume di avvio danneggiato per le istanze basate su Linux

Se l'avvio dell'istanza non riesce o si avvia con il volume di avvio impostato per l'accesso in sola lettura, è possibile che il volume di avvio dell'istanza sia danneggiato. Sebbene sia raro, il danneggiamento del volume di avvio può verificarsi nei seguenti scenari:

  • Quando si verifica una chiusura forzata di un'istanza mediante l'API.

  • Quando un'istanza subisce un blocco del sistema a causa di un errore del sistema operativo o del software, si verifica un timeout del riavvio o dell'arresto dell'istanza, quindi si verifica un arresto forzato.

  • Quando si verifica un errore o un'indisponibilità nell'infrastruttura sottostante e nel sistema erano presenti scritture critiche del disco in sospeso.

Importante

Nella maggior parte dei casi un semplice riavvio risolverà i problemi di danneggiamento del volume di avvio, quindi questa è la prima azione da eseguire durante la risoluzione dei problemi.

Questo argomento descrive come determinare se il volume di avvio dell'istanza basata su Linux è danneggiato e quali passi eseguire per risolvere i problemi e recuperare il volume di avvio danneggiato. Per le istanze di Windows, vedere Recupero di un volume di avvio danneggiato per le istanze di Windows.

Rilevamento del danneggiamento del volume di avvio

Il danneggiamento del volume di avvio può impedire il corretto avvio di un'istanza, pertanto potrebbe non essere possibile connettersi all'istanza utilizzando la shell SSH. In alternativa, è possibile utilizzare la funzione di connessione della console dell'istanza per connettersi all'istanza che non funziona correttamente. Per ulteriori informazioni sull'uso di questa funzione, vedere Risoluzione dei problemi delle istanze mediante le connessioni della console delle istanze.

In questa sezione viene descritto come utilizzare una connessione console seriale per rilevare se si è verificato un danneggiamento del volume di avvio.

Suggerimento

Se hai già confermato che il volume di avvio della tua istanza è danneggiato o se stai utilizzando un'immagine personalizzata importata, vai alla sezione Recupero del volume di avvio, che descrive come utilizzare una seconda istanza insieme agli strumenti del file system standard per rilevare e riparare il danneggiamento del volume di avvio.
  1. Creare una connessione alla console seriale per l'istanza.

  2. Connettiti all'istanza tramite la console seriale.

    A questo punto, è normale che la console seriale appaia bloccata, poiché il sistema potrebbe essersi già bloccato.

  3. Riavviare l'istanza dalla console.

  4. Una volta avviato il processo di riavvio, torna alla finestra del terminale e dovresti vedere i messaggi di sistema dall'istanza iniziare a apparire nella finestra.

  5. Monitorare i messaggi visualizzati all'avvio del sistema. La maggior parte dei sistemi operativi imposterà il volume di avvio in sola lettura non appena viene rilevato un danneggiamento del disco per evitare che le scritture danneggino ulteriormente il volume, quindi cercare i messaggi che indicano che il volume di avvio è in modalità di sola lettura. Ecco alcuni esempi:

    • In un'istanza con volumi di avvio collegati a iSCSI, il servizio iscsiadm non riuscirà a collegare un volume perché è in modalità di sola lettura. In genere, ciò impedirà l'avvio delle istanze. La console seriale potrebbe visualizzare un messaggio simile al seguente:

      iscsiadm: Maybe you are not root?
iscsiadm: Could not lock discovery DB: /var/lock/iscsi/lock.write: Read-only file system
touch: cannot touch `/var/lock/subsys/iscsid': Read-only file system
touch: cannot touch `/var/lock/subsys/iscsi': Read-only file system

    • In un'istanza con volumi di avvio collegati pseudo-virtualizzati, il sistema potrebbe continuare il processo di avvio, ma si troverà in uno stato degradato perché nella console seriale drive.The di avvio non è possibile scrivere nulla per visualizzare messaggi di errore simili ai seguenti:

      [FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.
...
[   27.160070] cloud-init[819]:     os.chmod(path, real_mode)
[   27.166027] cloud-init[819]: OSError: [Errno 30] Read-only file system: '/var/lib/cloud/data'

    I messaggi di errore e il comportamento del sistema descritti qui sono i più comuni per il danneggiamento del volume di avvio, tuttavia, a seconda del sistema operativo, potrebbero essere visualizzati diversi messaggi di errore e comportamento del sistema. Se non vengono visualizzati quelli descritti qui, consultare la documentazione del sistema operativo per ulteriori informazioni sulla risoluzione dei problemi.

Recupero del volume di avvio

Per risolvere i problemi e recuperare il volume di avvio danneggiato, è necessario scollegare il volume di avvio dall'istanza e quindi collegare il volume di avvio a una seconda istanza come volume di dati.

Scollegamento del volume di avvio

Se hai rilevato che il volume di avvio dell'istanza è danneggiato, devi scollegare il volume di avvio dall'istanza prima di poter iniziare i passi di risoluzione dei problemi e recupero.

  1. Arrestare l'istanza.
  2. Scollega il volume di avvio dall'istanza.

Collegamento del volume di avvio come volume di dati a una seconda istanza

Per la seconda istanza, si consiglia di utilizzare un'istanza su cui è in esecuzione un sistema operativo che corrisponde più da vicino al sistema operativo per l'istanza del volume di avvio. È consigliabile collegare solo volumi di avvio per istanze basate su Linux ad altre istanze basate su Linux. La seconda istanza deve trovarsi nello stesso dominio di disponibilità e nella stessa area dell'istanza del volume di avvio. Se non è disponibile alcuna istanza esistente, creare una nuova istanza Linux utilizzando i passi descritti nella sezione Creazione di un'istanza. Dopo aver eseguito la seconda istanza, assicurarsi di poter eseguire il login all'istanza e che sia funzionale prima di procedere con i passi di recupero. Per i passi per accedere all'istanza, vedere Connessione a un'istanza Linux. Dopo aver confermato che l'istanza è funzionante, attenersi alla procedura riportata di seguito.

  1. Eseguire il comando lsblk e prendere nota delle unità attualmente presenti nell'istanza, ad esempio:

    lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi
  2. Collegare il volume di avvio alla seconda istanza come volume di dati. Per ulteriori informazioni, vedere Collegamento di un volume a blocchi a un'istanza.
    Per collegare il volume di avvio come volume dati
    1. Aprire il menu di navigazione e selezionare Computazione. In Computazione, selezionare Istanze.
    2. Fare clic sull'istanza a cui si desidera collegare un volume.
    3. In Risorse, fare clic su Volumi a blocchi collegati.
    4. Fare clic su Collega volume a blocchi.

    5. Selezionare il tipo di collegamento del volume. Se per questa istanza sono disponibili collegamenti virtualizzati, si consiglia di selezionare questo tipo di collegamento per questa procedura.

      Se si seleziona iSCSI come tipo di collegamento del volume, è necessario connettersi al volume. Per ulteriori informazioni, vedere Connessione a un volume a blocchi.

    6. Nell'elenco a discesa Compartimento volume a blocchi selezionare il compartimento.
    7. Scegliere l'opzione Select Volume, quindi selezionare il volume dalla sezione Boot Volume dell'elenco a discesa Block Volume.
    8. Selezionare Leggi/scrivi come tipo di accesso.

    9. Fare clic su Allega.

      Quando l'icona del volume non lo elenca più come Collegamento, procedere con i passi successivi.

  3. Eseguire di nuovo il comando lsblk per confermare che il volume di avvio viene ora visualizzato come volume collegato all'istanza. In questo output di esempio per lsblk, il volume di avvio collegato come volume di dati viene visualizzato come sdb:
    lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sdb      8:16   0 46.6G  0 disk
├─sdb2   8:18   0    8G  0 part
├─sdb3   8:19   0 38.4G  0 part
└─sdb1   8:17   0  200M  0 part
sda      8:0    0 46.6G  0 disk
├─sda2   8:2    0    8G  0 part [SWAP]
├─sda3   8:3    0 38.4G  0 part /
└─sda1   8:1    0  200M  0 part /boot/efi

  4. Eseguire il comando fsck sulla partizione root del volume. La partizione radice è in genere la partizione più grande del volume.

    L'esempio seguente per il comando fsck mostra l'output quando non sono presenti errori o danneggiamenti nelle partizioni per un'istanza di Oracle 7.6:

    sudo fsck -V /dev/sdb1
fsck from util-linux 2.23.2
[/sbin/fsck.vfat (1) -- /boot/efi] fsck.vfat /dev/sdb1
fsck.fat 3.0.20 (12 Jun 2013)
/dev/sdb1: 17 files, 2466/51145 clusters

sudo fsck -V /dev/sdb2
fsck from util-linux 2.23.2

sudo fsck -V /dev/sdb3
fsck from util-linux 2.23.2
[/sbin/fsck.xfs (1) -- /] fsck.xfs /dev/sdb3
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).

    Se sono presenti errori in una partizione, in genere viene richiesto di correggere gli errori. Di seguito è riportato un esempio di sessione di riparazione interattiva di un volume di avvio ext4 danneggiato per un'istanza Ubuntu.

    sudo fsck -V /dev/sdb1
fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/sdb1
e2fsck 1.44.1 (24-Mar-2018)
One or more block group descriptor checksums are invalid.  Fix<y> yes
Group descriptor 92 checksum is 0xe9a1, should be 0x1f53.  FIXED.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: Group 92 block bitmap does not match checksum.
FIXED.

cloudimg-rootfs: ***** FILE SYSTEM WAS MODIFIED *****
cloudimg-rootfs: 75336/5999616 files (0.1% non-contiguous), 798678/12181243 blocks
    Nota

    I file system XFS in genere riparano automaticamente il loro contenuto al boot del sistema, correggendo eventuali danni durante il processo di boot. È possibile utilizzare il comando xfs_repair per forzare una riparazione per gli scenari in cui il danneggiamento del volume di avvio impedisce il funzionamento della funzionalità di riparazione automatica, come mostrato nell'esempio riportato di seguito.

    sudo xfs_repair /dev/sdb3
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
...
Phase 7 - verify and correct link counts...
done