ilko_t

You can try to disable them in BIOS, or switch them to SATA mode and make sure your source does not have such driver. Setup cannot decide properly where to install boot files and check and overwrite MBR and bootsectors if needed, if other disks are present. Your best bet is to not let installer see any other disks. Linux installer typically would ask you where to put the bootloader and such, but Windows decides for you, and it gets confused, especially in a non typical for it scenario. What do you mean? In all recent versions, from the 4-5 years, there is only one boot from USB needed when using WinSetupFromUSB. The second boot from USB is optional, in case an user needs unattended installation and computer is set to boot from USB, so it automatically selects the second step and continues. Whether you boot from the internal disk or the USB for the second part of Setup, as per Microsoft's design, in a typical scenario, wouldn't matter. With other tools and methods you might have to boot again from USB and launch some commands first, detailed answer would be much longer. You might, but next you will be asking how to make an universal XP installation running on different hardware, which might get tricky. I happen to develop it, but can't understand what you mean by ""Install portable on [ H:\.... ]".. Do you mean to just replace XP Setup and another program to install Windows on a destination disk? Well, good idea, unfortunately XP (2000 and 2003 as well) Setup is not that easy to replicate, not at all. And what you are asking is possible with very few operating systems, bypassing their installer completely. Keep in mind that XP installer is very old, dating back from the NT4 times (almost 20 years back) with very minor changes since then, when USB didn't even exist or was just in a very early stage of development and adoption, in case you wonder all this workarounds and mess.

Testdriver, you need to make sure the advanced option mentioned above is selected when preparing the USB disk. It was introduced in beta8 and present in all later versions. In addition- you do need to disconnect all other disks, internal, external, whatever, but the prepared disk which would be also a target disk.

Use latest WinSetupFromUSB from my signature, prepare only the disk you need Windows installed onto with the Setup files, selecting the advanced option "Prepare Windows 2000/XP/2003 to be installed on USB", details in the FAQ page there. Disconnect all other disks and install onto the same one you are booting from without formatting it during setup. Use USB2 ports only. This was tested with 32 bit XP, can't recall 64 bit tests, been a while. Let us know how it goes.

Most likely the WPI script needs files from the DVD/source directory, but the ISO is mounted and available only during the PE stage. What you can do is to move the files WPI needs to the relevant \sources\$OEM$ folder in the ISO so they are copied to the destination disk during the PE phase. You might find those extra files and figure out their destination by comparing yours with an original ISO for example. I can't provide more details without knowing what exactly the custom scripts in your source do and expect.

After restart does wpi start and continue without errors? Does this happen if using the previous 1.0 beta8 version or from a DVD, which uses flat files sctructure and source is copied as is? Does the wpi script search for files on the DVD?

The partition is already listed by the kernel and available, it's the init scripts ignoring it because it doesn't match certain pattern, and partition ID is not part of it. For the record, discovering and listing disks and their partitions in the kernel seems to happen in /block/genhd.c.

I was more interested about the init scripts which mount the fake partition, because that's where booting in such way may fail, and because Linux is way more flexible and doesn't really care much if mounting block device, a file or contiguous space as marked in the partition table. Mount utility seems to do fine its job as long as it recognises valid FS and kernel/udev scripts list the fake partition as a valid device in /proc/partitions for example to be in the list. From what I found so far, the various Linux distros handle searching for and mounting the needed CD-ROM in different ways in their init scripts. Debian netinst for example makes use of two binaries cdrom-detect, cdrom-checker, and a shell script list-devices to handle all that. Once candidate devices are discovered according to certain criteria, they are passed to mount to be checked for the tag files, and mount does not care if the device is a whole disk, partition or a file, just attempts to mount it using all known file systems, or cdfs if explicitly passed as argument. ISO mounted as a fake partition is not found and used for example if using USB hard disk. In case of USB flash drive, no matter removable or fixed type everything is fine. Apparently somewhere along the lines devices which are (on) USB hard disks are excluded. devices="$(list-devices cd; list-devices maybe-usb-floppy)" for device in $devices; do if try_mount $device $CDFS; then break 2 fi done devices="$(list-devices usb-partition)" for device in $devices; do if try_mount $device $CDFS; then db_set cdrom-detect/hybrid true break 2 fi if try_mount $device $FATFS; then db_set cdrom-detect/usb-hdd true break 2 fi done .... try_mount() { # TO REMOVE, there is a bug somewhere in the kernel, the first # mount command fail when changing floppy disk # so we have to launch mount twice mount $1 -tauto $MNT || true umount $MNT || true mount $1 -tauto $MNT media_mounted && checkcontents $MNT } ... Puppi Linux Slacko 5.6, uses probepart_init in the init script, which when listing all partitions uses /proc/partitions to make the list. The regex returns our /dev/sda4 too, which later on will be passed to mount and mounted eventually as CDFS. Slackware (14.0) uses hardcoded device list - /dev/srN, /dev/hdX, /dev/pcdN etc, mounting the fake partition fails, it does not expect CDFS on a partition. Trinity Rescue Kit searches in /proc/partitions for the given volume label using mlabel, which fails since it seem to expect partition with vfat file system. Luckily, most other distros search in partitions for their files and when passing each possible partition to mount it succeeds mounting it as CDFS.

My impression was that the isohybrid part actually tricks Linux to mount contents exposed such way, so they are accessible. Just completed some tests with regular and isohybrid-ed variants of the same Linux images and they both worked the same way, thanks for the clarification, in this case compatibility is even better. Actually the most of the recent Linux distros come with isohybrid-ed ISOs, at least all of the 30-40 various popular distros checked some time ago when I was playing with this stuff. Never suspected or hinted that Easy2boot modifies them, since they already come isohybrid-ed, and I am also using this method in WinSetupFromUSB in all recent versions. Anyway, thanks for the heads up. Now since you brought me back to this subject, I am curios which part/script of the boot process actually is responsible and eventually are we all just lucky using a design flaw/bug/coincidence/just happens to work, or it's intended behaviour.

It's helpful you to be around and be picky, nothing bad. Please correct me if I am wrong- I got the impression that if the ISO image is not isohybrid-ed, its contents, mapped as a partition, won't be used by Linux. Have you confirmed that for example, the same distro ISO image, on first case isohybrid image, and the seconds case non-isohybrid work the same way? My conclusions were also based on attempts to boot this way *BSD ISO images, none of them worked unless no other files were required outside initrd/kernel, and all images were non-isohybrid. It could have been just the kernel/init scripts ignoring such partitions, no matter as contents of isohybrid-ed image or not.

To boot all Linux and similar non Windows ISO files program uses a trick hinted by cdob and extended by Steve, check the comments in this menu entry: http://reboot.pro/topic/9916-grub4dos-isohybrided/page-2#entry88531 In short, ISOHYBRID ISO images are mapped as a partition, thus requiring an available partition entry in the partition table. This is written by grub4dos when the selected menu is launched. PLoP has read-only USB driver, meaning this modification cannot be made, hence the message you are seeing. Simple images like Acronis, which have only kernel and initrd files and nothing outside to be needed by OS later on, do not actually need to be mapped as partitions, but programatically it's hard to find out if that's the case. For such images you could manually create a menu like: title Boot XXXXX.ISOmap /ISO/my.iso (0xff) || map --mem /ISO/my.iso (0xff)map --hookchainloader (0xff)Or simply use QEMU (slower) as the included option in WinSetupFromUSB or VirtualBox (faster) from above to test, both allow write operations and there will be no need of PLoP. In addition, make sure 4th partition entry is unused, and the 3rd if using persistent space:

Here are some hints how to test in VMplayer: http://reboot.pro/topic/16897-how-to-add-kav-rescue-10iso-to-grub4dos-menu/page-2#entry154729 Here is about Virtual Box, altough not an actual USB boot as the above: http://reboot.pro/files/file/339-virtual-machine-usb-boot/

Ahh, you are ruining it Jaclaz, recently purchased lots of SanDisk shares Seriously, OP asked for a push in a direction, I am of course sharing my push in my direction. Other opinions and directions are always welcome, just as yours.

Recommending it specifically not because of the fixed disk type, but mostly because of the speed/price ratio, which seems to be one of the best in my research, in addition to the lifetime warranty. Kingston DateTraveler Workspace for example at similar speeds is twice the price. What I usually do is to look at usbflashspeed.com and start researching prices/reviews/speed tests for the fastest drives. It's the XP, not tested 2003, FAT32 driver and reading lots of small files, details. Any later Windows version is fine. Mostly GPT partition scheme support. Secure boot on the other hand, but in my opinion it's just Microsoft limiting users of using other OS. No idea where you are seeing those options, isn't it MBR type? Use grub4dos one if that's the case. I got 2, both arrived as fixed disks. I've no idea about this particular tool. You may find another one with this option, if chipset supports it at all, at flashboot.ru. In general, I'd avoid messing with the controller, unless it's last resort (read dead drive), or it's a really cheap one I don't mind losing. Most tools come with an interface, quite far from user-friendly, and of course they are not intended to be, besides, one can hardly find a guidance with the configuration or the options.

UEFI is a new system firmware, replacing the ageing BIOS. Most, if not all modern PC/Laptops come with UEFI, at the same time most of them providing an option to boot in BIOS mode for backward compatibility. UEFI can boot from FAT32 formatted partition, no matter active or not, partial support for NTFS, manufacture dependant and very rare. There is also an NTFS UEFI driver which might help. In general, if you are going to boot in UEFI, stick with FAT32. XP setup from a FAT32 partition could be painfully slow, NTFS would be times faster. Multipartition- if using USB stick seen as removable, versus fixed (hard disk) type, Windows by default recognizes only the first partition. There are workarounds, but in my opinion not worth the troubles, given the small benefits. If USB stick is seen as a fixed disk, such as SanDisk Extreme for example, multiple partitions are not an issue with Windows. In this case you can have FAT32 partition for UEFI boot and Windows 7/8 sources and perhaps some Linux ISOs, and a NTFS one for the XP sources. My general advice would be to get the mentioned SanDisk Extreme, which is recognised as a fixed disk, make 2 partitions, first FAT32 acrtive and second NTFS, and leave the remaining 2 partition entries unused, to be able to boot Linux ISOs with persistence space if needed. The mentioned UFD is also insanely fast, especially on USB 3.0 mode.

Do you need to multiboot several NT6 sources? If not, you could always use the previous 1.0 beta versions, beta8 for example, they would copy source as it is, flat files structure. If you need multiboot, you may try using autounattend.xml placed on the root of a USB removable disk, in case of a USB fixed disk, it has to be in root of the ISO for example, or in root of image 2 in boot.wim. Or if autounattend.xml doesn't work for you, you could edit the ISO files directly on the USB disk, if boot.wim does not change, just an extra step when customizing.

http://www.msfn.org/board/index.php?/topic/120444-How-to-install-Windows-from-USB--WinSetupFromUSB-with-GUI#entry1076608

1) It may not be such straightforward process as it may appear to be automatized 2) I don't have wide variety of USB 3.0 hardware to test. 3) I don't expect lots of users having hardware with USB 3.0 to run XP on it 4) With XP support officially ended, I wouldn't spend much time adding new features in regards to NT5 sources, program already deals with the most common and needed ones You could try using the advanced option to add F6 floppy having prepared such with the needed drivers: http://www.msfn.org/board/topic/161875-usb-30-txtsetupoem-files/ http://www.msfn.org/board/topic/158290-install-xp-on-usb3-stick/ https://www.google.com/search?q=usb+3+drivers+txtsetup.oem+site:www.msfn.org There will be 2 boot options for this floppy image, try the second one which utilizes Firadisk driver as well if the first one is not working. This way you could add several floppy images for each USB 3.0 driver. of course I need EFI. install.wim's file size is 4177288 KB. when I put file iso to program, it's appear the notice like you said. iso's file size is 4.7GB + 58MB! what should I do now??? You could use the previous 1.0 beta8 version and add this source first as a flat file structure. Next Windows NT6 sources can be added with the latest 1.4 version, as long as they are < 4GB of course. Limitation is that you can have only one source using the flat file structure. Alternatively, you could try NTFS and EFI as mentioned here.

Got emails for this topic, seems ok now, thanks.

I've missed yesterday 2 notifications for subscribed topic and forum too. Checked spam folder just in case, nothing there.

Please do not double post, the other post has been answered: http://www.msfn.org/board/topic/120444-how-to-install-windows-from-usb-winsetupfromusb-with-gui/page-84#entry1076258

If you dont need EFI you could use NTFS. How large is install.wim?

You'd need to play a bit to find the right syntax, if possible at all. If you are testing on a Dell system use the modified ntdetect.com just in case. Besides, is it just an experiment? Why not start setup directly from the CD?

Welcome to the MSFN forum. Please do not double and triple post the same content, you will get answers when and if possible. I have removed the other posts. Why multi(0)disk(0)cdrom(224) ? Where are setup files located? How are you planning to inject drivers using grub4dos? Mind you, grub4dos is not the same as grub, it's a constantly developed fork of the retired grub legacy, with added quite a lot features and improvements.

Programs updated to version 1.4. Changes since version 1.3: added better handling of illegal characters for Linux/Other ISO source file name added advanced option for adding persistence partition for Linux sources. Each source has its own persistence space associated with it added better handling for Kon-Boot, source is to be added as ISO file using the Linux/Other ISO option added advanced option to add custom folder with boot critical drivers for NT6 sources (Vista and later). These drivers are added in boot.wim and loaded with DrvLoad before start of Setup, scratch space is increased accordingly. Only drivers for present devices will be loaded. Use it to add USB, SATA/SCSI or Chipset/USB drivers for example. Loaded drivers will be staged and available to the OS being installed. For non boot-critical drivers (Lan, WLan, Video etc.), have a look here added internal check for NT6 sources with multiple boot.wim, only default osloader entry in BCD store and the corresponding boot.wim will be added fixed errors when USB disk was initially prepared with the auto-format option, and on next run of the program it may complain about missing MBR and partition table

Glad you have it working now. A little correction- use whatever you need to modify the source and then transfer it to USB disk with WinSetupFromUSB, it should always be last.