Bug 140382

Summary: Installer fails to find root partition to upgrade
Product: [Fedora] Fedora Reporter: Andrew Gilmore <agilmore>
Component: partedAssignee: Chris Lumens <clumens>
Status: CLOSED NOTABUG QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 3CC: clausen, herrold, pnasrat
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-02-09 22:00:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
anaconda log file
anaconda log through installtype
syslog from machine none

Description Andrew Gilmore 2004-11-22 18:36:52 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
FC3 Final release, graphical install loads, 
attempts to find partitions to upgrade fails
Further attempt to do a custom install fails during disk partitioning
due to corrupt partition table on hda (?)

during install, can switch to VC2, and do fdisk /dev/hda
and sfdisk -l /dev/hda and no problems are reported.

Rescue mode also fails to find any Linux partitions.

Machine is running Fedora Core 2 with no problems.
Thinkpad R40 with 80gb drive, 3 GB host protected area
CHS = 10000,240,63 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.boot from install cd
2.walk through install to point after keyboard language selection
3.fails to find upgradeable partitions

Actual Results:  asked what type of install to do, no upgrade offered

Expected Results:  offered upgrade option

Additional info:

sfdisk -l output:

Disk /dev/hda: 150008 cylinders, 16 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/240/63 (instead of 150008/16/63).
For this listing I'll assume that geometry.
Units = cylinders of 7741440 bytes, blocks of 1024 bytes, counting from 0
   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/hda1   *      0+   1380    1381-  10440328+   c  W95 FAT32 (LBA)
/dev/hda2       1381   10336    8956   67707360    f  W95 Ext'd (LBA)
/dev/hda3          0       -       0          0    0  Empty
/dev/hda4          0       -       0          0    0  Empty
/dev/hda5       1381+   1387       7-     52888+  83  Linux
/dev/hda6       1388+   8863    7476-  56518528+  83  Linux
/dev/hda7       8864+   9899    1036-   7832128+   b  W95 FAT32
/dev/hda8       9900+   9999     100-    755968+  82  Linux swap

Comment 1 Andrew Gilmore 2004-11-22 19:51:07 UTC
doing the geometry shuffle like FC2 issues:

sfdisk -d /dev/hda |sfdisk --no-reread -H240 /dev/hda

had no affect.

Comment 2 Jeremy Katz 2004-11-22 19:52:24 UTC
If you boot with 'linux upgradeany' does it work?

Comment 3 Andrew Gilmore 2004-11-22 20:09:18 UTC
No. Tried it twice. Also tried askmethod and specifying
rootpath=/dev/hda6 on the kernel command line, no joy.

Comment 4 Andrew Gilmore 2004-11-22 20:35:26 UTC

Comment 5 Jeremy Katz 2004-11-22 21:34:26 UTC
Can you get to the point where you get asked what type of install you
want, switch to tty2 and grab /tmp/anaconda.log and /tmp/syslog and
attach them here?

Comment 6 Andrew Gilmore 2004-11-22 21:49:47 UTC
Created attachment 107247 [details]
anaconda log file

Comment 7 Andrew Gilmore 2004-11-22 21:52:01 UTC
Created attachment 107248 [details]
anaconda log through installtype

(previous was to welcome)

Comment 8 Andrew Gilmore 2004-11-22 21:52:56 UTC
Created attachment 107249 [details]
syslog from machine

Comment 9 Jeremy Katz 2004-11-23 13:44:21 UTC
For some reason, it looks like we're not finding the fs on hda6 -- if
you go to the partitioning screen and just see what it currently looks
like, what filesystem does it say is currently in use?  Can you mount
/dev/hda6 from tty2?

Comment 10 Andrew Gilmore 2004-11-23 15:10:56 UTC

I enabled debug mode on the boot command line, set a decent breakpoint
and watched the process. The failure occurred in partedUtils.py,
function openDevices at the section
                disk = parted.PedDisk.new(dev)

This fails with an exception that gets printed when in debug mode, but
never saw it in the logs:

"Error: Can't have a partition outside the disk!"

Further, sfdisk and fdisk work just fine, but if I run parted on the
disk, I get the same error when I try to print the partition table.

Then, looking at the partition table (in the bug report), note the
extended partition, which has an ending cylinder of 10336 which is the
end of the REAL drive, but is way outside the allowed area at 9999. 

After fixing the extended partition to end at 9999, the upgrade was
offered. So, although there was no primary or logical partitions in
the Host Protected Area, since the extended partition included that
area, parted fails.

(Yes, /dev/hda6 mounts just fine, and when the partition type screen
comes up, and next is selected, the corrupted partition table warning
comes up from the same code (openDevices) and the partition table is
wiped if it is selected to continue.)

Sorry to have wasted your time. Not sure if a bit better error
handling would help much, since this really was a partition table problem.

Comment 11 Jeremy Katz 2004-11-23 15:20:15 UTC
Can you try using http://people.redhat.com/~katzj/fc3-part-upd.img as
an update disk as described at
http://rhlinux.redhat.com/anaconda/updatedisks.html and see if that helps?

Comment 12 Andrew Gilmore 2004-11-23 16:06:59 UTC
I'd like to, but...

this is a laptop with no floppy drive.

Suggestions? I halfheartedly googled with no solution found.

Comment 13 Andrew Gilmore 2004-11-23 16:10:23 UTC
Not sure why bugzilla says I keep assigning this. I double checked and
the leave as needinfo radio button was selected.

Sorry about that, I'm not saying you need to take this, it was a
partition table problem.

Comment 14 Andrew Gilmore 2005-02-09 22:00:47 UTC
I'm not sure this is a parted issue, since command line parted gives a somewhat
reasonable error, see comment #10.

It's just that anaconda doesn't give as much detail about why it thinks that the
partition table is corrupt as perhaps I would have liked.

Again, the problem occurred because /dev/hda2 in the partition table extended
beyond the end of the reported drive. System boots fine, but parted was right in
complaining about it.

I consider this bug a PEBKAC, and will close it. Sorry about the spammage.