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

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

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

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

Beitrag von aki » 28.02.2018 13:15:11

Hallo,
ich habe mich mal in Bezug auf ext4 und Maximum mount count -1 informiert. Von daher sehe ich meiner Änderung auf die automatische Prüfung mehr als gelassen entgegen. Von daher ist mein Thread als gelöst anzusehen.

Beste Grüße

Antworten