nuking initramfs contents: Kernel panic at boot

I have the same problem on my laptop:

run-init: nuking initramfs contents: Directory not empty
...Kernel panic - not syncing: Attempted to kill init!

I am worried that this could screw up my files.

Same problem on startup and the HDD led flash. I think there is maybe a problem with the file system ( I am using LVM )

Error :

unlink_secure : chown(/dev/.tmp-254-6, 0 , 0) failed : no sufh file or directory
unlink_secure : chown(/dev/.tmp-254-6, 0000) failed : no sufh file or directory
run_program : open/dev/null failed : no such file or directory

run-init: nuking initramfs contents: Directory not empty
Kernel panic - not syncing: Attempted to kill init!

I am also using LVM.

I met same problem on my ThinkPad T43p: Occasionally (about 2 out of 5), my Gutsy system got panic on boot. I've installed my Gutsy system using alternative CD with encrypted root partition (no encryption of swap nor /boot). The panic occurred soon after I enter the correct root partition password in the splash screen.

Steps to Reproduce:
1) Boot the system
2) Input correct encrypt filesystem password in GUI splash screen

Actual Results:
Kernel panic in about 2 out of 5 boots

Expected Results:
Always good boot

Reproducibility:
About 2 out of 5 boots.

Build Date & Platform Bug Found:
Gutsy on an i686 ThinkPad T43p with encrypted root partition. Swap nor /boot not encrypted. All updates installed (no pre-release updates)

Additional info:
# fdisk -l

Disk /dev/sda: 60.0 GB, 60011642880 bytes
255 heads, 63 sectors/track, 7296 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xcccdcccd

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 1913 15361888+ 7 HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2 7054 7296 1951897+ 82 Linux swap / Solaris
/dev/sda3 1914 1943 240975 83 Linux
/dev/sda4 1944 7053 41046075 83 Linux

Partition table entries are not in disk order
root@yantp:~# mount
/dev/mapper/yantp-root on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.22-14-generic/volatile type tmpfs (rw)
/dev/sda3 on /boot type ext3 (rw)
/dev/mapper/yantp-home on /home type ext3 (rw)
securityfs on /sys/kernel/security type securityfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

After entered my encrypt filesystem password, I press "Alt-F1" swiftly to switch to console, and got this screenshot of panic.

It's a rather annoying bug. For several times I wanna show my Ubuntu Gutsy to my friends and met this problem in the field, embarrassed me! Hope this would be fixed soon.

The Hardy Heron Alpha series is currently under development and contains an updated version of the kernel. It would be helpful if you could test the latest Hardy Alpha release: http://www.ubuntu.com/testing . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. We'll keep this open against the actively developed kernel bug against 2.6.22 this will be closed. Thanks.

I'm running Hardy kernel on this machine and it's no longer suffering from this problem.

Yan Li, thanks for testing and the update. I'm glad to hear things are working for you.

Jef, since you are the original bug reporter, I'd like to get confirmation from you before closing this. Thanks.

Some time after I reported this bug, the problem disappeared (and I forgot about the bugreport). I didn't change anything on my system, except for installing updates. So I have no idea what caused the problem or what may have fixed it.

I am using the linux 2.6.24.4

I reduced the kernel configuration my removing many modules and drivers.

But after removing the last few modules I am getting the following errors as my kernel panics

run-init: nuking initramfs contents: Directory not empty
...Kernel panic - not syncing: Attempted to kill init!

Can any one please suggest me as soon as possible whts gone wrong

Its really urgent!!!

I've started getting this intermittently in the past week on 10.10/Maverick Meerkat. It's hard to get a log of the error message when it does happen but it includes:

run-init: nuking initramfs contents: Directory not empty

Kernel panic - not syncing: Attempted to kill init!

run-init not tainted 2.6.35-28-generic #49-Ubuntu

(I am using LVM if that is important.)

Haven't see my problem since the 29th March!

I am having this problem intermittently. I have Ubuntu 10.10 on an Asus EEE PC 1005 HA (Hard drive), 1 Mb of RAM, dual booting with Windows XP. This has been updated from Ubuntu 10.04 (which was all OK) just a week ago, so this might possibly related to the upgrade (?).

Additional info: this error on cold boot happened after having had an X crash also during bootup, where the screen became blank after showing the plymouth splash for only one second, then some lines with errors for a fraction of a second, then frozen. Needed to use power button. Then after a couple of times same failure, the kernel panic error:

run-init: nuking initramfs contents: Directory not empty
[ 2.768910] Kernel panic - not syncing: Attempted to kill init!
udevd-work[100]: inotify_add_watch(6, /dev/sda7, 10) failed: No such file or directory.

There are other people affected recently - see the duplicates of this bug. Dear devs, any comment?

This problem is caused by being unable to fully terminate udev when switching from the initramfs to the real root filesystem. Bug 613273 has a more detailed description of the situation. In short, the problem should be fixed for oneiric, but for the versions of udev used in older releases there doesn't seem to be any way to fix the problem 100% of the time.

> In short, the problem should be fixed for oneiric, but for the versions of udev used in older releases there
> doesn't seem to be any way to fix the problem 100% of the time.

I'm still experiencing this bug on oneiric.

I have this bug on the latest update of Ubuntu 10 (had to enter this in Windows as I can’t get past the error screen in Ubuntu).