nginx: SSL mit Perfect-Forward-Secrecy und SPDY unter Ubuntu

Geschrieben von everflux am Juni 27th, 2013

Es gibt SSL und es gibt SSL mit Perfect-Forward-Secrecy (PFS). Der Unterschied: Bei perfect forward secrecy kann durch den Verlust des privaten Schlüssels nicht im Nachhinein aufgezeichnete Kommunikation der Vergangenheit entschlüsselt werden. Der Grund liegt darin, dass der zufällige Sitzungsschlüssel nicht zwischen den Parteien mittels public-key-cryptography versendet wird, sondern mit einem speziellen Verfahren berechnet wird. Bei diesem Diffie-Hellmann-Schlüsselaustausch berechnen beide Parteien gemeinsam einen Sitzungsschlüssel. Der private Schlüssel hilft später nicht den Sitzungsschlüssel zu erlangen, jeder Sitzungsschlüssel muss einzeln mit speziellen Verfahren gebrochen werden, was aufwendig ist.

Damit Besucher einer Webseite keine Warnung des Browsers erhalten, weil dem Zertifikat der Webseite nicht vertraut wird, empfiehlt es sich, das Zertifikat von einer CA signieren zu lassen, die von den Browserherstellern unterstützt wird.
Ein Anbieter kostenloser Zertifikate ist „StartSSL“: http://www.startssl.com/

Wenn man lediglich SSL und perfect-forward-security mit nginx konfigurieren moechte, funktioniert dich bereits mit Ubuntu 12.04 Precise (LTS). Fuer SPDY reicht das alleine nicht: Die OpenSSL Version ist nicht aktuell genug und nginx ist nicht mit dem Modul kompiliert worden. Aber dazu gibt es ein PPA 🙂

Erster Schritt: SSL Zertifikat besorgen. Mit diesem Aufruf (www.server.com durch die korrekte Domain ersetzen) erzeugt man die nötigen Dateien (private key und certificate signing request).

openssl req -nodes -newkey rsa:4096 -nodes -keyout myserver.key -out server.csr \
-subj "/C=DE/ST=State/L=City/O=Company/OU=IT/CN=www.server.com"

Zweiter Schritt: Bei StartSSL signieren lassen. Das Ergebnis speichert man in der Datei „www.example.com.pem“.

Dritter Schritt: CA Zertifikat herunterladen

wget http://www.startssl.com/certs/sub.class1.server.ca.pem
wget http://www.startssl.com/certs/ca.pem

Vierter Schritt: Wir erzeugen eine Datei mit den Diffie-Hellmann-Parametern

openssl dhparam -rand - 1024 > dhparam.pem

Fünfter Schritt: Alles zu einer certificate-chain vereinigen.

cat ww*.pem dhparam.pem sub.class1.server.ca.pem ca.pem > www.example.com.chain.pem

Sechster Schritt: Konfiguration von nginx mit SSL – die IP 1.2.3.4 ersetzt man durch die korrekte.

server {
#your IP here
listen 1.2.3.4:443;
server_name www.example.com;
#ssl
ssl on;
ssl_certificate /etc/nginx/ssl/example.com.chain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
#PFS
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers On;
ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;
...
}

Fertig bis auf SPDY Support. Das ganze kann man mit dem SSL Check Tool von https://www.ssllabs.com/ssltest/ zusätzlich auf korrekte Konfiguration prüfen.

Für SPDY Support geht es so weiter:
Installation einer nginx Version mit SPDY Support die statisch gegen OpenSSL gelinkt ist, so dass NPN Support (Next protocol negotiation) funktioniert, auch wenn Ubuntu 12.04 eigentlich mit einem älteren OpenSSL kommt.

sudo add-apt-repository ppa:chris-lea/nginx-devel
sudo apt-get update
sudo apt-get install nginx-full

nginx Konfiguration anpassen:

server {
...
listen 443 ssl spdy default_server;
...
}

Damit auch User, die nicht per SSL auf die Seite zugreifen SPDY erkennen und umschalten, kann man noch diesen Header setzen:


add_header Alternate-Protocol 443:npn-spdy/2;

Als Performance Verbesserung kann noch diese Option zur Aktivierung von OCSP Stapling verwendet werden:

#google public dns
resolver 8.8.8.8;
ssl_stapling on;
ssl_trusted_certificate ssl/www.example.com.chain.pem;

Leider ist mit der Apache Version, die derzeit mit Ubuntu ausgeliefert wird, kein performantes perfect forward secrecy möglich. Der Apache http in der (uralt) Version hat keine Unterstützung für elliptic curve cryptography mit der die gemeinsame Berechnung eines Sitzungsschlüssels schnell und ressourcenschonend möglich ist.
Es gibt zwar andere Algorithmen die mittels Diffie-Hellmann PFS realisieren und auch mit dem Apache httpd funktionieren, jedoch sind diese für größere Webseiten nicht ohne zusätzliche Hardware praktikabel.

Ubuntu 12.04: OpenJDK selber bauen

Geschrieben von everflux am Mai 12th, 2012

Ubuntu ist für mich die präferierte Entwicklungsplattform, sicherlich geht es vielen anderen (Java) Softwareentwicklern ähnlich. Und im Sinne von OpenSource möchte man OpenJDK auch auf dem eigenen Rechner übersetzen können. Das ist z.B. nützlich, wenn man selber das Java mal patchen oder debuggen möchte, aber auch um z.B. die neuesten Entwicklungen von Java 8 auf dem eigenen System ausprobieren zu können.

Im Vergleich zu früher macht der Übergang von Ubuntu zu MultiArch auf 64 bit Systemen etwas Probleme, jedoch ist das mit einem „gewusst wie“ schnell erledigt. Als Vorbedingung muss ein Java (OpenJDK 6/7, Oracle JDK) installiert sein. Ich habe in meinem Fall unter /usr/lib/jvm/jdk1.7.0 ein Oracle JDK installiert.

Als nächstes benötigt man Mercurial, die hgforest extension und ein paar Bibliotheken für den Build. Ich installiere hgforest im Home-Verzeichnis, wer das nicht mag, muss die Pfade entsprechend anpassen:

apt-get install mercurial
apt-get install gawk g++ libcups2-dev libasound2-dev libfreetype6-dev libx11-dev libxt-dev libxext-dev libxrender-dev libxtst-dev libfontconfig1-dev
hg clone https://bitbucket.org/pmezard/hgforest-crew/overview/ "$HOME/hgforest"

Die hgforest Erweiterung fuer Mercurial traegt man direkt in der Mercurial Konfiguration ein, indem man die Datei ~/.hgrc editiert und folgenden Abschnitt ergaenzt (auch hier gilt dann ggf. den Pfad anzupassen)

[extensions]
forest=~/hgforest/forest.py

Nun clont man die OpenJDK Sourcen aus dem Updates-Repository für OpenJDK 7:

hg fclone http://hg.openjdk.java.net/jdk7u/jdk7u openjdk7u

Dazu solle man ca. ein Gigabyte Speicher auf der Festplatte einplanen. Bei dem ersten Build sollte auch eine Internet Verbindung vorhanden sein, da ggf. noch zusätzliche Libraries nachgeladen werden. Nun starten wir den Build:

cd openjdk7u
unset JAVA_HOME
export LANG=C
export ALT_BOOTDIR="/usr/lib/jvm/jdk1.7.0"
export ALLOW_DOWNLOADS=true
export EXTRA_LIBS=/usr/lib/x86_64-linux-gnu/libasound.so.2
make sanity && time make

Zu beachten ist hier, dass die Environment-Variablen „ALLOW_DOWNLOADS“ und „EXTRA_LIBS“ gesetzt sind. Letztere rührt daher, dass auf 64 Bit Systemen mit Ubuntu das OpenJDK Build-System die Libraries (noch) nicht von selbst richtig findet. Auf 32 bit Systemen wird das nicht nötig sein, und vermutlich auch in zukünftigen OpenJDK Versionen direkt implementiert sein.

Der Build Output sollte in etwa so aussehen:

########################################################################
##### Build time 00:10:30 jdk for target(s) sanity all docs images #####
########################################################################


#-- Build times ----------
Target all_product_build
Start 2012-05-12 11:40:32
End   2012-05-12 12:04:01
00:01:27 corba
00:10:15 hotspot
00:00:18 jaxp
00:00:27 jaxws
00:10:30 jdk
00:00:32 langtools
00:23:29 TOTAL
-------------------------


real    23m30.532s
user    32m10.625s
sys    2m24.617s

Im Ordner „build“ befindet sich dann der Ordner „linux-amd64“ in dem sich das frisch kompilierte Java auch ausführen lässt:

./build/linux-amd64/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse_2012_05_12_11_40-b00)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
Übrigens lässt sich genauso einfach auch Java 8 (OpenJDK 8 ) auf einem Debian oder Ubuntu System übersetzen, das Repository ist unter http://hg.openjdk.java.net/jdk8/jdk8/ zu finden.

Grub bootet nicht – fail von recordfail?

Geschrieben von everflux am März 10th, 2012

Ubuntu setzt den Grub / Grub2 Bootloader standardmäßig ein. Solange er funktioniert ist auch alles prima. Bei Desktop Rechnern gibt es sowieso kein Problem – hier kann man notfalls manuell eingreifen und im Boot Menü seine Lieblingsoption auswählen oder ganz von Hand booten.
Bei Servern sieht das schon etwas anders aus. Normalerweise sind diese nicht an eine Konsole angeschlossen, oder stehen sogar (sehr) weit weg.
Ein Feature von Grub ist, dass sich der Bootloader merken kann, ob ein Startvorgang erfolgreich war. Wenn der schief geht, wird beim nächsten Start nicht direkt gebootet, sondern das Grub Menü bleibt stehen, damit der Anwender eine andere Option auswählen kann. Das ist für einen Desktop Rechner sicherlich genau das gewünschte, und Ubuntu zielt primär auf Desktop User. Der Anwender kann jetzt eine Rettungs-Konfiguration auswählen, oder es einfach nochmal versuchen.
Wenn bei einem Server ein boot jedoch schief geht – z.B. weil genau da ein Reset/Stromausfall o.ä. stattfindet – dann steht der Server. Bis jemand etwas von Hand einstellt. Das kann dann eine längere Downtime bedeuten.
Ich kann damit besser leben wenn der Server im Falle eines Defekts endlos immer wieder Boot-Versuche unternimmt, als wenn er stehen bleibt weil einmal etwas blöd gelaufen ist. Das ist auch ganz einfach zu ändern:
Man öffne die Datei /etc/grub.d/20_header und ersetze folgenden Abschnitt

if [ "\${recordfail}" = 1 ]; then
  set timeout=-1

Durch diesen Abschnitt:

if [ "\${recordfail}" = 1 ]; then
  set timeout=30

Danach noch ein "update-grub" und in Zukunft wird im Falle eines Bootfehlers 30 Sekunden auf Eingaben gewartet und sonst ein neuer Boot-Versuch gestartet.

Ubuntu VLC: Echo, Kratzen und Rauschen

Geschrieben von everflux am März 3rd, 2012

Seit gewisser Zeit – ich weiss nicht wann genau – habe ich Probleme mit dem Sound von VLC: Es rauscht, knistert und es klingt als würde die Audio Spur doppelt wiedergegeben.

Totem und andere Programme machen dabei keine Probleme, lediglich VLC. Der Rechner ist ein 6 Kern AMD mit Ubuntu 11.10 und VLC 1.1.12 aus dem Ubuntu Repository. Auch verschiedene Einstellungen bei den VLC Audio Codecs und Wiedergabe Devices (Alsa, Pulse-Audio, OSS) haben dabei nichts geändert.

Abhilfe konnte ich jedoch zum Glück auch finden:  Ich habe „pavucontrol“ installiert und dann das vorhandene HDMI Wiedergabe Gerät deaktiviert und den Stereo-Ausgang umkonfiguriert (kein demux mehr). Siehe da, alles ist prima!

sudo apt-get install pavucontrol

Danach starten und Konfiguration anpassen.

Virtualisierung: I/O Last senken mit KVM/libvirt

Geschrieben von everflux am Dezember 11th, 2011

Das Thema Virtualisierung geht einher mit neuen Anforderungen an die Ressourcen des Host Systems. Da zwar die CPU Leistung kontinuierlich zunimmt (Anzahl Kerne, Leistung/Stromverbrauch) und auch RAM Speicher immer günstiger wird, jedoch die Leistung der Festplatten nicht zunimmt, ergeben sich neue Probleme: Selbst mit schnell drehenden Platten und RAID Verbund wirkt sich die erhöhte Last durch mehrere virtualisierte Maschinen auf einem „Blech“ deutlich aus, da die Leistung – gemessen an der Anzahl der I/O Operationen pro Zeiteinheit – nicht mit gewachsen ist. Durch mehrere virtualisierte Systeme verändert sich auch das Zugriffsprofil: Selbst lineares Lesen jedes einzelnen Systems für sich sieht für die Festplatten eher wie ein Zufallsmuster aus, da mehrere Systeme parallel arbeiten. Ein Weg zur Erhöhung der I/O Operationen pro Sekunde ist starkes Caching oder Einsatz von SSD Festplatten (die wieder eigene Probleme haben).

Für den Einsatz unter Linux hat sich KVM als Standard für Virtualisierung durchgesetzt, ergänzt um Abstraktionsschichten wie libvirt. Vor allem bei den derzeit angebotenen dedicated Servern lohnt sich die Nutzung als Virtualisierungshost, da dies die Management-Möglichkeiten deutlich verbessert werden und die Flexibilität erhöht wird. Bei dieser Konstellation wird in der Regel die lokale Platte/Platten als Storage verwendet, mit den oben angeführten Einschränkungen. Was noch dazu kommt: Virtualisiert man die Festplatten „direkt“, stellt diese also als IDE oder SCSI Device zur Verfügung, kommt deutlicher Overhead dazu. Der lässt sich nicht vermeiden, wenn man Windows oder ein Betriebssystem virtualisiert, das keine Paravirtualisierung unterstützt.

Paravirtualisierung liegt dann vor, wenn das virtualisierte System etwas davon weiß, in welcher Umgebung es läuft, und entsprechend kooperativ ist. Mit Linux ist das kein Problem, unter anderem durch die Vorarbeiten die fuer die Xen Virtualisierung erfolgt ist. Daher sollte man nicht als „ide“ sondern „virtio“ als Schnittstelle für Gäste verwenden, die das unterstützen, um geringere Last und höhere Performance zu erzielen.

Weiterlesen »

Ubuntu HDMI (kein) Sound

Geschrieben von everflux am Oktober 14th, 2011

Seit meinem neuen Computer (und Ubuntu Oneric) ist mein zweiter Monitor per HDMI Kabel angeschlossen. Das Problem: Per HDMI ist neben Bild- auch ein Tonausgabegerät und wird als Default Device verwendet. Damit ist dann teilweise nichts zu hören – offenbar ist das jedoch Anwendungsabhängig.

Als Lösung habe ich mir pragmatisch ein virtuelles pulseaudio device eingerichtet, dass auf alle Geräte den Sound dann ausgibt. Dazu installiert man sich das Paket „paprefs“

sudo apt-get install paprefs

und starte diese („paprefs“). Auf dem Reiter „simultaneous output“ (im englischen) kann dann ein virtuelles Gerät aktiviert werden, dass die Ausgabe auf alle Geräte weiterleitet.

Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration

Geschrieben von everflux am Oktober 14th, 2011

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem „Master Password“ gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter „0“. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die „echte“ Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern „lediglich“ eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Oneiric update auf VM Gast bricht ab

Geschrieben von everflux am Oktober 14th, 2011

Wer einen KVM/VM Gastsystem dass mit „vmbuilder“ erstellt wurde auf Ubuntu Oneiric updaten möchte wird möglicherweise diese unschöne Überraschung erleben:


A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.

Ein Blick in die genannten Logdateien hilft weiter:

2011-10-14 08:39:47,147 DEBUG creating statefile: '/var/log/dist-upgrade/apt-clone_system_state.tar.gz'
2011-10-14 08:39:56,877 DEBUG lspci failed: [Errno 2] No such file or directory
2011-10-14 08:39:56,920 DEBUG lsb-release: 'natty'
2011-10-14 08:40:00,162 ERROR not handled exception:
Traceback (most recent call last):

Da schlägt der Aufruf von „lspci“ fehl. Das Paket ist in dem per vmbuilder unter lucid erstellten System nicht installiert, und wurde auch bei den nachfolgenden Updates nicht als Dependency deklariert und somit nicht installiert.
Installiert man das Paket kurzerhand selbst

sudo apt-get install pciutils

funktioniert danach das Update auf den ersten Blick auch fehlerfrei.

OpenJDK – Java 7 – mit Ubuntu kompilieren

Geschrieben von everflux am Juli 24th, 2011

Ich habe ein merkwuerdiges SSL Problem mit Java 7 (Build 147, dem Release Candidate) im Zusammenhang mit Online-Banking und Jameica/Hibiskus:

Caused by: java.security.cert.CertificateException: Certificates does not conform to algorithm constraints
 at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:873)
 at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:804)
 at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1319)
 ... 19 more

Schaut man sich dazu den Source Code an, sieht man schnell, dass leider die verursachende Exception verschluckt wird. (Das kommt davon, wenn Committer und Reviewer identisch sind…)
Meine Idee war also, OpenJDK selber zu bauen und da ggf. besseres Logging einzubauen. Die im Internet veröffentlichten Anleitungen sind alle ein paar Jahre alt und nicht mehr ganz korrekt, daher hier meine Ergebnisse zum Nachmachen.
Ich habe Ubuntu als System verwendet, dort ist eine Übersetzung von OpenJDK / Java 7 sehr einfach.
OpenJDK wird mittels Mercurial verwaltet, zur Hierarchiebildung wird die Mercurial Forest extension benötigt (und Mercurial). Ist das „mercurial“ Paket bereits installiert so kann man die Forest extension einfach herunterladen:

hg clone http://bitbucket.org/pmezard/hgforest-crew hgforest

Diese muss nun in die .hgrc eingetragen werden: (das „….“ durch den Pfad zum Download ersetzen)

[extensions]
forest=......hgforest/forest.py
fetch=

Danach installiert man die Build Abhängigkeiten:

sudo apt-get install build-essential gawk libasound2-dev libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev libxrender-dev

Und checkt per mercurial-forest die Sourcen fuer OpenJDK aus:

hg fclone http://hg.openjdk.java.net/jdk7/jdk7 jdk7

Da beim späteren Build noch Java Abhängigkeiten heruntergeladen werden müssen, hab ich noch folgendens in die Ant Konfiguration eingesetzt: ~/.antrc

ANT_OPTS=”$ANT_OPTS -Dallow.downloads=true”

Für den build benötigt man ein existierendes Java, und setzt folgenden Umgebungsvariablen:

export ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
unset JAVA_HOME
export LANG="C"
make sanity

Da sollten keine Fehler zu sehen sein und gibt dann den „make“ Befehl (dauert bei mir rund 40 Minuten):

make

Und kann es dann aus dem aktuellen Verzeichnis testen ob „java“ vorhanden ist:

build/linux-amd64/bin/java -version

Bei mir sieht das dann folgendermassen aus:

openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse-b00)
OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)

Fertig.
(Ja man benötigt wirklich keine „binary plugs“ o.a“. mehr!)

Update: Für Ubuntu 12.04 benötigt man folgende Pakete:

libcups2-dev, libfreetype6-dev, liboss4-salsa-dev

Und muss (Stand Mai 2012) auch wegen der neueren Kernelversion als die bei OpenJDK bekannten eine Environment Variable setzen:
export DISABLE_HOTSPOT_OS_VERSION_CHECK=ok

Ubuntu Natty: Busybox v1.17.1

Geschrieben von everflux am Mai 5th, 2011

Eine frische Ubuntu 11.04 Natty Installation schlug bei mir stets fehl: es kam statt des gewohnten Ubuntu Systems lediglich ein „Busybox v1.17.1“ Prompt.

Ich hatte das Ubuntu System dabei über den „Alternate Installer“ installiert, LVM crypt fuer full disc encryption und btrfs als Dateisystem. Nichts besonderes, und es hatte bisher mit Karmic und Jaunty immer prima geklappt. So ganz genau weiss ich auch nicht, woran es liegt, jedenfalls wird die Grub Konfiguration nicht korrekt erzeugt, und dadurch kann das System nicht korrekt hochfahren.

Man kann die Grub Flags manuell editieren und in meinem Fall fehlt dabei:

[email protected]

Hat man dies editiert, kann man mit Strg-X booten. Ein „update-grub“ alleine hat entgegen anderer Aussagen in den zugehoerigen Bugs im Canonical Bugtracker nicht geholfen.

Ich habe dann das Paket grub2 aktualisiert und nochmals „update-grub“ gemacht. Das hat jedoch auch nicht geholfen.

Schliesslich habe ich die /etc/default/grub Konfigurationsdatei editiert und da bei GRUB_CMDLINE_LINUX_DEFAULT noch „[email protected]“ eingetragen und „update-grub“ aufgerufen.

Danach funktionierte alles wie es sollte. puh.


http://everflux.de/
Copyright © 2007, 2008 everflux. Alle Rechte vorbehalten. All rights reserved.