Correzione di "sola lettura file system" di Ubuntu VM?

Stavo per installare gli strumenti VMWare su una macchina virtuale del server Ubuntu, ma ho riscontrato il problema di non poter creare una directory cdrom nella directory / mnt. Ho quindi testato per vedere se era solo un problema di autorizzazioni, ma non riuscivo nemmeno a creare una cartella nella home directory. Continua a dichiarare che si tratta di un file system di sola lettura. Conosco un po 'di Linux e non mi sento ancora a mio agio con esso. Qualsiasi consiglio sarebbe molto apprezzato.

Informazioni richieste da un commento:

username @ servername : ~ $ mount
/ dev / sda1 on / tipo ext4 (rw, errori = remount-ro)
proc on / proc tipo proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connections tipo fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / security type securityfs (rw)
udev on / dev type tmpfs (rw, mode = 0755)
nessuna su dev dev tipo / dev / pts (rw, noexec, nosuid, gid = 5, mode = 0620)
nessuna su / dev / shm tipo tmpfs (rw, nosuid, nodev)
nessuna su / var / run tipo tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
nessuna su / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc tipo binfmt_misc (rw, noexec, nosuid, nosev)

Sicuramente l'output di root.

root @ server01: ~ # mount
/ dev / sda1 on / type ext4 (rw, errori = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connections tipo fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / security type securityfs (rw)
udev on / dev type tmpfs (rw, mode = 0755)
nessuna su dev dev tipo / dev / pts (rw, noexec, nosuid, gid = 5, mode = 0620)
nessuna su / dev / shm tipo tmpfs (rw, nosuid, nodev)
nessuna su / var / run tipo tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
nessuna su / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc tipo binfmt_misc (rw, noexec, nosuid, nosev)

Sebbene questa sia una domanda relativamente vecchia, la risposta è sempre la stessa. Hai una macchina virtuale (in esecuzione su un host fisico) e una sorta di memoria (o memoria condivisa - una FC SAN, memoria iSCSI, una condivisione NFS - o memoria locale).

Con la virtualizzazione, molte macchine virtuali tentano di accedere alle stesse risorse fisiche contemporaneamente. A causa di limitazioni fisiche (numero di operazioni di lettura / scrittura - IOPS; velocità effettiva; latenza) potrebbe esserci un problema per soddisfare tutte le richieste di archiviazione di tutte le macchine fisiche contemporaneamente. Cosa succede di solito: sarai in grado di vedere "Tentativi SCSI" e operazioni SCSI non riuscite nei sistemi operativi delle tue macchine virtuali. Se si verificano troppi errori / tentativi in ​​un determinato periodo di tempo, il kernel imposterà i filesystem montati in sola lettura al fine di prevenire danni al filesystem.

Per farla breve: la tua memoria fisica non è abbastanza "potente". Esistono troppi processi (macchine virtuali) che accedono contemporaneamente al sistema di archiviazione, le macchine virtuali non ottengono la risposta dall'archiviazione abbastanza velocemente e il filesystem passa in sola lettura.

Non ci sono molte cose che puoi fare. La soluzione ovvia è una memoria migliore / aggiuntiva. È inoltre possibile modificare i parametri per i timeout SCSI nel kernel Linux. I dettagli sono descritti, ad esempio, in:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009465

http://www.cyberciti.biz/tips/vmware-esx-server-scsi-timeout-for-linux-guest.html

Tuttavia, ciò "rimanderà" i tuoi problemi, poiché il kernel impiega solo più tempo prima che il filesystem venga impostato in sola lettura. (Cioè, non risolvi la causa del problema.)

La mia esperienza (diversi anni con VMware) è che questo problema esiste solo con kernel Linux (stiamo usando RHEL e SLES) e non con server Windows. Inoltre, questo problema si verifica su tutti i tipi di archiviazione: FC, iSCSI, archiviazione locale. Per noi, il componente più critico (e costoso) nella nostra infrastruttura virtuale è lo storage. (Stiamo usando HP LeftHand con connessioni iSCSI da 1 Gbps e da allora non abbiamo più avuto problemi di archiviazione. Abbiamo scelto LeftHand (rispetto alle tradizionali soluzioni FC) per la sua scalabilità.

Una probabile spiegazione è che esiste un problema hardware (errore parziale del disco) e che il kernel ha rimontato il filesystem di root in sola lettura non appena ha rilevato il problema, al fine di minimizzare il problema. Un modo più affidabile¹ per verificare le opzioni di mount correnti è cat /proc/mounts( grep ' / ' /proc/mountsper il filesystem di root, ignorare una rootfs / …linea che è un artefatto del processo di avvio). Probabilmente scoprirai che rw,errors=remount-roè cambiato in ro(potrebbero essere visualizzate anche altre opzioni).

I log del kernel probabilmente contengono il messaggio Remounting filesystem read-only, preceduto da errori di accesso al disco. I log normalmente vivono /var/log/kern.log, tuttavia se questo è su un filesystem di sola lettura il messaggio non verrà mostrato lì, anche se gli errori precedenti dovrebbero. Puoi anche vedere gli ultimi errori del kernel con il dmesgcomando.

A parte questo, sotto Ubuntu, il solito posto per i punti di mount (utilizzato dall'interfaccia desktop) è sotto /media(ad esempio /media/cdrom0), sebbene sia possibile utilizzarlo /mnto /mnt/cdromse lo si desidera.

¹ _{rapporti da . Se il filesystem di root è di sola lettura, non può essere aggiornato. mount/etc/mtab/etc/mtab}

Quello che è successo è stato, di recente si è verificato un blackout nel data center. Da allora, non ho più toccato il mio server. Quando il nostro data center perde potenza, VSphere fa leggere il file system di Ubuntu solo fino al suo riavvio. Avrei provato a riavviare ma non volevo che tutto il monitoraggio diventasse pazzo. Ho messo a tacere Nagios (servizio di monitoraggio) e tutto funziona bene ora che ho riavviato il sistema. Grazie per tutti i suggerimenti. È molto apprezzato

Potrebbe essere ovvio, ma sei un utente "root" quando cerchi di farlo? / mnt è di proprietà di root e scrivibile solo da root. È inoltre possibile verificare se si sono verificati errori all'avvio. L'output sopra dice che / (e quindi / mnt) dovrebbe essere rimontato in lettura solo se il processo di avvio rileva errori. Puoi cambiarlo (cioè rimontarlo come r / w) con il comando mount, ma non lo farei se non sei sicuro che qualunque cosa abbia causato l'errore non è grave.