0

I recently installed Ubuntu Mate 19.04 on my MacBook Pro (x86_64 arch). After my system went into hibernation, the root filesystem (ext4 mounted on /) became corrupted. Initially, startup would drop to a BusyBox shell. If I remember correctly, I was able to run fsck from BusyBox on the root filesystem. I was then able to boot up into the system, but the X11 server would not start so I was left in a command line shell. I checked the list of services & focused on the following:

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

Restarting the lightdm service (service lightdm restart) did nothing. Trying to start the x11-common service (service x11-common start) reported, if I remember the error correctly, that /lib/systemd/system/x11-common.service was "shadowed" (Edit: I looked up the correct term, it was "masked"). Looking up the error, I found reports that it meant that /lib/systemd/system/x11-common.service was a symbolic link to /dev/null. This turned out to be the case. The resolution that was given was to delete /lib/systemd/system/x11-common.service. Trying to do so, I found that the filesystem still contained errors & couldn't be mounted read-write. I eventually booted into a live CD/USB, ran fsck/e2fsck on the filesystem then mounted the local disk partition in read-write & deleted the file. After rebooting, I found that it was still dropping me to the command line shell. Now starting the x11-common service didn't report any error, but still didn't launch the X11 server. It appears that the x11-common service is now running:

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

But I still cannot get into the X11 graphics mode. No matter if I clean the filesystem via fsck in a live CD/USB, I am always dropped to a terminal & the filesystem is marked write-protected. Trying to remount does not work:

# mount -o remount,rw /

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

I cannot force unmount either:

# 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)

Logging into my user account, I try to run xinit but it fails:

$ 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

Obviously because the filesystem is read-only. startx fails with the same error. Re-installing is an option, but if this continues to occur I would like to be able to fix it without doing a fresh re-install every time.

If anyone has some insight into my problem I would much appreciate it. Once I get this fixed, I will work on what caused the filesystem to be corrupted in the first place when the system went into hibernation.

The model number on my MacBook is A1226. It appears from this site, it is one of three possible systems with either a 2.2GHz, 2.4GHz, or 2.6GHz Core 2 Duo CPU built in 2007. This is an x86_64 system, not a PowerPC.

Edit: I also tried to fix the filesystem by running fsck from Ubuntu's recovery mode, via the menu option and dropping to a root shell & running manually, without success. As I understand it, this is equivalent to running a live CD/USB & running fsck on the filesystem.

  • Isn't the real issue that your filesystem is corrupted? Stop booting from that drive, and use a recovery disk immediately! Copy your files to a backup, then find out what the issue is, and whether it was due to a hardware failure or not. – jpaugh Sep 30 '19 at 22:04
  • I didn't realize it, but it's a combination of issues. 1) X11 server wasn't starting 2) filesystem is corrupted (perhaps causing X11 to fail initially). The X11 server is now starting, but the filesystem is still corrupted/write-protected. As stated in my question, I already used a live CD/USB to fix the filesystem which reports that it repaired the filesystem. But still it is marked as write-protected when I boot from the internal hard drive. I will attempt using a live CD/USB once again though. I do not need to back anything up as this is a new installation. – AntumDeluge Sep 30 '19 at 22:53
  • I just did another restart after I got X11 working (didn't run live CD/USB yet) & filesystem is no longer corrupted. Just seems I needed to do one last restart to finalize the fix. I don't understand why, but that's what happened: /dev/sda2 on / type ext4 (rw,relatime,errors=remount-ro). – AntumDeluge Sep 30 '19 at 22:57
0

My problem has been resolved, & apparently had been resolved somewhere in the steps I took mentioned in my question. The reason I was getting the results that I did appears to have been related to a manual entry that I had in the GRUB2 bootloader.

After I initially installed Ubuntu MATE on my MacBook, I was having trouble booting into the system. It would freeze even before the Plymouth splash screen was loaded. The original kernel line in the GRUB2 menu entry was as follows:

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

I came to the conclusion that the $vt_handoff value was causing the problem. Removing it from the line allowed the system to boot. So, I manually created an entry in GRUB2 that omitted $vt_handoff, & I also added the nomodeset option. When my system crashed, I continued to try to boot using this manual entry & I kept getting stuck in the tty terminal. Not long after posting my question, I went into the original GRUB2 menu entry & added the nomodeset option so the line read as follows:

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

Now the system boots fine. In the end, the answer was to have both nomodeset and $vt_handoff present in the GRUB2 menu entry line. I can't say I understand why this was happening & why adding nomodeset fixed the problem, but it did. I'm sure this won't be the answer for everyone, but hopefully it helps somebody else.

Note: My first problem when I couldn't get the system to boot after the initial installation appears to be the same or similar to this question. Not sure if my system has an nVidia graphics chipset.

Edit: After I was able to boot up with the X server running, the filesystem was still corrupted & marked write-protected. I simply did another restart & it resolved the issue. Root filesystem is now clean & mounted as read-write.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.