Kernel panic after "Initializing /dev" during startup after "/init: 76: Syntax error"

Bug #74009 reported by levander on 2006-12-01
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)

Bug Description

What's going on now with my edgy upgrade from dapper (I did use update-manager) is that when I boot into the recovery mode kernel, it hangs. The last few lines:

Begin: Initializing /dev...
/init: 76: Syntax error: 0xID=4bd43095-7d5e-4829-95dd-25bb7860664
[4294680.075000] Kernel panic - not syncing : Attempted to kill init!

And here the system just hangs. Not even the power button works. I have to turn power off on the back of the computer.

Before I got into this problem, and after I started trying to upgrade, /etc/fstab has been converted to some format based on udev, and I'm wondering if this is related to my problem above? The hex numbers in the error message look similar to the ones I saw in /etc/fstab. When I would boot before, if I logged in, I'd get some warning mesage about logging in with $HOME=/. I'd log in and be able to successfully mount boot and home with /dev/hda files. After logging in with $HOME back equal to /home/username, I ran "dpkg --configure -a" to try to complete the install. And, later on rebooting, I'm now getting the kernel panic above.

levander (levander) on 2006-12-01
description: updated
description: updated

it looks like grub is passing the wrong root=UUID=$longnumber.

Can you please try to see what's in the grub menu and fix it as above?


levander (levander) wrote :

I made an edgy LiveCD and booted the problem machine with it - boots fine. It looks like the menu.lst that is installed on the system is correct. Although, I did make one mistake in typing out the UUID in the original bug report above. I changed the 5th to last character from a c to a 6.

Other things that may be wrong appreciated.

The default grub choice (which is what I'm booting) from menu.lst:

title Ubuntu, kernel 2.6.12-10-686-smp
root (hd0,0)
kernel /vmlinuz-2.6.12-10-686-smp root=UUID=4db43095-7d5e-4829-95dd-25bb786c0664 ro quiet splash
initrd /initrd.img-2.6.12-10-686-smp

Relevant line in /etc/fstab:

# /dev/hda3 -- converted during upgrade to edgy
UUID=4db43095-7d5e-4829-95dd-25bb786c0664 / ext3 defaults,errors=remount-ro 0 1

"vol_id /dev/hda3" output:

ubuntu@ubuntu:/mnt/boot/grub$ sudo vol_id /dev/hda3

levander (levander) wrote :

I just noticed something. I'm still on the 2.6.12 kernel (as is shown in the menu.lst excerpt above). With the edgy upgrade, aren't I supposed to be on 2.6.17?

I originally installed Warty on this machine, and have upgraded through every Ubuntu release. The only thing I can remember doing strange is you used to have to install an smp kernel to take advantage of dual processors. I did that way back on warty. For what reason could my kernel not have been upgraded? Will all this udev stuff work with the 2.6.12 kernel?

"ls boot/*17*" shows no files. There's not even a 2.6.17 kernel on the filesystem.

If I do need to be on 2.6.17, is there a way to upgrade a kernel on a system that won't boot? Like using the LiveCD or something?

levander (levander) wrote :

I modified /etc/fstab and the grub configuration to use /dev/hda files instead of UUID's. That got the 2.6.12 kernel to boot. There was some wierdness, like USB would not work, but I was able to use the machine. After booting 2.6.12, I "sudo aptitude install linux-generic" to get a more recent kernel.

Then I could boot reboot with the 2.6.17 (and the UUID's in the grub configuration).

It looks like what happened, is back in the hoary days I made my kernel "meta-" package linux-image-686-smp. But, unbeknownst to me, you guys stopped updating that package. So, when the edgy upgrade did all this stuff with udev, it messed my machine up.

You guys probably need to at least put a kernel version dependency in the udev package. And, since udev is so integral to edgy, maybe put an initial check in update-manager to make sure you have a minimum kernel version before starting the whole upgrade process.

There already are such checks in udev ...

This looks far more like a syntax error in the /init shell script in the initramfs!

The day before yesterday, I upgraded to Dapper. There were a couple issues, but booting and logging in went fine. So yesterday, I decided to upgrade to Edgy rather than fix the problems I had with Dapper. After a smooth update-manager process, I got described the kernel panic when the system rebooted.

I do not recall doing anything out of the ordinary with the system. Anything you would like me to do to troubleshoot the issue?

levander (levander) wrote :

Carlos, what I did to fix my system is in the 12/03 00:21 post.

First, the 2.6.17 kernel (which is what Edgy runs) is not installed on the system. You can do this just by looking at the grub menu on boot. If 2.6.17 is installed, you don't have the exact same problem I had.

Explaining a little more my post above:

You can edit the grub configuration for a specific kernel by highlighting that kernel number, pressing 'e', and changing the UUID's to /dev filenames. This doesn't modify the configuration permanently (there might be some command to tell it to be permanent, but don't have to use it). Just make sure it's a pre-edgy kernel as that's where all the udev stuff came into play.

/etc/fstab has to be modified by hand. If you can't boot your system, you can boot it off of a LiveCD and then mount /etc.

I was running 2.6.12-10-686. The solution presented above worked for me as well. Thanks.

Mike Dahlgren (dahlgren) wrote :

Thanks for the bug report. However since this bug was last reported in Edgy, I was wondering if this issue is still outstanding?

~ Mike

levander (levander) wrote :

I have no idea. The bug occurred by upgrading from Dapper to Edgy because Ubuntu switched to udev in the Edgy release. I have not tried upgrading a pre-udev system since getting over this problem.

I guess this problem would only be producable under software currently support by Ubuntu by upgrading from Dapper (pre-udev) to Hardy (which has udev). This would fall under things that are supposed to be supported by Ubuntu because both Dapper and Hardy are Long Term Support releases.

Well, maybe Dapper isn't still supported by Ubuntu? Is it 2 years or 5 years that Ubuntu supports Long Term Support releases? I don't remember.

Daniel T Chen (crimsun) on 2008-09-19
Changed in initramfs-tools:
importance: Undecided → Medium
status: New → Confirmed

Are there any updates here because Dapper and Edgy are EOL.

Changed in initramfs-tools (Ubuntu):
status: Confirmed → Incomplete
Launchpad Janitor (janitor) wrote :

[Expired for initramfs-tools (Ubuntu) because there has been no activity for 60 days.]

Changed in initramfs-tools (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers