Hi Jerome, if the installer cannot be sure that it will have a ramdisk, then there should be ways to do ALL the things which it does without needing pipes or temp files, until a target drive is open :-)
So apart from MBR analysis, what else would it have to miss without a ramdisk at the moment? Given that FDISK has many known problems (see my earlier mails) an update for FDISK could include some "MBR analysis, return results by errorlevel". How does the installer test for presence of 1. any and 2. FAT partitions at the moment? And 3. how does it test whether the FAT partitions are formatted yet? Tom, general question about the known issues in FDISK, would you or Japheth be willing to fix those and add some MBR analysis feature? Or is Brian E reifsnyder still available for help? >> the installer could easily >> check for the following: >> >> - does the MBR have the 55 AA magic yet? > > There is *no tool* for this at present. > >> - does the MBR have a boot program at the start yet? > > There is *no tool* for this either. > >> - does the MBR contain any partitions yet? > > Installer does that already. > >> - is any of the partitions FAT yet? > > Installer does that already. > >> - is any of the partitions flagged as bootable yet? > > Installer *does not do* that. > >> - is a FAT partition flagged as bootable yet? > > Installer *does not do* that. > It simply marks the target partition as active. > >> I guess it would be even better if FDISK itself >> can provide those checks and answer by errorlevel? Of course a separate check tool would be okay, too. Something similar to my WHICHFAT tool, for example. If necessary, I could come up with a small tool for this. Would it always check BIOS drive 0x80 or does it have to be more flexible? Should it also check for GPT or do some other fancy things, by the way? > Actually, I have a different idea in mind > > If the installer can auto-partition the drive (which > ONLY happens on drives without existing partitions), Good point. Any existing partitions should not be touched by automated partitioning changes, as we use no partition move/resize/etc. tool. > then V8Power Tools will check the MBR. > If it does not have boot code, it will write > a boot code signature to it. What do you mean by "write a boot code signature" and what is your definition for "have boot code"? > Later, when the installer gets to the point where > it wants to update the MBR. It will ask V8PT to > check for that signature. If present, it will just > overwrite the boot code. Otherwise, the installer > will prompt the user to see if they want to replace it. So apparently you mean some kind of magic value to indicate "there were no partitions here before". But which advantage does that have? You could also say "if there were no partitions at all AND there was no boot code, add boot code as well while the FAT partition is created." This would avoid the need for magic messaging between two time points. Also, "if there WERE partitions, but NO boot code, ASK the user before adding boot code". This is not likely to happen often, but it would happen e.g. when you install to a pre-formatted, not-bootable SD card, USB stick or similar. > In effect, if the drive was blank and had no MBR, it will be > automatically updated. Otherwise, user will be asked to replace it. Actually if it was not blank and if it had MBR boot code, replacing the existing boot code is probably not necessary at all, but it is okay to still offer MBR code updates in advanced mode. Even if it WAS blank, but HAD boot code, there is no real need to update the boot code either. > On a side note, moving the “Update the MBR?” prompt from > advanced mode only to default mode has at least one issue. > I do not know how many inexperienced users will understand > the question and realize what it actually means. The > question should probably be reworded. If the users do not know what they are doing at all, do not invite them to shoot their own feet either. If it ain't broke, don't break it. Cheers, Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
