There are a lot of people asking about kiosk functions, and so it is worth adding a lot of background on the topic. The concepts are actually pretty simple, but the amount of background information needed to tie it all together is “somewhat large”. I’ll answer what I can to get people started with building a kiosk.
- I’m not sure what you mean by the first point, “remove boot loader info…”. Are you speaking of speeding up boot? Or perhaps disabling something for security?
- The second point is one of auto-login. I’m going to suggest that you have a regular admin account, and any auto-login be to a restricted account if this is going to be some public environment and not a place you trust (e.g., if it is for your own use, then just leave the admin auto-login, but if it is in a shopping mall, you certainly want a restricted account). Once you do that, then what @DaneLLL posted will get the application(s) started.
- There are several threads around about splash screens in the boot software, but I’ve not done this myself, so I don’t know the specific details. If it is an X11 GUI login splash you are looking to disable (I don’t know the details of adding a splash to X11’s login), then there is this you can add to the “
/etc/X11/xorg.conf” in Section: "Device":
Section: "Device"
...so here goes...
Option: "NoLogo" true
...
EndSection
It seems like one could add a logo with a “false” version of the above, but I’m not sure where the image is at, nor what specifications there are. This would only be for the GUI part, not the bootloader which is a separate logo.
- Under normal circumstances the behavior of the GUI login is via the login manager, and the behavior of the GUI desktop is via the desktop manager. More about that below.
- There is normally a GUI method to set a desktop background. One could simply set that up, and then look for where the image name is mentioned in the software to find out how/where the GUI app places that image. This is probably also published somewhere if you look up the desktop software manual (this varies depending on Linux distribution, I tend to use KDE and don’t pay much attention to Gnome).
- The desktop config might or might not be the right place to auto-start. @DaneLLL mentioned what is usually used. The desktop GUI itself though often allows setting up auto-start.
Keep in mind that if you research something and get stuck on it, then you could ask about that particular detail. You might even want to start a separate thread in the forums for each topic, e.g., splash screen in the bootloader is probably good as a different thread versus splash screen in Xorg start. Or if you find a GUI tool to change a background, and can’t find where that is specified in files or for manual file setup, then that might be a good forum thread by itself.
I don’t know most of the actual details you are interested in aside from either that it can be done, but some background on how login and shells and the GUI are arranged would likely be useful to you, and so that is what follows. There are more details at some places than needed, but for the sake of continuity and just for the trivia, I’ll mention some things about the entire boot process (you did ask about splash screens which can be from the start of boot or from the GUI).
Early on in boot, before Linux loads, you get to some bootloader software which is when some drivers first get loaded. This includes drivers for the hard drive, serial console, perhaps regular local console, and a simple video buffer setup (which is where the boot splash starts). All of this is modified by modifying boot software and is not part of Linux other than Linux inheriting this when it boots.
Then the Linux kernel loads. This is a single application. The bootloader is actually also a kernel, but it is a kernel which has the purpose of overwriting itself with another kernel rather than running another program and surviving that. The Linux kernel runs a single process: init (these days it is a symbolic link to the systemd daemon, but used to just be bash scripts).
It is init which runs non-user processes, e.g., just check out what it has by this command to list its devices and services:
systemctl list-units
One service systemd runs at “multi-user.target” (text-mode only login) is either getty or agetty. All these do is to listen for keystroke on the keyboard. More than one getty will run at once in most cases. If no GUI is running (remember, this is multi-user.target, not graphical.target), and if six getty (or agetty) are running, then it listens for these six key bindings:
Seeing a binding like this tells it which is the active text terminal. You can log in and work independently on each of those terminals. These terminals in turn trigger the preferred shell, e.g., bash.
When you go to the GUI (“graphical mode”, or to systemd, “graphics.target”) it is a case of systemd substituting the GUI software for one or more of the getty programs. The GUI does not run on a getty, but is instead a direct replacement to a getty. They are both an interface to the user, but the GUI version is more complicated. If you are in a text-mode only terminal, and if the GUI is the default setup, then then following key bindings are listened to by init:
- In the GUI, one can go to a text-mode terminal via
CTRL-ALT-F2 through CTRL-ALT-F6 (we replaced the first text terminal with a GUI).
- In text mode you can still go back and forth among text terminals with
ALT-F2 through ALT-F6.
- In text mode you can go to the GUI via
ALT-F1 (which used to be a text terminal).
It is quite possible to replace a text terminal with some other program, e.g., a clock (but beware if it is a GUI program it gets complicated since it must run in the right environment). For example, you could edit the second console, ALT-F2, and turn it into a clock instead of a login. You’d just change the getty (or agetty) to the binary executable (without specific help this would run as user root).
It is also easy to run a new GUI login on one terminal. So you could have a GUI setup with these bindings:
- In the GUI, one can go to a text-mode terminal via
CTRL-ALT-F3 through CTRL-ALT-F6 (we replaced the first text terminal with a GUI).
- In text mode you can still go back and forth among text terminals with
ALT-F3 through ALT-F6.
- In text mode you can go to the GUI via either
ALT-F1 (which used to be a text terminal) or ALT-F2 (which also used to be a text terminal).
This latter of having two independent X server logins (it could also be Vulkan…remember that the key bindings start execution of a program, but init does not care if it is a GUI or text console or something completely non-interactive) is useful to have a regular login plus a virtual desktop login (normally people replace their login with a virtual desktop, but you could append a desktop).
Speaking of append, you could set up some mix of logins and custom apps on ALT-F1 through ALT-F12 since you have the keys. This of course takes more resources, and probably wouldn’t be useful to most people.
I say all of this because if you have a kiosk, then what people have access to might require disabling terminals. The serial console itself could remain active if it is physically not available. The serial console is also a getty (but it is run by nvgetty.service rather than agetty or getty…note they all have “tty” in their names, and in the device special files they will be group “tty” when they are a terminal). If your system has enough resources, then during development you might also want create a test GUI in the first default GUI, ALT-F1 (or if you are in some other GUI, then CTRL-ALT-F1), and keep a regular GUI in ALT-F2. You’d boot up to the kiosk by default, but be able to develop if you hit the key binding CTRL-ALT-F2 (or text terminals). Once you release, you’d remove those services and leave only the kiosk (you might leave serial console so long as it requires a password and is also physically not available in normal circumstances…I don’t really know what environment you want your kiosk to run in).
Regarding the splash screen and custom environments, if you want a real kiosk, then you should understand some things about graphical desktop environments in addition to the key bindings reaching this GUI.
Xorg/X11 really only runs one program. It is nothing more than a convenient and very basic way to organize a framebuffer. One can run X11 without any desktop, and all you see is a mouse cursor and an ugly grayish desktop not capable of doing much of anything. What you normally see is not X11, but is instead the desktop manager, e.g., Gnome or KDE (which is actually the plasma app). It is the desktop software which adds icons and multiple programs running simultaneously in a nice and cooperative way. When you talk about removing desktop icons, you are normally talking about removing them from the desktop manager. If you use Gnome 3, then this is the software you need to configure and understand.
FYI, I use the terms Xorg and X11 interchangeably because Xorg is the GNU vendor we use in Ubuntu, and X11 is the protocol. If I say X, then I mean the same thing, except specifically
For a kiosk though it can get interesting. What happens normally when you hit the ALT-F1 key binding to reach the GUI is this (keep in mind that X itself runs only one program at this lower level):
init runs a specific Xorg (a "DISPLAY" context; there can be more than one).
-> Xorg runs a login manager as root.
-> relaunches Xorg as a user with a desktop manager as the program.
-> runs its login setup now that it knows which user to set up for.
-> runs the user's interactive commands.
Remember how I said you could change a text terminal to be another GUI? You could also have it run an altered subset of the above. One can skip the login manager, and I don’t mean auto-login, I literally mean to directly run Xorg while naming the desktop manager:
init runs a specific Xorg as a user with a desktop manager as the program.
-> runs the user's interactive commands.
In the latter init is running Xorg with arguments directly naming the desktop manager without going through a login manager. Unless steps are taken this environment will run as root because systemd/init is running as root. Root does not require a password to use sudo, and instead of starting the command with X ...some argument... it can also (assuming user name is “kiosk”) sudo -u kiosk X ...arguments...
So far you’ve been thinking about starting a desktop which is customized for a non-interactive use, e.g., remove the icons. If you don’t need a desktop manager, and if only a single program will run, e.g., something like the “Kodi” program (Kodi is used for many multimedia kiosks, but it can be any program), then Kodi could be named directly as the program which X runs instead of running a desktop manager.
The interactive user program is often gnome3, is the bulk of the argument passed to the X server (other options, e.g., desktop width and height, would be examples of other options). Check out some of the options here (along with a mention of some of its configuration files):
https://manpages.ubuntu.com/manpages/xenial/man1/Xorg.1.html
X options get complicated. When init builds them up it uses services files. The command line method is best explained by reading the script file “/usr/bin/startx”. This builds up arguments for manually starting X, and includes a desktop window manager. If you look at this, then you could copy it and edit to start one application instead of the desktop manager (for example, it could substitute kodi for gome). This customized startx could be the target of the ALT-F3 binding (sometimes the first server is ALT-F1, but sometimes it is also ALT-F2…from the GUI try CTRL-ALT-F2 and also CTRL-ALT-F3 if F2 does not seem to do anything).
Go to an unused plain text terminal and log in as your regular user. Then try the “startx” program. You’ll see an alternative X environment using the arguments of startx. If you exit this, then since there is no login manager, it’ll revert back to the text-mode console which you started this from (you can’t run this within another GUI). Towards the end you will see it in turn uses xinit to run X. Remember how the system uses init (systemd)? When starting graphical mode this has its own additional init if started on command line. I’m not sure if systemd uses xinit directly…systemd probably uses this as a service of sorts (I don’t know for sure, but in the old days when bash scripts were used the xinit was used directly). If you find the right arguments to xinit by way of editing a custom startx, then one terminal could be bound directly to this.
Recommendation: Figure out which terminal the regular GUI runs in. Probably it is ALT-F1, but it might be ALT-F2 (with a prefix CTRL if you are already in a GUI and switching to another GUI or text console). Leave this alone at first. Learn to use startx to start an ordinary independent X session on another text console. For this you will probably need to fail a few times due to needing NVIDIA adjustments. Remember that on the startx session you can kill it with CTRL-ALT-backspace. Then you’ll see error messages, and can ask here (NVIDIA moderators will know how to answer NVIDIA-specific X startup arguments for manual startx…make a new thread for that topic on the forums) how to fix that to manually start X with their drivers.
Once you have that in a custom startx, learn how to start that script in a new terminal via systemd (when you get there you can experiment and start a new forum thread to ask about it). Once you have that you can edit this to replace the desktop manager with your single application, e.g., kodi. Or of course you could build your script to start kodi without a desktop manager before automating it in systemd/init. If you have a custom startx (or know arguments passed to xinit or to a direct X command, then you can post that) which other people can try and examine it will make asking questions easier. Note that whoever runs startx or xinit is who the GUI will run as.