Category: HowTo

Installing Windows 8 on a Samsung Series 5

Here's some info on installing Windows 8 Pro on a Samsung Series 5 Ultrabook, in case anybody else has one and they wanna reinstall Windows from scratch.

To get the basics out of the way first:

• Computers that ship with Windows 8 pre-installed usually have the Windows 8 Core Edition on them by default.
• Also, the product key for the Core Edition install is baked in to the BIOS ROM.
• If you boot a "vanilla" DVD or USB for Windows 8 Pro, it will fail, because Windows 8 looks for the product key in the BIOS ROM and will see that it is not a valid Pro key.
• Some people say you can't install Windows from a USB on this laptop. You can do it, it's just tricksy.

The method that I found worked involves a dual-boot setup, where I have Windows 8 and Fedora Linux installed on the same laptop (you can substitute Fedora with any Linux distro of your choice... Ubuntu, Mint, etc.). If you want only Windows 8 on your laptop, this guide isn't for you. Sorry.

My particular laptop (the 13.3" variety) includes a 500GB hard drive and a 32GB SSD drive, which apparently is the ExpressCache drive. This is important.

So first, how to get Windows 8 to actually attempt to install. You can't just boot a vanilla DVD or USB, because the installer will see the OEM product key baked into the BIOS, and complain because it's for Core Edition and you're trying to install Pro Edition.

You need to make a USB installer for Windows 8 using the "Windows 7 DVD/USB Tool" (Google it). This is because you have to add a text file to the USB. You might be able to modify an ISO to add the text file to it, but you're on your own there.

Open Notepad, and create a text file named "PID.txt", and put this in as its contents:

[PID]
Value=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

Substitute the X's for your Windows 8 Pro product key. Place the text file in the Win8 USB under the "sources" directory, for example D:\sources\PID.txt

Now when you boot from the USB, Windows will use that product key instead of looking in the BIOS. And the installation will continue as normal.

But, it won't boot from disk after the installation is done. This is because the Windows Installer saw the 32GB ExpressCache disk, and it installed its bootloader onto that disk instead of onto the primary hard drive. The problem with this is that the BIOS on the laptop can't see the ExpressCache disk, and so it can't boot Windows from it.

I saw a couple solutions floating around the Internet for this. One solution said to format the ExpressCache disk with a Mac OS X file system, so that Windows wouldn't make use of it for its bootloader. You could probably format it with a Linux filesystem as well and get the same result. In this case, Windows 8 would've installed the bootloader directly onto the primary hard drive, and the BIOS would be able to boot it. This isn't much help to you, though, if you don't already have Windows installed to be able to format this partition.

What I did instead when I got to this point was... go ahead and install Linux. When I installed Windows 8, I gave it a 128GB partition on the hard drive. I gave Linux the remaining space to partition up as it pleases. When Linux installs the GRUB bootloader, it installs it onto the primary hard drive. This means the BIOS is able to boot GRUB... and, GRUB is able to see the Windows 8 Bootloader on the ExpressCache disk. Score! So now you can boot either Linux or Windows from GRUB.

This is what worked for me, anyway. If you don't wish to dual-boot Linux on your laptop, you may want to just boot a Linux LiveCD/USB, format the ExpressCache disk (/dev/sdb, probably) with a Linux filesystem like ext4, and then run the Windows installer again. Theoretically, Windows won't touch the ExpressCache disk to install its bootloader, and will install it on the primary disk. No guarantees that will work, though, as I haven't tested it.

Fun with Command Blocks

It's high time for my first Minecraft mini tutorial!

I tend to prefer playing vanilla Minecraft and try to get away with it as much as I can, and as such I've been electing not to run Bukkit or any other custom servers ever since about Minecraft 1.4 came out.

Minecraft has Command Blocks nowadays, and you can do a lot of creative things with them to replicate the behavior you could get by using Bukkit plugins. I recently started a new "Swampcore" server... the name is borrowed from a popular server on Reddit when they set up a swamp superflat temporarily while they waited for Bukkit plugins to get updated for the latest version of Minecraft.

Their version of Swampcore had you spawn in a small enclosed room, lined with pressure plates by the walls which would teleport you to an unpredictable location within a large radius on the overworld. The idea was to evenly distribute the players, so that people wouldn't build too close to the spawn point and therefore be open to griefing by newly joining players. Also, Swampcore had a 24/7 thunderstorm, which prevents mobs from burning up during the day and even allowed them to spawn in the middle of the day. I've managed to more or less copy all of this behavior using nothing more than the vanilla server, and here's how I did it:

First, the superflat preset I'm using is this:

2;0,49,1,2x7,3,2;6;biome_1,decoration,lake,lava_lake

Put simply, from the bottom up you have: 1 layer of air, 1 layer of obsidian, 1 layer of stone, 2 layers of bedrock, 1 layer of dirt, and 1 layer of grass. It's set in a swamp biome, with lakes and lava lakes, and sometimes the stone blocks (around lava lakes for example, or in the stone layer) might spawn ores.

So, go into creative mode and find the world's spawn point (give yourself a compass and go to where the needle points to, until you get to the point where the needle flips the opposite direction when you cross onto the next block). This is the center of the spawn point.

The server's spawn protection radius should be reasonably large (16 blocks should do). The protection radius basically prevents any users who aren't the operator from being able to change any blocks (destroy or place any). It also prevents them from activating any redstone devices except for pressure plates. They couldn't even open wooden doors in the protection zone.

Build a bunker out of bedrock. Here's what mine looked like:

(Click this and other screenshots for full size versions)

I put an iron door on my bunker and have a stone button that opens it. The button couldn't be activated by a non-operator, and as you'll see shortly, it should be unreasonably difficult for a non-operator to grief your bunker by having a creeper explode next to it.

Inside the bunker, build a redstone circuit designed to run on an infinite loop. I put a bunch of repeaters around, all set to the longest delay (right click 3 times), to keep the loop from bunching up on itself. When you're ready (not yet!), you'll place a redstone torch on the raised bedrock block and then immediately destroy it, so that it's only there long enough to give a quick pulse to the circuit and get it started.

Pro Tip: the 5x5 chunk radius surrounding the spawn point is always loaded in memory. Any redstone circuit that runs there will never be unloaded from memory even if all the players wander far away, so it's a good place to put your infinitely looping circuits that enforce "rules" on your server. The spawn protection radius is icing on the cake as well, as it automatically protects your circuit from being interfered with by other players (note that creepers and TNT launched from outside the protected zone can still damage the protected blocks).

In part of the circuit, make sure the redstone runs over the top of a command block. Use /give <your name> 137 to give yourself a command block to place. You'll definitely need to be an operator and in creative mode to set the command on the block. Hint: you can place redstone on top of the block by holding down the Shift key while you place the redstone.

The command I have here is this:

/tp @a[m=0,r=36] -336 202 179

This command will teleport all Survival Mode players (m=0), within a radius of 36 blocks from this command block, up to the coordinates -336, 202, 179. These coordinates in my case are, the spawn point, 202 blocks up into the sky.

The radius is set to 36 to make sure it fully encompasses the entire spawn region of the server. So anybody who joins the server or dies without a bed, they'll spawn on the surface (probably) within this radius and be immediately sniped up to the teleport spot. Players in Creative Mode are not affected, so that the operator can still get into the bedrock bunker to restart the redstone circuit in case it fails for any reason, or whatever.

Up in the sky above the spawn point, I built this floating room:

The floor of this room is at Y=200... I set the command block on the surface to teleport players to Y=202 just to have them off the floor a little bit. YMMV.

This room is a lot like their Swampcore server. It's a radially symmetrical room (looks the same on all 4 sides) with command blocks surrounding the perimeter. This is so that when you die and respawn and come back to this room, it won't be easy to know which pressure plate you used the last time. Even if you remember you "used the one in the middle", you still only have a 25% chance of guessing the same exact one as last time. The pressure plates are all rigged to command blocks to teleport players to a spot within a large radius, to evenly distribute them across the overworld.

Here is a view of this floating room from above. I put a roof area and a hole to drop down into the room just in case a user happens to spawn on top of the roof, instead of somewhere on the surface near the bedrock bunker. Hey, it happens. Note that since this room is still within the spawn protection zone, the blocks can't be destroyed or altered by the players unless they're operators. And since the room is so high in the air, the odds of getting a creeper up here, or launching TNT into the spawn region from outside to damage the room are extremely low.

Just like with the bedrock bunker, I have an iron door with a stone button for maintenance work (if needed) for the server operator. Even if a survival mode player spawns on the roof and drops down to this door, they can't get inside because of the protection radius.

This is a view from inside the maintenance room, directly below the main spawn room. These are all the command blocks that are positioned underneath the pressure plates above. I placed wooden signs under each command block that tells me the coordinates that the block will teleport you to. I also placed stone buttons on the side of the block (hint: hold down Shift to place the buttons), for testing purposes. Both the button and the pressure plate above will activate the command block.

The commands I used on these blocks are along these lines:

/tp @p 500 7 -1000

This teleports them to Y=7 (the level of the surface in my world), at the X/Y coordinates that are mentioned on the wooden signs below the command block. The @p targets the nearest player, which will usually be the one standing on the pressure plate above.

And that's all there is to it. If players find their way back to the spawn region, they can't get anywhere near the bunker without being teleported back up to the welcome room. The only way they could attack the bunker would be to somehow fling TNT over 36 blocks towards the bunker (an amazing feat in itself), but it being made of bedrock they wouldn't be able to do a whole lot of damage to it. The only way they could attack the welcome room would be to build up a super large tower to the top of the world, build a bridge as close as they're allowed to (within what the spawn protection radius will allow), and then fling TNT from all the way over there. If you set your radius high enough, even this will be highly impractical.

As for the 24-hour thunder storm... you could use another command block down in the bedrock bunker that does /weather thunder to make sure the weather stays tempestuous. Personally, I have a cron job that runs my make-it-rain script every 2 minutes. This is my cron entry for anyone interested:

*/2 * * * * /home/minecraft/bin/make-it-rain swampcore thunder 9000

Install PAR::Packer on Windows

I recently had need to install PAR::Packer on Windows (for those that don't know, pp is the best fully-open-source way to build a stand-alone .exe file from a Perl script, which doesn't require a Perl installation to run). I had installed pp on Windows a long time ago, but the process seems to have changed a bit so here's my experience doing it now, what problems I ran into, and how I fixed them.

Versions:

• Windows: Windows XP Professional, 32-bit
• Perl: ActivePerl 5.16.2 for Windows 32-bit
• PAR::Packer: 1.014
• Module::ScanDeps: 1.10

The Makefile.PL from PAR::Packer lists what other dependencies it has. These were all available in ActivePerl's PPM repository so they were easy to install, for example, ppm install Win32-Exe.

nmake 1.5?

A long time ago, you used to be able to download this stand-alone nmake binary from Microsoft, which replaced the usual make command from Unix. But, it seems Microsoft has pulled this download offline and they want you to install some kind of Visual Studio Express app that provides a newer version of nmake. I ended up finding a copy of nmake somewhere else on the Internet, which I've hosted here: nmake15.zip (NOTE: You might not need nmake, I later found out ActivePerl comes with dmake which worked for installing other modules, YMMV).

The only modules I needed to manually install (perl Makefile.PL; nmake; nmake install) were Module::ScanDeps and PAR::Packer, but running nmake gave this rather cryptic error message:

to undefined at C:/Perl/lib/ExtUtils/Install.pm line 1208

I found this relevant Perlmonks article. What I needed to do was open the Makefile (not Makefile.PL; the one with no extension) in Wordpad, and do a Find/Replace of {{@ARGV}} to {@ARGV}, and then nmake ran just fine.

For my project I needed to manually install Template::Toolkit, and the Makefile.PL told me to run dmake. Running this worked just fine without requiring me to manually modify the Makefile. If this is available, I imagine it would probably work better for you then nmake.

Anyway, after installing PAR::Packer's dependencies, PAR::Packer installed and ran just fine.

Steam for Linux in Fedora x64

Update: Spot has a Steam yum repository set up. Download steam.repo to your /etc/yum.repos.d directory, and then yum install steam. When I originally wrote this post, Spot's steam repo was gone (that link gave a 404).

---

Just a quick post about how to install the Steam for Linux client on 64-bit Fedora Linux.

This works for Fedora 17 x64. I'm not sure it will work in Fedora 18 or later versions when they come out, but I'll probably test that at some point too and update this post.

NOTE: It should go without saying, but the terminal commands I list below begin with a $ sign -- you don't type this symbol. That represents your prompt. So when it says "$ yum install ..." you just type "yum install ..."

1. Download the steam.deb Ubuntu package (currently, Steam only officially supports Ubuntu 12.04) - link that works as of the time of this writing.
2. Open the .deb in an archive manager, such as Gnome's file-roller. Extract data.tar.gz from the .deb file.
3. Extract data.tar.gz somewhere like ~/steam - put it in an empty folder, so after extracting, this folder will only contain the directories "etc" and "usr"
4. In a terminal, switch to the directory you extracted data.tar.gz to, and run:
   $ sudo cp -r * /
   Alternatively, open a file manager like Nautilus as the root user if you'd prefer to do a copy/paste visually.
5. You'll also have to install the 32-bit versions of some libraries that Steam depends on. Run this command in a terminal:
   $ sudo yum -y install libpng.i686 libpng-compat.i686 gtk2.i686
6. Run Steam either by the steam command in your terminal, or via your application menu.

And it should work. You will probably also need to install 32-bit support libraries for your video card, for example xorg-x11-drv-nvidia-libs.i686 for recent NVIDIA video cards (assuming of course you're using kmod-nvidia and not the default nouveau drivers!). You're on your own here though, but this Crossover Wiki page may help.

Problems?

If you get an error that says "Failed to load steamui.so", this will be caused by missing dependency errors. Steam will need the 32-bit versions of some libraries it depends on, which don't get installed by default in a 64-bit Fedora OS. Re-read the steps above and make sure you installed the 32-bit versions of libpng, libpng-compat, and gtk2. If they're all installed, it may be another library (I personally only had to install the three listed). The general procedure to track down missing libraries in Linux is as follows:

1. In a terminal, navigate to Steam's library folder, which (as of right now) should be in $HOME/.local/share/Steam/ubuntu12_32
2. Run this command to list the missing library dependencies for steamui.so:
   env LD_LIBRARY_PATH="$PWD:$LD_LIBRARY_PATH" ldd steamui.so | grep "not found"
3. If this command shows no results, this means there are no missing libraries and everything should be working. If it does list results, continue reading.
4. For example, if it says "libgtk-x11-2.0.so.0 => not found", run this command to identify the package in Fedora that provides that file:
   yum provides '*/libgtk-x11-2.0.so.0'
5. This will list packages like gtk2-2.24.10-1.fc17.i686 : The GIMP Toolkit (GTK+), a library for creating GUIs for X (there will also be a ".x86_64" version, but we don't care about those because we need the 32-bit libraries).
6. Ignore the version number part of the package and just sudo yum install gtk2.i686 -- make sure to include the .i686 part, otherwise Fedora will just assume you want 64-bit because it matches your current architecture.

Good luck!

Android 4.0 in VirtualBox

This information is a little hard to find on the Internet. This is how to install Android 4.0 (Ice Cream Sandwich) in VirtualBox, in a "do it yourself" way (installing from an ISO image). There are some people who have made pre-installed VirtualBox images, but one problem you may run into going that route is that the Android serial number will match everybody else who's using the same image as you, since Android generates this number on its first boot.

Screenshot of my Android VM. Click for bigger version.

Getting an Android ISO

The folks at Android-x86 have been making x86 builds of the Android OS for quite a while now, and none of this would be possible without them. They have ISO images for various versions of Android available, but most of them don't work very well in VirtualBox. For example, their "eeepc" image for Android 4.0 has issues with the audio drivers and the network (it has no Ethernet support built in, etc.)

So this means using one of the Android-x86 images from there won't get you too far because audio and networking won't work. Fortunately, somebody has put together an ISO image that's been custom tailored to VirtualBox. I don't remember where I found this ISO image; if it's yours, leave me a comment and I'll edit this post. I found the ISO here: android-x86 VirtualBox/VMWare support (thanks @jakimfett!)

I have a copy of this ISO hosted here: android-x86-vm-20120130.iso (244MB). This ISO works much better.

Create a Virtual Machine

In VirtualBox, create a new machine for Android.

• Machine Name: "Android ICS" (you can name it anything you want)
• Machine Type: "Linux 2.6"
• Memory: I gave my VM 1024MB of memory.
• Hard Disk: I created a new 16GB VDI image that dynamically expands.

All the default settings worked fine for me. Here's what the defaults were on my system:

• Networking:
  • Type: NAT
  • Adaptor: "Intel Pro/1000 MT Desktop (82540EM)"
• Audio: Intel AC'97
• Storage Layout:
  • IDE Controller:
    • CD Device
  • SATA Controller:
    • Hard Disk

Update: In the comments, @Ni mentions this:

Make sure you add the SATA Controller if it does not appear, when you setup the virtual box and then add the ISO image and virtual disk image to this.

If you try and add the ISO image and virtual disk image to the IDE Controller this will not work at.

This information maybe useful to someone making this mistake.

It worked for me as listed above (IDE CD drive, SATA hard disk), but this is something to keep in mind if you have any issues booting the CD or installing it to disk.

Installation

Make sure the VM boots from the ISO image.

1. On the boot screen, select "Installation - Install Android-x86 to harddisk"
2. Choose "Create/Modify Partitions". This takes you into cfdisk.
   1. Choose "[New]"
   2. Choose "[Primary]"
   3. Press enter to accept the default partition size (mine was 17174.38)
   4. Choose "[Bootable]"
   5. Choose "[Write]"
   6. Type "yes" to confirm writing.
   7. Choose "[Quit]"
3. Choose to install on the sda1 device (Linux VBOX HARDDISK)
4. Choose to format the drive "ext3"
5. Pick "Yes" to confirm formatting.
6. Pick "Yes" when it asks to install the GRUB bootloader.
7. Pick "Yes" when it asks to mount /system as read-write (this will be important later to install the Google apps).
8. Create a fake SD card when it prompts. I made mine 2047MB (the maximum allowed).
9. Choose "<Reboot>"

Make sure you detach the ISO image from the virtual machine so that it will boot into the installed OS. If you see the "Installation" option again, it means you're booting from the ISO still!

Tips for Running Android

You'll want to disable mouse integration to be able to interact with the GUI at all. This can be done from choosing the "Machine" menu in the VM window and clicking "Disable Mouse Integration" -- or pressing HostKey+I.

The Escape key on your keyboard corresponds to the Back key in Android. The context menu key on your keyboard corresponds to the Menu button in Android (the context menu key is usually next to the right Windows key).

To power off the VM, press HostKey+H. This will cause Android to pop up the shutdown dialog that you'd expect on a real phone. You can also use the "Machine->Send Shutdown Signal" to do the same.

Install the Google Apps

You may notice that this Android VM doesn't include the Android Market, GMail, or Google Maps. These are some of the Google Apps and due to some licensing restrictions Android-x86 doesn't include them "out of the box".

On a real Android device that's been rooted and flashed with a custom ROM, you'd install the Google apps by flashing them in recovery mode. But you can't get into recovery mode on VirtualBox. Thus, the method for installing the Google Apps is kinda sketchy, but it works (and if you know of a better way, feel free to tell me).

You'll need a file with a name like "gapps-ics-20120304-signed.zip". These are the Google apps (the date part might be different). You can Google them, but I have a copy of them here to download too.

You don't really need the entire Google Apps file, actually. Just the "system" folder inside the zip file. Create a new tar file of the "system" folder so that it will be easy to get it into your Android device. I have a prepared "system.tar.gz" for you if you just want to use mine.

• GApps Download Links:
  • gapps-ics-20120304-signed.zip (52MB)
  • system.tar.gz (just the /system folder; 28MB)

The steps to install the Google Apps are as follows:

1. Download system.tar.gz to your Android VM somehow. I used the Web Browser app and downloaded it there. You could probably also use the Email app, or if you're really Android savvy, push it with the Android Debugger.
   • If Android tells you that there is no SD card so it can't download the Google Apps, that's because you skipped that step while first installing your Android system. The very last step of the installer asks if you'd like to create a virtual SD card partition, and you should've had it do that. If you didn't, the only easy solution I know of is to reinstall the OS.
2. Open the "Terminal Emulator" app in Android.
3. Enter these commands (note: don't type the $ or # symbols at the beginning of these lines. These symbols indicate the prompt.)

   $ cd /sdcard/Download
   $ tar -xzvf system.tar.gz
   $ su
   # cd /sdcard/Download
   # cp -rf system/* /system/

   Pay special attention to the cp -rf command. Make sure the slashes and *'s are in the right places.
4. Reboot the phone.

You should now see the Market app, GMail and the others in your app menu.

Note: in my experience, the Market app will be somewhat unstable. When you start the app, it will Force Quit after 10 or 15 seconds. However, if you're fast enough you should be able to quickly search for a specific app you'd like and begin the download process before Market crashes, and the app will continue to download and install regardless.

I imagine that the unorthodox way of installing the Google Apps might be partly to blame for the Market being unstable. The other Google apps seem to work fine though.

Custom Screen Resolutions

This is a tip I discovered somewhere a while back for getting custom resolutions to work in your Android VM (for example, to mimic the screen dimensions of the Galaxy Nexus phone, or just to run the VM at a higher resolution like 1024x768). I've found that you can use just about any arbitrary resolution you want, but when the resolution isn't a standard 4:3 one (like 1024x768), the VM seems to get somewhat laggy.

The general steps are as follows. Substitute 1024x768 with whatever resolution you want. You can add multiple video modes by changing "CustomVideoMode1" to be "CustomVideoMode2", etc.

1. In your Terminal or Command Prompt window on the host system, run this command:
   VBoxManage setextradata "Android ICS" "CustomVideoMode1" "1024x768x32"
   Substitute "Android ICS" with the name of your VM (but keep the quotes).
2. Start your Android VM, and when you see the bootloader screen:
   1. Press the "e" key to edit the boot arguments
   2. Press "e" again to edit the kernel boot line
   3. Add UVESA_MODE=1024x768 to the end of the boot arguments (make sure to hit Space first), and press Enter.
   4. Press "b" to boot.

There should theoretically be a way to edit the GRUB config file and add more boot options that have the custom resolutions already configured, but I'll leave that as an exercise for the reader.

No Warranty

Android is primarily an ARM architecture operating system and the x86 version isn't supported by Google. While a lot of apps will work in Android-x86, some may crash in weird ways. If you're an Android developer though, this can be pretty useful because Android-x86 will run a lot faster on your hardware than the standard emulator from the SDK does, so you can test your apps much more rapidly (the Android-x86 site has some documentation on how to connect ADB to your virtual machine).

Your mileage may vary.

Updates

To answer common questions that come up in the comments...

• Adobe Flash, Netflix, others... -- these apps won't work in Android-x86, because they aren't pure Java. They include C code that's compiled for the ARM processor found in most Android devices. They won't run on x86 processors.
• Apps that rotate your screen... -- apps that force the orientation into portrait mode (thus turning your screen sideways) can be dealt with by changing your VM's screen resolution to be taller than it is wide (i.e. 800x1280). The app will recognize the portrait resolution and not rotate. However, your VM may be laggy when it's not in a standard 4:3 resolution. Alternatively, find an app that forces/locks your orientation to one direction or another -- however, some apps misbehave when forced to use the wrong resolution and may not be usable.
• Don't expect a lot of apps to work -- for various reasons, apps that work on real Android devices may not function properly on Android-x86.
• Text messaging and phone calls won't work -- Your virtual machine is not a phone. It doesn't have a cellular connection to AT&T or Verizon or anybody. The standard texting apps like Messaging and Handcent SMS are useless on an Android VM (this also goes for most Android tablets that don't have cell connections). If you want to text from your VM, you might try using the Tablet Talk app, connect it with your actual cell phone, and text through that app. If you want to make phone calls, you might have luck with a Voice over IP app -- however, I can't guarantee your microphone and such will work with the VM, as I haven't tested it.

I'll update the list above as more common questions come in from the comments below.