jaclaz

You don't actually need to "move" the MBR. (or more generally to "move" anything) You just partition the external hard drive, then you format the active priamry partition on it under any NT based system before Vista or 7 and you will get a PBR that invokes NTLDR. (and you are in the same condition as you are now): BIOS->MBR->Active Partition->PBR->NTLDR->BOOT.INI->grldr Or you use Vista or 7 and add grldr.mbr to the BCD. BIOS->MBR->Active Partition->PBR->BOOTMGR->\boot\BCD->grldr.mbr->grldr Or you use a PBR invoking grldr. BIOS->MBR->Active Partition->PBR->grldr Or you use a PBR booting DOS, and from it you run grub.exe. BIOS->MBR->Active Partition->PBR->IO.SYS->grub.exe Or you install grub4dos to the MBR <- this will load directly grldr. BIOS->MBR (grldr.mbr)->grldr (plenty of choices, as you can see) Read the guide: http://diddy.boot-land.net/grub4dos/Grub4dos.htm jaclaz

Guess why I was talking of PLoP and "BIOS extensions"? Your BIOS deos NOT know *anything* about USB. Your BIOS does not know *anything* about that PCI card. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<-insert here somethign that wil add info about that card to the BIOS reported info DOS trusts (blindly) info that comes from BIOS. You do understand how *something* is needed on the dotted line? Now could this be PLoP? Cannot say, you need to try and see. jaclaz

Yep. Read the links I posted. Sure, as well as posting ANY other trick, advice or proper procedure. What the heck! It is "since the dawn of time" that there is XPLITE (Commercial): http://www.litepc.com/xplite.html and of course there are FDV's files (which have no limited license attached if I remember correctly) Let me try again. Someone attempts to do something. This something is done through applying procedure A, then procedure B. The result is not satisfying. The peep - being an IT technician - presumes that procedure A is the problem. Upon inspection of the procedures used a supposedly more knowledgeable member determines that the problem is procedure B, instead. I.e. there will be the SAME failure NO matter if procedure A is applied or not. Everytime procedure B is applied (since it is improper) there will be a failure. Procedure A has a limitation with license. Procedure B has no such limitations. Should I not suggest how to correct procedure B because the user has previously applied - breaching it's license - procedure A? I am perfectly OK with this approach, I didn't thought this was a policy of the board. Yeah, sure, nice attempt to preventively soften me. As well there are plenty of things I don't know and I'm not as well in the IT industry. You got it wrong , in case of war (but there is no war right now ), the difference is between right and left : About the particular issue at hand, in a perfect world an "IT technician" would wear a uniform, with a correspondent rank, like "lieutenant IT", upon public posting on a board like in this case, he would be judged by a martial court that would: downgrade him to "private IT" < for using a "non-commercial only" tool immediately discharge him (OTH) for manifest unsuitability <- for not having learned during training basic copying/cloning procedures remove from command the whatever commanding officer that actually approved the "IT leutenant" to the grade and role he so blatantly failed at. On the other hand, he posted with sincerity, without mis-representing his role and the environment he was working in, so maybe the court would show some clemency and, taking into account the fact that it is first offence : downgrade him to "private IT" < for using a "non-commercial only" tool keep him in the ranks < clemency send him to Leavenworth for three months, then back to training courses <- for not having learned during training basic copying/cloning procedures remove from command the whatever commanding officer that actually approved the "IT leutenant" to the grade and role he so blatantly failed at. Not being in a perfect world, and not even in the military, the most I can do is a stern look of disapproval: jaclaz

Care to share your view why? My point is as per post #4 - Item 1 & 5 Because the final result comes from an improper "handling" of the "cloning procedure". In other words, no matter if nlite was NOT used on the source, was used on it lawfully or was used on it in a complete and utter breach of it's license, the result would be anyway a failed logon because of the improper procedure followed when making and restoring the image(s). Or if you prefer, the issue should not even have been posted in the nlite forum, and "my" point is along the lines of post #2 - item 2 in it : As often happens the OP, being an IT technician, presumed a connection between the use of nlite and the issue he had, while there is IMHO none. jaclaz

Good. Are the current settings in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices "correct"? Meaning is the "C:\" drive (I presume that that is your "system" drive, first primary active partrition) pointing to the right disk signature and offset? It is possible that in your previous attempts of booting (with the C:\ entry pointing to the "old" disk signature) XP attempted to "self-heal" and "botched" some path to other apps, though it is unlikely. Can you try: verify HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices keys mount the Registry OFFLINE save current (if verified OK) HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices re-appply the driveimageXML file BEFORE booting to the XP the first time apply the saved HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices to the offline registry If the behaviour is the same there is somehting else that has probably it's roots in the "base" image. You can then try to reinstall and try with an actual disk image. To troubleshoot the issue, most probably the only thing that can help is running procmon at boot time. Can you run TaskMgr and check WHAT actually get 100% CPU? It may help but not necessarily will lead to the cause. Possibly unrelated, but as a rule of thumb DELL sources are normally prone to cause problems. jaclaz

I asked you a question, can you reply to it? And no, there is no way that a restore or a new applying of a driveimageXML image can solve the logon problem, you used one of the two given solutions (probably the "wrong" one). jaclaz

HOW did you fix the logon issue? (choose one): Microsoft's way of removing/changing drive letter in Registry (wrong) <- this is intended as a way to manage to log in *somehow* Correcting disk signature/Mounted devices (right) <- this is how everything should be, right disk signature/partition coupled to "right" system partition AND drive letter See also here (ONLY seemingly unrelated): http://www.911cd.net/forums//index.php?showtopic=19663 jaclaz

I would say that the use of nlite is completely irrelevant and NOT connected to the issue. NTBACKUP does a backup. DriveImageXML does an image of the drive (NOT of the disk ) Who/What/How is taking care of disk signature? http://www.911cd.net/forums//index.php?showtopic=22984 http://www.911cd.net/forums//index.php?showtopic=22984page&st=6 http://support.microsoft.com/kb/249321/en-us http://support.microsoft.com/kb/555648/en-us Or clear HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices on the OFFLINE registry. jaclaz

Hmmm, maybe you are overcautious. http://en.kioskea.net/faq/781-what-is-pci Basically you are putting a card that supports speeds of 66 Mhz Mhz on a motherboard that has a clock at 33 Mhz. http://www.pcisig.com/specifications/PCI_Family_History.pdf http://en.kioskea.net/contents/pc/pci.php3 Most (but not all) cards can work at a lower then spec clock, "normally" there is no problem, as long as they "fit" in the slot (3.3V vs. 5 V vs. "universal" slot), compare with: http://www.roalan.com/Report%20pci%202.3%20030206d1%20ro.pdf As said previously, YMMV jaclaz

Another happy bunny jaclaz

I see. Get latest grub4dos from here: http://code.google.com/p/grub4dos-chenall/downloads/list Expand with 7-zip two files: grldr menu.lst to root of your boot drive (usually C:\) Copy to root of the same drive the .iso (I will call it "acronis.iso") Add a line to boot.ini: C:\grldr="grub4dos" Edit menu.lst adding to it: title Acronis find --set-root /acronis.iso map /acronis.iso (hd32) map --hook chainloader (hd32) or title Acronis find --set-root /acronis.iso map /acronis.iso (0xFF) map --hook chainloader (0xFF) Try it. jaclaz

Can you better explain/describe what you want to do? (I cannot understand it from your post ). jaclaz

It is a possibility, only trying to find a reason for the mentioned "/A (default)", BTW DOS 7 comes AFTER NT and before 2K. jaclaz

Well, that seems to apply to MS-DOS 7. The MS resource seen before: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx?mfr=true is about XP. The one I cited seems like being NT4 and 2K "oriented": http://ss64.com/nt/copy.html (though as said it is possible that is alltogether "wrong", it does look similar to an actual output of a "COPY /?" ) Since it is not the first time that a "common" program syntax changes dramatically between one version of the OS and the other, it is still possible that NT4/2K behave differently. I have found another "hits" for " /A : ASCII text file (default)": http://www.bat-to-exe.com/batchcommands/copy.html that seem like not coming from the same SS64 source. @tomasz86 Why don't you simply try with a few files? jaclaz

Well, the most straightforward IMHO is Qemu (+Qemu Manager) stiil free: http://www.davereyn.co.uk/download.htm A Virtual Machine, besides being "Virtual" is a "Machine", sporting it's own (Virtual) hardware, so you need to have in the OS you are going to install (the XP in your case) the actual drivers for the Virtual Machine Hardware. Obviously all VM's have drivers for their hardware for XP, the advantage of Qemu is that it uses "standard" hardware for which the drivers are already inside the XP CD and you don't have to add anythng else. Please note how Qemu is/will be slower than more "optimized" VM's, like Virtualbox or Virtual PC, but in this specific case speed (or lack of it) won't be a problem, when compared to the simplified setup. The actual advantage of Virtualbox and other VM's is that it is easier with them to "exchange" data betwenn the VM and the "real" machine, as they provide some "extensions/apps" to that effect. Basically the idea is the following: you install Qemu (+Qemu Manager) you create a new virtual hard disk for it (it is a guided procedure) a size of 5 Gb should be adequate do use the RAW option as format for the virtual hard disk. you add the .iso of your XP CD as cd-rom device for the VM you select it as first boot device you start the VM and install XP in it "normally". you shut down the VM you mount the virtual hard disk through a hard disk image mounting program, IMDISK is advised for your case. you copy to the mounted disk image all you need, like nlite, the SP3 etc. you unmount the Virtual disk, start the VM and operate "normally" in it slipstreaming the SP3 and nliting whatever once you have created the .iso you test it in another VM until you are satisfied by the result Once virtual tests are OK, you burn the .iso and test it on the "real machine". jaclaz

Yes, the way the filter driver works is that one, more than the Registry device class, it would be interesting to know what happens with dd --list or Winobject. I.e. if the actual partition/drive gets something like \DeviceHardDiskVolumen or something like \Device\Harddiskm\DP(x)0-0+y Still it should mean that *somehow* the video drivers include a filter driver for mass storage. The behaviour you experienced, if I get it right, it is that of the reversedummy.sys, i.e. make an otherwise "fixed" USB hard disk become a "removable" device. Queer. jaclaz

Yep, I was not doubting it in the least , only re-marking that our good FreeDOS friends have not much "order" or "tidyness" in what they release. As soon as the good guys at reboot.pro will have finished playing with the board in order to make it "better" (please read as "ruining senselessly an otherways perfectly working setup to add some completely unneeded eye-candy" ) you will be able to have a look at what I needed to do in order to get a "right" SYS.COM. Here is a google cache: http://webcache.googleusercontent.com/search?q=cache:W6Y1ReYKsDsJ:reboot.pro/15123/ Fixed (seemingly): http://reboot.pro/15123/ After my little odissey (and probably somehow thanks to it ), the file was fixed, thanks to the good FreeDOS guy , and the current version (august 10, 2011): http://www.fdos.org/kernel/sys/ has also RX-DOS and DE (stoopid Dell RMK): About Volume track, sure , that key is useful to set it in "your own" Win9x/Me, I was trying to say that most people won't have it, and thus you can easily get an image (or bootsector) with "absurd" OEM field contents (and the original MS floppy image mixup is a proof of how common this can be, basically any "MS-DOS floppy" made on XP the "standard way" will have such a botched OEM). jaclaz

Since you have the original XP CD and it's key, advised is to temporarily install it on any VM (for some reasons I use Qemu+Qemu Manager, but any of Virtual PC, VmWare, Virtualbox, etc. will do nicely as well) and do all slipstreaming and nlite operation in the VM. (you don't actually need to have SP3 installed to the VM, your plainSP2 will do nicely). Then, test the the result in the VM first. jaclaz

Yes/No. I just tested, see here: http://reboot.pro/15123/ the FreeDOS and it has another OEM name, FRDOS4.1. You can call the 2nd sector whatever you want , but if the theme is "making a filesystem from scratch" you will have to create the 2nd sector too. About the OEM field being part or not (it is not) of the BPB (already cited): http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/volume-boot-block-oem-name-field.html the issues are TWO as I see it: some boot code will check it nonetheless the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names a good example of the latter is the DOS 8.0/WinME floppy embedded in XP/2003's diskcopy.dll: http://www.911cd.net/forums//index.php?showtopic=16745 I have no idea if it can happen that it creates non-batch compatible string (like one containing ! or & or <>, etc.) Stiil trying to get an agreement: Size in sectors (small-16) Size in sectors (large-32) or Number of sectors (small-16) Number of sectors (large-32) (just to be homogenous with other field names, you don't have "Total FAT(s)" or "Total Heads" ....) jaclaz

Do you mean that *somehow* on that machine the video drivers change the way a mass storage filter driver works ? I am presuming you are using one of cfadisk.sys or dummydisk.sys) Maybe they are not "just" video drivers? jaclaz

Yep. Most probably you will also need some other drivers integrated. DriverPacks: http://driverpacks.net/ provide a "wide range" of drivers (but of course size of install media will grow). Or you can use nlite to integrate the single drivers that you need for your laptop. About SP3, I would integrate/slipstream it manually before adding the drivers. Remember that Rule #1 of nlite is: NEVER run nlite using as source the result of a previous nlite session, always start from an "untouched-by-nlite" source and do everything in one "pass". jaclaz

FAT32 has actually three of them sectors, but I thought we were (at the moment) inside the FAT12/16 realm. With FAT32 we additionally have the "third" sector being in "variable places", namely, for the ones I remember: MS_DOS sector 2 NT sector 12 ReactOS 14 Summed up here: (I presume - but haven't checked - that FreeDOS is similar to MS-DOS) Using an MD5 or even a simpler algorithm is OK, I don't think we will ever have enough samples to have even a minimal possibility of a collision. Personally I think that zeroing out a number of initial bytes in the sectors is not the "right" approach. Why not simply have: the original bootsector(s) copy. apply to it a .ini with all the values we will change, exception made for: Jump_Bytes OEM_String System_ID Magic_bytes set to 00's? jaclaz

You really should fix your google http://gsmartcontrol.berlios.de/home/index.php/en/Home http://gsmartcontrol.berlios.de/home/index.php/en/Screenshots jaclaz

Yes, it is "innatural". Both "Start_Sector" and "Sector_Offset" are both better, the "Sectors_before" comes from the same comparison about different "partition related tools": http://jaclaz.altervista.org/Projects/USB/USBstick.html SectBefore StartSector Sectors Before Relative Sectors Starting I find it a plain English way (without entering in the detail tha LBA sectors are numbered from 0) to describe what the field should contain, still in the "hard disk" world, the LBA start address is the number of "sectors before" and: TotSectors NumSectors Sectors Total Sectors is the number of sectors in the partition, corresponding to either of the two fields "Small_Type_Sectors" and "Large_Sectors", where also as seen before there is not yet an univocal agreement: @dencorso The idea of the .ini has several "goals" have a "standard" way to exchange "complete" information about such images/formats. As we have seen in this an similar threads it is easy to forget "passing" a parameter (like the number of "ROOT" entries) and often sources you can find miss this or that detail a .ini file (besides being parsable by *anything*, including batches ) can be posted "as is" on the board or inside an e-mail, or whatever using a .ini the spreadsheet could output such a .ini and one could use a "generic" batch or program to simply load the .ini settings, being it "plain text" it could be easily modified/tweaked without any spreadsheet app and without actually changing values in the batch, everyone could write his/her own little program to read the "common format" .ini and produce the image, adding also features like "full", "truncated" and "sparse" (this could be "cross-platform") another operation that could be done through an "extension" of the app could be replacing what bootpart does (with a number of limitations) and/or correcting the "Sectors Before" to make logical volumes inside extended bootable, the use of the .ini would be a way to put down all data needed when performing this "kind" of operation and then each program may take from it only what is needed and there could be an app that dreates the .ini from an existing volume or image additionally, in situations like the "flashing cursor" or "j in top left of the screen" the user asking for help may run a little app to create the .ini and post it, and it would be a breeze to troubleshoot the issue... the thing I find more needed is the actual image naming convention (the actual "section" of the .ini) as I often (please read as "always") find myself with a bunch of images with a name that give no hints of their contents, if we could devise a way of naming that would give a hint of the way the image was made, it's size and "contents" (in the sense of boot code in it) it would solve or mitigate this problem, and I am pretty sure I am not the only one having it jaclaz

Well, the idea was to give you the hints, not doing your tests.... What happens with: FOR /F %%I IN ('^>nul DIR/A-D/B HFMER 2^>^&1') DO ( jaclaz