2011
HOWTO Install Mac OS X 10.7 Lion From DVD
23/06/11 12:07 Filed in: Mac
Apple would have you believe that the only way to install Lion on a Mac is to install 10.6 Snow Leopard, update it to the latest revision, go to the Mac App Store, download Lion from there and run it.
Cobblers.
It is trivially simple to burn Lion to a DVD or USB stick so you can install it onto a clean Mac without having to install anything first. Obviously firstly you need to get a copy of Lion from the Mac App Store, but only bother doing that once.
Then all you need to do is use Disk Utility to either burn that to a DVD or write it to a USB stick.
Burn InstallESD.dmg to DVD
Write InstallESD.dmg to USB stick
Now you can put the DVD or USB stick into the Mac you want to use for Lion, and hold down the Option/Alt key while you power on the Mac. Keep Option/Alt held down until a picture of your bootable devices appears. Select the DVD or USB device you want to boot from (the one you just wrote) and the standard Lion installer will appear in a while.
Cobblers.
It is trivially simple to burn Lion to a DVD or USB stick so you can install it onto a clean Mac without having to install anything first. Obviously firstly you need to get a copy of Lion from the Mac App Store, but only bother doing that once.
- Right-click on the Lion application and choose “Show Package Contents”.
- Navigate into the Contents/SharedSupport folder.
- In there you will see a huge file called “InstallESD.dmg”.
Then all you need to do is use Disk Utility to either burn that to a DVD or write it to a USB stick.
Burn InstallESD.dmg to DVD
- Run Disk Utility.
- Drag InstallESD.dmg from a Finder window into the bottom left pane in Disk Utility.
- Click the “Burn” button in the toolbar.
Write InstallESD.dmg to USB stick
- Run Disk Utility.
- Insert your USB stick and wait for it to appear in the list of devices in the top-left pane in Disk Utility.
- Select your USB stick in Disk Utility.
- Click on “Erase” in the right pane, enter the name “Lion” and click the “Erase...” button. Note: This will totally wipe all of your USB stick. Make sure there are no files or apps on there that you need!
- After it has erased, click on “Restore” in the right pane.
- Drag InstallESD.dmg from a Finder window into the “Source” box.
- Drag the “Lion” icon (immediately below your USB stick) from the top-left pane to the “Destination” box.
- Ensure the “Erase destination” box is ticked.
- Click the “Restore” button.
Now you can put the DVD or USB stick into the Mac you want to use for Lion, and hold down the Option/Alt key while you power on the Mac. Keep Option/Alt held down until a picture of your bootable devices appears. Select the DVD or USB device you want to boot from (the one you just wrote) and the standard Lion installer will appear in a while.
Comments
Installing Mac OS X Lion Developer Preview 4 on 2011 MacBook Pro
09/06/11 09:09 Filed in: Mac
If you try to install Lion Developer Preview 4 on a 2011 MacBook Pro (certainly the 13” model, not sure about 15” or 17&rdquo
, it will crash the first time it tries to boot in order to do the bulk of the installation.
Here is how to work round it:
Let us hope they fix this shortly!
, it will crash the first time it tries to boot in order to do the bulk of the installation.Here is how to work round it:
- Get a copy of the whole of /System/Library/Extensions/IO80211Family.kext from Developer Preview 3. Alternatively I have a copy stashed away (zipped, unpack it first). Put that copy on another Mac, or another bootable partition.
- Run the “Mac OS X Lion Developer Preview 4” app.
- Keep your eyes on it. As soon as it starts to reboot, hold down the Shift key.
- The installer will now run — if it doesn’t, do step 7 now and try again. I’m unsure exactly what will stop the installer from running.
- At the end of the installation, it will reboot and crash.
- Hold down the power button until it switches off.
- Using either Target Disk Mode or your other bootable partition, overwrite the whole of /System/Library/Extensions/IO80211Family.kext with the copy you saved earlier.
- Reboot. Lion Developer Preview 4 will now boot normally.
Let us hope they fix this shortly!
Shrinking VMDK virtual hard disks in vSphere
There is a bug in VMware vSphere 4.1.
You should be able to reclaim the space in a virtual hard disk (VMDK) by zeroing out all the free virtual disk space with “sdelete” or “dd”, and then migrate it (Storage vMotion) to a different datastore as a Thin provisioned disk. VMware will look for all the blocks full of zeroes and remove them from the VMDK image, often drastically reducing the amount of physical disk space it occupies.
The bug is that if the 2 datastores (source and destination of the migration) have the same block size, VMware does not remove the blocks of zeroes.
To make it work, just migrate it to a datastore with a different block size, and migrate it back where you want to keep it.
To find the block size of a datastore, in vSphere Client go to Home —> Inventory —> Datastores. Select the datastore, and switch to the “Configuration” tab on the right-hand side of the window.
I appreciate that most people format all their datastores with 8MB block size, as that allows the greatest maximum VMDK file size (2Tbytes). This is a very good reason to keep at least 1 datastore with a different block size!
So the full procedure for Windows is
For Linux, it’s like this
You should be able to reclaim the space in a virtual hard disk (VMDK) by zeroing out all the free virtual disk space with “sdelete” or “dd”, and then migrate it (Storage vMotion) to a different datastore as a Thin provisioned disk. VMware will look for all the blocks full of zeroes and remove them from the VMDK image, often drastically reducing the amount of physical disk space it occupies.
The bug is that if the 2 datastores (source and destination of the migration) have the same block size, VMware does not remove the blocks of zeroes.
To make it work, just migrate it to a datastore with a different block size, and migrate it back where you want to keep it.
To find the block size of a datastore, in vSphere Client go to Home —> Inventory —> Datastores. Select the datastore, and switch to the “Configuration” tab on the right-hand side of the window.
I appreciate that most people format all their datastores with 8MB block size, as that allows the greatest maximum VMDK file size (2Tbytes). This is a very good reason to keep at least 1 datastore with a different block size!
So the full procedure for Windows is
- Download “sdelete” from Microsoft.
- Run the command “sdelete -c C:” from a Command Prompt, while logged in as an Administrator.
- Migrate the VM from its current datastore to one with a different block size. Be sure to select “Thin provisioned format”.
- Migrate it back again.
- Bingo! You have all your unused disk space back.
For Linux, it’s like this
- Run the command “dd if=/dev/zero of=BIGFILE bs=1024000 ; rm -f BIGFILE”. If you have several large filesystems in the VM, then do this while your current directory is inside each one in turn. You only need to be root if you have user quotas enforced (most people don’t). But it does no harm to run the command as root if you want to.
- Migrate the VM from its current datastore to one with a different block size. Be sure to select “Thin provisioned format”.
- Migrate it back again.
- Bingo! You have all your unused disk space back.
VMware Data Recovery log analyser
Update: Improved error reporting, so script generates a “Failed” email if the log copy fails.
vSphere 4.1 and ESXi 4.1 are both very bad at letting you monitor what has happened with the VMware Data Recovery backup system. You cannot currently even email the log.
So I have written a log analyser which takes the raw VDR log file (similar to the log file viewable in the vSphere plugin) and works out what has happened since it was last run.
The log you see in the plugin is actually a heavily processed version of the raw log file, which is not remotely readable.
You can download my script for free. It’s a short Perl script that uses “iconv” to do the UTF-16 to UTF-8 conversion needed, and the “sendmail” binary (which is provided by all major email systems) to send the email report.
There is a comment at the top that you should read, and there is a little block of definitions which you should adapt for your setup. But otherwise it should work on any Linux distribution without further modification.
You may use my script for free, but please do not charge anyone any fee, monetary or otherwise, for the ability to use it in any form or derivative.
As an example of the output, here’s a little chunk of the email it sends:
21/12/10 08:22 VM Win2008R2x64 Server Source Ok
21/12/10 08:23 FAIL kanga-az1g10 Execution incomplete Trouble reading files, error -3948 ( vcb api exception)
21/12/10 08:24 VM kanga-hl1g09 Ok
21/12/10 08:31 VM kanga-cl14e10 Ok
21/12/10 08:31 VM kanga-cm7e09 Ok
21/12/10 08:34 VM kanga-bc2e10 Ok
21/12/10 08:56 Operation Verify (Execution unit 1) Ok
21/12/10 08:59 VM kanga-amg Ok
vSphere 4.1 and ESXi 4.1 are both very bad at letting you monitor what has happened with the VMware Data Recovery backup system. You cannot currently even email the log.
So I have written a log analyser which takes the raw VDR log file (similar to the log file viewable in the vSphere plugin) and works out what has happened since it was last run.
The log you see in the plugin is actually a heavily processed version of the raw log file, which is not remotely readable.
You can download my script for free. It’s a short Perl script that uses “iconv” to do the UTF-16 to UTF-8 conversion needed, and the “sendmail” binary (which is provided by all major email systems) to send the email report.
There is a comment at the top that you should read, and there is a little block of definitions which you should adapt for your setup. But otherwise it should work on any Linux distribution without further modification.
You may use my script for free, but please do not charge anyone any fee, monetary or otherwise, for the ability to use it in any form or derivative.
As an example of the output, here’s a little chunk of the email it sends:
21/12/10 08:22 VM Win2008R2x64 Server Source Ok
21/12/10 08:23 FAIL kanga-az1g10 Execution incomplete Trouble reading files, error -3948 ( vcb api exception)
21/12/10 08:24 VM kanga-hl1g09 Ok
21/12/10 08:31 VM kanga-cl14e10 Ok
21/12/10 08:31 VM kanga-cm7e09 Ok
21/12/10 08:34 VM kanga-bc2e10 Ok
21/12/10 08:56 Operation Verify (Execution unit 1) Ok
21/12/10 08:59 VM kanga-amg Ok