Re: [FreeBSD] shutdown und textmode

[Detlef Sax]

On Fri, 10 Feb 2023 15:03:55 +0100, Volker Englisch wrote:
> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
> regelmäßig die Einträge im /var/log/messages:
>
> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted

Ist ufs2?! Die sind nicht "clean". Liest jedenfalls für mich so.

> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
> shutdown schief - wo sollte man anfangen zu suchen?

Anfangen zu beheben *könnte* klappen mit einem
fsck_y_enable="YES" in /etc/rc.conf
Im besten Fall kommt ein "marked clean" zurück.
Einen Versuch ist es wert.

> 2) Die Textausgabe auf der Konsole ist sehr schlecht lesbar. Ich hätte
> gerne, dass FreeBSD nicht auf VGA umschaltet, sondern im einfachen
> Textmodus fortfährt.

Ja, das ist Winzschift.

Deswegen habe ich in /usr/local/etc/rc.d/ ein Script das im
Wesentlichen ein simples
vidcontrol -f terminus-b32
enthält. Dummerweise glaube ich das es erst nach dem mounten der
lokalen Datenträger, also nach diesem Ereignis geschaltet wird.

Allerdings kannst Du versuchen mit drücken der "Rollen"-Taste vor dem
Login auf der Konsole mit dem Pfeil nach oben nach oben zu rollen.
Beenden des Rollens dann mit Taste. Habe ich jetzt nicht im Kopf nur
in den Fingern (Q?).


> Ein Versuch mit screen_textmode="1" in /boot/loader.conf bringt überhaupt
> nichts. Ein Versuch mit vbe_max_resolution="1" führt nur dazu, dass das
> Boot-Menü bereits grafisch ist. Wie zwinge ich FreeBSD dazu, im reinen
> Textmode zu bleiben?
>
> TIA!

Tja. Hoffe ich konnte zumindest eine Anregung bieten.

Detlef
--
https://www.12schrittefrei.de/
https://www.noart.de/

[Volker Englisch]

Ingrid ('Volker Englisch') schrieb am 10.02.2023:
> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
> regelmäßig die Einträge im /var/log/messages:
>
> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted
>

> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
> shutdown schief - wo sollte man anfangen zu suchen?
>

> 2) Die Textausgabe auf der Konsole ist sehr schlecht lesbar. Ich hätte
> gerne, dass FreeBSD nicht auf VGA umschaltet, sondern im einfachen
> Textmodus fortfährt.
>

> Ein Versuch mit screen_textmode="1" in /boot/loader.conf bringt überhaupt
> nichts. Ein Versuch mit vbe_max_resolution="1" führt nur dazu, dass das
> Boot-Menü bereits grafisch ist. Wie zwinge ich FreeBSD dazu, im reinen
> Textmode zu bleiben?

RTFM :-) Das Problem mit dem Textmodus hat sich erledigt. hw.vga.textmode
in /boot/loader.conf hat geholfen...

Bleibt "nur" noch die nicht umounteten Dateisysteme beim Shutdown...

[Matthias Andree]

Am 10.02.23 um 15:03 schrieb Volker Englisch:

> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
> regelmäßig die Einträge im /var/log/messages:
>
> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted
>
> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
> shutdown schief - wo sollte man anfangen zu suchen?

Laufen da force unmounts? Timeouts? Oder unzureichende Wartezeit, sodass
die Superblöcke nicht weggeschrieben werden, wenn der Reset des
Hostcontrollers dann das eigentliche Schreiben der Speichermedien abbricht?

Ich würd mir den shutdown-Prozess auf der Konsole genau angucken. Ggf.
Video vom Monitor drehen und dann in Zeitlupenwiedergabe nachlesen, aber
normalerweise dauert das buffer flushing lang genug.

Oder crasht ein Modul, das entladen wird?

[Volker Englisch]

Detlef Sax schrieb am 10.02.2023:
> On Fri, 10 Feb 2023 15:03:55 +0100, Volker Englisch wrote:
>> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
>> regelmäßig die Einträge im /var/log/messages:
>>
>> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
>> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted
>
> Ist ufs2?! Die sind nicht "clean". Liest jedenfalls für mich so.
>
>> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
>> shutdown schief - wo sollte man anfangen zu suchen?
>
> Anfangen zu beheben *könnte* klappen mit einem
> fsck_y_enable="YES" in /etc/rc.conf
> Im besten Fall kommt ein "marked clean" zurück.
> Einen Versuch ist es wert.

Das ist da eh schon drin. Wenn denn ur ein "marked clean" zurückkäme...

AUTOFS ist im Kernel nicht aktiviert. Unter /etc/rc.d findet sich ein file
namens automount, in dem kommt nur ein umount -At autofs vor. Sollte aber
mangels AUTOFS nicht zum tragen kommen.

In /etc/rc.shutdown existiert *kein* umount. Ich habe da jetzt mal am Ende
ein umount -a reingepackt. Beim nächsten Neustart mal sehen...

>> 2) Die Textausgabe auf der Konsole ist sehr schlecht lesbar. Ich hätte
>> gerne, dass FreeBSD nicht auf VGA umschaltet, sondern im einfachen
>> Textmodus fortfährt.
>
> Ja, das ist Winzschift.

:-)

Ich habe es jetzt durch hw.vga.textmode="1" in /etc/loader.conf gelöst.

> Tja. Hoffe ich konnte zumindest eine Anregung bieten.

Jep. Herzlichen Dank!

[Volker Englisch]

Matthias Andree schrieb am 10.02.2023:
> Am 10.02.23 um 15:03 schrieb Volker Englisch:
>> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
>> regelmäßig die Einträge im /var/log/messages:
>>
>> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
>> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
>> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted
>>
>> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
>> shutdown schief - wo sollte man anfangen zu suchen?
>
> Laufen da force unmounts? Timeouts? Oder unzureichende Wartezeit, sodass
> die Superblöcke nicht weggeschrieben werden, wenn der Reset des
> Hostcontrollers dann das eigentliche Schreiben der Speichermedien abbricht?

Nicht, dass ich wüßte.

> Ich würd mir den shutdown-Prozess auf der Konsole genau angucken. Ggf.
> Video vom Monitor drehen und dann in Zeitlupenwiedergabe nachlesen, aber
> normalerweise dauert das buffer flushing lang genug.

Die Idee mit dem Video ist gar nicht so dumm :-) Danke!

> Oder crasht ein Modul, das entladen wird?

Sagen wir mal so: Im Syslog findet sich rein gar nichts, was auf ein
Problem beim Herunterfahren hindeutet.

[Detlef Sax]

On Sat, 11 Feb 2023 18:21:18 +0100, Volker Englisch wrote:
> Detlef Sax schrieb am 10.02.2023:
>> On Fri, 10 Feb 2023 15:03:55 +0100, Volker Englisch wrote:
>>> 1) Bei einem FreeBSD 13.1 bekomme ich nach einem "shutdown -r now"
>>> regelmäßig die Einträge im /var/log/messages:
>>>
>>> Feb 10 14:53:44 selene kernel: mountroot: waiting for device /dev/ada0a...
>>> Feb 10 14:53:44 selene kernel: WARNING: /export was not properly dismounted
>>> Feb 10 14:53:44 selene kernel: WARNING: /home was not properly dismounted
>>> Feb 10 14:53:44 selene kernel: WARNING: /tmp was not properly dismounted
>>> Feb 10 14:53:44 selene kernel: WARNING: /usr was not properly dismounted
>>> Feb 10 14:53:44 selene kernel: WARNING: /var was not properly dismounted
>>
>> Ist ufs2?! Die sind nicht "clean". Liest jedenfalls für mich so.
>>
>>> Das sind alle gemounteten Filesysteme, ausser root (/). Was läuft da beim
>>> shutdown schief - wo sollte man anfangen zu suchen?
>>
>> Anfangen zu beheben *könnte* klappen mit einem
>> fsck_y_enable="YES" in /etc/rc.conf
>> Im besten Fall kommt ein "marked clean" zurück.
>> Einen Versuch ist es wert.
>
> Das ist da eh schon drin. Wenn denn ur ein "marked clean" zurückkäme...
>
> AUTOFS ist im Kernel nicht aktiviert. Unter /etc/rc.d findet sich ein file
> namens automount, in dem kommt nur ein umount -At autofs vor. Sollte aber
> mangels AUTOFS nicht zum tragen kommen.

Diese Scripte, sofern es sich nicht um Notwendige handelt, sind sowieso optional.
grep -i AUTOFS /etc/defaults/rc.conf
autofs_enable="NO"

> In /etc/rc.shutdown existiert *kein* umount. Ich habe da jetzt mal am Ende
> ein umount -a reingepackt. Beim nächsten Neustart mal sehen...

Irgendwo wird aber nach shutdown umounted. Es sei denn ein Prozess der
auf diese Filesysteme zugreift will nicht sterben.

"0 0 0 0 0 0 0 0 0 0 ...giving up"
Und schon ist das Filesystem "dirty".
Ich weiss allerdings nicht mehr ob dieser Prozess bei den letzten
Atemzügen noch mal genannt wird.

Mit fsck_y_enable gab es dann beim starten so gut wie nie Probleme.
Habe mittlerweile seit 1 Jahr zfs.

Wer will nicht sterben oder verschwinden? Das ist die Frage.

>
>>> 2) Die Textausgabe auf der Konsole ist sehr schlecht lesbar. Ich hätte
>>> gerne, dass FreeBSD nicht auf VGA umschaltet, sondern im einfachen
>>> Textmodus fortfährt.
>>
>> Ja, das ist Winzschift.
>
>:-)
>
> Ich habe es jetzt durch hw.vga.textmode="1" in /etc/loader.conf gelöst.

Und ich habe erfolgreich vbe_max_resolution=1 nach deiner Anregung
eingebaut und so wollte ich das schon lange haben, war mir aber nicht
wichtig genug zum suchen :-) So als eye-candy.

>> Tja. Hoffe ich konnte zumindest eine Anregung bieten.
>
> Jep. Herzlichen Dank!
>

dito

[Matthias Andree]

Am 11.02.23 um 18:23 schrieb Volker Englisch:

> Sagen wir mal so: Im Syslog findet sich rein gar nichts, was auf ein
> Problem beim Herunterfahren hindeutet.

wenn Dein / bzw. /var schon read-only ist, kannst da auch nix mehr
reinschreiben lassen.

[Volker N. Englisch]

Detlef Sax <s...@noart.de> schrieb:

Steht bei mir auch so drin.

>> In /etc/rc.shutdown existiert *kein* umount. Ich habe da jetzt mal am Ende
>> ein umount -a reingepackt. Beim nächsten Neustart mal sehen...
>
> Irgendwo wird aber nach shutdown umounted. Es sei denn ein Prozess der
> auf diese Filesysteme zugreift will nicht sterben.
>
> "0 0 0 0 0 0 0 0 0 0 ...giving up"
> Und schon ist das Filesystem "dirty".

Das kommt bei mir definitiv nicht - kein "dirty".

> Mit fsck_y_enable gab es dann beim starten so gut wie nie Probleme.
> Habe mittlerweile seit 1 Jahr zfs.

Ich werde es mal probieren, aber ich denke doch, es ist ein Problem beim
herunterfahren.

Wo müsste denn das finale "umount" normalerweise stehen? Beim
Herunterfahren muß ja irgendwo ein "umount -A" oder ein "umount -a"
kommen.

Nur - in welchem Script?

Volker

[Detlef Sax]

Das hat mich jetzt auch interessiert und die Antwort ist wohl das
normalerweise garnicht umounted wird, alle Prozesse werden beendet und
dann neu gebootet:

init (8)
3. Absatz bevor die Runlevel erklärt werden:

"After all user processes have been terminated, init will try to run
the /etc/rc.final script. This script can be used to finally prepare
and unmount filesystems that may have been needed during shutdown, for
instance. ..."

/etc/rc.final gibt es nicht (hier) und müsste eben selbst angelegt werden.

War deine Feststellung das kein umount passiert richtig.
Hätte ich nicht gedacht.

Was aber mir nicht erklärt warum im Fall der Fälle beim booten der
Hinweis kam das nicht sauber umounted wurde und deshalb fsck gestartet
wird. Das ist wie gesagt nur aus der Erinnerung die aber noch
ausreichend funktioniert.

[Volker Englisch]

Am 13.02.23 um 10:13 schrieb Detlef Sax:

> On Sun, 12 Feb 2023 17:59:45 -0000 (UTC), Volker N. Englisch wrote:
>> Detlef Sax <s...@noart.de> schrieb:

>>> Mit fsck_y_enable gab es dann beim starten so gut wie nie Probleme.
>>> Habe mittlerweile seit 1 Jahr zfs.

Ich habe ufs... Mit fsck_y_enable verschwindet die Meldung beim Start
wohl, aber IMHO nur deshalb, weil damit ein fsck erzwungen wird, das
eigentlich gar nicht nötig sein sollte. Ich kann mich aber natürlich
auch täuschen.

>> Wo müsste denn das finale "umount" normalerweise stehen? Beim
>> Herunterfahren muß ja irgendwo ein "umount -A" oder ein "umount -a"
>> kommen.
>

> Das hat mich jetzt auch interessiert und die Antwort ist wohl das
> normalerweise garnicht umounted wird, alle Prozesse werden beendet und
> dann neu gebootet:

Bisher war es aber IMO üblich, gemountete Dateisysteme auszuhängen,
bevor sich das OS beendet...

> "After all user processes have been terminated, init will try to run
> the /etc/rc.final script. This script can be used to finally prepare
> and unmount filesystems that may have been needed during shutdown, for
> instance. ..."

Interessant. Unter man 8 init finde ich hier keinen Hinweis auf
/etc/rc.final.

> /etc/rc.final gibt es nicht (hier) und müsste eben selbst angelegt werden.

Hier auch nicht. Dafür aber ein /etc/rc.shutdown. Wenn ich da am Ende
ein umount eintrage, erhalte ich beim Herunterfahren die Meldung, dass
die Dateisysteme noch busy seien :-(

Interessant finde ich noch, daß ein rcorder -k shutdown /etc/rc.d/* eine
Reihenfolge der Abarbeitung der Scripts ausgibt, die ich nicht erwartet
hätte. Leider kenne ich mich mit dem Init-System nicht so gut aus, daß
ich mich trauen würde, da einzugreifen.

> War deine Feststellung das kein umount passiert richtig.
> Hätte ich nicht gedacht.

Danke für die Bestätigung. Richtig kann das aber IMO nicht sein.

Jetzt fehlt nur noch jemand, der erklärt, warum das entweder doch so
sein muß - oder an welcher Stelle im System genau das umount fehlt.

Freiwillige vor :-)

Volker

[Matthias Andree]

Am 13.02.23 um 12:41 schrieb Volker Englisch:

Ich hab hier FreeBSD 13.2-BETA1 (aus git geholt & gebaut), da gibt's
sowas hier (rg ist aus ripgrep, statt rg täte es auch grep -r):

$ rg -l umount /etc/rc*
/etc/rc.initdiskless
/etc/rc.d/mdconfig
/etc/rc.d/automount
/etc/rc.d/geli
/etc/rc.d/gbde
/etc/rc.d/mdconfig2
/etc/rc.d/root

Außerdem sind init(8) und /etc/rc zum Beispiel am Bootprozess beteiligt,
und rc.shutdown/rc.final sind bei mir durchaus in man 8 init zu finden,
von der Tabelle der Runlevel und Signale drei bzw. fünf Abschnitte
rückwärts abzählen.

Was die Reihenfolge angeht, siehe man rc.shutdown:

> 4. Invoke rcorder(8) to order the files in /etc/rc.d/ and the
> $local_startup directories that have a “shutdown” KEYWORD (refer to
> rcorder(8)'s -k flag), reverse that order, and assign the result to
> a variable.

Du müsstest die rcorder-Liste also rückwärts durchgehen.

Stellt sich weiterhin die Frage, welche Prozesse oder Mounts den
Shutdown "überleben" und das umount der Dateisysteme verhindern.

HTH
Matthias

[Volker Englisch]

Am 13.02.23 um 22:21 schrieb Matthias Andree:

> Am 13.02.23 um 12:41 schrieb Volker Englisch:

> [Kein u(n)mount beim Shutdown]

> Ich hab hier FreeBSD 13.2-BETA1 (aus git geholt & gebaut), da gibt's
> sowas hier (rg ist aus ripgrep, statt rg täte es auch grep -r):
>
> $ rg -l umount /etc/rc*
> /etc/rc.initdiskless

Das gibt's hier nicht.

> etc/rc.d/mdconfig
> /etc/rc.d/automount
> /etc/rc.d/geli
> /etc/rc.d/gbde
> /etc/rc.d/mdconfig2
> /etc/rc.d/root
>
> Außerdem sind init(8) und /etc/rc zum Beispiel am Bootprozess beteiligt,
> und rc.shutdown/rc.final sind bei mir durchaus in man 8 init zu finden,
> von der Tabelle der Runlevel und Signale drei bzw. fünf Abschnitte
> rückwärts abzählen.

rc.final wird hier in init 8 definitiv nicht erwähnt.

> Stellt sich weiterhin die Frage, welche Prozesse oder Mounts den
> Shutdown "überleben" und das umount der Dateisysteme verhindern.

Jetzt wirds aber richtig interessant. Ein sysctl -a | grep unmount
(sic!) ergibt:

<118>Unmounting filesystems and disabling swap
<118>umount: unmount of /var failed: Device busy
<118>umount: unmount of /usr failed: Device busy

Wie kommt das dort hin, bzw. was ist da kaputt!?

Volker

[Volker Englisch]

Am 14.02.23 um 09:01 schrieb 'Ingrid' Volker Englisch:

> Jetzt wirds aber richtig interessant. Ein sysctl -a | grep unmount
> (sic!) ergibt:
>
> <118>Unmounting filesystems and disabling swap
> <118>umount: unmount of /var failed: Device busy
> <118>umount: unmount of /usr failed: Device busy
>
> Wie kommt das dort hin, bzw. was ist da kaputt!?

Ich habe nun den Kernel neu gebaut. Diese "Geistereinträge" sind jetzt
verschwunden. Vielleicht hat sich der Rest des Problems damit auch
erledigt. Schau'n mer mal...

Danke für Eure Geduld!

Volker