From MAILER-DAEMON Tue Mar 12 12:55:59 2013 Date: 12 Mar 2013 12:55:59 -0400 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Message-ID: <1363107359@example.com> X-IMAP: 1363107359 0000000007 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From smoser@example.com Tue Mar 12 12:48:30 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id B09BC1472123 for ; Thu, 21 Feb 2013 11:08:19 +0000 (UTC) Received: from cluster-e.mailcontrol.com (cluster-e.mailcontrol.com [85.115.58.190]) by fiordland.canonical.com (Postfix) with ESMTP id 86813A185FC for ; Thu, 21 Feb 2013 11:08:19 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly71e.srv.mailcontrol.com (MailControl) with ESMTP id r1LB8DFL003865 for ; Thu, 21 Feb 2013 11:08:13 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8U0b-0001Hi-8L for scott.moser@example.com; Thu, 21 Feb 2013 11:08:13 +0000 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by fiordland.canonical.com (Postfix) with ESMTP id 0A7F6A1865B for ; Thu, 21 Feb 2013 11:08:13 +0000 (UTC) Received: from p5b2e40d9.dip.t-dialin.net ([91.46.64.217] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1U8U0a-0006m8-UU for scott.moser@example.com; Thu, 21 Feb 2013 11:08:13 +0000 Message-ID: <5126001B.3080304@example.com> Date: Thu, 21 Feb 2013 12:08:11 +0100 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Scott Moser Subject: console questions X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4FA77024A194ABF9ADE45F76" X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: -0.068 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.69.0.181 Status: R X-Status: A X-Keywords: X-UID: 1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4FA77024A194ABF9ADE45F76 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi Scott, I think I need to get back to you and try to clarify whether I completely= understand the issue there. The last bug report you pointed at rather see= ms to be something slightly different. So what I understand is that for the kernel boot messages things can be h= andled by just having a well defined sequence of console=3D arguments in the ker= nel command line. The kernel sends boot messages out to all those and so are = visible to whatever console is looked at. The problem as I understand it is that you cannot make upstart (which han= dles the output of cloud-init) to do that. That uses /dev/console and that by definition is the preferred (last one) console. Thought there is some way to redirect console, I think that has some limi= tations and also I think there are certain variations where you cannot decide as = a program what the intended console should be. So I think there would be two possible solutions: 1. have a multiplexer daemon in userspace that provides a named pipe upst= art could use and writes that to all consoles. You can get all active cons= oles from looking at /proc/consoles. 2. there is /dev/ttyprintk which uses the kernels dmesg buffer and that w= ould hit all consoles, too. The only "problem" there is that messages send = there atm use the priority "info". We may agree to add a command-line option to change that level. Though= for tests you could try to use "dmesg -n7" to lift the limitation of what = is sent to the consoles. That probably causes more unwanted stuff and should be reset after cloud-init. But for trying it might be ok. Let me know whether I got the problem right and whether one of those woul= d work for you. Cheers, Stefan --------------enig4FA77024A194ABF9ADE45F76 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRJgAbAAoJEOhnXe7L7s6j25UP+QGFmEheKJ4b09rP3n6m2461 36SzhAbCqugj+f31yBcFPrrvU0g6J+PDogPZTLVN1n5FBh3uc/lJ156udB5ZOael jUGvKRIundynPh68ma+/yQcR21rd1dyTPibq+WcI5FtFSo4xC3XfYMiaDMKBQY/F twXNq3E6Ob/zoTRlJLlB5ZVOQg33BkwJgcjq9NVcVfJ4MYyPbwX76iAsPDp7bBw1 Dlx/8D49uiKBtBNhr7o/FZlscwm9ru4ACEmCcKIEpIOeOvroEyM8b0SOOB+Qwt6t wCrM0lLxsm+SZpf/vZ9X57OGataf0IfWnuHWDkGCKDxBMP/nQkw99WxsiaM3EoZj Qq1nGvEG57JgE2StHoFAYNRrWex6O/LqCnCK+1vfld3lmLkGik8MTuTk1HWiELbP D2xY2dMyGxekDPPZxHSM1GtM+d9PIJGFw7rzKZmojIhlsith8K9jvQTyGiLORbFx lZtLAYePEBazT1sehFSQpNW4s0lXT9cfHWbuEtIeNJyTb+LVs66n7NIkBHSkyHk0 PP4P/4t7cPs3TzEAKy5GY9OgWpWa53/6coYUGPbsJ79fBpDh0ezXBeEKP3SEruFk yni5pGfALulZRPT/AkYQQI2PbS5EUd1yKim1TY4dKace0OfHFI+kBjFS4irJgVlj tgLKCEy3fREr38PZ+Rkf =/Ym6 -----END PGP SIGNATURE----- --------------enig4FA77024A194ABF9ADE45F76-- From smoser@example.com Tue Mar 12 12:48:30 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id 148DC1472124; Thu, 21 Feb 2013 15:58:22 +0000 (UTC) Received: from cluster-e.mailcontrol.com (cluster-e.mailcontrol.com [85.115.58.190]) by fiordland.canonical.com (Postfix) with ESMTP id D65B6A188F3; Thu, 21 Feb 2013 15:58:21 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly71e.srv.mailcontrol.com (MailControl) with ESMTP id r1LFwJok031432; Thu, 21 Feb 2013 15:58:19 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8YXL-0000LF-3Z; Thu, 21 Feb 2013 15:58:19 +0000 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by fiordland.canonical.com (Postfix) with ESMTP id 2F0E5A188C4; Thu, 21 Feb 2013 15:58:19 +0000 (UTC) Received: from d14-69-66-169.try.wideopenwest.com ([69.14.169.66] helo=brickies-eth0.mosers.us) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1U8YXK-00074C-TH; Thu, 21 Feb 2013 15:58:19 +0000 Date: Thu, 21 Feb 2013 10:58:16 -0500 (EST) From: Scott Moser X-X-Sender: smoser@brickies To: Stefan Bader cc: Steve Langasek Subject: Re: console questions In-Reply-To: <5126001B.3080304@example.com> Message-ID: References: <5126001B.3080304@example.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: -0.8 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.69.0.181 Status: RO X-Status: X-Keywords: X-UID: 2 On Thu, 21 Feb 2013, Stefan Bader wrote: > Hi Scott, Thanks for following up, Stefan. I've copied Steve just because I had talked to him about this also. > I think I need to get back to you and try to clarify whether I completely > understand the issue there. The last bug report you pointed at rather seems to > be something slightly different. > > So what I understand is that for the kernel boot messages things can be handled > by just having a well defined sequence of console= arguments in the kernel > command line. The kernel sends boot messages out to all those and so are visible > to whatever console is looked at. Our issue is primarily that "well defined" requires you to know about hardware present on the system that you're going to boot, and we're trying to create an image that will work without any such knowledge. Ie, I do not know if there will be a serial device on the system. Generically, though, I'd be quite happy if all output that currently is being sent to /dev/console went to "anywhere where someone might be looking". > The problem as I understand it is that you cannot make upstart (which handles > the output of cloud-init) to do that. That uses /dev/console and that by > definition is the preferred (last one) console. > > Thought there is some way to redirect console, I think that has some limitations > and also I think there are certain variations where you cannot decide as a > program what the intended console should be. There is some way to redirect console. But, as you said, it has issues. http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246433.html I think our issue was that we wanted to redirect to /dev/ttyS0 if there was a device, but "TIOCCONS only works for pseudo terminals." > So I think there would be two possible solutions: > > 1. have a multiplexer daemon in userspace that provides a named pipe upstart > could use and writes that to all consoles. You can get all active consoles > from looking at /proc/consoles. Well, 'active' lists ttyS0 even if there is no serial device attached to the system. > 2. there is /dev/ttyprintk which uses the kernels dmesg buffer and that would > hit all consoles, too. The only "problem" there is that messages send there > atm use the priority "info". > We may agree to add a command-line option to change that level. Though for > tests you could try to use "dmesg -n7" to lift the limitation of what is > sent to the consoles. That probably causes more unwanted stuff and > should be reset after cloud-init. But for trying it might be ok. This is interesting, I was unaware of /dev/ttyprintk. This and /dev/kmsg would be good targets for failsafe situations. > > Let me know whether I got the problem right and whether one of those would work > for you. * bug 1122245: booting from a cloud image hangs until virsh console used * bug 1061977: Machine fails to commission when console=ttyS0 is present on kernel opts * bug 1016695: add console=tty1 to cloud-image kernel boot parameters * bug 1123220: cloud-image VM causes kernel panic if image is resized These bugs are all a result of us wanting/needing "by default" for kernel and user-space messages to go to ttyS0. We've chosen ttyS0 as the target as it is commonly logged or remotely readable. That might be as a "real serial console" and a package like conserv-server, or by the hypervisor in a cloud platform. If I do not pass any console= arguments on the command line, output of kernel messages and /dev/console will get assigned to the VGA device (if present). In any case where there is serial console available, it is almost certainly superior, as you can get *text* from it (and log it or search it ...). So, thats why we *want* to have 'console=ttyS0' on the command line baked into our images. The problem occurs when there is no serial device on the machine. If you boot a system with no serial device, but have 'console=ttyS0' on the kernel command line, then writes to /dev/console clearly wont be seen. That doesn't seem terribly unreasonable. That can be demonstrated by: imgurl=http://cloud-images.ubuntu.com/releases/precise/release-20130204/ubuntu-12.04-server-cloudimg-amd64-disk1.img wget $imgurl -O precise-amd64.img.dist qemu-img create -f qcow2 -b precise-amd64.img.dist disk.img echo -e "#cloud-config\npassword: passw0rd\nssh_pwauth: True" > user-data cloud-localds seed.img user-data kvm -serial none -drive file=disk.img,if=virtio -drive file=seed.img \ -curses -m 256 What causes problems is the fact that writes to /dev/console fail. log in and do something like: $ sudo sh -c 'cat /etc/passwd > /dev/console' cat: write error: Input/output error $ echo $? 1 $ cat /proc/cmdline BO... root=LABEL=cloudimg-rootfs ro console=ttyS0 $ cat /proc/consoles ttyS0 -W- (EC p a) 4:64 $ ls -l /dev/ttyS0 crw-rw---- 1 root dialout 4, 64 Feb 21 15:14 /dev/ttyS0 # sh -c "python -c 'import sys; sys.stdout.write(sys.argv[0])' > /dev/console" close failed in file object destructor: sys.excepthook is missing lost sys.stderr The problem here is that the initramfs, and then subsequently upstart have their stdout and stderr sent to /dev/console. So any program that is inherited from them (or in upstart has 'console output') will have writes to stdout fail. That means a 'set -e' shell script or just about any python program is going to fail when it tries to write its stdout. I can think of some better behaviors: * given a cmdline with 'console=tty1 console=ttyS0' and no serial device I'd like the kernel to recognize that situation and use tty1 for /dev/console. * given situation where /dev/console becomes broken, kernel could/should basically remove that from the 'console=' parameters and re-run its "find a console" routine. Then, writes to /dev/console would continue to work, and even go to VGA, which is better than no where. if a write to /dev/console fails when /dev/console is "busted", then I can modify the user-space (initramfs and upstart) to test it first. Then, if it is broken, to re-direct their output elsewhere (tty1, /dev/kmsg, /dev/ttyprintk). The fallout of this would be I'd have to write a '.' or ' ' to test if writes would work, and thus, with a working console, you'd have an additional unexpected output there. Probably not the end of the world. With a workaround like that in place, programs run from initramfs or upstart could at least sanely expect stdout and stderr writes to succeed. I had memory, though, that lead me to believe that there was a kernel buffer around /dev/console, and that as a result, you could not reliably test by writing a '.' to /dev/console. That memory came from debugging on bug 1061977, but in local testing of kvm, I can't reproduce it. I tried to reproduce that by: * modify kernel cmdline to have 'quiet' and 'console=ttyS0' * add the following to /usr/share/initramfs-tools/init immediately after /run was mounted: smdbg=/run/initramfs/smdebug i=0; while :; do i=$(($i+1)) echo -n "." ret=$? echo "$i:$ret" > "$smdbg" [ $(($i%100)) -eq 0 ] && echo "$i" 1>&2 [ $ret -eq 0 ] || break [ $i -lt 8193 ] || break done * boot a kvm system without a serial device as described above. Upon logging in, /run/initramfs/smdebug had '1:255', indicating that the first write failed with error code 255. If there is no buffer, and broken /dev/console can be reliably determined by initramfs and upstart, then we can probably work around in user-space, with something like the snippet of code in comment 5 in bug 1123220. Even if that was the case, Steve suggested that we should "fix it right" (tm) rather than "work around". From smoser@example.com Tue Mar 12 12:48:30 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id F105E147217B; Thu, 21 Feb 2013 21:13:53 +0000 (UTC) Received: from cluster-j.mailcontrol.com (cluster-j.mailcontrol.com [85.115.54.190]) by fiordland.canonical.com (Postfix) with ESMTP id CD59AA185F6; Thu, 21 Feb 2013 21:13:53 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly28j.srv.mailcontrol.com (MailControl) with ESMTP id r1LLDpO2001752; Thu, 21 Feb 2013 21:13:51 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8dSh-0000Hi-Fr; Thu, 21 Feb 2013 21:13:51 +0000 Received: from becquer.dodds.net (becquer.dodds.net [207.224.24.209]) by fiordland.canonical.com (Postfix) with ESMTP id F37C5A18954; Thu, 21 Feb 2013 21:13:50 +0000 (UTC) Received: from virgil.dodds.net (unknown [192.168.15.42]) by becquer.dodds.net (Postfix) with ESMTPA id D154B30B8F; Thu, 21 Feb 2013 13:13:48 -0800 (PST) Received: by virgil.dodds.net (Postfix, from userid 1000) id 5E61060982; Thu, 21 Feb 2013 13:13:44 -0800 (PST) Date: Thu, 21 Feb 2013 13:13:44 -0800 From: Steve Langasek To: Scott Moser Cc: Stefan Bader Subject: Re: console questions Message-ID: <20130221211344.GD12342@virgil.dodds.net> References: <5126001B.3080304@example.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: -0.8 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.74.0.138 Status: R X-Status: X-Keywords: X-UID: 3 --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi guys, On Thu, Feb 21, 2013 at 10:58:16AM -0500, Scott Moser wrote: > > Hi Scott, > Thanks for following up, Stefan. I've copied Steve just because I had > talked to him about this also. > > I think I need to get back to you and try to clarify whether I > > completely understand the issue there. The last bug report you pointed > > at rather seems to be something slightly different. > > So what I understand is that for the kernel boot messages things can be > > handled by just having a well defined sequence of console=3D arguments = in > > the kernel command line. The kernel sends boot messages out to all > > those and so are visible to whatever console is looked at. > Our issue is primarily that "well defined" requires you to know about > hardware present on the system that you're going to boot, and we're trying > to create an image that will work without any such knowledge. Ie, I do > not know if there will be a serial device on the system. > Generically, though, I'd be quite happy if all output that currently is > being sent to /dev/console went to "anywhere where someone might be > looking". > > The problem as I understand it is that you cannot make upstart (which > > handles the output of cloud-init) to do that. That uses /dev/console > > and that by definition is the preferred (last one) console. > > Thought there is some way to redirect console, I think that has some > > limitations and also I think there are certain variations where you > > cannot decide as a program what the intended console should be. > There is some way to redirect console. But, as you said, it has issues. > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246433.html > I think our issue was that we wanted to redirect to /dev/ttyS0 if there > was a device, but "TIOCCONS only works for pseudo terminals." So from my POV, I think it's fine that /dev/console only point to one of the consoles, and not to all of the endpoints that the kernel knows about via console=3D options. The problem is when the kernel points /dev/console at a device that doesn't actually *work*, causing userspace to get errors when trying to write to it. That, to me, is a kernel bug; I don't think the kernel should ever be directing /dev/console somewhere that fundamentally doesn't work, regardless of which console=3D options have been passed.=20 /dev/console is a pretty basic interface, which is assumed not just by upstart, but also by things like the initramfs; and in the case we're discussing, userspace has no reasonable fallback option if /dev/console is broken. (I don't think /dev/ttyprintk is a sensible fallback, fwiw.) In contrast, the kernel certainly *does* have enough information to fall back: it knows if it's going to return an error that it really shouldn't, and ideally could adjust where /dev/console is pointed in response. Thanks, > > So I think there would be two possible solutions: > > > > 1. have a multiplexer daemon in userspace that provides a named pipe up= start > > could use and writes that to all consoles. You can get all active co= nsoles > > from looking at /proc/consoles. > Well, 'active' lists ttyS0 even if there is no serial device attached to > the system. For the record, plymouth is intended to be just such a multiplexer daemon. But there are times when plymouth isn't running (e.g., early boot in the initramfs), which is where some of the problems seem to be happening right now. Thanks, --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org > > Let me know whether I got the problem right and whether one of those wo= uld work > > for you. > * bug 1122245: booting from a cloud image hangs until virsh console used > * bug 1061977: Machine fails to commission when console=3DttyS0 is prese= nt > on kernel opts > * bug 1016695: add console=3Dtty1 to cloud-image kernel boot parameters > * bug 1123220: cloud-image VM causes kernel panic if image is resized > These bugs are all a result of us wanting/needing "by default" for kernel > and user-space messages to go to ttyS0. We've chosen ttyS0 as the target > as it is commonly logged or remotely readable. That might be as a "real > serial console" and a package like conserv-server, or by the hypervisor in > a cloud platform. > If I do not pass any console=3D arguments on the command line, output of > kernel messages and /dev/console will get assigned to the VGA device (if > present). In any case where there is serial console available, it is > almost certainly superior, as you can get *text* from it (and log it or > search it ...). > So, thats why we *want* to have 'console=3DttyS0' on the command line bak= ed > into our images. > The problem occurs when there is no serial device on the machine. If you > boot a system with no serial device, but have 'console=3DttyS0' on the > kernel command line, then writes to /dev/console clearly wont be seen.=20 > That doesn't seem terribly unreasonable. > That can be demonstrated by: > imgurl=3Dhttp://cloud-images.ubuntu.com/releases/precise/release-2013020= 4/ubuntu-12.04-server-cloudimg-amd64-disk1.img > wget $imgurl -O precise-amd64.img.dist > qemu-img create -f qcow2 -b precise-amd64.img.dist disk.img > echo -e "#cloud-config\npassword: passw0rd\nssh_pwauth: True" > user-data > cloud-localds seed.img user-data > kvm -serial none -drive file=3Ddisk.img,if=3Dvirtio -drive file=3Dseed.i= mg \ > -curses -m 256 >=20 > What causes problems is the fact that writes to /dev/console fail. > log in and do something like: > $ sudo sh -c 'cat /etc/passwd > /dev/console' > cat: write error: Input/output error > $ echo $? > 1 > $ cat /proc/cmdline > BO... root=3DLABEL=3Dcloudimg-rootfs ro console=3DttyS0 > $ cat /proc/consoles > ttyS0 -W- (EC p a) 4:64 > $ ls -l /dev/ttyS0 > crw-rw---- 1 root dialout 4, 64 Feb 21 15:14 /dev/ttyS0 > # sh -c "python -c 'import sys; sys.stdout.write(sys.argv[0])' > /dev/c= onsole" > close failed in file object destructor: > sys.excepthook is missing > lost sys.stderr > The problem here is that the initramfs, and then subsequently upstart have > their stdout and stderr sent to /dev/console. So any program that is > inherited from them (or in upstart has 'console output') will have writes > to stdout fail. That means a 'set -e' shell script or just about any pyt= hon > program is going to fail when it tries to write its stdout. > I can think of some better behaviors: > * given a cmdline with 'console=3Dtty1 console=3DttyS0' and no serial de= vice > I'd like the kernel to recognize that situation and use tty1 for > /dev/console. > * given situation where /dev/console becomes broken, kernel could/should > basically remove that from the 'console=3D' parameters and re-run its > "find a console" routine. Then, writes to /dev/console would continue > to work, and even go to VGA, which is better than no where. > if a write to /dev/console fails when /dev/console is "busted", then I can > modify the user-space (initramfs and upstart) to test it first. Then, if > it is broken, to re-direct their output elsewhere (tty1, /dev/kmsg, > /dev/ttyprintk). The fallout of this would be I'd have to write a '.' or > ' ' to test if writes would work, and thus, with a working console, you'd > have an additional unexpected output there. Probably not the end of the > world. > With a workaround like that in place, programs run from initramfs or > upstart could at least sanely expect stdout and stderr writes to succeed. > I had memory, though, that lead me to believe that there was a kernel > buffer around /dev/console, and that as a result, you could not reliably > test by writing a '.' to /dev/console. That memory came from debugging > on bug 1061977, but in local testing of kvm, I can't reproduce it. > I tried to reproduce that by: > * modify kernel cmdline to have 'quiet' and 'console=3DttyS0' > * add the following to /usr/share/initramfs-tools/init immediately after > /run was mounted: > smdbg=3D/run/initramfs/smdebug > i=3D0; > while :; do > i=3D$(($i+1)) > echo -n "." > ret=3D$? > echo "$i:$ret" > "$smdbg" > [ $(($i%100)) -eq 0 ] && echo "$i" 1>&2 > [ $ret -eq 0 ] || break > [ $i -lt 8193 ] || break > done > * boot a kvm system without a serial device as described above. > Upon logging in, /run/initramfs/smdebug had '1:255', indicating that the > first write failed with error code 255. > If there is no buffer, and broken /dev/console can be reliably determined > by initramfs and upstart, then we can probably work around in user-space, > with something like the snippet of code in comment 5 in bug 1123220. > Even if that was the case, Steve suggested that we should "fix it right" > (tm) rather than "work around". --JwB53PgKC5A7+0Ej Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRJo4HAAoJEFaNMPMhshM938kP/2DxeWOpzVEyxYDuWsOWfl0d rk1NOfcZh1caux2aGM+t51YbTgynBCrpwGc8PC2K4YJHgBvLfGjr5xy43IUSq6Sa B8KCDxEWwC401A7XLxaxPBogvqnmhnD6E5X9wrXQP9/5oahXoeTddgHG32hMtcTD DzVkZAhlWBMO1rvEOIabXOx56UflW3/or4Yt1YMZCbnZf7Scdl8j9eFrfUUs3Ayq 6w9222O0fBjiG5pvgmtKaMJrKCTw4vnp17nnBBurZHXRDVf/BjQz1jpbpz1vK5yR Huv4uS7Rx44oL7FAWe5i5ZtSNuE8HxKWGxz9JFk/5BznbAbjNRICq+vDNPy4Uz14 3x+tQtLHO2TK4HTKXswA8XywIzHQ1OKEHbIPrNYQMgHFnkXblamPTVCPwsdPDy7J iDQm37WrKuhWxhYEyUV9GYVUtR7FqSQKf43E81Nysl64qZWpmi2/Z42ZphqNePgc hbaAk9n2hlSqcUjpaOMl3w/OXxyzehlCrFPhr0N+0+UaTBOj9mvQN01Ej889PtQY Ti/tGnXn1ZvYIaXzkKPEuJI2zgVK1TFKtnWPQyL9L2fuwZ38X6QOcNOMzE6nrSz0 aMD77K0IHCICQ23AsGRUXQxlGrWQdJEsTvTQ21OgSB9h0MYd30XBYfDV5FDzHkVC bYweXjh0evXmD1Zmkr5n =/Hnn -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej-- From smoser@example.com Tue Mar 12 12:48:30 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id 10CFF14720FD; Fri, 22 Feb 2013 09:24:51 +0000 (UTC) Received: from cluster-j.mailcontrol.com (cluster-j.mailcontrol.com [85.115.54.190]) by fiordland.canonical.com (Postfix) with ESMTP id E3D87A18822; Fri, 22 Feb 2013 09:24:50 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly42j.srv.mailcontrol.com (MailControl) with ESMTP id r1M9OjR7015201; Fri, 22 Feb 2013 09:24:45 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8os1-00019l-K6; Fri, 22 Feb 2013 09:24:45 +0000 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by fiordland.canonical.com (Postfix) with ESMTP id 6C348A18867; Fri, 22 Feb 2013 09:24:45 +0000 (UTC) Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1U8os1-0003t3-9b; Fri, 22 Feb 2013 09:24:45 +0000 Message-ID: <51273948.1060800@example.com> Date: Fri, 22 Feb 2013 10:24:24 +0100 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Steve Langasek CC: Scott Moser Subject: Re: console questions References: <5126001B.3080304@example.com> <20130221211344.GD12342@virgil.dodds.net> In-Reply-To: <20130221211344.GD12342@virgil.dodds.net> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA2DCB3E76374550187A2F49C" X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: -0.3 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.74.0.152 Status: R X-Status: A X-Keywords: X-UID: 4 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA2DCB3E76374550187A2F49C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 21.02.2013 22:13, Steve Langasek wrote: > Hi guys, >=20 > On Thu, Feb 21, 2013 at 10:58:16AM -0500, Scott Moser wrote: >>> Hi Scott, >=20 >> Thanks for following up, Stefan. I've copied Steve just because I had= >> talked to him about this also. >=20 >>> I think I need to get back to you and try to clarify whether I >>> completely understand the issue there. The last bug report you point= ed >>> at rather seems to be something slightly different. >=20 >>> So what I understand is that for the kernel boot messages things can = be >>> handled by just having a well defined sequence of console=3D argument= s in >>> the kernel command line. The kernel sends boot messages out to all >>> those and so are visible to whatever console is looked at. >=20 >> Our issue is primarily that "well defined" requires you to know about >> hardware present on the system that you're going to boot, and we're tr= ying >> to create an image that will work without any such knowledge. Ie, I d= o >> not know if there will be a serial device on the system. >=20 >> Generically, though, I'd be quite happy if all output that currently i= s >> being sent to /dev/console went to "anywhere where someone might be >> looking". >=20 >>> The problem as I understand it is that you cannot make upstart (which= >>> handles the output of cloud-init) to do that. That uses /dev/console= >>> and that by definition is the preferred (last one) console. >=20 >>> Thought there is some way to redirect console, I think that has some >>> limitations and also I think there are certain variations where you >>> cannot decide as a program what the intended console should be. >=20 >> There is some way to redirect console. But, as you said, it has issue= s. >> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg246433.htm= l >> I think our issue was that we wanted to redirect to /dev/ttyS0 if ther= e >> was a device, but "TIOCCONS only works for pseudo terminals." >=20 > So from my POV, I think it's fine that /dev/console only point to one o= f the > consoles, and not to all of the endpoints that the kernel knows about v= ia > console=3D options. The problem is when the kernel points /dev/console= at a > device that doesn't actually *work*, causing userspace to get errors wh= en > trying to write to it. That, to me, is a kernel bug; I don't think the= > kernel should ever be directing /dev/console somewhere that fundamental= ly > doesn't work, regardless of which console=3D options have been passed. = > /dev/console is a pretty basic interface, which is assumed not just by > upstart, but also by things like the initramfs; and in the case we're > discussing, userspace has no reasonable fallback option if /dev/console= is > broken. (I don't think /dev/ttyprintk is a sensible fallback, fwiw.) I= n > contrast, the kernel certainly *does* have enough information to fall b= ack: > it knows if it's going to return an error that it really shouldn't, and= > ideally could adjust where /dev/console is pointed in response. Ok, that was one of the details which before (both replies) was not clear= to me. With the added problem that when I tried (or at least thought I did) it s= eemed that giving a non-existent ttyS1 would not show up in /dev/consoles. And = as such not cause any io errors. Not sure what I did wrong but trying to repeat i= t just showed the issue at hand. Lets see what can be done there. I have not looked more deeply into it bu= t at least the message about using ttyS0 seems to arrive even before initializ= ing the serial chip/port. Which feels wrong, too. Unfortunately a lot of those th= ings come from a time where boot arguments where tailored to fit the hardware = and likely are pretty dumb. Without anything else, the safe bet would be to order the consoles so tha= t tty0 is the last/preferred. 0 seems also somewhat special as it is current con= sole and can point to other major minors (like tty1 or tty7). Anything multipl= exing would need to handle failure... but yeah, I agree this rather feels like = it a kernel problem. But needs some investigation... Cheers, Stefan >=20 > Thanks, >=20 >=20 >>> So I think there would be two possible solutions: >>> >>> 1. have a multiplexer daemon in userspace that provides a named pipe = upstart >>> could use and writes that to all consoles. You can get all active = consoles >>> from looking at /proc/consoles. >=20 >> Well, 'active' lists ttyS0 even if there is no serial device attached = to >> the system. >=20 > For the record, plymouth is intended to be just such a multiplexer daem= on. > But there are times when plymouth isn't running (e.g., early boot in th= e > initramfs), which is where some of the problems seem to be happening ri= ght > now. >=20 > Thanks, >=20 --------------enigA2DCB3E76374550187A2F49C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRJzlbAAoJEOhnXe7L7s6j0RkP/RDCBD0x58yqTdqnoeORkWb0 1MdBK2x1qyhDKKEXISAuehTbsTL6clMbNYj4nrhYE/W04tBWE3lxjbbwS2ux2/3G xey+Ww7VvqC8qyajcGhLTNEFMpZXEAGaoqHJ7qKHwN2aQmmoWknS8Je4RsahS+Vn Ctl23i+5UuSCoC8LEYvJR2TMfMt0mWcJXCn2DFLrOyH2O5KPV+LmJf2kvRic5Sc+ xfx5dF8Qr8YPw052W2/Rbo9X4tcoaAAP4gM7FLqlqKlfJtnGV/a0ZszUyqEMwuCz T6uZOEFgEC8tE+kqKVmPpY3JQZFNQnXEONiLkGhLGUOvPG3oYoYdalQQvg/Iua2B wIKenX4gnFc9TgpWRisG9olu2wUHkj6FJUinV75bA60Zd/ID4CVWq3+G/TYXVw3O Jba2Hyed/Hqf9IgHVXk9MP3HFPsp1cO6/79W/9WdW4Hf2B01krshE4Q/RnTr8pSh gFodcB6s++YEJKIqPfZKldKb/zexcV+sOPt36+ZFnkA19ho7yQOdbrrzG34/X025 tiCXY/07I83Nq9NCdCWQBU93JWeQqDA9pI4UTGqpgLSFTpnelQ13pGSkgNU5GBZX Sqkr7F8aJO3LzAJKWDqMa5kltdL54eQCWf82Vzw8eV9nvVB8K5PMxoDn9HD5l+C9 gtTNDWF0M/x8fFryZItt =lPDL -----END PGP SIGNATURE----- --------------enigA2DCB3E76374550187A2F49C-- From smoser@example.com Tue Mar 12 12:48:30 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id 7604014721EA; Fri, 22 Feb 2013 14:25:57 +0000 (UTC) Received: from cluster-j.mailcontrol.com (cluster-j.mailcontrol.com [85.115.54.190]) by fiordland.canonical.com (Postfix) with ESMTP id 43EF1A18DE9; Fri, 22 Feb 2013 14:25:56 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly59j.srv.mailcontrol.com (MailControl) with ESMTP id r1MEPaYo024191; Fri, 22 Feb 2013 14:25:36 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8tZA-0004jt-SJ; Fri, 22 Feb 2013 14:25:36 +0000 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by fiordland.canonical.com (Postfix) with ESMTP id A2795A18B05; Fri, 22 Feb 2013 14:25:36 +0000 (UTC) Received: from p5b2e3f6a.dip.t-dialin.net ([91.46.63.106] helo=[192.168.2.5]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1U8tZA-0000Vb-Gx; Fri, 22 Feb 2013 14:25:36 +0000 Message-ID: <51277FDE.8060503@example.com> Date: Fri, 22 Feb 2013 15:25:34 +0100 From: Stefan Bader User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Scott Moser CC: Steve Langasek , Andy Whitcroft Subject: Re: console questions References: <5126001B.3080304@example.com> <20130221211344.GD12342@virgil.dodds.net> <51273948.1060800@example.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig7B39D56197B0F6FB1AE84F7A" X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: 0.2 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.74.0.169 Status: R X-Status: X-Keywords: X-UID: 5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B39D56197B0F6FB1AE84F7A Content-Type: multipart/mixed; boundary="------------030505040801070801040304" This is a multi-part message in MIME format. --------------030505040801070801040304 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 22.02.2013 14:41, Scott Moser wrote: > On Fri, 22 Feb 2013, Stefan Bader wrote: >=20 >> Ok, that was one of the details which before (both replies) was not cl= ear to me. >> With the added problem that when I tried (or at least thought I did) i= t seemed >> that giving a non-existent ttyS1 would not show up in /dev/consoles. A= nd as such >> not cause any io errors. Not sure what I did wrong but trying to repea= t it just >> showed the issue at hand. >> >> Lets see what can be done there. I have not looked more deeply into it= but at >> least the message about using ttyS0 seems to arrive even before initia= lizing the >> serial chip/port. Which feels wrong, too. Unfortunately a lot of those= things >> come from a time where boot arguments where tailored to fit the hardwa= re and >> likely are pretty dumb. >> >> Without anything else, the safe bet would be to order the consoles so = that tty0 >> is the last/preferred. 0 seems also somewhat special as it is current = console >> and can point to other major minors (like tty1 or tty7). Anything mult= iplexing >> would need to handle failure... but yeah, I agree this rather feels li= ke it a >> kernel problem. But needs some investigation... >=20 > Well, except we want it to get to ttyS0. Thats the most likely "good > thing". And if console=3DttyS0 is not last, then we don't get kernel > messgaes there in the case where there is a serial device. If it *is* > last, then we dont' get messages elsewhere if there is *no* serial > device. You do get kernel messages. You don't get those messages of boot that are= written into /dev/console. >=20 > Anyway, I can somewhat justify the issue in the kernel. stuff starts > being written to /dev/console before ttyS0 might be initilaized (as you= > suggested). It could be a module not loaded yet. It could be a > netconsole!. As you say. Thinking and discussing with Andy we don't think the kernel c= an do something there without risking races or confusing changes. By placing th= e console arguments, you tell the kernel that this are consoles and which o= ne is your preferred (one you know is always there) and the kernel tries to do = its best to use this without blocking the boot. At the time usage start, ther= e may not be a actual device backing this. Even if a serial port is detected, i= n the real world the terminal connected there may be turned off. Still that mig= ht be the only and preferred console which you want to use when you turn it on.= Thats why I would use tty0 as the preferred one as that is the most likel= y to be usable under any circumstances. Having multiple console line will make ke= rnel messages appear everywhere (if possible). Which leaves the other boot mes= sages (the one that upstart lets go to /dev/console). Using /dev/ttyprintk has a similar behavior as kernel messages, just that= right now they would not appear because it uses level info and we set the conso= les to hide messages lesser than errors. Also messages coming through ttyprintk = will get prefixed by a timestamp and some special marker ("[U]"). Interestingly I found that the console redirection does actually work wit= h serial ttys, so the attached program causes writes to /dev/console to com= e out of the serial console after running it. Mind, that is is quite a hack, re= quires to have /sys mounted and maybe other changes to work with a limited libc.= -Stefan >=20 > So it is not as simple as it first appears. > Scott >> >> Cheers, >> Stefan >>> >>> Thanks, >>> >>> >>>>> So I think there would be two possible solutions: >>>>> >>>>> 1. have a multiplexer daemon in userspace that provides a named pip= e upstart >>>>> could use and writes that to all consoles. You can get all activ= e consoles >>>>> from looking at /proc/consoles. >>> >>>> Well, 'active' lists ttyS0 even if there is no serial device attache= d to >>>> the system. >>> >>> For the record, plymouth is intended to be just such a multiplexer da= emon. >>> But there are times when plymouth isn't running (e.g., early boot in = the >>> initramfs), which is where some of the problems seem to be happening = right >>> now. >>> >>> Thanks, >>> >> >> >> --------------030505040801070801040304 Content-Type: text/x-csrc; name="cons-redir.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="cons-redir.c" #include #include #include #include #include #include #include #include int ttySx_present(char x) { char path[] =3D "/sys/class/tty/ttySx/device/resources"; struct stat sbuf; path[19] =3D x; if (stat(path, &sbuf) =3D=3D 0) return 1; else return 0; } int main(void) { int fd; int rc; if (!ttySx_present('0')) { return -EINVAL; } printf("Redirecting console to ttyS0\n"); /* Drop old redirect */ fd =3D open("/dev/console", O_RDWR); if (fd >=3D 0) { rc =3D ioctl(fd, TIOCCONS, NULL); close(fd); } fd =3D open("/dev/ttyS0", O_RDWR); if (fd < 0) { printf("open failed\n"); } else { rc =3D ioctl(fd, TIOCCONS, NULL); if (rc) printf("ioctl2 -> %i(%i)\n", rc, errno); close(fd); } return 0; } --------------030505040801070801040304-- --------------enig7B39D56197B0F6FB1AE84F7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJRJ3/eAAoJEOhnXe7L7s6jQEMP/2VpwP0jgjB+4IM9s+ttp+vl hZv7ZkkLiXqAs5nS7WHndz3o7EhNRh/EvtzYKDI0zD1tFAs/7Tt78SWhKNc4/Ka1 EL7BdtTVziho8NBbvbjVE/3n2mwg6Te8Oi7ZNS0JM5S0Ok2tXD3SshMXHjqHLicz 2atOGFIThhzCq5x2Nve/tnByahOXxGsRnLuYDy/QVZR8GVyxLwoaXDcB8DxigOJx sQ+y43SilPTpLvJk9e3qCUsKrQWxIKkQ4ypcjGNFvv/OtRy22N/tQPCa6BJUy6uI GMi9fFa4QLXB0FgPuzDMWbfEZi6dSt9XAmXwHCkX0bK8EMbhN4wkKRe5GgYYf4hL 5BekZHAFB2xAOXzqnSXfYp2iz+tqMNvuj9es5hblO6sTcuLoxLcrmYy+ps0CISHe 9fuqr6M/Ef8AGAAtKGNfQZK81CsTyrsR4se4XWiMq/jO4c1L4vP1a3idCtlg3TlG eIS4dZmDtypuqgR92kAZqr8yy1p1j42GlvC2slGRPSmG7mV3BmaZZ0iwMu2wpt17 lt+thT2bjUF7p88UpwKypjtH2Pz9EAtMho++jMOupFqRZLwSRue2hb4ZQWzv/hRF RUfieD488GTG2UQeb6wuPyYRiybANEMGtRNuoIUUdOQ15ruLPxHbXzHpeTy3x6vb 6hT+mOkGB14x74gnEPqj =D8jT -----END PGP SIGNATURE----- --------------enig7B39D56197B0F6FB1AE84F7A-- From smoser@example.com Tue Mar 12 12:48:31 2013 -0400 Return-Path: X-Original-To: smoser@example.com Delivered-To: smoser@example.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by grenadilla.canonical.com (Postfix) with ESMTP id 52B7C147214A; Fri, 22 Feb 2013 16:05:46 +0000 (UTC) Received: from cluster-j.mailcontrol.com (cluster-j.mailcontrol.com [85.115.54.190]) by fiordland.canonical.com (Postfix) with ESMTP id 3842EA19469; Fri, 22 Feb 2013 16:05:46 +0000 (UTC) Received: from arctowski.canonical.com (arctowski.canonical.com [91.189.94.158]) by rly27j.srv.mailcontrol.com (MailControl) with ESMTP id r1MG5ift026710; Fri, 22 Feb 2013 16:05:44 GMT Received: from fiordland.canonical.com ([91.189.94.145]) by arctowski.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1U8v84-0004sl-44; Fri, 22 Feb 2013 16:05:44 +0000 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by fiordland.canonical.com (Postfix) with ESMTP id F1DBEA1945E; Fri, 22 Feb 2013 16:05:43 +0000 (UTC) Received: from 79-78-222-154.dynamic.dsl.as9105.com ([79.78.222.154] helo=localhost) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1U8v83-0003v5-Py; Fri, 22 Feb 2013 16:05:43 +0000 Date: Fri, 22 Feb 2013 16:05:42 +0000 From: Andy Whitcroft To: Stefan Bader Cc: Scott Moser , Steve Langasek Subject: Re: console questions Message-ID: <20130222160542.GD2736@dm> References: <5126001B.3080304@example.com> <20130221211344.GD12342@virgil.dodds.net> <51273948.1060800@example.com> <51277FDE.8060503@example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51277FDE.8060503@example.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailcontrol-Inbound: WBq!ucXEz80wFmxD6S7f3nyjenN!phNbIQWiyBG44+lo3FL0yiLKb3yjenN!phNbh+9WRKrdgbE= X-Spam-Score: 1.495 X-Scanned-By: MailControl 13381.65 (www.mailcontrol.com) on 10.74.0.137 Status: R X-Status: X-Keywords: X-UID: 6 On Fri, Feb 22, 2013 at 03:25:34PM +0100, Stefan Bader wrote: > Interestingly I found that the console redirection does actually work with > serial ttys, so the attached program causes writes to /dev/console to come out > of the serial console after running it. Mind, that is is quite a hack, requires > to have /sys mounted and maybe other changes to work with a limited libc. The suggestion here is that we would use 'console=ttyS0 console=tty0' on the kernel command line. The program that smb hinted at or similar would be the first thing run when entering userspace. This would trigger a switch from tty0 to ttyS0 (for /dev/console) if ttyS0 seemed to be working. -apw From smoser@example.com Tue Mar 12 12:48:31 2013 -0400 Date: Fri, 22 Feb 2013 08:41:38 -0500 (EST) From: Scott Moser X-X-Sender: smoser@brickies To: Stefan Bader cc: Steve Langasek Subject: Re: console questions In-Reply-To: <51273948.1060800@example.com> Message-ID: References: <5126001B.3080304@example.com> <20130221211344.GD12342@virgil.dodds.net> <51273948.1060800@example.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R X-Status: X-Keywords: X-UID: 7 On Fri, 22 Feb 2013, Stefan Bader wrote: > Ok, that was one of the details which before (both replies) was not clear to me. > With the added problem that when I tried (or at least thought I did) it seemed > that giving a non-existent ttyS1 would not show up in /dev/consoles. And as such > not cause any io errors. Not sure what I did wrong but trying to repeat it just > showed the issue at hand. > > Lets see what can be done there. I have not looked more deeply into it but at > least the message about using ttyS0 seems to arrive even before initializing the > serial chip/port. Which feels wrong, too. Unfortunately a lot of those things > come from a time where boot arguments where tailored to fit the hardware and > likely are pretty dumb. > > Without anything else, the safe bet would be to order the consoles so that tty0 > is the last/preferred. 0 seems also somewhat special as it is current console > and can point to other major minors (like tty1 or tty7). Anything multiplexing > would need to handle failure... but yeah, I agree this rather feels like it a > kernel problem. But needs some investigation... Well, except we want it to get to ttyS0. Thats the most likely "good thing". And if console=ttyS0 is not last, then we don't get kernel messgaes there in the case where there is a serial device. If it *is* last, then we dont' get messages elsewhere if there is *no* serial device. Anyway, I can somewhat justify the issue in the kernel. stuff starts being written to /dev/console before ttyS0 might be initilaized (as you suggested). It could be a module not loaded yet. It could be a netconsole!. So it is not as simple as it first appears. Scott > > Cheers, > Stefan > > > > Thanks, > > > > > >>> So I think there would be two possible solutions: > >>> > >>> 1. have a multiplexer daemon in userspace that provides a named pipe upstart > >>> could use and writes that to all consoles. You can get all active consoles > >>> from looking at /proc/consoles. > > > >> Well, 'active' lists ttyS0 even if there is no serial device attached to > >> the system. > > > > For the record, plymouth is intended to be just such a multiplexer daemon. > > But there are times when plymouth isn't running (e.g., early boot in the > > initramfs), which is where some of the problems seem to be happening right > > now. > > > > Thanks, > > > > >