Archiv ‘Linux’

Samstag, 27. August 2011

Debian unter VMware meldet „Waiting for root file system“

Link zu diesem Artikel

Gestern wurde der VMware-Server aktualisiert, unter welchem eine von mir betreute Debian GNU/Linux-Installation läuft. Wie ich erst jetzt realisiert habe, funktioniert der Server seit dem Update nicht mehr.

Nachdem ich mich per VPN über den Terminalserver und den VMware vSphere Client auf die Konsole der Kiste eingewählt und die Kiste neu gestartet hatte, lächelte mich folgende Fehlermeldung an:

Waiting for root file system

Nach einer Google-Suche und einiger Lektüre stiess ich auf einen erhellenden Artikel “Waiting for root file system” caused by out dated VMware Server, dessen Lösung für mich zwar nicht anwendbar war, mich aber immerhin darauf brachte, die in GRUB hinterlegten Referenzierungen auf die Partitionen zu überdenken.

Und siehe da: Zuerst betätigte ich beim GRUB-Screen zuerst einmal den Cursor, um den automatischen Start des Betriebssystems zu verhindern. Anschliessend bearbeitete ich den standardmässig aktivierten Eintrag mit Druck auf die Taste e. Hier wechselte ich folgende Angaben:

kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sdb2 ro

auf

kernen          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda2 ro

und einem anschliessenden Enter gefolgt von b liess die Kiste wieder booten.

Als nächstes musste ich die soeben gemachte Anpassung noch fix in /boot/grub/menu.lst vornehmen. Beim nächsten Neustart lief alles wieder wie gewohnt.

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 31. Juli 2011

TeX Live 2011 sucks

Link zu diesem Artikel

Da wollte ich also gestern schnell mal TeX Live 2011 auf dem Windows-Laptop meiner Freundin installieren, scheiterte schlussendlich aber kläglich …

Zuerst habe ich mir install-tl.zip für Windows heruntergeladen, entpackt und danach die Datei install-tl.bat gestartet. Die Installation lief durch, hing aber schlussendlich bei „Finished downloading“. Erst viel später merkte ich, dass im Hintergrund ein Kommandozeilenfenster geöffnet war und irgendwas von mir wollte.

Der zweite Installationsversuch klappte ebenfalls nicht, obwohl alle erneut Pakete heruntergeladen werden mussten (!). Die Einträge im Startmenu fehlten.

Als ich deshalb den Installer unter C:\texlive\2011\ erneut ausführen wollte (ein zweiter Durchlauf kann nie schaden), erschien folgende Fehlermeldung:

Cannot open 'C:/texlive/2011/tlpkg/installer/texlive.png' in mode 'r' at C:\texlive\2011\tlpkg\tlperl\lib/Tk/Image.pm line 21.

Nach etwas pröbeln kopierte ich kurzerhand den von der Web-Site heruntergeladenen install-Ordner unter ~/Downloads über den Ordner in C:/texlive/2011/tlpkg/installer/. Damit die Pakete dabei aber nicht erneut heruntergeladen werden mussten, startete ich den Installer von der Kommandozeile mit

install-tl.bat -in-place

Die Installation lief nun das erste Mal richtig durch, indem TeX Live auch klar sichtbar konfiguriert wurde. Der Ordner im Startmenu tauchte aber auch hier nicht auf.

Unter C:\texlive\2011\ fand ich eine Taskbar-Applikation, welche mir so Zugriff auf TeXWorks verschaffte. Die Kompilierung einer Beispieldatei schlug grandios fehl, die Fehlermeldung lautete:

kpathsea: Running mktextex latex.ini
 Running: pdftex --ini --jobname=latex --progname=latex
-translate-file=cp227.tcx
*latex.ini  *latex.ini

 (Press Enter to retry, or Control-Z to exit)
 Please type another input file name:
 ! Emergency stop.
 <*> *latex.ini

 No pages of output.
 Transcript written on latex.log.

Offenbar ist dieses Problem im Netz nicht sonderlich bekannt, eine Google-Suche lieferte nur bruchstückhafte Hinweise auf die Ursache (und Lösung) des Problems.

Indem ich

fmtutil --missing

ausführte, erhielt ich die Fehlermeldung präsentiert, dass mangels .ini-Dateien 37 Format-Dateien nicht hätten erstellt werden können. Eine Beispielsuche nach latex.ini zeigte mir, dass die Datei unter C:\texlive\2011\ vorhanden war — doch wieso fand sie fmtutil nicht?!

Über Mailinglistenkommentare führte ich folgenden Befehl aus, welcher aber ohne Output hängen blieb:

tlmgr generate --rebuild-sys language

Die Anpassung auf

tlmgr generate language

lief zwar durch, brachte aber keine Besserung.

Lösungsansätze

Die Ursache allen Übels scheint zu sein, dass folgender Befehl nichts zurückgibt:

kpsewhich latex.ini

Im Mailinglisten-Thread [tex-live] Error : „I can’t find the format file `latex.fmt‘! sind die Fehlermeldungen besprochen, obwohl die Ursache hier eine andere zu sein scheint.

Hellhörig macht mich nur:

Normally the TEX… variables are not set in the shell but by
loading texmf.cnf in the tex-related programs.
You should use kpathsea debugging to see what is really
going on.

Ein anderer Ansatz könnte folgende Unterlassung sein:

Administrator privileges on Vista and Windows 7: even when running as administrator, if you want to install for all users, right-click install-tl.bat and select ‘Run as administrator’. The same is needed when running tlmgr (TeX Live Package Manager).

Quelle: TeX Live Windows installation

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 23. Juli 2011

Mac OS X 10.7 Lion ohne Samba?!

Link zu diesem Artikel

As part of the Lion release, Apple switched their SMB server from the open-source Samba implementation to an internal implementation.

Quelle: Update to Mac users on OS X 10.7 (Lion) support on Sonos – Sonos Forums

Irgendwie ist das völlig an mir vorbeigezogen … aber anscheinend soll die GPLv3 Schuld daran sein. Stattdessen werkelt unter Lions Haube nun SMBX, ein von Apple intern entwickelte SMB1/2-Implementation.

Tags: , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 13. Juni 2011

cacti pingt nicht mehr

Link zu diesem Artikel

Heute habe ich mich endlich einem Problem angenommen, das mich mit meiner Cacti-Installation seit mehr als einem Jahr plagt: Die Ping-Werte für Google werden nicht mehr aufgezeichnet.

Nachdem ich unter

  1. Console
  2. System Utilities
  3. View Cacti Log File

nach „ping“ gesucht hatte und feststellen musste, dass das Script ~/cacti/scripts/ping.pl permanent „U“ als Wert zurücklieferte, begann das Debugging.

Auch die manuelle Ausführung von

~/cacti/scripts/ping.pl www.google.com

brachte ein „U“ als Resultat hervor. Was cheibs?

Im Grunde ruft das Perl-Script folgenden Kommandozeilenbefehl auf und filtert im Anschluss den Rückgabe wert:

ping -c 1 www.google.com | grep icmp_seq | grep time

Als ich dies auf der Kommandezeile ausführte, wurde ein leerer Wert zurückgegeben.

Nachdem ich ein Blick auf das Resultat von

$ ping -c 1 www.google.com
PING www.l.google.com (74.125.79.104) 56(84) bytes of data.
64 bytes from ey-in-f104.1e100.net (74.125.79.104): icmp_req=1 ttl=53 time=34.6 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 34.695/34.695/34.695/0.000 ms

geworfen hatte, war mir sofort klar, was das Problem war: grep nach icmp_seq kann nicht von Erfolg gekrönt sein, weil hier offenbar icmp_req steht.

Das Problem ist im ping.pl does not account for ping using icmp_req rather than icmp_seq in some versions of ping festgehalten: Offenbar gab es bei ping irgendwann einmal eine Anpassung am Code, die nur noch diese Ausgabe zur Folge hatte.

Nach einem Blick auf den Patch nahm ich die Anpassung an ~/cacti/scripts/ping.pl selber vor — irgendwie einfach ein wenig anders als vorgeschlagen:

...
open(PROCESS, "ping -c 1 $host | grep -E 'icmp_(r|s)eq' | grep time |");
...

Damit klappte es wieder.

Nachtrag

Unter einer Synology DiskStation klappt es auch trotz dieser Anpassung nicht. Der Ping-Befehl gibt folgendes aus:

ping -c 1 192.168.8.8
PING 192.168.8.8 (192.168.8.8): 56 data bytes
64 bytes from 192.168.8.8: seq=0 ttl=64 time=0.223 ms

Keine Spur von icmp_seq, stattdessen steht dort nur seq. Somit passt man das Script finalerweise folgendermassen an:

...
open(PROCESS, "ping -c 1 $host | grep -E '(r|s)eq' | grep time |");
...

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 9. Juni 2011

Unable to connect to CUPS server

Link zu diesem Artikel

Erscheinen im syslog folgende Fehlermeldungen …

May 18 17:00:21 smbd[25311]: [2011/05/18 17:00:21.386431,  0] printing/print_cups.c:108(cups_connect)
May 18 17:00:21 smbd[25311]:   Unable to connect to CUPS server localhost:631 - Connection refused

… sollte man in der /etc/samba/smb.conf folgenden Eintrag sicherstellen:

...
printcap name = /etc/printcap
...

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 8. Juni 2011

Zertifikatsprobleme mit imapfilter bei einem loadbalancierten Exchange 2010-Server

Link zu diesem Artikel

ACHTUNG: Funktioniert leider doch nicht wie erwünscht.

imapfilter ist das Tool meiner Wahl, um einkommende Mail-Nachrichten in IMAP-Unterordner zu verschieben. Dessen Anwendung habe ich in einem Blog-Artikel erläutert.

Seit mein Arbeitgeber mein E-Mail-Konto von einem Unix-Mailserver auf eine Microsoft Exchange 2010-Lösung migriert hat, gab es Probleme mit den Zertifikaten. (Natürlich hätte ich die Regeln erneut unter Exchange erfassen können, aber der Vorteil von imapfilter ist eben gerade, dass man nur die Serververbindung anpassen muss, und die Mails werden weiter schön sauber sortiert).

imapfilter lässt man bekanntlich beim ersten Verbindungsversuch im interaktiven Modus laufen und akzeptiert dort dann brav das Zertifikat das Mail-Servers:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: CD:10:34:E9:6D:1D:07:09:3D:9E:53:FC:B5:94:B0:10
(R)eject, accept (t)emporarily or accept (p)ermanently? p

Doch leider schien dieser Server in der Folge einfach so den Fingerprint zu wechseln. Als ich imapfilter nach einiger Zeit (und Fehlermeldungen im cron.log) erneut im interaktiven Modus ausführte, erschien folgende Warnung:

Server certificate subject: /1.3.6.1.4.1.311.60.2.1.3=CH/ 
1.3.6.1.4.1.311.60.2.1.2=Bern/businessCategory=Government Entity/ 
serialNumber=1834-03-14/C=CH/ST=Bern/L=Bern/O=Universitaet Bern/ 
OU=Informatikdienste - SYS/CN=mail.campus.unibe.ch
Server certificate issuer: /C=BM/O=QuoVadis
Limited/OU=http://www.quovadisglobal.com/CN=QuoVadis 
 Global SSL ICA
Server key fingerprint: 6D:D9:E8:FF:A3:70:2A:D8:44:10:0C:7D:0E:94:65:FC
ATTENTION: SSL/TLS certificate fingerprint mismatch.
Proceed with the connection (y/n)? y

Leider führte das Bestätigen der Warnung nicht dazu, dass dieses neue Zertifikat akzeptiert wurde (wohl, weil für denselben Server bereits ein anderes Zertifikat gespeichert war). Meine Vermutung: Da mein Arbeitgeber einen loadbalancierte Exchange 2010-Infrastruktur aufgebaut hat, besitzt jeder Server ein anderes Zertifikat (auch wenn beide gegen aussen als mail.campus.unibe.ch in Erscheinung treten).

Der Workaround sah folgendermassen aus:

$ copy ~/.imapfilter/certificates ~/.imapfilter/certificates.old
$ imapfilter -c myconfigfile
(... accept certificate permanently ...)
$ cat ~/.imapfilter/certificates.old >> ~/.imapfilter/certificates

Ab sofort motzte imapfilter nicht mehr über den gelegentlich wechselnden Fingerprint, weil nun einfach beide möglichen Zertifikate in der Datei gespeichert sind.

Tags: , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. Juni 2011

ffmpeg will AVI-Video nicht mehr nach MP4 konvertieren

Link zu diesem Artikel

Nachfolgender Befehl tat während vieler Monate genau das, was er tun sollte: Eine AVI-Videodatei (mit mencoder aus JPEG-Bildern zusammengesetzt; hier $1) in eine MP4-Datei (hier: $2) umzuwandeln, damit diese auch auf einem iPhone betrachtet werden kann.

Doch seit Neuestem nun dies:

$ ffmpeg -flags +loop -y -i "$1" -b 200000 -s 320x240 -vcodec libxvid -an -f mp4 "$2"
...
[libxvid @ 0x97f1ab0] Invalid pixel aspect ratio 1701/1504

Nach einem hilfreichen Hinweis in einem Online-Forum dann die Lösung: Abkehr von libxvid, neu setze ich voll auf MPEG4:

$ ffmpeg -flags +loop -y -i "$1" -b 200000 -s 320x240 -vcodec mpeg4 -an -f mp4 "$2"
...
Input #0, avi, from '$1':
  Metadata:
    encoder         : MEncoder 1.0rc4-4.4.5
  Duration: 00:00:04.60, start: 0.000000, bitrate: 1898 kb/s
    Stream #0.0: Video: mpeg4, yuv420p, 567x376 [PAR 1:1 DAR 567:376], 20 tbr, 20 tbn, 20 tbc
[buffer @ 0x968fef0] w:567 h:376 pixfmt:yuv420p
[scale @ 0x96dd580] w:567 h:376 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004
Output #0, mp4, to '$2':
  Metadata:
    encoder         : Lavf52.87.1
    Stream #0.0: Video: mpeg4, yuv420p, 320x240 [PAR 95:84 DAR 95:63], q=2-31, 200 kb/s, 20 tbn, 20 tbc
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
frame=   92 fps=  0 q=12.4 Lsize=     225kB time=4.60 bitrate= 400.5kbits/s    
video:223kB audio:0kB global headers:0kB muxing overhead 0.666259%

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 5. Juni 2011

mencoder meldete für verschiedene Libraries „no version information available“

Link zu diesem Artikel

Debian ist gut und recht, aber leider ist die ganze Geschichte mit Multimedia-Tools auf Grund von Problemen mit geistigem Eigentum unnötig kompliziert.

Das führt dann auch mal zu einer solchen Flut von Fehlermeldungen, wenn man den mencoder benutzen möchte:

$ mencoder
/usr/bin/mencoder: /usr/lib/i686/cmov/libswscale.so.0: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libpostproc.so.51: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavutil.so.50: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: relocation error: /usr/bin/mencoder: symbol av_reverse, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference

Das Problem konnte ich schlussendlich lösen, indem ich folgende Zeilen wieder in die /etc/apt/sources.list aufnahm:

...
# mplayer
deb		http://www.debian-multimedia.org squeeze main
deb-src		http://www.debian-multimedia.org squeeze main
...

Anschliessend ein apt-get update && apt-get upgrade. Irgendwann einmal waren dann nur noch zwei Fehlermeldungen zu sehen:

$ mencoder
/usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder)

Doch dieses Problem schien nun unmöglich zu lösen zu sein:

# apt-get install ffmpeg libavcodec52 libavdevice52 libavformat52 libavfilter1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ffmpeg : Depends: libavfilter1 (>= 5:0.6.1+svn20101128) but 4:0.6.2-3 is to be installed
 libavfilter1 : Depends: libavcodec52 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libavcodec-extra-52 (< 4:0.6.2-99) but it is not installable
                Depends: libavutil50 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libavutil-extra-50 (< 4:0.6.2-99) but it is not installable
                Depends: libswscale0 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libswscale-extra-0 (< 4:0.6.2-99) but it is not installable
E: Broken packages

Die Lösung:

/etc/apt/preferences:

...
Package: *
Pin: origin www.debian-multimedia.org
Pin-Priority: 600

und dann:

# apt-get install -t unstable ffmpeg

Tags: ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. Juni 2011

Eine portable Festplatte unter Linux mit FAT32 formatieren

Link zu diesem Artikel

Windows ist ja mittlerweile recht bockig, wenn es darum geht, übergrosse portable Festplatten mit FAT32 zu formatieren — stattdessen empfiehlt die Formatierungssoftware aus Redmond, man solle doch bitte das proprietäre NTFS verwenden. Der Haken dabei: Linux und Mac OS X bringen immer noch keine saubere Unterstützung dieses Dateisystems mit sich, wenn es um Schreiboperationen geht (im Klartext: auf eigenes Risiko!).

Unter Linux ist es ein Kinderspiel, auch neueste Festplatten mit riesigen Volumina mit FAT32 zu formatieren.

Nachdem man herausgefunden hat, unter welchem Devicenamen à la /dev/sdX die USB-Festplatte ansprechbar ist, erstellt man erstmals eine Partition:

# fdisk /dev/sdd
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-9729, default 1): <enter>
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-9729, default 9729): <enter>
Using default value 9729
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): w

Mit dieser Befehlsabfolge hat man nun eine primäre Partition mit dem Dateisystem FAT32 angelegt.

Die Festplatte muss nun aber auch noch formatiert werden, damit Daten darauf geschrieben werden können. Das ist noch viel einfacher als die Partitionierung:

# mkfs -t vfat /dev/sdd1

Tags: , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 4. Juni 2011

Debian meldet „error in version: version number does not start with digit“

Link zu diesem Artikel

Der täglich ausgeführte Cron-Job /etc/cron.daily/man-db meldete seit dem Upgrade auf die neueste Debian-Version folgende Probleme:

dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22552 package 'am-utils':
 'Replaces' field, reference to 'amd': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22555 package 'am-utils':
 'Conflicts' field, reference to 'amd': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 52773 package 'root-tail':
 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 65726 package 'wmnetselect':
 'Suggests' field, reference to 'mozilla': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 69143 package 'e3':
 error in Version string 'e3-2.30-1': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 75804 package 'tac-plus':
 error in Version string 'F4.0.4.alpha-9.1': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 125732 package 'epic4-script-thirdeye':
 'Depends' field, reference to 'epic4': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 149557 package 'cnews':
 error in Version string 'cr.g7-31': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 152423 package 'kernel-image-2.4.25':
 error in Version string 'mad.8': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 168065 package 'mkcdrec':
 error in Version string 'v0.8.0-2': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 189590 package 'request-tracker1':
 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 201432 package 'epic4':
 'Conflicts' field, reference to 'epic4-help': error in version: version number does not start with digit

Nachdem ich mir die Datei /var/lib/dpkg/available angeschaut hatte, kam ich zum Schluss, dass ich lieber die Finger von dieser Auflistung lasse (ich überlegte mir kurz, die Versionsangaben der betreffenden Pakete manuell anzupassen).

Die Überprüfung auf das Vorhandensein all dieser Pakete förderte nichts zu Tage:

$ dpkg --list | grep am-utils
$ dpkg --list | grep root-tail
$ dpkg --list | grep wmnet
$

Komisch! Stattdessen fand ich nach ein wenig Googlen das Patentrezept gegen solche Probleme:

# dpkg --clear-avail
# apt-get update

Tags:
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

« Older Entries
Newer Entries »