My current problem

After cloning the root filesystem of my debian system to an SSD (cp -ax) I no longer see the output of my rc scripts during boot from the SSD. I do see them during shutdown or when I run rc-scripts manually. I also see them when I boot into runlevel 1, login as root an then exit. Kernel is 3.8.2 compiled by myself.

When the system boots, I see the kernel messages (which look like what dmesg would show), then there are no more messages for a while until I finally see a login prompt or a display-manger login. Some of the kernel messages really originate from rc scripts but I only see the kernel messages and not the output of the rc scripts like [ ok ] starting foo themselves. Other than that the system runs okay.

I tried to boot a stock debian kernel (3.2.0-4-486) which lives on another partition (/dev/sda3) and pass it my root (/dev/sda1), so it takes my rc-scripts. In this case I see the messages.

On the internet I found a few reports about the exact same problem. But there was either no solution posted or the solution was "reinstall".

A possibly related issue is that I cannot boot into single-user mode anymore (runlevel 1 works). It boots straight into initdefault (=3). I suspect that the console is missing, sulogin fails and the boot process continues as if I had exited from sulogin. I also cannot boot into a shell (sash). I see a welcome message from sash, but it won't talk to me (no prompt).

my current theories meander around

  • Did cp -ax miss anything (e.g. /dev)?
  • Does the faster disc cause a timing problem?
  • Or is it something utterly trivial and I just cannot see it?

Edit May 4th

I finally realized that /dev/console needs to be present right from the start. So I created one, using mknod and now I see messages from the rc scripts again. While /dev/console gets created early on by udev, that doesn't seem to fix things during boot. So my original problem is solved. Still I'd like to know

  • why booting another kernel fixes the problem. /dev/console is present on /dev/sda3 (the location of the other kernel) before udev runs. This observation made me create /dev/console in the first place. But I don't understand why the kernel would take this /dev even though I passed it another root.
  • where /dev comes from during boot
  • why /dev/console created by udev isn't good enough
  • what other /dev nodes are needed

  • why booting into init=/bin/sash still doesn't work

1 Answer 1


I had similar issue with my FreeBSD livecd - on some PCs there were no output of rc scripts.

The issue was related to kernel option "dcons_crom", which was present in kernel config. When this option is enabled, console output redirected to FireWire port in case if it's present. When I have removed this option from kernel configuration, problem has gone.

Maybe your issue have the same source.

  • My 3.8.2 kernel does not have dcons_crom option in its config. But I am using firewire firewire_ohci firewire_core crc_itu_t. May 10, 2014 at 9:33
  • 'dcons_crom' is a FreeBSD kernel option, i'm not sure it exists in Linux. Try to remove FireWire support from kernel - it might help. May 19, 2014 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.