I have a Dell PowerEdge 2650 (dual Xeon) which was running FC2. I upgraded to FC3 and after the first reboot it failed to start the kernel. It looks like it is having trouble reading or mounting the filesystems. The upgrade process itself went flawlessly. Also it was initially installed/built with FC2, and no non-Fedora software had ever been loaded on it.
For information this system has built-in hardware SCSI RAID. Except for the /boot partition, the whole logical disc was set up to use LVM. All filesystems within the LVM group were ext3. I've tried booting with both the SMP kernel as well as the single-processor kernel, with the same results. This is what appears during the initial boot text (I copied this off the screen manually, so there may be typos)....
++++++++BEGIN+++++++ Booting Fedora Core (2.6.9-1.667smp) root (hd0,1) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.9=1.667smp ro root=/dev/vg00/lvol00 rhgb quiet [Linux-bzImage, setup=0x1400, size=0x14d2a0] initrd /initrd-2.6.9-1.667smp.img [Linux-initrd @ 0x37ee5000, 0x10ab88 bytes]
Uncompressing Linux... Ok, booting the kernel. audit(1101329215.035:0): initialized Red Hat nash version 4.1.18 starting Reading all physical volumes. This may take a while... No volume groups found No volume groups found No volume groups found mount: error 6 mounting ext3 mount: error 2 mounting none switchroot: mount failed: 22 umount /initrd/dev failed: 2 Kernel panic - not syncing: Attempted to kill init! +++++++++END++++++++
At that point the system was locked up and only the power off/on would restart.
Deron Meranda wrote:
I have a Dell PowerEdge 2650 (dual Xeon) which was running FC2. I upgraded to FC3 and after the first reboot it failed to start the kernel. It looks like it is having trouble reading or mounting the filesystems. The upgrade process itself went flawlessly. Also it was initially installed/built with FC2, and no non-Fedora software had ever been loaded on it.
I've seen the same problem on some systems when I was playing around with LVM. The only difference my for-fun machines were initial inistall. When booted into rescue mode, I can mount root file system (from LVM volume). When booting normaly, kernel fails to find LVM volumes (and thus no root file system to mount that leads to kernel panic).
Have you got any replies on this off-list, or maybe managed to figure it out yourself?
Aleksandar Milivojevic wrote:
Deron Meranda wrote:
I have a Dell PowerEdge 2650 (dual Xeon) which was running FC2. I upgraded to FC3 and after the first reboot it failed to start the kernel. It looks like it is having trouble reading or mounting the filesystems. The upgrade process itself went flawlessly. Also it was initially installed/built with FC2, and no non-Fedora software had ever been loaded on it.
I've seen the same problem on some systems when I was playing around with LVM. The only difference my for-fun machines were initial inistall. When booted into rescue mode, I can mount root file system (from LVM volume). When booting normaly, kernel fails to find LVM volumes (and thus no root file system to mount that leads to kernel panic).
Have you got any replies on this off-list, or maybe managed to figure it out yourself?
OK, I found why it hasn't worked in my setup. It was timing issue during execution of init script from initrd image.
What happened was that device driver for my SCSI card (sym53c8xx) was rather slow in detecting disk drives. Init script would load the SCSI driver, and than go after loading raid1 and dm-* drivers, and detecting logical volumes. The sym53c8xx didn't had enough time to find and report disk drives, and the rest was chain reaction: raid1 devices were not configured (since raid1 module couldn't see any disks), and LVM couldn't find any volumes (since the mirrors were not setup).
This also explains why everything was OK when booting from rescue CD, but not when booting normally from disk. When booting from rescue CD, sym53c8xx is first loaded, and than after some user interaction, raid1 and dm-* modules are loaded. "user interaction" part gave sym53c8xx enough time to detect and report attached disks before raid1 and dm-* modules were loaded. No such luck when booting off disk.
I made rather dirty workaround (inserted "sleep 30") after "insmod 53c8xx" line in init script. This gave 53c8xx driver enough time to detect disks, and now everything works.
Now I need to remember that I'll have to rebuild initrd manually every time I update the kernel...
What SCSI controller do you have on your motherboard, and how disks are connected? It might be that part of my problem was the fact that disks were connected to second SCSI controller (first SCSI controller was faulty).
Does anybody know if "insmod" is supposed to wait until driver initializes itself (in this case, finds all devices attached to SCSI controller). Or is there race issue with using initrd images (that most people are lucky not to hit)?
On Tue, 14 Dec 2004 14:56:55 -0600, Aleksandar Milivojevic amilivojevic@pbl.ca wrote:
I've seen the same problem on some systems when I was playing around with LVM. ... Have you got any replies on this off-list, or maybe managed to figure it out yourself?
Yes, I figured it out myself. I ended up having to create my own boot initrd image manually to put things into debugging mode to figure it all out. What fun.
Anyway it turned out to be a problem with the hardware RAID on this high-end Dell server. The linux kernel driver for it changed names between FC2 and FC3; and the modprobe.conf file was not changed accordingly.
It's actually all documented very well in another thread in this mailing list. The thread title was "FC3 can't find LVM volumes, boot fails, kernel panics".