Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just cloned my root partition (in anticipation of a dist-upgrade), changed lilo.conf and fstab (in the cloned partition) and ran lilo.

But alas the system won't boot from the cloned partition. I can see a few pages of unsuspicous kernel messages, then it just stops.

For some reason I tried to boot from the good partition, adding init=/bin/sh and again the system didn't boot and stopped at the same kernel message. This made be believe that "there is something wrong with init".

So I decided to turn the tables and passed init=/sbin/init when booting from the "bad" partition and this indeed worked - the system booted just fine.

But I don't understand what's going on here. Does anyone have an explanation for this?

Here's my lilo,conf

# Automatically added by lilo postinst script





Edit: These are the kernel messages

[    3.258242] sd 6:0:0:1: [sdf] Assuming drive cache: write through
[    3.262845] sd 6:0:0:1: [sdf] Attached SCSI removable disk

if it stops then at this point and I won't see any of these:

[    3.490096] firewire_core 0000:07:06.0: created device fw0: GUID 00ca308600001a4d, S400
[    3.513091] nvidia: module license 'NVIDIA' taints kernel.
[    3.517657] Disabling lock debugging due to kernel taint
[    3.818951] vgaarb: device changed decodes: PCI:0000:01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[    3.823236] NVRM: loading NVIDIA UNIX x86 Kernel Module  310.40  Sun Mar  3 20:44:11 PST 2013
share|improve this question
If changing init=... option doesn't change the behavior, it's most likely that the boot procedure fails before launching init... – Levans Aug 5 '13 at 8:52
But Martin wrote that changing it to init=/sbin/init makes the system to boot correctly. The behaviour is strange. The Linux kernel should search for /sbin/init by default and if it is not able to execute init it should end in kernel panic. – pabouk Aug 5 '13 at 11:10
Passing init=/bin/sh does not result in a kernel panic either. Nor does it start a shell. – Martin Drautzburg Aug 5 '13 at 15:47
@MartinDrautzburg: What are the last messages before the kernel initialization stops? What shows after these messages when the system boots correctly? To see the messages you can try to scroll back using Shift+PgUp or you can try kernel parameter boot_delay=500. Also regarding /bin/sh: It is probably dynamically linked. If so are the dynamic libraries on the root filesystem? – pabouk Aug 5 '13 at 22:38
@MartinDrautzburg: Do you think that till the freeze point both systems have the same boot messages? I would try the following: on the working system: dmesg|grep 'Command line: ' and cat /proc/cmdline to see the actual boot parameters. mount and ls -l /proc/1/exe to see the actual binary of the init process. ldd /proc/1/exe and cat /proc/1/maps | grep -o '/.*\.so.*$' | sort | uniq to see the dynamic libraries of init. On the problematic system: Before boot I would try to remove the unneeded disks like /dev/sdf. – pabouk Aug 6 '13 at 12:21

You must log in to answer this question.

Browse other questions tagged .