Сервер X11 не запускается - защищенная от записи файловая система

Недавно я установил Ubuntu Mate 19.04 на свой MacBook Pro (арка x86_64). После того, как моя система перешла в спящий режим, корневая файловая система (подключенная к ext4) была повреждена. Первоначально, запуск перешел бы на оболочку BusyBox. Если я правильно помню, я смог запустить fsck из BusyBox в корневой файловой системе. После этого я смог загрузить систему, но сервер X11 не запустился, поэтому я остался в оболочке командной строки. Я проверил список служб и сосредоточился на следующем:

# service --status-all
...
[ + ]  lightdm
...
[ - ]  x11-common

Перезапуск службы lightdm (service lightdm restart) ничего не сделал. При попытке запустить общую службу x11 (service x11-common start), если я правильно помню ошибку, сообщается, что /lib/systemd/system/x11-common.service было "затенено" ( Редактировать: I посмотрел правильный термин, он был «замаскирован») . Посмотрев на ошибку, я обнаружил сообщения, что это означало, что /lib/systemd/system/x11-common.service была символической ссылкой на /dev/null. Это оказалось так. Было дано решение удалить /lib/systemd/system/x11-common.service. Пытаясь это сделать, я обнаружил, что файловая система все еще содержит ошибки и не может быть смонтирована для чтения-записи. В конце концов я загрузился на live CD / USB, запустил fsck/e2fsck в файловой системе, затем подключил раздел локального диска для чтения-записи и удалил файл. После перезагрузки я обнаружил, что он по-прежнему сбрасывает меня в оболочку командной строки. Теперь запуск службы x11-common не сообщил об ошибке, но все равно не запустил сервер X11. Похоже, что служба x11-common сейчас запущена:

# service --status-all
...
[ + ]  lightdm
...
[ + ]  x11-common

Но я все еще не могу войти в графический режим X11. Независимо от того, очищаю ли я файловую систему через fsck на live CD / USB, меня всегда переносят в терминал, а файловая система помечается как защищенная от записи. Попытка перемонтирования не работает:

# mount -o remount,rw /

mount: /: cannot remount /dev/sda2 read-write, is write-protected

Я не могу принудительно размонтировать либо:

# umount -f /

# mount | grep sda

/dev/sda2 on / type ext4 (ro,relatime,errors=remount-ro)
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

Входя в свою учетную запись пользователя, я пытаюсь запустить xinit, но это не удается:

$ sudo xinit

(EE)
Fatal server error:
(EE) Could not create lock file in /tmp/.tX0-lock
(EE)
(EE)
Please consult the The X.Org Foundation support
    at http://wiki.x.org
 for help.
(EE)
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

Очевидно, потому что файловая система доступна только для чтения. startx завершается с той же ошибкой. Переустановка возможна, но если это будет продолжаться, я бы хотел исправить ее, не выполняя каждый раз новую переустановку.

1131 Если у кого-то есть понимание моей проблемы, я был бы очень признателен. Как только я это исправлю, я начну работать над тем, что привело к повреждению файловой системы, когда система перешла в спящий режим.

Номер модели на моем MacBook - A1226. Как следует из этого сайта , это одна из трех возможных систем с процессором Core 2 Duo 2,2 ГГц, 2,4 ГГц или 2,6 ГГц, построенного в 2007 году. Это система x86_64, не PowerPC.

Редактировать: Я также пытался исправить файловую систему, запустив fsck из режима восстановления Ubuntu, с помощью опции меню и , вызвав корневую оболочку и запустив ее вручную, но безуспешно , Насколько я понимаю, это эквивалентно запуску live CD / USB и запуску fsck в файловой системе.

-1
задан 5 October 2019 в 01:43

1 ответ

Моя проблема была разрешена, & по-видимому, был разрешен где-нибудь на шагах, которые я сделал упомянутый в моем вопросе. Причина я получал результаты, которые я сделал, кажется, была связана с ручной записью, которую я имел в загрузчике GRUB2.

После того, как я первоначально установил ПОМОЩНИКА Ubuntu на своем MacBook, я испытывал затруднения при начальной загрузке в систему. Заморозилось бы даже, прежде чем Плимутский экран-заставка был загружен. Исходная строка ядра в записи меню GRUB2 была следующие:

linux    /boot/vmlinuz-5.0.0-29-generic root=UUID=<UUID> ro  quiet splash $vt_handoff

я пришел к выводу, что эти $vt_handoff значение вызывало проблему. Удаление его от строки позволило системе загружаться. Так, я вручную создал запись в GRUB2, который опустил $vt_handoff, & я также добавил nomodeset опция. Когда моя система отказала, я продолжал пытаться загрузить использование этой ручной записи & я продолжал застревать в tty терминале. Вскоре после регистрации моего вопроса я вошел в исходную GRUB2 запись меню & добавленный nomodeset опция так чтение строки следующим образом:

linux    /boot/vmlinuz-5.0.0-29-generic root=UUID=<UUID> ro  quiet splash nomodeset $vt_handoff

Теперь прекрасные начальные загрузки системы. В конце ответ должен был иметь и nomodeset и $vt_handoff существующий в строке ввода меню GRUB2. Я не могу сказать, что понимаю , почему это происходило & , почему добавление nomodeset решило проблему, но это сделало. Я уверен, что это не будет ответом для всех, но надо надеяться он помогает кому-то еще.

Примечание: Моя первая проблема, когда я не мог заставить систему загружаться после начальной установки, кажется, то же или подобный этот вопрос . Не уверенный, если моя система имеет чипсет графики Nvidia.

Редактирование: После того, как я смог загрузиться с выполнением X-сервера, файловая система была все еще повреждена & отмеченный защищенный от записи. Я просто сделал другой перезапуск & это решило вопрос. Корневая файловая система является теперь чистым & смонтированный как чтение-запись.

0
ответ дан 23 October 2019 в 09:48

Другие вопросы по тегам:

Похожие вопросы: