I've got a Ubuntu server 12.04 64-bit packed into squashfs and booting into RAM using toram option. When I reboot the machine I get a kernel panic 3 out of 5 times, sometimes multiple times in row, but then it will eventually just work.

This is the error that I get:

Target filesystem doesn't have requested /sbin/init.
run-init: opening console: No such file or directory
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

Well, obviously /sbin/init does exist as sometimes the system loads without any issue with no changes to anything whatsoever.

Moreover the machine is brand new and memtest suggests there's no issue with the RAM itself.

Here is how my setup was prepared:

  • I've compiled Ubuntu-3.11.0-18.32 kernel with built-in aufs and squashfs support on an external 64-bit Ubuntu server 12.04 VirtualBox VM.
  • The kernel was installed on target machine and I've made a squashfs out of a copy of the filesystem with -always-use-fragments option.
  • I've installed Debian's live-boot-3.0.1-1 scripts in order to be able to boot the squashfs to RAM. The grub menu entry looks like this:

    menuentry 'Ubun2RAM' --class ubuntu --class gnu-linux --class gnu --class os {
    linux   /boot/vmlinuz-$(uname -r) BOOT=LIVE boot=live toram=filesystem.squashfs rw quiet splash apparmor=0 security="" $vt_handoff kernel.panic=1
    initrd  /boot/initrd.img-$(uname -r)

This is based on the Ubun2RAM guide available at http://roadha.us/2013/01/resilient-ubuntu-boot-to-ram-usb-stick/, the main difference being that in my case the "thumb box" and "target" is one Ubuntu server installation.

I've tried to either find out what's causing the kernel panics or to force the system to restart upon encountering one by passing kernel.panic=1 as a boot parameter or by putting the same into /etc/sysctl.conf.
The problem is that I can't view any logs from a failed start-up attempt (as the system boots into RAM) and the system never reboots after a kernel panic occurs (despite having configured it that way, or so I thought).

An ideal solution would be to get rid of the kernel panics, however I'd be satisfied with having the system reboot when a kernel panic occurs.

Any input is appreciated.


I've managed to figure this out.

Apparently the old drive on which I've stored the filesystem image sometimes isn't ready when an access attempt is made (and I found out about that by accident). I never expected a live-boot version marked as 'stable' to not have the functionality to wait for the drive to become ready, but that appears to be the case. Fortunately I found out that there's a 4.x alpha branch and updating to 4.0~alpha21 solved my issue.

I also made sure that the problem wasn't associated with my kernel and got the exact same result with 3.11.0-20.34 kernel sources compiled on the machine in question.

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.