Schlagwort: Linux

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 14 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Seit ein paar Tagen habe ich in mei­nem /var/log/syslog ein paar häss­li­che Mel­dun­gen, die das gan­ze sys­log ‚voll­mül­len‘.

Hier mal ein Beispiel:

Apr 24 08:55:10 axolotl kernel: [36283.935663] Valid eCryptfs headers not found in file header region or xattr region, inode 1717173
Apr 24 08:55:10 axolotl kernel: [36283.935674] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

Auf der Suche nach Ursa­che & Lösung bin ich über

Das Pro­blem der Mel­dun­gen (sie­he Rapha­els Erklä­run­gen) ist wohl, dass es in mei­nem (mit eCryptfs ver­schlüs­sel­tem) home Datei­en gibt, die eine Grö­ße von 0 Bytes haben. Wie die da hin gekom­men sind kann ich nicht mehr reka­pi­tu­lie­ren, da ich mir auch nicht mehr ganz sicher bin, seit wann die Mel­dun­gen im sys­log ste­hen (und ich eben­falls wenig Lust habe, die alten sys­log-Datei­en zu durchsuchen…).

Am Ende habe ich nun Fol­gen­des dur­ge­führt, um das eCryptfs wie­der kon­sis­ten zu machen & somit auch die Mel­dun­gen los zu werden.

  1. sudo find /home/.ecryptfs/$username/.Private/ -xdev -size 0c ($username = mein Login-Name)
  2. Der ers­te Befehl sucht alle Datei­en mit der 0‑By­te-Grö­ße und gibt die­se aus. – Bei mir waren es zehn die­ser Dateien.
  3. Danach habe ich alle aus­ge­ge­be­nen Datei­en per Hand noch­mal kon­trol­liert – ls -lha $datei.
  4. Abschlie­ßend (nach­dem ich fest­ge­stellt hat­te, dass alle Datei­en wirk­lich mir gehö­ren & wirk­lich 0 Bytes groß waren) habe ich dann alle zehn Datei­en ein­zeln gelöscht: sudo rm "$datei".

Das Gan­ze habe ich immer mit root-Rech­ten (sudo) gemacht, da es ohne die­se stän­dig zu Feh­ler­mel­dun­gen bzgl. der Rech­te kam – was aber auch an der Benut­zung von trash-cli lie­gen kann!

Zusam­men­fas­send kann ich sagen, dass

  • seit dem die Mel­dun­gen im sys­log nicht mehr vor­han­den sind *cla­ro!*;
  • ich seit dem kei­ne Pro­ble­me fest­stel­len konnte,
  • der Bug offen­sicht­lich (für bestimm­te Anwen­dun­gen) bereits gefi­xed ist (nichts des­to trotz kann ein Sys­tem­crash nat. dazu füh­ren, dass die­se Datei­en wie­der exis­tie­ren und dann mosert eCryptfs ja zurecht…) und
  • ich der Mei­nung bin, dass man die Datei­en rela­tiv gefahr­los löschen kann – 0 Byte gro­ße Datei­en haben kei­nen (pri­va­ten) Inhalt und soll­te es sich um Spe­zi­al­da­tei­en von bestimmtn Anwen­dun­gen han­deln, wer­den die beim Neu­start der Anwen­dung wahrsch. wie­der neu erstellt.

In die­sem Sin­ne & ohne die Über­nah­me irgend wel­cher Geweh­re,
der sokai

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 15 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Schon seit einer Wei­le habe ich unter Ubun­tu auf mei­nem EeePC das “proposed”-Repository instal­liert. Doch gera­de nach mei­nem Upgrade zu Onei­ric habe ich eini­ge merk­wür­di­ge Erschei­nungen, als deren Ursa­che ich eben die­ses Repo in Ver­dacht habe. (Außer­dem ist das “proposed”-Repo für ein Pro­duk­tiv­sys­tem – auf dem also im All­tag alles funk­tio­nie­ren soll – wohl eh nicht gut…)

Nun woll­te ich ein­fach das “proposed”-Repo deak­ti­vie­ren und mein Sys­tem sozu­sa­gen (wie­der auf den Stan­dard) “deak­tua­li­sie­ren”. Aber irgend­wie funk­tio­niert das nicht so einfach…

Nach eini­gem Suchen habe ich dann einen funk­tio­nie­ren­den Weg bei “Ask Ubun­tu” gefun­den, den ich hier mal (auch für mich zum Mer­ken) ver­lin­ke: “How can I revert back from an upgrade to the Pro­po­sed repo­si­to­ry?”.

Noch ein klei­ner Hin­weis zu obi­gem Vor­ge­hen: Bevor ihr die bei­den Skrip­te durch­lau­fen lasst, deak­ti­viert das “proposed”-Repo nicht. Erst nach­dem ihr euer Sys­tem deak­tua­li­siert habt, könnt ihr bspw. über die Soft­ware-Paket­quel­len-Ver­wal­tung auf dem Rei­ter “Aktua­li­sie­run­gen” den Haken beim Repo weg machen.

Viel Glück! 🙂

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 16 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Wer (unter GNOME & Ubun­tu Maverick) auch das Pro­blem hat, dass beim Instant Mes­sen­ger Pidgin (2.7.11) die Klän­ge – wenn sich Bud­dies an- oder abmel­den etc. – so komisch knarzen/knacken, dem sei der Tipp emp­foh­len, die (Ausgabe-)Methode der Klän­ge von “Auto­ma­tisch” (die Default Ein­stel­lung) auf Pul­seAu­dio umzustellen.

Und so gehts:

  1. Pidgin → Werk­zeu­ge → Ein­stel­lun­gen (oder [Strg + P])
  2. Rei­ter “Klän­ge” auswählen
  3. bei der Opti­on “Metho­de” steht wahr­schein­lich “Auto­ma­tisch” – hier ist jetzt “Kom­man­do” auszuwählen
  4. und nun (ganz oben) Fol­gen­des bei “Klang-Abspiel­be­fehl (%s für den Datei­na­men)” hin­ein schrei­ben: paplay %s
  5. auf “Schlie­ßen” kli­cken *fer­tig*

Dank für die Lösung – die­ser schon eine Wei­le recht ner­vi­gen Pro­ble­ma­tik – geht an bur­li und sei­nen Post im ubuntuusers.de-Forum!

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 16 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

The fol­lo­wig post is not writ­ten by mys­elf. It’s a copy! – Today I found the artic­le in the Goog­le Cache and thought the­re are more peo­p­le (than me) inte­res­ted in the archi­ved text that was ori­gi­nal­ly published at a blog named M‑x Kel­sin.

Let’s start …

After rea­ding ano­ther cool blog post about put­ting your cur­rent git branch in your bash prompt I deci­ded I nee­ded to try this out. Once I got it working I added in color coding to see the sta­tus of the cur­rent check­out as well!

First off, you need bash-com­ple­ti­on and git instal­led on your ser­ver (bash-com­ple­ti­on and git-core on Debian/Ubuntu). Once instal­led you can enable bash com­ple­ti­on in the sys­tem wide bash file (/etc/bash.bashrc) or in your own ~/.bashrc by adding the­se lines (Cle­ar­ly if you are not on Debian/Ubuntu dou­ble check file paths):

# Completion
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

Once this is all set you should have a func­tion cal­led git_ps1 available. Try it out by just run­ning git_ps1 on your com­mand line from a git repo. You should get the branch name retur­ned insi­de parenthesis’s.

Now comes my varia­ti­ons on how to include this in your prompt. My enti­re ~/.bash_prompt file can be found on my git repo. I source this file into my ~/.bashrc. The two most inte­res­t­ing parts are the func­tion that deter­mi­nes the color of the branch based on git-sta­tus out­put and the func­tion that gets the branch name. Branch name is pret­ty simp­le. We check that the __git_ps1 func­tion is available and if it is, check that we’­re in a branch using it. If we are we echo the branch name. Pret­ty clean.

prompt_git_branch() {
    if type -p __git_ps1; then
        branch=$(__git_ps1 '%s')
        if [ -n "$branch" ]; then
            echo -e "$branch"
        fi
    fi
}

The next func­tion has to grep stuff out of git sta­tus to deter­mi­ne what sta­te the repo is in. If we are com­ple­te­ly up to date we use green. If I have local chan­ges it’s blue. If we have files in our index rea­dy to be com­mit­ted I use red. This is real­ly gre­at with my home direc­to­ry cau­se it helps remind me to add new dot­files that I don’t care about to .gitigno­re (or com­mit them if they should be public con­fig files).

prompt_git_branch_color() {
    if type -p __git_ps1; then
        branch=$(__git_ps1 '%s')
        if [ -n "$branch" ]; then
            status=$(git status 2> /dev/null)

            if $(echo $status | grep 'added to commit' &> /dev/null); then
                # If we have modified files but no index (blue)
                echo -e "\033[1;34m"
            else
                if $(echo $status | grep 'to be committed' &> /dev/null); then
                    # If we have files in index (red)
                    echo -e "\033[1;31m"
                else
                    # If we are completely clean (green)
                    echo -e "\033[1;32m"
                fi
            fi
        fi
    fi
}

It took some play­ing but I final­ly found the right final line to cor­rect­ly tell bash which cha­rac­ters in the prompt are visi­ble. If anyo­ne has a good way of making the­se func­tions smal­ler or fas­ter I’d love to hear it. I had some trou­ble making sure that the func­tions were always exe­cu­ted (not just on a new shell’s crea­ti­on, but on every dis­play of PS1). The speed is FINE on all of my com­pu­ters but more speed never hurts.

Veröffentlicht am
von
Old but not bus­ted … – Die­ser Inhalt wur­de vor mehr als 16 Jah­ren publi­ziert. Die Kor­rekt­heit und Ver­füg­bar­keit von Links kön­nen lei­der nicht gewähr­leis­tet werden.

Schon seit einer Wei­le lau­fen auf radioeins sehr amü­san­te Trai­ler für das “Hör­spiel­ki­no unterm Ster­nen­him­mel” – einer groß­ar­ti­gen und sehr zu emp­feh­len­den Ver­an­stal­tung der ande­ren Art -, die auch online anhör­bar sind.

Nun fand ich letz­tens den Hör­spiel­ki­no-Trai­ler “Bud Spen­cer und Terence Hill” so nett, dass ich ihn mir ger­ne – für das pri­va­te Archiv – her­un­ter­la­den woll­te. Doof dar­an war, dass die MP3 in dem Flash-Play­er “JW Play­er” ein­ge­packt ist und somit nicht ein­fach über einen Rechts­klick her­un­ter­lad­bar ist.

Auf der Suche nach einer Lösung bin ich dann über RTMP­Dump gestol­pert und konn­te die MP3 nach der Instal­la­ti­on unter Ubun­tu mittels

$ sudo aptitude install rtmpdump

mit dem Aufruf

$ rtmpdump -r rtmp://stream5.rbb-online.de/rad -o radio1-trailer.mp3 -y mp3:_programm/8/201103_hsk_bud

in den aktu­el­len Ord­ner streamen/herunterladen. 🙂 (Die URL für den -r Para­me­ter fin­det man im Quell­text der Sei­te, auf der der JW Play­er ein­ge­bun­den ist…)

Etwas spä­ter bin ich dann – wohl durch Zufall – auch noch über den Direkt­link zu der MP3-Datei gestol­pert: http://download.radioeins.de/mp3/_programm/8/201103_hsk_bud.mp3 *naja*
MP3-Datei direkt hier anhören

…das mal so kurz am Rande… 😉