| View previous topic :: View next topic |
| Author |
Message |
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3480
Location: Berlin
|
 Posted: Thu Jun 08, 2017 6:00 pm Post subject: Systemd hängt bei HD Fehler |
 |
|
Hallo, ich habe vor geraumer Zeit festgestellt, das systemd einfach mit dem Startvorgang Schluß macht, wenn etwas mit den Festplatteneinträgen in der fstab nicht stimmt oder beispielsweise ein Fehler auf einer ntfs Partition festgestellt wird. Ich hatte zum Beispiel unter Windows 10 "schnelles Herunterfahren" aktiviert. Ein anderes Mal hatte ich eine SATA HD umgesteckt.
Da kommt dann die Aufforderung "Administratorpassowrt für Wartungszwecke eingeben oder STRG+D drücken um fortzufahren". Hat aber beides nichts geholfen. (Ich musste das Herunterfahren unter Windows ändern und das andere Mal die HD wieder umstecken.
Bei der Verwendung von OpenRC konnte man immerhin interaktiv starten.
Gibt es da etwas für systemd? |
|
| Back to top |
|
 |
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Thu Jun 08, 2017 7:53 pm Post subject: |
|
|
| nofail wird das sein, was du suchst. |
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1924
Location: Schweiz
|
| Posted: Fri Jun 09, 2017 7:05 am Post subject: |
|
|
| musv wrote: | | nofail wird das sein, was du suchst. |
Das wäre ja eigentlich etwas das in "eselect news" erwähnenswert gewesen wäre, oder?
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Fri Jun 09, 2017 9:33 am Post subject: Re: Systemd hängt bei HD Fehler |
|
|
| flammenflitzer wrote: | | Ein anderes Mal hatte ich eine SATA HD umgesteckt. |
Echt jetzt? Das ist doch langsam nicht mehr witzig. Also ich finde, dass systemd lernen sollte mit so etwas umzugehen.
Ein Kollege von mir konnte ein Mal seine VM nicht starten, weil er eine externe (!!) USB-Platte (!!) abgezogen hatte, die beim Herunterfahren noch dran war.
| musv wrote: | | nofail wird das sein, was du suchst. |
Das man einen Eintrag aus der fstab, der mit 'noauto' markiert ist, nicht manuell mounten kann, kann ich aber so nicht bestätigen. Auf unseren Debian-Servern gibt es viele solcher Einträge, die alle wunderbar manuell gemountet werden können. 'nofail' haben wir da nie gebraucht.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1924
Location: Schweiz
|
| Posted: Fri Jun 09, 2017 10:08 am Post subject: Re: Systemd hängt bei HD Fehler |
|
|
| Yamakuzure wrote: | | flammenflitzer wrote: | | Ein anderes Mal hatte ich eine SATA HD umgesteckt. |
Echt jetzt? Das ist doch langsam nicht mehr witzig. Also ich finde, dass systemd lernen sollte mit so etwas umzugehen.
Ein Kollege von mir konnte ein Mal seine VM nicht starten, weil er eine externe (!!) USB-Platte (!!) abgezogen hatte, die beim Herunterfahren noch dran war. |
Und was hat das jetzt bitte mit systemd zu tun wenn die Angaben in der fstab nicht mehr stimmen? OpenRC verschluckt sich an sowas auch nur all zu gern.
Würden die Leute endlich mal anfangen die UUID, PARTUUID oder das Label in der fstab zu benutzen würde die Reihenfolge der Geräte weder unter systemd noch OpenRC eine Rolle spielen. Aber leider gehen an genau dieser Stelle nicht einmal die Handbücher mit gutem Beispiel voran, also überrascht das Ergebnis nicht wirklich.
| Yamakuzure wrote: | | musv wrote: | | nofail wird das sein, was du suchst. |
Das man einen Eintrag aus der fstab, der mit 'noauto' markiert ist, nicht manuell mounten kann, kann ich aber so nicht bestätigen. Auf unseren Debian-Servern gibt es viele solcher Einträge, die alle wunderbar manuell gemountet werden können. 'nofail' haben wir da nie gebraucht. |
Bei der Option noauto ist nofail auch gemäß der oben erwähnten Manpage unnötig. Nur wenn "auto" oder nichts gesetzt ist (denn ohne "noauto" geht systemd standardmäßig davon aus das es beim boot eingebunden werden soll) sollte ein "nofail" dran wenn es sich nicht um ein für den boot notwendiges Dateisystem handelt.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
musv
Advocate
Joined: 01 Dec 2002
Posts: 3337
Location: de
|
| Posted: Sat Jun 10, 2017 1:00 pm Post subject: |
|
|
Ich kann unterschreiben, was schmidicom sagt.
Systemd steigt beim Bootvorgang aus, wenn ein systemrelevantes Laufwerk nicht eingebunden werden kann. Als "systemrelevant" wird halt definiert, was in der fstab steht und nicht mit noauto oder nofail gekennzeichnet ist. Meiner Meinung nach ist das vollkommen korrekt. Systemd schickt Dich bei einer fehlerhaften fstab dann direkt in den Wartungsmodus, damit erst mal die fstab korrigieren kannst, ohne das gesamte System zu zerschießen. Wie handhabt OpenRC diesen Fall? |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Mon Jun 12, 2017 12:14 pm Post subject: |
|
|
| musv wrote: | Ich kann unterschreiben, was schmidicom sagt.
Systemd steigt beim Bootvorgang aus, wenn ein systemrelevantes Laufwerk nicht eingebunden werden kann. Als "systemrelevant" wird halt definiert, was in der fstab steht und nicht mit noauto oder nofail gekennzeichnet ist. Meiner Meinung nach ist das vollkommen korrekt. Systemd schickt Dich bei einer fehlerhaften fstab dann direkt in den Wartungsmodus, damit erst mal die fstab korrigieren kannst, ohne das gesamte System zu zerschießen. Wie handhabt OpenRC diesen Fall? |
Ihr missversteht mich.
Mein Kollege hat eine externe USB-Platte gemountet, und wie durch ein Wunder war systemd der Ansicht, dass diese ganz dringend beim nächsten Boot-Vorgang benötigt würde. An der fstab hat er *nichts* geändert.
...und wenn ich das nicht schon selber einmal bei einem Server erlebt hätte, hätte ich ihm das nicht geglaubt. Selbiger Server wollte dann auch ein mal nicht von alleine booten, weil systemd nach einem Update der Meinung war, das Plymouth ganz furchtbar dringend benötigt wird... auf einem reinen SFTP-Server... 
| schmidicom wrote: | | Würden die Leute endlich mal anfangen die UUID, PARTUUID oder das Label in der fstab... |
Ach herrje, das stimmt natürlich. flammenflitzer hat den Fall ja nun nicht näher spezifiziert.
Nunja, systemd muss da auch nichts in der /etc/fstab finden. Es muss ja nur entschieden haben, dass das Gerät notwendig ist.
Leute, ihr könnt systemd so heilig sprechen, wie ihr wollt. systemd funktioniert auf Desktop-Systemen (meistens) ganz prima. Ich kenne nun eben auch gut ein Dutzend Möglichkeiten einen Server dank systemd zum Backstein zu machen. Und das sind alles Möglichkeiten, die ohne systemd gar nicht funktionieren würden. Alle Standpunkte sind nun mal subjektiv.
Also beschränken wir uns doch lieber auf das Wesentliche, ja?
| schmidicom wrote: | | Bei der Option noauto ist nofail auch gemäß der oben erwähnten Manpage unnötig. Nur wenn "auto" oder nichts gesetzt ist (denn ohne "noauto" geht systemd standardmäßig davon aus das es beim boot eingebunden werden soll) sollte ein "nofail" dran wenn es sich nicht um ein für den boot notwendiges Dateisystem handelt. |
Ich bitte vielmals um Entschuldigung, ich bin da auf den Link eingegangen, und habe mich genau dort verlesen: "When I try to mount manually without the drive connected, I immediately get the error(...)" - Das "without" hatte ich überlesen. *schäm*
Wie dem auch sei, flammenflitzer schrieb, er hätte die HD wieder umstecken müssen. Das klang für mich nicht nach einer "/dev/sdX" zu "/dev/sdY" Änderung. Aber wie gesagt, der Fall ist ja nicht näher spezifiziert.
Ich bin (leichtsinniger Weise) von einer Pfadänderung ausgegangen, und damit hat *nur* systemd ein Problem.
Erklärung:
Auf einem meiner Server heißt /dev/sda für systemd: | systemctl list-units wrote: | | sys-devices-pci0000:00-0000:00:02.0-0000:1c:00.0-0000:1d:00.0-0000:1f:00.0-host0-target0:2:0-0:2:0:0-block-sda.device |
Niedlicher Name, gell?
| Code: |
0000:00:02.0 : PCI Bridge Port 2
0000:1c:00.0 : PCI Express Upstream Port
0000:1d:00.0 : PCI Express Downstream Port
0000:1f:00.0 : LSI Logic MegaRAID SAS
host0 : Localhost. Ist klar.
target0:2:0 : Ich kann beim besten Willen nicht sagen, was das ist...
0:2:0:0 : Das ist endlich die Adresse. scsi0, Channel 02, Target 00, LUN 00 |
Wenn ich die LUN dieses RAID-Laufwerks ändere, bleibt das in jedem Fall /dev/sda. Wenn ich den RAID-Kontroller auf Port 1, 3 oder 4 umstecke, bleibt das Laufwerk in jedem Fall /dev/sda.
Aber was aus dem Device-Pfad wird, könnt Ihr euch ja denken...
Wie gesagt, entschuldigt bitte, dass ich naiver Weise von so einem Fall ausgegangen bin.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1924
Location: Schweiz
|
| Posted: Mon Jun 12, 2017 12:44 pm Post subject: |
|
|
systemd generiert zwar viele Units "on the fly" die es intern verwendet aber keines davon überlebt einen Neustart (manchmal nicht einmal den Standby) und könnte anschließend den Rechner blockieren.
Das Device-Unit das du da gerade als Beispiel zeigst ist eines von denen:
https://www.freedesktop.org/software/systemd/man/systemd.device.html
Würdest du deinen Controller also umstecken gäbe es das Ding beim nächsten Neustart nicht mehr. systemd würde es, wegen der Reaktion von udev, sogar im laufenden Betrieb wegschmeißen wenn du den Controller ohne Neustart umstecken könntest.
Ganz ehrlich, ich bezweifle sehr das sich systemd ohne spezielle Konfiguration (selber geschriebene Mount-Units, fehlerhafte Einträge in der fstab oder eben durch das gewurschtel einer anderen Komponente welche meint system/udev dazwischen grätschen zu müssen) so verhält wie du es beschreibst, denn ich setze es nun schon lange auf meinem Laptop, mehreren Desktops und Servern (Gentoo, Ubuntu, Debian) ein und hatte nie ein ähnliches Problem.
Zur Abhängigkeit von Plymouth:
Das hingegen kenne ich, war in meinem Fall jedoch auch nicht wirklich die Schuld von systemd. Ein fehlerhaftes Service-Unit welches durch ein anderes Programm installiert wurde brachte diese Abhängigkeit in den bootprozess weshalb dann systemd krampfhaft versuchte diese Abhängigkeit zu erfüllen, was aber an einer fehlenden Plymouthkonfiguration kläglich scheiterte. Durch ein "systemctl list-dependencies" konnte ich damals den Übeltäter schnell finden und entsorgen.
EDIT:
Ich bin der Meinung viele Probleme entstehen nicht durch systemd selbst sondern durch mangelhaft geschriebene Units und sowas hätte auch unter OpenRC unangenehme Konsequenzen. Aber am Anfang, als systemd noch neu war, gab es weit mehr solche Units. Es braucht nun mal bei jeder neuen Komponente etwas Zeit bis alles rund läuft...
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Tue Jun 13, 2017 8:17 am Post subject: |
|
|
| schmidicom wrote: | systemd generiert zwar viele Units "on the fly" die es intern verwendet aber keines davon überlebt einen Neustart (manchmal nicht einmal den Standby) und könnte anschließend den Rechner blockieren.
(...)
systemd würde es, wegen der Reaktion von udev, sogar im laufenden Betrieb wegschmeißen wenn du den Controller ohne Neustart umstecken könntest. |
Oh, prima!
Ich muss gestehen, dass der Fall mit dem Server eine Weile her ist. Debian ist ja nun nicht unbedingt dafür bekannt, immer die neueste Software (eher Asbach Uralt zu Tode gepatcht  ) einzusetzen.
Wenn sowas gar nicht mehr vorkommen kann, ists ja gut. das hat mir damals auf dem Server echt einiges an Nerven gekostet.
| schmidicom wrote: | | Ganz ehrlich, ich bezweifle sehr das sich systemd ohne spezielle Konfiguration (selber geschriebene Mount-Units, fehlerhafte Einträge in der fstab oder eben durch das gewurschtel einer anderen Komponente welche meint system/udev dazwischen grätschen zu müssen) so verhält wie du es beschreibst, denn ich setze es nun schon lange auf meinem Laptop, mehreren Desktops und Servern (Gentoo, Ubuntu, Debian) ein und hatte nie ein ähnliches Problem. |
Sowohl Server, wie auch die VM meines Kollegen, liefen auf Debian Jessie. Aber wie gesagt, der Server war nicht gerade aktuell, und dann halt auch noch Debian.
Bei meinem Kollegen vermute ich einfach mal, dass das durch das Durchreichen von USB3 an die VMware Workstation verursacht wurde. Vielleicht sieht das für das System dann einfach nicht "Removable" genug aus... wer weiß...
| schmidicom wrote: | Zur Abhängigkeit von Plymouth:
Das hingegen kenne ich, war in meinem Fall jedoch auch nicht wirklich die Schuld von systemd. Ein fehlerhaftes Service-Unit welches durch ein anderes Programm installiert wurde brachte diese Abhängigkeit in den bootprozess weshalb dann systemd krampfhaft versuchte diese Abhängigkeit zu erfüllen, was aber an einer fehlenden Plymouthkonfiguration kläglich scheiterte. Durch ein "systemctl list-dependencies" konnte ich damals den Übeltäter schnell finden und entsorgen. |
Oh! Ich bin nicht der Einzige, der das mal hatte!
Ich frage mich nur, wie es möglich sein kann, so einer Unit so eine hohe Bedeutung zuschanzen zu können.
Mit OpenRC gibt es ja nun wirklich wenig, was bei einem Fehlschlag den ganzen Boot-Prozess zum Stehen bringt...
| schmidicom wrote: | | Es braucht nun mal bei jeder neuen Komponente etwas Zeit bis alles rund läuft... |
Hört, hört. 
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1924
Location: Schweiz
|
| Posted: Tue Jun 13, 2017 8:42 am Post subject: |
|
|
| Yamakuzure wrote: | Ich frage mich nur, wie es möglich sein kann, so einer Unit so eine hohe Bedeutung zuschanzen zu können.
Mit OpenRC gibt es ja nun wirklich wenig, was bei einem Fehlschlag den ganzen Boot-Prozess zum Stehen bringt... |
Das von mir erwähnte Service-Unit war das von einem DisplayManager (bin mir nicht mehr sicher welcher aber ich glaube es war lightdm) und wurde von mir selbst per "systemctl enable lightdm" aktiviert. In so einem Fall muss systemd ja davon ausgehen das es mit samt seinen definierten Abhängigkeiten essentiell für den Start des Systems ist und dementsprechend reagieren. Ich wäre sehr verwundert wenn OpenRC das anders sehen würde, immerhin kann es vor allem bei einem Server ziemlich unschön enden wenn ein explizit aktivierter Dienst (z.B. fail2ban oder ähnliches) dann doch nicht startet und der Start trotzdem unbeeindruckt fortgesetzt wird.
Zum eigentlich Fehler im Unit von damals:
Derjenige der das Unit geschrieben hatte verwechselte wohl "Requires=" mit "Wants=".
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
flammenflitzer
Advocate
Joined: 25 Nov 2003
Posts: 3480
Location: Berlin
|
| Posted: Sat Jun 17, 2017 1:50 pm Post subject: |
|
|
Der Eintrag in der fstab sollte also von | Code: | | UUID=01CF06C8812ED670 /home/flammenflitzer/Daten ntfs-3g auto,users,uid=1000,gid=1000,locale=de_DE.utf8 0 0 |
in | Code: | | UUID=01CF06C8812ED670 /home/flammenflitzer/Daten ntfs-3g nofail,users,uid=1000,gid=1000,locale=de_DE.utf8 0 0 |
geändert werden? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
