Bug 322441 - fc6-fc7 upgrade can't find valid partition table
fc6-fc7 upgrade can't find valid partition table
Status: CLOSED DUPLICATE of bug 241288
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i586 Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-07 15:54 EDT by Ray Todd Stevens
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-11 07:50:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ray Todd Stevens 2007-10-07 15:54:46 EDT
No this is not the same server as the otehr bug a reported.   Two separate problems.

I am attempting to upgrade a fc6 server to an fc7 server.   The server is
presently running a single IDE drive.   It is directly partitioned for linux
without using lvm.

When I try and upgrade it, (accross the network, httpd) the system tells me that
sda does not contain a valid partition table and asks me if I want to initialize
it.   However if I fc7 boot to rescue mode and look at the sda partition table I
see the correct data.
Comment 1 David Timms 2007-10-07 18:26:40 EDT
Hi, is the exact error message what is shown in bug 236743 ?

Are partition labels present for all partitions ?
Comment 2 Ray Todd Stevens 2007-10-07 19:52:29 EDT
Right error message.  It appeasr to be a different problem

/dev/hda3: LABEL="/" UUID="63e19fe3-b294-454d-99fc-83676c961182" SEC_TYPE="ext2"
/dev/hda1: LABEL="/boot" UUID="cb871120-68ab-4e2e-a667-e55384f61672"
SEC_TYPE="ext2" TYPE="ext3" 
/dev/hda2: LABEL="SWAP-hda2" TYPE="swap" 

fdisk gives

Disk /dev/hda: 20.0 GB, 20020396032 bytes
255 heads, 63 sectors/track, 2434 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1          13      104391   83  Linux
/dev/hda2              14         395     3068415   82  Linux swap / Solaris
/dev/hda3             396        2434    16378267+  83  Linux
Comment 3 David Timms 2007-10-08 06:00:35 EDT
Does the existing system mount these filesystems via these labels; what is the
contents of /etc/fstab and /boot/grub/grub.conf ?

Comment 4 Ray Todd Stevens 2007-10-08 14:16:58 EDT
This is the way they should be mounted.   Everything  is working under fc6 fine.

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
sysfs                   /sys                    sysfs   defaults        0 0
LABEL=SWAP-hda2         swap                    swap    defaults        0 0

title Fedora Core (
        root (hd0,0)
        kernel /vmlinuz- ro root=LABEL=/ rhgb quiet
        initrd /initrd-
title Fedora Core (2.6.20-1.2962.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.20-1.2962.fc6 ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.20-1.2962.fc6.img

Comment 5 David Timms 2007-10-09 09:01:06 EDT
Agreed. The FC6 grub/fstab look fine.

There was another common problem: the new libata driver began enforcing the host
protected area of hard disks, and hence crying foul if the existing partitions
on the disk extended into the protected area. See: {HPA}

Does passing that param to the installer get past the error ?

If not, there was an installer updates.img generated but not released {from what
I can see}, but I do not know if this has a workaround. This is available from:
with a how to use at:
Comment 6 Ray Todd Stevens 2007-10-09 17:05:02 EDT
The first option fixed the problem.  However it took a bit to figure out how to
make this work from the information in this note.

The instrucitons were to add 
to boot:linux

No can do as this doesn't come up from the cdrom install.  (rescue disk)

instead you highlight the first option
press tab to get to edit mode 
add the "libata.ignore_hpa=1 " at the end of the line and hit return.  

Now everything is hunky dorry so far.   The upgrade is running like a champ.  
Hopefully it will now boot when it is done.   (another problem I have that has
yet to be fixed. :-(  )
Comment 7 Ray Todd Stevens 2007-10-10 15:15:42 EDT
The upgrade worked fine, but now I do get a buffer io error a bunch of times
then it boots.   Everything appears to be working though.
Comment 8 David Timms 2007-10-11 05:48:07 EDT
(In reply to comment #7)
> The upgrade worked fine
Great, would you like to mark this bug as closed dupe of bug 241288 .

> but now I do get a buffer io error a bunch of times
> then it boots.   Everything appears to be working though.
Would you like to search for the exact error message you are seeing, and if not
found file another bug for that issue ?
Comment 9 Ray Todd Stevens 2007-10-11 07:13:05 EDT
I would think that closing it would be a great idea, --- but I was wondering if
we could tie these back and forth or something.   As I noted above the
instructions in 


Don't work as specified with a cdrom boot.   I have the right instructions here
for that version.  Would it be possible to fix this report to include the cdrom
boot instructions and then close this one?
Comment 10 Jeremy Katz 2007-10-11 07:50:17 EDT

*** This bug has been marked as a duplicate of 241288 ***

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