Vraag Slow boot - "een startjob wordt uitgevoerd voor dev-disk-by ..."


Ik kan me niet herinneren wanneer het probleem begon op te lossen, maar het is waarschijnlijk dat ik mijn VMWare Ubuntu-afbeelding naar een externe SSD heb verplaatst, zodat ik het besturingssysteem op een van mijn pc's kan gebruiken. Er zijn niet veel links op Google over het probleem, maar degenen die lijken te praten over fstab. Bijvoorbeeld.

Vermeldingen die de swappartitie moeten verwijderen en opnieuw moeten maken.

Ik kan dit proberen met Gparted, maar mijn grootste zorg is het verliezen van mijn huidige set-up in Ubuntu, omdat ik niet helemaal zeker weet wat er zal gebeuren als ik rotzooi met swap zoals voorgesteld in de thread. Iedereen die kan helpen?

screenshot


75
2017-12-18 20:45


oorsprong


Misschien wil je je SSD klonen en dan kun je jezelf knock-out doen :) (Try Clonezilla voor deze) - Grammargeek
Hah ja, ik denk dat ik dat kan doen. Ik wacht tot ik terug ben van de vakantie, zodat ik het kan verplaatsen naar iets waar ik meer ruimte voor heb - cpd1
Uiteindelijk heb ik dit opgelost. Ik denk niet dat er ooit een ruil is geweest als ik door Gparted ga. Ik heb er uiteindelijk een gemaakt en de invoer in fstab gewijzigd. Dat werkte en geen 90 seconden meer opstarten - cpd1
als je je eigen probleem hebt opgelost, maak je eigen antwoord en klik je op het vinkje om het als opgelost te markeren :) - Grammargeek
Klinkt logisch ... ik heb het toegevoegd - cpd1


antwoorden:


Als u "een startjob gestart door dev-disk-by .." krijgt gevolgd door een vertraging van 90 seconden tijdens elke opstartprocedure, voert u de volgende stappen uit:

  1. Installeer gparted met behulp van het Software Center
  2. Open Gparted en zie welke partities Ubuntu momenteel gebruikt
  3. Bewerk het fstab-bestand met behulp van de onderstaande regel.

    sudo -H gedit /etc/fstab
    
  4. Zoek het apparaat dat u momenteel niet gebruikt

  5. Plaats een # en een spatie aan het begin van die regel geeft commentaar.

  6. Reset, hoop dat het voor u werkt!


81
2018-04-04 05:06



Stap voor stap instructies helpen iedereen! bedankt! - John Hall
Ik heb de jouwe getagged als het antwoord, omdat je de stappen hebt gegeven - cpd1
+1 ... voor degenen die het niet kunnen vinden /etc/fstab, je kunt het ook bekijken in /etc/crypttab - dat was mijn zaak. - meta
Als het een blok-ID is dat is gewijzigd, in plaats van er commentaar op te geven, geef ik er de voorkeur aan om het apparaat-ID te corrigeren. Gebruik lsblk -f om te zien welk apparaat aan welk ID is gekoppeld en vervang het ID. - user1708042
Wat voor mij werkte was om stap 4 te veranderen in: "Kopieer de UUID gevonden in gparted voor het apparaat dat de vertraging veroorzaakt bij het opstarten", en stap 5 naar: "Vervang het waar het apparaat is gevonden in het fstab-bestand". Soms wanneer u van verplaatsingspartities verandert, veranderen de UUID's en dat is de oorzaak van het probleem. U hoeft alleen de nieuwe UUID voor de gewijzigde partitie te repareren. - m4l490n


Lijkt erop dat het probleem te wijten was aan het feit dat fstab weliswaar een ruil had, maar dat er eigenlijk geen was. Ik heb GParted gebruikt om de grootte van de partitie te wijzigen en een nieuwe swap te maken. Ik heb de UUID vervolgens in het fstab-bestand gekopieerd ...

  1. Ik heb nu ruil
  2. En opstarten is binnen seconden seconden versus 90+ seconden

28
2017-12-31 01:56



Ik heb de grootte van mijn hoofdpartitie gewijzigd (swap verwijderen / opnieuw maken) en ben tegen dit probleem aangelopen. Ik heb 'sudo blkid' gebruikt om apparaten aan de hand van UUID te vermelden en vervolgens de nieuwe UUID in / etc / fstab te gebruiken. - Brad Goss
@BradGoss bedankt dat lost het op! - JREAM


Ik had hetzelfde probleem nadat ik mijn primaire partitie op mijn VM sindsdien had aangepast ging live dwong me om mijn swap te verwijderen en opnieuw te initialiseren om dit te doen. Dat zorgde ervoor dat een nieuwe UUID werd ingesteld die niet overeenkwam met het fstab-bestand.

Om het probleem te voorkomen, in /etc/fstab je kan of

  • Vervang de UUID voor verwisseling door de nieuwe (run sudo blkid om het te vinden) na het wijzigen van de primaire partitie.

  • Of zet de swappartitie uit vóór (of na) het wijzigen van de primaire partitie.

Ik zou de eerste aanraden, omdat het de manier is waarop het besturingssysteem moet worden ingesteld.


21
2017-08-09 18:24



Dit is het juiste antwoord! Dank maatje. - CppChase
Heeft me ook geholpen na het verplaatsen van mijn swappartitie - Humpawumpa


In mijn geval had ik eerder gecodeerde swap gebruikt en de startup-taak genoemd /dev/mapper/cryptswap1. Om het probleem op te lossen moest ik ook het bestand verwijderen /etc/crypttab, in aanvulling op de stappen beschreven in het antwoord van William MacDonald.


13
2017-09-28 11:40





Bij het vergroten of verkleinen van partities met gparted moet je vaak een nieuwe swappartitie maken.

Het is dan noodzakelijk om de swap via gparted te activeren nadat deze is aangemaakt (er is het commando "Activeer swap").

Verder moet je de nieuwe UUID kopiëren naar / etc / fstab om deze te mounten, anders zal het besturingssysteem bij het opstarten proberen het te vinden, maar tevergeefs omdat het fstab-bestand de UUID bevat die verwijst naar de oude swap. Gparted levert de informatie voor de UUID, maar u kunt eenvoudig in de terminal werken:

sudo blkid

om het te vinden.


3
2017-09-01 17:09





Ik had hetzelfde probleem bij het opstarten.

In mijn /etc/fstab bestand, mijn partities zijn gedefinieerd als /dev/sda1, /dev/sda2, enz., maar tijdens het booten, verscheen verschillende keren het bericht "Er wordt een startjob uitgevoerd voor dev-sdx"(" x "definieert welke eenheid of partitie werd beïnvloed).

Om het op te lossen, veranderde ik de waarde van /dev/sdx door de UUID van de partitie. Om de UUID te zien, vanaf terminal run lsblk -f. Kopieer vervolgens de UUID van de betreffende partitie en schrijf deze op /etc/fstab bestand, vervangen /dev/sdax als volgt: /dev/sda1 veranderd naar UUID=xxxxxxxxxxxxxxxxxx.

Het werkte voor mij, ik hoop dat deze informatie nuttig is.


2
2018-04-23 09:30



Ja. Dit is precies het probleem dat UUID's oplossen. Het systeem koppelt elke partitie met dat ID aan, ongeacht op welk apparaat het is of waar de partitie zich bevindt. Met het nadeel dat je nodig hebt om de UUID te veranderen wanneer je de partitie vernietigt / maakt of een nieuwe schijf installeert. En het dupliceren van een partitie (gparted copy / paste) zal een kopie maken met dezelfde UUID, wat problemen kan veroorzaken als het origineel en de kopie tegelijkertijd online zijn. Voor de meeste mensen is dit OK, maar u moet dit in gedachten houden bij het klonen / vervangen van schijven. - David C.


Mijn boot werd vertraagd omdat ik mijn schijf had geruild en de UUID niet overeenkwam. Dit veroorzaakte dat Ubuntu een scan deed tijdens het opstarten.

Ik wissel vaak rondjes rond. Als je mounts zich altijd op dezelfde plek bevinden (zoals de mijne), kun je gewoon de UUID verwijderen en het directe pad plaatsen om te voorkomen dat die scanfout optreedt ...

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

1
2018-01-25 18:43



Hoe zou deze suggestie het opstarten versnellen? Een referentie? - Mostafa Ahangarha
Ik beantwoordde zijn foutvraag die de trage start veroorzaakte. Ik heb mijn antwoord duidelijker gemaakt. - Dan
Ja, montage op apparaatnaam vermijdt het probleem, maar het creëert ook het probleem dat UUID's (en volumelabels) moesten oplossen - dat het koppelen van een schijf aan verschillende plaatsen (bijv. Van een SATA-interface naar een andere) de apparaatnaam zal veranderen, je mounts breken. U moet beslissen welk probleem gemakkelijker is om mee te leven, maar vergeet niet uw beslissing te onthouden, want het kan erg frustrerend zijn als er een probleem optreedt omdat u het bent vergeten. - David C.


U kunt het wachten overslaan en direct naar uw inlogscherm gaan met behulp van 'Ctrl+cen werk aan de oplossing. Soms zal dit voor altijd blijven bestaan, zo niet.


1
2018-02-27 11:55



Is dat letterlijk Ctrl, de plus-toets en c? - muru
Ja, dat is het :) - Ramon Suarez


Naast het controleren /etc/fstab of /etc/crypttab zoals vermeld in de andere antwoorden, controleer ook op UUID's afkomstig van de kernelparameters in /etc/default/grub. Een tijdje was ik erg in de war door een systeem dat een perfect cromulent had /etc/fstab alleen om een ​​te ontdekken resume=… kernelparameter in de GRUB-configuratie.


0
2017-07-03 14:03



Dit hielp me het probleem op te lossen. Mijn / etc / fstab was prima. Vervolgens, aanvullend op /etc/default/grub Ik moest ook wijzigingen aanbrengen in /boot/efi/EFI/fedora/grub.cfg. De linux "resume = UUID = ..." -parameter is verouderd nadat ik de swap-partitie handmatig heb gewijzigd. - Stphane