A start job is running - Bij het opstarten daarna 1m30 wachten.

[L.P.]

Ik krijg bij het opstarten A start job is running ........ en daarna gaat de pc voor 1m30 niet verder.
Ik heb 2 fotos in de bijlage bijgevoegd van de error.

[Paul Matthijsse]

Hallo, bekend probleem zo te zien (diverse distro's hebben het over precies 1m30s hangen/wachten), lijkt op een foute indeling van je /etc/fstab, in veel gevallen is er een swap-partitie teveel aangemaakt, kijk daar eerst eens naar.

[h2o]

Zo te zien heeft jouw systeem een probleem met de inhoud van /etc/fstab. Zeer waarschijnlijk met de swappartitie die niet gevonden wordt. Als je weet wat jouw swapppartitie is (bijv. /dev/sda4) dan kun je in fstab dat aanpassen:

# swap was on /dev/sda3 during installation
#UUID=f11b6341-0e0d-4a31-b58d-71590208a5b7 none            swap    sw              0       0
/dev/sda3   none      swap   0     0

Mijn situatie. Je ziet dat oorspronkelijk ook met UUIDf11enz. is gewerkt. Dat heb ik met een # uitgeschakeld en gewoon ouderwets met /dev/sda3 ben gaan werken.

Het bestand /etc/fstab muteren met bijv.

Code: [Selecteer]

sudo nano /etc/fstabI.p.v. nano kun je ook gedit, mousepad of een andere editor gebruiken.

[h2o]

Hallo, bekend probleem zo te zien (diverse distro's hebben het over precies 1m30s hangen/wachten), lijkt op een foute indeling van je /etc/fstab, in veel gevallen is er een swap-partitie teveel aangemaakt, kijk daar eerst eens naar.

Klopt, vaak als je meerdere distributies draait met een gemeenschappelijke swappartitie. Door het te forceren met /dev/sdxx los je het meestal wel op.

[L.P.]

Bedankt ga vanavond kijken

[L.P.]

Dit is mijn fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=020d162f-d91a-4e33-9b48-359993c82b50 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=6A35-4EFD  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
#
UUID=5ec94642-bf28-488e-ba05-306240524f5a /mnt/DATA ext4 defaults,x-gvfs-show 0 2

Wat moet ik veranderen

[h2o]

Dit is mijn fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=020d162f-d91a-4e33-9b48-359993c82b50 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=6A35-4EFD  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
#
UUID=5ec94642-bf28-488e-ba05-306240524f5a /mnt/DATA ext4 defaults,x-gvfs-show 0 2

Deze regel:
# swap was on /dev/sdb3 during installation
UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
moet worden:
# swap was on /dev/sdb3 during installation
#UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
/dev/sdb3  none            swap    sw              0       0

[Ron]

in veel gevallen is er een swap-partitie teveel aangemaakt, kijk daar eerst eens naar.

Dat mag gewoon hoor, bij mij heeft iedere HD een eigen swap-partitie, met 2 HD's heb je 2 swap-partities .........

[Paul Matthijsse]

Ron, misschien ja, maar ik roep ook maar gewoon wat ik elders lees en dat is precies dat een dubbele swap-partitie voor twee distro's dit '1m30s'-probleem veroorzaakt.

[peer]

als ik het goed begrijp dan ontstaat het 'blijven hangen' probleem doordat de UUID van de swap niet herkend wordt.
Je kunt met bv. Gparted kijken wat de UUID van de swap=partitie is en deze vergelijken met wat in het bestand fstab staat. Dit moet hetzelfde zijn.

ik heb zowel de situatie dat ik meerdere os heb met één gemeenschappelijk swap partitie. Dan is alles op één disk geïnstalleerd als de situatie met meerdere os met elke eigen disk met daarop een eigen swap partitie.

de 1m30 wachttijd komt zowel bij starten als bij afsluiten voor als een taak niet goed loopt. Ik draai linux neon en deze had 90 s nodig bij het afsluiten omdat er een taak bleef doorlopen. De 90 seconden staan in het configuatiebestand van systemd (/etc/systemd/systed.conf):
DefaultTimeoutStartSec=90s
DefaultTimeoutStopSec=90s
 

[h2o]

als ik het goed begrijp dan ontstaat het 'blijven hangen' probleem doordat de UUID van de swap niet herkend wordt.
Je kunt met bv. Gparted kijken wat de UUID van de swap=partitie is en deze vergelijken met wat in het bestand fstab staat. Dit moet hetzelfde zijn.

ik heb zowel de situatie dat ik meerdere os heb met één gemeenschappelijk swap partitie. Dan is alles op één disk geïnstalleerd als de situatie met meerdere os met elke eigen disk met daarop een eigen swap partitie.

Door de UUID van de swap partitie te vervangen door /dev/sdXX in de /etc/fstab van iedere distributie die je op je schijf hebt staan ondervang je dat. Die XX staat dan voor /dev/sda3, /dev/sdb5 afhankelijk van de locatie van je eigen swap partitie.
Na installatie van iedere distributie vervang in standaard die regel en laat daarna een

Code: [Selecteer]

sudo update-gruber achteraan volgen.

PS het kan best wezen dat UUID voordelen heeft, maar ik heb er een hekel aan en werk op mijn systeem met de /dev/sdXX methode. Ik houd liever zelf controle over mijn systemen. En zeker als ik meerdere distro's draai op één schijf.

[Ron]

Ik houd liever zelf controle over mijn systemen.
En zeker als ik meerdere distro's draai op één schijf.[/i]

Daar is iets voor te zeggen, wanneer een UUID niet klopt, dan krijg je vaak een melding, dat je een toets (M ?) moet indrukken, daar heb je op jouw manier geen last van.
Mijn fstab ziet er zo uit:

Code: [Selecteer]

#sda6 op SSD
UUID=a7840cab-0274-452f-b5c7-63589e14a989 /               ext4    noatime,errors=remount-ro 0       1
#Data op SDC3 HD
UUID=0E17DEC60A898DBB /media/ron/BTO_Data       ntfs    defaults,umask=007,gid=46 0       0
#################################################
# swap op sda10 SSD
UUID=fb70a787-a18b-48a2-baa8-0e61a84b8122 none            swap    sw              0       0
# swap op sdc2 HD
UUID=b4ec3bdd-acc6-430d-a8c4-4ec6fae372b8 none            swap    sw              0       0
Een opmerking hierbij is, dat de HD alleen /dev/sdc heet, wanneer de installatie (of andere) USB stick aangesloten is, in "rust" heet deze /dev/sdb.
Dit zou (mogelijk ?) problemen kunnen geven.............

[h2o]

Ik partitioneer alles op deze manier:
/dev/sda1  = /
/dev/sda2 = /home
/dev/sda3 = /swap
Bovenstaande allemaal primary partitions
De rest is logical dus...
/dev/sda5 = files
/dev/sda6 = ??
/dev/sda7 = ??

?? = eventuele extra partities voor andere distro's. Op /dev/sda5 staan de images die ik maak en bestanden zoals VDI bestanden van Virtualbox, iso bestanden enz.

Alle distro's gebruiken /dev/sda3 en staan als zodanig vermeld in /etc/fstab.
Dit partitie schema wordt op al mijn installaties toegepast, dus ook bij mijn 'klantjes' zodat ik desnoods telefonisch uit mijn hoofd support kan geven.

[L.P.]

Dit is mijn fstab

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb2 during installation
UUID=020d162f-d91a-4e33-9b48-359993c82b50 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sdb1 during installation
UUID=6A35-4EFD  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sdb3 during installation
UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
#
UUID=5ec94642-bf28-488e-ba05-306240524f5a /mnt/DATA ext4 defaults,x-gvfs-show 0 2

Deze regel:
# swap was on /dev/sdb3 during installation
UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
moet worden:
# swap was on /dev/sdb3 during installation
#UUID=16810c58-0005-4abe-9019-11f89db7435c none            swap    sw              0       0
/dev/sdb3  none            swap    sw              0       0

Ik heb dit verandert en het werkt weer goed, bedankt allemaal.
Ik heb begrepen dat dit met de swappartitiie te maken heeft maar wat is er nu precies verandert, kan iemand mij dat uitleggen dit om in de toekomst zelf de fout te kunnen herstellen

[h2o]

Vroegah (toen alles beter was...  ) werden de partities met /dev/sda1, /dev/sda2 enz. aangeduid.
Toen was er nog geen sprake van usb externe harde schijven enz. die automatisch aangekoppeld werden. Toen moest je alles met commando's als sudo mount -t /dev/sdb1 /mnt worden aangekoppeld.

Toen dergelijke hardware gemeengoed werd was de kans op fouten geworden. Er is toen besloten om met UUID's te werken. Iedere partitie heeft een unieke UUID code. Op zichzelf een goed systeem.

Maar er kunnen ook fouten worden gemaakt. Als GRUB niet de juiste UUID van (bijv. in jouw geval) van een (swap) partitie kan vinden, dan gaat die zoeken. Dat duurt dan ongeveer anderhalve minuut. Dergelijke fouten treden vaak op als er meerdere distributies op één harde schijf draaien. Iedere distributie maakt dan een nieuwe GRUB aan en dan kan het gebeuren dat de swap partitie van een andere distributie onklaar word gemaakt.

Door nu in het bestandje /etc/fstab jouw swap partitie geforceerd handmatig op /dev/sdb3 te zetten kan jouw GRUB meteen de swap partitie vinden. Je dwingt GRUB dus op die partitie voor swap te gebruiken.
Dat is ongeveer wat er aand e hand is.

[Nero]

De fout zit niet in GRUB maar in fstab.

Bij de standaard installatie van Linux met swap gaat de installer een eventueel bestaande swap partitie formatteren. Gevolg is een gewijzigde UUID van die swap partitie. Voorgaande installaties in een multiboot kennen enkel de oude UUID, waardoor het OS (met system-d) tijdens het opstarten blijft wachten tot de swap die in fstab staat aangekoppeld is.

Vervang je in fstab de UUID notatie door de /dev/sdX vorm dan mag die partitie een andere UUID krijgen zonder dat dit een gevolg heeft voor de instantie die deze swap wil gebruiken.

[peer]

duidelijk uitleg!

[L.P.]

Bedankt goede uitleg