[Gutsy] Kernel panic on boot, "run-init: nuking initramfs contents: Directory not empty"
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| initramfs-tools (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
| linux (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
| linux-source-2.6.22 (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: initramfs-tools
Overview Description:
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/
proc on /proc type proc (rw,noexec,
/sys on /sys type sysfs (rw,noexec,
varrun on /var/run type tmpfs (rw,noexec,
varlock on /var/lock type tmpfs (rw,noexec,
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/
/dev/sda3 on /boot type ext3 (rw)
/dev/mapper/
securityfs on /sys/kernel/
binfmt_misc on /proc/sys/
| Yan Li (yanli) wrote | #1 |
| Yan Li (yanli) wrote | #2 |
| iLugo (isra) wrote | #3 |
Okay, that helps explain why the rc.0 one alone did nothing for me -- I'm usually rebooting! ;-/
So the workaround is to do both --
sudo ln -s /etc/init.
sudo ln -s /etc/init.
Great job! That's a temporary work-around, and work-arounds are very good -- but when a request to test a patch or a fix comes out, you'll want to
return to the previous state and delete those symlinks so you can cleanly test.
sudo rm /etc/rc0.
sudo rm /etc/rc6.
For those who'd rather not edit, another work-around is to disconnect network cables, disable networking in nm-applet, or hit the Wi-Fi kill switc
h either before or during shutdown. If done before choosing shut-down or reboot, the hang is avoided. If done during the hang, then the remaining shutdown ha
ng at the alsa step is shortened from over 2 minutes to under 15 seconds.
@Daniel T. Chen -- are you still asking for help or information on this?