We can't fix this, because we do not have the information to make this kind of decision.  The "System" column from your fdisk output above is not exported to anaconda by parted/pyparted because it really only means something on the msdos disk type, and that's what we'd require to make this decision.  In all other ways, your first partition look exactly like a Windows partition so anaconda believes it is one.

We should note somewhere that this problem exists, and document the procedure to fix it.

This sucks, and I'd much rather we do something about it :)

Options:

a) ask parted developers to export the necessary property, for msdos disk types. This would seem best.

b) if a system has two Windows-type partitions and we haven't a clue what's on which, notify the user and ask. I realize this is a sucky question for many users, but for those kinds of users, having Fedora provide a bootloader option which goes into a strange interface they've never seen before, from which they could easily wind up wiping all their Windows data, is even more sucky. This is a better-of-two-evils situation.

c) do some kind of detection; fr'instance, you can spot an actual Windows partition, almost all the time, by looking for a few common first-level directory names (\WINDOWS and \WINNT , fr'instance, I'm sure there's a list out there somewhere to steal). This would allow us to pick at least _a_ Windows partition correctly in the vast majority of cases.

Abusing my power to re-open the bug, just this one time.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

oh, you could also try a size-based heuristic: rescue partitions are usually small. on a reasonably modern system, the primary Windows partition is extremely unlikely to be 5GB or less in size, but recovery partitions almost always are. I'd bet that heuristic would cover the vast majority of situations, a lot better than we do now anyway. It could be refined a little for odd cases, like really old systems.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(although I note in the case above the recovery partition is 6GB. sigh. what the hell are Compaq putting in there?!)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

oh, and of course there's the rather cogent point in 537155: the real Windows partition is almost certainly the one marked 'bootable' at the start of the process. Just keep that assignment, if you have no pressing reason to override it.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

hansg, the summary is that we would like parted to provide the extended partition information available for msdos-type partitions, that is used by fdisk to identify the recovery partition (see the initial description's fdisk output). Currently parted doesn't provide this info to anaconda.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

just so it's not lost, in case it's at all useful, Mandriva guys pointed out to me that HAL has (had, I guess, now...) a heuristic for spotting recovery partitions. Just look for labels:

'RECOVERY', 'PQSERVICE', 'HP_RECOVERY', 'Recovery Partition', 'DellUtility', 'DellRestore', 'IBM_SERVICE', 'SERVICEV001', 'SERVICEV002'

(from /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi ).

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

mdv's code is in http://svn.mandriva.com/svn/soft/drakx/trunk/perl-install/fs/type.pm , look for "sub isRecovery".

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Chris,

I don't see why this was changed to be a parted bug, as explained by yourself in comment #1, exporting the raw fs type byte from parted is not something which fits well in parted's model of abstracting partition tables.

Also as already said in other comments, a good solution would be to simply select which partition has the active flag set, which is already exported by parted.

Changing component back to anaconda. Not sure who to assign this to, so I'll just leave it assigned to the team for now.

Hans - I'd much rather use the fs type bytes from parted even if they're a little weird there than to use some heuristic that just seems like asking for future problems.

(In reply to comment #11)
> Hans - I'd much rather use the fs type bytes from parted even if they're a
> little weird there than to use some heuristic that just seems like asking for
> future problems.  

Hmm, but that will only work for msdos disk labels. How about putting the knowledge which msdos System ID is a rescue type inside parted and adding a
"rescue" flag which can be queried on partitions ?

Chris, any comments on my suggestion done in comment #12 ?

Hello to you all,

My bug 539886 "preupgrade of F11 to F12 has overwritten my boot sector" seems to be a duplicate of this?

Anyway, why is it not possible for a user (like me) to influence the boot options at install or preupgrade time?

Because:

I was pretty surprised after running preupgrade that my other OS's were not bootable anymore (see my bug). I did not at least aspect that, while before the upgrade I already had a working boot to my linux OS, it still was being changed without any warning afterwards.


Regards,

Eddie.

(In reply to comment #14)
> Hello to you all,
> 
> My bug 539886 "preupgrade of F11 to F12 has overwritten my boot sector" seems
> to be a duplicate of this?
> 

No, this is a different issue, for further discussion of your issue see bug 539886.

Nominating as F13 blocker due to criterion 6:"The installer must be able to install alongside into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working"

> Hmm, but that will only work for msdos disk labels. How about putting the
> knowledge which msdos System ID is a rescue type inside parted and adding a
> "rescue" flag which can be queried on partitions ?    

That seems like a decent idea to me.  Let me know what interface you decide upon and I can make the changes to pyparted as well.

Discussed at 04/16 and 04/23 blocker meetings. Agreed to be a blocker. Current status is that we expect anaconda team to move ahead with hansg's suggestion, in time for final release. Thanks!



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #18)
> Discussed at 04/16 and 04/23 blocker meetings. Agreed to be a blocker. Current
> status is that we expect anaconda team to move ahead with hansg's suggestion,
> in time for final release. Thanks!
> 

Hi the necessary parted and pyparted changes are in place, so now we just need anaconda team member who is familiar with the code in question to make use of
the new PED_PARTITION_DIAG flag.

As there seem to be no takers, I'll take this one. Patch coming up.

This should be fixed in anaconda-13.40-1, moving to modified.

This updates.img should include the fix for the bug:

http://people.fedoraproject.org/~jwrdegoede/f13-updates.img

Can someone please test with that? (I can't; ironically, this F13 install was done over the top of the rescue partition on this system, it's the only spare space :>)

anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13

anaconda-13.40-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13

We should now be able to confirm that this bug is fixed using the images here:

http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/

if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks.

I used the updates.img from comment 22, but still have Windows pointing to (hd0,0) instead of (hd0,1).

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         196     1572864   27  Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2             196        2628    19535522    7  HPFS/NTFS
/dev/sda3           14462       14594     1060864    7  HPFS/NTFS

This might be a special case though since the active partition is sda1, no idea if that is how it was originally.  Fujitsu Lifebook S6510.  I'm going to mark sda2 as boot and re-install.

Marking /dev/sda2 as boot didn't have any effect.  Also, anaconda simply labels it as "Other"

(In reply to comment #26)
> I used the updates.img from comment 22, but still have Windows pointing to
> (hd0,0) instead of (hd0,1).
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *           1         196     1572864   27  Unknown
> Partition 1 does not end on cylinder boundary.
> /dev/sda2             196        2628    19535522    7  HPFS/NTFS
> /dev/sda3           14462       14594     1060864    7  HPFS/NTFS
> 

The issue is that sda1 has an id of 27, which as fdisk indicate is not any
known partition type id. Try changing it to "12" (compaq diagnostics), or to "de"
(dell diagnostics). My MSI laptop's recovery partition has a type of 12.

Hmm, doing some googling found me:
http://www.win.tue.nl/~aeb/partitions/partition_types-1.html

Which says that 0x27 also is used quite often for recovery partitions. One parted patch coming up.

anaconda-13.40-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Uhg, partition id 27 is the microsoft recommend id for a recovery partition, see:
http://technet.microsoft.com/en-us/library/dd744364%28WS.10%29.aspx

I definitely need to teach parted about this.

parted-2.1-8.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/parted-2.1-8.fc13

parted-2.1-8.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.