klibc - Jun 2014 - [PATCH] isatty(): use TCGETS instead of TIOCGPGRP, like dietlibc does

H. Peter Anvin dixit:
>But is that really a tty, then?  I also understand that virtio console
Hm. Both eglibc and dietlibc return true for isatty on it.
>doesn't support termios, which makes this an ugly bifurcation.  All of
Let me test that? quick? hah not really (CONFIG_VIRTIO_CONSOLE=m)?
ok luckily Ubuntu?s linux-image-3.15.0-5-generic is installable on
Debian stable and has CONFIG_VIRTIO_CONSOLE=y? but no reiserfs module?
gah? ok I could test it.

This works. It has got enough of a tty for mksh-static linked against
klibc to have proper command line editing even with console=hvc0.
>this is stupid, of course...
Fully agreed!

bye,
//mirabilos
-- 
?ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists ? sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor ? Debian
does
not strike me as a place for good humour, much less German admin-style humour?

Does ctrl+c work?

My experience with (non klibc) init=/bin/bash is that getting ctrl+c
to work requires some jumping through hoops, because running as pid 1
doesn't really work.

If I recall correctly you have to call setsid, and open a tty as a
controlling tty, you can't call setsid as pid 1.


The hack that I got to work (for reference, I'm using this for raw
kernel testing qemu-kvm) is:

kernel command line:  init=/boot/mz-boot.sh

$ cat /boot/mz-boot.sh
#!/bin/bash
main() {
  echo 'Init (hostname, HOSTNAME, INPUTRC, HOME, LOGNAME, USER,
USERNAME, BASH_ENV, TERM, proc, fsck)'
  hostname linuxvm
  export HOSTNAME=linuxvm
  export INPUTRC=/etc/inputrc
  export HOME=/root
  export LOGNAME=root
  export USER=root
  export USERNAME=root
  export BASH_ENV=/root/.bashrc
  export TERM=xterm
  mount -t proc proc /proc
  fsck /dev/sda1
  fsck /dev/sda3

  echo 'Allowing safe editing of boot script.'
  mount -o remount,rw /
  mv -f /boot/mz-boot.sh /boot/mz-boot.sh_
  cp -p /boot/mz-boot.sh_ /boot/mz-boot.sh
  mount -o remount,ro /
  sync

  echo 'Turning up networking.'
  ip link set eth0 up
  ip addr add 192.168.0.2/28 broadcast + dev eth0
  ip route add default via 192.168.0.1
  /usr/sbin/sshd

  echo 'Starting shell.'
  /boot/shell-to-bash
  echo '2nd (fallback) shell, just exit.'
  /bin/bash < /dev/ttyS0 > /dev/ttyS0 2> /dev/ttyS0

  echo 'Turning off networking.'
  killall sshd
  ip route del default
  ip addr del 192.168.0.2/28 broadcast + dev eth0
  ip link set eth0 down

  echo 'Sync and unmount.'
  sync
  mount -o remount,ro /
  sync

  echo 'Poweroff.'
  /sbin/halt -d -f -p
}

main "$@"; exit

it's important that shell-to-bash doesn't get execed, put
fork-and-execed, cause it won't work as pid 1.

execve("/boot/shell-to-bash", ["/boot/shell-to-bash"],
["HOSTNAME=linuxvm", "TERM=xterm",
"HOSTTYPE=i486", "PWD=/",
"PS1=\\h:\\w# ", "SHLVL=1", "HOME=/root",
"OSTYPE=linux-gnu",
"MACHTYPE=i486-pc-linux-gnu", "_=/usr/bin/strace"]) = 0
setsid()                                = 1216
close(2)                                = 0
close(1)                                = 0
close(0)                                = 0
open("/dev/ttyS0", O_RDONLY)            = 0
open("/dev/ttyS0", O_WRONLY|O_NOCTTY)   = 1
open("/dev/ttyS0", O_WRONLY|O_NOCTTY)   = 2
execve("/bin/bash", ["bash"], ["HOME=/root",
"TERM=xterm"]) = 0

I'm not sure how much of the above is relevant to /dev/console as
opposed to the /dev/ttyS0 I've obviously been using.

I guess what I wanted to say is that it might be desirable to have the
klibc shell do some dancing (perhaps controlled by some flags, but on
by default?)

If getpid() == 1 then fork a child, continue in the child, have the
parent wait for the child to terminate, then exit

child should

setsid()
close(2)
close(1)
close(0)
open("/dev/ttyS0", O_RDONLY)
open("/dev/ttyS0", O_WRONLY|O_NOCTTY)
open("/dev/ttyS0", O_WRONLY|O_NOCTTY)

And /dev/ttyS0 should either be /dev/console or specified on
commandline, or parsed out of kernel command line console= string.

Just loose ideas.

Maciej ?enczykowski dixit:
>Does ctrl+c work?
define(`work')dnl
>If I recall correctly you have to call setsid, and open a tty as a
>controlling tty, you can't call setsid as pid 1.
You don't get a controlling tty, but you don't need that for
most rescue work. And if you do, you just run one of

	mksh -lT!/dev/tty1
	mksh -lT!/dev/ttyS0
	mksh -lT!/dev/hvc0

and have a shell on the given tty.

bye,
//mirabilos
-- 
?ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists ? sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor ? Debian
does
not strike me as a place for good humour, much less German admin-style humour?