Make a bootable USB to install Windows XP from Linux
You can use VirtualBox and give the virtual machine access to the hard disk drive. Then install Windows XP in the virtual machine and create a new partition on the real hard disk drive. After installation you can reboot the computer and boot windows as normally.
To give VirtualBox access to the entire disk (change the x
to appropriate letter, for example, a
):
VBoxManage internalcommands createrawvmdk -filename ~/hdd.vmdk -rawdisk /dev/sdx
Then choose the existing hard disk drive, and select the file hdd.vmdk
in your home folder.
If the commands complains about missing permissions, add yourself to the group disk
with the following command, then log in and out and try again.
sudo adduser `whoami` disk
If you already have Linux installed on the target computer you can to this directly on that computer, but before you reboot into Windows, run
sudo update-grub
andsudo grub-install /dev/sdx
(change thex
to appropriate letter, for example,a
) to make sure that you will still be able to boot Linux. To avoid issues with differing hardware between your computer and what VirtualBox emulated in the VM (which can result in a BSOD), you can also create a second hardware profile in Windows before leaving the VM. When you boot directly into Windows with GRUB, select this second hardware profile. You can eventually make this new hardware profile the default.If the target computer is completely clean, make a bootable Ubuntu USB drive on which you also put an image of your (legally purchased) Windows install CD. Then boot Ubuntu on the target machine and follow the instructions above.
Download RUFUSLDR from here: https://dl.dropboxusercontent.com/u/20170669/RUFUSLDR Download ms-sys here: http://prdownloads.sourceforge.net/ms-sys/ms-sys-2.3.0.tar.gz?download Drag the ms-sys-2.3.0 folder out to somewhere that supports the execution flag (like your Linux home folder, most likely). cd a terminal there, type "make", then "sudo make install". Real easy.
I sympathize with you. I have tried tutorials on how to create, from Windows, a USB drive bootable into the WinXP installer. The diskpart one, the WinToFlash one, and the HP USB Format utility one all failed me.
Rufus actually works. But it is a Windows-only utility. You may install VirtualBox, install Windows within VirtualBox, install Rufus in the VM, share the USB drive to the VM, and have Rufus make the USB drive bootable into the Windows XP installer.
Rufus currently does not support making a bootable USB WinXP installer using loose installation files. It must see the iso. So you have VirtualBox mount the iso to install XP into the VM, but that shows up as loose files (won't see the iso). So to get Rufus to see the iso file itself, share the directory on your host machine where the iso is stored to the VM. Then point Rufus off to where the iso file is in the VM's network drive (Z:\ or whatever).
BTW, you may also just copy a FreeDOS floppy image to the drive, copy the files in from the iso as well, and use memdisk to boot into the floppy image. From FreeDOS, run i386\ winnt.exe . The downfall is that (unless you found a DOS NTFS driver?) you'll only be able to install Windows to a FAT32 volume, not an NTFS one.
You may find the Rufus process painfully slow due to being in a VM (don't understand why, maybe I was dumb about how I set settings). For me personally, on my laptop, it took one hour, 5 mins, and 40 seconds, I believe it was. I will tell you how to do it without Rufus in Linux. We will be immitating Rufus, but first, in case you decide to use Rufus from the VM instead, be aware that Linux will not be able to see the partition after Rufus is done with it:
Rufus not only formats the partition, it redoes the MBR (including partition table). So save anything off the thumb drive first.
Note: Rufus lays down a trick MBR that when executed by the BIOS swaps the first two BIOS drives (0x80 becomes 0x81 and vise versa). Additionally, it puts a BIOS id in this trick MBR to make the drive start out as 0x81 (the second drive). Why I'm telling you this: the trick MBR causes Linux (and Grub2 v2.00) to be unable to read the partition table. Windows will be just fine with it (give it a drive letter and all) and the drive will be bootable. But Linux will not see the partition and thus not be able to mount it. No problem. Save the MBR to file:
sudo dd if=/dev/sdX of=~/Desktop/rufus_trick_mbr count=1 bs=512
Now use fdisk to give it a new MBR. You're not even touching the partition itself, you're just giving it a new MBR. Nothing actually is done in fdisk until you hit "w".
sudo fdisk /dev/sdX
p //Print partition table. fdisk, unlike the kernel, CAN make sense of the partition table as-is.
You'll probably see the partition start on sector 2048 and go to the end.
o //Tells fdisk to make a new partition table
n //create new partition. By defualt, fdisk should also make the partition start at sector 2048 and go to the end. Make sure the partition starts where it used to and ends where it used to.
select primary
t //change partition type id
7 //for ntfs
p //Make sure everything is right. And no, don't worry about the boot flag.
w //when you're sure. Remember, we saved the old mbr and can undo any mess-ups made here with dd.
We can also make new mess-ups with dd:
HAMMOND – “Don’t worry, I’m not making the same mistakes again.” MALCOLM – “No, no, you’re making all new ones.”
-Jurassic Park II, The Lost World
Unplug and replug the thumb drive. If nothing else, /dev/sdXY should at least exist now (before only /dev/sdX existed - no "Y"). To mount it, ntfs-3g should be installed. If it's installed, see if it was already mounted (should show up on Desktop or in left pane of file browser if so). If not, mount it yourself. You can try to mount it with the file browser first. Here is how to manually mount it:
sudo mount -t ntfs-3g /dev/sdXY [mount point]
Do what you want to do with it in Linux.
If you wish, put rufus_trick_mbr back on:
sudo dd if=~/Desktop/rufus_trick_mbr of=/dev/sdX bs=512 count=1 //No "Y"! Just /dev/sdX!
But you don't have to put the trick MBR back on. You can use Grub2's ntldr command to load /BOOTMGR instead. (Probably will need to do "insmod ntldr" first to insert the ntldr module.)
Here's what happens:
Rufus lays down the trick MBR with one partition table entry, formats that partition as NTFS, puts stuff in the bootsector of that partition that only ntldr-style bootloaders care about, copies files out of iso to the partition, copies NTDETECT.COM from the i386 folder and puts it on the root level, copies txtsetup.sif from the i386 folder, puts it on the root level, AND adds a line, which github,c0m/pbatard/rufus/wiki/Targets-Supported does not mention, so thank you "openssl md5" and cmp for pointing this out to me.
drum roll: AND copies SETUPLDR.BIN from the i386 folder to the root level, renames it as BOOTMGR, AND patches that binary. Yes, that's the trick. SETUPLDR.BIN, when booted from CD, detects that it has been booted from CD and looks to the i386 folder for stuff. If booted off a hard drive, it detects that it booted off a hard drive, looks for an minint folder instead, and, if found, looks for a $WIN_NT$~BT folder to begin the second phase of installation (after the restart and when you boot into the target hard drive). So you can't even just rename "i386" to "minint". You have to modify SETUPLDR.BIN to look in the i386 folder even when booted off a hard drive (such as a USB drive).
I think it's a misnomer for Rufus to call the modified binary "BOOTMGR". That's what Vista and 7 (and 8?) use, not XP. BOOTMGR doesn't even look for a boot.ini file like NTLDR (of which SETUPLDR is a modified version) does. So I renamed it as "RUFUSLDR" and put it up for download. Plus you'd want to be able to tell it apart from any real BOOTMGRs you may have running around.
Rufus forces you to format the drive as NTFS if applying a Windows installer iso. I believe this is due to the x64 Windows 8 developer preview containing a file >4GB, which FAT32 can't support. But that doesn't apply here. We have no files anywhere near 4GB. You may use FAT32 and be just fine.
Let's immitate Rufus from Linux (or just about any unixoid, I guess):
Make sure drive is MBR-schemed. fdisk will throw a warning if it is GPT and also give you the option to make it MBR-schemed (option "o"). Less destructively, gdisk will let you convert your GPT-schemed drive to an MBR-schemed drive if you have 4 or less partitions. Gdisk also will let you make your drive a hybrid MBR/GPT-schemed disk where you may choose up to 3 partitions to be visible to GPT-unaware stuff (the 4th slot is taken up for a protective partition that covers up the rest). Even if you just use fdisk, as long as the new partition table entry still starts and stops at the same places, you won't loose your partition; just be sure to zero-over the secondary GPT at the end of the disk.
-
Make sure partition is formatted as FAT32 or NTFS. Remember, FAT32 is more cross-platform-friendly. If it's already formatted as FAT32 or ntfs, you don't need to format it:
sudo blkid /dev/sdXY [will say filesystem here, along with UUID, label, etc.]
If it's not FAT32 or NTFS, do one of these:
sudo mkdosfs -F 32 -n [insert volume label (name) here] /dev/sdXY
sudo mkntfs -L [insert volume label here] /dev/sdXY
3 Apply that magical bootsector stuff that DOS/Windows is oh so finicky about:
sudo ms-sys -w /dev/sdXY
*About this - "-w" stands for "write" - just writting. As opposed to specifying what to write. Thus "-w" is ms-sys's auto-mode: it determines the best kind of bootsector data to write for the situation. I was surprised to find that auto was right: for a FAT32 partition, I need ms-sys's FAT32 DOS bootsector not ms-sys's FAT32 NT bootsector, which I thought I would need to load a derivitive of _NT_LDR (NT loader)(SETUPLDR.BIN is a modified version of NTLDR, and RUFUSLDR a modified version of SETUPLDR.BIN).
4 For good measure, write geometry stuff to the partition as well. This does not change the geometry of the disk, it just leaves a note about the geometry for stuff too lazy to find out about geometry on their own:
sudo ms-sys -p /dev/sdXY
*Note: step 4 does not apply to NTFS. *Another note: make sure your linux kernel version is >2.6. Kernel 2.6 had a bug that reported the wrong number of heads (a geometry thing). Thus the "-p" option can put down the wrong info in kernel 2.6. The "-H" option, which allows the user to manually specify the number of heads to record, is the work-around. But really, just upgrade your kernel instead. If you're running 2.6, you're waaaay overdue. To tell your kernel version, do:
uname -r
5 Copy in the files from the iso, folder, whatever. Many distros mount isos upon double clicking them, or at least offer the option of opening with an archive mounter under right-click > open with. If that is not the case for you, do this:
sudo mount -o loop (path to iso) (path to desired mount point)
6 Place the modified SETUPLDR.BIN (RUFUSLDR) file on the root level.
7 Copy NTDETECT.COM from i386 to the root level.
8 Copy txtsetup.sif from i386 to the root level.
9 Open the new copy of txtsetup.sif and Ctrl+F for "[SetupData]". Right under that header, put this line:
SetupSourceDevice = "\device\harddisk1\partition1"
10 Either install a bootloader capable of loading NTLDR-style bootloaders to the drive, or to another drive that you'll use to boot this drive, or use an existing bootloader. If you have Grub2 installed on your hard drive to boot Ubuntu, you can just press "c" once you see the menu to enter the Grub commandline. If you have Syslinux instead, you can use it too. I'll just stick with Grub2 for the tutorial.
To install Grub2 to the disk (which you may not need to do if using your hard drive's existing bootloader):
sudo grub-install --boot-directory=[mount point of disk, not iso] [/dev/sdxy]
11a. Either make a grub.cfg entry or manually execute the following:
grub> insmod ntldr //Inserts (loads) the Grub2 module used for loading NTLDR-style bootloaders.
grub> set root=(hdx,msdosy) //Replace x and y as appropriate. Sets the current directory to the target partition. Probably not needed if you booted off the drive you put the WinXP installer files on, but we always do this. Use "ls" to list all drives and partitions. If you only have one MBR-schemed disk with only one (or however many you made) partition(s), you'll be able to pick out which is your thumb drive. If not, try one and do "ls /". It will list the files on the root level of that partition. That should be a dead-giveaway. Notice that "ls" (without slash) lists drives and partitions, and "ls /" (with slash) lists the files on the root level of the partition that is the current working directory.
grub> ntldr /RUFUSLDR //Tells it to load RUFUSLDR.
grub> boot //That's the "go button".
11b. As a grub.cfg entry, that'd look like this (do not line-up brackets, this is Grub, not college!!):
menuentry "Windows XP Installer" {
insmod ntldr
search --no-floppy --fs-uuid --set=root [insert filesystem's UUID here, obtaind by "sudo blkid /dev/sdXY"]
ntldr /RUFUSLDR
}
//Note that the above is a much more sure-fire means of setting Grub's current working directory. Also note that "boot" is implied for config file entries.
//Also note that although it is customary to have a "drivemap -s (hd0) ${root}" line for booting Windows (makes Window's drive the first BIOS drive), doing so for my USB Windows XP installer caused it to just reboot upon trying to boot the ntldr-style bootloader. If things aren't working, and you're sure you did all the steps, try "drivemap -s (hd0) ${root}"
//Be aware if you have more than one USB drive inserted at boot time. Your system will boot the most dominant bootable USB drive when told to boot USB. You can systematically figure out which USB ports are dominant to which with two bootable USB drives. For me, I didn't have to try many combinations, because my USB ports are arranged in columns and whole columns were dominant to other columns. Within a column, the higher one was dominant.
//Note that if you are booting your Windows XP USB installer from Grub2 on another drive, Grub2 will only see the most dominant USB drive (at least on my system). So be sure that your WinXP USB installer is in the most dominant used slot. (Or just switch the two if you have two USB drives and Grub2 sees the non-WinXP-installer drive.) Of course this is not an issue if only one USB drive is inserted.
//If it just reboots, make sure you did "sudo ms-sys -w /dev/sdXY" and, if FAT32, "sudo ms-sys -p /dev/sdXY", AND copied NTDETECT.COM from i386 to the root level.
//If it says it can't find whatever, you may not be using the modified bootloader. Make sure you're using the modified one. (Will have different md5 than i386/SETUPLDR.BIN.) Also make sure txtsetup.sif and NTDETECT.COM are on the root level.
//If it says to insert the Windows XP SP3 CD, make sure you added that line to txtsetup.sif AND that your CD Ident files are good (WIN51, WIN51IP, etc.). Just delete the CD Indent files and copy them back over if in doubt.
//If it says you need to insert a disc to prove you qualify for the upgrade installation, are there any GPT disks inserted? Perhaps this is causing the problem. Unplug any GPT-schemed disks or convert them to MBR in Linux. (as in turn off computer, unplug, try again. Not just yank.)
//BTW, to install TO a USB drive, you'll need to do the hack at ngine.de/article/id/8. Yes, it is possible to install Windows XP FROM USB TO USB.
Enjoy,
Jake XD
Turns out that Windows XP actually does configure itself for a specific hardware configuration during the first phase of the installer.
So if the method of using VirtualBox, QEMU, etc. in conjunction with your real hard drive is to work, you really do need to make a second hardware profile. I was hoping you could bypass this by shutting the VM down before rebooting into the second stage and instead boot your real machine into it and let it configure for your real hardware. But it configures for hardware in the first stage, not the second stage.
So I definitely recommend imitating Rufus. Just copy the files on and make a few tweaks. See existing post. No need to deal with a second hardware profile. Even if you made a second hardware profile, how would you boot into Windows to install drivers for your real hardware under the second profile? And if you did find a way, wouldn't licensing stop you (it looks at hardware)?
Have a look at UNetBootIn. This should do the trick.