No console messages during boot
hi guys,
I'm running slack64 13.0. At initial boot i see the two penguins and text from th kernel scrolls past until my root partition is mounted where upon all messages stop until the console prompt or KDM pops up. Everything seems to be operating as normal but i've no idea whats happening during the rc scripts (FS checking, etc). When shutting down though the rc.6/rc.0 script messages appear in the console though. To my knowledge i've not changed anything that would effect this (just modified inittab for runlevel 4 & tty4,5,6 in runlevel 4). There's nothing in dmesg but most messages don't get logged there as i understand. Any idea's? |
The root partition is mounted by /etc/rc.d/rc.S. Find the last message that appears on the console and then inspect the next lines of rc.S. If you can't find what's causing the problem, post them here (CODE tags would be nice).
|
Thanks for the pointer catkin.
Comparing the output from booting SW64 in a virtual machine with the output on my screen it appears that the console messages stop at the point where the kernel hands over to the init process. When i set runlevel 3 as default, all that appears on my monitor is kernel output a pause of ~20seconds with no text scrolling then the login prompt. Code:
usb 2-8: configuration #1 chosen from 1 choice Code:
..... So perhaps the init process is passing its messages to somewhere else? The man page for init states Code:
CONSOLE My /dev/console permissions are the same as those in my VM: Code:
user@slackbox:~$ ls -al /dev/console |
Mysterious! The console is working otherwise you wouldn't see the kernel messages. The /dev/console attributes look sane. What happens if you write to /dev/console? On my system echo foo > /dev/console does display "foo" on the console even when run by a non-root user but tty1 is commented out of inittab (#@ c1:12345:respawn:/sbin/agetty 38400 tty1 linux) which may or may not make a difference. Are you passing any parameters to the kernel that might affect the console?
|
I have the console set to the db9 serial port on some systems, and view the startup messages remotely with minicom. On those systems, if I had standard display monitors plugged into them, the behavior you describe would occur--that is, the start up messages are not visible on the display, but they are visible to minicom over the serial port...
maybe lilo is appending a console option to the kernel in lilo.conf, or maybe the tty for serial is uncommented in inittab |
Hi guys,
Thanks for the input. If i boot to runlevel 3 i can echo foo > /dev/console and it appears but only as root not as my normal user, which makes sense since the permissions are set so that only root has rw access. This is also the case in my VM All serial & dialup lines are commented out in lilo.conf. The only things being appended to the kernel in lilo.conf is default font Code:
# Start LILO global section I was considering trying the serial output to see if i can get the boot messages to appear over serial. I'll try that later when i have my serial cables. I'll keep testing things, watch this space. . . . |
right, i've tried setting up a serial console and its the same thing. Boot messages continue until the INIT process starts where all messages stop until the console appears.
so it seems that something is telling the INIT process to not display messages? However when i shutdown/reboot the rc.0/6 script messages appear? any ideas? |
still struggling with this one. Don't really want to upgrade to 13.1 until i've got this sorted.
I've done some more testing, changed from using the NVidia 190.XX driver back to vesa, still no console messages once init starts. However something i did try was to add append = "console=/dev/console" to my default kernel section in lilo.conf. This had the effect of removing all console messages to the point where i see the two penguins and a cursor up until /bin/login fires up! I also tried setting append = "console=/dev/tty" but got the same results. So it would appear that where ever /dev/console is during boot it isn't what my monitors attache to. Without the append statement in lilo.conf at least i get kernel messages up until init starts. I have onboard gfx card and a PCI-E installed, might this effect the /dev/console location? It's strange because during reboot/shutdown the messages do appear??? Anyone got any ideas? Thanks. |
This is a rare problem so it's something highly specific to your system; perhaps the init binary or the udev system initialisation files (relevant to the console) have suffered unwanted changes. The quickest and easiest way forward, especially if you are thinking of migrating to 13.1 anyway, might be to install 13.1 and see if the problem goes away. I'm assuming your file system layout facilitates having 13.0 and 13.1 dual-boot.
|
I thought i'd revisit this thread just to close it off. I'd say its not so much solved as fixed.
In the end i did a fresh install of slackware64-13.0 having backed up my /etc directory, patches and non-standard packages that i've built. I downloaded a fresh 13.0 install iso and burnt it to a new dvd then verified the image after burning to be sure (something i didn't do first time round**). I only formatted my root partition as home is on another partition. After a fresh install the console messages appeared throughout the boot sequence and persisted after copying over all my old configs and upgrading all packages. So as catkin suggested there must have been something corrupt with my original install. I must says its refreshing to be able to do a fresh install and be able to restore a system so quickly back to how it was and only having to reboot once to change to a generic kernel! Try doing that with windows! ** update. I ran an md5 check on my original install dvd and found the check sum to be wrong so must have installed initially from a duff dvd :redface:. The only reason for not doing so initially was because running a checksum on the dvd is a bit more involves than checking a iso image. So lesson learned, i now use slackpkg to do my updates as well as it validates downloads. Thanks to those who were kind enough to offer assistance/suggestions. |
Hi... I see you are over on the Mepis forum sometimes,welcome to this forum... Method is what you used to resolve your problem,Method is I think more important than the job itself,its how you go about something and in this case you were careful and practical with the each step you took... as it happens I have to keep reminding myself of this because I often push ahead ignoring all the checks...saves time... LOL
|
There's nothing "highly specific" about that issue (and I would have expected better than a "just reinstall" answer from fellow Slackware users, but I guess when you haven't experienced that issue, it's hard to troubleshoot it).
Not seeing the init messages on the console is a massive pain in the ass, and something you definitely want to sort out without having to reinstall. This issue has happened to me quite a few times already, on various Slackware distros (including armedslack 13.0), and I don't think it's limited to Slackware. When that happens, if you add an "echo $CONSOLE > /dev/ttyS0" in your rc.local, you'll see that the CONSOLE variable fed to init is defined /dev/null, so obviously, all the init console messages are lost. My understanding is that this is primarily due to udev rebuilding /dev when root is mounted, and init missing the console device as a result. You might be able to get away with adding a rule for your console or serial port in /etc/udev/rules.d (haven't tried that) but a better solution is to actually keep the /dev nodes that were used by the kernel even after root is mounted, and to do that, you just need to boot a kernel that has DEVTMPFS_MOUNT enabled. To enable that option, just go to Device Drivers ---> Generic Driver Options in your kernel config, and make sure that both "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)" and "Automount devtmpfs at /dev" are enabled. This ensures that the same /dev tree is used before and after root is mounted, and, if you already had the kernel messages on your console, then you'll get the init messages as well. |
All times are GMT -5. The time now is 12:13 PM. |