Bug 505744 - Anaconda Fails to Create Partitions, Destroys GRUB
Anaconda Fails to Create Partitions, Destroys GRUB
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-13 07:28 EDT by Daniel Qarras
Modified: 2009-11-16 09:27 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-16 09:27:18 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 Daniel Qarras 2009-06-13 07:28:36 EDT
Description of problem:
A system with Windows XP / Fedora 10 dual-boot using GRUB on /dev/sda with two hard drives, partitions as:

Disk /dev/sda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xc4a2c4a2

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        1188     9542578+   7  HPFS/NTFS
/dev/sda2            1189        9964    70493220    f  W95 Ext'd (LBA)
/dev/sda5            1189        1320     1060258+   7  HPFS/NTFS
/dev/sda6            1321        9964    69432898+   7  HPFS/NTFS

Disk /dev/sdb: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0490a8e7

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        1188     9542578+  83  Linux
/dev/sdb2            1189        9964    70493220    f  W95 Ext'd (LBA)
/dev/sdb5            1189        1320     1060258+  82  Linux swap / Solaris
/dev/sdb6            1321        9964    69432898+   7  HPFS/NTFS

Since /boot can't be on ext4 one needs to split the current /dev/sdb1 to a smaller /dev/sdb1 and create a new partition for ext4 /. Choosing "Create custom layout", creating /dev/sdb1 ext3 /boot (128MB, forcing primary partition) and /dev/sdb3 ext4 / (filling all available space, forcing primary partition). Anaconda starts to create file systems and soon reports a failure to mount /boot on /dev/sdb1, giving only option to press ok to quit. After this one finds that the boot loader created by F10 installer has been destroyed! (One could say this is a natural consequence in this case but a casual user might not agree.)

When trying again, same problem occurs. Manually checking partitioning with fdisk one sees that /dev/sdb1 does not end on cylinder boundary but otherwise partitioning seems to be ok. Since anaconda fails to create file systems every time, one needs to manually wipe out /dev/sdb1 and /dev/sdb3, recreate them (causing /dev/sdb1 to end on cylinder boundary) and then restart the installation, then anaconda finally succeeds creating the file systems.

I now have F11 installed so unfortunately I cannot retest this or provide logs but I thought this is worth reporting since destroying GRUB can be devastating for most users.

With F11 the second disk partition layout is as follows as reported by fdisk:

Disk /dev/sdb: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0490a8e7

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          17      136521   83  Linux
/dev/sdb2            1189        9964    70493220    f  W95 Ext'd (LBA)
/dev/sdb3              18        1188     9406057+  83  Linux
/dev/sdb5            1189        1320     1060258+  82  Linux swap / Solaris
/dev/sdb6            1321        9964    69432898+   7  HPFS/NTFS

Partition table entries are not in disk order
Comment 1 Björn Persson 2009-06-13 16:30:08 EDT
I had the same problem with a single disk and a much simpler partition layout. I requested a 400 MB boot partition with ext3, a 20 GB root partition with ext4, no swap partition, and to leave the rest of the disk unused. (I poked around a bit before that and changed my mind when Anaconda told me that /boot couldn't be on ext4.)

I got the same error as Daniel, that mounting the first partition as /boot failed.

I took the disk out and connected it to another computer, where fdisk reports the following:

Disk /dev/sdc: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x13c9f7c0

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1          51      409600   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdc2              51        2601    20480000   83  Linux
/dev/sdc3            2601        2601        1024   83  Linux

I don't remember requesting that third partition.

The version of Anaconda is the one in Fedora-11-i386-DVD.iso.
Comment 2 Daniel Qarras 2009-09-06 09:25:56 EDT
So, any news on this? Destroying GRUB is very bad, hopefully this is fixed soon?
Comment 3 Joel Andres Granados 2009-09-08 11:22:56 EDT
(In reply to comment #0)
> Description of problem:
> A system with Windows XP / Fedora 10 dual-boot using GRUB on /dev/sda with two
....
> When trying again, same problem occurs. Manually checking partitioning with
> fdisk one sees that /dev/sdb1 does not end on cylinder boundary but otherwise

Not ending on a cylinder boundry is no longer an issue.  This is just fdisk being legacy.  The new LBA approach to address storage blocks is much better.  Additionaly, fdisk give a warning not an error.  In this case this warning can be ignored.

> partitioning seems to be ok. Since anaconda fails to create file systems every
> time, one needs to manually wipe out /dev/sdb1 and /dev/sdb3, recreate them
> (causing /dev/sdb1 to end on cylinder boundary) and then restart the
> installation, then anaconda finally succeeds creating the file systems.
> 
> I now have F11 installed so unfortunately I cannot retest this or provide logs
> but I thought this is worth reporting since destroying GRUB can be devastating
> for most users.

This is indeed something that needs to be addressed.  With that said, can you test with rawhide?  For f11 we cannot do much of anything.  But we are moving forward with f12 installer.  This issue is probably already fixed.
Comment 4 Joel Andres Granados 2009-09-08 11:24:17 EDT
I failed to mention that withoug the log files (/tmp/*log* at installation time) we can't debug this accurately.
Comment 5 Daniel Qarras 2009-11-14 10:37:10 EST
I just finished installing F12 RC4 on the original system and all went well this time. I think it should be safe to close this report but I'll leave the final decision to you. Thanks.
Comment 6 Chris Lumens 2009-11-16 09:27:18 EST
Great, thanks for retesting.

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