Bug 9489 - fdisk partitiom listing doesn't match kernel view
fdisk partitiom listing doesn't match kernel view
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
6.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Erik Troan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-16 14:37 EST by Tomasz Kepczynski
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-06 19:04:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomasz Kepczynski 2000-02-16 14:37:38 EST
This is probably related to inclusion of sun disklabel in kernel (I haven't
checked this but it looks like it is included). Have a look at partition
table:
/dev/sda1             1       255   2048256   83  Linux
/dev/sda2   *       256       509   2040255   82  Linux swap
/dev/sda3           510      1106   4795402+   5  Extended
/dev/sda5           510       526    136521   82  Linux swap
/dev/sda6           527       532     48163+  83  Linux
/dev/sda7           533       915   3076416   83  Linux
/dev/sda8           916      1106   1534176   83  Linux
sda2 is Solaris 7 on x86. After installation (which for some reason
hasn't finished - it stalled after upgrading all packages) new kernel
refused to load saying it can't mount root. Adding 4 to all partitions
after sda5 in fstab and lilo.conf helped. But still fdisk shows the same
picture as above which is inconsistent with kernel knowledge about
partition table and current mountpoints. I have a feeling that lilo
doesn't handle this situation well as well - I had to use rescue mode
to change boot record on sda6 (picture above). sda is second disk on this
system (first one is ide on hda).
Please note that including sun disklabel may need some added code during
installation (at least for upgrade option which seems to rely on existing
fstab) and may require it to be included in kernel used during install
(which I believe is not a case).
I used smp kernel.
Comment 1 Anonymous 2000-04-24 15:55:59 EDT
This is showing up with the UnixWare support as well.  We normally install
Linux on the 4th physical partition in an extended partition that is beyond the
1023-cylinder boot limit.  Our first partition on the systems is normally a
UnixWare 7 partition.  Because UnixWare support is now compiled into the
default Red Hat 6.2 kernel, the system is now seeing hda1 <Unixware hda5 hda6
hda7 hda8 hda9 hda 10> hda2 hda3 <hda11 hda12> on boot, but during the install
process is seeing hda1 hda2 hda3 <hda5 hda6>.

A temporary fix is to boot with the Linux install floppy and change the
partition type number for the Unixware partition to a DOS-type number (using
fdisk).  When we do this, however, Unixware will Kernel Panic on bootup because
it cannnot locate it's root filesystem.

Manually changing the boot device in lilo.conf on the boot floppy to hda11 does
not solve the problem.
Comment 2 Anonymous 2000-04-24 16:11:59 EDT
(after talking with my boss):  I need  to say this about myself: I am a
contractor for Intel Corporation, not an employee, and as such, my opinions are
no reflection of the views or conerns of the Intel Corporation.
Comment 3 Cristian Gafton 2000-05-22 11:57:59 EDT
assigned to jbj
Comment 4 Erik Troan 2001-02-06 19:04:23 EST
Having 2 different sets of extended partitions isn't support by many linux
tools, and confuses many operating systems horrible. Don't do that.

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