Virtualbox (Failed, trying without DKMS)
vom: 26 November 2010.Ich habe immer wieder Probleme beim neu erstellen der Virtualbox Kernel Module. Bekanntlicher weise geht das ja via /etc/init.d/vboxdrv setup oder auf die neue Art service vboxdrv setup.
Die Ursache das das mit dieserse Fehlermeldung abbricht ist recht simpel …
(Failed, trying without DKMS)
Recompiling VirtualBox kernel modules ...failed!
(Look at /var/log/vbox-install.log to find out what went wrong)
… in meinem Falle fehlten immer die passenden Kernel Header zu meinem Linux Kernel. Unter Ubuntu könnt ihr mit sudo aptitude install linux-headers-`uname -r` diese herunterladen und installieren. Danach funktioniert service vboxdrv setup und die Virtualbox startet wieder fehlerfrei
Happy Birthday INVERT ;P
vom: 23 November 2010.Vielen Dank für all die Geburtstags.- Glückwünsche und Geschenke.
So schnell ist wieder ein Jahr rum und der Winter steht vor der Tür. Ich hoffe das ich in der kalten Jahreszeit mehr Zeit zum schreiben finde.
So und da das hier ein sehr Technik lastiges Blog ist gleich noch etwas zum Thema SSH Verbindungen unter Ubuntu ;)
Ich connecte von meinem Notebook via SSH zu den SSH Servern der Kunden. Im SSH Befehlt geben wir immer ein Tunnel an der dann über SSH aufgebaut wird. Zum Beispiel:
ssh user@213.165.64.75 -i ssh_schluessel.ssh -L 127.0.0.2:4000:192.168.1.10:3389
Es entsteht also auf meinem Notebook unter der IP 127.0.0.2 sowie dem Port 4000 der Server 192.168.1.10 und dessen Port 3389 (Windows Remote Desktop) zur Verfügung. Wenn man sich wie in dem o.g. Beispiel mit einem Dienst verbindet der keine direkten Eingaben erwartet (Remote Desktop zum Beispiel) dann meldet die SSH PTY allocation request failed on channel 1. Diese Meldung ist harmlos.
Der oben genannte Befehl ging bis Ubuntu 10.10 prima. Seit ich die frühe Alpha Version Ubuntu 11.04 einsetze bricht die o.g. Verbindung ohne weitere Meldung ab. Die übliche Meldung PTY allocation request failed on channel 1 ist aber der Schlüssel zu diesem Dilemma.
Teilt man SSH gleich im Befehl mit das man keine Shell will (-T) dann kommt a) die Meldung nicht mehr und b) wird die SSH Verbindung nicht unterbrochen wenn wir keine PTY bekommen.
Der oben genannte Befehl also nochmal, richtig ausgeschrieben:
ssh user@213.165.64.75 -i ssh_schluessel.ssh -L 127.0.0.2:4000:192.168.1.10:3389 -T
Sollte auch mit dem neuesten Ubuntu bzw. SSH Versionen funktionieren.
# ssh -v
OpenSSH_5.6p1 Debian-2ubuntu1, OpenSSL 0.9.8o 01 Jun 2010
Lenovo_x200_freeze_probleme
vom: 04 November 2010.Beschreibung der Funktion im Linux Kernel
http://www.mjmwired.net/kernel/Documentation/laptops/disk-shock-protection.txt
Hilfreich bei der formulierung der Shell Scripte
http://www.linuxjournal.com/content/running-complex-commands-sudo
=Zusätliche Informationen zum Thema
http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS
Speicher freigeben durch verwerfen der Kernel Caches
vom: 06 September 2010.Seit einigen Monaten habe ich immer wieder das gleiche Problem. Mein Notebook wird immer langsamer, oftmals reagiert die Mouse nur noch in Zeitlupe und Taskwechsel gehen mehr als zäh voran.
Das lässt in aller Regel auf zu wenig Speicher im System schließen. Ich habe in den Fällen immer versucht mit dem Befehl top den Prozess zu finden der den ganzen Speicher frisst. Leider konnte ich nie einen Prozess finden der übermäßig viel Speicher verbraucht.
Gestern nun bin ich auf diese Webseite gestoßen die den Linux Kernel als Ursache vermutet. Vielmehr den Cache (Zwischenspeicher) des Kernels. Mit einfachen, auf der Seite genannten Befehlen kann man den Cache Speicher des Kernels freigben. Bei mir brachte das machmal bis zu 800 MB zusätzlich freien Speicher. Es lohnt sich also auf alle Fälle.
Zudem ist das freigeben des Speicher “non destructive” d.h. ihr macht nichts kaputt wenn ihr den Cache freigebt ;)
Hier sind einige Screenshots zu sehen ich habe die gerade eben angefertigt ohne das ich irgendwelche Probleme mit meinem System hatte. Zu erst die Ausgabe von top, Mem: 1932432k total, 1176248k used, 756184k free wir haben also vorher 756184k Byte RAM frei. Die Befehlskette free; sync ; echo 3 > /proc/sys/vm/drop_caches ; free zeigt nochmal den freien Speicher via free dann wird das Datei system gesynct (alle Daten werden auf die Platte geschrieben) sync, nun wird der Cache geleert echo 3 > /proc/sys/vm/drop_caches und zum Schluss nochmals der Speicherverbrauch angezeigt free.
In diesem Fall haben wir nur ca. 300MB RAM gewonnen. Ich hatte aber auch keinerlei Probleme mit meinem System.
~# top
top - 09:52:42 up 1 day, 12:56, 4 users, load average: 3.96, 1.36, 0.88
Tasks: 220 total, 2 running, 217 sleeping, 0 stopped, 1 zombie
Cpu(s): 1.3%us, 6.7%sy, 0.0%ni, 92.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1932432k total, 1176248k used, 756184k free, 36236k buffers
Swap: 1951740k total, 615720k used, 1336020k free, 365616k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2088 root 20 0 242m 29m 6884 S 2 1.6 21:54.41 Xorg
3083 smueller 20 0 319m 10m 5544 S 1 0.6 1:04.31 gnome-terminal
3005 smueller 20 0 853m 183m 19m S 1 9.7 19:08.23 firefox-bin
2275 smueller 20 0 201m 8212 2308 S 0 0.4 5:43.45 awn-applet
14565 root 20 0 19396 1504 1060 R 0 0.1 0:00.06 top
1 root 20 0 23884 1284 612 S 0 0.1 0:00.96 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:09.74 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.01 migration/0
5 root RT 0 0 0 0 S 0 0.0 0:00.00 watchdog/0
9 root 20 0 0 0 0 S 0 0.0 0:04.13 events/0
11 root 20 0 0 0 0 S 0 0.0 0:00.00 cpuset
12 root 20 0 0 0 0 S 0 0.0 0:00.00 khelper
13 root 20 0 0 0 0 S 0 0.0 0:00.00 netns
14 root 20 0 0 0 0 S 0 0.0 0:00.00 async/mgr
15 root 20 0 0 0 0 S 0 0.0 0:00.00 pm
17 root 20 0 0 0 0 S 0 0.0 0:01.76 sync_supers
~# free; sync ; echo 3 > /proc/sys/vm/drop_caches ; free
total used free shared buffers cached
Mem: 1932432 1175728 756704 0 36324 365572
-/+ buffers/cache: 773832 1158600
Swap: 1951740 615720 1336020
total used free shared buffers cached
Mem: 1932432 899340 1033092 0 2464 124100
-/+ buffers/cache: 772776 1159656
Swap: 1951740 615704 1336036
Mein neues Jekyll Blog auf Github.com
vom: 03 September 2010.Sorry,
ich habe erst letzte Woche gemerkt das dass Blog offline ist.
Ich habe auch keine richtige Lust/ Zeit das in nächste Zeit wieder einzurichten. Ich hab mich desshalb entschlossen das Blog auf die Webseite von http://github.com umzuleiten. Deren Server sind viel sicherer und sicher auch um ein Vielfaches schneller.
Die Links zum Board werde ich gleich an der gewohnten Stelle einfügen.
Haut rein und bis bald.
Stefan
