Matthew Burgess wrote: > On Fri, 18 Sep 2009 15:52:44 -0600, Matthew Burgess > <matt...@linuxfromscratch.org> wrote: > >> stty: standard input: Inappropriate ioctl for device > > OK, figured this out to be the section of /etc/rc.d/init.d/functions > that sets the COLUMNS variable by calling 'stty' (obvious now!). So, > why can't it set that then?
I think because in processes launched by udevd, stdin is /dev/null. You
can't get the size of the terminal from /dev/null, since there is no
such thing. :-P
Also, output (*any* output!) from the RUN scripts may not be a good
thing; we might want silence the setclock script, especially if the
crazy escape codes confuse udevd by some chance. Maybe not critical
here, though.
> Am I missing a driver from my kernel, or is it due to my VirtualBox
> environment? That probably explains why a couple of the stty tests
> from coreutils fail too ('stty' and 'stty-row-col').
Doesn't seem to be VirtualBox (at least, not the stty failure) -- I get
the same message if I run your test with udev in debug mode. However,
the clock does get set correctly; if I muck with the system time and
then "echo add >/sys/class/rtc/rtc0/uevent", I can run "date" after a
couple seconds, and I get a valid time. (Though my hwclock is UTC, that
shouldn't matter. I don't think...)
(Can we point stty at some valid console device? Say, /dev/console?)
I've also verified that /proc/self/fd/0 points to /dev/null inside the
script when called from udevd. (Via "readlink /proc/self/fd/0 >
/root/dumpfile" at the start.) And udevd in debug mode always seems to
show the stty failure.
Not sure why it doesn't work for you, though... :-(
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
