jaclaz

Why not? Did you EVER build a BartPE? It is not difficult at all. jaclaz

Since a CD-ROM (and the .iso file is mounted as CD-ROM) is READ ONLY, I think that the reason is rather obvious. You need to re-build the .iso with pebuilder with a modified registration number in the Registry. Other options include hexediting the .iso file (tricky) Or extracting from the .iso the Registry Hive, modify it after having mounted it on running Registry, then unload it and write it back to the .iso, you will need a Comercial program like Ultraiso, Isobuster or similar ones to be able to edit the .iso, though. jaclaz

If you just formatted the partition, easier way out is using TESTDISK: http://www.cgsecurity.org/wiki/TestDisk It is STRONGLY advised to remove the drive from that PC and attach it to another one as "slave". If you need to perform a recovery of the files (as opposed to partition fixing needed for a wrong format operation with TESTDISK above), you should make a complete byte by byte copy of the drive to another one BEFORE attempting a recovery and perform the recovery on the copy, NOT on the original. AND, you will need enough free space on the "recovery machine" to save the recovered data. A suitable program is the companion of TESTDISK (PHOTOREC) or this program from CONWAY: http://www.pcinspector.de/file_recovery/UK/welcome.htm All the above are FREEWARE. There are severa other COMMERCIAL softwares that might do the job. Depending on the value you think your data has, you might however want to ask for a Professional service, an "easy" job like recovering partition data should be quoted around or below 100 US$, data recovery, depending on how much damage the filesystem has can range from a few hundred dollars to as much as several thousands. This is why it is so important to have a byte by byte copy, should your DYI job fail, you still have the ORIGINAL disk on which a professional can attempt ither methods. jaclaz

You need to edit TXTSETUP.SIF: http://www.msfn.org/board/Switches_TXTSETUPSIF_t14852.html jaclaz

@Ilko_t another question, how did you load the SATA drivers? 1) F6 + floppy 2) TEXTMODE folder: http://www.msfn.org/board/Unattended_insta...ppy_t13173.html 3) TXTSETUP.SIF ONLY: http://www.msfn.org/board/Add_slipstream_S...ion_t77999.html (maybe the last one could "trick" setup into thinking the SATA to be "native" like PATA?) jaclaz

You can use regedit and explore in the: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\PCI Or (more simply) use SIW: http://www.gtopala.com/ or SIV: http://siv.mysite.wanadoo-members.co.uk/ jaclaz P.S.: Yes, but how the "signature number" is generated is not at all clear, not even Daniel B.Sedory, who appears one of the first people to document the feature has a clear take on it. It is possible that some form of "checksum" is generated thus signature on same system (but in subsequent installs) remains the same. However "normal" installs appear to change the disk signature ONLY if it is not already present (i.e. 00 00 00 00).

Doesn't this work ?: http://www.pictview.com/pvw.htm Also, Irfanview should be able to manage .awd files: http://www.irfanview.com/ jaclaz

I'm still a bit lost about it. The rewriting of the MBR on the stick only happens when a SATA drive is present, doesn't it? Can you use an utility like Dimio's HD hacker: http://dimio.altervista.org/eng/ (or any other similar one) to extract: 1) Stick MBR as formatted anew (before starting install) 2) Stick MBR modified by SETUP 3) HD MBR as written by SETUP and attach them in a .zip file so that I can have a look at them? And, sorry, I know I seem a bit tough, and maybe I'm becoming a nuisance but can you re-cap for me if: means that you are running the stick with GRUB MBR and not with the "standard" MBR + NTLDR + Boot.ini with entry C:\GRLDR? Did you try with the second one above (it is possible that SETUP finds a "strange" code (not geometry) in the MBR and replaces it, what happens if the code is ALREADY a Win2K/XP/2003 MBR? jaclaz P.S.: did you also try putting on the stick the appropriate SATA miniport driver renamed as NTBOOTDD.SYS? This might avoid the different order of enumeration of the drives...

Yes and no, it should remove the drivers from Registry (but of course it will keep the existing driver "database"). So yes, once you reboot the hardware will be re-detected and drivers will be re-installed. And no, you won't need to re-install "a large portion of your software", everything should work automatically, like on a normal install, with windows detecting devices and installing the corresponding drivers that are already on the hard disk. The situation is just like when you remove a device from Device Manager. At subsequent reboot the system will detect the device and re-install it's driver. The method, even without sysprepping has been used with success to move a Win2K install on new hardware, see solution #4 here: http://www.windowsreinstall.com/install/ot...board/win2k.htm Quite obviously, on first re-boot the system will take some time to perform the described re-detection, but you won't need to reinstall ANY "user" software. The procedure is better detailed in #8 on the previous link, remembering that the context in which the article is written is that of changing the hardware, somethig you are NOT going to do. An exception may be some proprietary software whose license serial number is linked to the PC SID, i.e. those softwares that when installing produce a "challenge code" that you have to send to the software manufacturer to get the corresponding "response code", but this kind of software will need to be re-installed and re-activated or whatever anyway if you just re-install the system. jaclaz

hmmm, I don't get it, you CANNOT copy a MBR from stick to hard disk, the partition entry will be invalid (due to different size and geometry of partition) AND disk signature will be duplicated, which has been proved in the past to be a NO-NO due to the problems it causes in drive letter assignments; can you better elaborate? I may be wrong, as often happens, expecially when guessing an undocumented or poorly documented feature, but I think the right approach could be to create a second migrate.inf entry for the SATA disk, linking it's first partition to C:, directly from scratch as per these posts of mine: http://www.911cd.net/forums//index.php?showtopic=19663 http://www.boot-land.net/forums/index.php?...c=2085&st=3 And find a way to write the signature to the SATA drive before starting install. Signature should not be altered by FDISK /MBR or whatever similar action setup does when booting to prepare the HD. This would probably lead (through a signature syntax boot.ini entry AND the appropriate SATA driver copied to root as NTBOOTDD.SYS) to make setup correctly attribute letter C: to the SATA drive. If you could experiment a bit in this direction manually, we will later see if and how it is possible to replicate the procedure automatically, though this would probably mean having grub4dos/grub.exe and some flavour of DOS on the stick, thus, alas, substantially back to square one of the original method 1) through DOS and WINNT.EXE. jaclaz

@wimb Happy to hear a story of success! This is a very interesting report, for two reasons: 1) it confirms that when booting Windows can use NTBOOTDD.SYS even if it is a ATAPI driver, not only SCSI and SATA, I am very interested in this as it is another little step on the road of using the possibility to use ANY driver, as long as it is a Miniport one, to boot. 2) it confirms that the signature sintax works perfectly, though with a delay What would be interesting, if you could make some tests and report, it would be to understand whether the delay is due to: a. the "sheer" presence of the signature syntax (hence the need to scan Hard Disk(s) MBR to check it b. the presence of the Miniport driver renamed as NTBOOTDD.SYS (maybe different timings in initialization that cause the delay) Proposed testing (given that you are familiar with procedures needed should the system become unbootable): 1. Only re-copy the NTBOOTDD.SYS to root of drive 2. Only re-add the signature syntax line in BOOT.INI 3. Both of the above I have not any SATA equipped hardware, but I don't think that what you suggest is feasible/useful, as when you run the WINNT32.EXE C: will be almost invariably the First Active Partition of your First Hard Disk, and NOT the USB stick, moreover, if I am not mistaken, executing such a command will modify your "resident" BOOT.INI to start install at next reboot of the PC.... Cheers, jaclaz

Well, basically once you have stripped the SID from the machine, at next reboot Windows won't (obviously) find one, and thus will re-detect hardware and ask for Product Key. For the intended use of the sysprep tool, which is: 1) Doing a complete install with all settings configured 2) Removing specific hardware/machine settings 3) Image (clone) the system 4) Deploy system to other computers 5) Boot the other computers to let the minisetup find the changes (including individual machine SID and Product Key) It is of course VITAL to make the image immediately after the stripping has been done, otherwise on next reboot the stripped info will be re-detected and re-applied, thus making the install once again "machine dependant". Since you don't need to deploy the system, you also do not need to image it after "sysprepping" it, on the contrary it would be a VERY GOOD idea to image the system BEFORE attempting using sysprep on it. jaclaz

Yes, you need to change the serial info on your current install. Unfortunately, unlike XP, there is no "simple" freeware solution I know of. You can use Sysprep to change SID and product key, but it is not a really straightforward chore: http://www.microsoft.com/downloads/details...;displaylang=en but of course, since you are not, at the moment, a "Genuine user" you will need to download it from another PC. The procedure should be this: Since you are not changing system, this should be enough: sysprep -reseal -quiet -mini But DO READ the docs of the utility and search some more info in it BEFORE attempting the above, here is a very well made guide: http://www.vernalex.com/guides/sysprep/index.shtml jaclaz

FYI, and for the record, 52 is valid as well, but it is ususally a CP/M one: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Are you sure it was 52 and not 42? besides being the answer to the Ultimate Question of Life, the Universe and Everything , 42 is a valid partition identifier, but it belongs to "Dynamic Disks" : I have seen systems on which (reportedly by "black magic", but most probably by a failed attempt at fiddling with Dynamic Disks), the partition type has been changed to 42. jaclaz

Well, it is a pleasure, and by the way that's the base of a tech forum like MSFN is, to exchange ideas and (hopefully) find solutions. Just as an example, at the time of the 911CD post I was convinced that to have NTFS one would need to complete install as FAT/FAT32 and later run convert.exe, now, if I get it right, you just pointed out and confirmed that Windows Setup can convert the filesystem to NTFS even if the source files are on it? jaclaz

@eidenk VERY good info! Essentially we are all saying the same thing, with only some different "shades". You are very correct in your assumption: the slightly different approach I have is a "better safe than sorry" - call it "overcautious" if you like, but reading between the lines of this: I understand it as follows: "Look, since a lot of third parties made modifications to our Operating System DOS, we were forced to implement some of the same modifications, to avoid a prospectively enormous number of calls from customers that when upgrading from one of these modified systems to our new version of DOS, that remains the only GOOD one, risked to loose data, but we DO NOT like this, and we won't allow the abuse of the way DOS is designed to let people choose to have more than one Primary partitions through our tools, in other words, YOU ARE ON YOUR OWN" Given the above, and the sheer fact that, most probably, a lot of third party tools and utility developers assumed (wrongly) that the only way of partitioning is the "official" FDISK one, I still think Petr recommendation to be valid : as well as my take on the matter: To this you add the possibility, explained in my previous post: http://www.msfn.org/board/index.php?showto...85729&st=20 As said, the above does not mean impossible, it does not even hints that a problem will or has a probability to happen, only that it can happen, in particular occasions. Cheers, jaclaz

snowden, sorry, but evidently it's you that are missing something, like a few months work by several members. The initial "normal" way by porear you are referring to, due to the deletion of some files (and some other minor things) did work only once. The new "final" method, thanks to ilko_t and cdob is repeatable: http://www.msfn.org/board/index.php?showto...1384&st=128 (previous posts are to be considered obsolete by the above one) As said in the other thread I too find the WINNT.EXE method better, but I personally have on ALL my machine a 1 Gb FAT16 partition as First Active Primary. And, as said, speaking of nliting, removing WINNT.EXE install support makes the build smaller. jaclaz

OT: jaclaz

You mean this: http://support.microsoft.com/kb/278940/en-us jaclaz

@snowden If I may, it would be better if you do not double post, and simply give links to the thread where you posted: http://www.msfn.org/board/index.php?showtopic=82856 This way users can easily find the interconnections between different threads. jaclaz

@Ponch With all due respect, maybe jcarle is the only person knowing what he meant. I don't think that the fact that this is an old thread is at all relevant, as long as more CORRECT information is given. @all As is, the sentence: does not stand, as eidenk pointed out, if I may with a bit of unneeded aggressiveness, as FAT is a filesystem, and "knows nothing" itself about other partitions, a FAT partition doe not evem "know" if it is Active or not (as this info is in the MBR, which has NOTHING to do with the filesystem(s) used). If you just change one word in jcarle's sentence, everything is right however: It is the Operating System design that may (or may not in the case of DOS) allow for several primary partitions. About the MBR, as hinted before, though the de facto standard allows for 4 partition entries, there are "special" MBR that allow for more than 4: http://en.wikipedia.org/wiki/Master_boot_record http://www.win.tue.nl/~aeb/partitions/part...es-2.html#ss2.9 http://mirror.href.com/thestarman/asm/mbr/DOS33MBR.htm Please note that this has nothing to do with the use of some bootmanagers that allow more than four partitions by using redirections to other sectors on the HD. jaclaz

@snowden, FYI, another method that needs not WINNT.EXE support (and thus more "compatible" with nlited installs) can be found here: http://www.msfn.org/board/index.php?showtopic=61384&hl= Final (for the moment) howto here: http://www.msfn.org/board/index.php?showto...1384&st=128 Please note that this method, like the one linked to on the 911CD forum: http://www.911cd.net/forums//index.php?showtopic=16713 which is substantially the same as yours, does not require ANY Commercial app, everything is done through built-on tools and/or Freeware / Open Source software. If I may, you could "shave off" a couple of passages in your way of installing, the convert.exe program can convert BOTH FAT16 and FAT32 filesystems to NTFS: http://support.microsoft.com/kb/307881/en-us So, if you are using DOS 7.x/8.0, which supports FAT32, you don't need to make a small partition and later resize it, you can directly make an adequately sized FAT32 one and convert it. With the resizing of the partition made not needed, there is also no need for a Commercial app, you can do the first part with Freedos FDISK. Though the convert.exe does not appear to have ever caused problems, I find, at least theoretically, safer the newish "direct" method as the volume is natively formatted as NTFS by Windows setup, as in a "normal" install. jaclaz

Well, you cannot assign a number to a text, but you can use the text to determine a value in the cell where you are now putting the "SUM()" function. Can you better explain the layout of your excel spreadsheet? I mean you don't have you can have three cells in adjoining columns with tbose values. Supposing you have: A1 -> 2 B1 -> OUT C1 -> 3 the formula in D1, INSTEAD of =SUM(A1:C1) could be: =A1+C1+IF(B1="OUT",5,0) If you have several different strings to give a value to, you can make a table for them, say you have just two values, "OUT" and "IN" in another place of the same worksheet (in this example, but it can be on another sheet as well) you put (say): E1 -> IN E2 -> OUT F1 -> 10 F2 ->5 the formula in D1, INSTEAD of =A1+C1+IF(B1="OUT",5,0) could be: =A1+C1+VLOOKUP(B1;$E$1:$F$2;2;0) jaclaz

Just for the record, and trying to limit the confusion, everything in this thread is referred to grub4dos, not grub. Grub4dos is a "fork" / "evolution" of grub that adds a number of features to standard "grub" and (at the moment at least) misses some other features of the original. While the two projects are close relatives (and actually grub4dos is derived from grub), and the syntax and overall way of working is VERY similar, some commands and features present in grub4dos (mostly those related to booting DOS, Windows 9x/Me, NT/2k/XP/2003 and Vista) are COMPLETELY missing in grub, while some of the advanced features of grub, like variables handling aren't (yet) present in grub4dos. Thus, the two programs are NOT completely interchangeable. Grub4dos "Whereto" is here: http://www.boot-land.net/forums/index.php?showtopic=14 jaclaz

Just for the record, this site appears to be VERY informative on Vista dual booting: http://www.multibooters.co.uk/ jaclaz