Bug 238509 - Kernel panic
Kernel panic
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Peter Jones
David Lawrence
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-30 18:52 EDT by M. A. MacLain
Modified: 2008-04-04 09:20 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 09:20:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description M. A. MacLain 2007-04-30 18:52:17 EDT
Description of problem: Test 4 goes int panic at boot


Version-Release number of selected component (if applicable):
Fedora 7 Test 4

How reproducible:
Consistent

Steps to Reproduce:
1.Install test 4
2. Reboot
3.
  
Actual results:
Kernel Panic

Expected results:
Completion of the first boot after installation

Additional info:Test 4 (6.93) Goes into a kernel panic at boot. Last screen
displays:

SCSI device sdd: 312581808 572-byte hdwr sectors (1600042 MB)
sdd: Write protection is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: write cache enabled, read cache: enabled, doesn't't support DPO
or FUA
SCSI device sdd: 312581808 572-byte hdwr sectors (1600042 MB)
sdd: Write protection is off
sdd: Mode Sense: 00 3a 00 00
SCSI device sdd: write cache enabled, read cache: enabled, doesn't't support DPO
or FUA
sdd: Unknown partition table
sd: 3:0:0:0: Attached partition table
device-mapper:Setuproot: moving /dev failed: No such file or directory ioctl:
4.11.0-ioctl (2006-10-12) initialized; dm-devel@redhat.com
device-mapper: table: device 8:16 too small for target
device-mapper: table: 253:0: striped: Couldn't parse stripe destination
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl failed: no such device or address
Unable to access resume device (LABLE = swap-sdd2)
Mount: could not find filesystem '/dev/root'
Setuproot: moving /dev failed: No such file or directory
Setuproot: error mounting /proc: No such file or directory
Setuproot: error mounting /sys: No such file or directory
Kernel panic - no syncing: Attempted to kill init!


This box consists of an Asus P4C800 mobo; Intel P4 running at 3.4 GHz; 2 Gbytes
ram; 4 hard drives, two of which are in a Promise Raid arrangement, details later.

The first ide drive (250 GBytes) is configured in a multi-boot with 9
partitions, Windows 2K Pro, Windows XP Pro, Fedora Core 6, Ubuntu, Fedora 7
Test4, 2 vfat and one ext3 partitions for data.  A 10 GByte drive installed  the
second ide slave position serves as a dedicated Swap with separate 4 GBytes
partitions each for Linux and Windows. 
The Promise raid uses two 160 GBytes drives with 4 partitions, 3 ntfs and one vfat.

All Test 4 installations were very smooth, with no problems at all. All installs
were fresh installs in a dedicated partition (sdc9). The swap partition was
assigned to sdd2, the swap dedicated disk. In every install instance, the
partitions sdc9 and sdd2 were formated.

I believe that the Kernel panic is the result of erroneiusly identifying the
hard drives.

The partitioning program reports the hard drives and their partitions
(correctly) as follows:
mapper/pdc_dcihgbhidb 305251 MB Linux device-mapper
sdc	238473  MB  ATA  Samsung  SP2514N
sdd	  9539  MB  ATA  ST310211A

Hard Drives
   dev/mapper/pdc_dcihgbhidb
     dev/mapper/pdc_dcihgbhidb/pdc-1	ntfs		 76560	    1	 9760
     dev/mapper/pdc_dcihgbhidb/pdc-2  Extended		228691	 9761	38914
     dev/mapper/pdc_dcihgbhidb/pdc-5	ntfs		 76498	 9761	19511
     dev/mapper/pdc_dcihgbhidb/pdc-6	ntfs		 78411	19511	29507
     dev/mapper/pdc_dcihgbhidb/pdc-7	vfat		 73791	29507	38914

   /dev/sdc
	/dev/sdc1	ntfs		 18348		    1		2339	
	/dev/sdc2	vfat		 21650		 2340		5099
	/dev/sdc3	ntfs		 14998		 5100		7011
   
   /dev/sdc4	    extended		183477		 7012	        30401
	/dev/sdc5	vfat		 25000		 7012		10198
	/dev/sdc6	ext3		 28616		10199		13846
	/dev/sdc7	ext3		 14316		13847		15671
	/dev/sdc8	ext3		 14316		15672		17496
	/dev/sdc9	ext3		 14339		17497		19324
	Free	    Free Space		 85891		19325		30401

   /dev/sdd
	/dev/sdd1	ntfs		  4997		     1		  637
	/dev/sdd2	swap		  4103		   638		 1160
	/dev/sdd3	ext3		   439		  1161		 1216


 However, the last boot screen shows what seems to be an error:
"SCSI device sdd: 312581808 572-byte hdwr sectors (1600042 MB)"
/dev/sdd is only 10000 MB not 1600042 MB .  The entry "Unable to access resume
device (LABEL = swap-sdd2)" seems to indicate that one of the Promise Raid
drives (1600000 MB) is miss identified as /dev/sdd.

Regards,
M. A. MacLain
Comment 1 Dave Jones 2007-05-15 13:51:20 EDT
What was /dev/sdd in FC6 may have moved in F7, due to the PATA drivers now using
libata, and moving from /dev/hd* to /dev/sd* also.

I think mkinitrd might be just getting confused by the presence of other
distributions being installed.
Comment 2 M. A. MacLain 2007-05-16 19:18:48 EDT
Dave, I am away until June 9th.  You may like to know that I have F7
successfully running in a different box which is multi-booting 2 FC6s, Ubunto,
W2K and of course F7.

Regards,
M. A. MacLain
Comment 3 M. A. MacLain 2007-05-19 09:48:02 EDT
Dave, the box running F7 with no problems does not have a raid. I am incline to
believe that the problem is due to the raid detection at boot.  However, the
raid was properly detected during the installation.
Comment 4 M. A. MacLain 2007-06-09 21:31:25 EDT
Well I tried a new install this time with the just released Fedora 7.  The
install went without a glitch through the post install, but at the reboot Kernel
Panic again.  The contents of the last screen follows:


   Booting 'Fedora (2.6.21-1.3194.fc7)
root (hd0,8)
File system is ext2, partition type 0x83
kernel /boot/vmlinuz ro root=LABEL=/1 rhgb quiet
 [Linux-bz Image, setup=0x1e00, Size=0x1c9dd4]
initrd/boot/initrd-2.6.21-1.3194.fc7.img
 [Linux-initrd @ 0x37d24000, 0x2cb254 bytes]
Uncompressing Linux... OK, booting the kernel
Red Hat Version 6.0.9 starting
device-mapper: table: 253:0: striped: Couldn't parse stripe destination
device-mapper: reload ioctl failed: no such device or address
Unable to access resume device (LABEL=SWAP-sdd2)
mount: could not find file system '/dev/root/'
Setuproot: moving /dev failed: No such file or directory
Setuproot: error mounting /proc: No such file or directory
Setuproot: error mounting /sys: No such file or directory
Switch root:mount failed: No such file or directory
Kernel panic - not syncing: Attempted to kill init!


The installation showed the drives as follows:
Mapper/pdc_deihgbhidb 305251 MB Linux Device-mapper
sdc                   288473 MB ATA Samsung SP2514N
sdd                     9539 MB ATA         ST310211A


All other 4 OSs do execute perfectly

Thanks,
Manny

PS. To amlau@alum.mit.edu, Hi from a course VI class of '54 alumnus.


Comment 5 M. A. MacLain 2007-06-16 10:29:16 EDT
I had a little time to experiment with the Asus P4-800e box. I disconnected the
raid drives and re-started F-7. No good still kernel panic. Next I re-installed
F-7 fresh. This time F-7 booted with no problem. Then I reconnected the raid
drives, F-7 booted with no problem however the raid is not recognized properly.
It looks that the problem is related to the Promise® PDC20378 chip-set not being
adequately supported by F-7.
Would consider linking this bug to any other Promise® PDC20378 bug
Comment 6 Bug Zapper 2008-04-03 20:24:55 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 7 M. A. MacLain 2008-04-04 09:17:01 EDT
This bug is of no further value as far as I am concerned.  It is not
reproducible in a maintained Fedora version (7, 8, or
rawhide).

Thanks,
M. A. MacLain
Comment 8 M. A. MacLain 2008-04-04 09:20:30 EDT
This bug is of no further consequence. I could not reproduce it in a maintained
Fedora version (7, 8, or rawhide)

Note You need to log in before you can comment on or make changes to this bug.