Re: File system type compatibilities <SOLVED>

P19 · Post by **P19** » Mon Sep 01, 2014 12:36 am

> "are you backing up from linux itself? if so, that file system will be
> dirty, try backing up from windows or from the boot disk."

After I fix this problem, I may take a look at installing the program on Linux so that I can use it from there directly, but so far I have only ever used Windows or the IFL boot disk. The closest I have come to doing it in Linux is while booting from the ISO image in a VM on QEMU, which works nicely too.

Anyway, it appears that I have managed to get the wrong type ID put on these two partitions because they show up as type 7. So I need to fix this before it causes a bigger problem with another program. Fortunately, it appears to me that this field is more informative than anything else, at least based on my activities with it for the most part. I think, from what I have been able to find so far while googling this issue, I should be able to change the IDs with, say, fdisk without loosing any data. I know that the images from them work fine after restoring, as I mentioned before, and I do have good backups in any case.

What do you think? Use fdisk to change from 7 to 83, and keep my fingers crossed meanwhile?

Post by **TeraByte Support** » Mon Sep 01, 2014 5:51 am

use partition work in bootit or image for linux full version (if you have
the BIBM key) - just go to properties of that partition and change it.

"P19" wrote in message news:[email protected]...

> "are you backing up from linux itself? if so, that file system will be
> dirty, try backing up from windows or from the boot disk."

After I fix this problem, I may take a look at installing the program on
Linux so that I can use it from there directly, but so far I have only ever
used Windows or the IFL boot disk. The closest I have come to doing it in
Linux is while booting from the ISO image in a VM on QEMU, which works
nicely too.

![:)]({SMILIES_PATH}/icon_e_smile.gif)

Anyway, it appears that I have managed to get the wrong type ID put on these
two partitions because they show up as type 7. So I need to fix this before
it causes a bigger problem with another program. Fortunately, it appears to
me that this field is more informative than anything else, at least based on
my activities with it for the most part. I think, from what I have been able
to find so far while googling this issue, I should be able to change the IDs
with, say, fdisk without loosing any data. I know that the images from them
work fine after restoring, as I mentioned before, and I do have good backups
in any case.

![:)]({SMILIES_PATH}/icon_e_smile.gif)

What do you think? Use fdisk to change from 7 to 83, and keep my fingers
crossed meanwhile?

P19 · Post by **P19** » Mon Sep 01, 2014 4:13 pm

Okay, the primary partition allowed my changing it from 7 to 83, as did the logical partition #5; however, it looks like the extended partition #4, which contains partition #5, cannot be changed from type "f" to type 85 without first deleting it. So, I suppose that deleting it would delete what it contains along with it. Therefore, I need to have corrected the partition type of logical partition #5, made a backup, delete extended partition #4, replaced it with another extended partition identified as type 85, and finally restore the image of partition #5 manually. How's that sound to you?

I suppose what happened, in addition to my not paying attention to the effects, was that these partition types were created when I used Windows OS to repartition this disk. It made, for instance, the Windows Extended type f instead of Linux Extended type 85. Live and learn.

Post by **TeraByte Support** » Tue Sep 02, 2014 5:46 am

You can just change it if you like - just type in 0x85 if that's what you
want.

"P19" wrote in message news:[email protected]...

Okay, the primary partition allowed my changing it from 7 to 83, as did the
logical partition #5; however, it looks like the extended partition #4,
which contains partition #5, cannot be changed from type "f" to type 85
without first deleting it. So, I suppose that deleting it would delete what
it contains along with it. Therefore, I need to have corrected the partition
type of logical partition #5, made a backup, delete extended partition #4,
replaced it with another extended partition identified as type 85, and
finally restore the image of partition #5 manually. How's that sound to you?

I suppose what happened, in addition to my not paying attention to the
effects, was that these partition types were created when I used Windows OS
to repartition this disk. It made, for instance, the Windows Extended type f
instead of Linux Extended type 85. Live and learn.

TeraByte Support(TP) · Tue Sep 02, 2014 12:10 pm

P19 wrote:
> Okay, the primary partition allowed my changing it from 7 to 83, as did the
> logical partition #5; however, it looks like the extended partition #4,
> which contains partition #5, cannot be changed from type "f" to
> type 85 without first deleting it. So, I suppose that deleting it would
> delete what it contains along with it. Therefore, I need to have corrected
> the partition type of logical partition #5, made a backup, delete extended
> partition #4, replaced it with another extended partition identified as
> type 85, and finally restore the image of partition #5 manually. How's that
> sound to you?
>
> I suppose what happened, in addition to my not paying attention to the
> effects, was that these partition types were created when I used Windows OS
> to repartition this disk. It made, for instance, the Windows Extended type
> f instead of Linux Extended type 85. Live and learn.

Just a note that there's no need to change the extended partition type to type '85' to fix the problem you were having. Leaving it as a type 'f' will work fine. The main thing is changing the actual Linux partitions/volumes themselves to type '83'.

Also be aware that Windows will NOT recognize type '85' as an extended partition. So if Windows is on that system and needs to see any volumes inside that extended partition (i.e. NTFS or FAT32 volumes), the extended partition will have to stay as type 'f'. Linux itself will recognize any of the extended partition types (5, f, 85) as an extended partition.

P19 · Post by **P19** » Wed Sep 03, 2014 2:18 pm

This problem has been fixed now that I was able to change the partition labels for file system IDs to their correct types. It is not enough that I had changed the logical partition without changing the extended partition container as well. They are different types and both have to be labelled accordingly. With these changes TBI View shows me Linux ext3 and ext4 correctly. Thanks, again.

P19 · Post by **P19** » Wed Sep 03, 2014 8:27 pm

> "Just a note that there's no need to change the extended partition type to type '85' to fix the problem you were having. Leaving it as a type 'f' will work fine. The main thing is changing the actual Linux partitions/volumes themselves to type '83'."

Tom, I noticed your follow-up post 'after' I had already posted my last message. Your statement above was not exactly consistent with my experience. I mean, I did in fact try viewing the TBI file in TBI View with the logical partition set to type 83 for the ext4 file system while the extended partition was set to type "f", but it would not work. I got the same error message as described earlier. Once I changed it to type 5, it did now work correctly. I am not sure what the difference is between type 5 and type 85, and I originally intended to change it to 85, which might very well have worked, but I tried using type 5 and it worked.

I made this change with fdisk because I do not make use of the Boot Manager product (although I am sure it would work just as well). I also found, much to my delight, that I did not have to restore the logical partition as I had expected to have to do. I simply deleted the extended partition and immediately re-created it as type 5, and I then immediately recreated the logical partition within it and finalized the procedure. Afterwards, using "lsblk -f", I could see that the original logical partition, which I had put a label on and saved data to, was once again there as before. The file system contents is perfectly accessible and it appeared now within TBI View finally.

** Note that I edited this message to correct the partition type numbers, which I had stated incorrectly and left it unclear as to what I needed to do. For sake of clarity I am fixing that so that anyone else who runs across this problem and looks at the dialogue would know how I resolved it.

TeraByte Support(TP) · Thu Sep 04, 2014 1:42 pm

P19 wrote:
> > "Just a note that there's no need to change the extended partition type to
> type '85' to fix the problem you were having. Leaving it as a type 'f' will work
> fine. The main thing is changing the actual Linux partitions/volumes themselves to
> type '83'."
>
> Tom, I noticed your follow-up post 'after' I had already posted my last message. Your
> statement above was not exactly consistent with my experience. I mean, I did in fact
> try viewing the TBI file in TBI View with the logical partition set to type 83 for
> the ext4 file system while the extended partition was set to type "f", but
> it would not work. I got the same error message as described earlier. Once I changed
> it to type 5, it did now work correctly. I am not sure what the difference is between
> type 5 and type 85, and I originally intended to change it to 85, which might very
> well have worked, but I tried using type 5 and it worked.
>

If it's working for you now, that's the important thing.

But, FWIW, I do use a type 'f' extended partition on a couple of systems here, and have had no problems viewing the images of Linux logical partitions (volumes) like you were having. The extended partition type (5, f, or 85) shouldn't matter for this purpose. What does matter is that the Linux volume(s) inside that extended partition should be a type 83. If the Linux volume itself is not 83, IFL will treat it as an unrecognized file system, and then that image will not be viewable in TBIView.

The difference in those 3 extended partition types is in how they are recognized by the operating systems. Linux recognizes all 3 types the same way. A Linux installer using type '85' extended partition is pretty rare (if ever), from what I've seen. Most recent distros will use type 'f', which makes the most sense on multiboot systems, because Windows won't recognize type '85' as an extended partition.

Windows will only recognize types '5' and 'f' as extended partitions. Type '5' was for extended partitions within the first 8 GiB (or 1024 cylinders) of a disk, while type 'f' is for extended partitions that can extended beyond 8 GiB.

> I made this change with fdisk because I do not make use of the Boot Manager product
> (although I am sure it would work just as well). I also found, much to my delight,
> that I did not have to restore the logical partition as I had expected to have to do.
> I simply deleted the extended partition and immediately re-created it as type 5, and
> I then immediately recreated the logical partition within it and finalized the
> procedure. Afterwards, using "lsblk -f", I could see that the original
> logical partition, which I had put a label on and saved data to, was once again there
> as before. The file system contents is perfectly accessible and it appeared now
> within TBI View finally.

FWIW, Linux fdisk can also change the partition type without deleting the partition by typing 't', then specifying the partition number you want to change, and then entering the new partition type you want to use. You can also use 'l' to list known partition types as a reference.