Viele Meldungen auf dem Schirm beim Start von yavdr

Wenn ich mich nicht irre ist das nen diskcheck der die Festplatte auf Fehler überprüft.

Einfach mal ein paar Minuten laufen lassen, bis der VDR wieder anspringt, würd auch sagen es ist der Plattencheck.

Hau mal smartmon drauf und lass den mal durchlaufen...das weißt du evtl. mehr.

Hallo, zusammen!

Ich gehe davon aus, dass es sich um das gleiche Thema wie unter

http://www.vdr-portal.de/board…-aufnahmen-nach-dem-start

handelt. Ich habe das Phänomen auch seit einiger Zeit und kann es - derzeit - nur dadurch beseitigen, dass ich von einer Live-Distro aus manuell einen fsck meiner Systemplatte durchführe. Allerdings "hält" das dann nur solange, bis die Anzahl der maximalen Disk-Mounts wieder erreicht ist.

Bin nicht so tief drin in der Materie ... /etc/init.d/force-fsck ?

Gruß,
Holger.

Zum Link: Entweder das doppelte http://www.vdr-portal.de manuell löschen oder den hier verwenden:
[gelöst] fsck beim Einschalten / keine Aufnahmen nach dem Start

Gruß,
Werner

Hi, dippes!

Quote

Holger der link funktioniert leider nicht.

Sorry für den falschen Link. Hab es korrigiert.

Ich habe in

fsck beim shutdown

auf Werner's Hinweis hin auch bei mir die /etc/init/shutdownfsck.conf nicht gefunden.
Damit soll beim Herunterfahren des Systems/Reboot geprüft werden, ob ein Filesystem-Check notwendig ist.

Wenn sie bei Dir fehlt, kannst Du du die Datei aus den yaVDR Standard Templates mittels

sudo process-template /etc/init/shutdownfsck.conf

erstellen.

Ggf. ist das Fehlen dieser Datei der Grund für unsere Probleme ... mal abwarten.

Gruß,
Holger.

So,

nachdem ich mich gestern mit dem Thema shutdownfsck.conf befaßt habe, startet heute doch glatt mein VDR wieder mit vielen init Meldungen auf meinem TV

Auszug von strings boot.log

fsck from util-linux-ng 2.17.2
udevd[401]: BUS= will be removed in a future udev version, please use SUBSYSTEM= to match the event device, or SUBSYSTEMS= to match a parent device, in /etc/udev/rules.d/92-imon.rules:1
udevd[401]: SYSFS{}= will be removed in a future udev version, please use ATTR{}= to match the event device, or ATTRS{}= to match a parent device, in /etc/udev/rules.d/92-imon.rules:1
init: logo-start main process (958) terminated with status 2
init: logo-start post-stop process (971) terminated with status 2
lircd-0.8.6[961]: lircd(default) ready, using /var/run/lirc/lircd
init: vdr main process (1012) terminated with status 1
init: logo-stop main process (1051) terminated with status 2
init: logo-start main process (1149) terminated with status 2
init: logo-start post-stop process (1173) terminated with status 2
init: vdr main process (1151) terminated with status 1
init: logo-stop main process (1195) terminated with status 2
init: logo-start main process (1221) terminated with status 2
[...]

Hier meine einzelnen, gesammelten Indizien/Stati:

1. In meinem Root Verzeichnis liegt seit gestern die /forcefsck Datei; ich hatte mit tune2fs den mount-count auf den max-mount-count meiner Systempartition gesetzt. Diese Datei ist sicherlich vom Runlevel Skript /etc/[...]/S61force-fschk (Softlink auf /etc/init.d/force-fsck) angelegt worden, als die Notwendigkeit eines fsck ermittelt wurde.

Der mount-count meiner Systempartition ist nun ständig 1, auch nach Reboots und Neustarts.

2. Ist /forcefsck existent, wird die "Schwarzschaltung" in /etc/init/black.conf nicht durchgeführt (exit 0), daher kann ich die vielen init Meldungen auch auf meinem TV sehen. Soweit ist das okay.

3. Manchmal kommt es in diesem Zustand dazu, dass die Aufzeichnungen leer bleiben, wenn der VDR gestartet ist. Dann muß ich diese im VDR manuell wieder aktualisieren oder den VDR Prozess neu starten (Das ist m.W. hier auch schon von einem Nutzer gemeldet worden).

4. Die /forcefsck Datei wird aktuell nicht gelöscht, obwohl in /etc/init/mountall.conf im post-stop script Teil ein rm -rf dafür zu finden ist (?).

5. Ich habe die /forcefsck manuell gelöscht und das System neu gestartet (Reboot):
Die Meldungen auf dem TV bleiben aus und der mount-count meiner Systemplatte wird von 1 auf 2 erhöht.

6. Gegenprüfung
Mit tune2fs den mount-count=max-mount-count meiner Systempartition gesetzt:
- Die Datei /forcefsck ist wieder da.
- Der mount-count ist 1.
- Die Meldungen kommen wieder auf dem TV.
Nach einem Reboot bleibt alles so wie es ist.

Ist sicherlich ab hier hilfreich, wenn jemand aus dem yaVDR Team mal da reinschauen könnte wieso die /forcefsck nicht gelöscht wird/werden kann. Hinweise zum Debuggen nehme ich gerne entgegen, da die Situation bei mir reproduzierbar ist.

Gruß,
Holger.

Tach,

ich kann mich den Ausführungen von Holger nur anschließen: die /forcefsck ist wieder da und alle mountcounts sind auch wieder auf 1.

Ich habe noch 2 Vermutungen, die Fachkundige vielleicht bewerten mögen:
1) Kann man überhaupt zu dem Zeitpunkt /etc/init/mountall.conf auf der Platte löschen oder ist sie gar nicht mehr eingebunden? In /var/log/user.log und im syslog steht da z.B.

Jun 19 18:21:15 vdrhd vdr: [1890] exiting, exit code 0
Jun 19 18:21:16 vdrhd logger: fsck - /etc/init.d/force-fsck laeuft (von mir selbst ergänzt)

In beiden Dateien das jeweils die letzten Einträge bis zum nächsten Einschalten.

2) Vielleicht hat das Nicht-Löschen auch was mit den unterschiedlichen reboot-Methoden zu tun. Ich muss wegen meines Gigabyte-Hauptbretts zum aus schalten immer den poweroff-kernel rebooten. Vielleicht laufen da irgendwelche Skripten anders als gedacht?

Werner

Hallo, Werner.

/etc/init/mountall.conf ist m.W. Bestandteil der Ubuntu-Distribution.

Die letzten Upgrades des mountall Paketes liefen bei mir im September 2010 ein. Ich habe das Problem aber erst seit diesem Jahr. Leider kann ich das nicht mehr genau terminieren. Damit scheidet vielleicht mountall.conf aus, bin mir aber nicht wirklich sicher.

Bin nun temporär hin und habe die beiden init-Skripte für den forcierten fsck deaktiviert. Jetzt hoffe ich, dass das shutdownfsck.conf den Check übernimmt.

Gruß,
Holger.

Hast Du denn mal Deine /etc/fstab so angepasst, wie ich Dir das drüben im anderen Thread erzählt habe?

Ich hatte mal einen anderen Ubuntu-Rechner (ohne VDR) betreut, der ein ähnliches Verhalen gezeigt hatte und dann war Ruhe!

Nachtrag: http://wiki.ubuntuusers.de/Dat…eck#berpruefung-abstellen

Natürlich könnten wir den fsck total abschalten, aber wie auch in dem von dir verlinkten Text zu lesen ist, sollte man das nur unter extremen Umständen tun. Und die liegen zumindest für mich noch nicht vor.

Gruß,
Werner

Bei ext4 ist diese regelmäßige Überprüfung dank Journal überflüssig. Bei OpenSuSE wird die Überprüfung standardmäßig deaktiviert beim Formatieren...

Tach zusammen.

Ich habe die /forcefsck mal angelegt und dann nach einem Reboot (mit vielen Meldungen) ein sudo init S durchgeführt. Danach war die /forcefsck gelöscht.

P.S.: Ein kill auf den laufenden Prozess mountall funktioniert übrigens auch...

Gruß,
Holger.

Hallo,

habe auf einem anderen Ubuntu 10.04 mal einen Gegentest mit /forcefsck durchgeführt:
1. Die Datei ist nach einem Neustart inkl. fsck gelöscht.
2. Der mountall Prozess läuft dort nach dem Neustart nicht mehr.

Also:
Warum läuft unter yaVDR mountall als Prozess weiter und beendet sich nicht, weshalb /forcefsck nicht gelöscht wird?

Gruß,
Holger.

Verdammt, er hängt wieder.... Es wird wohl "erst einmal" keinen anderen Weg geben, als den Dateisystemchek zu deaktivieren.....

Gruß

Obelix

Hallo Obelix,

benenne doch fsck... einfach um, und der alte Name wird ein (Hard-)Link auf 'true'

Ich habe es mir jetzt nicht ganz durchgelesen, dann eventl. noch ein initrd-update.

Hardy

Hallo Hardy. Ich kann dir nicht ganz folgen. Was meinst du mit "und der alte Name wird ein (Hard-)Link auf 'true'"?

Gruß

Obelix