beim Booten "a start job is running..."

Welches Modul/Treiber für welche Hardware, Kernel compilieren...
aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

beim Booten "a start job is running..."

Beitrag von aki » 02.02.2018 12:07:24

Hallo zusammen,

ich habe ein ähnliches Problem und hoffe Ihr könnt mir helfen.

Der Fehler lautet:

Code: Alles auswählen

systemd[1]: swap.target: Job swap.target/start failed with result 'dependency'.
systemd[1]: dev-mapper-pdc_baeahcegi5.swap: Job dev-mapper-pdc_baeahcegi5.swap/start failed with result 'dependency'.
systemd[1]: dev-mapper-pdc_baeahcegi5.device: Job dev-mapper-pdc_baeahcegi5.device/start failed with result 'timeout'.
Da ist keine Meldung wie bei Euch von wegen UUID.

Hier die Ausgabe der /etc/fstab

Code: Alles auswählen

/dev/mapper/pdc_baeahcegi1 /               ext4    errors=remount-ro 0       1
/dev/mapper/pdc_baeahcegi5 none            swap    sw              0       0
Und hier noch die Ausgabe von blkid.

Code: Alles auswählen

# blkid
/dev/sdb1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sdb5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
/dev/sda1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sda5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
/dev/mapper/pdc_baeahcegi: PTUUID="3c26cbd0" PTTYPE="dos"
/dev/mapper/pdc_baeahcegi1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4"
/dev/mapper/pdc_baeahcegi5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap"
Zum System selber:

4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

Ich nutze über den onboard Controller die Platten als RAID1 im System ist das der /dev/mapper/pdc_baeahcegi.

Mit besten Grüßen

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von smutbert » 02.02.2018 12:33:23

Ursache für den Fehler sehe ich auf Anhieb keine, aber du könntest die swap-Partition testweise mit

Code: Alles auswählen

UUID=ab519919-f5c9-42eb-b71f-77ca31133458   none   swap   sw   0   0
einbinden statt dem Namen der Gerätedatei oder die Zeile in der fstab sogar komplett auskommentieren – normalerweise werden swap-Partitionen auch aktiviert, wenn es keinen entsprechenden Eintrag in der fstab gibt (da ist es eher ein Kampf zu _verhindern_, dass eine bestimmte swap-Partition verwendet wird...)

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von aki » 02.02.2018 13:28:38

Hallo,

das ist ja schon mal beruhigend zu wissen das ich nicht ganz so "blind" bin da ich eben auch keinen Grund für das Verhalten erkennen konnte.

Wie kann ich denn testen außer den Ruhemodus welchen ich eh nicht nutze ob die swap arbeitet oder nicht? Ich habe mal testweise mittels swapoff -a, swapon -a parallel in einem zweiten Terminal free -s 3 |grep Swap sowie swapoff /dev/mapper/pdc_baeahcegi5 und swapon /dev/mapper/pdc_baeahcegi5 geprüft ob da Fehlermeldungen kommen aber alles gut. Nur bin ich mir da halt nicht sicher da nichts ausgelagert wird da meine 16GB RAM noch reichlich Reserve haben.

Beste Grüße

Benutzeravatar
smutbert
Moderator
Beiträge: 8313
Registriert: 24.07.2011 13:27:39
Wohnort: Graz

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von smutbert » 02.02.2018 14:49:33

Code: Alles auswählen

# swapon
und

Code: Alles auswählen

$ cat /proc/swaps
liefern eine Liste der aktiven swap-Dateien/-Partitionen und in der Ausgabe von free sieht man natürlich auch die Größe es gesamten swap.

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von rendegast » 02.02.2018 14:55:06

aki hat geschrieben: /dev/sdb1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sdb5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
/dev/sda1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sda5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
Die Partitionen enthalten scheinbar keinen raid-Header "linux_raid_member", stattdessen "ext4" und "swap".

Die PARTUUID sollten eigentlich unterschiedlich sein, eventuell so vom Klonen.

Der Partitionstyp ('fdisk -l') wohl besser
29 - Linux RAID (gpt)
fd - Linux raid auto (dos)
(das ist für die Funktion eventuell belanglos, läßt sich aber mit fdisk schnell ändern)

Sollen obige Partitionen 2 raid1 bilden?
Resp. Ist das partitionierte pdc_baeahcegi aus den sd[ab]1 gebildet?





Sollte neuer Thread sein.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von aki » 02.02.2018 15:17:44

Hallo,

Code: Alles auswählen

cat /proc/swaps
Filename				Type		Size	Used	Priority
/dev/mapper/pdc_baeahcegi5              partition	16691196	0	-1
So wäre das korrekt aus meiner Sicht. Verstehe ich nicht was er dann beim Start für ein Problem hat.

Zu deiner Frage:

Es sind ja zwei 1TB Platten welche über den onboard Controller als Raid1 definiert wurden. Beim Installieren habe ich dann aufgrund der Erfahrungen von älteren Debian Versionen als zusätzliche Option dmraid=true mit angegeben. Das Ergebnis war das ich nur den Verbund aber nicht die einzelnen Platten zu sehen bekomme. Warum die UUID identisch ist kann ich Dir nicht beantworten dafür habe ich mich nicht ausreichend genug mit dessen zugrunde liegenden Konzept beschäftigt. Ich werde jedoch sofern keine Einwände bestehen mal die SWAP nach deinen Empfehlungen in der etc/fstab auskommentieren.

Beste Grüße

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von aki » 03.02.2018 20:52:10

Hallo,

das auskommentieren in der /etc/fstab funktioniert prinzipiell jedoch ist dann auch die SWAP nicht mehr nutzbar. Das umstellen auf die UUID in der /etc/fstab funktioniert auch wenn sich mir noch immer nicht erschließt warum dies notwendig war.

beste Grüße

Cae
Beiträge: 6349
Registriert: 17.07.2011 23:36:39
Wohnort: 2130706433

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von Cae » 04.02.2018 08:29:06

Andere, jedoch artverwandte Frage: Gibt es einen Override, um in's Timeout rennende Units interaktiv abzubrechen? Sowas wie ^C oder ^\ (was beides nicht tut). Suchmaschienen sind leider bisher wenig hilfreich gewesen (oder der Herr Poettering hat den seltenen Fall nicht vorgesehen, dass einen Rechner verwenden moechte, anstatt auf die init zu warten).

Gruss Cae
If universal surveillance were the answer, lots of us would have moved to the former East Germany. If surveillance cameras were the answer, camera-happy London, with something like 500,000 of them at a cost of $700 million, would be the safest city on the planet.

—Bruce Schneier

TomL

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von TomL » 04.02.2018 10:01:58

Cae hat geschrieben: ↑ zum Beitrag ↑
04.02.2018 08:29:06
Gibt es einen Override, um in's Timeout rennende Units interaktiv abzubrechen? Sowas wie ^C oder ^\ (was beides nicht tut).
Ja, sicher gibts das...

Code: Alles auswählen

systemctl stop <name.service
Systemd sendet einen SIGTERM an die Anwendung und wenn sie ordentlich programmiert ist, sollte sie sich damit beenden.

Cae
Beiträge: 6349
Registriert: 17.07.2011 23:36:39
Wohnort: 2130706433

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von Cae » 04.02.2018 10:52:37

Sorry, Missverstaendnis: Ich meine implizit den hier im Thread bestehenden Kontext "beim Booten", also wenn es eben keine Shell gibt.

Haeufiges Beispiel: Netzwerk ist auf DHCP eingestellt, dieser ist aber nicht verfuegbar (oder das Kabel steckt nicht). Das wartet dann 90 Sekunden (oder sogar fuenf Minuten, hab's gerade nicht im Kopf) und failt dann. Ich wuerde gerne interaktiv sagen koennen "nein, das wird nie klappen, bitte ueberspringen". Zu diesem Zeitpunkt hab' ich auch kein /dev/ttyX, wie es ganz frueher zu sysvinit-Zeiten war.

Gruss Cae
If universal surveillance were the answer, lots of us would have moved to the former East Germany. If surveillance cameras were the answer, camera-happy London, with something like 500,000 of them at a cost of $700 million, would be the safest city on the planet.

—Bruce Schneier

TomL

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von TomL » 04.02.2018 12:06:47

Nach meinem Verständnis muss man wahrscheinlich einmal in den sauren Apfel beissen und die Timeouts aushalten. Ich würde dann, wenn der Rechner läuft, die betroffenen Services von Hand starten und schauen, wo und warum es hakt. Und wenn ich nicht weiss, welche Services haken, dann hilft vielleicht die Debug-Shell:
https://freedesktop.org/wiki/Software/s ... Debugging/

Dann finde ich bei Störungen einen Blick ins Journal mit den Filtern "err" und "warning" und vor allem den Boot-Plot immer auch sehr interessant, an dem ich gleich optisch sehe, welcher Prozess ein Ausreisser war. Andere Lösungen hätte ich jetzt auch nicht parat.

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: GELÖST! beim Booten "a start job is running..."

Beitrag von aki » 19.02.2018 10:25:04

Hallo zusammen,

ganz großes Kino bei mir. Erstens mal mountet er die SWAP nach der Umstellung auf UUID in der /etc/fstab beim booten und mal nicht. Alles was ich dann sehe zu dem Thema (systemctl status /dev/mapper/pdc_.....) ist bei Job dead. Dann noch etwas ganz lustiges. Ich habe einen zweiten Verbund aufgebaut auf welchem bacula die Backups ablegt. Ich mounte gezwungener Maßen erst nach dem booten den zweiten Verbund als root. Der Eintrag in der /etc/fstab lautet wie folgt /dev/mapper/pdc_gijeeead1 /mnt/Backup ext4 defaults 0 2
# UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" /mnt/Backup ext4 defaults 0 2
. Ihr seht ich habe es auch schon mit der UUID versucht. Dazu wäre auch gleich eine Frage nämlich die Anführungszeichen müssen die sein? Im Netz finde ich die Angabe immer ohne aber die Abfrage von blkid ist immer mit diesen in der Ausgabe. Jedenfalls egal ob mit oder ohne UUID nach einem Neustart lande ich dann im Notfallmodus weil er den zweiten Verbund nicht mounten kann. Im laufenden System geht das ohne Probleme. Kann es sein das da ein interner Systemaccount Rechte brauch oder so was in der Richtung?

Beste Grüße

Benutzeravatar
KBDCALLS
Moderator
Beiträge: 22355
Registriert: 24.12.2003 21:26:55
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Dortmund
Kontaktdaten:

Re: beim Booten "a start job is running..."

Beitrag von KBDCALLS » 19.02.2018 11:32:10

Thread abgetrennt , da Ursprungs Thread von 2014
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.

EDV ist die Abkürzung für: Ende der Vernunft

Bevor du einen Beitrag postest:
  • Kennst du unsere Verhaltensregeln
  • Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.

rendegast
Beiträge: 15041
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von rendegast » 19.02.2018 19:40:15

Bzgl. der Verwendung von UUID, wie ist denn

Code: Alles auswählen

ls -l /dev/disk/by-uuid/
?
Sind alle devices eineindeutig dort vertreten?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von NAB » 19.02.2018 20:36:46

Sicher, dass du ein Raid betreibst?

Code: Alles auswählen

cat /proc/mdstat
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 20.02.2018 12:43:47

Hallo zusammen,

Die Ausgabe schaut so aus.

Code: Alles auswählen

ls -l /dev/disk/by-uuid/
insgesamt 0
lrwxrwxrwx 1 root root 10 Feb 20 12:33 4963ef0f-c4b8-4294-97f0-0ba593008031 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Feb 20 12:33 ab519919-f5c9-42eb-b71f-77ca31133458 -> ../../sdc5
lrwxrwxrwx 1 root root 10 Feb 20 12:33 dec4fa5e-97ba-40f1-9382-59c4485cfc39 -> ../../sdc1
sdb1 ist /mnt/Backup
sdc5 ist swap
sdc1 ist /


Und zur Frage mit dem RAID das läuft über dmraid.

Code: Alles auswählen

dmraid -r
/dev/sda: pdc, "pdc_gijeeead", mirror, ok, 3906249984 sectors, data@ 0
/dev/sdc: pdc, "pdc_baeahcegi", mirror, ok, 1953124992 sectors, data@ 0
/dev/sdb: pdc, "pdc_gijeeead", mirror, ok, 3906249984 sectors, data@ 0
/dev/sdd: pdc, "pdc_baeahcegi", mirror, ok, 1953124992 sectors, data@ 0
Beste Grüße

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von NAB » 20.02.2018 19:09:58

aki, da stimmt doch was nicht.

Dein baeahcegi Array besteht aus sdc und sdd. Korrekter Weise zeigt dir blkid sdc und sdd nicht einzeln an sondern stattdessen /dev/mapper/pdc_baeahcegi*
Wobei das auch nicht so ganz korrekt ist. sdc und sdd müssten als TYPE="promise_fasttrack_raid_member" auftauchen, vergleiche hier:
https://askubuntu.com/questions/37514/h ... 04-upgrade

Und jetzt guck mal auf dein gijeeead array. dmraid sagt, es läuft und besteht aus sda und sdb.

blkid sieht aber sda und sdb einzeln. Das taucht gar nicht unter /dev/mapper/pdc_gijeeead* auf.

Läuft gijeeead nun oder nicht?

Deine UUIDs scheinen völlig unzuverlässig zu sein. blkid sieht jede UUID dreifach.
sdb1 ist /mnt/Backup
jetzt wird's ganz spannend ... hier hat sdb1 plötzlich eine ganz neue UUID:
4963ef0f-c4b8-4294-97f0-0ba593008031
Vorher war es:
dec4fa5e-97ba-40f1-9382-59c4485cfc39 (die dreifach vergeben war).
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 20.02.2018 20:27:19

Hallo NAB,

ein wenig durcheinander hast mich jetzt schon gebracht aber ich versuche Dir mal zu folgen :D .

Die aktuelle Ausgabe von blkid schaut so aus

Code: Alles auswählen

/dev/sda1: LABEL="backup" UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" TYPE="ext4" PARTUUID="cc019d6b-01"
/dev/sdd1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sdd5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
/dev/sdb1: LABEL="backup" UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" TYPE="ext4" PARTUUID="cc019d6b-01"
/dev/sdc1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
/dev/sdc5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap" PARTUUID="3c26cbd0-05"
/dev/mapper/pdc_baeahcegi1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4"
/dev/mapper/pdc_gijeeead1: LABEL="backup" UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" TYPE="ext4"
/dev/mapper/pdc_baeahcegi5: UUID="ab519919-f5c9-42eb-b71f-77ca31133458" TYPE="swap"
/dev/mapper/pdc_gijeeead: PTUUID="cc019d6b" PTTYPE="dos"
/dev/mapper/pdc_baeahcegi: PTUUID="3c26cbd0" PTTYPE="dos"
/dev/mapper/pdc_baeahcegi2: PTUUID="4f17a968" PTTYPE="dos" PARTUUID="3c26cbd0-02"

Sprich die UUID von sda1, sdb1 und gijeeead1 ist identisch (/mnt/Backup). Und ja der Verbund arbeitet perfekt mit dem Umweg des mountens nach dem Booten.
Die UUID dec4fa5e-97ba-40f1-9382-59c4485cfc39 gehört zu sdd1, sdc1 und baeahcegi1 (/). Die UUID ab519919-f5c9-42eb-b71f-77ca31133458 gehört zu sdd5, sdc5 und baeahcegi5 (swap). Jetzt verstehe ich nicht was da nicht passen soll. Ich habe auch mal über gparted geschaut und dort ist zu sehen das der Füllstand, die Struktur etc. identisch ist.

Ich bin ein wenig verwirrt wo du den Fehler siehst :D

Beste Grüße

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 20.02.2018 20:42:11

Nachtrag,

was die je 3 identischen UUIDs angehen ich hoffe das ist es was Du meinst finde ich logisch weil Du hast ja pro Verbund zwei physische Platten (bei mir RAID1). Somit hat Platte 1 Partition 1 die UUID XYZ welche identisch ist mit Platte 2 Partition 1 und Identisch ist mit /dev/mapper/pdc_ da ja darüber der Verbund angesprochen wird und nicht die einzelnen Platten. Wäre das nicht so hätte ich auch kein RAID1 denn dann würde auf der jeweiligen Platte unterschiedliche Daten vorhanden sein.

Beste Grüße

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von NAB » 20.02.2018 23:16:31

Ah, nun sieht die Ausgabe von blkid ja vollständiger aus.

aki, ich bin keineswegs ein Experte für dmraid. Eigentlich bin ich überrascht, dass es noch eigenständig existiert. Ich dachte, das sei längst von md und mdadm geschluckt worden. Das Arch-Wiki bezeichnet dmraid inzwischen als "wird nicht mehr weiterentwickelt" und rät von dessen Verwendung ab. Ich habe keine Ahnung, wie gut dmraid noch mit aktuellen Systemen und insbesondere Systemd zusammenarbeitet.

Was mich stört ist, dass auf sda bis sdd überhaupt eigenständige Partitionen erkannt werden. Das sollte so nicht sein. Eigentlich sollte da nur:
/dev/sda: TYPE="promise_fasttrack_raid_member"
stehen, wie in obigem Beispiellink.

An deiner Stelle würde mir das ziemliche Sorgen bereiten und ich würde mich fragen, wie unzuverlässig dmraid inzwischen ist.

Systemd versucht inzwischen eigenständig, Swap-Partitionen zu erkennen und in Betrieb zu nehmen. Wenn das deine /dev/sdd5 oder /dev/sdc5 sieht und "versehentlich" in Betrieb nimmt, macht es dein Raid kaputt.

Was du als "logisch" empfindest, nämlich mehrfach vergebene UUIDs, macht den Sinn von UUIDs kaputt, die sollen nämlich "Unique", also einzigartig sein.

Korrekt zugeordnet werden sie auch nicht, wie dein
ls -l /dev/disk/by-uuid/
zeigt. Die UUIDs müssten auf /dev/mapper/... zeigen.

Auf deine "Laufwerksbuchstaben" /dev/sda, /dev/sdb u.s.w. kannst du dich auch nicht verlassen ... mal hat sdb1 die UUID 4963ef0f-c4b8-4294-97f0-0ba593008031, gehört also zu gijeeead, mal die UUID dec4fa5e-97ba-40f1-9382-59c4485cfc39, gehört also zu baeahcegi.

Du darfst also weder UUIDs noch /dev/sdX verwenden. Und du musst Systemd die Autoerkennung abgewöhnen (wobei der Sinn von Swap auf Raid1 eh fraglich ist und Systemd da nicht wirklich was kaputt machen dürfte, solange du kein Suspend-To-Disk machst).

Zu deinem eigentlichen Problem:
systemd beschwert sich, dass es /dev/mapper/pdc_baeahcegi5 nicht starten kann:
dev-mapper-pdc_baeahcegi5.device: Job dev-mapper-pdc_baeahcegi5.device/start failed with result 'timeout'.

Warum nicht? Keine Ahnung. Das Arch-Wiki erwähnt einen "dmraid.service", aber den finde ich unter Debian weder bei Systemd noch in den dmraid-Paketen. Wenn ich den Debian-Ansatz richtig verstehe, handhabt Debian dmraid komplett in der initramdisk, und da gibt's noch kein Systemd. Systemd sollte also bereits ein existierendes /dev/mapper/pdc_baeahcegi5 vorfinden und es gar nicht erst zu starten versuchen. Andererseits scheint dmraid in Debian in der initramdisk kaputt zu sein, wenn ich mir diesen einsamen Bugreport so angucke:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=864423
Das sieht mir so aus, als ob dmraid demnächst aus Debian rausfliegt.

Wann auch immer du deine Raids zusammenbastelst, Systemd scheint /dev/mapper/pdc_baeahcegi5 noch nicht zu finden. Warum das so ist, verstehe ich nicht - immerhin ist auf baeahcegi dein root-Dateisystem. baeahcegi müsste also laufen, inklusive /dev/mapper/pdc_baeahcegi5.

Entweder fummelst du das auseinander, oder du nimmst swap ganz aus der fstab und startest es per Hand, genau wie du es mit /mnt/Backup machst.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 21.02.2018 02:11:16

Hallo NAB,

erst mal Danke für die ausführlichen Infos.

Ich muss mir das morgen im ausgeruhten Zustand genauer anschauen aber wo siehst Du das denn mit der UUID (ich sehe grade den Wald vor lauter Bäumen nicht)?
NAB hat geschrieben: ↑ zum Beitrag ↑
20.02.2018 23:16:31
Auf deine "Laufwerksbuchstaben" /dev/sda, /dev/sdb u.s.w. kannst du dich auch nicht verlassen ... mal hat sdb1 die UUID 4963ef0f-c4b8-4294-97f0-0ba593008031, gehört also zu gijeeead, mal die UUID dec4fa5e-97ba-40f1-9382-59c4485cfc39, gehört also zu baeahcegi.
Morgen mehr.

Beste Grüße

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von NAB » 21.02.2018 04:25:19

aki hat geschrieben: ↑ zum Beitrag ↑
21.02.2018 02:11:16
aber wo siehst Du das denn mit der UUID (ich sehe grade den Wald vor lauter Bäumen nicht)?
Hier:
viewtopic.php?f=33&t=168751#p1163340
/dev/sdb1: UUID="dec4fa5e-97ba-40f1-9382-59c4485cfc39" TYPE="ext4" PARTUUID="3c26cbd0-01"
und hier:
viewtopic.php?f=33&t=168751&start=15#p1165636
lrwxrwxrwx 1 root root 10 Feb 20 12:33 4963ef0f-c4b8-4294-97f0-0ba593008031 -> ../../sdb1

Das ist nach einem Reboot nichts Ungewöhnliches, dass die Buchstaben sich ändern. Das hängt davon ab, in welcher Reihenfolge sich die Festplatten beim BIOS melden. Aber eben deswegen wurden die UUIDs erfunden, weil man sich auf die Buchstaben eben nicht mehr verlassen kann.

Auf die UUIDs kannst du dich aber auch nicht verlassen. Die erscheinen dreifach.

Worauf du dich (hoffentlich) verlassen kannst ist, dass dmraid dir /dev/mapper/... richtig zusammenbastelt.

Das Problem ist, dass der Kernel dir (und dem Rest des Systems) die Partitionen sda1, sdb1 usw. zusätzlich noch mal zeigt. Die sollten gar nicht existieren. Ich weiß nicht, warum das so ist, aber nach meinen Google-Funden scheint sich das so zwischen 2014 und 2016 geändert zu haben.

Ich hab da grad noch einen Bugreport von 2013 gefunden:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=699437
Interessant ist die Antwort von Ben Hutchings ganz unten. Der beschreibt eben den Effekt, dass der Kernel die einzelnen Partitionen eines Fake-Raid-Verbundes noch mal einzeln entdeckt und UUIDs mehrfach existieren. Immerhin deutet er an, dass die Einzel-Partitionen schreibgeschützt sind, das ist beruhigend. Beachte, dass schon hier kein Versuch mehr unternommen wird, den Fehler irgendwie zu beseitigen. dmraid ist ziemlich tot.

Und hier ist ein interessanter Fehlerbericht von Arch-Linux:
https://bugs.archlinux.org/task/31236
Interessant ist die Ausgabe von
ls -al /dev/mapper
Die Einträge unter /dev/mapper/ sind dort nur Symlinks zu /dev/dm-X.
Um diese Symlinks kümmert sich Udev. Weiter unten streiten sie sich darum, ob Udev diese Symlinks zu spät erzeugt und Systemd zu früh auf einen Link unter /dev/mapper/ zugreift. Wenn du dein "a start job is running..."-Problem Systemd-konform lösen möchtest, könntest du dich da durchwühlen.

Vermutlich ist es leichter, swap aus der fstab zu nehmen und später per Script zu mounten.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 21.02.2018 12:11:59

Hallo NAB,

also die wechselnde UUID kann ich mir nur wie folgt erklären (sdb1). Und zwar sind im PC 4 Platten 2 x1 TB WD und 2 x 2TB Seagate. Dies war bis vor kurzem unter Windoof 10 je ein RAID 1 Verbund. Da ich dann aber endgültig die Schnauze voll hatte das Mr. Bill Gates meint mir ungefragt ein Future Pack mit über 5 GB aufdrücken zu wollen. Selbst ohne Verbindung zum Internet mit GPO und haste nicht gesehen wurde ich weiterhin davon behelligt. Und auch als Oberadmin (nicht der normale Admin da gibt es tatsächlich einen Unterschied) hatte ich keine Chance das wieder los zu werden. Da war der Punkt endgültig erreicht wo ich wieder die Kontrolle über mein System haben wollte. Daher nach 7 Jahren Pause ist wieder Debian auf meinem System. Und aus der alten Zeit habe ich das auch mit dem DMRAID denn ohne hast damals in die Röhre geschaut. Also habe ich auf dem 1 TB Verbund das System Installiert und den 2 TB Verbund aufgelöst und zeitweise eine Platte mit eingebunden (sehr wahrscheinlich die sdb1) und die andere abgehängt als Weg zurück falls es nicht richtig hinhaut mit dem Umzug. Dann war alles soweit fertig und lief bis auf die blöde swap die ab und an beim booten nicht wollte. Deshalb habe ich dann vor wenigen Tagen wieder den 2 TB Verbund aufgebaut für bacula als Backup Volume. Weil da aber noch Altlasten drauf waren und mir eine der beiden Platten von DMRAID als /dev/mapper/pdc_nvidia gemeldet wurde habe ich über dmraid -E -r /dev/... klare Verhältnisse geschaffen. Und seit dem wechselt die UUID auch nicht mehr. Soviel zu der Hintergrundgeschichte. Es ist richtig das ich in nautilus die Platten zusätzlich die Platten einzeln sehe was aber vor 7 Jahren auch schon so war. Und damals wie heute kann ich auf diese regulär so nicht zugreifen sondern nur auf den pdc Verbund. Die Spiegelung funktioniert tadellos die Daten sind konsistent. Ich wühle mich da mal gerne durch bei der Arch Geschichte man kann nur dazu lernen. Ich Danke Dir auf alle Fälle schon mal sehr und melde mich wenn ich mehr weis. Das kann aber etwas dauern da ich aktuell mich in mein eigenes System hacken muss. Bin gerade dabei Baculum zu konfigurieren. Das Problem ist trotz penible Einhaltung vom Manual komme ich nicht auf die Webseiten zum konfigurieren. Er frisst nicht das Kennwort oder den Benutzer was in der baculum.users als hash hinterlegt ist. Muss dann um überhaupt drauf kommen zu können in der /etc/apache2/sites-available bei den betreffenden Seiten quasi so schummeln # Require valid-user. Das ist aber ein ganz eigenes Thema wenn auch hoch spannend und wenn das erledigt ist wende ich mich diesem Problem hier wieder zu.

bis dahin Beste Grüße

aki
Beiträge: 83
Registriert: 02.02.2018 11:48:58

Re: beim Booten "a start job is running..."

Beitrag von aki » 27.02.2018 13:35:05

Hallo,

verstehe noch einer die Welt .....

Es geht durch die Änderung in der /etc/fstab von UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" /mnt/Backup ext4 defaults 0 2 nach UUID="4963ef0f-c4b8-4294-97f0-0ba593008031" /mnt/Backup ext4 defaults 0 0 . Ich habe jetzt mehrfach neu gestartet und jedes mal wurde der Verbund beim booten eingebunden.

Soweit ich das verstanden habe steht die 2 für eine Dateisystemprüfung beim booten sprich / sollte 1 haben und alle anderen die 2.
Somit habe ich dann die automatische Prüfung deaktiviert was mir nicht so wirklich zusagt. Kann mir wer sagen warum es mit Prüfung nicht geht aber ohne schon?

Es schaut im System dann so aus:

Code: Alles auswählen

lsblk -f
NAME               FSTYPE                        LABEL  UUID                                 MOUNTPOINT
sda                promise_fasttrack_raid_member                                             
├─sda1             ext4                          backup 4963ef0f-c4b8-4294-97f0-0ba593008031 
└─pdc_gijeeead                                                                               
  └─pdc_gijeeead1  ext4                          backup 4963ef0f-c4b8-4294-97f0-0ba593008031 /mnt/Backup
sdb                promise_fasttrack_raid_member                                             
├─sdb1             ext4                          backup 4963ef0f-c4b8-4294-97f0-0ba593008031 
└─pdc_gijeeead                                                                               
  └─pdc_gijeeead1  ext4                          backup 4963ef0f-c4b8-4294-97f0-0ba593008031 /mnt/Backup
sdc                promise_fasttrack_raid_member                                             
├─sdc1             ext4                                 dec4fa5e-97ba-40f1-9382-59c4485cfc39 
├─sdc2             promise_fasttrack_raid_member                                             
├─sdc5             swap                                 ab519919-f5c9-42eb-b71f-77ca31133458 
└─pdc_baeahcegi                                                                              
  ├─pdc_baeahcegi1 ext4                                 dec4fa5e-97ba-40f1-9382-59c4485cfc39 /
  └─pdc_baeahcegi5 swap                                 ab519919-f5c9-42eb-b71f-77ca31133458 [SWAP]
sdd                promise_fasttrack_raid_member                                             
├─sdd1             ext4                                 dec4fa5e-97ba-40f1-9382-59c4485cfc39 
├─sdd2             promise_fasttrack_raid_member                                             
├─sdd5             swap                                 ab519919-f5c9-42eb-b71f-77ca31133458 
└─pdc_baeahcegi                                                                              
  ├─pdc_baeahcegi1 ext4                                 dec4fa5e-97ba-40f1-9382-59c4485cfc39 /
  └─pdc_baeahcegi5 swap                                 ab519919-f5c9-42eb-b71f-77ca31133458 [SWAP]
sr0                                 

Code: Alles auswählen

dmraid -s
*** Active Set
name   : pdc_gijeeead
size   : 3906249984
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0
*** Active Set
name   : pdc_baeahcegi
size   : 1953124992
stride : 128
type   : mirror
status : ok
subsets: 0
devs   : 2
spares : 0       


Beste Grüße

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: beim Booten "a start job is running..."

Beitrag von NAB » 28.02.2018 00:32:03

aki hat geschrieben: ↑ zum Beitrag ↑
21.02.2018 12:11:59
Und aus der alten Zeit habe ich das auch mit dem DMRAID denn ohne hast damals in die Röhre geschaut.
Auch vor 7 Jahren hättest du schon dein Mainboard von Raid auf AHCI umschalten können und ein ganz normales Raid mit mdadm und funktionierenden UUIDs aufbauen können.

UUIDs sind bei dir mehrfach vergeben und daher unzuverlässig. Was passiert, wenn du eine UUID in der fstab angibst, kann man daher nur raten. Vielleicht hat fsck vorher "die falsche" UUID genommen und da du es jetzt ausgeschaltet hast, tut fsck jetzt halt gar nichts mehr.

Nebenbei ... Red Hat schmeißt dmraid ab RHEL 8 aus dem Programm:
https://bugzilla.redhat.com/show_bug.cgi?id=1489587
An neuere Kernel wird es dann wohl niemand mehr anpassen.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Antworten