Bootloaderis not consistent when booting in real hardware

[nullplan]

Also, ext2/3/4 have a 1024 byte offset from the start of the partition before they use any data, so the BIOS can overwrite as much as it wants in that first sector, it is not going to hurt the superblock.

[bzt]

Nothing else uses it, and BIOSes are not checking for it (they actually can't check for it, that's just not possible).

They can check for and use it.

Yeah, do they? And how? There's no magic bytes in the BPB, how do you check for the presence of a BPB? It's not possible not even in theory. You could use the strings "FAT16", "FAT32" etc., but even M$ says never do that, and there's no guarantee that an NTFS boot sector will have those at all.

I've found one Dell PC that uses the BPB to decide how INT 0x13 AH=0x02 should translate CHS to LBA. It hangs during POST if the BPB is mostly correct but specifies 0 heads per cylinder. (This only happens with unpartitioned drives, of course.)

I call this bullshit.

First, you say that Dell BIOS checks for the BPB, then you say it doesn't. Which one is it then? How does the BIOS know if the disk is unpartitioned (talking about non-GPT)?

Second, how do you distinguish an MBR from a VBR? They have exactly the same magic numbers! No reliable method exists to tell if there's a partitioning table or a BPB in a boot sector. Both MBR and VBR can start with a jump instruction and they both have the same magic bytes. As a matter of fact my boot loader uses exactly the same sector for both the MBR and VBR. (FYI all the disk tools are using the LBA address to decide, which method doesn't work in your case.)

It is more likely that you had a bad boot sector code that Dell BIOS refused to boot. And then when you put a BPB in it, you accidentally fixed the issue that was preventing the boot, but it wasn't for the BPB at all. Or when you've partitioned it, that override the entire boot sector replacing your bad code.

If the intent is to write an MBR you wouldn't need a BPB.

That's 100% true, therefore rumors about BIOS checking BPB is nothing more than myth.

Cheers,
bzt

[neon]

Hi,

Magic values is a part of the equation: you are supposed to read the bytes and check if they make sense and are valid values. If you limit the domain of boot records that you need to make sure will work it becomes a lot easier. Vendors are able to make assumptions about the operating systems that will be started - many of which may not be general rules. Other operating systems just have to adopt if they want to run on these machines.

You are looking for a general solution to a problem that only exists in practice.

[Octocontrabass]

Yeah, do they? And how? There's no magic bytes in the BPB, how do you check for the presence of a BPB? It's not possible not even in theory. You could use the strings "FAT16", "FAT32" etc., but even M$ says never do that, and there's no guarantee that an NTFS boot sector will have those at all.

I don't think I ever figured out exactly what the Dell BIOS was looking for when deciding whether a disk contained a BPB or not. I do know that it wasn't very good: if I formatted an unpartitioned flash drive as FAT and overwrote offset 0xD (sectors per track) with 0, it decided no BPB was present, but doing the same with offset 0xF (heads) caused it to hang during POST.

First, you say that Dell BIOS checks for the BPB, then you say it doesn't. Which one is it then?

Where did I say it doesn't?

How does the BIOS know if the disk is unpartitioned (talking about non-GPT)?

Second, how do you distinguish an MBR from a VBR?

That depends on the firmware. Some will look for a valid BPB, and if they don't find one, they assume the disk is partitioned. Some will look for a valid partition table, and if they don't find one, they assume the disk is unpartitioned. Some will look for both a valid BPB and a valid partition table, and if they find neither, they refuse to boot the disk. Of course, there is no standard for what counts as "valid".

It is more likely that you had a bad boot sector code that Dell BIOS refused to boot. And then when you put a BPB in it, you accidentally fixed the issue that was preventing the boot, but it wasn't for the BPB at all. Or when you've partitioned it, that override the entire boot sector replacing your bad code.

No, I assure you, it would hang during POST. It shows a loading bar on the screen during POST. If I used Windows to format an unpartitioned flash drive to FAT and changed the byte at offset 0xF to 0, the loading bar would stop partway.

[bzt]

doing the same with offset 0xF (heads) caused it to hang during POST.

Sounds to me like a BIOS bug. I don't think it worth the effort to support that particular buggy BIOS.

First, you say that Dell BIOS checks for the BPB, then you say it doesn't. Which one is it then?

Where did I say it doesn't?

Here:

(This only happens with unpartitioned drives, of course.)

That's why I asked how does the BIOS know if the disk is unpartitioned?

How does the BIOS know if the disk is unpartitioned (talking about non-GPT)?

Second, how do you distinguish an MBR from a VBR?

That depends on the firmware. Some will look for a valid BPB, and if they don't find one, they assume the disk is partitioned.

Hold on right there. You said BPB is only checked if the disk is unpartitioned, therefore you cannot use the BPB check to determine if the disk is partitioned.

Some will look for a valid partition table

But how? Can you explain how to detect for an MBR partitioning table existence? (Other than it is in the first sector).
I mean, can you give an implementation for this?

Code: Select all

/* return 1 if there's a partitioning table included, 0 otherwise */
int hasPartitioningTable(char sector[512])
{
    /* I'm curious about this part */
}

But take a step back, why is there a need for any BIOS to know if there's a partition on the disk? According to the BIOS Boot Specification, the BIOS just loads the first sector, it doesn't care nor need to know if there are partitions or not. Any BIOS which does, is not BBS compliant and should be considered buggy and faulty.

Some will look for both a valid BPB and a valid partition table, and if they find neither, they refuse to boot the disk. Of course, there is no standard for what counts as "valid".

As I've said before it simply does not worth the effort to support such buggy BIOSes which violate the BBS specification. They are extremely rare, and now with UEFI taking over on real machines and BIOS soon will be exclusive to VMs it simply doesn't matter any more. (Plus this only happens if you choose "floppy emulation for USB" in the BIOS setup, so the solution on your Dell is just to uncheck that option. Sometimes called "use HDD emulation for USB" with reverse flag, but that's the same.)

The best and simplest solution is:
1. start your sector with a jump instruction (E8h or E9h)
2. finish it with 55h AAh magic
3. leave both the BPB and partitioning table area empty (leave it to be filled up by another tool, like fdisk or mkfs.vfat for example)
4. play with your BIOS setup, there'll be a configuration which does not check for BPB nor partitions

My boot loader does this, and it works as MBR, VBR and even as CDROM "no emulation" boot record too, and nobody ever complained about any BIOS refusing to boot it on real hardware, regardless to the configuration. It Just Works (tm)
BTW, if you still have that old Dell, I would appreciate if you could give a try to boot BOOTBOOT on it and see if it works.

Cheers,
bzt

[Octocontrabass]

Hold on right there. You said BPB is only checked if the disk is unpartitioned, therefore you cannot use the BPB check to determine if the disk is partitioned.

No, I said this particular Dell BIOS only uses the CHS geometry from the BPB for INT 0x13 AH=0x02 when the disk is unpartitioned. It may still examine the BPB when determining whether the disk is partitioned or not.

But how? Can you explain how to detect for an MBR partitioning table existence?

It's different for each BIOS I've examined. Some look for exactly one "active" partition and assume any values other than 0 or 0x80 means no partition table is present. Some examine the CHS or LBA addresses to see if the partitions physically fit on the disk and don't overlap each other or the MBR. There are probably other methods in use, these are just the ones I was able to confirm through testing.

But take a step back, why is there a need for any BIOS to know if there's a partition on the disk?

Because it maintains compatibility with DOS without forcing the user to change BIOS settings.

play with your BIOS setup, there'll be a configuration which does not check for BPB nor partitions

On most of the PCs I've tested, there is no such setting.

BTW, if you still have that old Dell, I would appreciate if you could give a try to boot BOOTBOOT on it and see if it works.

I don't have room to set it up at the moment. I expect it'll work, unless you've intentionally crafted a BPB that makes it hang.