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