[arch-general] Kernel panic with kernel26 2.6.32.2-2 from [core]

newer
[arch-general] Autofs5 does not...

older
[arch-general] Happy new year 22...

Heiko Baums

30 Dec 2009 30 Dec '09

4:22 p.m.

Hi, I already filed a bug report but thought it couldn't harm or even be good to post it to the mailing list, too. Since the update to kernel26 2.6.32.2-2 from [core] I can't boot this kernel anymore. I always get a kernel panic with these messages: Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. Pid: 1, comm: swapper Not tainted 2.6.32-ARCH #1 Call Trace: [<ffffffff813301c2>] ? panic+0x8a/0x14b [<ffffffff8100a28d>] ? init_post+0xad/0x100 [<ffffffff81502747>] ? kernel_init+0x19d/0x1a8 [<ffffffff8101311a>] ? child_rip+0xa/0x20 [<ffffffff815025aa>] ? kernel_init+0x0/0x1a8 [<ffffffff81013110>] ? child_rip+0x0/0x20 I found out that the reason for this is an outdated package in [core]. I don't know yet which package exactly but I guess it's mkinitcpio. After upgrading the system to [testing] and generating a new kernel26.img the system boots again. So, please, either move the packages currently in [testing] to [core] or move kernel26 2.6.32.2-2 back to [testing]. The first would be the best solution I think. See also my bug report: http://bugs.archlinux.org/task/17649 Greetings, Heiko

Show replies by date

Partha Chowdhury

31 Dec 31 Dec

2:59 a.m.

On Wed, Dec 30, 2009 at 05:22:33PM +0100, Heiko Baums wrote:

...

Hi,

I already filed a bug report but thought it couldn't harm or even be good to post it to the mailing list, too.

Since the update to kernel26 2.6.32.2-2 from [core] I can't boot this kernel anymore. I always get a kernel panic with these messages:

Failed to execute /init Kernel panic - not syncing: No init found. Try passing init= option to kernel. Pid: 1, comm: swapper Not tainted 2.6.32-ARCH #1 Call Trace: [<ffffffff813301c2>] ? panic+0x8a/0x14b [<ffffffff8100a28d>] ? init_post+0xad/0x100 [<ffffffff81502747>] ? kernel_init+0x19d/0x1a8 [<ffffffff8101311a>] ? child_rip+0xa/0x20 [<ffffffff815025aa>] ? kernel_init+0x0/0x1a8 [<ffffffff81013110>] ? child_rip+0x0/0x20

I found out that the reason for this is an outdated package in [core]. I don't know yet which package exactly but I guess it's mkinitcpio. After upgrading the system to [testing] and generating a new kernel26.img the system boots again.

So, please, either move the packages currently in [testing] to [core] or move kernel26 2.6.32.2-2 back to [testing]. The first would be the best solution I think.

See also my bug report: http://bugs.archlinux.org/task/17649

i just updated my system yesterday to kernel 2.6.32.2-2. I faced no problem. It is running as usual.After reading your mail, i looked in the pacman update log and found that only kernel and virtualbox were updated.Virtualbox is running fine also. and I don't use testing. About the kernel panic message,"Failed to execute /init" it means either the init script in the initrd image is messed up and it is not set executable or the /sbin/init executable in your system is missing ! you have to uncompress the kernel23.img file and take a look at init.

Steve Holmes

3:24 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Thu, Dec 31, 2009 at 08:29:01AM +0530, Partha Chowdhury wrote:

...

...
i just updated my system yesterday to kernel 2.6.32.2-2. I faced no problem. It is running as usual.After reading your mail, i looked in the pacman update log and found that only kernel and virtualbox were updated.Virtualbox is running fine also. and I don't use testing.

About the kernel panic message,"Failed to execute /init" it means either the init script in the initrd image is messed up and it is not set executable or the /sbin/init executable in your system is missing ! you have to uncompress the kernel23.img file and take a look at init.

I'll have to look to see if I have the same problem. I wonder why some people have been able to upgrade the kernel without incident and others are having the problem with the panic? What version of mkinitcpio is supposed to be in production these days? The version on my system is 0.5.26-1 and was built back in July of 2009. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAks8GWcACgkQWSjv55S0LfGzAACdGYIY0gY11Mbt4neKCcUmYR9e SZoAoJcea4RvJKjE/K+vO48YBuFTJ6PA =d5qF -----END PGP SIGNATURE-----

Heiko Baums

3:37 a.m.

Am Wed, 30 Dec 2009 20:24:24 -0700 schrieb Steve Holmes :

...

I'll have to look to see if I have the same problem. I wonder why some people have been able to upgrade the kernel without incident and others are having the problem with the panic? What version of mkinitcpio is supposed to be in production these days? The version on my system is 0.5.26-1 and was built back in July of 2009.

The problem occurs with mkinitcpio 0.5.26-1 from [core] but is fixed with mkinitcpio 0.5.26-2 from [testing]. Greetings, Heiko

Heiko Baums

3:43 a.m.

Am Thu, 31 Dec 2009 04:37:48 +0100 schrieb Heiko Baums :

...

The problem occurs with mkinitcpio 0.5.26-1 from [core] but is fixed with mkinitcpio 0.5.26-2 from [testing].

I don't know if only the mkinitcpio update fixed the issue or if there were other package updates from [testing] necessary because the system update to [testing] included several other updates of important packages like device-mapper, udev etc. Greetings, Heiko

Ionut Biru

8:42 a.m.

On 12/31/2009 05:43 AM, Heiko Baums wrote:

...

Am Thu, 31 Dec 2009 04:37:48 +0100 schrieb Heiko Baums:

...
The problem occurs with mkinitcpio 0.5.26-1 from [core] but is fixed with mkinitcpio 0.5.26-2 from [testing].

I don't know if only the mkinitcpio update fixed the issue or if there were other package updates from [testing] necessary because the system update to [testing] included several other updates of important packages like device-mapper, udev etc.

Greetings, Heiko

that information is not correct. yesterday i did a clean installation and i use ftp way. everything worked as expected without testing enabled. maybe is the case for ati/intel users? -- Ionut

Ionut Biru

8:54 a.m.

On 12/31/2009 10:42 AM, Ionut Biru wrote:

...

On 12/31/2009 05:43 AM, Heiko Baums wrote:

...
Am Thu, 31 Dec 2009 04:37:48 +0100 schrieb Heiko Baums:

...
The problem occurs with mkinitcpio 0.5.26-1 from [core] but is fixed with mkinitcpio 0.5.26-2 from [testing].

I don't know if only the mkinitcpio update fixed the issue or if there were other package updates from [testing] necessary because the system update to [testing] included several other updates of important packages like device-mapper, udev etc.

Greetings, Heiko

that information is not correct. yesterday i did a clean installation and i use ftp way. everything worked as expected without testing enabled.

maybe is the case for ati/intel users?

scratch the last one. mkinitcpio 0.5.26-2 the only change is for kblic-kdb version on dependency. can't be that -- Ionut

Heiko Baums

3:35 a.m.

Am Thu, 31 Dec 2009 08:29:01 +0530 schrieb Partha Chowdhury :

...

i just updated my system yesterday to kernel 2.6.32.2-2. I faced no problem. It is running as usual.After reading your mail, i looked in the pacman update log and found that only kernel and virtualbox were updated.Virtualbox is running fine also. and I don't use testing.

About the kernel panic message,"Failed to execute /init" it means either the init script in the initrd image is messed up and it is not set executable or the /sbin/init executable in your system is missing ! you have to uncompress the kernel23.img file and take a look at init.

I already did it and I couldn't find a problem. I also rebuilt kernel26.img several times with different settings in mkinitcpio.conf but this didn't help. I, btw., didn't change any settings when updating the kernel. Only updating the system to [testing] and rebuilding kernel26.img with the new mkinitcpio version from [testing] fixed the issue. So something has definitely been broken. Greetings, Heiko

Ng Oon-Ee

4:01 a.m.

On Thu, 2009-12-31 at 04:35 +0100, Heiko Baums wrote:

...

Am Thu, 31 Dec 2009 08:29:01 +0530 schrieb Partha Chowdhury :

...
i just updated my system yesterday to kernel 2.6.32.2-2. I faced no problem. It is running as usual.After reading your mail, i looked in the pacman update log and found that only kernel and virtualbox were updated.Virtualbox is running fine also. and I don't use testing.

About the kernel panic message,"Failed to execute /init" it means either the init script in the initrd image is messed up and it is not set executable or the /sbin/init executable in your system is missing ! you have to uncompress the kernel23.img file and take a look at init.

I already did it and I couldn't find a problem. I also rebuilt kernel26.img several times with different settings in mkinitcpio.conf but this didn't help. I, btw., didn't change any settings when updating the kernel.

Only updating the system to [testing] and rebuilding kernel26.img with the new mkinitcpio version from [testing] fixed the issue.

So something has definitely been broken.

Seeing as some haven't had the same problem, perhaps some investigation into the details of the systems which HAVE problems (currently two on this ML thread) would be useful? I've been using [testing], so haven't had problems.

Heiko Baums

4:26 a.m.

Am Thu, 31 Dec 2009 12:01:26 +0800 schrieb Ng Oon-Ee :

...

Seeing as some haven't had the same problem, perhaps some investigation into the details of the systems which HAVE problems (currently two on this ML thread) would be useful?

but how to investigate? Which information do you need? These packages were updated during my system update to [testing]: device-mapper (2.02.53-1 -> 2.02.56-1) udev (146-2 -> 149-1) initscripts (2009.08-1 -> 2009.11-1) iptables (1.4.5-1 -> 1.4.6-1) klibc (1.5.15-3 -> 1.5.15-4) klibc-extras (2.5-4 -> 2.5-5) klibc-kbd (1.15.20080312-10 -> 1.15.1-2) klibc-module-init-tools (3.8-1 -> 3.8-2) klibc-udev (141-3 -> 141-4) mdadm (2.6.9-1 -> 3.1.1-1) mkinitcpio (0.5.26-1 -> 0.5.26-2) pcmciautils (015-2 -> 016-1) pm-utils (1.2.6.1-2 -> 1.2.6.1-3) xz-utils (4.999.9beta-1 -> 4.999.9beta-2) zlib (1.2.3.3-3 -> 1.2.3.4-3) The packages which are involved into the boot process/the initrd need urgently be moved from [testing] to [core]. I suspect most mkinitcpio but every other package including the device mapper related packages could also be the reason because I've encrypted my whole system with dm-crypt/LUKS. The /boot partition is of course not encrypted. I'm running a simple x86_64, SATA only system with no esoteric hardware. CPU: AMD Athlon 64 X2 6000 Mainboard: Gigabyte GA-MA770-DS3 RAM: 4 GB DDR2 Graphics card: ATI Radeon HD3450 One 1 TB SATA hard disk One SATA DVD writer The SATA controller is completely set to AHCI. fdisk -l: /dev/sda5 5476 5480 40131 83 Linux /dev/sda6 5481 5612 1060258+ 82 Linux Swap / Solaris /dev/sda7 5613 8224 20980858+ 83 Linux /dev/sda8 8225 121601 910700721 83 Linux /etc/crypttab: swap /dev/sda6 ... home /dev/sda8 ... /etc/fstab: /dev/sda5 /boot ext2 defaults,noatime 0 1 /dev/mapper/swap swap swap sw 0 0 /dev/mapper/root / ext3 defaults,noatime 0 0 /dev/mapper/home /home ext3 defaults,noatime 0 0 /boot/grub/menu.lst: title Arch Linux root (hd0,4) kernel /vmlinuz26 cryptdevice=/dev/sda7:root root=/dev/mapper/root ro 5 initrd /kernel26.img

...

I've been using [testing], so haven't had problems.

That's obvious. ;-) Greetings, Heiko

Tobias Powalowski

9:50 a.m.

Am Donnerstag 31 Dezember 2009 schrieb Heiko Baums:

...

Am Thu, 31 Dec 2009 12:01:26 +0800

schrieb Ng Oon-Ee :

...
Seeing as some haven't had the same problem, perhaps some investigation into the details of the systems which HAVE problems (currently two on this ML thread) would be useful?

but how to investigate? Which information do you need?

These packages were updated during my system update to [testing]:

device-mapper (2.02.53-1 -> 2.02.56-1) udev (146-2 -> 149-1) initscripts (2009.08-1 -> 2009.11-1) iptables (1.4.5-1 -> 1.4.6-1) klibc (1.5.15-3 -> 1.5.15-4) klibc-extras (2.5-4 -> 2.5-5) klibc-kbd (1.15.20080312-10 -> 1.15.1-2) klibc-module-init-tools (3.8-1 -> 3.8-2) klibc-udev (141-3 -> 141-4) mdadm (2.6.9-1 -> 3.1.1-1) mkinitcpio (0.5.26-1 -> 0.5.26-2) pcmciautils (015-2 -> 016-1) pm-utils (1.2.6.1-2 -> 1.2.6.1-3) xz-utils (4.999.9beta-1 -> 4.999.9beta-2) zlib (1.2.3.3-3 -> 1.2.3.4-3)

The packages which are involved into the boot process/the initrd need urgently be moved from [testing] to [core].

I suspect most mkinitcpio but every other package including the device mapper related packages could also be the reason because I've encrypted my whole system with dm-crypt/LUKS. The /boot partition is of course not encrypted.

I'm running a simple x86_64, SATA only system with no esoteric hardware.

CPU: AMD Athlon 64 X2 6000 Mainboard: Gigabyte GA-MA770-DS3 RAM: 4 GB DDR2 Graphics card: ATI Radeon HD3450 One 1 TB SATA hard disk One SATA DVD writer The SATA controller is completely set to AHCI.

fdisk -l: /dev/sda5 5476 5480 40131 83 Linux /dev/sda6 5481 5612 1060258+ 82 Linux Swap / Solaris /dev/sda7 5613 8224 20980858+ 83 Linux /dev/sda8 8225 121601 910700721 83 Linux

/etc/crypttab: swap /dev/sda6 ... home /dev/sda8 ...

/etc/fstab: /dev/sda5 /boot ext2 defaults,noatime 0 1 /dev/mapper/swap swap swap sw 0 0 /dev/mapper/root / ext3 defaults,noatime 0 0 /dev/mapper/home /home ext3 defaults,noatime 0 0

/boot/grub/menu.lst: title Arch Linux root (hd0,4) kernel /vmlinuz26 cryptdevice=/dev/sda7:root root=/dev/mapper/root ro 5 initrd /kernel26.img

...
I've been using [testing], so haven't had problems.

That's obvious. ;-)

Greetings, Heiko

You could try to add all needed modules(filesystem,controllers etc.) to MODULES= array in initcpio.conf, perhaps the autodetection is not working for some reason. Just a guess, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Heiko Baums

2:20 p.m.

Am Thu, 31 Dec 2009 10:50:34 +0100 schrieb Tobias Powalowski :

...

You could try to add all needed modules(filesystem,controllers etc.) to MODULES= array in initcpio.conf, perhaps the autodetection is not working for some reason. Just a guess, greetings tpowa

I already tried this. Always the same kernel panic until I updated to [testing] and then rebuilt the initramfs again. Greetings, Heiko

Heiko Baums

2:49 p.m.

Am Thu, 31 Dec 2009 10:50:34 +0100 schrieb Tobias Powalowski :

...

You could try to add all needed modules(filesystem,controllers etc.) to MODULES= array in initcpio.conf, perhaps the autodetection is not working for some reason. Just a guess, greetings tpowa

Forgot to say that the kernel panic happened with kernel26-fallback.img, too. And the fallback image hasn't autodetection. I'm currently downgrading to [core] each package one by one and see if and when the kernel panic reappears. Another possibility is that something was broken before, wrong file permission of a file, a file was overwritten or whatever which hadn't had an impact before and that this was fixed by reinstalling/updating the appropriate package. Probably just reinstalling the appropriate package from [core], whatever package it was, would have helped, too. Greetings, Heiko

Heiko Baums

5:32 p.m.

Am Thu, 31 Dec 2009 15:49:51 +0100 schrieb Heiko Baums :

...

Forgot to say that the kernel panic happened with kernel26-fallback.img, too. And the fallback image hasn't autodetection.

I'm currently downgrading to [core] each package one by one and see if and when the kernel panic reappears.

Another possibility is that something was broken before, wrong file permission of a file, a file was overwritten or whatever which hadn't had an impact before and that this was fixed by reinstalling/updating the appropriate package. Probably just reinstalling the appropriate package from [core], whatever package it was, would have helped, too.

I don't know what was going on here but now I downgraded my system to [core] again each package one by one and the system booted every time without a kernel panic. There was likely something broken but I can't imagine what, maybe some file permissions have been change or some files have been changed or deleted by whatever and these files were overwritten by the reinstalling/updating. Probably a reinstall of the involved package from [core] had been sufficient. Greetings, Heiko

Steve Holmes

2 Jan 2 Jan

4:01 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I think I am in much better shape now. I managed to upgrade all kernel packages and speakup but had to modify my grub.cfg so all boots now with latest packages. What I have been using is kernel parameters to give me the 128x160 console but then my system stopped booting with the latest kernel upgrade. I will paste in my grub.cfg entries below so you can see what I had to comment out. Basically i stopped the insmod of the vbe module and removed the vga parms in the kernel entry. * Loading of modules #insmod vbe # Timeout for menu set timeout=15 # Set default boot entry as Entry 0 set default=0 # (0) Arch Linux menuentry "Arch Linux" { set root=(hd1,1) #linux /boot/vmlinuz26 root=/dev/sdb1 ro video=vesafb:mode=1024x768-32 vga=790 linux /boot/vmlinuz26 root=/dev/sdb1 ro initrd /boot/kernel26.img } You can see, I just commented out the entries that gave me the nice screen but at least I can boot now. Any ideas? Did something change with the 2.6.32 kernel in the VESA frame buffer department? On Thu, Dec 31, 2009 at 06:32:57PM +0100, Heiko Baums wrote:

...

Am Thu, 31 Dec 2009 15:49:51 +0100 schrieb Heiko Baums :

...
Forgot to say that the kernel panic happened with kernel26-fallback.img, too. And the fallback image hasn't autodetection.

I'm currently downgrading to [core] each package one by one and see if and when the kernel panic reappears.

Another possibility is that something was broken before, wrong file permission of a file, a file was overwritten or whatever which hadn't had an impact before and that this was fixed by reinstalling/updating the appropriate package. Probably just reinstalling the appropriate package from [core], whatever package it was, would have helped, too.

I don't know what was going on here but now I downgraded my system to [core] again each package one by one and the system booted every time without a kernel panic. There was likely something broken but I can't imagine what, maybe some file permissions have been change or some files have been changed or deleted by whatever and these files were overwritten by the reinstalling/updating. Probably a reinstall of the involved package from [core] had been sufficient.

Greetings, Heiko -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAks+xQMACgkQWSjv55S0LfHahACgl1lQ84dWisIKC6vK2utI8DLB JrsAniODlmxdGzTwxEfwPqHM6l02fP+j =hc87 -----END PGP SIGNATURE-----

Heiko Baums

4:26 a.m.

Am Fri, 1 Jan 2010 21:01:07 -0700 schrieb Steve Holmes :

...

I think I am in much better shape now. I managed to upgrade all kernel packages and speakup but had to modify my grub.cfg so all boots now with latest packages. What I have been using is kernel parameters to give me the 128x160 console but then my system stopped booting with the latest kernel upgrade. I will paste in my grub.cfg entries below so you can see what I had to comment out. Basically i stopped the insmod of the vbe module and removed the vga parms in the kernel entry.

* Loading of modules #insmod vbe

# Timeout for menu set timeout=15

# Set default boot entry as Entry 0 set default=0 # (0) Arch Linux menuentry "Arch Linux" { set root=(hd1,1) #linux /boot/vmlinuz26 root=/dev/sdb1 ro video=vesafb:mode=1024x768-32 vga=790 linux /boot/vmlinuz26 root=/dev/sdb1 ro initrd /boot/kernel26.img }

You can see, I just commented out the entries that gave me the nice screen but at least I can boot now. Any ideas? Did something change with the 2.6.32 kernel in the VESA frame buffer department?

This has nothing to do with my kernel panics which were fixed by just upgrading to [testing] and didn't came back when downgrading back to [core]. I don't know what vbe is for but the video and vga parameters may conflict each other because both set the framebuffer resolution but set different framebuffer modes/devices. So you should either use the video or the vga parameter. For me the vga parameter is sufficient. As far as I know is vga for vesafb and video for vesafb-tng (if this still exists) and other framebuffer devices like radeonfb etc. And as far as I read is video with only the resolution necessary for KMS if KMS doesn't set the correct screen resolution automatically. Greetings, Heiko

Steve Holmes

5:14 a.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Sat, Jan 02, 2010 at 05:26:38AM +0100, Heiko Baums wrote:

...

This has nothing to do with my kernel panics which were fixed by just upgrading to [testing] and didn't came back when downgrading back to [core].

I don't know what vbe is for but the video and vga parameters may conflict each other because both set the framebuffer resolution but set different framebuffer modes/devices. So you should either use the video or the vga parameter. For me the vga parameter is sufficient.

As far as I know is vga for vesafb and video for vesafb-tng (if this still exists) and other framebuffer devices like radeonfb etc.

And as far as I read is video with only the resolution necessary for KMS if KMS doesn't set the correct screen resolution automatically.

Well, I tried to remove all the video mode stuff and just leave the 'vga=790' in the line and then it's back to the crash as noted before. True enough, no panic, just a blank screen! Something has obviously changed with the kernel upgrade from 2.6.31.6 to 2.6.32.2 as far as frame buffer support is concerned. I got the suggested video mode configuration stuff from a grub2 item on the arch wiki. At least now I can experiment with different grub entries and keep a good stable one available with the latest kernels. I'm just trying to get my big screen back <sigh>. See how spoiled we get when something breaks?:) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAks+1jYACgkQWSjv55S0LfFr6ACfSY4kNZz5CLJlwRgHURdj8k6z r/EAoISmrL2TXwIWuFqVHIbr6eU90nK1 =h1pJ -----END PGP SIGNATURE-----

5243

Age (days ago)

5246

Last active (days ago)

List overview

Download

16 comments

6 participants

participants (6)

Heiko Baums
Ionut Biru
Ng Oon-Ee
Partha Chowdhury
Steve Holmes
Tobias Powalowski