fai newsletter

[Valentijn Sessink]

Hi Thomas, hello list,


I don't have had time to dive into FAI - my colleague Wouter has,
though. I have been working with read-only NFSroots a few times lately,
and some of my findings might be of interest for FAI. Maybe you found
out some of these already, and another "problem" might be that, although
our company policy (if you can say that, in a three-people business ;)
is Debian, my NFSroots have been Slackware.

Anyway, I was triggered by:
> a second tty could maybe be may using a different /etc/initab or using
> getty. Has anyone an idea ?

Yes I do. You can use the "openvt" program (used to be "open" in Slink,
I think it's openvt in Potato). In inittab you can do something like

c1:1235:respawn:/usr/bin/openvt -c2 -w /bin/bash

"c2" opens tty2, "w" waits for /bin/bash to finish (otherwise init tries
to repeatedly restart openvt and will shortly fail with a "spawning too
fast" message). If you use a terminal that is in use, you can use -f
("force"). My experiences show that -f is necessary to open a shell on
terminal 1 (maybe because it is the console?)

There is an anomaly in the tty opening in Linux (which you might have
found out already), in that linux refuses to open a tty read/write on a
read-only mounted filesystem. The strange thing is, that a read-only
NFSroot that has been mounted read-write will give you working tty's
anyway. Examples to make this more clear:

server$ cat /etc/exports
*.*	faihost(rw,no_root_squash)
faihost# mount -o remount,ro /dev/root /
faihost# openvt -c13 /bin/bash
openvt: Cannot open /dev/tty13 read/write (Read-only file system)

server$ cat /etc/exports
*.*	faihost(ro,no_root_squash)
faihost# mount -o remount,rw /dev/root /
faihost# openvt -c13 /bin/bash
faihost#

There is another undocumented feature in the NFS filesystem, in that it
refuses to do the (no_root_squash) thing if you do not mention the
hostname of the particular machine. So:

*.*	(rw,no_root_squash)

gives me a root_squashed filesystem anyway. Does anyone know why this
is? Is there a workaround?

Did FAI succeed in starting the syslogd daemon on ro-NFSrooted machines?
If you try to start syslogd on an ro NFS-rooted machine, it just sits
there a couple of minutes and eventually times out. I found out that
this is /var/run/syslogd.pid. There is no way to tell syslogd to not
write /var/run/syslogd.pid. But then, /dev/log is a Unix socket, that
can't be created on a ro machine, so even if you can start syslogd, it
won't do anything since it can't create it's socket. What to do?

While we're at it: silly other stuff that might be of use on a tweaked
machine: 
if dd if=/dev/fd0 count=0; then echo "Floppy drive ready"; fi

Best regards,

Valentijn
--