ilko_t

Lets try. Boot from USB again. Press "c" key when the menus appear. This will get you in grub4dos command prompt. Then type: map (hd0) (hd1) map (hd1) (hd0) map --hook find --set-root --devices=h /ntldr chainloader /ntldr boot What does it return after "find --set-root --devices=h /ntldr"? Does the GUI mode start after "boot"? Another way- just boot from the internal disk after Text mode/First part. What happens then? How many internal disks do you have attached?

Can you figure out what the text is? What happens if you start the second part again, without going through the first part? Just select again the second part. What do you mean?

Start from scratch. Reformat the USB disk. Use the latest beta7. Do the changes mentioned in the first post next to the download link. Try on real hardware. Reports any errors with details.

If it works in QEMU then it should work on real hardware. I have no clue how and why you test in VMWare. You are not supposed to edit that line in txtsetup.sif, it's auto edited by the boot grub4dos script, and modifying it would lead to results like the ones you got. Actually, what's the point of your experiments? Are you just experimenting, or need to perform an installation on real hardware?

WinSetupFromUSB has an option- Test in QEMU. What happens if you select and use it?

I would start by reading the first post. Haven't heard about 1.ISO, can you give some clues? Sorry, this topic is about WinSetupFromUSB. Please open a new one describing what exactly you did.

What worries you?XP x64 is supported. Download latest version 1.0 beta7, read the notes in the first post next to the download line, select your sources, XP x64 and 7 in one go, press GO. Do the changes mentioned in winsetup.lst so you don't have further issues after the first install. That's it.

There is no need to use DPMS.ISO, DPMS.BAT should be enough. The point was that DPMS.BAT accepts parameters, e.g. /DPMS.bat 1map DPMS floppy to fd1 /DPMS.bat 0map DPMS floppy to fd0 /DPMS.bat 2map DPMS floppy to both fd0 and fd1 I've tested the above, with "/DPMS.bat 2" two floppies are created, fd0 blank or with unreadable contents, and fd1 with the drivers. The unreadable contents of fd0 are either a trick yet to be revealed, or a bug, or the parameter is expected to go along WINPE one. There is also a switch WINPE or winpe, put first if present, which causes only driver files to be copied to the floppy. Similar to 0xff, BIOS CD number- 0xff=255 decimal, 0xdf = 223. 0xdf must have been picked as likely to be available one, as 0xff or hd32 are typically used.

It seems a parameter can change the behavior: http://bbs.wuyou.com/viewthread.php?tid=197550 http://translate.google.com/translate?u=http%3A%2F%2Fbbs.wuyou.com%2Fviewthread.php%3Ftid%3D197550

Glad you got it sorted. By the way, you must have missed an important step: You either did not recreate the USB disk and change the lines and winsetup.lst, or did not : and change the lines and winsetup.lst Nope. If you prepare the USB disk and immediately change the lines in winsetup.lst then it's all good.If you already used the USB disk on computers with more than 2 internal disks, do the above mentioned steps- TXTSETUP.SIF + WINSETUP.LST, or recreate the USB disk and immediately change the lines in winsetup.lst only. Working on new version with a lot of fixes and changes, so meanwhile, apologies for any inconvenience caused by this bug.

Then you have some other problem. Because installer used in up to 2003 incl. is poorly documented and ancient, since times when not only USB boot was not possible, but USB was not even out. Thus USB has never been kept in mind. Open source? If Microsoft have published Windows code it probably would have been much different. But that's another story. Mostly by giving proper information what exactly the errors are and when they appear. When exactly and what error code? The easiest thing would be to start from a scratch. Reformat the USB disk and prepare it again. Replace the files and lines mentioned. Report what errors do you see and when exactly. I am thinking that BIOS sees the USB disk as a superfloppy/zip disk, hence the problems. But let's first rule out any interventions. What hardware are you installing to? Motherboard or laptop model? Using what USB disk?

Not saying because you are newbie, I don't even have a slight idea how newbie you possible could be reading only a few lines of yours, nor can I judge. Even the idea is very good. Lets put it this way- you have an issue, and you have a good idea how to boot the second part of setup, eliminating the need of boot.ini/ntldr/ntdetect.com on the USB disk. Let's focus on the issue first- the start with, go back to the default behavior, leave boot.ini/ntldr/ntdetect.com alone on the USB disk and boot ntldr as the default and take it from there, eliminating any possible user interventions. Once resolved, move to the good idea, test it with various ntldr/ntdetect.com versions and computers, confirm if that doesn't mess up disk enumeration later on and we are good to say "hey, that's a brilliant and working idea!". For now, for me, it's just a good idea, which in my slowly precessing and conservative mind needs time to bloom Not necessarily. If you have the willingness to troubleshoot the problem you have, here we are, all yours.But you will have to forget what you have in mind, and just follow the advices given. Sounds reasonable? Or are you giving up only because there was no quick answer do A and all is good? There is also a much newer beta versions with lots of improvements over the previous versions, the first one having no requirement to boot from USB twice, and being beta only because the method of installing is relatively new and not that long tested.

Which version of the program have you used? I guess 0.2.3, right? Let's stand correct, it's windows throwing an error, for a reason yet to be determined. Windows handles USB flash and hard disks in a different way. In addition, USB hard disks have a spin-up time as well as power saving functions which may cause a critical delay when accessing the disk. Well, don't, that seems quite wrong with unpredictable results, despite the fact it might have worked for you.Stick to tested and supported method of booting, to start with.

Is this a customised source? Do you boot for the second part from USB again or directly from the internal disk?

You may try a newer PLoP version from here: http://download.plop.at/files/bootmngr/plpbt-5.0.14.zip Replace plpbt.bin with the one from the archive.

The art of grub4dos, part III...

Thanks, that's a wonderful soltution. I like this.What about using file name %~pnx0 as tag file echo Locating %~pnx0 find --set-root --devices=fh %~pnx0 Perfect! Can you help with PLoP detection? Maybe I should open a new thread for that... I couldn't reliably detect if 5.0.13 was loaded in order to avoid messing with hard drives afterwards. For example "find --set-root /file" after PLoP was loaded from USB causes a hard hang on the two computers I was playing with. The reason is that grub4dos tries to access a "phantom" hard drive. USB disk is hd0, internal becomes hd2, hd1 is something messed up, existing but not accessible. Author is aware of the problem, but when would be fixed is unknown: http://forum.plop.at/index.php/topic,165.msg1493.html#msg1493 http://forum.plop.at/index.php/topic,151.0.html Not to mention that in a few cases simply loading PLoP from USB and find --set-root afterwards something went wrong with the partition table (I guess) on the internal disk, and after reboot from the local disk bootmgr started complaining about wrong boot configuration so had to rebuild the BCD store. Quite bad behaviour which has to be avoided.

In order to shift hard disk positions this unfinished batch could be a start base for a solution. I've been testing and using it last few weeks and it surprisingly seems to work somehow. Now with batch scripting support in grub4dos it's way easier than before. It might need some cleaning up. Reason behind detecting 5 or more internal disks was hinted by Tinybit here: http://reboot.pro/12449/page__view__findpost__p__108897 grub4dos has currently 8 map slots, unless something changed in the last versions- I used max. 5 slots for hd shift, so reserved are 2 for floppies and 1 for mapped ISO. shifthd.zip

For everyone using 1.0 beta7 version of the program and already put Windows 2000, XP, or 2003 source(s) on USB disk- a quick bug fix before the next version is ready. There are a few lines in winsetup.lst to be edited to avoid possible "I/O error...." errors at the very beginning of Text mode. The error would come up only if you previously started one of your Windows 2000/XP/2003 setup sources on computer with 2 or more internal hard disks and use the same setup source on a computer with different number of internal disks. This happens because BootDevice and SetupSourceDevice values in TXTSETUP.SIF in the small ISO file got permanently changed to new rdisk(X) values, thus consequent search for rdisk(1) & replace with rdisk(Y) will fail as rdisk(1) has been set to other value, according to the number of the hard drives connected in the previous boot of this menu entry. In other words- Setup will be searching for its files in the wrong disk and will throw an error that the disk is not accessible. Edit in root of the USB disk winsetup.lst in Notepad and change the line: map /WINSETUP/_ISO_FILENAME (0xff) || map --mem /WINSETUP/_ISO_FILENAME (0xff)where _ISO_FILENAME will vary according to your source, to: map --mem /WINSETUP/_ISO_FILENAME (0xff) map --e820cycles=3 Also replace GRLDR file in root with the one in this archive: http://grub4dos-chenall.googlecode.com/files/grub4dos-0.4.5b-2011-12-30.7z You need only the GRLDR file from the archive. If you already are experiencing the "I/O error", you may recreate the USB disk, or edit TXTSETUP.SIF in all present small ISO files in WINSETUP folder using UltraISO or a similar program and change all occurrences in SetupData section from rdisk(X) to rdisk(1) where X will vary. Next change the above mentioned lines in winsetup.lst to avoid further issues of this sort.

What can be the reason? Did you use PLoP boot manager entry before launching Setup?Do you have other USB disks or mass storage devices attached? Have you used that USB disk and Windows Setup on a computer with 2 internal hard disks?

Don't. Just copy SetupORG.exe as it is to its place in the virtual floppy- \setup\I386\. That's the original MS setup.exe which is needed and cannot be included because cannot be redistributed.Compare:

@danafik Compare: What happens if you do not press F6? Is there a single driver in the floppy? There is new far better and universal approach by one of the grub4dos developers Chenall- DPMS, look at cdob's post: http://www.911cd.net/forums//index.php?showtopic=24480&view=findpost&p=169525

The autounnatend.xml method does not need and wim editing, read this and below for details: http://reboot.pro/9076/page__view__findpost__p__123792 If there was wim editing involved, there are better methods. Dism isn't stand-alone, there are several other files involved. One cannot redistribute them freely. Another problem is where to obtain them from- if it's 7 source- one could be using XP 32-bits and has 7 x64 source. Is 32-bit version of the wim drivers included in 7 x64? What about using XP 32 and modifying Vista x64? There is no Dism, back to imagex plus there are no 32 bit drivers for the wim mounting. So we are back to WAIK...

I've been digging in this direction for a long time without a solution which suits my needs... There are several methods for having multiple Vista/7/2008 in same partition: 1) Edit boot.wim and add whatever script you want to be launched. 2) Edit boot.wim, add Firadisk or WinVBlock 3) Edit install.wim and add include other sources 4) Use changed on-the-fly autounattend.xml in root of a removable USB disk to tell Setup what to do 1,2 and 3 need to mount wim, that's pain in the @$$, need either WAIK or 7 source. I won't force a regular user to download and install 1.7 GBs WAIK. There is no yet free and legally redistributable solution which can mount and edit WIM files, at least I am not aware of such. 7-zip was a good bet, but author is not interested in going too deep into the wims: http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/4072972 4 has the limitation that USB disk has to be removable, or Setup won't use autounattend.xml. Thanks JFX, appreciate it.

@danafik Thanks, that helps a lot, indeed. @laddanator You have figured it out, some tired man stole the map --hook line