fdisk created fat32 partition, which type 0b or 0c?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Mandriva 2009 X86_64 suse 11.3 X86_64 Centos X86_64 Debian X86_64 Linux MInt 86_64 OS X
Posts: 2,369
Rep:
Fat 32 Fat stands as you know fore File Allocation Table It is the pointers of all you,re files
In the old days when you delete a file you only remove the pointer out of the fat so until it is overwritten
you can recover it
History begins with FAT 8 and Fat 16
It has some thing to do with the address the processor can handle and the amount of bites
When storage capacity are growing the heads and the amount off disk in the hd are growing
It was I think windows Me was the last one how use this type off file system
But still any OS needs to know where he can find the files
If you have a HD of 100 GB unformatted it is less 100 GB when it is formatted
is this a trick question? tredegar gave the answer already but in case this is no trick question and you really want to know i am trying to answer it a bit more detailed.
Quote:
Let's say I have a 100GB hard drive (/dev/sda) and need to create a 20GB partition (/dev/sda1) to be used as Windows C:.
What partition type would be needed for this (0x0b or 0x0c) and how do you determine which to use?
it depends on your bios and it's block adressing method: lba or chs. if chs 0x0b else 0x0c.
Quote:
Is is based on bios access method (lba or chs), size of partition, or location of partition? Maybe a little of each?
a little bit of each. 0x0b is a FAT32 primary partition. access method chs, size of partition must be <= 2047 GB. location: dunno if it must be the first partion but it must be primary as said before. 0x0c is FAT32 using lba. rest is the same...
Using gparted (Under SysRescueCD), I created a FAT32 partition and this is what it gives:
Code:
Disk /dev/sdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000f2c91
Device Boot Start End Blocks Id System
/dev/sdb1 1 4699 37744686 83 Linux
/dev/sdb2 4700 4865 1333395 b W95 FAT32
It went with 0x0b even though the drive must(?) be using LBA as:
1. I have it set that way in the BIOS.
2. Drive size is greater than 7.8 GiB. (Extended BIOS CHS Limit)
3. dmesg has this tasty bit:
ata1.01: ATA-5: WDC WD400BB-00AUA1, 18.20D18, max UDMA/100
ata1.01: 78165360 sectors, multi 16: LBA
While this may not be an issue for Linux as it does not care about CHS, it may be an issue for Windows.
Possible bug in gparted or is 0x0b still used for (small?) partitions on LBA drives?
@vadkutya
I understand how to change the type, but that may create "issues".
Here is what I just did:
1. Booted SysRescueCD
2. As root, dd if=/dev/zero of=/dev/sdb bs=512 count=1
3. Use gparted to create msdos partition layout and create 1 primary partition formatted as FAT32
Resulting in:
Code:
Disk /dev/sdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000a5875
Device Boot Start End Blocks Id System
/dev/sdb1 1 4865 39078081 b W95 FAT32
So either my understanding is off or there is a bug in gparted.
i never used gparted so i don't know if there's an option you are probably missing or so. also, i don't understand why fdisk might create "issues". but another way would be using mkfs.msdos or so...
is your FAT32 partition within an extended? i can see a flags column with lba in the picture. can you flag the FAT32 partition after you created it? or the extended, if you use one?
I think gparted does have an LBA checkbox but you would expect it to do that itself in that case.
Most of the "issues" affect old msdos software so I won't waste time with it here.
So here is what I learned so far:
After spending way too much time at Wikipedia under Logical Block Addressing and a dozen or so links from the references section, I decided to zero both sda & sdb and just see what Windows would do.
1. During install select a 5000MB C: Drive (/dev/sda1)
2. Finish install & reboot
3. Using the Disk Management thing, create a 2000MB D: (/dev/sda2) & a 10,000MB E: (/dev/sda3)
4. Reboot to SystemRescueCD
The results were surprising...
Code:
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x16c616c6
Device Boot Start End Blocks Id System
/dev/sda1 * 1 637 5116671 b W95 FAT32
/dev/sda2 638 892 2048287+ b W95 FAT32
/dev/sda3 893 2167 10241437+ c W95 FAT32 (LBA)
It appears that you should use 0x0b even on LBA drives as long as the created partition does not touch cylinder 1025 or above.
I would like to thank MICROS~1 for not putting this information anywhere in their knowledge base.
it seems that the horse doesn't jump higher than it has to . 0x0b (FAT32 without LBA) still uses the old BIOS INT 13 (low level disk read/write) which means it can adress a maximum of 7.8GB disk space. you created a partition of first 5GB than 2 GB (= 7GB) so windows is not forced to use BIOS INT 13h extensions. with the third partition however, it switches to LBA because it has to.
so far so good, but you created a primary partition with gparted which is 40GB. according to my understanding it must use BIOS INT 13h extension, hence no (E)CHS is possible and LBA is the only alternative. so the ID should be c NOT b. i am really confused by now...
maybe it's really a bug. on the other hand. unless you really install windows it doesn't matter since windows will setup the correct mode. the question remaining is can you access the whole 40GB if you mount the hd under linux. this shouldn't be possible. but i am not a hardware expert, sry...
Using gparted (Under SysRescueCD), I created a FAT32 partition and this is what it gives:
Code:
Disk /dev/sdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000f2c91
Device Boot Start End Blocks Id System
/dev/sdb1 1 4699 37744686 83 Linux
/dev/sdb2 4700 4865 1333395 b W95 FAT32
one additional point. the oder in which the partitions appear in fdisk is not neseccariliy the order in which they reside on your hd. if the BIOS uses only the INT13 routines it cannot map higher than 7.8GB so the FAT32 partition would be out of range. however, if the order is reverse this is no problem. also, if the os is linux the FAT format is not of interest since linux uses LBA.
Disk /dev/sdb: 40.0 GB, 40020664320 bytes
255 heads, 63 sectors/track, 4865 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000a5875
Device Boot Start End Blocks Id System
/dev/sdb1 1 4865 39078081 b W95 FAT32
addendum:
maybe gparted doesn't care about 0x0b/0x0c if you don't tell it explicitly. it doesn't really have to. the defaul might be 0x0b. if you install windows then this will be handeled during windows installation. if not and you use linux then linux talks with the BIOS and the BIOS with the disk controller and the disk controller maps it all to the correct physical adress. so if linux handles your partition this should be no problem.
but as i said before. i'm not really sure about all this.
hope this helps, vadkutya
Old thread but still it is useful to update old information:
> NTFS can now be read and written from Linux, though it is slow, and ext2/3 can be
> read/written from Windows. So why use FAT?
I have had issues with NTFS just recently. I could not modify it. No file I created
was really created. I could read the content and copy it, after I put it from my
windows box onto the external hdd. But I could not modify it.
This had something to do with the ntfs3 drivers or something. Rather than wanting
to find out what was the case I changed to vfat. And now I can modify this easily.
Perhaps NTFS is better and nicer on windows, but I am simply giving an example to
the above "why use FAT". In particular VFAT is still useful. Hopefully NTFS
support in Linux will one day be great, but until then even in 2022 you STILL can
have and run into issues. I even read on the www how windows can cause ntfs3 to
honour some weird fast boot setting and make no modification. I have no idea why
NTFS did not work for me here but I had no time to debug this any further, thus
vfat to the rescue (I use an external hdd to transfer my stuff onto windows
machines; I have too much data to omit, lots of open source .exe and .msi files
I need, lots of programming source code I use, including java these days).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.