How do activate an automatic update for a Debian based distribution?

December 31, 2007

I’m running many VE’s (virtual environments) on some OpenVZ servers. A Linux distribution within the VE has no own kernel and I can always access a VE from the hardware node so I thought it is save to update them automatically every day, but they should not do the update at the same time (more than one runs on the same physical server) and if an error occurs I would like to get an email. Sounds not that easy, but it is. Just do following:


# apt-get -y install cron-apt
# cat > /etc/cron-apt/action.d/9-dist-upgrade
dist-upgrade -y -V -u -o Dpkg::Options::=--force-confold


and you’re done. If you configured the root mail alias to the right address you get a mail if something didn’t work. cron-apt waits a random amount of time when started by cron before it starts calling apt-get – so we are done. I’ve this setup running now for some years without ever having a problem with it. I use it for Debian Sarge and Etch and Ubuntu Dapper 6.06 LTS.

How to read a RAID1 hard disk if you can’t use the RAID Controller?

December 30, 2007

I had following problem:
An 3ware RAID controller got destroyed after a power surge and I needed to read the data on the RAID without waiting for a replacement controller. I therefore attached one of the hard disks via an USB adapter (PATA/SATA to USB2) to my notebook. The problem now is that a RAID Controller uses some blocks at the beginning of the disk for itself, this leads to the problem that the partition table is not found by the Linux kernel.

Solution:
I used LDE (The Linux Disk Editor) to find out how many blocks are used by the RAID controller. My 3ware controller used 0x200 = 512 blocks with 1024 byte = 524288 bytes offset. I therefore created an loop back device with this offset:

# losetup -o 524288 /dev/loop0 /dev/sdb

and I checked if the partition table is readable via:

# fdisk -l /dev/loop/0
Disk /dev/loop/0: 160.0 GB, 160041361408 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/loop/0p1               1         249     2000061   82  Linux swap /
Solaris
/dev/loop/0p2   *         250        1494    10000462+  83  Linux
/dev/loop/0p3            1495       19457   144287797+  83  Linux

Looks good, but mounting didn’t work directly but I didn’t have the time to look into more detail (maybe udev didn’t created the /dev entries), it was important to get the data of the disks as fast as possible. So I just removed the loop back device with

# losetup -d /dev/loop0

and started to do some math. The swap partition was of no need, I needed only the two ext3 partitions. I calculated the offset of the first of these partitions this way: 249 units with each 8225280 bytes and of cource the RAID controller offset:

249*8225280 + 524288 = 2048619008

with this I did the mounting like this:

# losetup -o 2048619008 /dev/loop0 /dev/sdb
# mount -r /dev/loop0 /tmp/1

and for the second ext3 partition this.

1494*8225280 + 524288 = 12289092608


# losetup -o 12289092608 /dev/loop1 /dev/sdb
# mount -r /dev/loop1 /tmp/2/

I hope this helps someone in a similar situation as I was.