Hi Paul,
apart from the GPT question, the current problem also revolves about NOT booting from a fixed disk. So what a normal MBR does is, or should be: ==> Look at all four primary partitions. If exactly one of them is marked as bootable by boot flag, load the boot sector of that. If that contains the 55 AA magic, run the boot sector. If anything goes wrong, show a message, wait for a keypress and return control to the BIOS to let it try to boot from other disks, for example from CD/DVD. <== The FreeDOS installer can use this to make sure that if it finds a disk to have to DOS partition yet, it can make one: If it had OTHER partitions before, it must first ask the user whether they want to replace those, add a DOS partition in the free space, if any, or abort, because it cannot resize existing partitions! By not flagging the new partition as bootable, the next boot process should be able to AVOID booting from the not yet formatted partition, boot the installer from CD/DVD/USB again, so it can format the new partition and optionally reboot once more. Only when the partition can be written as DOS drive letter, the installer can SYS it and put all needed FreeDOS files on it before marking the partition as bootable. This would save efforts for the user on real or virtual computers which make it hard to open the "boot from CD/DVD/USB" menu somehow. And it would not require destroying the boot program, which also is stored in the MBR, to avoid booting from a disk before DOS is there. I really think the installer should never destroy the boot program without asking. As FDISK can read the existing MBR into a file, because the installer has a RAMDISK for temp file processing, the installer could easily check for the following: - does the MBR have the 55 AA magic yet? - does the MBR have a boot program at the start yet? - does the MBR contain any partitions yet? - is any of the partitions FAT yet? - is any of the partitions flagged as bootable yet? - is a FAT partition flagged as bootable yet? I guess it would be even better if FDISK itself can provide those checks and answer by errorlevel? At the moment, FDISK overwrites the boot program if there is no 55 AA magic, without askinig and without showing a message about it. That sounds like a VERY bad idea. If I remember correctly, people have gotten their MBR destroyed in freak accidents where a spurious MBR read error gave FDISK the impression that there was no 55 AA. Others may have useful content in their MBR, but no MBR 55 AA magic yet. Again, FDISK should really ask first about such things! If the MBR boot code itself is missing, for example because the MBR has ONLY identical bytes in it from offset 0 to 7F or similar, FDISK could of course make a more bold statement about replacing the MBR being a GOOD idea. Are there MBR boot programs which do not even try to boot anything, but only show a message and hang or return to the BIOS? If so, how should it detect those? I guess not containing any CD 13 would be an easily detectable sign: No BIOS disk access ;-) > I think in most cases, it would do the right thing. > And could be better than most MBR already present. > > Not sure it could be coded in such a small place however. If you want an example of a decent MBR boot code, you could probably check Tom's "smart" MBR which he has made available for use via FDISK /SMARTMBR The SYSLINUX MBR requires 386+ and if anything goes wrong, it shows a message, returns control to the BIOS by invoking int 18, and if int 18 unexpectedly returns, it halts the system. It uses int 13.41 and int 13.08 for LBA and CHS geometry checks and int 13.42 or 13.02 to read the boot sector. The SYSLINUX GPT MBR instead of int 13.08 uses int 13.48 and of course will handle a different, GPT, partition table format. At first glance, the SYSLINUX "alternate MBR" will not try to calculate CHS values from LBA values, but use the CHS values from the raw partition table. Also, it will not care about you having more than one bootable partition, even though you should not :-p As example for checks being important, the MBR of an SD card I bought DOES contain the 55 AA magic AND a partition table, but the partition is not marked as bootable and if I would change the flag it will still not boot: ALL bytes on offsets 0 to 1BD have the value ZERO ;-) Another example is a boot cheat I have made myself ages ago: It can either jump to int 18 or halt the system depending on the detected problem and never uses LBA. And it reserves a bit of memory (via 40:13) to install a thing to modify int 13 calls to interpret access to disk 0x81 as access to heads > 64 on disk 0x80 on a really ancient BIOS I had back then which would use the 2 highest bits of the head number as additional bits of the cylinder number. So instead of being limited to 512/528 MB, I was able to use my 850 MB disk as one of 504 MB and one of 346 MB. This was a horribly ugly trick and I had switched to using Ontrack Ez Drive or similar soon afterwards. Modern systems can always translate your geometry into "more heads" to get the most capacity out of your first 1024 cylinders, e.g. 8 GB, but old BIOS needed Ontrack help for this. But I think it is a good example of why one should never delete boot code without asking. Because no matter whether Ontrack is installed or Eric's ugly trick, overwriting the MBR boot code would destroy it. Note that Ontrack had the option to boot from floppy AFTER loading Ontrack from MBR: You were safe then, because it would hide the Ontrack MBR from you and let you see only the "more heads" transformed data. Cheers, Eric :-) _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
