Month: August 2015

Default Kompressionsalgorithmus von debuild ändern

Leave a Comment

Auf Arbeit laufen große Teile der Clients noch auf Ubuntu 12.04 Precise, weshalb ich dafür natürlich auch meist Pakete dafür baute. Gestern habe ich ein paar Pakete für 14.04 Trusty bauen müssen und hab dabei fast die Kriese bekommen. Das bauen an sich machte keine Probleme, allerdings unser Repository, welches schon etwas in die Jahre gekommen ist. Ich bekam nun bei erstellen des Repository’s jedes mal 

E: This is not a valid DEB archive, it has no 'data.tar.gz', 'data.tar.bz2' or 'data.tar.lzma' member
E: Errors apply to file '/var/www/linux/dists/gpl-trusty/main/binary-i386/libmd5-perl_2.03-1_all.deb'

Wenn ich mir das nun auf unserem Repository das Paket anschaute meldete der auch das damit etwas nicht stimmt. Gut hier ist es wieder meine eigene Schuld, denn ich las die Fehlermeldung nicht richtig, welche wie folgt lautete:

dpkg-deb: file `/root/gpl-trusty/main/libmd5-perl_2.03-1_all.deb' contains ununderstood data member data.tar.xz, giving up

Hätte ich mir diese und die vorhergehende Meldung mal direkt genauer angeschaut, hätte ich auch gesehen das er einfach mit dem Kompressionsalgorithmus XZ nicht klar kommt. Also Fazit, unter Trusty wurde der Default Kompressionsalgorithmus auf XZ gestellt, womit alte Systeme ein Problem haben. Nun muss ich also debuild beibringen das er wieder gzip als Default zu benutzen hat, was ich wie folgt getan habe:

  • Die Datei /usr/local/bin/dpkg-deb, mit folgendem Inhalt, erstellen
    • #!/bin/bash
/usr/bin/dpkg-deb -Zgzip $@
  • Folgendes noch in der .bashrc hinzufügen, da es in meinem Fall dauerhaft sein soll
    • alias debuild="debuild --preserve-envvar PATH"

    Anschließend nutzt dann debuild auch gzip und alles funktioniert. Es gibt auch noch andere Varianten debuild dazu zu bewegen gzip zu nutzen, wie beispielsweise die Datei debian/source/options mit folgendem Inhalt anzulegen:

    compression = "gzip"

    Dies ignorierte aber debuild bei mir komplett.

    Quelle: http://comments.gmane.org/gmane.linux.debian.devel.devscripts/9977

    PS: Dank geht auch wieder an meinen Kollegen, der mir bei der Aufklärung behilflich war.

    Diskfilter writes are not supported

    2 Comments

    Auf Servern mit Ubuntu 14.04 bekomme ich beim booten schon immer folgenden Fehler angezeigt:

    error:  Diskfilter writes are not supported

    Dies ist ein Bug, der Auftritt wenn man die Root, oder wenn einzeln die Boot Partition, in einem RAID oder LVM anlegt. Ein sehr gute ausführliche Beschreibung, warum der Bug auftritt gibt es in diesem Forumbeitrag: Beitrag bei askbuntu.com Da dieser alles ziemlich gut erklärt, werde ich das jetzt nicht nochmal niederschreiben, sondern nur die Lösung:

  • Download der gepatchten GRUB Header Datei
    • wget https://gist.githubusercontent.com/rarylson/da6b77ad6edde25529b2/raw/99f266a10e663e1829efc25eca6eddb9412c6fdc/00_header_patched
  • Sichern der Originaldatei und verschieben der neuen
    • mv /etc/grub.d/00_header /etc/grub.d/00_header.orig
mv 00_header_patched /etc/grub.d/00_header
  • Altes Script deaktivieren und neues aktivieren
    • chmod -x /etc/grub.d/00_header.orig
chmod +x /etc/grub.d/00_header
  • GRUB updaten
    • update-grub

    Wie man in dem Beitrag auch lesen kann ist das ab 15.04 gefixt. Warum sie den Patch nicht in 14.04 einfließen lassen, versteh ich nicht.

    Move LV’s von einem Device auf ein anderes

    Leave a Comment

    Ich habe auf Arbeit ein Storage worin 3 RAID’s sind. Ein RAID1, welches für diesen Artikel irrelevant ist, ein RAID6 (md1) worauf iSCSI Volumes in Form von LV’s liegen und ein RAID5 (md2) welches zum Testen da ist. Das RAID6 besteht dabei aus 8 relativ alten Platten, welches nun zu bröckeln anfing und zu allem Übel fing ein Platteneinschub auch noch an CRC Error zu produzieren, wodurch ein Plattentausch verhindert wurde, da jede sofort wieder aus dem RAID geworfen wurde. Es wurde von mir also kurzer Hand das RAID5 Volume gekapert, da mir die Tests in dem Moment relativ egal waren, und fügte es meiner VG hinzu:

    vgextend vg /dev/md2

    Diese sollte mit einer Erfolgsmeldung quittiert werden. Man kann aber mit pvdisplay nochmal kontrollieren. Um zu sehen auf welchem Volume welches LV liegt benutzt man

    lvs -o +devices

    Moven der LV’s geht dann wie folgt, entweder man tut es mit jeder einzeln:

    pvmove -n test /dev/md1 /dev/md2

    was ich, wie man schon an dem Namen der LV sieht, erstmal nur zum testen tat, oder man verschiebt einmal den gesamten Pool:

    pvmove /dev/md1 /dev/md2

    Das ganze funktionierte während des Betriebs, ohne das die VM’s, zu welchen die LV’s gehören, irgendwas davon merkten. Das ganze dauert natürlich, abhängig von der Größe eine ganze Weile, da die Daten blockweise kopiert werden.
    Sind die Daten dann alle verschoben kann man das kaputte RAID aus der VG entfernen:

    vgreduce vg /dev/md1