Hi again (wow, what a lot of traffic today, sigh...), > > I wanted to make ABSOLUTELY CLEAR that nothing must ever automatically > > do FDISK /MBR with as only exception a CUSTOM install disk for unattended > > install on known-empty / known-not-to-have-any-useful-MBR-program systems.
> too bad, people want to have a working system being set up for them. > if MS FDISK does alter MBR, then our FDISK should do so also. I already gave the answer to that one: Display a message "if you have reached this [i.e. partitioning done, SYS done, OSCHECK confirmed the success of SYS] point and still nothing at all happens when you try to boot, please boot from CD-ROM again and type FDISK /MBR". No idea whether MS FDISK zaps the MBR from time to time, but it better not. > On the other hand, destroying dualboots is something MS also does in > Windows setup, and which is a thing we can't afford... Good example. > > Buy a new harddisk and do: > > MIRROR /PARTN > only get a "Drive letter is out of range..operation terminated" > any debug script? MIRROR 0 /PARTN maybe? I am not overly happy with MIRROR anyway, and always use UNDELETE SYSSAVE instead (which can save a lot of stuff but not the partition table). > > Whether the current MBR PROGRAM is working is as hard to decide as whether > > you have a boot virus in there. Far beyond the scope of FDISK. > consider the presence of AA55 as "working". FDISK 1.2.1 / 1.3.0-beta works like this and it kills disk contents. NOT GOOD. In addition, the 55 aa only means "there is a partition table" (DATA) and makes no claim whatsoever about the PROGRAM. If there is a program, you cannot know if it WORKS unless you have a database of all working boot loaders, along with information which of them can handle LBA and information which of them you should never see (e.g. the database would tell you that if you can see EZDRIVE then you MUST NOT proceed with FDISKing, as you will get the wrong partition table contents and might even kill EZDRIVE, possibly losing access to all data on disk until you repair it, which is not at all trivial...). Actually it would be an idea to backup the MBR before anything is written to it. FDISK had some command line option to do exactly that, read the FDISK /? output. I mean: FDISK can save the MBR to a file. Well, the user would then have to save that file to diskette to make repair easy, but at least repair from "unbootable but partition table data is still okay" state would get easier even without diskette backup. > we buy a brand new hard drive that's a clean as you can ever get, and we > want to install a DOS or Windows operating system to it - we haven't > decided yet. What is the correct procedure for getting a "working boot > program" into the "valid Master Boot Record", and who supplies this > program? Is it Microsoft, Intel?? To force the MBR to contain a working boot PROGRAM by deleting the previous version of the boot program, use FDISK /MBR. This even works with FreeDOS FDISK, but my point is that it should never happen automatically, because: > arrive with XP pre-installed, and I have to FDISK them to get rid of it, > but those drives STILL HAVE an MBR right? Yes, if you use FDISK to remove the drive letters for WinXP, the MBR boot program will stay working. Basically the chance to meet any harddisk with broken or missing MBR boot program is only the fraction of the chance to completely screw up your system (EzDrive case) or the bootability of your system (many other cases) by doing FDISK /MBR without thinking about it carefully first. Okay, there are ways to reconstruct partition tables, but just keep it like: Add a text to the readme, or, if you insist, to the install system messages, which tells "if you have never booted any OS on this PC or harddisk, then there is a tiny chance that you have to use FDISK /MBR if the system does not boot after you completed this install process. Do never ever use FDISK /MBR if you already have other operating systems or boot loaders on this system..." Okay, not never ever, sometimes you can be in the lucky situation that FDISK /MBR overwrites a virus without breaking your system, basically if you use no EzDrive/OnTrack/DDO-style software and no fancy boot loaders or anything smiilar. > However, if I understand correctly, AA55 is just a sig, it's not a boot > program... Exactly. Current FDISK 1.2.1 decides that if the sig is missing (or a read error happens) then it would be okay to delete the entire MBR data and entire MBR boot program, replacing it by values for an unpartitioned empty harddisk (but at least with a boot program). So current FDISK 1.2.1 can and will destroy your data if a read error happens or some other unexpected things happen. Luckily gpart can often guess the deleted values after an hour of searching or so, allowing you to regain access to the disk, as only the partitioning but not the contents of the partitions screws up. Eric ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
