Installing windows on a laptop that had linux

At my office, most of the people use macs, and of the people that don't, most use windows but some use linux.

I don't really care what people use, but when someone wants a windows laptop and the only available hardware in our inventory used to have linux on it, I need to pop in the old windows installation cd and get windows installed, right?

Problem is, the windows installer CD will not install by default onto a hard disk that has linux on it.

Why not? I have no idea. I'm fine with it obliterating all the data - I want it to actually. But it will say "Setup is investigating your something or other..." then get stuck on a black screen. The installer doesn't really start.

The solution? Boot the machine with some linux install cd (or something similar that you have handy) and zero out the first part of the hard disk. The first 800MB did it for me (it did that before I could even hit ctrl-c, probably just a few MB is enough). It is not enough to just re-partition the drive without zeroing out some data. (specifically I popped a fedora core install CD into the drive, typed "linux rescue" at the boot prompt, told it to skip networking and skip finding linux installs, then at the root prompt said 'dd if=/dev/zero of=/dev/hda bs=1M', let it run for a second, then hit ctrl-c, then when the prompt came back, said 'exit' and rebooted)

After that, you can use the windows installation cd with no issues.

$PATH issues on windows

If you're busy perl-scripting on a windows machine, and you're getting unexpected behavior from the command-line utilities your shelling out to (say, 'find', or something), it may be because instead of getting the utility you think you're getting (/usr/bin/find, for example, from cygwin) you're getting something totally different (dos find, for example)

This can lead to a lot of confusion when you try to figure out why you aren't getting consistent results between systems you're working on.

Solution? Use full paths. If you want the cygwin find, say "/usr/bin/find" or you just can't be sure.

Beware DOS line endings with Perl open command in cygwin

Just a quick note, if you are opening files in cygwin perl on windows, you need to beware the difference between line endings on unix and windows (CR vs CRLF)

You can either twiddle with what constitutes a line-break in perl or dos2unix the file, but if you do neither you'll get unexpected results

Patterns of deployment

This link just flew across the transom, and since I'm think in automated deployment on most projects I'm on I thought it was too good not to pass on.

It's called "Patterns of deployment" and the best part I think is the info about host-specific / environment stuff. That's always a tough nut to crack

Windows locks files, I unlock them

Still dealing with a recalcitrant windows environment where I'm trying to automate the deployment of a ColdFusion application.

Problem is, even after you stop the ColdFusion servers (and you ensure they're down via tasklist.exe inspection), some files are still locked.

It appears the only way to unlock them is to reboot the machine. (yes, I know this is abhorrent, believe me, I'd avoid it)

The way to do this easiest (I think) is to use the 'sc' Windows builtin to set the services to start manually (instead of automatically) (e.g. 'sc config "" start= demand')


Then reboot the machine, and check remotely until the machine's uptime is recent (via something like 'net statistics srvr|grep since 2>&1') via ssh, then parsing (m/\D+(\d+)\D(\d+)\D(\d+)\s+(\d+):(\d+)\s+(AM|PM)/) out the uptime (using Time::Local, and being careful if you don't get what you expect since that machines the machine is rebooting so the connection failed).

Once it's rebooted, you should be good to go, then just sc to set the start back to "auto" and you're done.

Easy (ha)

cygwin messes up windows permissions, cacl fixes them

I recently had the misfortune to work in a windows environment via cygwin+openssh

This is a seemingly civilized configuration - to my unix-biased way of thinking - as cygwin gives me a shell and ssh is a very familiar way to access machines for logins and automation.

Unfortunately, Windows has a very complex permissions scheme (ACLs) and cygwin+openssh+scp just won't honor Windows permissions. No matter how I tried, the files would land on the server without properly inheriting the permissions of the directories they landed in.

Luckily, Windows provides a relatively easy way to fix this problem in the utility cacls.

What I ended up doing was using cacls with the '/S' switch to get the string representation of the parent directory of the location I copied files to, then used the '/S:' switch again, this time with the string I got from the first invocation, but now targeted at the actual directory I was working in.

You can use the nifty "AccessEnum" utility (google it) to verify your permissions a lot more quickly than a ton of right-click/sharing-tab examinations.

Poof, perfectly consistent permissions.

I'll continue choosing unix for my servers though, thank you...