Red Hat Bugzilla – Bug 372831
Kernel panic - not syncing: No init found.
Last modified: 2008-11-26 13:55:44 EST
Description of problem:
When attempting to boot from the f8 kernel I get the following error:
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
I have no problem booting from the f7 kernels...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try and boot my system from the Fedora 8 kernel
Note this is a system I upgraded from Fedora 7.
Created attachment 252811 [details]
For reference, this is my grub.conf file.
Created attachment 252821 [details]
For reference, my initrd for fc8.
Created attachment 252831 [details]
For reference, my initrd for fc7. This one works...
Please let me know any other information you think you would be useful. I used
mkinitrd to rebuild my initrd but as expected it had no effect. From the error
message, it looks like the kernel isn't even finding the file. My best guess is
the f8 kernel does not have sufficient drivers compiled in to read the initrd
from my sata drive.
My partition table is as follows:
Disk /dev/sda: 80.0 GB, 80000000000 bytes
255 heads, 63 sectors/track, 9726 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000080
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 104391 83 Linux
/dev/sda2 14 7513 60243750 fd Linux raid autodetect
/dev/sda3 7514 9726 17775922+ 8e Linux LVM
The following is the list of modules loaded by the fc7 kernel:
Module Size Used by
tun 17217 1
ipt_MASQUERADE 11329 1
iptable_nat 14661 1
nf_nat 25837 2 ipt_MASQUERADE,iptable_nat
bridge 59241 0
rfcomm 50537 0
l2cap 36161 9 rfcomm
bluetooth 64325 4 rfcomm,l2cap
autofs4 28361 3
sunrpc 168009 1
nf_conntrack_netbios_ns 10945 0
xt_physdev 10961 1
ipt_REJECT 12353 3
ipt_LOG 14145 1
nf_conntrack_ipv4 17225 5 iptable_nat
xt_state 10689 3
nf_conntrack 65217 6
nfnetlink 13321 3 nf_nat,nf_conntrack_ipv4,nf_conntrack
iptable_filter 11073 1
ip_tables 26153 2 iptable_nat,iptable_filter
xt_tcpudp 11713 27
ip6t_REJECT 12993 2
ip6table_filter 10817 1
ip6_tables 21129 1 ip6table_filter
x_tables 23113 10
cpufreq_ondemand 15569 4
acpi_cpufreq 16977 0
dm_multipath 24273 0
ipv6 307273 35 ip6t_REJECT
kvm_intel 28125 0
kvm 69657 1 kvm_intel
nvidia 7010708 18
snd_hda_intel 338021 4
snd_seq_dummy 11461 0
snd_seq_oss 37185 0
snd_seq_midi_event 14913 1 snd_seq_oss
snd_seq 56673 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 15061 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 47553 0
parport_pc 35049 0
snd_mixer_oss 22721 2 snd_pcm_oss
parport 42189 1 parport_pc
snd_pcm 80585 2 snd_hda_intel,snd_pcm_oss
firewire_ohci 23873 0
i2c_i801 16733 0
i5000_edac 17097 0
firewire_core 46081 1 firewire_ohci
i2c_core 28737 2 nvidia,i2c_i801
button 15713 0
snd_timer 27721 2 snd_seq,snd_pcm
edac_core 51449 3 i5000_edac
iTCO_wdt 19857 0
iTCO_vendor_support 11717 1 iTCO_wdt
snd 59753 14
tg3 110405 0
soundcore 14945 2 snd
shpchp 37853 0
serio_raw 14149 0
joydev 17601 0
crc_itu_t 10433 1 firewire_core
snd_page_alloc 16337 2 snd_hda_intel,snd_pcm
floppy 65769 0
sg 40169 0
sr_mod 23269 0
cdrom 40425 1 sr_mod
dm_snapshot 22793 0
dm_zero 10305 0
dm_mirror 26945 0
dm_mod 57521 15 dm_multipath,dm_snapshot,dm_zero,dm_mirror
ata_piix 24133 0
ahci 29893 3
libata 113905 2 ata_piix,ahci
sd_mod 33217 4
scsi_mod 145401 4 sg,sr_mod,libata,sd_mod
raid456 128353 0
async_xor 12609 1 raid456
async_memcpy 11201 1 raid456
async_tx 14773 3 raid456,async_xor,async_memcpy
xor 13649 2 raid456,async_xor
raid1 28481 1
ext3 126929 4
jbd 64689 1 ext3
mbcache 15809 1 ext3
ehci_hcd 38989 0
ohci_hcd 27845 0
uhci_hcd 30561 0
Please post contents of /etc/fstab
Created attachment 253031 [details]
Comment on attachment 253031 [details]
Contents of /etc/fstab.
Can you capture the boot messages on a serial console? The initrd contents look
almost exactly the same (they are just .cpio.gz files.)
Also boot with "vga=791" option and see if there are any other error messages.
Take a picture with a digital camera and attach that if there is any additional
Created attachment 258101 [details]
This is a video of booting the F8 kernel. Sorry, I can't find my tripod, so
this is very jittery.
Created attachment 258111 [details]
Picture of kernel panic message.
Created attachment 258131 [details]
picture of kernel panic with the vga=791 boot option.
Sorry, no serial cable. But as you can see from the screen shots, and the video
there is virtually no diagnostic information. I have a hard time believing
this is hardware related, because so many people at Red Hat are using the Dell
490, this would have been spotted sooner. However, this happens so early in the
boot sequence, I can not really see how it can be anything but a hardware
Try removing the quiet and crashkernel parameters.
Created attachment 258951 [details]
Booting without the quiet and crash options. This is much more verbose, but I
do not see anything that looks useful.
(In reply to comment #15)
> Created an attachment (id=258951) 
> Booting without the quiet and crash options. This is much more verbose, but I
> do not see anything that looks useful.
I can't play that .avi file. Can you attach a still picture from booting with
Created attachment 259851 [details]
I have isolated the cause. It seems lvm2 made my volume group scratch larger
than the physical partition. This resulted in a corruption... In theory, this
should be reassigned as an lvm2 bug, but since I have no idea how to reproduce
the problem, or even which package version originally created the problem, that
would probably not be a productive.
I guess this is more complicated than I thought. I fixed the lvm2 problem, and
the 184.108.40.206-42.fc8 kernel works. But then yum updated to the 220.127.116.11-49.fc8
version, which has the exact same kernel panic init not found problem.
I finally isolated the problem. It is definitely the initrd file. If I create
an initrd file with a fresh Fedora 8 install, the initrd file works. If I
create the same initrd file with Fedora 8 created by upgrading from Fedora 7,
the initrd does not work. I do see there are some differences between the two
initrd's. The following are the significant differences:
Binary files 18.104.22.168-42.fc8.broken/etc/ld.so.cache and
Only in 22.214.171.124-42.fc8.broken/etc/ld.so.conf.d: openais-x86_64.conf
Only in 126.96.36.199-42.fc8.works/lib64: ld-linux-x86-64.so.2
diff: 188.8.131.52-42.fc8.works/lib64/libglib-2.0.so.0: No such file or directory
Only in 184.108.40.206-42.fc8.works/lib64: libglib-2.0.so.0.1400.2
Only in 220.127.116.11-42.fc8.broken/lib64: libglib-2.0.so.0.1400.3
Binary files 18.104.22.168-42.fc8.broken/usr/lib64/libnl.so.1.0-pre5 and
Created attachment 269821 [details]
This initrd was created with a fresh Fedora 8 install, and boots normally.
The problem is the following:
Only in 22.214.171.124-42.fc8.works/lib64: ld-linux-x86-64.so.2
Ultimately this is caused, because initrd is not copying the symbolic link for
hte upgraded system, but it is copying the symbolic link for the fresh install
system. I do not understand how the symbolic link gets copied in either case...
mkinitrd used to copy the old library and that bug was fixed; now it looks like
it doesn't copy anything at all in some cases?
Created attachment 269991 [details]
Patch to fix mkinitrd script
I've tested that this patch fixes the problem by explicitly adding symbolic
links to the dependencies list.
Any chance of apply this fix to the test channel?
I'm pretty sure this was fixed before the F8 release.
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Yeah, this was fixed.