Tag Archives: Linux

Grub auf mehreren Festplatten

Leave a reply

Leute spielen mit Eisenbahnen, sammeln Briefmarken oder züchten Rosen. Ich probiere neue Betriebssysteme aus und pflege verschiedene Installationen für den einen oder anderen Zweck. In einem Testrechner sind hier drei Festplatten verbaut, alles alte Dinger, aber genug Platz für mehrere Betriebssysteme.

In diesem speziellen Fall sind auf der ersten Platte (80 GB) Windows 98 und XP installiert sowie ein Ubuntu und ein Eisfair-1. Auf der zweiten Platte (40 GB) residiert ganz allein ein Debian Etch als Host für Xen und last but not least ist auf der dritten Platte (4 GB) noch Platz für eine Beta-Version von Eisfair-2. Wäre nur die erste Platte eingebaut, hätte ich kein Problem. Ubuntu benutzt Grub und Grub erkennt bei der Installation andere Systeme. Ubuntu selbst und das Eisfair-1 von der ersten Platte starten ohne Probleme, Ubuntu hat die Hand auf dem Bootloader und aktualisiert bei Kernel-Updates seine eigenen Einträge. Die beiden Windosen lassen sich über chainloader ebenfalls problemlos booten.

Interessant wird es mit Betriebssystemen auf den anderen beiden Platten. Die bringen für gewöhnlich ihren eigenen Bootloader mit und verwalten die entsprechenden Einträge bei Kernel-Updates oder ähnlichem auch selbst. Der neue Eisfair-Installer schreibt sich in den MBR der Platte, wo das System landet, in dem Fall die dritte Platte hdc. Debian lässt einem da mehr Freiheit, aber in Frage kommen im Prinzip nur der MBR von der zweiten Platte (hdb) oder direkt die Bootpartition /dev/hdb1. Will ich die Systeme booten, kann ich natürlich die Namen, Orte und Optionen der Kernel von Hand bei jedem Update in die Grub-Konfiguration des Ubuntu auf hda eintragen, aber das ist mir ehrlich gesagt zu umständlich.

Die nächste Möglichkeit ist der bereits erwähnte chainloader. Ja, aber… der funktioniert nur, wenn z.B. Debian seinen Bootloader an den Anfang einer Partition und nicht in den MBR schreibt. Ich habe es nicht hinbekommen, mit dem chainloader sozusagen den MBR einer anderen Platte zu starten. Klar, ich könnte jedesmal ins BIOS und die Bootplatte umstellen, aber das ist mir dann auch zu umständlich.

Heute habe ich eine weitere Möglichkeit herausgefunden. Es ist aus dem Grub-Menü heraus möglich, eine andere Grub-Config zu laden. Anstatt eines langen Eintrags mit kernel usw. reicht dann folgendes:

title       hdb: Debian
configfile  (hd1,0)/grub/menu.lst

Trage ich das bei den zusätzlichen Systemen in die /boot/grub/menu.lst meines Ubuntu ein, kann ich ganz locker die menu.lst laden, die unter der Fuchtel des Debian auf der zweiten Platte steht. Umgekehrt geht’s natürlich auch, so dass ich munter hin und her springen kann, auch zu dem Grub vom Eisfair-2 oder zurück zum Debian-Bootmenü und von da wieder zum Bootmenü vom Ubuntu und wenn ich dann vom Umherspringen in meinen Grub-Menüs genug habe, boote ich einfach das System, das ich will.

XOrg vs. Eclipse

1 Reply

Als ich am Montag nach einem System-Update (Debian sid) mein Eclipse starten wollte, erschien statt der erwarteten IDE ein Fensterchen mit der Meldung, es hätte einen Fehler in der JVM gegeben. Eclipse konnte nicht gestartet werden, dementsprechend konnte ich meine Arbeit auch nicht fortsetzen.

Da man den Fehler ja zuerst bei sich selbst sucht, habe ich erst einmal das Update des Java Development Kit rückgängig gemacht und die Version 1.5 installiert. Der Fehler blieb leider.

Ein Blick auf die Console hat folgendes ergeben:
The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 1272 error_code 11 request_code 148 minor_code 5)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

Eine Suche nach den entsprechenden Schlagworten hat mich schnell in die überall präsenten Ubuntu-Foren geführt, wo sich herausstellte, dass der Schuldige das Paket xserver-xorg-core ist, das mit Einführung eines Sicherheitsupdates das Ausführen von SWT-Applikationen mit eben dieser Meldung quittiert.

Die spontane Lösung dafür ist, das Update rückgängig zu machen und eine ältere Version zu installieren. Die habe ich auf den Paketservern leider nicht mehr gefunden, da dort nur die jeweils aktuellen Versionen vorliegen. Fündig geworden bin ich dann im Paket-Cache auf meinem eigenen Rechner, wo ich zum Glück noch eine ältere Version dieses Paketes hatte; manchmal ist es doch praktisch, nicht immer sofort alle Caches zu leeren. :)

Sollte jemand mit dem gleichen Problem hier vorbeikommen, kann er das mit folgenden Befehlen beheben:

wget http://www.tuxathome.de/deb/xserver-xorg-core_2%253a1.4.1%7Egit20080105-2_i386.deb
dpkg -i xserver-xorg-core_2%3a1.4.1~git20080105-2_i386.deb

Das installiert die Version, die vor dem Update ausgeliefert wurde. Es empfiehlt sich, die Version vom 18.01. als Forbidden zu markieren, damit sie beim nächsten Upgrade nicht gleich wieder installiert wird.

Achtung: Ich übernehme keinerlei gewährt für die Korrektheit und Verfügbarkeit des Paketes auf meinem Server oder den ordnungsgemäßen Ablauf des Downgrades!

Ich werde noch einen Bugrepot anfertigen (den habe ich jedenfalls nicht gefunden) und bin gespannt, wie lange es dauert, bis das Problem behoben ist. Mein Eclipse läuft jedenfalls erstmal wieder.

Nicht das gesamte System verschlüsseln

3 Replies

Nach etwas oberflächlicher Recherche bin ich der Meinung, das Internet quillt über von Anleitungen zur Verschlüsselung ganzer Partitionen, ja ganzer Rechner (bis auf den MBR), mit allen Auswüchsen, die man sich denken kann und auch noch Motivationen und Begründungen dazu. Verschlüsselung der root-Partition, LVM auf einem verschlüsselten physical volume, verschlüsselte logical volumes in ansonsten unverschlüsselten LVM Dingern, das ganze noch mit und ohne RAID oder mit /boot noch auf dem USB-Stick, wahlweise mit Keyfiles oder herkömmlichen Passwörtern usw. Die Ansätze zur Verschlüsselung sind ähnlich vielfältig: dm-crypt mit und ohne luks, das klassische loop-aes oder truecrypt, um nur einige zu nennen.

Ich will einfach nur unter Debian Lenny eine Datenpartition verschlüsseln, kein RAID, kein LVM, boot-, root- und swap-Partition dürfen auch unverschlüsselt bleiben und das ganze am besten ohne einen eigenen Kernel kompilieren zu müssen und ohne Installation mit Live-CD oder sonstigen Spielerchen.

Ich habe also HowTos, Tutorials und manpages gewälzt und die Wahl fiel auf dm-crypt mit luks. Das ist aktuell, es ist alles bei Debian schon dabei und der Kernel muss nich neu kompiliert werden. Kurz noch die Grundvorraussetzungen hier: /boot auf CF-Karte als hda1, root-Partition ist hdd1 und swap hdd2, die Daten sollen alle auf hdd3 landen. Die ganze Einrichtung spielt sich mit root-Rechten ab, da wir nicht bei Ubuntu sind, einfach als root einloggen dafür! Die ersten Schritte bestehen darin, die nötigen Kernel-Module zu laden und das Programm cryptsetup zu installieren:

modprobe aes
modprobe dm-crypt
modprobe dm-mod
aptitude install cryptsetup

Die Partition, die verschlüsselt werden soll, darf nicht gemountet sein, ein Mountpoint sollte für später vorhanden sein, einfach das gewünschte Verzeichnis anlegen. Bei mir wird das /mnt/data sein. Als nächstes wird die Partition für die Verschlüsselung vorbereitet und geöffnet, quasi dem Device-Mapper bekannt gemacht. An diesem Punkt bitte darauf achten, dass alle Daten, die sich noch auf /dev/hdd3 befinden, danach unwiederbringlich verloren sind.

cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/hdd3
cryptsetup luksOpen /dev/hdd3 data

Beim ersten Aufruf wird nach einem Kennwort gefragt, das später als Schlüssel dient. Der zweite Aufruf öffnet sozusagen die verschlüsselte Partition, daher ist das Kennwort nochmal einzugeben. Jetzt kann man über /dev/mapper/data auf die verschlüsselte Partition zugreifen. Der erste Schritt: formatieren. Ich habe das ganze mit einer etwa 227 GB großen Partition und einem Pentium 133 getan. In der Zeit kann man ganz entspannt Kaffee kochen, trinken, die Kaffeemaschine sauber machen, Pizza backen, Pizza essen, den Ofen sauber machen…

mkfs.ext3 -v -L DATA /dev/mapper/data

Mounten klappt von Hand dann schonmal. Jetzt soll es noch so eingerichtet werden, dass die Partition auch beim Boot gemountet wird. Dazu werden die nötigen Kernelmodule, die vorhin von Hand geladen wurden in /etc/initramfs-tools/modules/ eintragen. Das sind

aes
dm-crypt
dm-mod
sha256

Danach nochmal die initrd neu bauen lassen mit

update-initramfs -u -k all

Als nächstes wird die /etc/fstab angepasst. Dort einfach /dev/hdd3 durch /dev/mapper/data ersetzen oder die Zeile neu anlegen. Weiterhin ist es noch nötig, die Datei /etc/crypttab anzupassen:

data /dev/hdd3 none luks,retry=1,cipher=aes-cbc-essiv:sha256

Das war’s. Das ist alles, mehr ist nicht zu tun. Beim booten wird man nach dem Passwort gefragt, der Rest läuft wie gewohnt. Noch ein Wort zur Performance: da nur die Datenpartition verschlüsselt ist, machen sich natürlich nur Zugriffe darauf bemerkbar. Kopieren mit rsync+ssh lastet den Rechner voll aus, das war vorher auch schon so, da ssh hier den Prozessor bereits zu voller Auslastung treibt. Mit zusätzlicher Verschlüsselung der Datenpartition sieht das in top dann so aus, als würden ssh und kcryptd/0 zu ungefähr gleichen Teilen für die CPU-Last verantwortlich sein. Mehr Aussagen kann ich dann machen, wenn die Daten wieder zurückgeschrieben sind, morgen oder übermorgen…

ext3-Dateisystem verkleinern mit Knoppix

2 Replies

Hatte ich schon erwähnt, dass ich im September umgezogen bin? Bin ich, nur in anderes Viertel, aber mit jemandem zusammen in eine neue WG, der wie ich ebenfalls einen kleinen Server zu Haus stehen hatte. Da die Hardware heutzutage leistungsfähig genug ist und Xen zuverlässig läuft, sind wir dabei Schritt für Schritt die Dienste von den beiden ehemaligen Servern auf eine Maschine mit ein paar virtuellen Xen-Hosts zu packen. Da ich ungern an Produktivsystemen neue Dinge ausprobiere, teste ich solche Sachen auf einem anderen Rechner. Gestern hatte ich dank dieser Anleitung auf besagtem Testrechner unter Debian Etch in kurzer Zeit einen laufenden Xen-Wirt eingerichtet. Die 40GB-Platte war dort ungefähr zu gleichen Teilen in /home und / geteilt – klassische Partitionen. Da ich Xen gern mit LVM testen wollte und die Partitionen kaum belegt waren, entschied ich mich für eine Neuaufteilung: 8 GB für das root-Filesystem und der Rest für LVM. Auf dem Testsystem sind außer Testinstallationen keine wichtigen Daten, also die erste Gelegenheit für mich, mal resize2fs auszuprobieren…

Beim Verkleinern einer Partition soll man erst mit resize2fs das Dateisystem (ich benutze eigentlich immer ext3) verkleinern und dann mit fdisk die Partition selbst noch verkleinern. Das Manual sagt, dass die Partition natürlich nicht kleiner gemacht werden soll als das Dateisystem – logisch. Zunächst jedoch will resize2fs nochmal e2fsck aufgerufen haben:

e2fsck -f /dev/hdb3
resize2fs -p /dev/hdb3 8G

Dann habe ich fdisk /dev/hdb aufgerufen, hdb3 gelöscht und neu angelegt. Der vorgeschlagene Beginn der Partition war der gleiche wie zuvor, habe ich extra kontrolliert und dann die Partition mit +8300M neu angelegt. Reboot und siehe da: reicht wohl nicht, es kommt die Beschwerde, dass das Dateisystem 2 097 152 Blöcke hat, die Partition aber nur 2 026 458. Also nochmal Knoppix booten und Partition neu anlegen. Interessant ist dann zunächst die Ausgabe von fdisk -l

Platte /dev/hdb: 40.0 GByte, 40020664320 Byte
16 Köpfe, 63 Sektoren/Spuren, 77545 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes

    Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/hdb1   *           1         203      102280+  83  Linux
/dev/hdb2             204        2284     1048824   82  Linux Swap / Solaris
/dev/hdb3            2285       18367     8105832   83  Linux
/dev/hdb4           43895       77545    16960104    5  Erweiterte
/dev/hdb5           43895       77545    16960072+  83  Linux

fdisk zeigt hier auch Blöcke an, aber die Anzahl ist verschieden zu der, die zuvor e2fsck beim Boot des Systems zeigte – genau genommen exakt viermal so groß. Aber irgendwie stimmt das auch ungefähr mit den 8300 Megabyte von vorhin überein, in Kilobyte versteht sich. Ich habe dann also diesmal beim Neuanlegen der Partition +8388608K angegeben, das vierfache von dem Wert, den das System vorher beim Booten für die Größe des Dateisystem genannt hatte. Der kam wie gesagt ursprünglich von den 8G beim resize2fs. fdisk machte dann ein paar Blöcke mehr draus, als ich Kilobyte eingegeben hatte, umso besser. Da der Kernel noch nichts von der Änderung der Partitionstabelle durch fdisk wusste, lohnte ein e2fsck unter Knoppix nicht und ich hab gleich neu gestartet.

Das Debian etch beschwerte sich dann nicht mehr über ein Filesystem, das größer war als die Partition, ließ aber dennoch einen Check drüber laufen. Der weitere Systemstart verlief problemlos. Das LVM richte ich dann später ein…

happy

Interessant finde ich jedoch noch die Frage, was ich hätte eingeben müssen, um von vornherein die passenden Größen für resize2fs und fdisk parat zu haben, einfach auch 8G bei fdisk wäre nämlich deutlich zu wenig gewesen. Ziel: möglichst wenig Platz auf der Partition verschenken. Wer da Ideen hat, den bitte ich um Kommentare!

Alter schützt vor Treibern nicht

Leave a reply

Mein aktuelles Bastelprojekt ist ein alter Rechner. Eingebaut ist ein Pentium mit 133 MHz, ein wenig EDO-RAM, eine alte Soundkarte vom Typ Terratec Base 1, 3com Netzwerkkarte und eine große Festplatte, auf der Daten gesichert werden. Für Konsole reicht das gut hin und Musik kann er auch abspielen. Installiert hatte ich Debian Etch.

Die Kiste hängt an einem 17″-Röhrenmonitor, eine Konsole mit 80×25 Zeichen ist nett, aber 800×600 Pixel sind locker drin – immerhin 100×37 Zeichen. Damit lässt sich gut chatten, für E-Mails ist genug Platz und auch im Midnight Commander steigt die Übersicht. Das ganze steht und fällt mit dem dafür nötigen Betrieb der Grafikkarte im Framebuffer-Modus. Bei neuen Karten geht das leicht über den VESA-Treiber, einfach vga=789 an die Kernel-Optionen von Grub angehängt und fertig. Leider ist in dem Rechner eine alte S3 Trio64V+ eingebaut und die unterstützt der VESA-Treiber nicht.

Zum Glück gibt es noch andere Framebuffer-Treiber. Bei der ersten Recherche im Netz stellte sich aber Ernüchterung ein. S3 nur für PPC oder Amiga, warum auch immer. Dann stieß ich auf eine erst ein paar Monate alte Neuigkeit. Da hatte doch tatsächlich jemand für Kernel 2.6.21 noch einen neuen Treiber für die Karte geschrieben. Ich finde das reichlich bemerkenswert, schließlich reden wir hier von einer Grafikkarte aus den späten Neunzigern!

Der Ehrgeiz war geweckt, jetzt galt es das Ding zum Laufen zu bringen. Zunächst schaute ich, was nach Debian Etch an Kernel-Versionen bereit stand. Der aktuelle Testing-Zweig bringt 2.6.22 mit, also machte ich ein Dist-Upgrade von Etch nach Lenny. Das war nicht weiter aufregend, allerdings noch nicht alles. Um den Treiber jetzt auch zu benutzen waren (als root!) folgende Schritte notwendig:

  • s3fb in die Datei /etc/initramfs-tools/modules eintragen
  • update-initramfs -u -k all
  • in /boot/grub/menu.lst die entsprechende Zeile wie folgt ändern:
    # defoptions=video=s3fb:800x600@85

Anschließend neu booten und freuen. Der Rechner läuft tatsächlich mit Framebuffer-Konsole auf S3 Trio64V+.

happy

Schicker Minirechner mit Debian

1 Reply

Den Titel der Heise-Meldung musste ich doch nach der Begutachtung des Gerätes glatt mal übernehmen.

Die Rede ist von einem Debian-basierten Desktop-Rechner im Office-Format. Das heißt, er ist nicht überdimensional groß, sondern hat mit (18×11,2×4,8)cm das Format eines etwas dickeren Manuscripts, komplett passiv gekühlt, damit also kaum hörbar und hat dazu nur 12 Watt Leistungsaufnahme, was einen Dauerbetrieb über den gesamten Arbeitstag unbedenklich macht.

Vorinstalliert ist besagtes Debian-System mit dem KDE-Desktop, Firefox und OpenOffice. Damit sollten die meisten Anwendungsfälle abgedeckt sein.

Leider gibt es keinen Testdownload des angebotenen Systems – Debian lässt sich schließlich auf die unterschiedlichsten Arten konfigurieren, wie die verschiedenen Derivate zeigen und auch über die Update-Fähigkeit werden keine Aussagen gemacht. Zweites Manko ist der Preis von 450 Euro – dafür bekommt man durchaus schon einen recht leistungsfähigen PC oder kann einen weniger leistungsfähigen PC 2 Jahre lang mit Strom versorgen. Die Office-Eigenschaften müssen hier gezielt gewünscht und mit viel Geld erkauft werden. Denkbar wäre aber eine Subventionierung solcher Geräte im Rahmen eines Umweltschutzprojektes.

Für mich käme das Gerät wohl nicht in Frage, da es als Entwicklungsrechner nur begrenzt einsetzbar ist. Sowohl Prozessor als auch Hauptspeicher entsprechen nicht mehr den heute üblichen Voraussetzungen. Trotzdem würde ich darauf gern mal ein bis zwei Tage testarbeiten – ich kann mir gut vorstellen, dass sich alle anderen Dinge damit sehr gut erledigen lassen.

KDE PIM: Kalenderreparatur

Leave a reply

Ich habe mich vorgestern abend gefreut, dass doch tatsächlich noch eine Version 3.5.8 der KDE mit einer großen Menge von Bugfixes über den Debian Paketstream geliefert wurde. Leider kam dann gestern auch die Ernüchterung: Seit dem Update funktionierte mein Kalender nicht mehr.

Um auch von anderen Rechnern aus auf meine Kalenderdaten zugreifen zu können, benutze ich einen IMAP-Account zur Ablage der Kalenderdaten. Die einzelnen Einträge werden dabei im ical-Format in jeweils eine E-Mail gelegt. Ich finde das sehr praktisch, weil es sich gut speichern lässt, für IMAP eine Menge Bibliotheken vorhanden sind und man so auch mit anderer Software leicht zugreifen kann.Die Fehlermeldung war:

libkcal: ERROR: Can't read uid map file

Damit das im Kontact verwendet werden kann, muss man im KMail einen Groupware-Ordner angeben, unterhalb dem dann die PIM-Daten (Kalender, Notizen, Kontakte und Journal) abgelegt werden. Seit der Version 3.5.8 (bzw nach den Newsgroups wohl schon ein wenig früher) hat sich diese Konfiguration wohl geändert, jedenfalls ist nun ein Eintrag notwendig, um zu kennzeichnen, welcher IMAP-Account für die Daten zuständig ist. Das musste ich von Hand nachpflegen.

Eine Anleitung, was dabei zu tun ist, gibt es in folgendem Foreneintrag: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/139433/comments/7

Damit funktioniert mein Kalender nun wieder und ich kann mich auch wieder ordentlich organisieren. Nebenbei ist mir aber mal wieder aufgefallen, wie sehr man sich doch von der Funktion bestimmter Tools abhängig macht. Es wird Zeit, dass ich mir eine zweite Alternative für den Zugriff auf diese Kalenderdaten suche.

Backup auf DVD-RAM

Leave a reply

Ich hatte am Sonnabend an den Build-Skripten für meine Eisfair-Pakete geschraubt. Sonnabend ist auch einer von zwei Tagen in der Woche, wo mein Heimserver Backups macht, die ich für gewöhnlich auf DVD-RAM kopiere. Da das immer die gleichen Arbeitsabläufe sind und ich gerade drin steckte im Programmieren, hab ich mir für das Backup ein kleines Skript geschrieben, das diese Arbeitsabläufe auf den Aufruf des Skriptes zusammenfasst. Das Skript mal gekürzt:

#!/bin/sh
. /var/install/include/eislib
mecho -info "Mounting DVD..."
mount -t udf /dev/cdrom /cdrom
mecho -info "Removing old backup..."
rm -f /cdrom/backup-zip/*
rm -f /cdrom/svn/*
mecho -info "Getting free space from DVD... "
DVDFREEMB=`df --block-size=M | awk '//dev/cdrom/ {print $4}'
    | sed -e 's/(^[0-9]*).*/1/'`
mecho -info "Getting size of home dir backup..."
cd /mnt/data/backup/backup-zip/cron
CUMBUSIZE=0
for i in `ls -l --block-size=M | awk '/home_1/ {print $5}'
    | sed -e 's/(^[0-9]*).*/1/'`
do
	CUMBUSIZE=`expr $CUMBUSIZE + $i`
done
cd /mnt/data/backup
SVNSIZE=`du --block-size=M -s svn/ | cut -f1
    | sed -e 's/(^[0-9]*).*/1/'`
CUMBUSIZE=`expr $CUMBUSIZE + $SVNSIZE + 25`	# sicherheitsfaktor
if [ $CUMBUSIZE -gt $DVDFREEMB ]
then
	mecho -error "Backup is $CUMBUSIZE MB but only $DVDFREEMB MB are free on DVD. Aborting..."
	exit 1
else
	mecho -info "Backup is $CUMBUSIZE MB and $DVDFREEMB MB are free on DVD. Continuing..."
fi
# script continues with copying, cutting off here...

Das Debuggen wurde mir in diesem Fall künstlich erschwert, weil meine eine DVD-RAM allem Anschein nach jetzt kaputt ist. Das Backup selbst dauerte doppelt so lang wie normal mit diversen Fehlermeldungen vom UDF-Dateisystem im Syslog und bei der letzten Datei wurde wider Erwarten abgebrochen mit der Meldung es sei nicht genug Platz auf dem Datenträger. Mehrfaches Neuformatieren hat nichts gebracht. Das ist eine beinahe schockierende Erkenntnis, gelten DVD-RAM-Medien doch als wesentlich sicherer für Backups als herkömmliche DVD±RW. Das Backup lief mit einem frischen Medium dann in einer guten Stunde durch.

Eine andere Sache ist das Skript selbst nochmal. Ich lasse mir von den unterschiedlichen Tools Speicherplatz in Megabyte ausgeben, d.h. die Angaben sind beispielsweise “512M”, also immer eine Zahl mit dem “M” dahinter. Mangels tiefergehender Kenntnisse in awk jage ich das weiter an sed wo ich dann mit einem regulären Ausdruck alles hinter den Ziffern entferne. Das ist ja nun schlechter Stil, normalerweise sollte awk das direkt selbst machen können, d.h. in die geschweiften Klammern muss nicht nur “print” rein…
Wenn jemand eine Idee hat, wie das zu bewerkstelligen ist, bitte ich Euch es mich wissen zu lassen!