Show something useful on tty1

Hi all, I have an old laptop reconfigured to be a server, and it generally just shows tty1 login after boot.

It would be nice to have it show something useful, or just cool instead of a login prompt that will never be used.

I understand I can override login command with services.getty.loginProgram , but i’m not sure what to replace it with (if this is the way at all)

It would be nice to see any statistics, like htop, but just a nice looking screensaver is also an option

Hi!

I don’t know if it’s possible but let me ask you a question why did you choose nixos for that laptop? Wouldn’t Proxmox be better?

Best,
Miro

why nixos? just because it’s easier to setup what i need, ni real reason.

why would proxmox be better?

What you appear to be describing is effectively a kiosk.

2 Likes

A long time ago, when NixOS was more fun, the installer device used to have rogue running on tty8, so you could play while waiting for the installation to finish.

This is how it was implemented:

systemd.services.rogue =
  { description = "Rogue dungeon crawling game";
    wantedBy = [ "multi-user.target" ];
    serviceConfig =
      { ExecStart = "${pkgs.rogue}/bin/rogue";
        StandardInput = "tty";
        StandardOutput = "tty";
        TTYPath = "/dev/tty8";
        TTYReset = true;
        TTYVTDisallocate = true;
        WorkingDirectory = "/tmp";
        Restart = "always";
      };
  };

You could adapt this and run any program you like on the virtual console.

17 Likes

that’s cool! why did they remove it??

that looks like it! though I’d prefer it to be running in text mode

Sounds like a neat little piece of history. Perhaps the wiki could use a “trivia” page :^)

2 Likes

interestingly, this does not work on tty1. tried with rogue and btop.

on other tty - it works fine, but on tty1 - service does work, you can see program draw it’s stuff on top of boot messages still being printed, but then it switches to black screen and blinking cursor.

Looking at the commit history, rouge needs ncurses5, which increases the ISO size.

4 Likes

You can spin up as many vms or containers as you want, backup them, clone them, move them between nodes (if you have more than one). You can easily create ceph storage and use it e.g. for backups, there’s also support for zfs.

Simply put: enterprise ready virtualisation solution.

but can i declaratively define and configure it?
do i really need enterprise ready virtualization solution for a small home server?

I run NixOS on my home lab. Unless you’re trying to coordinate a load of high-availability containerised servers, there’s no real point using proxmox or any other virtualisation and orchastration frameworks.

The only benefits I can see of running some enterprise ready virtualisation/orchastration/whatever system is:

  • The additional isolation you get from using container virtualisation (hardly needed on a home server, but also: NixOS Manual, and Security - Official NixOS Wiki if you decide you do need it).
  • If you know you’re going to eventually have a cluster and don’t want to have to reconfigure everything to support it.
  • If you want to learn how to use them.

You could use something like this in your ~/.bash_profile (or ~/.zlogin if you use zsh) to automatically start htop when you login on tty1:

if [ "${XDG_VTNR}" -eq 1 ]; then
  exec htop
fi

Then (if security isn’t a concern) you could automatically login using this NixOS option:

services.getty.autologinUser = <username>;

You’re probably missing this in your systemd service:

{
  conflicts = [ "getty@tty1.service" ];
}

You may also want boot.kernelParams = [ "quiet" ]; if you don’t have it already.

the conflicts does fix the problem!
i wonder why this is not required for ttys other than 1.

And how exactly does it work that i state the conflicting service? why the ordering is correct by default and tty1 is not disabling my service instead?

It’s a little mysterious to me too, but I believe that systemd has some baked-in logic for tty1. It’s autostarted very early. For any other systemd conflict between services, I’d also want to add after = [ the-other-service ]; to the one that should win, to make sure that the other service doesn’t shut down that one. I’ve never needed that with getty@tty1, but it wouldn’t hurt to add.