Pavel Machek <[email protected]> said:
[...]
> You get pretty nasty managment problems. How do you do init=/bin/bash
> if your keyboard is userspace?
You don't tell any kernel about that... it is the bootloader you are
talking to. And that one may very well have integrated kbd support.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> Pavel Machek <[email protected]> said:
> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
>
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.
So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it loads
the kernel, the kernel launches init, /bin/bash gets loaded - and /bin/bash
can't talk to the keyboard because the userspace handler hasn't happened. At
that point you're stuck...
Hi!
> [...]
>
> > You get pretty nasty managment problems. How do you do init=/bin/bash
> > if your keyboard is userspace?
>
> You don't tell any kernel about that... it is the bootloader you are
> talking to. And that one may very well have integrated kbd support.
I know bootloader will hae its own kbd driver.
But when kernel boots, you'll not be able to enter commands into the bash.
--
934a471f20d6580d5aad759bf0d97ddc
>>>>> "Pavel" == Pavel Machek <[email protected]> writes:
Pavel> I know bootloader will hae its own kbd driver.
Pavel> But when kernel boots, you'll not be able to enter commands
Pavel> into the bash.
Funny. How did you type the command to start bash?
If you can arrange bash to be run, then why is it that difficult to
arrange "modprobe atkbd; modprobe i8042" to be executed?
Some distros even have the disk driver and filesystem for the root fs
compiled as modules. They do manage to load those modules correct to
mount the rootfs. How come it is so hard to imagine that 'i8042' and
'atkbd' can somehow be loaded without user attention at boot time?
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
Hi!
> Pavel> I know bootloader will hae its own kbd driver.
>
> Pavel> But when kernel boots, you'll not be able to enter commands
> Pavel> into the bash.
>
> Funny. How did you type the command to start bash?
That was in comment you stripped.
> If you can arrange bash to be run, then why is it that difficult to
> arrange "modprobe atkbd; modprobe i8042" to be executed?
It would not be "modprobe atkbd" but "my-keyboard-daemon &". And AFAIK
you can't add that to "init=" commandline.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
On Friday 04 June 2004 21:37, [email protected] wrote:
> On Fri, 04 Jun 2004 14:17:14 EDT, Horst von Brand said:
> > Pavel Machek <[email protected]> said:
> > > You get pretty nasty managment problems. How do you do init=/bin/bash
> > > if your keyboard is userspace?
> >
> > You don't tell any kernel about that... it is the bootloader you are
> > talking to. And that one may very well have integrated kbd support.
>
> So GRUB knows about keyboards, lets you type in the "init=/bin/bash", it
> loads the kernel, the kernel launches init, /bin/bash gets loaded - and
> /bin/bash can't talk to the keyboard because the userspace handler hasn't
> happened. At that point you're stuck...
Using shell scripts instead of 'standard' init etc is
way more configurable. As an example, my current setup
at home:
My kernel params are:
root=/dev/ram
init=/linuxrc
devfs=mount
ROOTFS=/dev/ide/host0/bus0/target0/lun0/part7
IPCFG=mac,100mbit
INIT=/init
/linuxrc (in initrd):
#!/bin/sh
export PATH=/bin:/usr/bin
cd /
mount -n -t devfs none /dev
mount -n -t proc none /proc
#mount -n -t sysfs none /sys
echo "# Configuring interfaces"
# Optional, for NFS happiness
ip l set dev lo up
ip a add 127.0.0.1/8 dev lo
/script/cfg_ip
echo "# Mounting root fs"
/script/mount_root
# Clean up
#umount /sys
umount /proc
echo "# Chrooting into root fs"
mount -n -t devfs none /new_root/dev
cd /new_root
# making sure we dont keep /dev busy
exec <dev/console >dev/console 2>&1
# proc/ in new root is used here as a temp mountpoint
pivot_root . proc
echo "# Exec'ing init"
if ! test "$INIT"; then
INIT=/init
fi
exec \
chroot . \
sh -c \
'umount -n /proc/dev; umount -n /proc; exec /bin/env - $INIT'
echo "Error in 'exec chroot . sh': exit code $?"
while true; do
sleep 32000
done
And, finally, /init:
#!/bin/sh
fileprefix=/etc/rc.d
bootprog=3.runlevel
unset HOSTNAME
unset devfs
unset MACHTYPE
unset SHLVL
unset SHELL
unset HOSTTYPE
unset OSTYPE
unset HOME
unset TERM
export PATH=/bin:/usr/bin
exec >/dev/console
exec 2>&1
exec </dev/null
(
cd "$fileprefix"
env - PATH="$PATH" "$fileprefix/$bootprog" start
)
# Close all descriptors
exec >&-
exec 2>&-
exec <&-
while true; do
env - sleep 32000
done
--
vda
On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
> Using shell scripts instead of 'standard' init etc is
> way more configurable. As an example, my current setup
> at home:
>
> My kernel params are:
Yes. Those are *YOUR* config setup parameters, that happen to work with *your*
specific configuration when everything is operational. Some problems:
1) Not all the world uses initrd....
2) I hope your /script/mount_root will Do The Right Thing if the mount fails
because it needs an fsck, for example. Answering those 'y' and 'n' prompts can
be a problem if your keyboard isn't working yet..
3) Bonus points if you can explain how to, *without* a working keyboard, modify
that /linuxrc on your initrd to deal with the situation where your keyboard
setup is wrong (think "booting with borrowed keyboard because your usual one
just suffered a carbonated caffeine overdose")...
There's a *BASIC* bootstrapping problem here - if you move "initialize and
handle the keyboard" into userspace, you then *require* that a significantly
larger chunk of userspace be operational in order to be able to even type at
the machine. If you're trying to recover a *broken* userspace, it gets a lot
harder.
And the embedded people who use "init=/onlyprogramthateverruns" are going
to have a significant collective cow about this....
On Friday 04 June 2004 22:50, [email protected] wrote:
> On Fri, 04 Jun 2004 22:33:41 +0300, Denis Vlasenko said:
> > Using shell scripts instead of 'standard' init etc is
> > way more configurable. As an example, my current setup
> > at home:
> >
> > My kernel params are:
>
> Yes. Those are *YOUR* config setup parameters, that happen to work with
> *your* specific configuration when everything is operational. Some
> problems:
In *any* setup, kernelspace or userspace, it's typically possible
to find some silly way to break boot sequence. Unplugging
keyboard and removing (unneded for server) videocard are my
favorites ;)
> 1) Not all the world uses initrd....
I stayed away from it too, but I always knew I'll need it sooner
or later.
> 2) I hope your /script/mount_root will Do The Right Thing if the mount
> fails because it needs an fsck, for example. Answering those 'y' and 'n'
> prompts can be a problem if your keyboard isn't working yet..
My init scripts are (trying to) recover from any failure.
They ignore non-fatal error conditions.
I'll fix your fsck example like this: make script check
FSCK_ACTION env var for N (never do fsck), ASK (ask user
if serious trouble), and AUTO (fix automagically without
user). Set FSCK_ACTION as needed per box via kernel command line.
Fixing/tailoring init written in C is harder (more time-consuming).
Fixing/tailoring kernel bootstrap sequence is harder still.
As an example, NFS boot. How can you force your ethernet into,
say, 100 Mbit FDX _before_ kernel do DHCP thing via ip= kernel
parameter?
That's one of reasons why moving to userspace might be a good idea.
> 3) Bonus points if you can explain how to, *without* a working keyboard,
> modify that /linuxrc on your initrd to deal with the situation where your
> keyboard setup is wrong (think "booting with borrowed keyboard because your
> usual one just suffered a carbonated caffeine overdose")...
I just did that yesterday when I needed to make USB keyboard to
work on my box, first time ever for me. I let it boot, ssh'ed in,
and built new kernel. I could modify my initrd too, but that wasn't
needed.
> There's a *BASIC* bootstrapping problem here - if you move "initialize and
> handle the keyboard" into userspace, you then *require* that a
> significantly larger chunk of userspace be operational in order to be able
> to even type at the machine. If you're trying to recover a *broken*
> userspace, it gets a lot harder.
Bootstrapping problem exist no matter how you are bootstrapping.
When something is broken, difficulty of repairs cannot be estimated
that simple. I don't think "you are using intird -> fixing will be hard"
always holds true.
BTW, in my case, booting my box was not just hard, it was impossible.
It had broken PS2 ports. I needed to "only" enter BIOS setup and tell
it to ignore keyboard errors on boot, but I couldn't enter it
without keyboard! But I digress...
--
vda
>>>>> "Pavel" == Pavel Machek <[email protected]> writes:
>> If you can arrange bash to be run, then why is it that
>> difficult to arrange "modprobe atkbd; modprobe i8042" to be
>> executed?
Pavel> It would not be "modprobe atkbd" but "my-keyboard-daemon
Pavel> &".
What's the difference? Both are commands. Commands can be put in
shell scripts, which can be put in shell scripts, ... Eventually, you
only need one root script to spawn all the offsprings.
Pavel> And AFAIK you can't add that to "init=" commandline.
That's getting funny. You can't start 6 copies of getty on
/dev/tty[1-6] on "init=", can you?
--
Sau Dan LEE ???u??(Big5) ~{@nJX6X~}(HZ)
E-mail: [email protected]
Home page: http://www.informatik.uni-freiburg.de/~danlee
Hi!
> Pavel> And AFAIK you can't add that to "init=" commandline.
>
> That's getting funny. You can't start 6 copies of getty on
> /dev/tty[1-6] on "init=", can you?
No, but you can do init=/bin/bash. [Are you reading my mails at all?!]
And init=/bin/bash is enough to recover broken system.
What you are proposing is incompatible update that would break 99% of
all systems, for gain of 8K of unswappable memory or something like
that. That's no-no in 2.6 series, and probably bad idea for 2.7, too.
Now, can we end the thread here? Userland keyboard driver is not going
to happen in 2.6.X.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc