Ubuntu › Seite 8 › loggn.de

Ubuntu/Debian – Kernel: 2.6.32.3 – Loop-AES selber kompilieren

Nach meinem Kernelupdate auf Version 2.6.32.3 wollte ich ganz normal, wie in der alten HowTo beschrieben, loop-AES kompilieren. Jedoch lief bereits das Kompilieren von util-linux-2.12r auf Fehler.

cc -c -O2 -fomit-frame-pointer -I../lib -Wall -Wmissing-prototypes -Wstrict-prototypes -DNCH=1&nbsp;&nbsp; -D_FILE_OFFSET_BITS=64 -DSBINDIR=\&quot;/sbin\&quot; -DUSRSBINDIR=\&quot;/usr/sbin\&quot; -DLOGDIR=\&quot;/var/log\&quot; -DVARPATH=\&quot;/var\&quot; -DLOCALEDIR=\&quot;/usr/share/locale\&quot; -O2 fsck.cramfs.c -o fsck.cramfs.o
fsck.cramfs.c:79:22: error: asm/page.h: No such file or directory
fsck.cramfs.c: In function ‘romfs_read’:
fsck.cramfs.c:144: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result
fsck.cramfs.c: In function ‘do_symlink’:
fsck.cramfs.c:274: warning: ignoring return value of ‘symlink’, declared with attribute warn_unused_result
fsck.cramfs.c: In function ‘do_uncompress’:
fsck.cramfs.c:361: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
fsck.cramfs.c: In function ‘main’:
fsck.cramfs.c:532: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result
make[1]: *** [fsck.cramfs.o] Fehler 1
make[1]: Verlasse Verzeichnis '/usr/src/util-linux-2.12r/disk-utils'
make: *** [all] Fehler 1

Um dieses Problem schnellstmöglich zu umgehen habe ich mich für die util-linux Alternative util-linux-ng entschieden. Kurz und knapp nochmal die veränderte HowTo: Ubuntu/Debian – Kernel: 2.6.32.3 – Loop-AES selber kompilieren weiterlesen

Ubuntu Server 9.10 – update-grub hängt

Heute war es mal wieder an der Zeit meinen Ubuntu-Server aufzuräumen. Ich habe mehrere alte Kernel mit aptitude ge’purge’d. Leider ist die Paketverwaltung beim Running postrm hook script /usr/sbin/update-grub hängen geblieben.

...
Entferne linux-image-2.6.31-16-generic ...
Running postrm hook script /usr/sbin/update-grub

Auch ein Beenden der Paketverwaltung und erneutes Ausführen brachte keinen Erfolg, update-grub sowie update-grub2 schwieg nach dem Ausführen… 😥

Lösung: Ein simpler reboot des Systems hilft manchmal Wunder.

Ubuntu Karmic 9.10 – NVIDIA VDPAU + SMplayer – Dekodieren, Deinterlacen und Skalieren über die GPU

Alle Jahre wieder…

Am Wochenende wollte mein Ubuntu 9.04 auf das aktuelle 9.10 updaten, verschlafen wie ich war stimmte ich dem Ganzen zu. Nach jeder Menge Fehlermeldungen inklusive nvidia-common wollte das System neu starten, jedoch verweigerte ich den Neustart und genoss meinen Sonntag auf der Couch. Nichtsahnend, was am nächsten Tag wohl passieren mag fuhr ich meinen Media-PC dann am Abend herunter. Nach 8 Stunden Arbeit und den letzten Weihnachtseinkäufen kam ich nach Hause, mein MacBook erblickte das Licht der Welt und mein Media-PC bootetet. Dann erschien plötzlich und völlig unerwartet die Fehlermeldung „Ubuntu running in low graphics mode“. 😡 *…der Abend ist dann wohl gelaufen!*

Nachdem die Versuche den NVIDIA-Treiber über das Karmic Repository zu installieren zwar erfolgreich waren aber keine VDPAU Unterstützung verfügbar war versuchte ich das Ganze noch einmal mit dem NVIDIA-VDPAU-TEAM Repository. Alle Versuche schlugen fehl!

In der Ubuntuusers-Community konnte man verfolgen dass viele Mitglieder Probleme nach dem Update auf Version 9.10 hatten, fast jedes Mal wurde zu einer Neuinstallation geraten.

Gesagt, getan! Zehn Minuten später, mit dem frisch installiertem Ubuntu Karmic 9.10, lief alles wieder wunderbar.

sudo vi /etc/apt/sources.list

Auf dem Launchpad PPA vom NVIDIA-VDPAU-TEAM gibt es ein schönes Repository, ein Rundum-Sorglos-Paket für VDPAU.

deb http://ppa.launchpad.net/nvidia-vdpau/ppa/ubuntu/ karmic main
deb-src http://ppa.launchpad.net/nvidia-vdpau/ppa/ubuntu/ karmic main

Jetzt holen wir den PGP-Key, damit aptitude nicht diese Fehlermeldung NO_PUBKEY 1DABDBB4CEC06767 zeigt. Ubuntu Karmic 9.10 – NVIDIA VDPAU + SMplayer – Dekodieren, Deinterlacen und Skalieren über die GPU weiterlesen

Ubuntu – Green IT – Suspend to RAM – Flexibler Ladenschluss

Tausende von Servern laufen ohne irgendeine Aktivität 24 Stunden am Tag, 7 Tage die Woche und 365 Tage im Jahr. Aber wenn kein Client im Netzwerk aktiv ist muss in den meisten Netzwerken auch kein Server mehr aktiv sein. In meinem Fall läuft der Server auch 24 Stunden am Tag, obwohl dieser auch nur laufen müsste wenn ein anderen Client im Netzwerk aktiv ist. Mein System (NAS, Backup, VDR-Stream und Virtualisierung) hat eine Leistungsaufnahme von 140 W, das entspricht 3,4 kWh am Tag, 100,8 kWh im Monat. Bei 20 Cent pro Kilowattstunde ergibt das umgerechnet 20,16 € im Monat.

Da kommt der c’t-Artikel in der 25. Ausgabe 09 auf Seite 190 gerade richtig.

Flexibler Ladenschluss
Wake on LAN und Schlaf bei Bedarf für Server und NAS
Linux-Server laufen meist den ganzen Tag, was reichlich Strom vergeudet. Ein Skript legt sie immer dann schlafen, wenn niemand mehr im LAN ist, der ihre Dienste braucht.

Der Autor Reik Kaps hat einen sehr interessanten Artikel geschrieben, das aktuelle Skript kann von einem Mercurial-Repository bei Intuxication heruntergeladen werden. (server-sleepd)

Ubuntu – Green IT – Suspend to RAM – Flexibler Ladenschluss weiterlesen

Debian vs. Ubuntu Server – Suspend to RAM

In den meisten Fällen ist der Ruhezustand und der Bereitsschaftsmodus unter Ubuntu kein Problem mehr. Mit der Linux-Distribution Debian habe ich festgestellt, dass es mit bestimmter Hardware hin und wieder zu Problemen kommt. Das kann daran liegen, dass bei Ubuntu die Pakete wesentlich aktueller gehalten werden.

Server-Hardware:

Board: MSI P45D3 Platinum
CPU: Intel Pentium Dual-Core E2220
RAM: G.Skill DIMM 2GB PC3-10667U
GPU: ASUS Extreme N6200LE TC256
DVB-S2: TechnoTrend S2-3200 HDTV-S2
SYS-HDD: OCZ Throttle eSATA Flash Drive 8GB
DATA-HDDs: Samsung SpinPoint F1 1000GB (HD103UJ)

Die letzten 6 Tage habe ich mich mit dem Bereitschaftsmodus (Suspend to RAM) unter Debian Lenny (ohne X-Server) beschäftigt. Nachdem ich alle erdenklichen Wiki-Einträge, Foren-Threads und Blog-Artikel über dieses Thema gelesen habe, alle möglichen Kommandos inkl. Optionen ausprobiert habe, bin ich zu dem Fazit gekommen > „Was für ein Sch***!“.

Problem: In meinem Fall ist das System beim pm-suspend problemlos in den Bereitschaftsmodus gefahren. Auch die Logdatei /var/log/pm-suspend.log wurde geschrieben, keinerlei Fehlermeldungen. Nach dem Aufwachen sollte jedoch genau in diese Logdatei auch wieder geloggt werden, das geschah nicht. Ein Ping kam circa 5-10 Sekunden nach dem Aufwachen am System an, danach ist es eingefroren. Debian vs. Ubuntu Server – Suspend to RAM weiterlesen