No console messages during boot

brooko · 06-23-2010, 02:50 PM

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?

catkin · 06-24-2010, 11:23 AM

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).

brooko · 06-26-2010, 02:05 AM

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
cfg80211: Regulatory domain changed to country: US
	(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
	(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm)
	(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm)
	(5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
	(5490000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
	(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm)
ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
nvidia 0000:03:00.0: PCI INT A -> Link[APC5] -> GSI 16 (level, low) -> IRQ 16
nvidia 0000:03:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module  190.42  Tue Oct 20 20:25:42 PDT 2009
usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x7504
usbcore: registered new interface driver usblp
Adding 1084376k swap on /dev/sda2.  Priority:-1 extents:1 across:1084376k 
EXT4 FS on sda3, internal journal on sda3:8
lp0: using parport0 (interrupt-driven).
lp0: console ready
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ processors (2 cpu cores) (version 2.20.00)
powernow-k8:    0 : fid 0x10 (2400 MHz), vid 0xe
powernow-k8:    1 : fid 0xe (2200 MHz), vid 0x10
powernow-k8:    2 : fid 0xc (2000 MHz), vid 0x10
powernow-k8:    3 : fid 0xa (1800 MHz), vid 0x10
powernow-k8:    4 : fid 0x2 (1000 MHz), vid 0x12
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.   <<<< end of kernel


Welcome to Linux 2.6.29.6 (tty1)

slackbox login:

Comparing this to my virtual machine (VM) the next step is to start the init process, on my VM this is shown as

Code:

.....
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly on device 3:1.
Freeing unused kernel memory: 436K freed
INIT: version 2.86 booting              <<<< Start of INIT process
proc on /proc type proc (rw)            <<<< first line of rc.S
sysfs on /sys type sysfs (rw)
....

So basically any messages after the init process starts don't appear on my monitor (/dev/console).
So perhaps the init process is passing its messages to somewhere else? The man page for init states

Code:

CONSOLE
              The system console. This is really inherited from the kernel; however if it is not
              set init will set it to /dev/console by default.

So i would expect it to output to the same console the kernel is using?

My /dev/console permissions are the same as those in my VM:

Code:

user@slackbox:~$ ls -al /dev/console
crw------- 1 root root 5, 1 2010-06-26 07:02 /dev/console

thanks.

catkin · 06-26-2010, 07:34 AM

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?

slac-in-the-box · 06-26-2010, 10:13 AM

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

brooko · 06-26-2010, 11:25 AM

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
# Append any additional kernel parameters:
append=" vt.default_utf8=0"
boot = /dev/sda
compact
# Boot BMP Image.

I have got a PCI-E graphics card installed as well as on board, but i've set the PCI-E to the preferred output. I did test the on board video the other day just in case the messages were getting sent there and got nothing, so at least it proved it wasn't sending the messages to the wrong video output.
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. . . .

brooko · 06-27-2010, 07:51 AM

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?

brooko · 07-07-2010, 02:02 PM

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.

catkin · 07-08-2010, 01:48 AM

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.

brooko · 08-08-2010, 04:54 PM

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

. 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.

hughetorrance · 08-10-2010, 04:03 AM

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

el_nihilo · 08-13-2010, 05:34 AM

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.