From: J. B. F. <bf...@fi...> - 2003-10-06 17:55:06
|
I'm using uml from debian unstable (linux --version says 2.4.22-5um), building a filesystem for it using rootstrap (0.3.17-1), and then booting to it in single-user mode (I need to set the root password, apparently). My commandline is: linux ubd0=/scratch/tmp.img eth0=tuntap,tap0,,192.168.88.1 An xterm pops up for virtual console #1, and then I get the "Press enter for maintenance (or type Control-D for normal startup):" message. However, keyboard input to the new xterm is ignored by uml. Instead I find input is only accepted on the original xterm (from which I started uml). Output still gets sent to the new xterm, so with some flipping back and forth I can still get things done. Any idea where to look for the problem? --Bruce Fields |
From: J. B. F. <bf...@fi...> - 2003-10-06 18:11:08
|
On Mon, Oct 06, 2003 at 01:55:02PM -0400, bfields wrote: > I'm using uml from debian unstable (linux --version says 2.4.22-5um), > building a filesystem for it using rootstrap (0.3.17-1), and then booting > to it in single-user mode (I need to set the root password, apparently). > My commandline is: > > linux ubd0=/scratch/tmp.img eth0=tuntap,tap0,,192.168.88.1 Sorry, that should have been: linux single ubd0=/scratch/tmp.img eth0=tuntap,tap0,,192.168.88.1 > An xterm pops up for virtual console #1, and then I get the > "Press enter for maintenance > (or type Control-D for normal startup):" > message. However, keyboard input to the new xterm is ignored by uml. > Instead I find input is only accepted on the original xterm (from which I > started uml). Output still gets sent to the new xterm, so with some > flipping back and forth I can still get things done. Any idea where to > look for the problem? > > --Bruce Fields |
From: J. B. F. <bf...@fi...> - 2003-10-07 02:09:39
|
On Mon, Oct 06, 2003 at 02:11:03PM -0400, J. Bruce Fields wrote: > On Mon, Oct 06, 2003 at 01:55:02PM -0400, bfields wrote: > > I'm using uml from debian unstable (linux --version says 2.4.22-5um), > > building a filesystem for it using rootstrap (0.3.17-1), and then booting > > to it in single-user mode (I need to set the root password, apparently). > > My commandline is: > > > > linux ubd0=/scratch/tmp.img eth0=tuntap,tap0,,192.168.88.1 > > Sorry, that should have been: > > linux single ubd0=/scratch/tmp.img eth0=tuntap,tap0,,192.168.88.1 > > > An xterm pops up for virtual console #1, and then I get the > > "Press enter for maintenance > > (or type Control-D for normal startup):" > > message. However, keyboard input to the new xterm is ignored by uml. > > Instead I find input is only accepted on the original xterm (from which I > > started uml). Output still gets sent to the new xterm, so with some > > flipping back and forth I can still get things done. Any idea where to > > look for the problem? Hrm, after fooling around some more, it seems to be bootlogd's fault. I haven't figured out exactly how that's supposed to work, though. --Bruce Fields |
From: <Ulf...@t-...> - 2003-10-06 18:56:59
|
Am Mon, 2003-10-06 um 19.55 schrieb J. Bruce Fields: > An xterm pops up for virtual console #1, and then I get the > "Press enter for maintenance > (or type Control-D for normal startup):" > message. However, keyboard input to the new xterm is ignored by uml. > Instead I find input is only accepted on the original xterm (from which I > started uml). Output still gets sent to the new xterm, so with some > flipping back and forth I can still get things done. Any idea where to > look for the problem? create a getty line in inittab for console0 (tty0 if not using devfs, vc/0 otherwise) |
From: J. B. F. <bf...@fi...> - 2003-10-06 21:19:23
|
On Mon, Oct 06, 2003 at 08:56:23PM +0200, Ulf Bartelt wrote: > Am Mon, 2003-10-06 um 19.55 schrieb J. Bruce Fields: > > An xterm pops up for virtual console #1, and then I get the > > "Press enter for maintenance > > (or type Control-D for normal startup):" > > message. However, keyboard input to the new xterm is ignored by uml. > > Instead I find input is only accepted on the original xterm (from which I > > started uml). Output still gets sent to the new xterm, so with some > > flipping back and forth I can still get things done. Any idea where to > > look for the problem? > > create a getty line in inittab for console0 (tty0 if not using devfs, > vc/0 otherwise) Thanks. I'm afraid I don't understand that. But I tried, e.g., # Note that on most Debian systems tty7 is used by the X Window System, # so if you want to add more getty's go ahead but skip tty7 if you run # X. # +0:2345:respawn:/sbin/getty 38400 tty0 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 and it makes no difference; the symptoms are identical.--Bruce Fields |
From: Jeff D. <jd...@ad...> - 2003-10-06 21:23:58
|
bf...@fi... said: > An xterm pops up for virtual console #1, and then I get the "Press > enter for maintenance > (or type Control-D for normal startup):" message. However, keyboard > input to the new xterm is ignored by uml. Instead I find input is only > accepted on the original xterm (from which I started uml). Output > still gets sent to the new xterm, so with some flipping back and forth > I can still get things done. Any idea where to look for the problem? Strange. The default should be that everything is on the original stdin/stdout. It's strange that it's virtual console #1, since all that stuff should be on VC #0. Somehow the output is being directed to tty1, resulting in the xterm, with the input still being read from tty0. If you want to poke around the code, arch/drivers/{stdio_console,line}.c are the places to look. Jeff |
From: J. B. F. <bf...@fi...> - 2003-10-07 18:38:21
|
On Mon, Oct 06, 2003 at 05:25:44PM -0400, Jeff Dike wrote: > bf...@fi... said: > > An xterm pops up for virtual console #1, and then I get the "Press > > enter for maintenance > > (or type Control-D for normal startup):" message. However, keyboard > > input to the new xterm is ignored by uml. Instead I find input is only > > accepted on the original xterm (from which I started uml). Output > > still gets sent to the new xterm, so with some flipping back and forth > > I can still get things done. Any idea where to look for the problem? > > Strange. The default should be that everything is on the original stdin/stdout. > It's strange that it's virtual console #1, since all that stuff should be > on VC #0. Somehow the output is being directed to tty1, resulting in the > xterm, with the input still being read from tty0. If you want to poke around > the code, arch/drivers/{stdio_console,line}.c are the places to look. The problem was that the first thing the debian initscripts do is run something called bootlogd, which uses the TIOCCONS ioctl to redirect console output to a pseudotty and then echoes the output to a log file and the "real" console. But bootlogd goes through gyrations I don't understand to guess what the real console is, and refuses to believe that it's tty0 (I suppose since tty0 usually seems to have the special meaning "this console"), substituting tty1 instead, with poor results in the uml case. Why doesn't uml treat tty0 as an alias to the current console? Are there other tools that expect this? --Bruce Fields |
From: Jeff D. <jd...@ad...> - 2003-10-07 21:49:46
|
bf...@fi... said: > Why doesn't uml treat tty0 as an alias to the current console? Are > there other tools that expect this? This isn't really a UML thing. It may be how /dev is set up (assignments of majors and minors to names), but the kernel doesn't really have anything to do with it. Jeff |
From: J. B. F. <bf...@fi...> - 2003-10-07 22:35:43
|
On Tue, Oct 07, 2003 at 05:51:47PM -0400, Jeff Dike wrote: > bf...@fi... said: > > Why doesn't uml treat tty0 as an alias to the current console? Are > > there other tools that expect this? > > This isn't really a UML thing. It may be how /dev is set up (assignments > of majors and minors to names), but the kernel doesn't really have anything > to do with it. Are you sure? Maybe I don't understand what you mean, but it sure looks to me like on a non-UML system the aliasing of /dev/tty0 to the current virtual terminal is done by the kernel. From within my UML: #ls -l /dev/tty0 crw------- 1 root tty 4, 0 Oct 7 21:04 /dev/tty0 From the host: # ls -l /dev/tty0 crw------- 1 root root 4, 0 2003-10-07 18:03 /dev/tty0 So the major and minor numbers are the same. On a virtual terminal on the host, "echo FOO >/dev/tty0" has the same effect as "echo FOO". Within the UML, the "FOO" goes to the first virtual terminal instead of the current one. This is documented in "man console": "A Linux system has up to 63 virtual consoles (character devices with major number 4 and minor number 1 to 63), usually called /dev/ttyn with 1 <= n <= 63. The current console is also addressed by /dev/console or /dev/tty0, the character device with major number 4 and minor number 0." In the absence of some reason to the contrary I'd think that people would want UML to emulate this behavior. --Bruce Fields |
From: Jeff D. <jd...@ad...> - 2003-10-09 03:02:52
|
bf...@fi... said: > On a virtual terminal on the host, "echo FOO >/dev/tty0" has the same > effect as "echo FOO". Within the UML, the "FOO" goes to the first > virtual terminal instead of the current one. OK, maybe it's something that needs fixing in the driver, although I would have thought that sort of thing would be implemented above the arch layer. Jeff |
From: J. B. F. <bf...@fi...> - 2003-10-09 18:09:45
|
On Wed, Oct 08, 2003 at 11:04:56PM -0400, Jeff Dike wrote: > bf...@fi... said: > > On a virtual terminal on the host, "echo FOO >/dev/tty0" has the same > > effect as "echo FOO". I got this wrong. Those two things aren't quite the same, as you see if you try, e.g., "sleep 2; echo FOO >/dev/tty0" and then immediately switch virtual terminals. "FOO" will be echoed to the new virtual terminal, not the one echo was run on. So "/dev/tty0" is the current (foreground) virtual terminal. As Ulf Bartelt pointed out to me, UML doesn't have any reasonable analog to this notion of the current virtual terminal. > > Within the UML, the "FOO" goes to the first > > virtual terminal instead of the current one. > > OK, maybe it's something that needs fixing in the driver, although I would > have thought that sort of thing would be implemented above the arch layer. Yep. I spent a few minutes yesterday trying to figure out where in the kernel the /dev/tty0 aliasing is done and didn't find it. --b. |