2

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
large-memory

lba32
boot=/dev/sda
root=/dev/sda3
install=/boot/boot.b
prompt
delay=30
timeout=30
vga=normal

default="Linux-3.8.2"

image=/boot/vmlinuz-3.8.2-ext4
        root=/dev/sda3
        label="Linux-3.8.2"
        vga=0x317

image=/boot/vmlinuz-3.8.2-ext4
        root=/dev/sdd3
        label="Linux-3.8.2-bak"
        vga=0x317

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
Martin Drautzburg
  • 141
  • 7
  • If changing `init=...` option doesn't change the behavior, it's most likely that the boot procedure fails **before** launching init... – Levans Aug 05 '13 at 08: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 - Ukraine stay strong Aug 05 '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 05 '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 - Ukraine stay strong Aug 05 '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 - Ukraine stay strong Aug 06 '13 at 12:21
  • @MartinDrautzburg: Also: Which distribution and version are you using? The kernel is the default one? – pabouk - Ukraine stay strong Aug 06 '13 at 12:22

0 Answers0