Bug 229704 - anaconda does not handle hdX -> sdX change
Summary: anaconda does not handle hdX -> sdX change
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact:
URL:
Whiteboard:
: 234834 235327 236476 (view as bug list)
Depends On:
Blocks: FC7Blocker F7Test4
TreeView+ depends on / blocked
 
Reported: 2007-02-22 20:46 UTC by Charles R. Anderson
Modified: 2007-11-30 22:11 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-04-23 16:53:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
First 64 sectors of /dev/sda (32.00 KB, application/octet-stream)
2007-02-22 20:46 UTC, Charles R. Anderson
no flags Details
anaconda.log (17.79 KB, text/plain)
2007-04-19 20:09 UTC, Charles R. Anderson
no flags Details
anaconda syslog (18.86 KB, text/plain)
2007-04-19 20:09 UTC, Charles R. Anderson
no flags Details

Description Charles R. Anderson 2007-02-22 20:46:41 UTC
Description of problem:

Upgrading a recent fresh install of FC6 to F7/development (buildstamp
200702220434.i386) fails to detect boot loader (grub) installed by FC6.

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

How reproducible:
didn't try

Steps to Reproduce:
1. boot anaconda installer
2. select upgrade of FC6 partition
3.
  
Actual results:
"The installer is unable to detect the boot loader currently in use on your system.

What would you like to do?

(greyed out: Update boot loader configuration)
Skip boot loader updating
Create new boot loader configuration

Expected results:
Anaconda should detect my existing grub in /dev/sda (which was /dev/hda on the
FC6 kernel).

Additional info:
HP OmniBook 6000, P-III 600 MHz, 384 MB RAM.

Comment 1 Charles R. Anderson 2007-02-22 20:46:41 UTC
Created attachment 148626 [details]
First 64 sectors of /dev/sda

Comment 2 Charles R. Anderson 2007-02-22 20:48:50 UTC
Output from sfdisk -x -l:

Disk /dev/sda: 4864 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sda1          0+      1-      2-     15088+  a0  IBM Thinkpad hibernation
                end: (c,h,s) expected (1,224,63) found (29,15,63)
/dev/sda2   *      1+   2432-   2432-  19527480    c  W95 FAT32 (LBA)
                start: (c,h,s) expected (1,225,1) found (30,0,1)
                end: (c,h,s) expected (1023,254,63) found (1023,15,63)
/dev/sda3       2432+   2446-     14-    105840   83  Linux
                start: (c,h,s) expected (1023,254,63) found (1023,239,63)
                end: (c,h,s) expected (1023,254,63) found (1023,239,63)
/dev/sda4       2446+   4863    2418-  19421640    5  Extended
                start: (c,h,s) expected (1023,254,63) found (1023,239,63)
                end: (c,h,s) expected (1023,254,63) found (1023,239,63)

/dev/sda5       2446+   4863    2418-  19421608+  8e  Linux LVM
                start: (c,h,s) expected (1023,254,63) found (1023,239,63)
                end: (c,h,s) expected (1023,254,63) found (1023,239,63)
    -           2446+   2446-      0          0    0  Empty
    -           2446+   2446-      0          0    0  Empty
    -           2446+   2446-      0          0    0  Empty


Comment 3 Charles R. Anderson 2007-02-22 21:28:52 UTC
Hmm looking at this partition table further, it seems that under FC6, the disk
is detected with 16 heads:

Disk /dev/hda: 77520 cylinders, 16 heads, 63 sectors/track

But under FC7, the disk is detected with 255 heads:

Disk /dev/sda: 4864 cylinders, 255 heads, 63 sectors/track

Additionally, I believe some partitions were somehow created with 16 heads, and
others with 240 heads in the partition table.  This smells like an old
anaconda/parted bug from ages ago.


Comment 4 Jeremy Katz 2007-02-26 19:55:39 UTC
... let me guess, /etc/sysconfig/grub has "boot=/dev/hda" in it.

Comment 5 Charles R. Anderson 2007-02-27 20:30:47 UTC
Yes it does.  How will upgrades handle this case?


Comment 6 Jeremy Katz 2007-02-27 20:36:37 UTC
Right now, not very well.

We definitely need to do something about this for F7, just not quite sure what yet.

Comment 7 Chris Lumens 2007-04-11 20:53:20 UTC
*** Bug 234834 has been marked as a duplicate of this bug. ***

Comment 8 Chris Lumens 2007-04-16 14:18:08 UTC
*** Bug 235327 has been marked as a duplicate of this bug. ***

Comment 9 Chris Lumens 2007-04-16 14:19:51 UTC
*** Bug 236476 has been marked as a duplicate of this bug. ***

Comment 10 Jeremy Katz 2007-04-17 23:15:05 UTC
We've committed a lot of stuff today to help handle these cases.  Testing is
still needed, though.

Comment 11 Charles R. Anderson 2007-04-19 20:07:53 UTC
I tested today's (2004-04-19 10:00) rawhide install and I still get the same
error upgrading a freshly installed, fully updated FC6:

"The installer is unable to detect the boot loader currently in use on your system."

anaconda-11.2.0.52-1

Here are my FC6 files:

/etc/sysconfig/grub:
boot=/dev/hda
forcelba=0

/etc/grub.conf:
# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,2)
#          kernel /vmlinuz-version ro root=/dev/q/root
#          initrd /initrd-version.img
#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,2)/grub/splash.xpm.gz
hiddenmenu
title Fedora Core (2.6.20-1.2944.fc6)
        root (hd0,2)
        kernel /vmlinuz-2.6.20-1.2944.fc6 ro root=/dev/q/root rhgb quiet
        initrd /initrd-2.6.20-1.2944.fc6.img
title Fedora Core (2.6.18-1.2798.fc6)
        root (hd0,2)
        kernel /vmlinuz-2.6.18-1.2798.fc6 ro root=/dev/q/root rhgb quiet
        initrd /initrd-2.6.18-1.2798.fc6.img
title Fedora Core Development Installer
        root (hd0,2)
        kernel /vmlinuz-devel graphical askmethod
        initrd /initrd-devel.img
title Other
        rootnoverify (hd0,1)
        chainloader +1


Comment 12 Charles R. Anderson 2007-04-19 20:09:00 UTC
Created attachment 153054 [details]
anaconda.log

Comment 13 Charles R. Anderson 2007-04-19 20:09:51 UTC
Created attachment 153055 [details]
anaconda syslog

Comment 14 Jeremy Katz 2007-04-19 20:17:43 UTC
The message is correct and we pretty much have to punt on doing automatic
bootloader reconfig.  While it's doable for the case of one controller, the
second you throw a second controller (or even two disks) into the picture, it
becomes impossible.  So we detect and require you to generate a new boot loader
config at which point we can get things correct.

With today's rawhide, there's one little thing that's not right which is
/boot/grub/device.map doesn't get properly recreated.  But that should be fixed
for tomorrow

Comment 15 Jeremy Katz 2007-04-23 16:53:09 UTC
Testing I've done on this is looking good.  Closing out

Comment 16 David Timms 2007-04-27 22:47:14 UTC
I am seeing this situation "cant detect your bootloader" with f7t4 pxeboot+ftp
on an LSI raid dell poweredge. Did the fixes in comment 14 make it in to test4 ?


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