Bug 483402
Summary: | bad msftres flag | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alexey Kuznetsov <axet> | ||||
Component: | parted | Assignee: | Joel Andres Granados <jgranado> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 10 | CC: | hdegoede, jgranado, the.ridikulus.rat, zenczykowski | ||||
Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-12-16 14:07:04 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Alexey Kuznetsov
2009-01-31 20:45:27 UTC
that is common problem, check google: http://www.google.com/search?q=clean+msftres also interesting (in confirm to comment 1): [root@axet-laptop axet]# parted /dev/sda GNU Parted 1.8.8 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA FUJITSU MHW2120B (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI boot, hidden 2 210MB 34.4GB 34.2GB hfs+ Leopard 3 34.6GB 96.8GB 62.2GB ext3 Fedora 4 96.9GB 120GB 23.1GB ntfs Windows 7 (parted) set 3 ms off (parted) p Model: ATA FUJITSU MHW2120B (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI boot, hidden 2 210MB 34.4GB 34.2GB hfs+ Leopard 3 34.6GB 96.8GB 62.2GB ext3 Fedora msftres 4 96.9GB 120GB 23.1GB ntfs Windows 7 (parted) set 4 ms off (parted) p Model: ATA FUJITSU MHW2120B (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI boot, hidden 2 210MB 34.4GB 34.2GB hfs+ Leopard 3 34.6GB 96.8GB 62.2GB ext3 Fedora msftres 4 96.9GB 120GB 23.1GB ntfs Windows 7 msftres (parted) problem persist in fedora 11. if no body want to understand how good it is, please just apply my patch. Created attachment 345197 [details]
parted-f11.patch
patch for f11 package (parted-1.8.8-17.fc11.i586)
You patch was not applied as you sent it but I have corrected the logic on those if statements. To test pls go to http://koji.fedoraproject.org/koji/taskinfo?taskID=1405593. This is one of the scratch builds that I have done of upstream parted and its making its way to rawhide (in a week or so). Feel free to reopen if the issue persists. Check out https://bugzilla.redhat.com/show_bug.cgi?id=510476 The "Microsoft Reserved" Partition in GPT is needed only for conversion from a basic disk to dynamic disk in Windows. Otherwise it is not at all needed and according to Microsoft, any FAT(16,32 etc..) or NTFS partition(s) should be "Basic Data Partition" if they have to be accessible in Windows and Mac (Linux allows access even to a msftres partition). Think of it like the 128 MB gap between partitions imposed by Mac OS X's Disk Utility in GPT disk for future usage which cannot be anticipated at present. Microsoft creates this partition for any future usage similar to the 128 MB gap. The above mentioned code in libparted assumes that any FAT or NTFS partition must be marked as Microsoft Reserved (the same way any HFS partition must be marked Apple_HFS), but this is not correct. This bug can be corrected by either deleting the above lines or by modifying them as follows :- if (strncmp (fs_type->name, "fat", 3) == 0 || strcmp (fs_type->name, "ntfs") == 0) { gpt_part_data->type = PARTITION_BASIC_DATA_GUID; return 1; } What is a Microsoft Reserved Partition? The Microsoft Reserved Partition reserves space on each disk drive for subsequent use by operating system software. GUID Partition Table disks do not allow hidden sectors. Software components that formerly used hidden sectors now allocate portions of the Microsoft Reserved Partition for component-specific partitions. For example, converting a basic disk to a dynamic disk causes the Microsoft Reserved Partition on that disk to be reduced in size and a newly created partition holds the dynamic disk database. Will end users see the Extensible Firmware Interface System Partition, Microsoft Reserved Partition, and OEM-specific partitions? The user won't see these partitions exposed in Windows Explorer, nor is any recognized file system exposed to legacy programs such as Context Indexing. The Extensible Firmware Interface System Partition, OEM-specific, and other unrecognized partitions will be visible only in the Disk Management MMC snap-in. What partitions are mounted by default by Windows? Windows exposes only basic data partitions. Other partitions with FAT file systems may be mounted, but not exposed (only programmatically). Only basic data partitions are assigned drive letters or mount points. The Microsoft Reserved Partition (and any partitions that are created from the Microsoft Reserved Partition) could have recognizable file systems; none are exposed. What happens when a basic disk is converted to dynamic? For a drive to be eligible for conversion to dynamic, all basic data partitions on the drive must be contiguous. If other unrecognized partitions separate basic data partitions, the disk cannot be converted. This is one of the reasons that the Microsoft Reserved Partition must be created before any basic data partitions. The first step in conversion is to separate a portion of the Microsoft Reserved Partition to create the configuration database partition. All non-bootable basic partitions are then combined into a single data container partition. Boot partitions are retained as separate data container partitions. This is analogous to conversion of primary partitions. Retrieved from http://support.microsoft.com/kb/302873 - FAQ about GPT Disk Architecture (In reply to comment #6) > Check out https://bugzilla.redhat.com/show_bug.cgi?id=510476 > So the problem in this bug and in 510476 is the same. I will dup 510476 and reopen this one, which has more information, to have just one point to handle this issue. *** Bug 510476 has been marked as a duplicate of this bug. *** (In reply to comment #7) > (In reply to comment #6) > > Check out https://bugzilla.redhat.com/show_bug.cgi?id=510476 > > > > So the problem in this bug and in 510476 is the same. I will dup 510476 and > reopen this one, which has more information, to have just one point to handle > this issue. This bug does not have anything to do with AppleTV Partitions or anything else related to Fedora appletv support patch. This bug occurs because some parted developer, at some point of time, misunderstood the real need for Microsoft Reserved Partitions in GPT and added the mentioned code in gpt.c file thinking that any FAT or NTFS partition should be by default marked as msftres, which is exactly opposite to what Microsoft claims and How Windows deals with FAT and NTFS partitions in GPT. This is just a 128 MB reserved (for future use) space for converting basic disks to dynamic discs and tasks similar to that by Windows compensating for the absence of Hidden Sectors in GPT. To Joel Andres Granados:- Since you are also one of the main parted developers, correct this problem in main Parted GIT repository so that it is solved once and for all, instead of just creating a patch for Fedora's Parted src-rpm package. Also try out this software - GPT fdisk http://rodsbooks.com/gdisk/ and http://sourceforge.net/projects/gptfdisk/ This software has some very good features like setting any arbitary partition type GUID for a GPT partition, converting a disk from MBR (or msdos disklabel) to GPT without loss of data etc. It is a full-fledged GPT editor for all non-filesystem related tasks (it does not include filesystem related functions). GNU Parted is good for things like filesystem resizing etc. But for things like manipulating the Partition type GUID, Partition Unique GUID, Disk GUID, and other GPT header and the Partition table related data (not related to the contents of the partitions - filesystems), GNU Parted fails most of the time. Although it will take a lot of time to integrate its features into GNU Parted, please include atleast the arbitary Partition type GUID option as soon as possible. It is a very important feature which, according to me, should be present even in a bare-minimum GPT related tool. This is particularly useful for people who are struck up with partitions like that of NetBSD and like Windows Recovery (WinRE) whose GUIDs parted does not contain by default. See http://en.wikipedia.org/wiki/GUID_Partition_Table for a whole list of Partition Type GUIDs. And please integrate these features into main Parted repository, not just for Fedora. Thank you. keshav: Thx for the link and explinations. I'll get to this as soon as I can. Keshav: thanks for the link to gdisk. It just saved me... I created a new partition in mac os x, and mistakenly formatted it as vfat, then dd'ed over another hfs+ formatted disk onto it. Couldn't figure out how to get it to get detected as hfs+, so I ran parted from a boot cd, and eventually ended up with msftres flag set and couldn't get rid of it. Eventually used gdisk to manually set the GUID to mac/hfs+. Problem solved. (oh, and the problem is present in F11 as well, since I used an F11 install dvd) Why is this bug not yet corrected? The exact cause of the problem has already been shown. Also why there is no activity in Parted's GIT repository for a long time? Please read the parted bug list (apart from the mailing list) mentioned in Parted website. There are lots of bug reports in that but there is not even a single reply from a parted developer to any of them. (In reply to comment #15) > Also why there is no activity in Parted's GIT repository for a long time? The Git repo for parted is moving along as expected, there is stuff going into next and master is being left alone for now. Can you be more specific? > Please read the parted bug list (apart from the mailing list) mentioned in > Parted website. There are lots of bug reports in that but there is not even a > single reply from a parted developer to any of them. Are you referring to parted-bug list? There were some 10 bugs that were outstanding from previous months. I tried to address them all and 1.9.0 came out with a lot of fixes from that list. Can you also be more specific? Which bugs are you referring to? (In reply to comment #14) > Why is this bug not yet corrected? The exact cause of the problem has already > been shown. Doing lots of things at the same time. If you have a patch, I would really appreciate it!!! I am referring to these bugs and other bugs in these pages http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/186 http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/215 This bug has been corrected in GNU Parted GIT repository http://git.debian.org/?p=parted/parted.git (as on 25th September 2009). This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This bug has been corrected in Parted v2.0 Beta. I am unable to change the Fedora version number to 12 or rawhide. I suppose this bug report should be open untill fedora repository bring out Parted v2.0 rpm package. I request someone to change the Fedora version number to 12 or rawhide here. Thank you. This bug is also fixed in parted-1.9.0, which we have been shipping for a while, closing. |