Re: ash: Can't access tty problems (initramfs)
On Saturday 19 May 2007 16:06, Hamish Moffatt wrote: > On Sat, May 19, 2007 at 01:00:16PM +0200, Denis Vlasenko wrote: > > I think that there is indeed an understandable desire to start > > shell on the console and yet to have a ctty (have working ^C). > > Main reason is that this will automatically start shell on > > serial line or Linux vt - whichever is configured as console > > for the kernel. Otherwise, it's sort of not trivial where > > the console is. > > [...] > > This device is special - it cannot be a controlling tty. > > Why is that? You can ask kernel people. Bbox FAQ even tells you how to turn it off by hacking your kernel. > What changed from busybox 1.4.2 to make this an issue? A hack was removed from init.c (and is now available as "cttyhack" applet). busybox is about size, and our init.c is still doing some silly things it should not do. Like setting TERM (not just setting it, but setting it *differently* for serial lines (TERM=vt102) and everybody else (TERM=linux)!). This is just silly. init has no business setting TERM. -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Sat, May 19, 2007 at 01:00:16PM +0200, Denis Vlasenko wrote: > I think that there is indeed an understandable desire to start > shell on the console and yet to have a ctty (have working ^C). > Main reason is that this will automatically start shell on > serial line or Linux vt - whichever is configured as console > for the kernel. Otherwise, it's sort of not trivial where > the console is. [...] > This device is special - it cannot be a controlling tty. Why is that? What changed from busybox 1.4.2 to make this an issue? I've previously used simpleinit + bash and it wasn't an issue either. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Saturday 19 May 2007 13:00, Denis Vlasenko wrote: > I decided to add an applet which helps with that. It's in svn now > in "shells" section, it's called cttyhack and it has a nice (I hope) > help text which explains its purpose: [--SNIP--] > What you guys think about it? I like it. By its name, it's clear that it's a hack. By its functionality, it helps being quickly up'n'running. Plus the help message is clear and precise about both and usage. Thank you Denis! Regards, Yann E. MORIN. -- .-..--.. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^| | --==< °_° >==-- °.---: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL| """ conspiracy. | °--°---°--°° ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Friday 18 May 2007 19:00, David Daney wrote: > >> ttyS0::askfirst:-/bin/sh > >> > >> That will open the shell on a device that can be a controlling tty > >> (/dev/ttyS0). > > > > Why shouldn't you be able to use console (or ""), so that it follows the > > console wherever that is? (ttyS0, ttyS1, or a real linux virtual > > console). > > > > Like I said, the documentation says the above is an implicit rule if you > > have no inittab. The code appears to agree. > > You have a choice. > > If you want to suppress the bothersome message and be able to send > SIGINT to a process by pressing a key (typically ^C) do it my way. > > If you want the behavior obtained by doing it your way, change nothing. > > If you want all this documented somewhere, patches are welcome. I think that there is indeed an understandable desire to start shell on the console and yet to have a ctty (have working ^C). Main reason is that this will automatically start shell on serial line or Linux vt - whichever is configured as console for the kernel. Otherwise, it's sort of not trivial where the console is. IOW: I think these complaints will never stop unless something is done about this. I decided to add an applet which helps with that. It's in svn now in "shells" section, it's called cttyhack and it has a nice (I hope) help text which explains its purpose: config CTTYHACK bool "cttyhack" default n help One common problem reported on the mailing list is "can't access tty; job control turned off" error message which typically appears when one tries to use shell with stdin/stdout opened to /dev/console. This device is special - it cannot be a controlling tty. Proper solution is to use correct device instead of /dev/console. cttyhack provides "quick and dirty" solution to this problem. It analyzes stdin with various ioctls, trying to determine whether it is a /dev/ttyN or /dev/ttySN (virtual terminal or serial line). If it detects one, it closes stdin/out/err and reopens that device. Then it executes given program. Usage example for /etc/inittab (for busybox init): ::respawn:/bin/cttyhack /bin/sh What you guys think about it? -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
Hamish Moffatt wrote: > On Thu, May 17, 2007 at 05:05:30PM -0700, David Daney wrote: >> Hamish Moffatt wrote: >>> I got the controlling tty errors as a result of the following in >>> inittab: >>> >>> ::askfirst:-/bin/sh >>> >>> Do you mean that this is wrong? (According to the documentation, it is an >>> implicit rule if inittab is missing.) >> It is incorrect. You should use something like this: >> >> ttyS0::askfirst:-/bin/sh >> >> That will open the shell on a device that can be a controlling tty >> (/dev/ttyS0). > > Why shouldn't you be able to use console (or ""), so that it follows the > console wherever that is? (ttyS0, ttyS1, or a real linux virtual > console). > > Like I said, the documentation says the above is an implicit rule if you > have no inittab. The code appears to agree. > You have a choice. If you want to suppress the bothersome message and be able to send SIGINT to a process by pressing a key (typically ^C) do it my way. If you want the behavior obtained by doing it your way, change nothing. If you want all this documented somewhere, patches are welcome. David Daney ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Thu, May 17, 2007 at 05:05:30PM -0700, David Daney wrote: > Hamish Moffatt wrote: > >I got the controlling tty errors as a result of the following in > >inittab: > > > >::askfirst:-/bin/sh > > > >Do you mean that this is wrong? (According to the documentation, it is an > >implicit rule if inittab is missing.) > > It is incorrect. You should use something like this: > > ttyS0::askfirst:-/bin/sh > > That will open the shell on a device that can be a controlling tty > (/dev/ttyS0). Why shouldn't you be able to use console (or ""), so that it follows the console wherever that is? (ttyS0, ttyS1, or a real linux virtual console). Like I said, the documentation says the above is an implicit rule if you have no inittab. The code appears to agree. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Fri, 2007-05-18 at 01:49 +0200, Denis Vlasenko wrote: > On Friday 18 May 2007 01:28, Denis Vlasenko wrote: > > Boot with init=/bin/ash, and you will get "Can't access tty" message. > > That's because fd# 0,1,2 are opened to /dev/console. > > Now execute this in ash: > > > > # exec /bin/ash /dev/tty1 2>&1 > > > > This one will work ok, because fds are opened to /dev/tty0, > > which can be a controlling tty. > > :( please s/tty0/tty1/ above... > > -- > vda This is what my init.ash contains. I'm still getting the "can't access tty" message. Do you see anything else wrong? -- ##!/bin/ash echo "Mounting real root file system..." mount -t sysfs none /sys mount -t proc none /proc mount -t ext2 /dev/hdf1 /mnt/realroot # Chain to real filesystem echo "Chaining to real file system..." #exec switch_root /mnt/realroot/sbin/init "$@" $/mnt/realroot/dev/console exec /bin/ash /dev/tty0 2>&1 -- My initramfs config for the tty/console devices is: nod /dev/tty0 666 0 5 c 4 0 nod /dev/tty1 666 0 5 c 4 1 nod /dev/tty2 666 0 5 c 4 2 nod /dev/tty3 666 0 5 c 4 3 nod /dev/tty4 666 0 5 c 4 4 nod /dev/tty5 666 0 5 c 4 5 nod /dev/tty6 666 0 5 c 4 6 nod /dev/tty7 666 0 5 c 4 7 nod /dev/tty8 666 0 5 c 4 8 nod /dev/ttyS0 666 0 5 c 5 0 nod /dev/console 644 0 0 c 5 1 ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
Hamish Moffatt wrote: > On Fri, May 18, 2007 at 01:28:00AM +0200, Denis Vlasenko wrote: >> On Thursday 17 May 2007 18:28, Dallas Clement wrote: >>> I'm getting the infamous "Can't access tty; job control turned off" >>> message when I try to invoke the ash shell during my initial bootup. >>> >>> I'm using busybox 1.5.0. I also understand that ash requires a >>> controlling tty rather than the console. Though, I don't understand all >>> the reasons. >>> >>> If I don't define a console however, I get a kernel panic from >>> initramfs. >> Boot with init=/bin/ash, and you will get "Can't access tty" message. >> That's because fd# 0,1,2 are opened to /dev/console. >> Now execute this in ash: >> >> # exec /bin/ash /dev/tty1 2>&1 >> >> This one will work ok, because fds are opened to /dev/tty0, >> which can be a controlling tty. >> >> Basically that's it. If you want ctty, open some device different from >> /dev/console > > I got the controlling tty errors as a result of the following in > inittab: > > ::askfirst:-/bin/sh > > Do you mean that this is wrong? (According to the documentation, it is an > implicit rule if inittab is missing.) It is incorrect. You should use something like this: ttyS0::askfirst:-/bin/sh That will open the shell on a device that can be a controlling tty (/dev/ttyS0). David Daney ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Fri, May 18, 2007 at 01:28:00AM +0200, Denis Vlasenko wrote: > On Thursday 17 May 2007 18:28, Dallas Clement wrote: > > I'm getting the infamous "Can't access tty; job control turned off" > > message when I try to invoke the ash shell during my initial bootup. > > > > I'm using busybox 1.5.0. I also understand that ash requires a > > controlling tty rather than the console. Though, I don't understand all > > the reasons. > > > > If I don't define a console however, I get a kernel panic from > > initramfs. > > Boot with init=/bin/ash, and you will get "Can't access tty" message. > That's because fd# 0,1,2 are opened to /dev/console. > Now execute this in ash: > > # exec /bin/ash /dev/tty1 2>&1 > > This one will work ok, because fds are opened to /dev/tty0, > which can be a controlling tty. > > Basically that's it. If you want ctty, open some device different from > /dev/console I got the controlling tty errors as a result of the following in inittab: ::askfirst:-/bin/sh Do you mean that this is wrong? (According to the documentation, it is an implicit rule if inittab is missing.) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Friday 18 May 2007 01:28, Denis Vlasenko wrote: > Boot with init=/bin/ash, and you will get "Can't access tty" message. > That's because fd# 0,1,2 are opened to /dev/console. > Now execute this in ash: > > # exec /bin/ash /dev/tty1 2>&1 > > This one will work ok, because fds are opened to /dev/tty0, > which can be a controlling tty. :( please s/tty0/tty1/ above... -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Thursday 17 May 2007 18:28, Dallas Clement wrote: > I'm getting the infamous "Can't access tty; job control turned off" > message when I try to invoke the ash shell during my initial bootup. > > I'm using busybox 1.5.0. I also understand that ash requires a > controlling tty rather than the console. Though, I don't understand all > the reasons. > > If I don't define a console however, I get a kernel panic from > initramfs. Boot with init=/bin/ash, and you will get "Can't access tty" message. That's because fd# 0,1,2 are opened to /dev/console. Now execute this in ash: # exec /bin/ash /dev/tty1 2>&1 This one will work ok, because fds are opened to /dev/tty0, which can be a controlling tty. Basically that's it. If you want ctty, open some device different from /dev/console -- vda ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Friday 18 May 2007 00:29, Hamish Moffatt wrote:
> On Thu, May 17, 2007 at 11:28:06AM -0500, Dallas Clement wrote:
> > I'm getting the infamous "Can't access tty; job control turned off"
> > message when I try to invoke the ash shell during my initial bootup.
> >
> > I'm using busybox 1.5.0. I also understand that ash requires a
> > controlling tty rather than the console. Though, I don't understand all
> > the reasons.
>
> I saw this too when I upgraded from 1.4.2 from 1.5.0, so I switched
> back. The same /dev entries work perfectly in 1.4.2. I did not have
> time/need to debug it.
I think there is nothing to "debug", as this is not a bug.
/dev/console CANNOT be a controlling tty, and code which
was trying to "fix" this was removed from init.c
The diff is a bit big:
http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/init/init.c?rev=17937&r1=17917&r2=17937
but the core of change is here:
static void console_init(void)
{
- int fd;
- int tried = 0;
- struct vt_stat vt;
struct serial_struct sr;
char *s;
- if ((s = getenv("CONSOLE")) != NULL || (s = getenv("console")) != NULL)
{
- safe_strncpy(console_name, s, sizeof(console_name));
- } else {
- /* 2.2 kernels: identify the real console backend and try to
use it */
- if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
- /* this is a serial console */
- snprintf(console_name, sizeof(console_name) - 1,
SC_FORMAT, sr.line);
- } else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
- /* this is linux virtual tty */
- snprintf(console_name, sizeof(console_name) - 1,
VC_FORMAT, vt.v_active);
- } else {
- strcpy(console_name, DEV_CONSOLE);
- tried++;
- }
+ s = getenv("CONSOLE");
+ if (!s) s = getenv("console");
+ if (s) {
+ int fd = open(s, O_RDWR | O_NONBLOCK | O_NOCTTY);
+ if (fd >= 0) {
+ dup2(fd, 0);
+ dup2(fd, 1);
+ dup2(fd, 2);
+ while (fd > 2) close(fd--);
+ }
+ messageD(L_LOG, "console='%s'", s);
}
- while ((fd = open(console_name, O_RDONLY | O_NONBLOCK)) < 0 && tried <
2) {
- /* Can't open selected console -- try
- logical system console and VT_MASTER */
- strcpy(console_name, (tried == 0 ? DEV_CONSOLE : CURRENT_VC));
- tried++;
- }
- if (fd < 0) {
- /* Perhaps we should panic here? */
See those now-removed ioctls and then 'while ((fd = open(console_name...' ?
This is the code which tried to close '/dev/console' and open
'/dev/ttyN' or '/dev/ttyS0' instead.
This is just WRONG. init should not do it. It should just use file
descriptors 0, 1, and 2 which were given to it by kernel.
--
vda
___
busybox mailing list
busybox@busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
RE: ash: Can't access tty problems (initramfs)
Thanks for the tip! At least I can make progress with it. I'd still like to know why I'm having trouble with 1.5.0. I saw some explanation in the FAQ, but I'm afraid it needs to be translated into noobese with some specific examples of how to setup the tty / console. Regards, Dallas -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hamish Moffatt Sent: Thursday, May 17, 2007 5:29 PM To: busybox@busybox.net Subject: Re: ash: Can't access tty problems (initramfs) On Thu, May 17, 2007 at 11:28:06AM -0500, Dallas Clement wrote: > I'm getting the infamous "Can't access tty; job control turned off" > message when I try to invoke the ash shell during my initial bootup. > > I'm using busybox 1.5.0. I also understand that ash requires a > controlling tty rather than the console. Though, I don't understand all > the reasons. I saw this too when I upgraded from 1.4.2 from 1.5.0, so I switched back. The same /dev entries work perfectly in 1.4.2. I did not have time/need to debug it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
Re: ash: Can't access tty problems (initramfs)
On Thu, May 17, 2007 at 11:28:06AM -0500, Dallas Clement wrote: > I'm getting the infamous "Can't access tty; job control turned off" > message when I try to invoke the ash shell during my initial bootup. > > I'm using busybox 1.5.0. I also understand that ash requires a > controlling tty rather than the console. Though, I don't understand all > the reasons. I saw this too when I upgraded from 1.4.2 from 1.5.0, so I switched back. The same /dev entries work perfectly in 1.4.2. I did not have time/need to debug it. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
ash: Can't access tty problems (initramfs)
I'm getting the infamous "Can't access tty; job control turned off" message when I try to invoke the ash shell during my initial bootup. I'm using busybox 1.5.0. I also understand that ash requires a controlling tty rather than the console. Though, I don't understand all the reasons. If I don't define a console however, I get a kernel panic from initramfs. Could someone please give me some pointers on how tty and console should be configured? I'm connected via my VGA port (not a serial port). Here is the contents of my initramfs makefile: dir /dev 755 0 0 nod /dev/tty0 666 0 5 c 5 0 nod /dev/tty1 666 0 5 c 4 1 nod /dev/tty2 666 0 5 c 4 2 nod /dev/tty3 666 0 5 c 4 3 nod /dev/tty4 666 0 5 c 4 4 nod /dev/tty5 666 0 5 c 4 5 nod /dev/tty6 666 0 5 c 4 6 nod /dev/tty7 666 0 5 c 4 7 nod /dev/tty8 666 0 5 c 4 8 nod /dev/ttyS0 666 0 5 c 5 0 nod /dev/console 644 0 0 c 5 1 nod /dev/null 666 0 0 c 1 3 nod /dev/hda 660 0 6 b 3 0 nod /dev/hda1 660 0 0 b 3 1 nod /dev/hdb 660 0 6 b 3 0 nod /dev/hdb1 660 0 0 b 3 1 nod /dev/hdf 660 0 6 b 3 0 nod /dev/hdf1 660 0 0 b 3 1 dir /bin 755 1000 1000 file /bin/busybox /home/dallas/initramfs/busybox 755 0 0 slink /bin/ash busybox 777 0 0 slink /bin/mkdir busybox 777 0 0 slink /bin/mount busybox 777 0 0 slink /bin/cat busybox 777 0 0 slink /bin/switch_root busybox 777 0 0 dir /root 700 0 0 dir /proc 755 0 0 dir /sys 755 0 0 dir /var 755 0 0 dir /var/lock 755 0 0 dir /tmp 755 0 0 dir /mnt 755 0 0 dir /mnt/realroot 755 0 0 dir /etc 755 0 0 file /etc/fstab /home/dallas/initramfs/fstab 755 0 0 file /init /home/dallas/initramfs/init.ash 755 0 0 ___ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox
