Ubuntu VM „naprawia system plików tylko do odczytu”?

Zamierzałem zainstalować narzędzia VMWare na maszynie wirtualnej serwera Ubuntu, ale natknąłem się na problem z niemożnością utworzenia katalogu cdrom w katalogu / mnt. Następnie przetestowałem, czy to tylko kwestia uprawnień, ale nie mogłem nawet utworzyć folderu w katalogu domowym. Nadal stwierdza, że ​​jest to system plików tylko do odczytu. Wiem trochę o Linuksie i jeszcze mi się nie podoba. Wszelkie porady będą mile widziane.

Żądane informacje z komentarza:

nazwa użytkownika @ nazwa serwera : ~ $ mount
/ dev / sda1 on / type ext4 (rw, error = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connection type 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)
none on / dev / pts type devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm type tmpfs (rw, nosuid, nodev)
none on / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
none on / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc type binfmt_misc (rw, noexec, nosuid, nodev)

Na pewno wyjście root.

root @ server01: ~ # mount
/ dev / sda1 on / type ext4 (rw, error = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / connection type 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)
none on / dev / pts type devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm type tmpfs (rw, nosuid, nodev)
none on / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
none on / lib / init / rw type tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc type binfmt_misc (rw, noexec, nosuid, nodev)

Chociaż jest to stosunkowo stare pytanie, odpowiedź jest nadal taka sama. Masz maszynę wirtualną (działającą na hoście fizycznym) i jakiś rodzaj pamięci (pamięć współdzieloną - FC SAN, pamięć iSCSI, udział NFS - lub pamięć lokalna).

Dzięki wirtualizacji wiele maszyn wirtualnych próbuje uzyskać dostęp do tych samych zasobów fizycznych w tym samym czasie. Ze względu na ograniczenia fizyczne (liczba operacji odczytu / zapisu - IOPS; przepustowość; opóźnienie) może wystąpić problem z zaspokojeniem wszystkich żądań pamięci wszystkich maszyn fizycznych w tym samym czasie. Co zwykle się dzieje: w systemach operacyjnych maszyn wirtualnych będą widoczne „Ponowne próby SCSI” i nieudane operacje SCSI. Jeśli w określonym czasie pojawi się zbyt wiele błędów / ponownych prób, jądro ustawi zamontowane systemy plików tylko do odczytu, aby zapobiec uszkodzeniu systemu plików.

Krótko mówiąc: Twoja pamięć fizyczna nie jest wystarczająco „mocna”. Jednocześnie zbyt wiele procesów (maszyn wirtualnych) uzyskuje dostęp do systemu pamięci masowej, maszyny wirtualne nie otrzymują odpowiedzi z pamięci wystarczająco szybko, a system plików przechodzi tylko do odczytu.

Niewiele rzeczy można zrobić. Oczywistym rozwiązaniem jest lepsze / dodatkowe miejsce do przechowywania. Możesz także zmodyfikować parametry limitów czasu SCSI w jądrze Linux. Szczegóły opisano np. W:

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

Spowoduje to jednak jedynie „odłożenie” problemów, ponieważ jądro ma więcej czasu, zanim system plików zostanie ustawiony jako tylko do odczytu. (Tj. Nie rozwiązujesz przyczyny problemu).

Moje doświadczenie (kilka lat z VMware) polega na tym, że ten problem występuje tylko w jądrach Linuksa (używamy RHEL i SLES), a nie w serwerach Windows. Ponadto ten problem występuje na wszystkich rodzajach pamięci - FC, iSCSI, pamięć lokalna. Dla nas najważniejszym (i najdroższym) elementem naszej infrastruktury wirtualnej jest pamięć masowa. (Używamy teraz HP LeftHand z połączeniami iSCSI 1 Gb / s i od tego czasu nie mieliśmy żadnych problemów z pamięcią. Wybraliśmy LeftHand (w porównaniu z tradycyjnymi rozwiązaniami FC) ze względu na jego skalowalność.

Prawdopodobnym wyjaśnieniem jest problem sprzętowy (częściowa awaria dysku) oraz że jądro ponownie zamontowało główny system plików jako tylko do odczytu, gdy tylko wykryje problem, aby zminimalizować problem. Bardziej niezawodnym¹ sposobem sprawdzenia bieżących opcji montowania jest cat /proc/mounts( grep ' / ' /proc/mountsw przypadku głównego systemu plików zignoruj rootfs / …wiersz będący artefaktem procesu rozruchu). Prawdopodobnie okaże się, że rw,errors=remount-rozmieniło się na ro(inne opcje mogą być wyświetlane dodatkowo).

Dzienniki jądra prawdopodobnie zawierają komunikat Remounting filesystem read-onlypoprzedzony błędami dostępu do dysku. Dzienniki zwykle znajdują się w /var/log/kern.logsystemie, jednak jeśli jest to system plików tylko do odczytu, komunikat się tam nie pojawi, chociaż poprzednie błędy powinny. Za pomocą polecenia można również zobaczyć kilka ostatnich błędów jądra dmesg.

Nawiasem mówiąc, w Ubuntu, zwykłe miejsce dla punktów montowania (używane przez interfejs pulpitu) znajduje się pod /media(np. /media/cdrom0), Chociaż możesz użyć /mntlub /mnt/cdromjeśli chcesz.

¹ _{raporty z . Jeśli główny system plików jest tylko do odczytu, nie można go aktualizować. mount/etc/mtab/etc/mtab}

Stało się tak, że ostatnio doszło do awarii zasilania w centrum danych. Od tego czasu nie dotknąłem mojego serwera. Kiedy nasze centrum danych traci moc, VSphere sprawia, że ​​system plików Ubuntu jest odczytywany tylko do momentu ponownego uruchomienia. Spróbowałbym zrestartować komputer, ale nie chciałem, żeby cały monitoring zwariował. Uciszyłem Nagios (usługa monitorowania) i po ponownym uruchomieniu systemu wszystko działa dobrze. Dzięki za cały wkład. To jest bardzo cenione.

Może to być oczywiste, ale czy jesteś użytkownikiem „root”, gdy próbujesz to zrobić? / mnt jest własnością root i może być zapisywany tylko przez root. Możesz także sprawdzić, czy podczas uruchamiania wystąpiły błędy. Powyższe dane wyjściowe mówią, że / (a ​​tym samym / mnt) należy ponownie zamontować tylko do odczytu, jeśli proces rozruchu wykryje błędy. Możesz to zmienić (tj. Ponownie zamontować jako r / w) za pomocą polecenia mount, ale nie zrobiłbym tego, chyba że jesteś pewien, że to, co spowodowało błąd, nie jest poważne.