0

My cloud server hosted in Rackspace stopped working after I installed some GUI application in Ubuntu 12.04 which automatically installed it's dependency package ubuntu-desktop (or some other similar (GUI) package).

Actually, that happened 2 weeks ago.

But today is the first time I'm rebooting my server after ubuntu-desktop (or a similar package) was installed, and I realized the webserver cannot boot as it does not have enough RAM to load the GUI (and it doesn't have a graphical device neither) - It frezes after printing "Loading Boot screen" (or something like that) into the terminal.

To fix it, I have access to Rescue Mode in Rackspace, where I can access the filesystem of my server without actually booting it, so I can tweak configs here and there before turning it on.

I did some research and saw that I can force console mode changing Grub configuration from GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="text". But this change requires running update-grub which I can't, because I can only access the server filesystem, but not log into it to run commands.

Do you guys understand my problem? Am I clear enough? Sorry about my bad English, i'm still learning it.

So, here's my question:

How can I update grub without being logged in a server? Is that even possible? If not, is there any other way to force boot into text mode by only tweaking configuration files and thus not having to log into the server?

Thanks.

Improve this question

3 Answers 3

Reset to default
3

Yay!

I got it to work by manually editing /boot/grub/grub.cfg on the mounted filesystem and replacing the single occurrence of "quiet splash" to "text". That way, update-grub was not needed.

It's not an elegant solution, but it worked.

Now I'm able to connect normally through SSH to my server again. I'll later run update-grub so I can make sure this manual file edit won't have any side effects.

So, here's what I learned today: don't install a GUI on those cheap low performance cloud servers because they won't have enough resources to boot, making things difficult to fix.

Improve this answer
4
  • you shouldn't have to run update-grub. The manual edit should be just fine.
    – mdpc
    Oct 26, 2012 at 20:17
  • Thanks @mdpc. Is grub.conf just an intermediate configuration file for the sake of organization and clearness? Is it always safe to make changes directly into grub.cfg?
    – pagliuca
    Oct 26, 2012 at 20:26
  • grub.cfg is the control file that grub consults as it runs through its paces at reboot.
    – mdpc
    Oct 26, 2012 at 20:27
  • grub.cfg is completely generated by update-grub, so any changes you make there will get overwritten. Your solution of editing grub.cfg to get the system to boot and then running update-grub is correct though.
    – mgorven
    Oct 26, 2012 at 22:54
0

Hmmm.....Is rescue mode basically a Linux single user root shell? If so, try running the program from the mounted filesystem. I assume that your mounted disk contains the /boot area.

There also might be a grub on the rescue image for you to run to fix the external disk.

At worse, contact Rackspace for guidance.

Improve this answer
2
  • First: the Rescue Mode is a different server that I loggin as root, that I can access my regular filesystem by mounting it. But running update-grub will only update the grub for this specific "Rescue Mode special server", not my real server. The bad thing is that I don't have the Rackspace managed plan, as they won't fix stuff inside my server, you know? I have to pay more for them to do that.
    – pagliuca
    Oct 26, 2012 at 19:02
  • I don't know if I was clear, but after logging into the special Rescue Mode server, I can mount my regular filesystem in, as an example, /mnt/regular_fs. So my grub config is at /mnt/regular_fs/etc/default/grub and my boot folder is at /mnt/regular_fs/boot so if I run udpate_grub it will not know that I want to update the regular_fs config.
    – pagliuca
    Oct 26, 2012 at 19:05
0

Can you log into the host via single-user mode? That should interrupt the attempt at a GUI and give you an opportunity to edit grub.conf and run update-grub.

Also, check your /etc/inittab, if your OS uses that functionality. You may be able to set your default runlevel to a non-GUI value. See Section 10.4.2 of the RHEL6 Installation Guide for one example.

Good luck!

Improve this answer
2
  • Thanks. Right now, the server is checking filsystem for errors (due to the many reboots I went through in the past few hours), so I can't test your suggestions. When the filesystem check is completed, I'll try them.
    – pagliuca
    Oct 26, 2012 at 19:25
  • I couldn't get to test your solutions, because my system booted just fine after the filesystem check, because of the changes I made in /boot/grub/grub.cfg. Right now, I rather not mess with that again, because my webservices stood offline for a long time today (~ 3 hours). Thanks for your help, tho.
    – pagliuca
    Oct 26, 2012 at 20:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .