Testing - neue statusmeldungen beim booten/herunterfahren?

[kupe]

abend,

folgendes upgrade hab' ich heut' früh eingespielt (auszug aus history.log):

Code: Alles auswählen

Start-Date: 2012-05-05  09:37:58
Commandline: apt-get dist-upgrade
Upgrade: lsof:amd64 (4.81.dfsg.1-1.1, 4.86+dfsg-1), diffutils:amd64 (3.2-2, 3.2-6), whois:amd64 (5.0.15, 5.0.16), lsb-base:amd64 (4.1+Debian0, 4.1+Debian2), libxvmc1:amd64 (1.0.6-1, 1.0.7-1), libxv1:amd64 (1.0.6-2, 1.0.7-1), lsb-release:amd64 (4.1+Debian0, 4.1+Debian2)

seitdem kommt beim booten resp. herunterfahren quasi vor jeder textzeile eine art statusmeldung:

zuerst ein [....], und dann wird das eben zu einem farbigen [info] oder [ok]. eig. ganz nett, drei fragen hätt' ich allerdings dazu:

• kann das jemand bestätigen (also daß dieses verhalten durch dieses heutige upgrade ausgelöst wurde)?
• welches paket ist dafür verantwortlich? etwa lsb-base oder lsb-release?
• die meisten zeilen liefern nach ihrer »vollendung« sowieso schon ein ...done nach, wodurch oftmals die statusmeldung doppelt vorhanden ist => eig. obsolet. kann man das irgendwie umgehen/unterbinden/etc. => entweder oder?

herzlichen dank.

[deberik]

Es ist lsb-base, siehe (auch für mehr Infos) http://lists.debian.org/debian-lsb/2012 ... 00002.html

PS: Mailinglisten sind echt hilfreich!

[habakug]

Hallo!

Das ist aus lsb-base:

lsb (4.1+Debian1) unstable; urgency=low

This version implements a new "Fancy output" in the form of "[....] "
[...]
The "Fancy output" can be disabled by setting the FANCYTTY variable to 0
in the /etc/lsb-base-logging.sh configuration file.

Gruß, habakug

# zless /usr/share/doc/lsb-base/NEWS.Debian.gz

edit:
Zulange News gelesen

[kupe]

danke für die antworten; ja, sobald man das schlagwort fancytty kennen gelernt hat, findet man einiges darüber.


bzgl. abschalten desselbigen:

It is also possible to completely disable the "Fancy output" by setting the FANCYTTY variable to 0 in the same file.

das heißt also, den sog. »Fancy output« kann ich rel. einfach deaktivieren, das standardmäßige ...done aber nicht?

bezieht sich dieser satz auf folg. passage?

Code: Alles auswählen

log_use_fancy_output () {
    TPUT=/usr/bin/tput
    EXPR=/usr/bin/expr
    if  [ -t 1 ] &&
	[ "x${TERM:-}" != "x" ] &&
	[ "x${TERM:-}" != "xdumb" ] &&
	[ -x $TPUT ] && [ -x $EXPR ] &&
	$TPUT hpa 60 >/dev/null 2>&1 &&
	$TPUT setaf 1 >/dev/null 2>&1
    then
        [ -z $FANCYTTY ] && FANCYTTY=1 || true
    else
        FANCYTTY=0
    fi
    case "$FANCYTTY" in
        1|Y|yes|true)   true;;
        *)              false;;
    esac
}

falls ja: soll dementspr. gleich die ganze if- oder die case-bedingung »plattgemacht« (da by default deaktiviert => eig. sinnlos?) werden?


edit: ich sehe gerade, daß ja /etc/lsb-base-logging.sh gemeint ist. selbiges scheint bei mir allerdings nicht vorhanden zu sein?

oder soll resp. kann etwa (der einfachheit halber?) das »auf 0 setzen« doch hier in der letzten zeile von init-functions erfolgen:

Code: Alles auswählen

FANCYTTY=
[ -e /etc/lsb-base-logging.sh ] && . /etc/lsb-base-logging.sh || true

sorry, aber bei solchen quick-'n'-dirty-geschichten frag' ich dann doch lieber noch mal nach.

[habakug]

Hallo!

Die Datei "/etc/lsb-base-logging.sh" mit diesem Inhalt erzeugen:

Code: Alles auswählen

#!/bin/sh
FANCYTTY=0

Dann noch ein

Code: Alles auswählen

# update-initramfs -u

und der Spuk ist verschwunden.

Gruß, habakug

[Cae]

Dann noch ein

Code: Alles auswählen

# update-initramfs -u

und der Spuk ist verschwunden.

Nö, geht auch ohne. Die ganzen Bootscripte liegen ja in /etc und haben in der initrd gar keinen Sinn, da die aufzurufenden Dienste im gemounteten System liegen.

Gruß Cae

[habakug]

Hallo!

Ja, es geht auch ohne update-initramfs. Es schadet aber auch nicht oder verursacht Schmerzen.
Aber so bist du wenigstens dein "Nö" losgeworden.

Gruß, habakug

[Cae]

Ja, es geht auch ohne update-initramfs. Es schadet aber auch nicht oder verursacht Schmerzen.
Aber so bist du wenigstens dein "Nö" losgeworden.

Stimmt… Übrigens war mein Post oben eigentlich als ergänzender Hinweis gedacht, jetzt liest sich das aber ziemlich ruppig. So war es aber nicht gemeint

Gruß Cae

[kupe]

'tschuldigung, daß ich erst jetzt antworte, ging leider nicht früher.

das mit /etc/lsb-base-logging.sh funktioniert, das direkte »herumpfuschen« in unter /lib/lsb/init-functions tats. ebenfalls, allerdings habe ich ein deutlich besseres gefühl bei der von habakug vorgeschl. methode => skript nach /etc, als munter in /lib herumzuwühlen.

auch ohne update-initramfs. noch mal zum verständnis: selbigen befehl brauche ich afaik eig. »nur«, wenn ich bspw. manuell ein init.d-skript mit lsb-header in den start- resp. stopvorgang (runlevel X: link => /etc/rcX.d) eingliedern will, oder irre ich mich da?


nachdem lsb-base-logging.sh aber ja nur unter /etc liegt, bedarf es - soweit ich das verstanden habe - also nicht diesen befehls.


bitte korrigieren falls falsch und noch mal danke für eure hilfe.

[Cae]

Das initramfs braucht nach meinem Verständnis nur dann neu gebaut werden, wenn sich etwas Grundlegendes ändert, Dateisystemtreiber, ATA-Chipsatz-Treiber, RAID, LVM, so etwas in der Richtung. Normale init.d-Skripte haben damit wenig zu tun, da sie nicht so essentiell wie ein Dateisystem sind.

Gruß Cae

[kupe]

das heißt also, für normale init.d-skripte reicht wirklich i.d.r. ein chmod 755 /pfad/zum/skript und ein anschließendes update-rc.d?

[Natureshadow]

So knallebunt wie das jetzt ist könnte man meinen, die lsb-base-Maintainer wollten back to the roots.

There are two major products to come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence do we?

Bald wird das Paket dann wohl auch in lsd-base umbenannt.

Besonders hübsch finde ich den hier von der Mailingliste:

* The above has the side-effect of hiding 7 characters of potentially
useful output.

Ich darf mal übersetzen? "Ich weiß, dass das grober Unfug ist, aber hauptsache FÄÄÄÄNZIIII!"

-nik

[kupe]

na ja, prinzipiell sind diese info-elemente sicherlich nicht verkehrt, aber bspw. die doppelung von [ ok ] mit anschl. ...done innerhalb einer statuszeile finde ich dann doch reichlich sonderbar resp. ist das schlichtweg obsolet => XOR statt OR/AND ergäbe imho wieder sinn.