Ubuntu: Upgrade to 16.04 unable to boot, read-only root filesystem, modified grub


This is totally goof (IMHO). I upgraded one computer to 16.04 (Xubuntu), and had issues with it that I discussed elsewhere read here. So I waited a few weeks until I got that computer running well enough, and then upgraded my other computer, a 2006 vintage single core. Once the upgrade was installed, I was not able to boot into Xubuntu. I tried the tricks I did for my first computer, I think the most useful was replacing "quiet mode" with "nomodeset" in /boot/grub/grub.cfg. All this did was boot me to a command line interface. Once I logged in, I found that I could not run startx to initiate the GUI desktop environment. Hmmm... Some more hunting around and trying different things, and I found my root partition was in read-only mode. I found that I could rectify that with the command

sudo mount -o remount,rw /  

Once I did this, the system immediately came up into the GUI desktop environment (although without the graphics driver and in reduced resolution). Hurray! Unfortunately, this only lasts for the current boot. Every time I boot, I'm at the command line and I have to reissue this command. Not a solution.

In researching this, most of the posts point to the /etc/fstab file, and points to the option for the root filesystem


And that this option is for your protection, because something is wrong with the root filesystem and you shouldn't write to it, and in fact you'd better back it up, because it's on the way out. Run a fsck on it. Well, I find it suspicious that this occurs immediately after an upgrade. Also, this is on a relatively new SSD, and I'm told not to run fsck on it anyway. But I can remove that option, and the root filesystem still comes up in read-only mode, so this wasn't a fstab issue.

Something else occurred to me. In the grub file, the launch line is

linux   /vmlinuz-4.4.0-38-generic root=/dev/mapper/vg_ssd1-xubu_root_ssd1 ro  nomodeset $vt_handoff  

Just before "nomodeset" (changed from "quiet splash") is "ro". Is Grug booting my root system into read-only mode? I changed the "ro" to "rw", and also changed "nomodeset" back to "quiet splash", saved the file, and rebooted. It came up fine in graphics mode at the correct resolution.

Hmmm.... I ran

sudo upgrade-grub   

to rebuild the grub.cfg file. Again, the launch line was changed back to "ro", and would again reboot to the command line.

Was my upgrade incomplete? I ran the following commands to verify a complete upgrade, and sure enough additional stuff was installed:

sudo apt-get -f install  sudo apt-get update  sudo apt-get dist-upgrade  sudo apt-get autoremove  sudo apt-get clean  

I again ran

sudo upgrade-grub   

but again it came back that the launch line was set to "ro".

So I did some more searching around. I looked in the file /etc/grub.d/10_linux, and did a search for " ro ". I found the following code snippet:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then    sed "s/^/$submenu_indentation/" << EOF    linux ${rel_dirname}/${basename}.efi.signed root=${linux_root_device_thisversion} ro ${args}  EOF  else    sed "s/^/$submenu_indentation/" << EOF    linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}  EOF  

I had to look up what the efi signed stuff is about, and that's about a secure boot that protects your system from malware in the boot sector. So is my BIOS boot partition infected? I do have a version of Windows XP on the system, although it doesn't get run much anymore.

But then, the "ro" status is implemented on either side of the if statement. I did some playing around, and found it was the "else" condition that was getting implemented. So I changed this from "ro" to "rw", so now the whole snippet looks like this:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then    sed "s/^/$submenu_indentation/" << EOF    linux ${rel_dirname}/${basename}.efi.signed  root=${linux_root_device_thisversion} ro ${args}  EOF  else    sed "s/^/$submenu_indentation/" << EOF    linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} rw ${args}  EOF  

I reran


And everything came out fine. I inspected the launch line in grub.cfg, and it has "rw" rather than "ro".

linux   /vmlinuz-4.4.0-38-generic root=/dev/mapper/vg_ssd1-xubu_root_ssd1 rw  nomodeset $vt_handoff  

I rebooted, and everything came up fine. So I would say problem solved, but I don't think it is. I don't think this is just a bug in Grub. Some other Linux systems found by the os-prober had launch lines that didn't specify either "rw" or "ro".

I don't get what's going on here, and why it defaulted to "ro" in the first place. If anyone can shed some insight into this, and a better fix for this problem, I'd greatly appreciate it.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »