pk stuff

Or perhaps it should be: how to retrieve an lvm partition from an xvda partition within an lvm partition.

Quite some time ago, I built a CentOS Xen DomU using lvm within an xvda partition. And the whole VM was hosted in yet another lvm partition. While lvm is easy to manage and physical backup and restore is straightforward, accessing the contents of the embedded partition without the VM running is tricky. Luckily, device mapping in Linux is very powerful and can be used recursively (not quite like Haskell or OCaml, but impressive none the less).

This recipe can be applied multiple times to dig deeper into your embedded file systems.

Add the device mappings (assuming the device created is /dev/xvda ):

kpartx -a /dev/VolGroupXX/LogVolxx

Kpartx is amazing as it will scan all your lvm volumes and create device mapper entries, which are required for the lvm tools to do their thing.

Scan for physical volumes:

pvscan

The above should tell you the physical volumes with LVM partitions (the PV column) along with the volume groups on it (the VG column). Activate the volume group:

vgchange -ay {VG name from previous step}

If you have additional embedded LVM, run vgscan to discover these, and vgchange -ay as required. You may need to repeat the kpartx and pvscan too.

When you eventually get to the volume required, mount it with :

mount /dev/{VG name}/{LV name} /mnt/xxx ;

The folks at Citrix have more detail here, especially if you’re running Xen.

from linuxnet.ch

To disable IPv6 in RHEL/CentOS 6.x:

Edit /etc/sysconfig/network
Change the following:

NETWORKING_IPV6=yes to

NETWORKING_IPV6=no

Edit /etc/modprobe.conf
If not present, add the following:

alias net-pf-10 off

alias ipv6 off

Stop the ipv6tables service

service ip6tables stop

Disable the ipv6tables service

chkconfig ip6tables off

After rebooting, IPv6 will be disabled.

Followed this recipe first, but got bogged down on the home-brew tools and very detailed guest config. However, this blog has the best description and config I’ve ever seen for bridge networking on CentOS – worked like a charm.
Finally got everything working with these (much simpler) instructions using a centos6 guest from the openvz template download site.

I like Growl notifications for automated builds (and not much else – does anyone really need more distractions from IM, Facebook, Twitter?).

As of version 1.3, Growl is only available through AppStore for $1.99, but the source is still available online. So if you happen to have XCode installed, the following instructions will get you running.

1) You need Mercurial to retrieve Growl source. To Install Mercurial: sudo easy_install pip && sudo pip install Mercurial

2) In a terminal window:

cd /tmp
hg clone https://code.google.com/p/growl/
cd growl
open Growl.xcodeproj

3) In XCode, disable code signing.

4) Back in terminal:

xcodebuild -project Growl.xcodeproj -target Growl.app -configuration Release
open build/Release

5) Copy Growl.app to your Applications folder.

More detailed, illustrated instructions available at: https://pragmactic-osxer.blogspot.com/2011/11/building-growl.html

I’ve been incredibly frustrated by how poorly DNS resolves since upgrading first to Lion, then later to Mountain Lion (on a new machine, but migrating my old files). The impact of this was particularly bad connecting to SMB/CIFS/Samba shares – some would mount after several minutes, others not at all.

Early on it became clear the problems were related to my router (DDWRT) not supporting IPv6 but then neither does my ISP. Here are a few things to try:

DNS Resolver Order

Normally /etc/hosts is first in line for DNS resolution. But it seems improper line termination, presumably a carriage return/linefeed instead of just a linefeed, causes all sorts of problems. Many posts describe ways to force reloading of the hosts file, but the root cause seems to be improper line termination. Always make sure you use a Unix compatible editor.

To check the order resolvers are called:

scutil --dns

/etc/hosts Entries

These two were the main source of my problems:

1. My host has multiple names – these must all be present, and fully qualified:

127.0.0.1 hosta hosta.foo.com
127.0.0.1 hostb hostb.foo.com

2. All localhost entries must have ::1 entries too, or OS X will send IPv6 requests to resolve them externally. And this despite IPv6 being disabled on the interface!

::1 hosta hosta.foo.com
::1 hostb hostb.foo.com

Turn off IPv6 in Network Preferences

Go to System Preferences -> Network -> Advanced -> TCP. In the Configure IPv6 list, you may have an “Off” option. If so, select it. If not, see next tip.

Turn off IPv6 from Terminal

List available network services:

networksetup -listallnetworkservices

Turn off IPv6 on chosen device (name from above list):

networksetup -setv6off your_device_name (i.e. Wi-Fi, Ethernet)

Now the Configure IPv6 list  for that device will show “Off”  (see previous tip).

MobileMe Remnants

Apparently older OS X installations migrated to newer releases may still have hooks to no-longer existant MobileMe servers. Many users report that removing these greatly speeds up SMB connection. The following removes those references if present and are harmless if not.

defaults delete -g iToolsMemberDomain
defaults delete -g iToolsMember

 

Generally I like to run servers headless, as in with no display or console. In Parallels this is a little tricky, but doable from Terminal. However, Parallels Desktop must not be running. If you do launch Parallels while a Terminal-spawned VM is running, a console will automatically be created.

To see a list of available VM:

prlctl list -a

To launch a VM:

prlctl start vm_name

Continuing from my Timemachine post, here is my summary of instructions from Garth Gillespie’s site (garth.org).

In Terminal:

sudo su - 

The verication that has already run has marked your sparsebundle as bad, so first we need to make it look normal:

chflags -R nouchg /Volumes/{name of your network share}/{name of}.sparsebundle

This may take a little while. Then:

hdiutil attach -nomount -noverify -noautofsck /Volumes/{name of your network share/{name of}.sparsebundle 

You will then see something like

/dev/diskx Apple_partition_scheme /dev/diskxs1 Apple_partition_map /dev/diskxs2 Apple_HFSX 

Where x is the disk id for the external disk. You are interested in the one labeled Apple_HFSX or Apple_HFS. It might be 2, 3, 4 or higher.

At this point, the filesystem check is running. To see what’s going on, tail the fsck_hfs.log

tail -f /var/log/fsck_hfs.log 

Normally, if fsck is running, it will successfully repair the sparsebundle, but it can take a long time (hours). Grab a coffee.

When done, you should see:

The Volume was repaired successfully

So far, this has always worked for me. But if you get:

The Volume could not be repaired

fsck_hfs -drfy /dev/diskxs2 

Make sure to replace x with whatever number your disk is from the output above. Like before, use tail to follow the fsck log output, and get comfy.

Once fsck has completed successfully, unmount the volume:

hdiutil detach /dev/diskxs2 

Lastly, you need to clean up your backup’s state by editing com.apple.TimeMachine.MachineID.plist (top level of your sparsebundle) as follows:

1) Remove these two nodes:

<key>RecoveryBackupDeclinedDate</key> <date>{whatever-the-date}</date> 

2) Replace:

<key>VerificationState</key>
<integer>2</integer>

with:

<key>VerificationState</key> <integer>0</integer> 

And you should be good to go!

I can never figure out why Apple has to be different, and especially why the change (break) stuff that already works fine. Today’s example: flushing the DNS cache.

From terminal, these are the commands to flush the cache on several (relatively) recent versions of OSX:

Tiger
lookupd -flushcache

Leopard / Snow Leopard
dscacheutil -flushcache

Lion / Mountain Lion
sudo killall -HUP mDNSResponder

From the Apple discussion groups, drm31078 says:

Received another reply from synology pointing to Lion as the problem…

Here is what I received from my engineers.

This problem seems to have happened since OSX 10.7.
We use the open source – netatalk to support AFP and
it summarized that this problem also exists on Apple Time Capsule too.
(https://www.netafp.com/tn005-10-7-lion-time-machine-and-netatalkafp-620/
https://discussions.apple.com/message/17441528#17441528 )

For the Macs that doesn’t trigger “Start New Backup” YET,
users may use the following method to try and fix the verification flag and avoid wiping out all old backup history.
https://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html
https://pondini.org/TM/C13.html

Hey Apple are you seeing this?!?!

I use a Debian 6.0 box running Netatalk to backup my Mac using Timemachine. This all worked nicely until recently upgrading to Mountain Lion when, big surprise, Timemachine/Netatalk became unreliable. This seems to happen pretty much every time Apple bumps OSX – for reasons know only to them, all sorts of breaking changes are required to change from one feline to another, while providing minimal value to users.

Some research later, it became clear that Mountain Lion needs Netatalk 3.1 (post 12/8/22) to run reliably.

The instructions here worked well: https://gist.github.com/2856490

Note: do not forget the “./bootstrap”. Also, missing from the requirements are autotools (automake) and libtool.

Quoted from github:

Install prerequisites:

    $ sudo apt-get install build-essential pkg-config checkinstall git-core avahi-daemon libavahi-client-dev

Download src:

    $ cd /usr/local/src
    $ git clone git://netatalk.git.sourceforge.net/gitroot/netatalk/netatalk
    $ cd netatalk
    $ ./bootstrap

Find current version of Berkeley DB available

    $ apt-cache search libdb

Mine was 5.1, so I'll install that

    $ sudo apt-get install libdb5.1-dev db-util db5.1-util

Same for libgcrypt:

    $ apt-cache search libgcrypt
    $ sudo apt-get install libgcrypt11 libgcrypt11-dev

Configure install

    $ ./configure --with-init-style=debian --with-zeroconf

Build!

    $ make
    $ sudo checkinstall

Config is in /usr/local/etc/afp.conf