My /etc/default/grub
is as follows - see image - but the VM is booting into the GUI. Why?
-
after making changes, you have to run ''sudo update-grub" command. Are you sure you have done that?– Vasu Dev GargDec 15, 2015 at 11:52
-
Yes, I have. A few times.– user482637Dec 15, 2015 at 11:54
-
refer askubuntu.com/questions/92276/how-do-i-boot-into-true-text-mode– Vasu Dev GargDec 15, 2015 at 12:00
-
This isn't helping. How can I attract more attention to this question?– user482637Dec 15, 2015 at 20:45
2 Answers
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 toinit
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.overrideOne changes it back by editing that stanza out, or simply deleting the override (if it contains nothing else) with
rm /etc/init/lightdm.overrideSubstitute
/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 gdmThere is a
graphics
target, but it has no effect in nosh versions up to version 1.23.
Further reading
- Paul Menzel (2012-06-23). GDM service file for Debian (was: systemd unit files for Debian based systems). systemd-devel.
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
Armand
-
1I 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!– user482637Dec 15, 2015 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 Dec 15, 2015 at 13:58
-
1Your 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?– user482637Dec 15, 2015 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) Dec 16, 2015 at 9:34
-
If you found any of our answer helpful please mark as accepted. Thanks. Dec 17, 2015 at 10:27