Moving or Upgrade Old Mac HD to a New Mac HD

Okay. Moving or Upgrading from an old Mac HD (including its partition, boot, installation, recovery) to a new Mac HD (maybe because you want to increase the capacity to a higher HDD) is relatively an easy task.  The hard part is just for the preparation on how you want to partition your new HDD.  Here is my story.

I am coming from an old MacBook (early 2009 edition – the white one) and my latest maximum Mac OS X version that I can install is the Mac OS X Lion 10.7.  Since I am a developer, I increased the RAM capacity to 4GB – the maximum it can get.  Now I am planning to increase its internal HDD size from 120GB to 500GB since I have a spare 500GB HDD that I am not using anymore.

As I am writing this blog, I am also doing the upgrade at the same time.  Here goes:

Partition Planning

My old Mac HDD (120GB) have by default 3 partitions – a MacBook partition is the primary bootable partition and this is where the Mac OS X Lion is installed and this is also where I am installing any apps I might have.  My second partition is the Data partition which is where I am storing my data (unencrypted – since I hardly connect to the net from the Mac) – data includes my huge collection of music files (Hey, I love music!)  The third partition, is the mandatory Mac Recovery partition – which is named Mac OS X Base System.  This is where we will boot just in case anything goes wrong and we want to re-install the Lion again.

First, get your Mac OS X Lion DVD and boot from it. Holding Option key when the Mac is starting up.  Then open the Disk Utility.

Now, I got my external USB drive, and then change the HDD inside into my spare 500GB drive.  Inserted it. Erase *all* of its partitions from the Disk Utility.  Then setup my own partition, which goes like this:

Partition 1: MacBook – main bootable partition to which we will clone our old previous installation into this.  I set this into 200GB.

Partition 2: Data – my data, and music partition – 200GB

Partition 3: Reserve partition – to which I am planning to install Kali Linux and CentOS for experiments (developers love to experiments) – I assigned 98GB for this.

Partition 4: Recovery partition – Mac Lion needs 2GB of space for this.

When all is said and done, click Apply so that your partitions will be saved.  Also be sure to backup first your data before doing this since changing the partition WILL erase all your data from your new HDD.

Cloning

There are ants crawling on my computer, I hate them now.  Anyway, the second process is to Clone your previous partitions into your new partitions.  Cloning is the right term since basically it will copy ALL files, boot, permissions, folders, from your old HDD to your new one.  It doesn’t matter if the size of both HDD is different.  Theoretically since I am upgrading to a higher size HDD, I have no problem.

Now, to clone the main partition from your old HD to your new one, click the main partition and then click the “Restore” tab.  You will see that there are input fields labelled Source: and then Destination.

Drag the main partition into the source, and drag the new main partition into the destination field, and then click the Restore button.  This will copy everything from the source to the destination; erasing everything from the destination.  It will just ignore the free spaces, so it should have no problem if your HDD have different sizes.

Do this for the (1) main partition, (2) data partition, and (3) recovery partition.

Then you are done!  If you have more data, then the process will take longer.  Please wait until finish.

Checking

To check, restart your Mac, and hold the Options key while booting.

It will display a list of bootable partitions to which your Mac can boot.  At the minimum, it should display: (1) Old main partition, (2) Old recovery partition, (3) New main partition, (4) New recovery partition.

Once you see this 4 partitions, you are good to go.

You can then open your MacBook and then remove the old HD, and replace it with your new HD.  And when you boot, holding the Options key, you would then see the 2 partitions from your New HD (the main, and the recovery)

Advertisements

Subversion client connecting using SVN+SSH

If you have different username from the SVN remote:

Setup ssh_config
Host <www.domain.com>
User <username in the domain.com>

Subversion and SSH

Subversion allows you to use SSH as the network protocol by using the svn+ssh:// scheme in the repository URL. One downside to this is that the only way to specify your remote username is in the URL, for example:

svn+ssh://dribin@svn.example.com/repo

This is all fine and dandy if you’re just doing a checkout, but this can cause problems if you want to use the svn:externals property. If you include a username in your URL, no other user can use the external without your remote password. Ideally, you want to allow each user to use their own username in the URL. Unfortunately Subversion has no way to override the SSH username in the URL. The trick around this is to not use usernames in URLs at all:

svn+ssh://svn.example.com/repo

You can then specify your remote username in your $HOME/.ssh/config:

Host svn.example.com

User dribin

OpenSSH Public Key Authentication

Public Key Setup | Configure ssh-agent Process | Agent Forwarding

Secure Shell (SSH) public key authentication can be used by a client to access servers, if properly configured. These notes describe how to configure OpenSSH for public key authentication, how to enable a ssh-agent to allow for passphrase-free logins, and tips on debugging problems with SSH connections. Password free logins benefit remote access and automation, for example if administering many servers or accessing version control software over SSH.
Public key authenticate can prevent brute force SSH attacks, but only if all password-based authentication methods are disabled. Other options to protect against brute force SSH attacks include pam_tally, or port knocking. Public key authentication does not work well with Kerberos or OpenAFS, which require a password or principal from the client.
Definition of terms used in this documentation:

  • Client: the system one types directly on, such as a laptop or desktop system.
  • Server: anything connected to from the client. This includes other servers accessed through the first server connected to.

Never allow root-to-root trust between systems. If required by poorly engineered legacy scripts, limit the from access of the public keys, and if possible only allow specific public keys to run specific commands. Instead, setup named accounts for users or roles, and grant as little root access as possible via sudo.

For more information, see also SSH, The Secure Shell: The Definitive Guide. SSHKeyChain offers integration between the Apple Keychain and OpenSSH.

Public Key Setup

Key Generation | Key Distribution | Key Access Limits
First, confirm that OpenSSH is the SSH software installed on the client system. Key generation may vary under different implementations of SSH. The ssh -V command should print a line beginning with OpenSSH, followed by other details.
$ ssh -V
OpenSSH_3.6.1p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090702f

Key Generation

A RSA key pair must be generated on the client system. The public portion of this key pair will reside on the servers being connected to, while the private portion needs to remain on a secure local area of the client system, by default in ~/.ssh/id_rsa. The key generation can be done with the ssh-keygen(1) utility.
client$ mkdir ~/.ssh
client$
chmod 700 ~/.ssh
client$
ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
Enter passphrase (empty for no passphrase): …
Enter same passphrase again: …

Do not use your account password, nor an empty passphrase. The password should be at least 16 characters long, and not a simple sentence. One choice would be several lines to a song or poem, interspersed with punctuation and other non-letter characters. The ssh-agent setup notes below will reduce the number of times this passphrase will need to be used, so using a long passphrase is encouraged.
The file permissions should be locked down to prevent other users from being able to read the key pair data. OpenSSH may also refuse to support public key authentication if the file permissions are too open. These fixes should be done on all systems involved.
$ chmod go-w ~/
$
chmod 700 ~/.ssh
$
chmod go-rwx ~/.ssh/*

Key Distribution

The public portion of the RSA key pair must be copied to any servers that will be accessed by the client. The public key information to be copied should be located in the ~/.ssh/id_rsa.pub file on the client. Assuming that all of the servers use OpenSSH instead of a different SSH implementation, the public key data must be appended into the ~/.ssh/authorized_keys file on the servers.
# first, upload public key from client to server
client$
scp ~/.ssh/id_rsa.pub server.example.org:

# next, setup the public key on server
server$ mkdir ~/.ssh
server$
chmod 700 ~/.ssh
server$
cat ~/id_rsa.pub >> ~/.ssh/authorized_keys
server$
chmod 600 ~/.ssh/authorized_keys
server$
rm ~/id_rsa.pub
Be sure to append new public key data to the authorized_keys file, as multiple public keys may be in use. Each public key entry must be on a different line.
Many different things can prevent public key authentication from working, so be sure to confirm that public key connections to the server work properly. If the following test fails, consult the debugging notes.
client$ ssh -o PreferredAuthentications=publickey server.example.org
Enter passphrase for key ‘/…/.ssh/id_rsa’: …

server$

Key distribution can be automated with module:authkey and CFEngine. This script maps public keys stored in a filesystem repository to specific accounts on various classes of systems, allowing a user key to be replicated to all systems the user has access to.
If exporting the public key to a different group or company, consider removing or changing the optional public key comment field to avoid exposing the default username and hostname.

Key Access Limits

As an optional step to limit usage of the public key for access to any servers, a from statement can be used before public key entries in the ~/.ssh/authorized_keys file on the servers to limit where the client system is permitted to access the server from. Without a from limit, any client system with the appropriate private key data will be able to connect to the server from anywhere. If the keypair should only work when the client system is connecting from a host under example.org, set from=”*.example.org before the public key data.
server$ cat ~/.ssh/authorized_keys
from=”*.example.org” ssh-rsa AAAAB3NzaC1…

If a text editor is used to add the from option, ensure the data is saved as a single line; some editors may wrap the public key and thus corrupt the data. Each public key in the ~/.ssh/authorized_keys file must not span multiple lines.
Multiple hosts or addresses can be specified as comma separated values. For more information on the syntax of the from option, see the sshd(8) documentation.
from=”*.example.org,10.*,external.example.com” …

Configure ssh-agent Process

To reduce the frequency with which the key passphrase must be typed in, setup a ssh-agent(1) daemon to hold the private portion of the RSA key pair for the duration of a session. There are several ways to run and manage ssh-agent, for example from a X11 login script or with a utility like Keychain. These notes rely on the setup of ssh-agent via an @reboot crontab(5) entry, along with appropriate shell configuration.

The ssh-agent must only be run on the client system. The private key of the RSA key pair must remain on the client system. Agent forwarding should be used to make the key available to subsequent logins to other servers from the first server connected to.

1. Startup cron job

    The following crontab(5) entry should run the agent at system startup time. The crond daemon on BSD and Linux systems should support the special @reboot syntax required for this to work.

    @reboot ssh-agent -s | grep -v echo > $HOME/.ssh-agent

    To setup the agent for the first time without having to reboot the system, run the following.

    $ nohup ssh-agent -s > ~/.ssh-agent

    Once the ssh-agent is running, any shells already running will need to source in the environment settings from the ~/.ssh-agent file. The SSH_AUTH_SOCK andSSH_AGENT_PID environment variables set in this file are required for the OpenSSH commands such as ssh and ssh-add to communicate with the ssh-agent on the client system.

    $ . ~/.ssh-agent

    Notes on configuring all shells to be able to run arbitrary commands are available. This reduces the initial setup to the following commands, which can be done from the script reagent.

    $ nohup ssh-agent -s | grep -v echo > ~/.ssh-agent

    $ allsh – < ~/.ssh-agent

    If csh or tcsh is being used instead of a Bourne-based shell, replace the -s argument with -c, and the source command used instead of . in any running shells.

    2. Shell startup script changes

      The shell’s startup script on the client system will need to be modified to pull in the required environment settings from ~/.ssh-agent and setup useful aliases. The agent settings in ~/.ssh-agent should not be read in if the client system is being connected to as a server. Remote connections set the SSH_CLIENT environment variable, so~/.ssh-agent must not be read in when this variable contains data.

      [ -z “$SSH_CLIENT” ] && . $HOME/.ssh-agent

      alias keyon=”ssh-add -t 10800″

      alias keyoff=’ssh-add -D’

      alias keylist=’ssh-add -l’

      The -t option to ssh-add will remove keys from memory after the specified number of seconds. This option prevents the keys from being left unlocked for long periods of time. Older versions of OpenSSH will not have the timeout -t option.

      For the csh and tcsh shells, slightly different configuration of the agent and aliases is required. Consult the relevant ssh-agent(1) and shell documentation.

      Once the ssh-agent is running and shell configured to read in the appropriate settings and set easy aliases, enable the key then test a login to a remote server. Thekeyon will only need to be run when initially adding the private key data to ssh-agent, and only rerun if ssh-agent is restarted or the key is removed with keyoff.

      client$ keyon

      client$ ssh server.example.org
      server$ exit
      client$ keyoff
      Use the keylist command to see what keys are in the agent process.

      $ keylist

      1024 01:a1:aa:34:21:bc:7d:a4:ea:56:a4:a1:1a:c5:fa:9f /home/…/.ssh/id_rsa (RSA)
      If password free logins do not work, see tips on debugging problems with SSH connections to work out where the problem may be.

      To make other applications not run from a shell aware of the agent, the environment definitions in the ~/.ssh-agent file will need to be read into the software in question. Consult the documentation for the software to see whether this is possible.

      Agent Forwarding

      For simple client to server connections, SSH agent forwarding will not be a concern. However, if from the server connected to, one logs into other servers, SSH agent forwarding will need to be enabled. If SSH agent forwarding is disabled, a private key must be available on the proxy system that is recognized by the server being connected to.
      To enable forwarding, either use the -A option to ssh when connecting, or set ForwardAgent in an OpenSSH config file, such as ~/.ssh/config. Note that command line arguments override the user-specific configuration file, which in turn can override the global ssh_config configuration file, if any.
      Host *

      ForwardAgent yes


      ForwardX11 no

      Agent (and X11) forwarding may represent a security risk, providing more options to an attacker on a compromised server to work back to the client system. If paranoid, disable Agent and X11 forwarding by default, and only enable the features where needed. Also enable StrictHostKeyChecking and use configuration management software such as CFEngine to distribute a global ssh_known_hosts file to all client systems.

      iAtkos 5 Mac OSX

      OSX86 is a collaborative hacking project to run the Mac OS X computer operating system on non-Apple personal computers with x86 architecture processors.

      This upload includes iATKOS 5i DVD iso image and md5 rtf file.

      iATKOS 5i DVD: Leopard 10.5.5 Build 9F33 OSX86 installer DVD for Intel X86 CPU non-Apple Personal Computers (PC).

      The oscar goes to Apple and OSX86 community..

      Attention:

      1- This DVD is designed for Intel architectures.
      Minimum requirements: Intel SSE2 CPU, 512MB RAM, 10GB free space on target partition, OpenGL VGA card.
      Recommended: Intel Core CPU, 1GB RAM, 15GB free space on target partition, nVidia 6xxx or newer – ATI X1300 or newer – Intel GMA950 or X3100 VGA card.

      2- This DVD includes Apple’s Mac OS X Leopard 10.5.5 (9F33) installation.

      3- Make sure that the md5 checksum of your iATKOS iso image matches the one posted on our website or the one in md5.rtf file. Otherwise you may have a faulty DVD image. Use quality media/burner and burn slowly.

      Information:

      – This OSX86 installation DVD release supports both GPT and MBR partitioned harddrives.

      – The major improvement on this 5i release is updating your running system using software updater just like real Macs. This is possible for Intel based chipsets. Please read the information about preparing an upgradable system.

      – Main system is fully stock! That means it can’t run on x86 hardware without selecting none of x86 patches. At least you need to choose one of the decrypters.

      website: www.uphuck.com
      irc    : irc.atlantis-irc.net #uphuck.DVD
      core.osx86.hu #iATKOS

      cheers

      osx86.Türk team

      Installation:
      ——————————————————–

      Attention!
      iATKOS 5i 10.5.5 Intel DVD has been released at November 29, 2008.

      Release Information

      * This DVD is designed for Intel architectures.

      Minimum requirements: Intel SSE2 CPU, 512MB RAM, 10GB free space on target partition, OpenGL VGA card.
      Recommended: Intel Core CPU, 1GB RAM, 15GB free space on target partition, nVidia 6xxx or newer – ATI X1300 or newer – Intel GMA950 or X3100 VGA card.

      * This DVD includes Apple’s Mac OS X Leopard 10.5.5 (9F33) installation.

      * Make sure that the md5 checksum of your iATKOS iso image matches the one posted on our website. Otherwise you may have a faulty DVD image. Use quality media/burner and burn slowly.

      * This OSX86 installation DVD release supports both GPT and MBR partitioned harddrives.

      * The major improvement on this 5i release is updating your running system using software updater just like real Macs. This is possible for Intel based chipsets. Please read the information about preparing an upgradable system below.

      * Main system is fully stock! That means it can’t run on x86 hardware without selecting none of x86 patches. At least you need to choose one of the decrypters.

      Installation

      1. Run Disk Utility via Utilities menu and erase the target partition for clean install. Do partitioning if you need to.

      a – You can choose MBR (Master Boot Record) or GPT (Guid Partition Table) via partitioning options. If you want to change your existing partition table type, note that all your existing data on disk will be gone.
      b – For Windows fellows that has not tested this amazing system yet and that does not want to loose their windows software, porn and virus&trojan archive on D:\, should use Parted Magic Live CD for preparing an active primary target partition and after that, just erase it via diskutil. Jump to Step 2.

      1. Select the destination for installation.

      2. Click *Customize* and select what you need.

      3. Click Install.

      Install time is about 20 minutes.

      The Customize section is the most important part of the installation for you to make OS X work on your hardware.

      * iATKOS Main system: If you want to install the osx86 main system, you need to select this.
      * Bootloader: You have 2 choices. You must select one of them for booting your osx86 system. PC_EFI V9 is an “all in one” bootloader and has many options. The most important ones are DSDT override, external kexts and the 64bit mode (snow leo only). DSDT override will be needed for the upcoming updates, otherwise osx86 systems will have kernel panic due to new RTC driver. “External kexts” option allows users to use external location for their special drivers (/Extra/Extensions), this will protect them from the updates. iATKOS v5i installation has all the needed scripts and packages for you to prepare an upgradable system and update like real Macs, but you need to read the information about preparing an upgradable system below.

      The other choice is Chameleon v1.0.11. This is compatible for most systems, users whom want to have a normal old-style osx86 system may choose this bootloader.

      * Decrypters: You must select one of the decrypters for your x86 hardware.
      * SMBIOS: You need to select one of the enablers or classic x86 SMBIOS drivers. Enablers allow your system to run on stock SMBIOS driver and this is also a must for upgradable systems. x86 patched SMBIOS’ are for normal old style osx86 systems.
      * Kernel: You can choose 9.5.0 voodoo, 9.5.0 fassl kernel or old 9.2.0 toh kernel which is compatible for most.

      For upgradable systems, the custom kernel you selected will be protected after applying the update, which means you will be running on new System.kext + your old 9.x.0 custom kernel which is not right. System must run on System.kext that belongs to your kernel version. So, you will need to replace new System.kext with your old System.kext, otherwise you will not able to use none of USB devices. You can find your custom kernel’s System.kext under /Library/Temp. New updated one is in /System/Library/Extensions folder. Do not forget to repair the disk permissions using Disk Utility.
      If you want to switch to stock kernel when running upgradable system, then you need to edit com.apple.Boot.plist file under /Library/Preferences/SystemConfiguration. You need to change the value ”custom” to ”mach_kernel” and reboot. Don’t forget to use the same System.kext version with your running kernel. For normal iATKOS osx86 systems you need to check /Library/Backups folder for the stock kernel and replace it with the existing kernel on your root.

      * ACPI: Main system includes stock ACPI driver. You can choose modified ACPI for shutdown/reboot problems and also you can select OHR driver for such issues. You can choose x86 modified ACPI driver for PS2 mouse/keyboard and also PS2 driver can sure manage that but it is not a good choice for upgradable systems. You may need to select APIC driver for some mobo.
      * Disabler: This driver disables some problematic drivers, you may not need this for PC_EFI V9 systems but this can still be usefull for most systems.
      * Remove PowerManagement: This removes the most problematic driver. You do not need it if you select Disabler or if you are on PC_EFI V9 bootloader.
      * PS/2: Driver for PS/2 keyboard/mouse. You will need to modify the Info.plist of ACPIPS2Nub.kext for the update’s ACPI version before applying main system update, otherwise your ps2 mouse/keboard will not work. For upgradable systems, I advice you to use x86 ACPI driver instead of this.
      * OHR: Driver for freeze issues on shutdown/reboot. Modified ACPI driver can be an alternative for this.
      * Drivers: Additional drivers for your setup. Please read the descriptions.