Недавно я установил 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
было "затенено" del> ( Редактировать: 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
завершается с той же ошибкой. Переустановка возможна, но если это будет продолжаться, я бы хотел исправить ее, не выполняя каждый раз новую переустановку.
Номер модели на моем MacBook - A1226. Как следует из этого сайта , это одна из трех возможных систем с процессором Core 2 Duo 2,2 ГГц, 2,4 ГГц или 2,6 ГГц, построенного в 2007 году. Это система x86_64, не PowerPC.
Редактировать: Я также пытался исправить файловую систему, запустив fsck
из режима восстановления Ubuntu, с помощью опции меню и , вызвав корневую оболочку и запустив ее вручную, но безуспешно , Насколько я понимаю, это эквивалентно запуску live CD / USB и запуску fsck
в файловой системе.
Моя проблема была разрешена, & по-видимому, был разрешен где-нибудь на шагах, которые я сделал упомянутый в моем вопросе. Причина я получал результаты, которые я сделал, кажется, была связана с ручной записью, которую я имел в загрузчике 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-сервера, файловая система была все еще повреждена & отмеченный защищенный от записи. Я просто сделал другой перезапуск & это решило вопрос. Корневая файловая система является теперь чистым & смонтированный как чтение-запись.