Ubuntu VM виправити лише файлову систему?

Я збирався встановити інструменти VMWare на віртуальній машині сервера Ubuntu, але я зіткнувся з проблемою неможливості створення каталогу cdrom у каталозі / mnt. Потім я перевірив, чи це лише проблема з дозволом, але я навіть не зміг створити папку в домашньому каталозі. Він продовжує стверджувати, що це файлова система лише для читання. Я мало знаю про Linux, і мені це ще не комфортно. Будь-яка порада буде дуже вдячна.

Запитана інформація з коментаря:

ім'я користувача @ ім'я сервера : ~ $ mount
/ dev / sda1 on / type ext4 (rw, помилки = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / type type fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / type type securityfs (rw)
udev on / dev типу tmpfs (rw, mode = 0755)
none on / dev / pts типу devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm типу tmpfs (rw, nosuid, nodev)
немає на / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
немає в / lib / init / rw типу tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc типу binfmt_misc (rw, noexec, nosuid, nodev)

Для впевненого кореневого виводу.

root @ server01: ~ # mount
/ dev / sda1 on / type ext4 (rw, помилки = remount-ro)
proc on / proc type proc (rw)
none on / sys type sysfs (rw, noexec, nosuid, nodev)
none on / sys / fs / fuse / type type fusectl (rw)
none on / sys / kernel / debug type debugfs (rw)
none on / sys / kernel / type type securityfs (rw)
udev on / dev типу tmpfs (rw, mode = 0755)
none on / dev / pts типу devpts (rw, noexec, nosuid, gid = 5, mode = 0620)
none on / dev / shm типу tmpfs (rw, nosuid, nodev)
немає на / var / run type tmpfs (rw , nosuid, mode = 0755)
none on / var / lock type tmpfs (rw, noexec, nosuid, nodev)
немає в / lib / init / rw типу tmpfs (rw, nosuid, mode = 0755) binfmt_misc on / proc / sys / fs / binfmt_misc типу binfmt_misc (rw, noexec, nosuid, nodev)

Хоча це відносно старе питання, відповідь все одно. У вас віртуальна машина (працює на фізичному хості) і якийсь сховище (або спільне сховище - FC SAN, сховище iSCSI, NFS-спільний доступ, або локальне сховище).

За допомогою віртуалізації багато віртуальних машин намагаються отримати доступ до тих самих фізичних ресурсів одночасно. Через фізичні обмеження (кількість операцій читання / запису - IOPS; пропускна здатність; затримка) може виникнути проблема задоволення всіх запитів на зберігання всіх фізичних машин одночасно. Що зазвичай буває: ви зможете побачити "повторні спроби SCSI" та невдалі операції SCSI в операційних системах ваших віртуальних машин. Якщо ви отримаєте занадто багато помилок / спроб за певний проміжок часу, ядро ​​встановить змонтовані файлові системи лише для читання, щоб уникнути пошкодження файлової системи.

Якщо коротко сказати: ваше фізичне сховище недостатньо "потужне". Занадто багато процесів (віртуальних машин) одночасно отримує доступ до системи зберігання, ваші віртуальні машини не отримують відповідь зі сховища досить швидко, а файлова система переходить у режим лише для читання.

Немає надзвичайно багато речей, які ти можеш зробити. Очевидне рішення - краще / додаткове зберігання. Ви також можете змінити параметри для тайм-аутів SCSI в ядрі Linux. Деталі описані, наприклад, у:

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

Однак це лише "відкладе" ваші проблеми, оскільки ядро ​​отримує більше часу, перш ніж файлова система буде встановлена ​​лише для читання. (Тобто ви не вирішуєте причину проблеми.)

Мій досвід (кілька років з VMware) полягає в тому, що ця проблема існує лише з ядрами Linux (ми використовуємо RHEL і SLES), а не з серверами Windows. Також ця проблема виникає на всіляких сховищах - FC, iSCSI, локальних сховищах. Для нас найважливішим (і дорогим) компонентом нашої віртуальної інфраструктури є зберігання. (Зараз ми використовуємо HP LeftHand з підключеннями iSCSI 1 Гбіт / с, і з тих пір не виникало проблем із зберіганням. Ми вибрали LeftHand (над традиційними рішеннями FC) для його масштабованості.

Ймовірно, пояснення полягає в тому, що існує проблема апаратного забезпечення (частковий збій диска) і що ядро ​​перепрограмувало кореневу файлову систему як лише для читання, як тільки виявило проблему, щоб мінімізувати проблему. Більш надійним способом перевірити поточні параметри монтажу є cat /proc/mounts( grep ' / ' /proc/mountsдля кореневої файлової системи ігноруйте rootfs / …рядок, який є артефактом процесу завантаження). Ви, мабуть, знайдете, що rw,errors=remount-roзмінилося на ro(додатково можуть відображатися інші параметри).

Журнали ядра, ймовірно, містять повідомлення Remounting filesystem read-only, якому передують помилки доступу до диска. Журнали зазвичай живуть /var/log/kern.log, однак якщо це у файловій системі, що лише для читання, повідомлення там не відображатиметься, хоча попередні помилки повинні. Ви також можете побачити останні останні помилки ядра з dmesgкомандою.

Крім Ubuntu, під Ubuntu зазвичай знаходиться місце /media(наприклад /media/cdrom0, інтерфейс робочого столу), звичайне місце для монтажу (наприклад ), хоча ви можете використовувати /mntабо /mnt/cdromякщо хочете.

¹ _{звіти від . Якщо коренева файлова система доступна лише для читання, вона не може бути оновлена. mount/etc/mtab/etc/mtab}

Що трапилося, нещодавно у центрі обробки даних стався відключення електроенергії. З тих пір я не торкався свого сервера. Після того, як наш центр обробки даних втрачає живлення, VSphere робить файлову систему Ubuntu лише для читання до її перезавантаження. Я б спробував перезапустити, але я не хотів, щоб весь моніторинг зійшов з розуму. Я замовкнув Nagios (служба моніторингу), і все працює нормально, коли я перезапустив систему. Дякую за весь вклад Це дуже цінується.

Можливо, це буде очевидно, але ви "root" користувач, намагаючись це зробити? / mnt є власністю root та лише для кореневого запису. Ви також можете перевірити, чи були помилки під час завантаження. Наведений вище висновок говорить про те, що / (і, таким чином, / mnt) слід перечитати читання, лише якщо процес завантаження бачить помилки. Ви можете змінити це (тобто перерахувати як r / w) за допомогою команди mount, але я б цього не робив, якщо ви не впевнені, що все, що спричинило помилку, не є серйозним.