Hacker News Reader

Comment by vortico | Hacker News Reader

Along the same lines as a program running on lightweight DOS, is it possible (or common) to build a Linux "distribution" for the sake of running a single TTY program? How fast would it boot, and how reliable would it be? (To avoid being called into work because a brief power outage "bricked" the POS.) Linux would have the advantage of working on modern PCs with modern hardware like touch screens, USB scanners/printers, etc.

Or, say I want to boot directly into a video game console emulator with Linux with 0 additional steps. How would I do that?

View on HN

While you can just make it launch a program instead of /sbin/init, you may be surprised at the results, because it won't mount any of your filesystems, setup the network, etc. So you want systemd/sysvinit (according to taste) to run first, which will take the normal amount of time to boot.

The cleaner way of doing this is through "inittab". Normally this starts a program called "getty" on the console which provides the login prompt etc. That's what you want to override. It will also restart your program every time it quits.

(Less normal options include "put your program in the initrd", which is viable if it's very small and does all the setup itself, or "write something that runs directly from the UEFI loader")

Or just stick with a lightweight init like OpenRC. It's used in Alpine and as such also in Docker containers. It stands out in how little, really, it does.

Also, you can use /etc/passwd to set the shell for every user. If you set this to a non-shell application, you essentially limit this user's session to only ever running that program. So a very lightweight, but networked system could set up sshd in innittab and then create a user with your single-user application set as the shell, and maybe an admin user that actually has access to a proper shell as a back-up.

There actually was a blog post I read not too long ago about a sysadmin who detailed the security challenges of running an open SSH server in which passwd set the shell to a game. There was a little bit more to it to get it completely secure. Unfortunately can't find it right now.

Another less normal option would simply be to make /sbin/init a shell script.

Instead of trying to detect hardware, network, and all, you could just hardcode everything. If you're working with a standardized set of hardware, that would most likely be simpler than anything else.

This sounds interresting. Do you know any guides on this?

I don't know of a guide, off-hand. I saw it done before in postmarketOS [0], which is what made me think of it.

Note that pmOS does it to call an actual init system, but it could be done as an init in and of itself.

0: https://gitlab.com/postmarketOS/pmaports/tree/master/main/po...

When Linux finishes initializing itself it runs /sbin/init (it is one path it tries among a bunch of others, though i think /sbin/init is the first it attempts to run - you can override that with the init= kernel parameter at boot time, e.g. in GRUB). So just make /sbin/init be your binary and make sure it can run by itself without any other initialization and it should work.

In fact, init=/bin/bash is the traditional way to gain root into a system for which you have forgotten the password. Assuming the filesystem is not encrypted.

For your last question, here's something I wrote some time ago to do just that: https://raymii.org/s/tutorials/Run_software_on_tty1_console_...

IIRC, Chrome OS started as that very concept, although it's kind of evolved since then.

Reply on news.ycombinator.com