jaclaz

Just for the record, and to keep things together as possible, here is an interesting thread on 911CD about using parameters passed to memdisk into autoexec.bat, in case you are using DOS based floppy images: http://www.911cd.net/forums//index.php?showtopic=5706 just a few days ago the thread was revamped: http://www.911cd.net/forums//index.php?showtopic=19634 with contributions (hopefully enhancements) by d4vr0s and yours truly. jaclaz

From what you report it appears to me like a bad port on the motherboard or a bad cable. Try changing the cable first. Double check that hard disk is properly identified in BIOS, if it's not there is no way you can install/boot from that PC. jaclaz

No, sorry, but the way you describe can potentially lead to much greater problems. There is NO such thing as a "safer" way, as well as there is no "better" way, it all depends on what you need/want to achieve, but using third party bootmanagers, expecially if installed to MBR is, rather obviously, a deviation from "standard" and, as thus, can potentially lead to incompatibilities with other utilities that assume that the given "standard" is respected, statistically this is the MOST RISKY situation you can have. On the contrary, more than 12 years of experience with NT based systems, confirm that installing on a logical volume inside an extended partition, as Gilles Vollant recommends: http://www.winimage.com/bootpart.htm keeping "standard" MBR and NTLDR, is a VERY safe way. You might want to read this for further considerations: http://www.msfn.org/board/index.php?showtopic=33964&st=6 Though this is possible, a word of WARNING is needed, changing the SYSTEM drive letter can (and will) render the system UNBOOTABLE. If you ever want to attempt such, BEFORE doing it, do read this and related links: http://www.msfn.org/board/index.php?showtopic=90495 jaclaz

Nothing really universal, unfortunately. Some possibilities exist, though: http://www.boot-land.net/forums/index.php?showtopic=808 jaclaz

Sorry, fly, crossposting. It is perfectly normal, the VALUE of "KEY" is %USERPROFILE%\My Documents\, you need to transform it before: ECHO %KEY% CALL SET KEY=%KEY% ECHO %KEY% jaclaz

I re-checked, the token appears to be 3*, not 2* , however it still does not work with /v syntax @dexter yes, you are right, the line without "delims= " works allright. Can anyone try running this?: @echo off CLS SET KEY= :: delims is a TAB FOR /F "tokens=3* delims= " %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal"') DO SET KEY=%%K ECHO KEY1 IS %KEY% ECHO. SET KEY= FOR /F "skip=4 tokens=2*" %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /v Personal') DO SET KEY=%%K ECHO KEY2 IS %KEY% ECHO. SET KEY= FOR /F "tokens=3*" %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal"') DO SET KEY=%%K ECHO KEY3 IS %KEY% ECHO. SET KEY= FOR /F "skip=4 tokens=3*" %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /v Personal') DO SET KEY=%%K ECHO KEY4 IS %KEY% ECHO. SET KEY= FOR /F "tokens=2,*" %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /v Personal') DO IF %%K==Personal SET KEY=%%L ECHO KEY5 IS %KEY% ECHO. What I get is the following: i.e. "odd" keys (using "my" and "dexter's" code) do work, while "even" ones, based on the /v syntax, do not, #2 gets, as said above the wrong token, #4 gets last item and NOT the right one. jaclaz

No prob, mate. Do report if everything is working as expected.... jaclaz

It DOES look nice , did you try it? jaclaz

hmmm, just for the record, REG.EXE is not "default" on Win2K, you have to install it expressly. However, on my Win2K the /v syntax appears not to be working, this one does: @echo off REM FOR /F "skip=2 delims=~" %%K in ('REG QUERY ^"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders^" /v Personal') DO SET KEY=%%K :: delims is a TAB FOR /F "tokens=3* delims= " %%K in ('REG QUERY "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal"') DO ECHO %%K jaclaz

It seems like those errors appear when something is "not right" with the hard disk: http://support.microsoft.com/kb/271240/en-us More specifically, this seems exactly that error you report: http://www.computing.net/windows95/wwwboar...rum/164732.html Have a look at this also: http://www.smartcomputing.com/editorial/ar...05l06/05l06.asp Maybe you can use some switch of Setup to avoid the problem. jaclaz

@All Joc asked me if I could help him in making a dual boot cd with GEEXBOX + XP SETUP. Here is the resulting "HOWTO", GEEXBOX uses the ZFS ISO filesystem, this needs a -z parameter for mkisofs that appears to be somewhat incompatible with XP cd. The workaround is to uncompress the GEEXBOX .iso and re-build it uncompressed, since original .iso is very small, around 8.5 Mb, the uncompressed version is not much bigger, around 9.5 Mb. In the following I used grub4dos, or to be more exact grub4dos's grldr as bootselector, but I guess that making the same with CDshell, BCDW or isolinux should be possible as well. 1) download Geexbox Generator: http://geexbox.org/en/index.html http://www.geexbox.org/releases/1.1-rc2/ge...rc2.i386.tar.gz 2) download grub4dos 0.4.2: http://grub4dos.jot.com/WikiHome http://grub4dos.jot.com/WikiHome/grub_for_dos-0.4.2.zip 3) install generator normally, use it to generate a .iso for your system 4) test the .iso, loop to #3 until you are satisfied with result 5) copy and paste the following into a new file geexbox-generator-1.1-rc2.i386\geexprep.cmd @ECHO OFF CLS ECHO Small batch to extract a GEEXBOX ZFStree to uncompressed tree SET Root_dir=dualboot SET ISO_dir=dualboot\MYISO SET Source_dir=dualboot\origISO\GEEXBOX SET Base_source_dir=dualboot\origISO SET Dest_dir=dualboot\MYISO\GEEXBOX ECHO. ECHO SOURCE tree is %Source_dir% ECHO. ECHO DESTINATION is %Dest_dir% ECHO. PAUSE :START IF NOT EXIST %Root_dir% md %Root_dir% IF NOT EXIST %ISO_dir% md %ISO_dir% IF NOT EXIST %Base_source_dir% md %Base_source_dir% IF NOT EXIST %Source_dir% goto :error IF EXIST %Dest_dir% ( CLS ECHO The directory %Dest_dir% and all it's contents will be erased. RD %Dest_dir% /S ) ECHO NOW the tree will be extracted.... PAUSE tools\win32\mkzftree -u -v %Source_dir% %Dest_dir% PAUSE GOTO :EOF :ERROR ECHO YOU must copy the GEEXBOX folder and all it's contents to \dualboot\origISO\GEEXBOX PAUSE 6) run geexprep.cmd it will prepare the directory tree and exit with an error, ignore it and go on 7) mount the .iso as a virtual CD or however copy the entire Geexbox folder from the working Geexbox CD to \dualboot\origiso\ 8) extract from the grub4dos archive the file grldr to \dualboot\myiso\ 9) copy and paste the following into a new file \dualboot\myiso\menu.lst # Following lines load a splashimage and set text foreground/background colour splashimage /GEEXBOX/usr/share/grub-splash.xpm.gz foreground = 69ee44 background = 337722 timeout 10 default 0 title GEEXBOX kernel /GEEXBOX/boot/vmlinuz root=/dev/ram0 rw init=linuxrc boot=cdrom remote=atiusb receiver=atiusb keymap=qwerty splash=silent vga=0 video=vesafb:ywrap,mtrr initrd /GEEXBOX/boot/initrd.gz title XP SETUP chainloader /I386/SETUPLDR.BIN Please note that these are the settings I needed to use to make Geexbox work on my QEMU, you might want to revise the kernel parameters by checking them against the correspoding ones in \dualboot\myiso\GEEXBOX\boot\isolinux.cfg, here is MY line: APPEND initrd=initrd.gz root=/dev/ram0 rw init=linuxrc boot=cdrom remote=atiusb receiver=atiusb keymap=qwerty splash=silent vga=0 video=vesafb:ywrap,mtrr 10) copy and paste the following into a new file geexbox-generator-1.1-rc2.i386\makeiso.cmd @ECHO OFF SET CDTITLE="Dual Boot" SET CDFILENAME="dualboot\MyCD.ISO" SET SOURCE_DIR="dualboot\MYISO" tools\win32\mkisofs -v -iso-level 4 -l -D -d -J -joliet-long -R -volid %CDTITLE% -A GRLDR/MKISOFS -sysid "Win32" -b grldr -no-emul-boot -boot-load-seg 0x1000 -allow-multidot -hide boot.catalog -o %CDFILENAME% %SOURCE_DIR% 11) run again geexprep.cmd, this time it will give you no errors 12) run makeiso.cmd 13) test the resulting mycd.iso, the option for Geexbox should work as on the original .iso 14) now get your (working) BartPE or XP cd, copy from it the (at least) \I386 directory (and all its contents) to \dualboot\myiso\ 15) copy all the files on the root of the CD to \dualboot\myiso\ 16) run again makeiso.cmd 17) test the resulting mycd.iso, both options should work As always, please do respect my "CAREWARE" license: http://home.graffiti.net/jaclaz:graffiti.net/careware.html and have fun.... jaclaz

FYI, NTFS4DOS (FREEWARE): http://www.free-av.com/antivirclassic/avira_ntfs4dos.html jaclaz

@ilko_t Maybe one could use this method: http://www.msfn.org/board/index.php?showtopic=12566 to execute commands when the GUI part starts. In the post it is reported that, while regedit.exe doesn't work in this stage, reg.exe does. jaclaz

(hopefully) some ideas to solve this part of the problem: I doubt that partition table gets corrupt. The MBR code is replaced, that's all. It should be quite easy to work around the problem (from the beginning, INSTEAD of your step #2): 1) DO NOT install grdr.mbr 2) Install normally the XP MBR and bootsector (i.e. do nothing, the HP utility will do it) 3) add to root of the stick GRLDR 4) add to root of the stick NTLDR 5) Add to root of the stick a BOOT.INI like this: [Boot Loader] Timeout=10 Default=C:\GRLDR [Operating Systems] C:\GRLDR="Start GRUB" This way grub4dos is chainloaded through "normal" NTLDR. Also, you don't need to rename setupldr.bin to ntldrstp. jaclaz

Moreover, you can use a CD bootloader like BCDW or grub4dos as no-emulation boot sector of the cd (with grub4dos you can also make the boot floppy). Between its features it has the ability to directly chainload setupldr.bin. Search on the 911CD forum for posts by me (jaclaz), spacesurfer and diddy with keyword "grub4dos", you'll find a number of tutorials and lots of info. jaclaz

Maybe it is not an "invisible folder" it is an "invisible partition", or at least sort of, it could be a particular kind of .iso where an entire bootable filesystem is written in the bootable sectors, or it could be an image of either a filesystem of a CD inside a monolithic file that is mounted at booting. I cannot say more without knowing the exact application that is used, is this the one program?: http://www.ntfs.com/boot-disk.htm If it's this one, I did look at the trial version: http://www.ntfs.com/downloads/boot-cd-iso.zip it appears to be a "normal" El-torito emulation bootCD with an image of 2.880 Mb floppy as bootsector. When you boot from the CD, the "hidden" files are not hidden at all, the floppy image is mapped either as A: or B:, and the files within it are normally visible. A small reference is here: http://forum.winimage.com/viewtopic.php?t=2454 Search with google for "el-torito" and you'll find several informative articles. A word of warning, though, referencing to "files downloaded from Rapidshare" and to "Hiren's", could mean WAREZ which are a NO NO on this board: http://www.msfn.org/board/index.php?showtopic=18408 jaclaz

Yes, that would be nice, but right now I have no idea on how to do it, unless we cycle to another menu.lst through the "config-file" command, but I cannot see at the moment how to conditionally do that. If I remember right, there is a feature like this in "Linux" grub, that uses variables, there is this guy, Adrian Raulete, that made this "Grub superdisk" or something like that. It uses this feature to make a very complex multilevel boot menu but last time I played with grub4dos it didn't have this feature, or at least I wasn't able to make it work. I'll have a look at the idea and see if something comes out. Well, that should be the easiest thing, it should just be a Reg file merged at the end of GUI setup or, if you prefer, on first "real boot" of the newly installed OS. I am not an expert at all on this but in one or the other "unattended" sections of the board there is info for this. Maybe cdob might help on this particular thing. jaclaz

Problem might be if the destination drive is formatted as NTFS, one could put up a triple boot on the stick with DOS files and this utility: EditBINI™ This utility will allow you to edit \BOOT.INI in an NTFS partition from DOS or Win9x. http://www.terabyteunlimited.com/utilities.html But if the path to the drive is wrongly hardcoded into $winnt$.inf, one would need to use NTFS4DOS, which is free for PERSONAL USE only: http://www.free-av.com/antivirclassic/avira_ntfs4dos.html to access the NTFS drive from DOS. Personally, besides licensing problems for Commercial users, I always prefer the simpler solution so I guess the above could only be an "extreme" workaround, if nothing else work. I didn't get if you completed the install and if you got with the the correct C:\ letter on the hard disk (without migrate.inf). I guess that the setup re-scan the systems and gets again the "HardDisk0" and "HardDisk1" directly from Bios, bypassing the "temporary patch" made by grub4dos. In a couple VM I tried, the TXT mode map (hd0) (hd1) map (hd1) (hd0) map --hook .... works allright, most probably one could prepare instead of a pair of menu entries, several pairs, to allow for "strange" BIOS behaviour... jaclaz

Yep. if the image is somehow doubled, the fond --set-root won't work, as devices are scanned in order.... A lot of info is coming out from your experiments, I'll have to study it a bit and do some more tests myself...continue reporting... jaclaz

Well, who put ntldrstp on the HD? However in this case (on the stick that is prepared before) one can use another file, such as menu.lst, or in "find --set-root" command or directly a "special" marker file, simply open notepad, and save the file as USBOOTME.1ST on the stick.....,"find --set-root /USBOOTME.1ST" will not possibly get the "wrong" root. hmmm, it is possible that the laptop BIOS has some incompatibilities with grub4dos. What happens on the laptop with the "alternate method": You can try, issuing single command lines from the command line, one by one, grub4dos in this case is more "verbose" and one can hopefully pinpoint the single command that causes an error. jaclaz

OK, so definitely we need the SETUPLDR.BIN and NTDETECT.COM on root. A possible "definitive" way out could be: In the second item if ntldr is found on both disks, it could maybe cause problems, one could use another file as a marker even if it is found in a subdirectory, the "root" will be to the drive, I am not at all an expert in this, but if one cannot find a file that is on the HD and not on the stick, it should be possible to create it with some entry in TXTSETUP.SIF or similar. Also, maybe there is something "between the lines" of this: http://support.microsoft.com/kb/312569/en-us (if we can find an alternative to the "loong" wait and/or the extraction and reinsertion of the key, we would have a potential "unattended" method) jaclaz

VERY GOOD. Also, try with "root" instead of "rootnoverify".... jaclaz

@ilko_t VERY good! It seems like we are almost done. I guess most of the merit has to go to cdob, whose help and knowledge has been decisive, and to porear whose contribution of ideas and testing was fundamental. While the first of your menu.lst entries does make sense to me, I am still curious how the second one works, as I see it things must have some logic behind, if BOTH the entries work, this: should be also working if rewritten as: by the same principle, viceversa, the entry: should work as well if rewritten as: As said, the final boot command is unnecessary, and it should be possible to replace: with: to avoid copying SETUPLDR.BIN and NTDETECT.COM to the root of the stick. And, besides, once you have issued a root or rootnoverify command, root is established, and you only need the forward slash, i.e. : should be functionally equivalent to: (as in the second menu.lst entry) I would be nice if you could test the above and make a new post with all steps together, something one could post a direct link to, to avoid other members to jump forward and backward on this longish thread, as is it is causing me headaches, and I already now most of it. jaclaz

Won't good ol' REG.EXE be enough? http://www.microsoft.com/resources/documen...g.mspx?mfr=true http://www.robvanderwoude.com/ntregistry.html http://www.robvanderwoude.com/ntregquery.html Or maybe REGFIND? http://www.petri.co.il/download_free_reskit_tools.htm The win2k version should work allright on XP, with only a minor glitch, easily fixed: http://www.jsifaq.com/SF/Tips/Tip.aspx?id=6003 jaclaz

@brucevangeorge Start from here: http://www.msfn.org/board/index.php?showtopic=81788&st=6 http://www.msfn.org/board/index.php?showtopic=61384&hl= http://www.msfn.org/board/index.php?showtopic=86946&hl= jaclaz