0

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

errors=remount-ro

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

update-grub

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.

  • If you have WindowsXP installed on your system it should be installed in legacy-mode on MBR-partitioned drive. Xubuntu should be installed in the same mode, mixing legacy nad UEFI almost leads to problems. I wonder where this EFI-things come from in your file /etc/grub.d/10_linux, I don't have this in my file , my Xubuntu is installed in legacy-mode, as I have XP installed too. I think this is a point you should check out... – mook765 Oct 7 '16 at 13:23

Your Answer

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

Browse other questions tagged or ask your own question.