X11 服务器无法启动-写保护文件系统

X11 服务器无法启动-写保护文件系统

我最近安装了Ubuntu 伴侣19.04 在我的 MacBook Pro(x86_64 arch)上。系统进入休眠状态后,根文件系统(安装在 / 上的 ext4)损坏。最初,启动会转到 BusyBox shell。如果我没记错的话,我能够fsck从根文件系统上的 BusyBox 运行。然后我能够启动到系统中,但 X11 服务器无法启动,所以我只能留在命令行 shell 中。我检查了服务列表并重点关注以下内容:

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

重新启动 lig​​htdm 服务 ( service lightdm restart) 没有任何效果。尝试启动 x11-common 服务 ( service x11-common start) 时报告错误,如果我没记错的话,那/lib/systemd/system/x11-common.service“阴影” 编辑:我查了正确的术语,它是“masked”)。查找错误,我发现有报告称这意味着这/lib/systemd/system/x11-common.service是一个指向的符号链接/dev/null。事实确实如此。给出的解决方案是删除/lib/systemd/system/x11-common.service。尝试这样做时,我发现文件系统仍然包含错误并且无法以读写方式挂载。我最终启动到实时 CD/USB,fsck/e2fsck在文件系统上运行,然后以读写方式挂载本地磁盘分区并删除该文件。重新启动后,我发现它仍然将我带到命令行 shell。现在启动服务x11-common没有报告任何错误,但仍然没有启动 X11 服务器。看来该x11-common服务现在正在运行:

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

但我仍然无法进入 X11 图形模式。无论我是否通过fsck实时 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。本网站,它是 2007 年制造的三种可能系统之一,分别搭载 2.2GHz、2.4GHz 或 2.6GHz Core 2 Duo CPU。这是一个 x86_64 系统,不是一台 PowerPC。

编辑:我还尝试fsck通过菜单选项从 Ubuntu 的恢复模式运行来修复文件系统降到 root shell 并手动运行,但没有成功。据我所知,这相当于运行实时 CD/USB 并fsck在文件系统上运行。

答案1

我的问题已经解决,显然在我问题中提到的步骤中已经解决了。我得到结果的原因似乎与我在 GRUB2 引导加载程序中的手动输入有关。

在我最初在 MacBook 上安装 Ubuntu MATE 后,我遇到了启动系统的问题。它甚至在 Plymouth 启动画面加载之前就会冻结。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_handoffGRUB2 菜单项行中。我不能说我理解为什么这是正在发生的事情为什么添加nomodeset解决了问题,但确实如此。我确信这不是每个人的答案,但希望它能帮助别人。

笔记:当我在初始安装后无法启动系统时遇到的第一个问题似乎与这个问题。不确定我的系统是否有 nVidia 图形芯片组。

编辑:当我能够在 X 服务器运行时启动时,文件系统仍然损坏并标记为写保护。我只需再次重新启动即可解决问题。根文件系统现在已清理并安装为读写。

相关内容