You are not logged in.

#1 2006-06-29 18:52:52

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 380

Another kernel panic [solved by kernel upgrade]

#
# /etc/lilo.conf
#

boot=/dev/hda
# This line often fixes L40 errors on bootup
# disk=/dev/hda bios=0x80

default=ArchCPIO
timeout=50
lba32
prompt

image=/boot/vmlinuz26
      label=ArchCPIO
      append="root=/dev/hda2 rootfstype=ext3"
      read-only
      initrd=/boot/kernel26.img

Having a Problem with this (and also with mkinitrd). This is kernel 2.6.17.1.
I dont get it.
Blind

BTW: /boot  is  /dev/hda1

Offline

#2 2006-06-29 19:20:02

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Another kernel panic [solved by kernel upgrade]

What is the kernel error? When does it happen? What are the last few lines before it fails?

Also, can your provide your mkinitcpio.conf?

Offline

#3 2006-06-30 07:42:34

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 380

Re: Another kernel panic [solved by kernel upgrade]

Sorry phrakture, you are right. Not enough information in the first post.
First of all, let me say it is a SMP machine:
dual Athlon MP 1900, 1GB RAM.
The panic appears after LILO booted the ramdisk and he wants to mount the root filesystem as far as I understand it.
As I am at work, I cannot provide you with the whole kernel message. As I remember, kinit complains about not being able to mount/find the root partition (which is why I added the rootfstype flag in the append). This did not really improve the situation (although now it stated that it mounted root)  but at the end it says:
kernel panic: kinit::attempt to kill init.
I will provide you with the full message as soon as I am home.
I have the mkinitcpio.conf, because it is the same as on my laptop:

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES=""

# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish.  This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in anyway.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
#    FILES="/etc/modprobe.conf"
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'modload' may be used in place of 'udev', but is not recommended
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
#    This setup specifies all modules in the MODULES setting above.
#    No raid, lvm, or encrypted root is needed.
#    HOOKS="base"
#
#    This setup will autodetect all modules for your system and should
#    work as a sane default
#    HOOKS="base udev autodetect ide scsi sata filesystems"
#
#    This setup will generate a 'full' image which supports most systems.
#    No autodetection is done.
#    HOOKS="base udev ide scsi sata usb filesystems"
#
#    This setup assembles an ide raid array with an encrypted root FS.
#    Note: See 'mkinitcpio -H raid' for more information on raid devices.
#    HOOKS="base udev ide filesystems raid encrypt"
#
#    This setup loads an LVM volume group on a usb device.
#    HOOKS="base udev usb filesystems lvm"
HOOKS="base udev ide filesystems"

So nothing special. I am using the same kernel and a very similar setup on my laptop (/boot is on the first partition) - except they are reiserfs: No problem with it there.
Do I have to install any extra software to use mkinitcpio/kinit/etc. that is not resolved in the dependencies? I am running the same Arch system on my Laptop since one year, so maybe I have some stuff on here, that is not on the other machine, which I only installed recently (and is only using current/extra).
Thank you for your help,
Blind

Offline

#4 2006-06-30 15:43:40

lilsirecho
Veteran
Registered: 2003-10-24
Posts: 5,000

Re: Another kernel panic [solved by kernel upgrade]

I recently discovered that kernel26beyond would fail boot because the mkinitcpio parameter fo initrd was incorrect in the Lilo bootloader.  It has been corrected as of yesterday.

I suspect a similar problem exists with your archcpio kernel because I had the same problem with the cpio kernels I loaded with the wiki Lilo data.

I had the same kernel panic in both archcpio and kernel26beyondcpio as well as the new kernel26beyond until I corrected the Lilo.

The wiki is now correct for kernel26beyond Lilo data but may not be correct for your archcpio.

The kernel panic is due to the initrd entry calling for the wrong /boot file.

Best to you big_smile


Sign of the times: Navajo blanket..made in China
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit!     X-ray confirms Iam spineless!

Offline

#5 2006-06-30 15:54:05

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Another kernel panic [solved by kernel upgrade]

Blind wrote:

at the end it says:
kernel panic: kinit::attempt to kill init.
I will provide you with the full message as soon as I am home.

Yeah, that's generic.  If kinit fails for any reason you get the "kernel panic attempting to kill kinit" - it just means "kinit fails and nothing else can happen, you're screwed!"

Kidding.  The full error would be nice.

Also, try adding the autodetect hook right after udev.  While it won't change anything, it's always possible.  Is this, by chance, an sata harddrive?

Offline

#6 2006-07-01 06:49:18

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 380

Re: Another kernel panic [solved by kernel upgrade]

Hi there,
sorry it took me so long, and thank you for your help!

Full error message is:

:: Runing Hook [filesystems]
:: Loading root filesystem module...ext3
:: Initramfs completed - control passing to kinit
kinit: Cannot open root device dev(0,0)
kinit: init not found
Kernel panic - not syncing: Attempted to kill init

Hmm, now that I am thinking about this a bit further: I guess dev(0,0) is /dev/hda or /dev/hda1? That would not be good, as the root filesystem is /dev/hda2 - can I do anything about this?
No sata drives - just plain old IDE - this computer was a freebee from work smile

Best wishes to you all and thanks again,
Blind

Offline

#7 2006-07-01 07:04:40

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 380

Re: Another kernel panic [solved by kernel upgrade]

Hi again - I like giving monologues - can you tell? My wife also complains about it.
Anyhow. I just saw this little message in the troubleshooting:

Problem
If you are having problems getting mkinitcpio to detect your hard drive giving errors akin to "Can't find device dev(0,0)" when switching to kinit, then this could be because of a conflict that the ata_piix and piix drivers have. The beyond kernel has some libata patches that cause ata_piix to *conflict* with piix.
Solution
Edit /etc/mkinitcpio.conf to only have ide or sata or scsi depending on what your system actually needs to boot.

That can't be it, I think...was that what you were looking at, phrakture?
BTW - autodetect did not improve the situation...

Oh, if it is of any help (probably not): it worked with kernel 2.6.16.X

Offline

#8 2006-07-01 21:55:18

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 380

Re: Another kernel panic [solved by kernel upgrade]

Well, changed nothing in the mkinitcpio.conf or lilo.conf. Just chrooted into Arch, did pacman -Syu and ran lilo, everything was just fine.
Don't ask me what was wrong......
Cheers,
Blind

Offline

#9 2006-07-06 03:13:11

ith140
Member
From: Ottawa, ON
Registered: 2005-07-13
Posts: 20

Re: Another kernel panic [solved by kernel upgrade]

I've had similar issues.  I use the beyond kernel, and I've removed filesystems ata_piix and just used ide_disk,piix, reiserfs.  Sometimes my system boots, sometimes it doesn't.  I don't understand why.

Offline

Board footer

Powered by FluxBB