4

My /etc/default/grub is as follows - see image - but the VM is booting into the GUI. Why?

screenshot

1

The myth of the text kernel parameter

It has passed around as system administrator folklore over the past few years that there's a standard kernel parameter for Linux, specificable from whatever boot loader one is using, by the name of text; and that specifying that parameter at bootstrap time ensures that the system comes up in multi-user mode with networking but without the graphical user interface — what on some systems with System 5 init used to be a distinct run level that one could choose at bootstrap time.

"If you are using GRUB", say hundreds of web logs, tutorials, discussion fora postings, and even Stack Exchange answers such as this one and this one and this one; "then you specify the text kernel parameter by adding it to the contents of the GRUB_CMDLINE_LINUX_DEFAULT setting in /etc/default/grub, or you just edit the kernel command line interactively from the GRUB menu and add text there."

This is not a widely used kernel parameter. It's a bodge that only works —

  • on Ubuntu Linux, with GDM, when upstart is in charge of system services;
  • on Debian Linux, with GDM, when System V rc is in charge of system services.

This is because it's a piece of shell script that checks every word on the kernel parameter list looking for one that reads text or s or single. On Ubuntu Linux it lives in the upstart job unit for GDM. On Debian Linux it lives in the old System V rc script for GDM. It's not a part of GDM proper. Nor is it a general convention.

People have already, long since (as in this 2011 AskUbuntu answer for just one example), spotted that Ubuntu with LightDM or KDM instead of GDM didn't obey this parameter. A similar upstart job file bodge was added for LightDM. With the switch from upstart to systemd in version 15, people are spotting, as you have, that this now doesn't work at all.

It's time to consign this bodge to the dustbin of history. Run levels have been a backwards compatibility measure on Ubuntu Linux for almost a decade, now. And that's for the system manager before the current default one. systemd doco actually explicitly describes them as "obsolete". They aren't the way to think about things. Ironically, "single-user mode" has been obsolete for far longer, almost twice as long indeed. It was superseded by a split "rescue mode" and "emergency mode" model in the middle 1990s when init gained its -b option.

The -b switch will be passed through LILO to init and will cause an emergency boot [...]

— David A. Bandel (1997-01-01). Disk Maintenance under Linux.. Linux Journal.

There's even more detail on the sorry tale of this bodge in Ubuntu bug #436936.

Doing things right

The right way to approach this is to think of it as an ordinary exercise in service management. The display manager is, after all, started by upstart or by systemd as service. So just use the standard service management tools to deal with it.

The systemd people, for one, opine (as Lennart Poettering does) that special-case shell-scripted logic for services to self-disable using idiosyncratic per-subsystem knobs of this sort is a bad idea. The better idea is to use the general cross-service knobs that the service management systems themselves provide.

upstart

As mentioned in detail elsewhere, with upstart one changes the relevant service to be a manually-started service, by adding the manual stanza to the job with

echo manual >> /etc/init/lightdm.override
One changes it back by editing that stanza out, or simply deleting the override (if it contains nothing else) with

rm /etc/init/lightdm.override
Substitute /etc/init/gdm.override as appropriate.

systemd

default.target is what systemd normally starts at bootstrap, in non-rescue non-emergency mode. This is an alias that points at one's choice of real target to start. Once choice is graphical.target, which in its turn causes whatever display manager one has chosen to be started. Display managers are services that are enabled/disabled by making them "wanted" by graphical.target.

You stop systemd from starting up graphical.target (and thus any display manager at all, whichever ones have actually been enabled) by pointing default.target to multi-user.target instead, with

systemctl set-default --force multi-user.target

You perform a once-off non-persistent override by using a systemd-specific kernel parameter, added to the kernel command line from the GRUB menu as before:

systemd.unit=multi-user.target

You can also enable/disable specific display managers by enabling/disabling their services. Enables only have effect when graphical.target is the default, of course. To disable GDM, for example:

systemctl disable gdm.service

nosh

nosh has a GDM service bundle "in the box", and one does the same with it as afore:

system-control disable gdm
There is a graphics target, but it has no effect in nosh versions up to version 1.23.

Further reading

| improve this answer | |
0

If I can understand you well, you want to simply boot to a non-graphical (console) interface by default

You can simply run the following commands. I ran them in VM (15.10) minutes ago and it worked well:

Switching run-level:

sudo systemctl set-default multi-user.target --force

Disable LightDM (Ubuntu's Desktop Manager)

sudo systemctl disable lightdm.service --force

Disable GUI completely

sudo systemctl disable graphical.target --force

Disable loading screen at boot

sudo systemctl disable plymouth.service --force

Source

Armand

| improve this answer | |
  • 1
    I wanted to understand why editing /etc/default/grub didn't work. Not sure what those command you suggested mean but thanks for trying to help! – user482637 Dec 15 '15 at 12:15
  • @user137810 It's a possible alternative solution if the GRUB editing would not work. But for GRUB: Remove the # before the GRUB_CMDLINE_LINUX_DEFAULT line then save then run sudo update-grub – Armand Bozsik Dec 15 '15 at 13:58
  • 1
    Your above commands worked. Thanks. I will look at the Source and discover those more. But I wanted to know what was wrong with the grub file. Why isn't it booting in text-mode with the alterations in the grub file? – user482637 Dec 15 '15 at 20:51
  • What version of Ubuntu are you using exactly? I tried editing grub too, but it seems after 15.04 they changed to systemd/systemctl permanently, so just this method works. wiki.ubuntu.com/VividVervet/ReleaseNotes ubuntuforums.org/showthread.php?t=2276909 (sandyd's comment) – Armand Bozsik Dec 16 '15 at 9:34
  • If you found any of our answer helpful please mark as accepted. Thanks. – Armand Bozsik Dec 17 '15 at 10:27

Your Answer

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