?

Log in

No account? Create an account

Previous Web | Next Web

Life migration....

OK, so I'm starting to get my head around replacing my laptop's internal ~110GiB HDD with a ~300GiB one... I've had the drive for a fair few months (like, um, May/June...) but haven't really been here for a lot of that... most of it, I've been down South and using the laptop heavily... and the install media for stuff has all been up here...

Anyway, this is a Dell laptop, so its got various non-Windows partitions on it... there's the Diags partition, the Restore partition and the MediaDirect partition (which is a logical partition inside and extended partition, rather than a primary partition).

There's also a Dell-specific MBR bootstrap (it shows up white-on-blue www.dell.co.uk (or .com.. can't remember)) banner-line at the start of boot-up, but also provides the interupt-boot key-combo (Ctrl-F11) that enables you to access Diags or Restore (it may also have something to do with MediaDirect, but I can't swear to that...).

So yeah, I'd kinda like to have these on the new HDD aswell... they're not all that big (total size is less than 6GiB for the 3 partitions), and (atleast the Diags) are kinda useful... (I don't think I've ever used MediaDirect, and I almost certainly won't use the Restore image).


So I started looking into ways to get them all transfered.


MBR BootStrap


Now, copying the MBR bootstrap looks reasonably easy... although it does require some care... basically its a case of copying the first block of the current HDD to the new HDD (possibly via a floppy or USB stick). Now, with unix/linux (ie, using a Live distro like Knoppix), this is essentially pretty easy.... its just a case of doing:

With old HDD installed:
dd if=/dev/hda of=bootstrap.blk bs=512 count=1
With new HDD installed:
dd if=bootstrap.blk of=/dev/hda bs=512 count=1

BUT this is where the 'care caveat' comes in... that 512byte block contains more than just the bootstrap... it also contains the partition table and an "NT id" field (for uniquely identifying the device... and its not just a Windows ("NT") thing these days... atleast some Linux distros tools apparently use it... dunno if the kernel does though)...

WARNING: MBR backup tools save an entire sector (512 bytes), which contains not only the boot code, but an NT Serial Number (aka, Disk ID) and a partition table. You do not want to overwrite your partition table! The partition table that is part of the MBR backup from another machine almost certainly won't match your own partition table. The partition table is the index to your hard disk's partitions. Overwriting this index with a mismatched copy from another computer may render some or all of your partitions unreadable. The purpose of copying the MBR from another machine is to restore your boot code, not your partition table.

Anyway simply copying an MBR from one drive to another will (a) destroy (NUKE!) the original partitioning (b) store the original drive's partition data to the new drive (c) replicate the original drive's ID (and d) probably not make a whole load of sense having done these things because the drive geometries won't be the same!

So what can be done instead?

Well... I came across a neat little tool specifically created for this scenario! (see http://www.goodells.net/dellrestore/fixmbr.htm). Instead of copying the first 512b, as per the 'dd' example, it copies just the bootstrap part, and ignores the ID, the partition table and the "magic" last two bytes that identify the bootblock as being a bootblock, (that is (according to wikipedia, anyway! ;-) 0xAA55)....

note: I suspect it might be possible to use a 'bs=440' with 'dd' to achieve the same thing (that is, to copy a 440 byte block... rather than a 512 byte block... 440 bytes being the maximum size of the bootstrap within the bootblock), but I'm all for using tools/techniques other people have tested! ;-)

Run Time Environment


The next thing to do was figure out what environment I'm gonna use to do the work from...

The "Dell MBR" tool is a DOS tool (that is, a true DOS tool, not a DOS-Box-In-Windows tool; in other words, it uses direct hardware/BIOS disk access rather than user-mode Win32 calls) so I need a DOS of some sort.

Now, part of my normal 'geek kit' is an Ultimate Boot CD For Windows (http://www.ubcd4win.com/)... I use it quite a lot... its got all sorts of useful tools on it for working on other people's machines... its basically a Windows XP system that runs from CD... anyway, my current one has gotten quite old, so the "anti-threat" tools are practically useless....

Also available, is the Ultimate Boot CD (http://www.ultimatebootcd.com/), which is the same idea, but DOS-based... (its an older concept than the Windows version... and inspiration for the same)

So I figured it was about time to:

  1. Build a new UBCD4Windows

  2. Build an UBCD


Now, it turns out that its actually possible to include "UBCD4dos" in the current UBCD4Windows...

So I figured that that would give me a pretty decent basis to work from... I'd just need to add my "system transfer" tools to the boot CD.

In addition, it is also now possible to make an "Ultimate Boot USB-Stick For Windows"... (that is, to make a bootable USB-stick with the UBCD4Win stuff on it)... which is even better... considering that I need to be able to save the Dell BootStrap somewhere, and CD is read-only... and not every machine has a floppy (and I don't always grab my USB floppy drive when I'm gonna work on someone else's machine, but do usually grab the UBCD4Win and my USB-stick)

The only problem with this stuff is that the resulting ISO image is 679MiB... which is too big for any CD-RW I possess... (and I'd want the option to boot from CD in case I'm on a machine that only has USB 1.1... can't imagine how painful booting would be at 1.1 speeds...!)

Transfering Partitions


So the next thing to figure out is how to transfer the content of those "special" Dell partitions...

Now, if I had a copy of Ghost, I suspect I could use that... but not necessarily... atleast, not without changing some partition types...

I actually came across the solution I'm gonna try for this while I was looking into how to put the "Dell MBR" tool onto the boot cd... the way you add new "multiboot into" options is to add plugins to the Builder environment... and there are a few pre-made ones available... one of which is for something called "CloneZilla"... which combines Partition Image, NTFSClone, PartClone and some other bits (like DRBL) to create both a "Ghost-alike" and a "Ghost Corporate Multicast-alike" solution.

CloneZilla Live is the "personal edition" version of CloneZilla, and is a Live CD. As such, it should be pretty easy to integrate into the UBCD4Win system.

Testing


So, I figured it would be a bright idea to test this stuff out... without actually using(/breaking!) any real hardware... so I turned to VMWare...

And got stumped almost immediately!

Turns out that VMWare 6 doesn't support booting from an attached USB device... which is bloody frustrating!

I mean, you can connect USB devices "directly" to the Guest OS (so you can plug a USB drive in to the physical USB port and tell VMware to 'grab' it from the Host OS... giving the Guest "safe" access (that is, only the Guest can access the device, without the Host simultaneously trying access to it... the Host doesn't see the device)... but there is no BIOS option in the emulated machine to select USB as a "boot from" device, even though you can boot from HDD, CDROM, Floppy and Network (PXE, I believe)...

Mindst, I suspect even the level of USB access I just described is a relatively new thing.

And this is the only thing (apart from a lack of OS/2 support (read "bootability"), which is a pretty, um, eccentric 'want') that I've now got to criticise VMware for... I mean, they've got Direct-3D support in the graphics driver now, so it should be possible to run the izzy-whizzy Vista GUI in all its, um, glory(?!) in a VM... not that I've tried that yet... I needed the diskspace that my Vista VM was using... and anyway, the installation wasn't activated and the grace period had expired with me not having used it since installation!

Now, amongst all the messing around to figure out getting the "Dell MBR" gizmo usable and the looking into CloneZilla, I've been poking around the SysLinux site (that being the bootstrap that Linux install and Live CDs all seem to use (as IsoLinux)) and in their HowTos list, there is a page with basic info on chainloading SysLinux when there is No Native BIOS Support for booting a device type (ie, CD and/or USB)... this in turn links to the PLoP Boot Manager, which looks like it does exactly what I want!!!

So, my next task is to see if I can get PLoP-BM to chainload the UBStick in VMware!



Oh yeah, before anyone asks, "Why use Windows as your primary OS?" the answer is multifold:

  • I have a couple of apps for programming PLCs that are not very well written... they're only available for, and run pretty damn slowly, under Windows... I dread to think how bad they'd be in a VM... plus they interface with USB devices, which I've never really wanted to try in a VM. Its just easier to run them under WinXP-as-a-Host-OS

  • Linux generally runs nicely in a VM... so I can boot WinXP and VMware and have both OS available to me

  • Getting OS/2 in a VM seems to work best in MS Virtual PC... which doesn't run on Linux... last time I tried it, VirtualBox didn't do it, and I never got around to trying QEMU

  • I have a fair few "paid for" apps (including Visual Studio, Office 2007 (I had an MSDN subscription for a year... gave me lots of nice entitlements :-) ) and PhotoShop) that are Windows apps and again, they don't exactly fly on WinXP-as-a-Host-OS... again, I dread running them in a Guest!

  • I don't mind WinXP... I'm very used to it... its like an old pair of slippers... they may have holes in them, they may be threadbare in places and a bit scruffy... but they're comfy and I'm used to them.... kinda the same reasons that I never minded Mac-OS (in its pre OS X guise)... and also why I don't get on with Vista... I don't have to think to use either of them... and stuff in XP is where I expect it to be (even if that is only because I've used it so long that its reflex); Vista confuses me!! ;-)