Langsamer Start - "Ein Startjob für dev-disk-by wird ausgeführt ..."

Ich kann mich nicht erinnern, wann das Problem aufgetreten ist, aber es ist wahrscheinlich, dass ich mein VMWare Ubuntu-Image auf eine externe SSD verschoben habe, damit ich das Betriebssystem auf jedem meiner PCs verwenden kann. Bei Google gibt es nicht viele Links zu diesem Thema, aber diejenigen, über die anscheinend gesprochen wird fstab. Beispiel: Langsamer Start - Was ist "Ein Startjob für dev-disk-by wird ausgeführt ..."? - OpenSUSE-Forum .

Erwähnt, dass die Swap-Partition gelöscht und erneut erstellt werden muss.

Ich kann versuchen, dies mit Gparted zu tun, aber mein Hauptanliegen ist es, mein aktuelles Setup in Ubuntu zu verlieren, da ich nicht ganz sicher bin, was passieren wird, wenn ich mit Swap herumspiele, wie im Thread vorgeschlagen. Kann jemand helfen?

Führen Sie die folgenden Schritte aus, wenn Sie "einen Startjob gestartet von dev-disk-by .." gefolgt von einer Verzögerung von 90 Sekunden bei jedem Start erhalten:

1. Installieren Sie gparted über das Software Center
2. Öffnen Sie gparted und sehen Sie, welche Partitionen Ubuntu aktuell verwendet

3. Bearbeiten Sie die fstab-Datei in der folgenden Zeile.

   sudo -H gedit /etc/fstab
   

4. Suchen Sie das Gerät, das Sie gerade nicht verwenden

5. Fügen Sie #am Anfang dieser Zeile ein und ein Leerzeichen ein, und kommentieren Sie es aus.

6. Zurücksetzen, hoffe, es funktioniert für Sie!

Anscheinend lag das Problem daran, dass fstab zwar einen Eintrag für einen Tausch hatte, aber eigentlich keinen. Ich habe GParted verwendet, um die Größe der Partition zu ändern, und einen neuen Swap erstellt. Ich habe dann die UUID in die fstab-Datei kopiert ...

1. Ich habe jetzt Swap
2. Und der Bootvorgang dauert nur wenige Sekunden - 90+ Sekunden

Ich hatte das gleiche Problem, nachdem ich die Größe meiner primären Partition auf meiner VM geändert hatte, da gparted live mich dazu gezwungen hat, meinen Swap zu löschen und neu zu initialisieren, um dies zu tun. Dadurch wurde eine neue UUID festgelegt, die nicht mit der fstab-Datei übereinstimmt.

Um das Problem zu vermeiden, /etc/fstabkönnen Sie entweder in

• Ersetzen Sie die Swap-UUID durch die neue (führen Sie sie aus sudo blkid, um sie zu finden), nachdem Sie die Größe der primären Partition geändert haben.

• Oder kommentieren Sie die Auslagerungspartition vor (oder nach) der Größenänderung der primären Partition aus.

Ich würde das erstere empfehlen, da es die Art und Weise ist, wie das Betriebssystem eingerichtet werden soll.

In meinem Fall hatte ich zuvor verschlüsselten Swap verwendet und den Startjob erwähnt /dev/mapper/cryptswap1. Um das Problem zu lösen, musste ich /etc/crypttabzusätzlich zu den in der Antwort von William MacDonald beschriebenen Schritten auch die Datei entfernen .

Wenn Sie mit gparted die Größe von Partitionen ändern oder Partitionen löschen, müssen Sie häufig eine neue Swap-Partition erstellen.

Es ist dann notwendig, den Swap über gparted nach dessen Erstellung zu aktivieren (es gibt den Befehl "Swap aktivieren").

Darüber hinaus müssen Sie die neue UUID in / etc / fstab kopieren, um sie zu mounten. Andernfalls versucht das Betriebssystem, sie beim Booten zu finden, aber vergebens, da die fstab-Datei die UUID enthält, die sich auf den alten Swap bezieht. Gparted liefert die Informationen für die UUID, Sie können sie jedoch problemlos im Terminal ausführen:

sudo blkid

es zu finden.

Ich hatte das gleiche Problem beim Booten.

In meiner /etc/fstabDatei, meine Partitionen wo definiert /dev/sda1, /dev/sda2usw., aber beim Booten erschien mehrmals die Meldung „ Ein Start Auftrag läuft für dev-SDX “ ( „x“ definiert , welche Einheit oder Partition betroffen war).

Um /dev/sdxdas Problem zu lösen, habe ich den Wert von durch die UUID der Partition geändert . Um die UUID zu sehen, starten Sie das Terminal lsblk -f. Kopieren Sie dann die UUID der betroffenen Partition und schreiben Sie sie in eine /etc/fstabDatei. Ersetzen Sie sie /dev/sdaxwie folgt: /dev/sda1ändert sich zu UUID=xxxxxxxxxxxxxxxxxx.

Es hat bei mir geklappt, ich hoffe diese Info ist hilfreich.

Mein Startvorgang wurde verlangsamt, weil ich mein Laufwerk ausgetauscht habe und die UUID nicht übereinstimmte. Dies führte dazu, dass Ubuntu beim Booten einen Scan durchführte.

Ich tausche häufig die Laufwerke. Wenn sich Ihre Reittiere immer an derselben Stelle befinden (wie meine), können Sie einfach die UUID entfernen und den direkten Pfad angeben, um zu verhindern, dass ein Scanfehler auftritt ...

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/sda1 /               ext4    errors=remount-ro 0       1
/dev/sda2 none            swap    sw              0       0

Hauptsituation:

Bereits im Detail beantwortet ... (Sie müssen die UUID unter diesen Dateien überprüfen)

/etc/crypttab 
/etc/fstab
/etc/grub.d/40_custom 
/boot/grub2/grub.cfg

Alternative Situation I - Udev:

Dies könnte verursacht werden durch udev , wenn Sie eine haben Regel Skript unter , /etc/udev/rules.d/dass nicht beim Booten soll laufen, wenn das Skript fehlschlagen wird , dass fstab Schritt für immer weitergehen machen, einfach bearbeiten Ihr Skript an Ihre Bedürfnisse anzupassen oder zu löschen.

Alternative Situation II - Crypted Dev:

Verschlüsselte Partitionen kann verwirrend sein , weil die Hauptpartition eine UUID haben und das zugeordnete Decrypted eine haben eine andere UUID unterscheidet sich von der Haupt eine für eine einzelne Partition haben sie in anderen Ort definiert werden etc/crypttabund/etc/fstab

# lsblk -o name,uuid,mountpoint
├─sda2                         727fa348-8804-4773-ae3d-f3e176d12dac
│ └─sda2_crypt (dm-0)          P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi

Echte UUID muss in angegeben werden etc/crypttab

# cat /etc/crypttab
sda2_crypt  UUID=727fa348-8804-4773-ae3d-f3e176d12dac  none  luks

Virtuelle UUID muss bei sein /etc/fstab

# cat /etc/fstab
UUID=P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi / ext4 defaults,errors=remount-ro 0 1

Alternative Situation III - Ghost Dev:

Ein Gerät, das so eingerichtet ist, dass es beim Start bereitgestellt wird, jedoch nicht im System vorhanden ist oder wie ein USB-Laufwerk getrennt wird.

Testen Sie echte verbundene Geräte mit lsblk -o name,uuid,mountpointund bearbeiten Sie sie /etc/fstab, um nur das verbundene Gerät zu behalten, ODER lassen Sie das nicht verbundene Gerät dort, aber richten Sie sie so ein, dass sie beim Booten mit der Option ignoriert werden, noautound stellen Sie die Zeile so ein

UUID=BLA-BLA-BLA /mount ext4 option,noauto,option 0 0

Überprüfen der Systemprotokolle

journalctl -ab 

systemd-analyze blame

systemd-analyze critical-chain

systemctl status dev-mapper-crypt_sda2.device

systemctl status systemd-udev-settle.service

Überprüfen Sie nicht nur, /etc/fstaboder /etc/crypttabwie in den anderen Antworten erwähnt, auch, ob UUIDs von den Kernelparametern in stammen /etc/default/grub. Eine Zeit lang war ich sehr verwirrt von einem System, das /etc/fstabnur einen resume=…Kernel-Parameter in der GRUB-Konfiguration entdeckte.

Sie können das Warten überspringen und mit ' Ctrl+ c' direkt zu Ihrem Anmeldebildschirm gehen und dann an der Lösung arbeiten. Manchmal wird das ewig so weitergehen, wenn nicht.

Ich weiß, das ist alt, aber ich bin auf dieses Problem gestoßen, die gleiche Fehlermeldung beim Klonen einer Installation mit rsync. Da fstab keine Fehler enthält, wurde das Problem nach dem manuellen Aktualisieren der initrdfs behoben. um das zu erreichen,

1. Booten Sie die Maschine in eine funktionierende Installation (Multiboot-Maschine, sonst Live-CD)

2. Hängen Sie die Root-Partition des Systems mit dem Problem ein

3. mount dev, sys und proc wie bei einem funktionierenden chroot

4. chroot in die Wurzel des Dateisystems

5. Führen Sie mkinitrd aus

6. chroot beenden und neu starten.