Feature #5528

boot menu

Added by Tails 2013-07-18 07:42:21 . Updated 2013-07-19 01:52:58 .

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:




While adding optional functionality to Tails, we need a way to ask the user for them at startup. This is for example required for localization at runtime, persistence, macchanger and bridge support, include truecrypt. The backlinks at the bottom of this page probably constitute an exhaustive list of this task’s reverse dependencies.

Ongoing and future work

Some of this task is being implemented by Max during GSoC2011. Progress can be tracked via TailsGreeter page.

Once tails-greeter is shipped in Tails, the current syslinux localization menu should be removed. It could e.g. be replaced by a (hidden by default) troubleshooting menu, such as the one being designed (used already?) for Fedora (blog post, syslinux.cfg, screenshot with menu hidden, screenshot with timeout interrupted and menu displayed. Work on this should be done in our feature/tails-greeter Git branch.

Past research

Using boot menus

In 0.6, the localisation at runtime is done in the syslinux menu for PCs, see localization at runtime, but it’s very hard to add more than one set of options to that kind of menu.

The only boot menu that will stay supported upstream seems to be gfxboot (to be verified). It configuration seems however quite hard to write.

Using a menu in the initramfs

It’s probably easier to write a nice user interface once linux is running. However, it should be done in the initramfs as the parameters wil be used at this stage.


It seems to be the easier way to implement it.

graphical UI on top of the framebuffer

This seemes to be well supported by Qt: http://qt.nokia.com/products/platform/qt-for-embedded-linux.

launching X11 very early

An other option would be to start X11 very early and to run a menu under X11. Then plymouth-x11 could be used to display a splash screen. The issue is that it seems quite hard to start GDM in an already running X11 instance.

Recent gdm3 (2.30.5-5) changes seem to fix issues wrt. static displays that might fix the earlier encountered problems.

Providing a configuration menu just before start desktop session

Current syslinux menu

This one could in this case be only a minimalistic menu like the default debian live one, providing the ability for the user to choose between

Still the user might have to choose at this stage some options we might be unable to run in the later xsession menu, like for thr truecrypt or persistent option. In this case, we could either tell the user to hit tab and type the needed option, or add an item to the syslinux menu.

Via GDM 3

On a "classic" Debian installation, users can choose their language and keyboard at the same time they enter their login and password in GDM.

Tails currently uses autologin, so these options do no usually shows up. Hence the selection of language and keyboard very early in the boot process.

But it looks like every configuration options that Tails would need do not really require to be applied before the desktop session actually starts.

So instead of hacking a "boot" menu, we could benefit from the flexible architecture of GDM 3:

  • Replace gdm-simple-greeter (the default user/login password prompt) by a new GTK+ application hereby named tails-greeter. To do so, it should be mostly about hacking autostart files.
  • tails-greeter would display widgets and help on changing the MAC address, persistence, and other configuration options.
  • When the Start Tails button is clicked, tails-greeter would send the needed D-Bus message to trigger an automatic login.
  • The selected configuration will be applied within one or more scripts in /etc/gdm3/PostLogin.

This variant is slated for implementation during GSoC2011 project. Progress can be tracked via TailsGreeter page.

With this approach, the initial boot menu (syslinux) can be kept pretty minimal and mostly offer failsafe boot options (e.g. overcoming issues preventing the graphical environment to start).

Getting rid of GDM 3

Another approach might be to get rid of GDM 3, and launch a (possibly GTK+) application with the /etc/X11/Xsessions.d/ mechanism. This might be easier to maintain that a having to hack GDM 3, and maybe might free some more space in the squashfs.



#1 Updated by intrigeri 2013-07-19 01:52:58

  • Type of work set to Code

Type of work: Code