Come interagisco con la console durante l'avvio su Amazon EC2?

Ho un'istanza bloccata a questo prompt di avvio (guardando il registro dell'istanza dalla console di gestione):

The disk drive for /mydisk is not ready yet or not present
Continue to wait; or Press S to skip mounting or M for manual recovery

Ho aggiunto un volume EBS, montato, quindi eliminato il volume EBS e ho dimenticato di rimuovere la voce da / etc / fstab e riavviato la macchina. Ora mi viene richiesto al momento dell'avvio e non sono in grado di accedere a SSH nell'istanza.

Cosa devo fare per risolvere questo problema?

amazon-ec2

— ErJab
fonte

Risposte:

Non conosco una soluzione "facile" al tuo problema, ma esiste una soluzione un po 'contorta (a seconda del tipo di dispositivo root).

Se l'istanza ha una radice EBS, la soluzione è abbastanza semplice: arrestare l'istanza, scollegare l'unità EBS, avviare un'altra istanza e collegare il volume EBS ad essa. Modifica il tuo file fstab secondo necessità, scollega il volume EBS e ricollegalo all'istanza originale.

Se la tua istanza ha un root supportato da S3 (ad esempio, store-istanza), la soluzione è un po 'più difficile. Puoi scaricare i dati dalla tua AMI (usando ec2-download-bundle ), quindi estrarre quei dati in un singolo file (usando ec2-unbundle ). È quindi possibile montare l'immagine, apportare le modifiche necessarie e ricomporre l'immagine (con ec2-bundle-vol , sovrascrivendo il volume predefinito in bundle con il flag -v). Ciò dovrebbe darti una nuova AMI praticabile, identica alla tua vecchia, fatta eccezione per le modifiche apportate. In alternativa, è possibile copiare il contenuto del file di immagine in un volume EBS utilizzando dd, quindi convertirlo in un'istanza supportata da root EBS.

— cyberx86
fonte

Per fortuna, la mia istanza ha una radice EBS! Grazie mille per la risposta. Lo proverò e confermerò che funziona.

— ErJab,

ErJab: ho scritto un articolo che descrive come eseguire questa operazione con l'avvio EBS: alestic.com/2011/02/ec2-fix-ebs-root

— Eric Hammond,

Sarebbe prudente aggiungere anche nofaila /etc/fstabnel caso in cui si commette un errore di battitura? Forse no, forse "errori" (come descritto in fstab(5)) non trattengono il processo di avvio.

— Adam Monsen,

@AdamMonsen: questa è una buona pratica per alcune unità, ad esempio unità effimere, poiché il processo di avvio uscirà in modalità di ripristino se un disco non è disponibile. Di solito uso l'opzione nobootwait- non ci ho provato nofail- credo che ci siano alcune sottili differenze tra di loro.

— cyberx86,

Se hai Ubuntu systemd, puoi modificare /lib/systemd/system/local-fs.targete commentare le ultime due righe:

#OnFailure=emergency.target
#OnFailureJobMode=replace-irreversibly

Non l'ho testato ampiamente e non so se ci siano rischi o effetti collaterali, ma finora funziona come un fascino. Monta il volume di root e tutti gli altri volumi (tranne quelli erroneamente configurati, ovviamente), quindi continua il processo di avvio fino a quando SSH è attivo, quindi puoi connetterti all'istanza e correggere le fstabvoci errate .

— ThiagoAlves
fonte