Bug 322441 - fc6-fc7 upgrade can't find valid partition table
Summary: fc6-fc7 upgrade can't find valid partition table
Status: CLOSED DUPLICATE of bug 241288
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 7
Hardware: i586
OS: Linux
low
low
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-07 19:54 UTC by Ray Todd Stevens
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-10-11 11:50:17 UTC


Attachments (Terms of Use)

Description Ray Todd Stevens 2007-10-07 19:54:46 UTC
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 22:26:40 UTC
Hi, is the exact error message what is shown in bug 236743 ?

Are partition labels present for all partitions ?
http://docs.fedoraproject.org/release-notes/f7/en_US/sn-Installer.html#id3152635

Comment 2 Ray Todd Stevens 2007-10-07 23:52:29 UTC
Right error message.  It appeasr to be a different problem

/dev/hda3: LABEL="/" UUID="63e19fe3-b294-454d-99fc-83676c961182" SEC_TYPE="ext2"
TYPE="ext3" 
/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 10:00:35 UTC
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 18:16:58 UTC
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

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.22.1-32.fc6)
        root (hd0,0)
        kernel /vmlinuz-2.6.22.1-32.fc6 ro root=LABEL=/ rhgb quiet
        initrd /initrd-2.6.22.1-32.fc6.img
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 13:01:06 UTC
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}
http://fedoraproject.org/wiki/Bugs/F7Common#head-65f561a07fdf2889f310f3aac0ab0f984faf3e9c

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:
http://people.redhat.com/clumens/f7-updates.img
with a how to use at:
http://fedoraproject.org/wiki/Anaconda/Updates

Comment 6 Ray Todd Stevens 2007-10-09 21:05:02 UTC
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 
libata.ignore_hpa=1 
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 19:15:42 UTC
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 09:48:07 UTC
(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 11:13:05 UTC
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 

http://fedoraproject.org/wiki/Bugs/F7Common#head-65f561a07fdf2889f310f3aac0ab0f984faf3e9c

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 11:50:17 UTC

*** 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.