OSDev.org

Octacone wrote:@Schol-R-LEA looks like you know a lot about old computers. It is always nice to learn some history along the way.

Thanks, although I should have done more fact-checking: my recollection to the contrary, the original IBM PC could have two full-height floppy drives. However, I am pretty sure that I was correct about it never booting from drive B:, though I am open to corrections.

Also, I once again forgot to specify which university abbreviated as 'SCSU' I was talking about; I meant Southern Connecticut State University, the CT State schools being the junior state university system to University of Connecticut's senior in the same way California State is to University of California.

Octacone wrote:Mkdosfs doesn’t seem to care about fdisk partitioned virtual HDDs??

Utilities like mkdosfs expect to operate on a partition device when the disk is partitioned. You're telling mkdosfs to work directly with your entire disk image, which it isn't really prepared to handle.

Since you're using Linux, it's pretty easy to mount your disk image as separate partition devices. You can then use mkdosfs to format the individual partition devices, just like you would partitions on a physical disk.

@Octocontrabass
Okay so I started over. Created an empty HDD image with 2 partitions, 5 GB each, mounted EACH of them as a loopback device. Checked everything with a hex editor, everything seems to be okay. Now I have a problem, since both fdisk and this page Loopback_Device are outdated I cannot create a FAT 32 filesystem on them. Why, you ask? Because I don't know how many #blocks are there.
This line: There is no way for me to figure that out and Wiki says I should. Any ideas on what that could be and how could I get that number? Google says one block = 1024 bytes but that doesn't make me know the value.

Edit: I figured out the formula:

The wiki instructions expect you to do everything manually, which is quite stupid when automated solutions exist. That's why I directed you to this page describing how to automatically set up partition devices from a loop device.

If you mount your disk image following those instructions, you will see partition devices named similar to /dev/loop0p1 that can be treated exactly the same as any partition on a physical disk, including the format commands. You won't need to specify the number of blocks since the partition device will be the correct size.

Octocontrabass wrote:The wiki instructions expect you to do everything manually, which is quite stupid when automated solutions exist. That's why I directed you to this page describing how to automatically set up partition devices from a loop device.

If you mount your disk image following those instructions, you will see partition devices named similar to /dev/loop0p1 that can be treated exactly the same as any partition on a physical disk, including the format commands. You won't need to specify the number of blocks since the partition device will be the correct size.

I actually managed to mount both of them. I don't have any problems with that, anymore. Except they are not formatted correctly... again...
I will try to use your method and see if it works.

Edit:
Success!
I did everything as suggested and it worked. There are now two mounted and FAT 32 formatted partitions that I can access. Now I can finally start working on my bootloader without having to worry about this kind of stuff.
Is it normal for a hard drive with two partitions to contain 4 "FAT32 " signatures? Are those just FAT 32 specific backup tables?

For those who are interested here is my MBR: and here is a table whose purpose I don't know. Is this a bios parameter block together with a file allocation table altogether forming a VBR? What are those 4 extra bytes after 55 AA (not in the picture, 52 52 61 41)?
https://i.imgur.com/PeHqMfR.png

Now might be a good time to grab a copy of Microsoft's FAT filesystem specification and see if you can find the answers to your questions in it.

Here's a PDF copy of it.