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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .