Time Machine backup...not

The other day I went to my Time Machine backup to try get a slightly older copy of a file that I'd been working on recently. But there was only a fairly ancient copy sitting there - and I KNEW I'd updated it since that date?!  My Time Machine backups seemed to be backing up just fine but only it wasn't..... Real handy?!

I Googled it and found a bunch of people had run into the same issue.

There are a bunch of files and directories that are normally excluded from backups - which are contained within the following plist files (You can see them just using a text editor or Quickview or edit them using e.g. Property List Editor) - check the 'ExcludeByPath' keys:

/Library/Preferences/com.apple.TimeMachine.plist

/System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist

Note: That in the com.apple.TimeMachine.plist there are a bunch of items that get added by certain Applications; Xcode adds the directories named 'build' (and maybe others) to the list exclusions, and Google's Chrome adds it's 'cache' directories to the exclusion list. There's probably others out there as it is achieved using a standard API call.

You can also find, using mdfind the OSX's command line version of Spotlight, all files or directories that have had the appropriate metadata attribute set (using xattr command) for backup exclusion:

sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'"

Out of interest you can list the metadata attributes on any file/dir:

mdls /path/to/that_curious_file

However in my case none of the above applied and it seems that under Sow Leopard there's some 'bug' that stops TM working properly if you haven't rebooted in a while (which I hadn't). So a simple reboot fixed it?! Not reassuring though.

There's a good list of things to check here and there.

Too many package managers

On every system someone seems to invent a new package management system which means you've gotta learn the nearly the same thing over and over again. Tedious... Here's some notes to myself about how you can do basic stuff in a few I use (OSX/MacPorts[port], Ubuntu/Debian[aptitude,apt], RedHat/RPM[rpm,yum]).

Install Package

OSX% port install ThatPeskyPackage
ubuntu% aptitude install ThatPeskyPackage
ubuntu% apt-get install ThatPeskyPackage
ubuntu% dpkg -i ThatPeskyPackage.deb
RedHat% yum install ThatPeskyPackage
RedHat% rpm -i ThatPeskyPackage.rpm

Remove Package

OSX% port uninstall ThatPeskyPackage [version]
ubuntu% aptitude remove ThatPeskyPackage
ubuntu% apt-get remove ThatPeskyPackage
RedHat% yum erase ThatPeskyPackage
RedHat% rpm -e ThatPeskyPackage.rpm

Package Info

OSX% port info ThatPeskyPackage
ubuntu% aptitude install ThatPeskyPackage
ubuntu% apt-get install ThatPeskyPackage
RedHat% yum info ThatPeskyPackage
RedHat% rpm -qi ThatPeskyPackage

Package Content: What files did it install?

OSX% port contents ThatPeskyPackage
ubuntu% dpkg -L ThatPeskyPackage
RedHat% rpm -ql ThatPeskyPackage

What package does this file belong to?

OSX% port provides /usr/some/place/weird/whatisthis
ubuntu% dpkg -S /usr/some/place/weird/whatisthis
RedHat% rpm -qf /usr/some/place/weird/whatisthis

Which packages have I got installed?

OSX% port installed
ubuntu% dpkg --get-selections
RedHat% rpm -qa
RedHat% yum list

What Linux release am I running?

For every Linux distribution/distro there seems to be a different way to work out which release version/name/codename you're running. Here's a the ways I've found, on the command line, to find out:

Ubuntu

lsb_release -a
cat /etc/lsb-release
cat /etc/debian_version

Note: For Ubuntu /etc/debian_version seems to contain the Debian base from which this version of Ubuntu originates.

Debian

cat /etc/debian_version
cat /etc/lsb-release
lsb_release -a

Note: The latter two are not always available on pure Debian systems.

Redhat/CentOS/Fedora

cat /etc/redhat-release

Gentoo

cat /etc/gentoo-release

Building and using a Linux initramfs

If your kernel needs to do 'stuff' during boot up or load modules that aren't compiled into it then an initramfs provides a way (initramfs supersedes the old initrd approach). Basically it is a file (cpio and gzipped) that contains a directory hierarchy containing all the necessary items to provide for loading of modules etc.

To enable the use of the initramfs you'll need to enable the relevant kernel option (e.g. General Setup --> Initial RAM filesystem and RAM disk (initramfs/initrd) support) and them supply the appropriate boot arguments to your boot loader (e.g. append initrd=my-initrd .....). At the very beginning of boot up you should see [on the console] the initrd being loaded (Loading initrd................), then further down it executes the ./init script within the initrd.

To build an initramfs from a suitably populated directory:

find . -print0 | cpio --null -ov --format=newc | gzip -9 > ../my-initrd

To check the contents of an initramfs:

gunzip -c my-initrd | cpio -t

To extract the contents of an initramfs into the current directory (you might want to create a temporary directory to unpack it into mkdir initrd.d ; cd initrd.d):

gunzip -c ../my-initrd | cpio -i -d -H newc --no-absolute-filenames

If you've been trying to use an initramfs and you're getting this error on boot up:

Failed to execute /init

Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Then maybe your ramfs image doesn't contain init, or it's not executable, or you're trying to use a shell within init that incompatible with your kernel's architecture (e.g. trying to use an amd64 arch shell with an i686 kernel).

There's a good Gentoo guide on building them.

On Ubuntu/debian there's a command to build an initrd called mkinitramfs. When running mkinitramfs whilst you can use an alternative config directory, it can only obtain kernel modules from /lib/modules/<kernel_version>. So you can run it using chroot, though its only a shell script so it can of course be tweaked....