fc2 kernel panic

Ted Kaczmarek fedora at linsolutions.com
Mon May 24 00:40:25 UTC 2004


     A. Did a yum upgrade earlier today from fc1 to fc2 and it appears
        like the initrd.imgcreated is bad. Boot squaks like it can't
        read the drive label, booted into 2.4 kernel and dumpe2fs shows
        the right label. This box has 2 scsi drives, 3 ide and 2
        cdrom's, smp athlon.

My typical work around is to rebuild kernel and not use initrd.img.
But this looks different to my untrained eyes.

glibc-2.3.3-27
mkinitrd-3.5.22-1

root at inyoureyes boot]# ls -latr initrd-2.*
-rw-rw-r--  1 root root 276009 Aug 20  2003 initrd-2.4.20-20.9.img
This one post yum upgrade.
-rw-r--r--  1 root root 195900 May 23 18:28initrd-2.6.5-1.358smp.img.old
This one I created "mkinitrd 2.6.5-1.358"
-rw-r--r--  1 root root 194628 May 23 18:34 initrd-2.6.5-1.358smp.img
And Arjans latest test kernel.
-rw-r--r--  1 root root 195429 May 23 19:13 initrd-2.6.6-1.376smp.img


mkrootdev: label / not found
mount: error 2 mounting ext3
pivotroot: pivot_root(/sysroot/initrd) failed: 2
umount /initrd/proc failed: 2
Freeing unused kernel memory: 188k freed
Kernel panic: No init found. Try passing init=option to kernel

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
password --md5 $1$l0WNN0$rK69CoayY343p0GqclgL/1
title Fedora Core (2.6.6-1.376smp)
        root (hd0,0)
        kernel /vmlinuz-2.6.6-1.376smp ro root=LABEL=/ acpi=on
        initrd /initrd-2.6.6-1.376smp.img
title Fedora Core (2.6.5-1.358smp)
        root (hd0,0)
        kernel /vmlinuz-2.6.5-1.358smp ro root=LABEL=/ acpi=on
        initrd /initrd-2.6.5-1.358smp.img

root at inyoureyes root]# dumpe2fs /dev/sda7 | less

filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          d461d983-1b76-4609-9c8e-b415253c4c61
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery
sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1602496
Block count:              3204959
Reserved block count:     160247
Free blocks:              1085648
Free inodes:              1197911
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16352
Inode blocks per group:   511
Filesystem created:       Fri May 23 15:35:38 2003
Last mount time:          Sun May 23 20:34:38 2004
Last write time:          Sun May 23 20:34:38 2004
Mount count:              8
Maximum mount count:      -1
Last checked:             Tue May 11 06:15:29 2004
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      911c4afd-9a89-42ee-a92a-9b3da98c9b82
Journal backup:           inode blocks


Group 0: (Blocks 0-32767)
  Primary superblock at 0, Group descriptors at 1-1
  Block bitmap at 2 (+2), Inode bitmap at 3 (+3)
  Inode table at 4-514 (+4)
  15069 free blocks, 15295 free inodes, 343 directories

Any thought's?

Thanks,
Ted








More information about the test mailing list