I know serial console doesn't always guarantee normal looking output (atleast with windows Hyperterm), but attached is the output of my mips and sparc32 machines showing strange syntax errors at line 65 in /sbin/rc. Surprisingly, Line 65 is just a comment. /sbin/rc: line 65: 24 80 -7: syntax error in expression (error token is "80 -7"
Created attachment 9921 [details] SGI Indigo2 Gentoo Boot Full boot log from Kernel boot until login prompt This was taken from a serial console, Windows Hyperterminal, at 38400bps
Comment on attachment 9921 [details] SGI Indigo2 Gentoo Boot Using gawk 3.1.1-r2 baselayout 1.8.6.4-r1
Created attachment 9922 [details] SPARCstation 20 Gentoo Boot Again, Full boot log from Kernel boot until login prompt This was taken from a serial console, Windows Hyperterminal, at 38400bps gawk -3.1.1-r1 baselayout 1.8.6.4-r1 Similar error regarding /sbin/rc on line 65. Whether this is serial console related, I don't know. In both cases, line 65 is a mere comment with an ellipses at the end. It was originally though the elippses may have been to blame, but removing it doesn't change anything. It seems to be isolated to the "sysinit" section of /sbin/rc, maybe the "boot" section, but I can't verify.
Comment on attachment 9922 [details] SPARCstation 20 Gentoo Boot Whoops, check that, this boot log didn't have the /sbin/rc bug, but rather a bit different one. Nonetheless, use it in any investigation....
See if following patch to /sbin/functions.sh fixes it for you: -------------------------------------------------------------- Index: sbin/functions.sh =================================================================== RCS file: /home/cvsroot/gentoo-src/rc-scripts/sbin/functions.sh,v retrieving revision 1.30 diff -u -r1.30 functions.sh --- sbin/functions.sh 11 Mar 2003 03:31:45 -0000 1.30 +++ sbin/functions.sh 30 Mar 2003 08:18:01 -0000 @@ -59,9 +59,9 @@ COLS="24 80" stty cols 80 &>/dev/null stty rows 24 &>/dev/null -else - COLS="`getcols ${COLS}`" -fi +if + +COLS="`getcols ${COLS}`" COLS=$((${COLS} -7)) ENDCOL=$'\e[A\e['${COLS}'G' # Now, ${ENDCOL} will move us to the end of the column; -------------------------------------------------------------- Note that swapon segfaulting is prob rather a kernel related problem ...
That patch == complete and total b0rkage. kept getting "unexpected end of file" and as a result, various functions, like eend, eerror and such were undefined. End result was a hosed system. I replaced it with another functions.sh from another machine and it's fixed, but I know where the error is coming from now (bash needs to be more informative on it's errors). I'll look at it and see what your patch was trying to do, and what it did wrong, and see if I can't find some fix for it, unless you've got another fix already.
Err, whoops, sorry. Type-o. Try this one: ------------------------------------------------------------- Index: sbin/functions.sh =================================================================== RCS file: /home/cvsroot/gentoo-src/rc-scripts/sbin/functions.sh,v retrieving revision 1.30 diff -u -r1.30 functions.sh --- sbin/functions.sh 11 Mar 2003 03:31:45 -0000 1.30 +++ sbin/functions.sh 30 Mar 2003 10:09:01 -0000 @@ -59,9 +59,9 @@ COLS="24 80" stty cols 80 &>/dev/null stty rows 24 &>/dev/null -else - COLS="`getcols ${COLS}`" fi + +COLS="`getcols ${COLS}`" COLS=$((${COLS} -7)) ENDCOL=$'\e[A\e['${COLS}'G' # Now, ${ENDCOL} will move us to the end of the column;
That appears to have fixed the bad token output I was getting. With the swapon error, I ran an strace on it, and it appears to be segfaulting when attempting to engage my swap partition, /dev/sda2. I'll run mkswap on it and see what's causing problems with it. The only other issue I see regarding serial console is how the "[ ok ]" output overwrites the first 6 or so characters of the service it starts. Is this fixable anyhow? It's really minor, but might confuse people looking at output pasted from a serial console. example: [ ok ]ing eth0 up... [ ok ]ting default gateway... [ ok ]ing network filesystems... [ ok ]ing syslog-ng... [ ok ]alizing clock via ntpdate... [ ok ]ing ntpd... [ ok ]ing sshd... [ ok ]ing vcron... [ ok ]ing local...
Edit /sbin/functions.sh, and change: ------------------------------------------- # Dont output to stdout? QUIET_STDOUT="no" ------------------------------------------- to: ------------------------------------------- # Dont output to stdout? QUIET_STDOUT="yes" ------------------------------------------- We might make it default for serial console if it fixes ....
Hrmm, that does get rid of the odd output...looks less pretty though, but well, it's minor and whatever works. One other issue I noted that seems directly related to functions.sh (rather in consolefont) is there needs to be some kind of code to check for the actual presense of a console. First, on bootup, consolefont and the keymap can't be set since it can't detect a valid tty1-6 on my sparc32. only /dev/tty and /dev/tty0 exist, followed by /dev/ttyS0-3. As result, the following messages are generated: Couldnt get a file descriptor referring to the console Failed to set user font Couldnt get a file descriptor referring to the console Error loading key mappings Also, init comes under fire with these issues: INIT: Id "c1" respawning too fast: disabled for 5 minutes INIT: Id "c5" respawning too fast: disabled for 5 minutes INIT: Id "c4" respawning too fast: disabled for 5 minutes INIT: Id "c6" respawning too fast: disabled for 5 minutes INIT: Id "c3" respawning too fast: disabled for 5 minutes INIT: Id "c2" respawning too fast: disabled for 5 minutes Fixed of course by commenting out the appropriate lines in /etc/inittab, but isn't there some other way to detect this and avoid it? In regards to the swapon issue, I think it's kernel related, but I'm not sure. Google searches are extremely vague. The one return that looked remotely similar to mine also used an SMP kernel, so I suspect it may be something with sparc32 kernel SMP code. Whether it's SMP hypersparcs or SMP supersparcs I don't know. strace reveals two strange quirks, which I have no further idea about other than to post here. stat64("/dev/sda2", {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 2), ...}) = 0 swapon("/dev/sda2") = -1 EBUSY (Device or resource busy) --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ ^-- When swap is already "on", and swapon -a is run. stat64("/dev/sda2", {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 2), ...}) = 0 swapon("/dev/sda2") = 0 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ ^-- With swap "off". Oddly, even though swapon segfaults, it still turns on swap.
We actually need a "nocolor" mode. Ill work on this at some stage. As for the getty's respawning .. noting that can be done init side :( The swap issue ... I had it before on x86 kernels with preempt/rmap patches mixed. Maybe its an issue for sparc still. Try vanilla or less patched kernel?
Actually, it is a stock kernel. 2.4.21-pre6 straight off kernel.org. Maybe this is some obscure kernel bug? It's on a super-small 1gb drive anyways (gentoo barely fits). I have an 18gb drive due in soon which I'll use to see if it still does this segfaulting issue. It may just be that drive, not sure. Portage already looks to have a "NOCOLOR" option, or is this a different no color option? I might play around some with functions.sh later on. I discovered fetching the latest Windows Hyperterminal helps fix alot of issues, and the newest hyperterm supports ANSI color and is alot more friendly in dealing with serial consoles. No idea if what works on one serial console program works on others, though.
Try baselayout-1.8.6.5.
And? Does 1.8.6.5 work better on serial console ?
It does look much better on serial console. With this sparc32 system, I still run into issues with Init not loading sometimes, or at other times, it gets hung up on "Calculating Module Dependencies". It's like a game of Russian Roulette. I'm slowly rebuilding the system batively though, so hopefully these issues may be resolved. Whether they are releated to baselayout or not, I am uncertain at this point.
Ok. If you find out about the other problems, add a bug for that, or reopen this one if related.
