Okay, a lot of people hate windows these days, few can say why.
A have quite a few reasons to do so. Especially, since quite a few retarted developers write software that I _have_ to use, to get some the work done, I eventually have to boot it, and, even, work in it. Luckily, thanks to the fact emacs feels nicely even there, that’s not big deal … But the tale is about how I wasted a whole evening trying to move a windows installations from one hdd to another. If in case of *NIX that takes a few minutes and a few config files to edit, here… Well, it’s a different reality.
So, my setup:
Old hdd, now in a usb-hdd enclosure:
/dev/sdс1 – / of the installed linux (Agilia)
/dev/sdc2 – swap
/dev/sdc3 – A temporary field for experiments with moblin/android x86/etc
/dev/sdc4 – WinXP
On the new drive, now fitted into my asus n10j the table was as follows:
/dev/sda1 – A spare place for Windoze
/dev/sda2 – / of Arch Linux
/dev/sda3 – swap
Usually, knowing how ‘awesome’ (in the worst meaning of this word) those brainiacs from Microsoft implemented this stuff, I try to keep windows ALWAYS on the very first partition of the very first drive, so that it won’t get bricked due to any hardware changes. But historically, I dont even remember why, I ended up with such a shitty partitioning on the old drive. And as another starting condition, I couldn’t do a clean install (due to the long lost and forgotten software installed there, with no distro avaliable whatsoever and bound to this installation with a sh*tload of registry keys). In other words – I needed THAT particular installation.
Here goes the fun.
First I did an ‘ntfsclone’ from linux, added a menu entry in grub and… nothing. Just a blinking cursor at top left corner when you chainload it. After a lot of experiments with ms-sys, dd, hexdumping I figured out, that the problem was in PBR (ака VBR), that stands for Volume Boot Record. It is being chainloaded by grub.
Starting a clean windows install on that partition won’t fix the problem. It sees a WinXP PBR, assumes it’s fine,copies the file, and we have exaxtly the same crap next boot.
After doing nice read on how NTFS works, comparing hexdumps, and getting quite insane, I wiped the partition clean, let windows install it’s initial loader, and then backed up whatever stuff it had at the beginning.
dd if=/dev/sda1 of=workingpbr bs=512 count=5000 |
Why so much? After giving the NTFS specs a read I found, that it’s not only the first 512 bytes that do the job, 16 next sectors also take part in it, and there are backups at the end as well. Where the actual bug was – I couldn’t determine. I hadq quite a few looks at hexdumps, and fun decoding NTFS params already. So I backed up the boot stuff, and ran ntfsclone again.
ntfsclone --overwrite /dev/sda1 /dev/sdc3 |
Than, as a good start, I applied the first 512 bytes of the backed up bootable partition.
dd if=workingpbr of=/dev/sda1 bs=512 count=1 |
And, miracle happens, I saw the long-awaited error message that hal.dll was not found. Next things were routine
I fired up vim and threw some minor modifications to boot.ini, replacing
multi(0)disk(0)rdisk(0)partition(3)
to
multi(0)disk(0)rdisk(0)partition(1)
Next, I went into WINDOWS/system32/config and nuked from hive ‘system’ the ‘MountedDevices’ key. If you don’t do that – you’ll see BSOD once replacing the drive.
Next amount fun goes…
It booted, but hung on the welcome screen, no user acoounts appeared. Safe mode worked the same way. WTF?
After thinking for while, I rebooted in linux once more and went to WINDOWS/system32/config, opened the hive ‘software’, and there, in Microsoft\Windows NT\CurrentVersion\Winlogon wiped UIhost, nuking the graphics welcome message.
Say hello to the oldschool login dialog. I entered my username and was logged out the next second.
Thinking, reading MSDN for another while, when it finally struck me: That freaking windows installation enlisted the prtition it was installed to as drive ‘F:\’. And after wiping the MountedDevices I got it reenumerated as ‘C:’.
And since windows (now you know why it’s defective by design) usually hardcodes absolute paths in .lnk files, in thousands of registry values, in .ini files, and in another dozen of places I can only assume they exist, lately I have found many new things, such as the password spy for pcTattletale for monitoring. Well, it’s not *NIX to solve that by running a sed with a regexp magic on the /etc and throwing yourself some coffee while it’s working.
As I expected, editing Userinit in winlogon branch to a correct path didn’t solve the issue. I still couldn’t login. I wasn’t logged off instantly, but the blue screen stayed for ever.
I had 2 choices:
- Edit MountedDevices, so that it will be F:\ instead of C:\, but chntpw, that worked awesomely up till now threw me an ‘Aborted’, whenever I tried to access those keys
- hack the partition table, effectively makeing the partitions to appear NOT in the disk order, so that windows will enumerate the drive as F:\.
Luckily I didn’t take the second pill – gave the safe mode another try, and, unlike regular init it booted to desktop, although nearly nothing (e.g. mmc) worked, crashing mostly instantly. I fired up regedit, navigated to MountedDevices, renamed:
\DosDevices\C:
to
\DosDevices\F:
reverted Userinit to the value it should have…
And after this f*cking voodoo, it booted as if nothing’s happened. And after that people say, that linux is difficult…