Windows 7 RC auf älterem PC installieren: Code Error 5

Als ich den Windows 7 RC gerade auf einem älteren PC (S. 939) installieren wollte, brach die Installation bzw. der Bootvorgang von der DVD mit folgendem Fehler ab: Cannot boot from CD - Code error: 5. Das Problem liegt anscheinend an einem zu alten BIOS, das den Bootsektor der DVD nicht korrekt auslesen kann. Nach etwas Recherche bin ich auf diesen Beitrag gestoßen, der erklärt, wie man die DVD dennoch mittels einem zusätzlichen Bootloader namens gujin booten kann – mit einer Boot-Diskette. Als Alternative zur Boot-Diskette wird auf ein Tutorial zur Konvertierung des Floppy-Images in eine Boot-CD mittels Nero verwiesen.

Da ich hier weder ein Floppy-Laufwerk (glaub das wär noch in irgendeinem Schrank aufzutreiben gewesen), funktionierende Disketten (die schon schwieriger) oder Nero installiert hatte, habe ich mich nach einer Alternativlösung umgesehen. Abhilfe schafft hier wieder mal Linux und mkisofs, mit dem sich das Floppy-Image einfach in ein CD-ISO umwandeln lässt. Diese Lösung setzt natürlich voraus, dass man in dem zu installierenden PC 2 optische Laufwerke hat, eines für die Windows7-DVD und eines für die Bootloader-CD. Also flugs eine Ubuntu-VM gebootet und darin das gujin-ISO gebastelt. Dazu lädt man sich in der VM zuerst die standard-Version von gujin herunter und entpackt das Archiv. In dem Archiv befindet sich eine Datei full.img.gz, die man wiederum entpackt. Die darin befindliche Datei floppy.144 schiebt man in einen Arbeitsordner (bei mir z.B. /tmp/floppyimage) und öffnet anschließend ein Terminal. Darin macht man dann ca. folgendes:

$ cd /tmp/floppyimage
$ mkisofs -pad -b floppy.144 -R -o /tmp/gujin.iso floppy.144

Und schon liegt in dem Ordner eine Datei gujin.iso, die sich auf CD brennen und booten lässt. Anschließend legt man die Bootloader-CD in das eine, die Win7-DVD in das andere Laufwerk und bootet von der soeben gebrannten CD. Nach kurzer Erkennungszeit lassen sich in gujin die verschiedenen zur Verfügung stehenden Bootoptionen auswählen. Wählt man hier das Laufwerk mit der Win7-DVD, bootet die DVD ohne Probleme und man kann sich daran machen, (wieder mal) ein neues System auf die Platte zu packen. Ist zumindest bei mir so, auf der doch recht betagten Hardware ist der Installer durchgelaufen, während ich diesen Post hier verfasst habe.

Backup Xen virtual machines with LVM snapshots and ftplicity/duplicity

Some time ago, I updated the backup system on a Server running multiple Xen VM instances (DomUs). Before changing the system, each virtual machine ran its own backup scripts to backup data to an external FTP server. Now, VMs are centrally backed up to FTP from the Dom0 using LVM (Logical Volume Manager) snapshots. As a backup solution I chose duplicity and ftplicity in combination with a shellscript to create automated LVM snapshots. Duplicity is a tool to create GPG-encrypted (this way you can store your backups at remote servers without having to worry about who has access to your data) incremental backups to remote servers, ftplicity is a wrapper script for duplicity which allows running duplicity without interaction (e.g. without the need to type any passwords). Ftplicity was originally published by the German computer magazine c’t, but has been undergone further development and is now hosted at SourceForge.

You can find tutorials on ftplicity/duplicity here (Note: they use the original c’t version of ftplicity):

Basically you can use this setup for any kind of LVM snapshot based system, but I’m focusing on backing up Xen VMs here. I assume you got your LVM and Xen system up and running so far. I did this on a Debian Lenny system, but it should be similar on other distros. I did all steps as root.

read more »

Repack a .deb-archive with dpkg-deb

I just needed to repack a Debian package to solve this problem. After a quick spin to #debian I got this solution:

$ mkdir -p extract/DEBIAN
$ dpkg-deb -x package.deb extract/
$ dpkg-deb -e package.deb extract/DEBIAN
[...do something, e.g. edit the control file...]
$ mkdir build
$ dpkg-deb -b extract/ build/
  • -x extracts the package contents
  • -e extracts the control files
  • -b builds the new package

Done.

Upgrade from Debian Etch/Xen 3.0 to Debian Lenny/Xen 3.2 (AMD64)

I was running a Xen server with Debian Etch as dom0 (Linux 2.6.18-6 with Xen 3.0.3-1 on AMD64) for some time now. Today, I decided to upgrade the dom0 to Debian Lenny (Linux 2.6.26-2 with Xen 3.2.1-2). The domUs are all running a Debian-based OS (3x Lenny, 1x Ubuntu Hardy). The upgrade was quite straightforward, however there were some pitfalls you can avoid in advance.

read more »

Set up symfony 1.2 on Debian/Ubuntu

Just wanted to give symfony a try and ran into some issues to set it up the way I wanted. Therefore I’d like to note the required steps.

First, install symfony via PEAR.

pear channel-discover pear.symfony-project.com
pear install symfony/symfony-1.2.4

This sould install symfony and make the symfony executable available in your PATH.

~$ symfony -V
symfony version 1.2.4 (/usr/share/php/symfony)

Create a directory for your vhost and create a new project.

mkdir /var/www/myproject
cd /var/www/myproject
symfony generate:project myproject

Create an example application in your project.

symfony generate:app frontend

Link the symfony resources to the project’s document root.

cd web
ln -s /usr/share/php/data/symfony/web/sf/

This should get you up and running with symfony. You just need to configure your server for the vhost. For personal preference, I’d like to have my document root directory named public instead of web. The following steps are needed to achive this.

Rename the document root directory.

mv web public

Add this line to config/ProjectConfiguration.class.php:

<?php
public function setup()
{
    $this->setWebDir($this->getRootDir() . '/public');

    // for compatibility / remove and enable only the plugins you want
    $this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin')$
}

Linux Software RAID1 defekte Platte tauschen

Da auf meinem Rootserver zum wiederholten Mal Probleme mit der zweiten Festplatte (/dev/sdb) auftraten, wurde diese soeben im Rechenzentrum getauscht (ein Lob an Hetzner für den schnellen Support). Da die Platte Bestandteil eines Software RAID1-Verbunds ist, kurz die Schritte zum Entfernen und anschließenden Reaktivieren der Platte.

Zuerst alle Partitionen der Platte auf faulty setzen und anschließend aus dem jeweiligen Array entfernen:

mdadm /dev/md0 --set-faulty /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1
mdadm /dev/md1 --set-faulty /dev/sdb2
mdadm /dev/md1 --remove /dev/sdb2
mdadm /dev/md2 --set-faulty /dev/sdb6
mdadm /dev/md2 --remove /dev/sdb6

Nach dem Tausch der Platte muss zuerst die Partitionstabelle auf die neue Platte kopiert werden:

sfdisk -d /dev/sda | sfdisk /dev/sdb 

Anschließend können die Partitionen wieder zu den jeweiligen Arrays hinzugefügt werden:

mdadm /dev/md0 --add /dev/sdb1
mdadm /dev/md1 --add /dev/sdb2
mdadm /dev/md2 --add /dev/sdb6

Über folgende Ausgaben kann der Resync der Arrays dann überprüft werden:

mdadm --detail /dev/md2
cat /proc/mdstat

Debian logcheck ignore file for sSMTP

On a server, I use logcheck to get an email based on logfile analysis if anything goes wrong and doesn’t fit the usual patterns. In addition, I use sSMTP to forward all sent mails to my mailserver. Unfortunately, this solution ends up in sending a mail like the following every hour because of a bug in logcheck’s ignorefile for sSMTP.

Dec 12 22:02:06 hostname sSMTP[22391]: Sent mail for logcheck@hostname (221 2.0.0 Bye) uid=101 username=logcheck outbytes=639

To fix this, I replaced the contents of the file /etc/logcheck/ignore.d.server/ssmtp with the following lines:

^w{3} [0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2} [a-zA-Z0-9]+ sSMTP[[0-9]+]: Sent mail for logcheck@.*$
^w{3}  [0-9] [0-9]{2}:[0-9]{2}:[0-9]{2} [a-zA-Z0-9]+ sSMTP[[0-9]+]: Sent mail for logcheck@.*$

I removed the other lines, because sSMTP shouldn’t do anything else on the system and if it would, I’d like to be informed. If you need more ignore patterns you might have to keep/edit some of the original lines.

Debootstrap a Ubuntu Hardy DomU on a Debian Etch Xen Dom0

Lately, I wanted set up a Ubuntu Hardy DomU on an existing Debian Etch Dom0 box. Usually, setting up Debian-based DomUs is very simple with xen-create-image and debootstrap (there are tons of tutorials out there dealing with this topic), but unfortunately Etch’s version of debootstrap doesn’t support Ubuntu Hardy. I spent a surprisingly long time on searching the net until I found a solution for this problem on a french site: Installer et configurer Xen sur Debian 4.0 Etch (it’s a complete howto for Xen on Debian Etch, but it deals with the Hardy part too). The author created a backport of the debootstrap package, which enables you to debootstrap Hardy.

First, you have to create the hardy.d directory (symlink) for xen-tools.

$ cd /usr/lib/xen-tools
$ ln -s ubuntu.d hardy.d

There’s a debian repository holding the backport package, however I got problems to use that repository on an amd64 box, so I downloaded and installed the package manually.

$ wget http://falcon.landure.fr/pool/etch/debootstrap/debootstrap_1.0.10_all.deb
$ dpkg -i debootstrap_1.0.10_all.deb

Now you should be able to debootstrap a Hardy DomU.

$ xen-create-image 
--hostname=hardy 
--ip=xxx.xxx.xxx.xxx 
--size=5Gb 
--memory=256Mb 
--dist=hardy 
--mirror=http://archive.ubuntu.com/ubuntu/

Use VPN connections in network-manager-pptp without rebooting

When configuring VPN connections in Ubuntu through network-manager-pptp the connections don’t get displayed until a reboot due to a bug. In the bugtracker I found a solution which makes the connections available without a reboot.

First, restart dbus

sudo /etc/init.d/dbus restart

Then run the NetworkManager applet by opening a command window with ALT+F2 and typing nm-applet.

Install git 1.6 from source on debian etch

$ aptitude install build-essential gettext
$ wget http://kernel.org/pub/software/scm/git/git-1.6.0.1.tar.gz
$ tar xvzf git-1.6.0.1.tar.gz
$ cd git-1.6.0.1
$ ./configure
$ make
$ make install