LFS with Runit (without SysV)

Keith Hedger · 05-03-2014, 05:49 AM

Quote:

Originally Posted by stoat

...I also have the Ctrl-C issue. Sort of a big deal when you ping Google to test the network. I had to reboot to stop that...

Which is exactly how I found out about Ctrl-C not working, of course if you had just switched to another console and done

Code:

killall ping

you wouldn't have had to reboot.

stoat · 05-03-2014, 08:44 AM

I tried that, but the other consoles weren't there then. Afterwards, I discovered $N in those getty run files. I guess I also could have used -c3 with ping. If I had known all that.

Keith Hedger · 05-03-2014, 10:45 AM

Well I have been playing with this and I've hit a bit of a brick wall, I can't ssh out of the machine, I can ssh in from a tablet and then ssh out again to another machine, but doing it directly I get errors like so:

Code:

OpenSSH_6.5, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.1.66 [192.168.1.66] port 22.
debug1: Connection established.
debug1: identity file /home/keithhedger/.ssh/id_rsa type -1
debug1: identity file /home/keithhedger/.ssh/id_rsa-cert type -1
debug1: identity file /home/keithhedger/.ssh/id_dsa type -1
debug1: identity file /home/keithhedger/.ssh/id_dsa-cert type -1
debug1: identity file /home/keithhedger/.ssh/id_ecdsa type -1
debug1: identity file /home/keithhedger/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/keithhedger/.ssh/id_ed25519 type -1
debug1: identity file /home/keithhedger/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4
debug1: match: OpenSSH_6.0p1 Debian-4 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA f5:39:7c:d3:4d:6f:dc:3b:f9:7f:df:75:88:ce:68:e1
debug1: Host '192.168.1.66' is known and matches the ECDSA host key.
debug1: Found key in /home/keithhedger/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/keithhedger/.ssh/id_rsa
debug1: Trying private key: /home/keithhedger/.ssh/id_dsa
debug1: Trying private key: /home/keithhedger/.ssh/id_ecdsa
debug1: Trying private key: /home/keithhedger/.ssh/id_ed25519
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: Permission denied
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: Permission denied
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
debug1: read_passphrase: can't open /dev/tty: Permission denied
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
Permission denied (publickey,password).

I've tried the usual stuff like deleting th .ssh folder which usually fix's problems with ssh.
All configs etc are the same as I normally use so it's probably not a simple config problem, what looks suspicious is the problems with the /dev/tty in there, I have also got a similar error saying "/dev/tty no such device" even though they are there, I assume this is related to the bash error about job control, the other bit of weirdness which may be related is that when I chroot into the system the prompt shows "root:/#" but when I log in from the booted system I get "bash:/#"

j_v · 05-03-2014, 01:08 PM

Looking at your ssh debug output, is it possible that the problem is that the reference to /dev/tty should perhaps be /dev/tty# or even pts/#? I'm wondering if you have a getty run script or could there be a problem loading it?

Keith Hedger · 05-03-2014, 01:30 PM

Yes there is a getty run script and all the /dev/tty* device nodes seem to be OK there is definitely something going wrong with either eudev or runnit, all the consoles are working but I can't do much at the moment as I fubared my runit system and I am rebuilding it now, ho hum.

j_v · 05-03-2014, 01:35 PM

I'm at 5.13 of a stable build on a qemu vm. I intend to use it for runit testing, so hopefully I will catch up eventually and contribute/collaborate.

Keith Hedger · 05-03-2014, 04:48 PM

Well done some googling and this seems to one of those odd problems that have a number of solutions, to start with if you install xorg and run an xterm then this problem seems togo away ie I can ssh out of the machine with no errors and opening a new xterm doesn't give the bash error, I also found a workaround called nullfilter which is a smal app that when run fixes the bad /dev/tty problem, unfortunately I am not at my machine at the mo so I can't paste a link,but I will tomorow,I will also have look at the code to see where the problem may be, but from my gooogling I think it may be that /dev/null and/or stdin/stdout/stderr may not be set up properly, I will get back ASAP unless someone else comes up with a solution first.

Sorry for the length of this post I'm a bit tipsy!

ReaperX7 · 05-04-2014, 12:34 AM

I think ArchLinux forces getty to run over a PID with their scripts, but they use ngetty over dash. It could be tested for agetty with bash, but I wont have access to my workstation till tomorrow night as I'm on my phone at the moment.

stoat · 05-04-2014, 07:57 AM

In the hint where it creates /etc/runit/1, is there a reason to comment out the line that runs the checkfs initscript? I uncommented that.

In the hint where it creates /etc/runit/3, should it include "/etc/rc.d/init.d/mountfs stop" to unmount all non-virtual filesystems? I added that.

I don't know what I've done, but I have Ctrl-C now. And I still see that "no job control" message line when logging in.

Why does an empty file named "reboot" appear in /etc/runit after rebooting? If I delete it and reboot, it comes back. Running /sbin/init 6 makes it happen, so it's being done by /sbin/runit-init. Running shutdown or /sbin/init 0 do not do any similar thing.

EDIT: Nevermind about the "reboot" thing. The runit-init man page explains it all.

Keith Hedger · 05-04-2014, 02:36 PM

I'd like to know how stoat got the CTRL-C working as it seems to be tied in to the problems with /dev/tty, I found a small work around, that corrects both problems, first get a copy of nullfilter using

Code:

svn co svn://svn.tartarus.org/sgt/filter

cd into the filter directory and run

Code:

make nullfilter
cp nullfilter /path/to/lfs/with/runit/sbin

and create a profile file like so

Code:

cat > /path/to/lfs/with/runit/root/.profile << "EOF"
#!/bin/bash

if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then
	exec startx
fi

exec /sbin/nullfilter -- /bin/bash

EOF

Now when you login on tty1 you start X automatically or if you log in to any other tty you get a normal login and CTRL-C works and so does ssh, if you don't want the X auto login just comment out the relevent line, notice the quotes around the first EOF this inhibits variable substitution so $DISPLAY is a literal string rather than the contents of $DISPLAY

You will probably have to get the filter svn repo from your host but you can compile it in the target system either in chroot or when booted.

This definitely seems to be a problem with /dev/pts, I hope it can be solved properly, I have just downloaded the Arch scripts and will have a look at those later.

ReaperX7 · 05-04-2014, 07:46 PM

Thanks Stoat. I'll add those in. As far as uncommenting that line I'll fix that. It should be uncommented. Still work to be done but hopefully by tomorrow I'll have the hint updated.

We will get this.

I've been thinking on this as I'm delayed till tomorrow from my workstation, but I think SysV uses a script that works with inittab that regulates accessibility to /dev/pts resources and directs things between PIDs and /dev/null outputs and redirects. I think, if I'm not mistaken from my last review of Arch's Runit scripts, they set this up in the Getty scripts and other bootscripts somehow.

It's likely not the fault of Runit, but one of many steps in the learning process of using Runit with GNU/Linux properly.

stoat · 05-05-2014, 03:37 PM

Turns out that I DO NOT have Ctrl-C in the tty consoles. Sorry folks. I somehow got myself mixed up and was talking about bash terminals in X. That obviously is not the same thing. Anyway, in a perverse sort of way, this is good because it means that I DID NOT accidentally fix this issue without knowing how to pass it along. Mine is still as busted as yours.

I'm working on the initscripts. CUPS and/or D-Bus is not working. I created some simple run and finish scripts for them. They seem to run okay. I can see them with ps along with the others started by runit. But I can't communicate with localhost:631. Calling the LFS dbus and cups initscripts directly does weird stuff and didn't work either. What have you all done about D-Bus and CUPS?

UPDATE...

YEEHAW! I printed a piece of paper! I got a dbus run script from here and used it as is. I used the simple CUPS run script from the smarden.org collection. Now I can print and scan. I have some messaging that spills over onto my login prompt screen, but I can fix that later.

UPDATE...

I created a simple firewall Runit run script for iptables by just copying the bash script from /etc/rc.d/rc.iptables to the /etc/sv/iptables/run file. I made a similar one on my own for ip6tables.

ReaperX7 · 05-05-2014, 08:19 PM

Quote:

Originally Posted by stoat

Turns out that I DO NOT have Ctrl-C in the tty consoles. Sorry folks. I somehow got myself mixed up and was talking about bash terminals in X. That obviously is not the same thing. Anyway, in a perverse sort of way, this is good because it means that I DID NOT accidentally fix this issue without knowing how to pass it along. Mine is still as busted as yours.

I'm working on the initscripts. CUPS and/or D-Bus is not working. I created some simple run and finish scripts for them. They seem to run okay. I can see them with ps along with the others started by runit. But I can't communicate with localhost:631. Calling the LFS dbus and cups initscripts directly does weird stuff and didn't work either. What have you all done about D-Bus and CUPS?

UPDATE...

YEEHAW! I printed a piece of paper! I got a dbus run script from here and used it as is. I used the simple CUPS run script from the smarden.org collection. Now I can print and scan. I have some messaging that spills over onto my login prompt screen, but I can fix that later. Onward to the next one.

UPDATE...

I created a simple firewall Runit run script for iptables by just copying the bash script from /etc/rc.d/rc.iptables to the /etc/sv/iptables/run file. I made a similar one on my own for ip6tables. Working. Onward.

Awesome job Stoat! I'd buy you a beer if I could.

I'll get the Hint updated and repost it so we can keep track of how far we've progressed with this. We may need a repository soon.

I want to pull more scripts from Arch and see how they did stuff just to be certain this. The issue of job control is going to be tough,b ut if we can crack it, we'll have what we need. For now, we may have to use the nullfilter fix.

Following that link Stoat posted, I checked the database and rana cross this:

Code:

#!/bin/sh
! type getty >/dev/null 2>&1 || exec chpst -P getty tty1
exec getty 38400 tty1

It looks like they're using a /dev/null handler with their getty service, could you guys check this and see how it works? If this works well we can borrow from these scripts, and see if it fixes the Job Control issue.

stoat · 05-05-2014, 08:27 PM

Quote:

Originally Posted by ReaperX7

...can you host the run scripts for eventual packaging?

That would be Keith, and imagine he will agree. Also there is an ATTACHMENTS/ subfolder where the hints are hosted at linuxfromscratch.org. It looks like a place to put files and things associated with hints. It might be a good place to store our own collection of run and finish scripts for the Runit hint.

stoat · 05-05-2014, 08:47 PM

I booted with that script for my getty-1 run script. Everything was going normally until Stage 2 seemed to finish (because I saw those dbus messages), and it stopped without going to my login screen. I have to admit that I don't exactly understand that first line. Can you explain what it is supposed to do?

UPDATE...

Got the alsa run and finish scripts done. Simple one-line commands to restore and save the alsamixer settings.

UPDATE...

Solved the D-Bus messaging on my login screen by creating a log/run script for D-Bus. Now that stuff goes to a log file in /var/log/dbus.