GPT vs MSDOS
FedoraForum.org - Fedora Support Forums and Community
Results 1 to 15 of 15
  1. #1
    Join Date
    Dec 2011
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    GPT vs MSDOS

    Hello guys,

    Don't blame me very much as I am a newbie to Linux. Here is my first experience trying to install and configure dual boot system on my laptop - F16 and Win 7. It wasn't so easy for me as I expected it to be at least it didn't bring me much pain in the past.

    Ok. Here is the problem scenario:

    1. First I tried to install F16 and then install Win 7. Yes, yes, I know that it's not recommended and it's gonna be painful a little bit but I don't look for easy ways. Ok, newly bought laptop (Toshiba Satellite C660-270), installed F16 32-bit, everything is ok. First experience in gnome shell 3...epic fail, by the way. Switched to KDE...full of bugs, by the way.

    2. Then I tried to install Win 7 and oops..it cannot be installed on the left free space as F16 created GPT instead of MSDOS which Win understands. So obviously I was not able to install Win 7 and I was reluctant to remove all existent linux partitions via Win installer and install Win 7. Tried to boot in Win 7 - Ok.

    3. Obviously my next step was to try to install F16 on the rest of the hard drive. I created USB with F16 Desktop and plug it in my laptop. Booted and oops, it was not able to detect existent win msdos partitions. What a hell...it's supposed to recognize the existent partitions, at least it worked fine recently and as per F16 documentation which says that F16 doesn't use GPT if it detects existent msdos table. Anyway something was going wrong. The only option is to format the whole hard drive and it means to eliminate Win 7. It's not an option to me.

    4. Booted from F16 Live CD to figure out the problem. First tried fdisk -lu and it provided me with good existent msdos partitions. No ideas so far. Also it said that fdisk detected GPT signature and it drove me crazy as Win was supposed to remove it when it formatted the disk for Win 7. Obviously it did not.

    5. I tried GNU parted and it said that it detected GPT but it's corrupted or something as GPT does not contain a fake msdos entry. Sorry I was too lazy to collect output. Sure after that I did parted /dev/sda, mktable msdos and it removed GPT and installed msdos table on my sda. Then I installed Win 7 and F16 successfully. F16 was now able to recognize the existent msdos layout.


    So, in few words, when you try to install F16, then Win 7, you get "corrupted" partition table which is msdos in nature but still contains GPT signature and it makes F16 unable to recognize msdos partitions. And you cannot overcome this problem other than remove GPT manually via live cd. It's not good.

    I think there is a good room for enhancement in F16 to be able to recognize such situation and provide end users with suggested steps to fix it. At least GNU parted can do that. Probably it would be good idea to enhance anaconda to do that stuff. Most likely it should remove GPT signature (ask user) and then follow msdos way.


    What do you think?


    Cheers,
    Evgeniy
    NN, Russia

  2. #2
    Join Date
    Nov 2007
    Location
    Berkeley, California
    Posts
    690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    The whole process of installing Fedora to dual boot with Windows has been clearly described in many places. There is no need to reinvent the wheel. Just carefully read instructions and follow them.

  3. #3
    Join Date
    Sep 2009
    Location
    Salento - Italy
    Age
    39
    Posts
    520
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    1. First I tried to install F16 and then install Win 7. Yes, yes, I know that it's not recommended and it's gonna be painful a little bit but I don't look for easy ways. Ok, newly bought laptop (Toshiba Satellite C660-270), installed F16 32-bit, everything is ok. First experience in gnome shell 3...epic fail, by the way. Switched to KDE...full of bugs, by the way.
    Bugs ?
    Which one so serious ?

    2. Then I tried to install Win 7 and oops..it cannot be installed on the left free space as F16 created GPT instead of MSDOS which Win understands. So obviously I was not able to install Win 7 and I was reluctant to remove all existent linux partitions via Win installer and install Win 7. Tried to boot in Win 7 - Ok.
    During Fedora default installation, Anaconda warns explicitly that will be written a GPT partition table


    Then if you do not know that Windows cannot boot from a GPT disk unless the computer uses Unified Extensible Firmware Interface (UEFI) firmware, you cannot attribuite responsibility to Anaconda installer.

    3. Obviously my next step was to try to install F16 on the rest of the hard drive. I created USB with F16 Desktop and plug it in my laptop. Booted and oops, it was not able to detect existent win msdos partitions. What a hell...it's supposed to recognize the existent partitions, at least it worked fine recently and as per F16 documentation which says that F16 doesn't use GPT if it detects existent msdos table. Anyway something was going wrong. The only option is to format the whole hard drive and it means to eliminate Win 7. It's not an option to me.
    After Windows 7 reinstallation, you must leave of the space not allocated wherein you could create Fedora partitions manually (including Bios boot partiton).
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	Screenshot - 12072011 - 01:36:51 PM.png 
Views:	3485 
Size:	79.0 KB 
ID:	22274  
    Last edited by Sagitter; 7th December 2011 at 02:56 PM.
    Homepage: http://www.fedoraos.wordpress.com
    Wiki page: https://fedoraproject.org/wiki/User:Sagitter

  4. #4
    Join Date
    Dec 2011
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Guys,

    Looks like there is misunderstanding 'cause of my English

    The problem is solved, I managed to dual install win 7 and F16. And now I am aware that GPT is and that if I want to install Win 7 in future I must run anaconda with nogpt key.
    The real problem is that if you 1) install F16 with GPT 2) install Win 7 on the same hard drive, it leads to corruption and you have GPT signature and a really used msdos partitioning table. Later in that case when you would like to install F16 along with Win 7 (sure you must leave free space as it is mentioned in the post above) you fall in troubles as F16 installer CANNOT recognize such situation and cannot read msdos partition table and hence it cannot install F16 along with Win 7. You MUST do tricks like parted>mktable>type msdos to overcome this barrier.
    I think (it is not a question, it's rather a request to community and F16 developers) it would be great to add a code to F16 installer which can recognize such kind of corruption and offer the end users options to fix it. I do not think it's big deal for F16 developers as GNU parted can already do that stuff. It's supposed to save hours of "googling" for unexpieneced users like me who try to configure dual boot.

  5. #5
    Join Date
    Jul 2011
    Location
    Birmingham, UK
    Age
    37
    Posts
    2,761
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by torNN
    I think (it is not a question, it's rather a request to community and F16 developers) it would be great to add a code to F16 installer which can recognize such kind of corruption and offer the end users options to fix it. I do not think it's big deal for F16 developers as GNU parted can already do that stuff.
    It may be nice if the installer could spot that situation, but it is not the fault of Fedora that it occurs.

    The first Fedora install created the GPT and protective MBR partitions, as it's supposed to in that situation.

    Windows 7 then over-wrote the MBR with it's DOS partition table, but left at least one of the GPT records alone because it was unaware of it and/or it was outside of the Windows partition (fair enough, not Windows fault either).

    Unfortunately, GPT-aware systems look at the GPT in preference of the MBR table (which is there even with GPT to prevent other potential issues). So the second attempt to install Linux saw whatever remained of the GPT and trusted it over the MBR, as again it is supposed to.

    Fixing inconsistencies like this is the domain of partition editing software, and whilst it would be nice for installers to spot this too, and ask which table to trust, it's merely a missing feature rather than a bug I'm afraid.

    Gareth

  6. #6
    Join Date
    Dec 2011
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by Gareth Jones
    it's merely a missing feature rather than a bug I'm afraid.
    Agreed. That's why I raised this topic as I haven't found a solid answer how to fix this situation and I BELIEVE that many users fall in such troubles like I did

  7. #7
    Join Date
    Dec 2008
    Location
    Vancouver, BC
    Posts
    4,328
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    torNN: it might be nice to be able to fix such cases, but it's also kind of a rabbit hole - there's so many ways you can wind up with some kind of problematic partition table. Or...anything else.

    But sure, you could file a bug against anaconda requesting that it try and fix cases like this. They'd certainly want at least an example of such a messed up disk label to work with, though. So you might have to recreate the problem and then take a copy.
    Adam Williamson | awilliam AT redhat DOT com
    Fedora QA Community Monkey
    IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
    http://www.happyassassin.net

  8. #8
    Join Date
    May 2010
    Posts
    1,058
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by torNN
    The real problem is that if you 1) install F16 with GPT 2) install Win 7 on the same hard drive, it leads to corruption and you have GPT signature and a really used msdos partitioning table.
    If you started with F16 as you stated, and do not use kernel parameter 'nogpt' then you install Windows 7 (BIOS) it is the Windows 7 installer that "corrupts" - although actually it is a case of it simply ignoring GPT. What is a little bizarre about this sequence that I don't understand here is that the resulting full disk F16 installation does have an MBR called a protective MBR which should have prevented Windows 7 installer from willy nilly claiming any space.

    If free space was left when Fedora's installer was run, still the resulting MBR and GPT should have had parity at that point. Free space shouldn't be in the protective MBR. So we'd need to see MBR and GPT output immediately after F16 installation leaving free space behind to see if this is a bug or not.



    Later in that case when you would like to install F16 along with Win 7 (sure you must leave free space as it is mentioned in the post above) you fall in troubles as F16 installer CANNOT recognize such situation and cannot read msdos partition table and hence it cannot install F16 along with Win 7.
    If Windows 7 is installed first, and you tell the Fedora installer to shrink that installation first to make room for Fedora, it will recognize MBR and will only use MBR and will not use GPT and you will end up with a functioning dual boot.

    You MUST do tricks like parted>mktable>type msdos to overcome this barrier.
    I think (it is not a question, it's rather a request to community and F16 developers) it would be great to add a code to F16 installer which can recognize such kind of corruption and offer the end users options to fix it.
    If in fact there is partition corruption, I would want the installer to inform me of it and bail out, not fix it. This should be dealt with special tools designed for fixing damaged partition tables and giving a clear review of the intended fix before applying it rather than merely autofixing it.

    I do not think it's big deal for F16 developers as GNU parted can already do that stuff. It's supposed to save hours of "googling" for unexpieneced users like me who try to configure dual boot.
    Well I think you hit the nail on the head originally when you essentially proposed it was a mistake to install F16 first and Windows afterward as Windows does not necessarily play nice to foreign operating systems installed before it. Especially if it's a preexisting GPT based installation.

  9. #9
    Join Date
    Jan 2011
    Location
    Woonsocket, RI
    Posts
    521
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by torNN
    The real problem is that if you 1) install F16 with GPT 2) install Win 7 on the same hard drive, it leads to corruption and you have GPT signature and a really used msdos partitioning table.
    An MBR partition table occupies one sector (sector 0, the MBR), plus optionally additional sectors scattered about if you use logical partitions. A GPT, OTOH, occupies several dozen sectors -- normally the first 34 and last 33 on the disk.

    When you ran the Windows installer from BIOS on a disk with GPT, the Windows installer ignored the GPT data and wrote a fresh MBR to sector 0. According to the GPT specification, this makes the disk a legal MBR disk. Although there's GPT data left over, it should be ignored. Unfortunately, as you discovered, some partitioning tools don't ignore it.

    You MUST do tricks like parted>mktable>type msdos to overcome this barrier.
    For future reference, a better solution in this specific case is to wipe the old GPT data without touching the MBR data. My FixParts program can do this. Perhaps some others can, too. (If nothing else, you could use dd, but you'd need to wipe both the second sector on the disk and the last sector on the disk to be 100% safe.)

    Quote Originally Posted by Gareth Jones
    Unfortunately, GPT-aware systems look at the GPT in preference of the MBR table (which is there even with GPT to prevent other potential issues). So the second attempt to install Linux saw whatever remained of the GPT and trusted it over the MBR, as again it is supposed to.
    Actually, if you check the GPT specification (part of the EFI/UEFI specification, available here), you'll see that a disk with a non-protective MBR and leftover GPT data is a valid MBR disk, not a GPT disk. Unfortunately, Anaconda relies on libparted, which handles this situation very badly. That's a bug in libparted. You can also argue, and I would agree, that the Windows installer should wipe the old GPT data when creating a fresh MBR table, but at least it's not doing anything that older partitioning tools don't do. That's presumably why the GPT spec says that this type of configuration should be treated as an MBR disk; it's entirely plausible that a GPT disk will be repartitioned using some GPT-unaware utility, in which case GPT-aware tools should recognize it as an MBR (or other non-GPT) disk.

    Quote Originally Posted by Gareth Jones
    Fixing inconsistencies like this is the domain of partition editing software, and whilst it would be nice for installers to spot this too, and ask which table to trust, it's merely a missing feature rather than a bug I'm afraid.
    I disagree, at least if you're saying the behavior overall is a "missing feature." It is a bug -- the installer claimed that a valid MBR disk was empty. This bug happens to lie in libparted, so it's not part of the main Anaconda code, but as Anaconda uses libparted, that means that Anaconda is heir to libparted's bugs.

    Quote Originally Posted by AdamW
    But sure, you could file a bug against anaconda requesting that it try and fix cases like this. They'd certainly want at least an example of such a messed up disk label to work with, though. So you might have to recreate the problem and then take a copy.
    To reproduce the problem, you'd need not just the MBR, but also the GPT data -- at least the first two sectors of the disk, and maybe more, perhaps including the backup GPT data at the end. (I'm not sure exactly what's required to trigger the bug.)

    An easier way is to re-create the problem. This can be done quite reliably:

    1. Put GPT partitions on a disk. (Use GNU Parted, GParted, gdisk, or any other GPT-aware tool.)
    2. Launch Linux fdisk (from util-linux or util-linux-ng, not GNU fdisk) on the disk.
    3. Using fdisk, delete the 0xEE "protective" partition from the disk.
    4. Using fdisk, create one or more new MBR partitions on the disk. (Actually, you can probably omit this step.)
    5. Type "w" in fdisk to save your changes.


    Tools based on libparted (GNU Parted, GParted, Palimpsest Disk Utility, Anaconda, etc.) will now misbehave. Most show the disk as being entirely empty, but some show the GPT data rather than the MBR data.

    Quote Originally Posted by chrismurphy
    What is a little bizarre about this sequence that I don't understand here is that the resulting full disk F16 installation does have an MBR called a protective MBR which should have prevented Windows 7 installer from willy nilly claiming any space.
    I don't recall the precise details, but I seem to recall that the Windows installer does have an option to completely wipe the partition table. When you use that option, it completely replaces the MBR data, but not the GPT data. This is an example of sloppiness on Microsoft's part, though -- Windows 7 does have GPT partitioning capabilities, which it uses when installing in UEFI mode. Probably the Microsoft programmers were being lazy, or didn't consider the possibility that not wiping the GPT data could cause problems.

    Quote Originally Posted by chrismurphy
    If in fact there is partition corruption, I would want the installer to inform me of it and bail out, not fix it. This should be dealt with special tools designed for fixing damaged partition tables and giving a clear review of the intended fix before applying it rather than merely autofixing it.
    Personally, I'd rather have the installer bail out rather than attempt to automatically (without authorization) fix the problem; but if the installer can fix the problem, providing the option to do so would be reasonable. If I trusted the installer (or libparted in this case), I could then use that option, or abort if not.

    At the moment, though, this is moot; libparted does a poor job of handling errors.

    Quote Originally Posted by chrismurphy
    Well I think you hit the nail on the head originally when you essentially proposed it was a mistake to install F16 first and Windows afterward as Windows does not necessarily play nice to foreign operating systems installed before it. Especially if it's a preexisting GPT based installation.
    I agree with this. I will say, though, that I think it's also a mistake for Fedora to have switched to using GPT as the default partitioning system on a blank disk, for precisely the reason that is leads down a path to problems like this one. GPT has its advantages, and I advocate its use when appropriate, but the Fedora developers can't possibly know whether a given user will want to install another OS after installing Fedora. IMO, it should work like this:

    • On BIOS-based systems with empty disks, use:
      • MBR on disks under 2 TiB in size
      • GPT on disks over 2 TiB in size, but warn the user of this choice, including explicit mention that Windows won't install to the disk.
    • On EFI/UEFI-based systems with empty disks, use GPT
    • On all systems, if existing partitions exist, use the existing partition table type
    • In all cases, Anaconda should provide the option to override the installer's default choice


    This last point will help bypass a lot of problems, although I admit it also clutters the user interface in a way that may be confusing to newbies. Perhaps it could be put on an "advanced" tab or something....

    At one time, I might have thought that switching to GPT as a default made sense, but there are just too many problems with using it on J. Q. Random's computer. TorNN's situation is one of the problems. Another is that there are buggy BIOSes that will only boot from a GPT disk if the MBR's protective 0xEE partition is set bootable, which is non-standard (in fact, it's a minor violation of the GPT spec). GPT's advantages are just too minor for an OS installer to risk these problems, which can be quite frustrating.

  10. #10
    Join Date
    Dec 2008
    Location
    Vancouver, BC
    Posts
    4,328
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    srs: that's actually the conclusion the anaconda devs are coming to, as well. they're certainly considering switching back to MS-DOS by default for <2TB disks on BIOS installs for F17 onwards.
    Adam Williamson | awilliam AT redhat DOT com
    Fedora QA Community Monkey
    IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
    http://www.happyassassin.net

  11. #11
    Join Date
    Jul 2011
    Location
    Birmingham, UK
    Age
    37
    Posts
    2,761
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by srs5694
    Actually, if you check the GPT specification (part of the EFI/UEFI specification, available here), you'll see that a disk with a non-protective MBR and leftover GPT data is a valid MBR disk, not a GPT disk.
    I don't much care for specifications that aren't freely distributable, even if I don't have to pay for access, so I'll just take your good word for it.

    IMO, it should work like this:

    • On BIOS-based systems with empty disks, use:
      • MBR on disks under 2 TiB in size
      • GPT on disks over 2 TiB in size, but warn the user of this choice, including explicit mention that Windows won't install to the disk.
    • On EFI/UEFI-based systems with empty disks, use GPT
    • On all systems, if existing partitions exist, use the existing partition table type
    • In all cases, Anaconda should provide the option to override the installer's default choice
    That I completely agree with as the most sensible default.

    Gareth

  12. #12
    Join Date
    Dec 2011
    Posts
    4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Ok. Thank you guys especially to srs5694.

    Now it's clear that it's a defect rather than enhancement. Also I fully agree that switching to GPT by default brings users like me a lot of pain and nothing more. Regular laptops of regular users do not have disks > 2T and hence GPT is pretty useless in such cases.

    I'll fire a bug against Fedora Anaconda to allow devs to track it down.


    Thank you!

  13. #13
    stevea Guest

    Re: GPT vs MSDOS

    Hmm - not really the place for a wibble - l but I think the MSDOS partitioning is so limited and restrictive that GPT should generally be the preference even on <2TB drives. Many of us have absolutely no intention of installing Win products.
    Growing pains - but I think it does need some q/a in the installer.

    IMO, it should work like this:

    * On BIOS-based systems with empty disks, use:
    o MBR on disks under 2 TiB in size AND the user indicates potential Win/BSD/etc installs
    Last edited by stevea; 9th December 2011 at 11:57 AM.

  14. #14
    Join Date
    Jan 2011
    Location
    Woonsocket, RI
    Posts
    521
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Re: GPT vs MSDOS

    Quote Originally Posted by stevea
    Hmm - not really the place for a wibble - l but I think the MSDOS partitioning is so limited and restrictive that GPT should generally be the preference even on <2TB drives. Many of us have absolutely no intention of installing Win products.
    Growing pains - but I think it does need some q/a in the installer.
    There are advantages to GPT, but whether MBR or GPT is superior, at least on a BIOS-based computer, depends very much on the specific computer and user. In terms of defaults, though, the downside to an inappropriate choice is much more significant for an inappropriate use of GPT than for an inappropriate use of MBR. This is especially a problem because so many people don't know a thing about MBR vs. GPT issues, and so are set adrift when the installer uses GPT inappropriately. That's why, IMO, the Fedora 16 policy should be adjusted -- using GPT by default creates more (or at least bigger) problems than it solves.

    All this said, this issue will fade in importance over the next few years, since computer manufacturers are phasing BIOS out. On UEFI, GPT is the logical choice, with few or no exceptions. (Mac installations with hybrid MBRs to support Windows represent one partial exception, but that's still in the GPT realm.)

  15. #15
    stevea Guest

    Re: GPT vs MSDOS

    srs' - I don't think that's a fair analysis.

    There are clear objective technical advantages of GPT over MBR.

    What you suggest is a "disadvantage" or "downside" of GPT on a BIOS computer isn't a GPT problem at all. It is that some propietary OSes don't support it; it's primarily a limitation of Win7 at issue.

    So let's not re-assign blame claiming GPT is the problem or not a clear advantage. It's a limitation of Win7 at fault. You are suggesting Fedora installer cater to difficulties of Win dual booters. [[The issue might also be resolved by describing the use of gdisk before installing a dual-boot.]]

    I am not immune to the argument that Fedora's installer might need to serve the needs of noob dual-booters who want to use Win ((but then I could suggest another dozen dumb-downs, including the removal of LVM as a default)). I don't greatly care so long as GPT is a clear available option.

Similar Threads

  1. MSDOS/VFAT file compatibility
    By bgoodwin91006 in forum Using Fedora
    Replies: 3
    Last Post: 11th October 2008, 02:36 AM
  2. msdos debug or windebug equivalents?
    By majikthise in forum Programming & Packaging
    Replies: 3
    Last Post: 29th May 2008, 12:54 AM
  3. Getting into MSDOS
    By drez0r in forum Using Fedora
    Replies: 13
    Last Post: 24th October 2006, 06:03 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •