When using OpenRC (2.x-3.x) over a serial connection, all status replies of started services ("[ OK ]") are on a newline. This causes the boot console to excessively scroll, and is somewhat annoying when screen space is limited and everything is whizzing by twice as fast, as a result of the boot process printing twice as many lines (since [ OK ] is on it's own line). Reproducible: Always Steps to Reproduce: 1. Install OpenRC w/Baselayout 2.0 2. Setup system for serial access (in grub: console=ttyS0,9600, uncomment ttyS0 lines in inittab) 3. Boot system with serial terminal attached 4. Observe as all [ OK ] or other status results are printed on a newline Actual Results: The same thing as every time. Boot console scrolls twice as fast, since there are twice as many lines being printed by OpenRC. Expected Results: In Baselayout 1.x, running over a serial terminal would have the init scripts assume the console was 80x25 (I think??) and format the [ OK ] and other status messages accordingly, on the *same* line as the originating message- for example: * Starting sshd ... [ OK ] Whereas OpenRC prints the following: * Starting sshd ... [ OK ] Personally, I don't think Baselayout 1.x formatting is required (having all the [ OK ]'s line up in a column). If OpenRC were to simply print the result status after the service text, ie: * Starting sshd ... [ OK ] This would be far more suitable then placing the result on a newline.
uberpc libeinfo # /etc/init.d/sshd restart * Stopping sshd ... [ok] * Starting sshd ... [ok] uberpc libeinfo # /etc/init.d/sshd restart &>/tmp/x uberpc libeinfo # cat /tmp/x * Stopping sshd ... [ok] * Starting sshd ... [ok] uberpc libeinfo # Looks fine to me. I don't have a serial console to find out what's special about it, but we do have some rules. Basically your console is reporting itself as a full tty AND has a TERM value we intrinsically understand OR termcap thinks it's colour if you've linked to ncurses. Does does "tty" say about the console and what is the TERM value of it?
openrc has always been broken on my serial console systems. what the console happens to report as tty doesnt matter much since there isnt anything we can do about it ... the settings are coming from the kernel. i'm not near a serial console atm though to get said values ...
Hmm. `tty` simply returns "/dev/ttyS0". `echo $TERM` simply returns whatever I've specified in /etc/inittab for the agetty serial lines, so vt220 in this case (default vt100). Baud is set to 38400, but setting it to 9600 or even 115200 has no effect. What's odd is that this only effects startup and shutdown messages, as the system is booted or halted. If I log in over serial (and $TERM is set to either vt100 or vt220), then the OpenRC output is colorless and I get the following: Mybox ~ # /etc/init.d/gpm restart * Stopping gpm ... [ ok ] * Starting gpm ... [ ok ] Which is correct. If I type halt on the very same session, I get the following: Mybox ~ # halt INIT: Sending processes the TERM signaln Oct 26 * Stopping local ... [ ok ] * Stopping vixie-cron ... [ ok ] * Saving random seed ... [ ok ] * Deactivating swap devices ... [ ok ] * Stopping sshd ... [ ok ] * Unmounting network filesystems ... [ ok ] (snip many more lines of the same stuff) Two things I notice here- one is that the output is colorful (the * is green) and formatted incorrectly (as opposed to being non-colorful and formatted properly, re: above), and the "INIT: Sending processes the TERM signal" seems to run into something else (with the date on the end, not sure if this is OpenRC related). There's a line under ebegin() in libeinfo.c that basically seems to check if the terminal supports color and prints a "\n" if this is the case. If I remove that, then the serial output is formatted correctly during startup/shutdown, but this breaks formatting under an SSH session or on the local console (the [ OK ] overwrites the status line, so you get "[ ok ]activating swap devices ..." instead of "Deactivating swap devices ... [ OK ]"). It almost seems like OpenRC is getting confused about what exactly the console is that it's running under- if it's serial or something else that supports the normal formatting you'd see on the local console. BTW: It would almost be nice to be able to set the "terminal width" in /etc/rc.conf for serial lines- and then format the [ OK ] column when running over serial accordingly. -KT
that's because the other output is coming from the init process which doesnt have this getty glue. it hooks straight up to /dev/console and its env/setup is whatever the kernel gave it. look in /proc/1/ at files like environ and fd/ and ...
Okay... /proc/1/environ states that TERM is "linux", even though we're running on Serial. `tty` does indeed report that the tty is /dev/ttyS1 (or S0) when I'm logged in over Serial. Not sure what else to do here. I'd love to go with OpenRC, but the whole serial thing is so bloody annoying... -KT
I would suggest that init needs to be fixed to report $TERM correctly.
Does it work if you specify TERM=foo on the kernel commandline? Replace foo with whatever TERM you configured in inittab.
Over a year since the last comment on this bug. This one will not block the stablereq 295613 because it isn't serious enough to be a blocker.
I see the same when connecting on xen domU console. During boot and logged in on /dev/hvc0 [ OK ] is always printed on a newline. Connected by SSH and it prints in the 'old' style.
I too am seeing this. I have an Alix board whose console is just a serial port. I suspect the reason that this bug was not commented on for a while is that there were not many people people using openrc with serial consoles. Now that baselayout2 is stable there will be a few more. Is it possible that this could be fixed please? Or is there somewhere early in the startup where I could set the TERM variable as a workaround?
Let me inform you (as I've written in gentoo-user@l.g.o) that the *same* behavior is eminently observable *and* reproducible when running Gentoo x86 on XenServer. *General* steps to reproduce: 1. Install Gentoo as usual (ensure that Xen PV supports are enabled) 2. Remove references to tty* and replace with single references to hvc0 3. Shutdown 4. Change VM mode into PV 5. Power on 6. Observe boot via XenCenter System boots okay, except that the status replies ALL have their "[ OK ]" uncolored and on a new line. (The asterisk is colored, though).
I am using openrc 0.9.3-r1 on ~amd64 and try to figure out how to use serial output at all. This is in my inittab: s0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102 This is my kernel-append: console=ttyS0,115200n8 console=tty1 I also enabled the serial port for grub2 and except for openrc everything else (grub2, memtest86+, kernel-booting-messages until openrc starts, then getty after openrc is finished) works over my serial line. On the other end I connected with minicom 2.4 and putty. It would be nice to have at least some buggy output :-)
looks like Roy's suggestion in comment #8 was missed. if you set TERM=vt220 on your kernel command line, i bet it works much better. i'd have to grub around the kernel source code to see if it unconditionally sets TERM=linux for all consoles.
I've added "TERM=vt220" to the kernel command line, but it didn't make any difference. Same for "TERM=vt100"
