Filesystem Type Unknown, Partition Type 0x7 - Dual Boot Linux/Windows

[gungaden]

I relate the following in the hope that it might bless someone else -

Several months ago, I installed PCLOS 2009 on a family member's PC running Windows XP. She was quite pleased with the ease of use and the quick response times compared to the XP OS installed. She did, however, still wish to boot into XP from time-to-time to access some Windows-specific software. Therefore, I setup a dual-boot system with GRUB.

When PCLOS 2010 was released, I installed the new version over the old 2009 version. The installation went very well, the family member was even happier with the 2010 version.

After the upgrade, however, Windows XP would no longer boot properly. Booting into XP, I continued to receive the error message "Filesystem Type Unknown, Partition Type 0x7". This issue was particularly perplexing in that the Windows Recovery Partition was the first partition with the second partition that of the primary Windows installation. I did considerable research on this error message and read many threads. Many threads stated that the user should run either "Fixboot" or "FixMbr" from the Windows Recovery Disk, or Installation CD. Some said suggested that a reinstallation of Windows is the only way to overcome the corrupted MBR. Some advised that one should run Chkdsk from a floppy. There were many "try this"-type of recommendations, but no one sounded as if they were certain that they could identify the problem nor provide the true solution.

After reading a great deal of reading, it struck me that maybe the partition structure was the problem.

I opened the PCC (PCLinuxOS Control Center), selected "Local disks", then "Manage disk partitions" and selected the Windows NTFS partition. Knowing that I had run Windows Disk Defragmenter multiple times before reducing the size of the Windows partition prior to installing 2009 and knowing that the owner had not done much in Windows subsequent to the PCLinuxOS installation, I took a risk. I reduced the size of the Windows NTFS partition by only a few bytes. I wrote the partition change to disk and rebooted.

This time, Windows loaded properly out of GRUB. It did go through a chkdsk routine before booting all of the way, but once chkdsk ran, Windows completed its boot.

I believe that the problem was introduced by the rounding process of the partition manager upon installation of 2010. In other words, it appears that the Windows partition and the Linux partition were overlapping slightly.

If any of you are experiencing this particular error message on a dual boot system, you might give this a try. However, please note that I did not reduce the Windows partition but a few bytes and had recently run defragmenter on the partition to reduce the risk of losing critical data. 

g

[CaptainSarcastic]

This is interesting - I have been seeing this error on this machine, but hadn't yet bothered trying to troubleshoot it since it has almost no practical effect on me.

I have PCLOS 2010 installed on two machines, both dual-booting.  The one without errors is on a single hard drive with both Windows and Linux partitions on it.  The one with that error is two hard drives, with Windows on one and PCLOS on the second along with a large NTFS data partition.

On this machine (the one with the error) I ran a fresh install on new partitions and installed GRUB on the second drive, leaving the first drive untouched.

I can use the boot menu from the BIOS to boot to Windows on the occasions I want to, and it boots fine, so I hadn't bothered trying to make GRUB boot Windows when it otherwise works just fine.  I might tinker with it, but figured I would chime in that I had also seen this issue and describe the system I've seen it on.

[gungaden]

To fully answer your question:
1) I used Gparted from SystemRescueDisk for initial resizing of the Windows XP partition
2) I then installed PCLOS 2009
3) I later installed PCLOS 2010 over the 2009 installation
4) Finally, I used the PCLOS partition editor within PCC to resize the Windows partition to overcome the error contained in this thread's title.

[The Chief]

gungaden

I suspect all you did was "force" a re-writing of the partition table.  But, how or why it got corrupted, I have no clue.

I'm also wondering if a "Redo MBR" might not have worked just as well...

[gungaden]

TheChief,

You probably know more about this topic than I do. Because Redo MBR only re-writes GRUB, I fail to see how it would have helped. I had already assured that the menu.lst was appropriate. The problem was that the Windows partition was corrupt. I agree with you that the re-write of the partition table fixed the problem. The issue to me seems to center on the question "How did the partition table get corrupted?". I still believe that it is likely that the partitions were made to overlap. If not, then I welcome the correct explanation.

Again, my point to others facing this problem, there is a solution now where none before seemingly existed.

g

[The Chief]

gungaden

I've noticed that to properly use the installation partitioning in PCLOS, you need to do some careful calculations.  I wish it had a choice to "use remaining free space" that you could choose for the last  partition you create, or at least warn you if you are about to leave some space unallocated.

And, of course, it's never clear whether they are talking about 1000 byte kB chunks or 1024 byte kB chunks.

[Never_More]

Okay buddy first of all you have to have linux partition as your primary. Meaning it is going to boot to this first and Pclinuxos should see windows. When you format the Pclinuxos partition you need to have it as either ext2, ext3, or ext4. Also windows has to be the first one on the hard drive in order for it to work. but like I said before in this post your Pclinuxos partition first. Your partitions should look something like this:

Fat32 (Windows)
Ext2 / (pclinuxos) this one should be primary!
Ext2 home (pclinuxos)

That is what your partitions should look like if your going to dual boot. I hope this helps you.

[gungaden]

Never_More,

I offer this response in the same spirit of helpfulness that prompted your response. The issue of this thread is not "What filesystems are appropriate for a dual boot system?", but rather "What can cause an PCLOS update-installation on a FUNCTIONING dual boot system to corrupt the NTFS (not FAT32) Windows partition and how can one solve the problem?". I thank you for your willingness to help, but I felt a need to clarify the issue to keep the thread on target so that it will help others with this specific issue.

g

[Old-Polack]

Never_More,

I offer this response in the same spirit of helpfulness that prompted your response. The issue of this thread is not "What filesystems are appropriate for a dual boot system?", but rather "What can cause an PCLOS update-installation on a FUNCTIONING dual boot system to corrupt the NTFS (not FAT32) Windows partition and how can one solve the problem?". I thank you for your willingness to help, but I felt a need to clarify the issue to keep the thread on target so that it will help others with this specific issue.

g

The answer to the first part of your question is "nothing" therefore there is no problem to solve within PCLinuxOS. Whatever the problem was with the NTFS formatted partition, it originated within Windows.

[gungaden]

old-polack,

I know you to be a seasoned veteran. I know that you carefully read every thread before offering help.

I do have difficulty understanding your logic in this response. Windows was not the operative here. The changes made to the drive partition were not made through the Windows operating system. The changes were made via Gparted and the PCLinuxOS PCC. I believe that it is naive to ignore the fact that the system had no partition problems prior to the PCLinuxOS 2010 installation. To say that the problem was within Windows makes no sense to me. Perhaps you can give me a concrete example of how Windows could have introduced the problem when the operating system was not invoked anywhere in the process. Remember that there was no error before the 2010 installation was begun.

Finally, please remember that my purpose in offering the original post was to provide a WORKING solution to those that receive this particular error message. After diligently researching this particular error, I find that the Linux community has been unable to provide a proper remedy to the error other than to suggest a complete reinstallation of Windows and then a reinstallation of Linux. I only intended to provide others with a proven workable remedy which MIGHT fit other's situations. I never intended this thread to become a contest of knowledge or a slight to PCLinuxOS. I am a PCLinuxOS fan. Statements like "There is no reason that a PCLinuxOS install would cause a corruption to the Windows partition." is a judgement, not a documented fact. It only means that you know of no reason that it could happen. For me, it did happen. For others, it has happened with Linux (other than PCLinuxOS) dual-boot installations. It seems to me that the Linux scripts which re-partition the drive are at fault. I have proven that a re-write of the partition table with a lower upper-limit on the Windows partition will fix the problem in certain cases. I do not hold myself up as an expert. I only know what I have seen and can reason from the observation. You may choose to toss my data or conclusions aside. That is, of course, your prerogative. I only hope that this thread does not get muddied to the point to which others no longer are able to focus on its original information and intent.

I conclude with the beginning statements. I know you to be a seasoned veteran. I know that you carefully read every thread before offering help. I hope that this response does not incite you to defend, but rather, helps you to better understand my purpose and the details.

[Old-Polack]

gungaden:

There's nothing to be defensive about, so don't let that worry you. Each OS uses it's own formatting system for the partition on which it resides. The information concerning the traits of the filesystem is stored on superblocks within the file system itself, on ext file systems. In NTFS the information is stored in a Master File Table. When the primary superblock, in an ext file system, or the Master File Table, in an NTFS file system, becomes corrupted, the file system type cannot be determined, and an error message, such as you received, is displayed. Master File Table corruption can happen in a number of ways, but simply installing PCLinuxOS is not one of them. User error is far more likely a suspect, such as an improper shut down, or even accidental errors such as electrical current spikes. That said, Windows has always been known to do strange things within its own file systems, and within it's registry, that cause spontaneous file system errors. That the error occurred at the time of the PCLinuxOS installation, is most likely pure coincidence. It would most likely have happened anyway, without the installation.

Built into the NTFS file system, a log of transactions against its components is maintained, and used by CHKDSK to repair a damaged Master File Table. Whenever a change is made to the partition, or directly to the file system itself that results in the file system being unreadable CHKDSK attempts to rebuild the Master File Table using the information in the transactions log. When you changed the partition size that triggered CHKDSK to run on the next boot. Most likely you could have just run it from the recovery disk, with the same results. Having not shown us the actual partition table before taking the measures you did, There's no real way of knowing what it's actual state was at the time.

The end result was what you desired, so that's good. The reasoning behind your choosing the method you chose is highly suspect, at best. Blaming the PCLinuxOS installation for the problem, with no more than the information you provided, is much like putting 2 plus 2 together and coming up with 22 as your answer; cute, but illogical. 

[gungaden]

OP,

Excellent response...

To pick up from your statements, I did try running chkdisk from the recovery disk. It provided no help. I also tried running FIXMBR and FIXBOOT from the recovery disk. No help. I did not observe an improper shutdown at any time.

Based upon your explanation, it does not yet make sense to me that chkdsk could have corrected the problem. I could not get GRUB to recognize the Windows partition (Due to corruption) prior to the resizing of the partition. In other words, at boot GRUB would lock up with the title error message. Only after a resizing of the partition would GRUB boot to Windows THEN chkdsk was able to run.

Ideas??

[Old-Polack]

OP,

Excellent response...

To pick up from your statements, I did try running chkdisk from the recovery disk. It provided no help. I also tried running FIXMBR and FIXBOOT from the recovery disk. No help. I did not observe an improper shutdown at any time.

Based upon your explanation, it does not yet make sense to me that chkdsk could have corrected the problem. I could not get GRUB to recognize the Windows partition (Due to corruption) prior to the resizing of the partition. In other words, at boot GRUB would lock up with the title error message. Only after a resizing of the partition would GRUB boot to Windows THEN chkdsk was able to run.

Ideas??

To start with grub can never recognize an NTFS file system, corrupted or not. It simply does not have that capability. (The Linux kernel can, and does, but that's irrelevant during Windows booting) This is why a proper Windows stanza for grub uses rootnoverify (hd0,n) for it's root statement; so grub does not try to read the filesystem, only pass the instruction to boot to whatever is there. If that's all you were going by, it's not even sure that the filesystem ever was corrupted.  

[gungaden]

I am not certain that I understand all of what you just said. I feel certain that in my explanation I have used words sloppily such as to derail you. I will try again....

GRUB was used as the bootloader. On the subject PC and at the point where GRUB reads from menu.lst, I have the option of choosing to boot into PCLinuxOS (either with or without safemode) or into XP. When the XP option was chosen, the error message would appear. That has been the problem from the onset and it is real to me (and at least a few hundred others based upon my internet research). If the filesystem was not corrupt, then the error message is in error, itself. Another way to make that statement is to say, I followed the prompts within the PCC disk partitioner, which is supposed to properly configure GRUB and its subsystem. If there is a problem with the manner in which menu.lst or other supporting scripts are written, then it is an issue with the PCC disk partitioning system. And if it were a problem with the partitioning scripts, how does resizing the Windows partition fix the original script problem? As to the "rootnoverify" statement, my  understanding is that it only suppresses the notification, it does not insure a clean boot. In this case, the boot would hang regardless of message.
 
Do you really believe that the partition filesystem was not corrupt??

[CaptainSarcastic]

I'm not sure if this helps, but I think I have figured out what is going with my system and this error, although I haven't fixed it.

As a refresher, my system is set up like this:

SATA 80GB with Windows XP 64-bit installed

SATA 120GB with large NTFS partition and PCLOS 2010 Gnome installed (/,/home, and swap)

The 80GB is primary in the BIOS, the 120GB secondary.

The 120GB is set as the boot device.

In setting up GRUB using the Control Center I see the 80GB as Windows and as sda, while the 120GB is sdb.

When I try to boot Windows from Grub I get the error initially posted, and noticed it is showing (1,0) as the drive, which would seem to indicate it is looking at the second hard drive, not the first (it is looking at sdb1 rather than sda1).

If I were to manually edit GRUB then I could probably resolve this, but I rarely boot to Windows and can use the BIOS one-time boot menu to change my startup device easily enough - I'm used to doing this to boot from USB drives.

I'm not sure if what gungaden might have affected how Grub saw the partitions vis a vis GRUB, but I figured I would add the additional information about my own error.