Lanzaam opstarten

[PKing]

Alhoewel het niet superstorend is, start mijn machine met Xubuntu 18.04 vrij langzaam op. Ongeveer een minuut en soms zelfs langer.
Misschien kunnen jullie meer vinden dan dat ik heb kunnen vinden
Gegevens machine:
CPU: AMD 1055
CPU: ATI 5700
MEM: 8GB
SSD: Kingston 120GB
2e Interne HDD 2 partities 1x Nfts 500GB 1x EXT4 100GB (voor snapshots Timeshift)

De systemd analayze:

pking@pking:~$ systemd-analyze critical
Unknown operation critical.
pking@pking:~$ systemd-analyze blame
         29.405s udisks2.service
         24.737s apt-daily.service
         20.176s apt-daily-upgrade.service
         15.339s fstrim.service
          8.209s snapd.service
          5.983s dev-sda1.device
          4.713s NetworkManager-wait-online.service
          4.655s lightdm.service
          4.654s plymouth-quit-wait.service
          4.014s networkd-dispatcher.service
          3.536s NetworkManager.service
          3.395s dev-loop9.device
          3.393s dev-loop5.device
          3.393s dev-loop6.device
          3.393s dev-loop8.device
          3.392s dev-loop7.device
          3.391s dev-loop10.device
          3.337s dev-loop11.device
          3.332s dev-loop13.device
          3.330s dev-loop12.device
          3.307s dev-loop2.device
          3.306s dev-loop3.device
          3.306s dev-loop0.device
lines 1-23

[Ron]

Wat is langzaam, duurt het lang voordat grub start, of is het de tijd van grub naar het starten?

[swake]

Ik denk maar even mee en het misschien te wijten is aan Timeshift .
Er word door velen het woord backup geplakt op de functie van Timeshift . Timeshift maakt momentopnames (snapshots) van je systeem , wat een systeemkopie maken is . Maar met timeshift kun je ook backups maken . Backups maak je van je belangrijke data .
Die interne schijf waar timeshift de snapshots bewaart is ook nog een gewone HD waarvan de schrijfsnelheid veel trager is dan bij een SSD .
Ik kan verkeerd zitten maar denk in die richting .

[PKing]

Ik zie nooit een grub, behalve wanneer ik shift gebruik, of de computer verkeerd afgesloten is.
Wat betreft langzaam...ik vind een minuut of meer langzaam met een SSD.
Wat betreft Timeshift, die maakt geen snapshot bij of net na booten, dat kun je gewoon instellen.
Toen ik timeshift nog gewoon op de SSD liet werken had ik hetzelfde probleem.

De oude Acer 5310 van mijn eega start op in rond de 30 seconden, met hetzelfde OS en dezelfde SSD.

[Ron]

Wanneer het lang duurt, voordat grub geladen is, kan het zijn, dat de swap partitie opnieuw is geformatteerd.
Wanneer het lang duurt, voordat *buntu geladen is, dan kan het ook een hardware probleem, of een configuratie probleem zijn, vandaar mijn vraag.

[pederoco]

Geef eens het antwoord op:

Code: [Selecteer]

sudo blkidEens kijken of er nog een aparte swappartitie aanwezig is.
Wat dus niet zou moeten bij *ubuntu 18

[swake]

Wanneer het lang duurt, voordat grub geladen is, kan het zijn, dat de swap partitie opnieuw is geformatteerd.

Of werd vergroot , dan gaat het systeem ook trager booten .

[PKing]

Zo te zien geen swap partitie, dat is trouwens volgens mij bij Xubuntu 18.04 toch een file i.p.v. een partitie?

pking@pking:~$ sudo blkid
[sudo] wachtwoord voor pking:
/dev/sda1: UUID="73940d2a-0642-4c1b-8bed-3f4a9de430af" TYPE="ext4" PARTUUID="e5df18ab-01"
/dev/sdb1: UUID="1EE6CCDB1153BC6A" TYPE="ntfs" PTTYPE="dos" PARTUUID="b544d576-01"
/dev/sdb2: LABEL="Backup" UUID="be4bd33b-c6f0-4552-b754-0b8395c1799f" TYPE="ext4" PARTUUID="b544d576-02"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
pking@pking:~$

[DarkEra]

Klopt, vanaf 18.04 is er enkel nog een swap file waar gebruik van wordt gemaakt en geen swap partitie. Tenzij je natuurlijk zelf manueel partities aanmaakt.

[swake]

Dat zijn inderdaad files die worden gemaakt bij snapshots .

Wat betreft Timeshift, die maakt geen snapshot bij of net na booten, dat kun je gewoon instellen.

Dat klopt , kijk daarom eens of je ze per ongeluk niet verkeerd ingesteld hebt .

[pederoco]

Die /dev/loop die vermeld worden zijn snap pakketten die je geïnstalleerd hebt.
Misschien dat die het probleem geven.
Zie: https://askubuntu.com/questions/1047456/why-are-all-snaps-being-mounted-and-listed-as-block-devices-or-partitions-for-ub

Misschien deze eens verwijderen en zien of dit het probleem is/was.

[Nero]

Wanneer het lang duurt, voordat grub geladen is, kan het zijn, dat de swap partitie opnieuw is geformatteerd.

Grub heeft geen weet van swap partities, dat speelt nog niet bij het initële laden. Ook de systemd-analyze begint maar nadat grub z'n werk heeft gedaan.
Het trage laden van grub kan enkel door de UEFI/BIOS of door meerdere leespogingen op het boot medium.
Als er externe opslag aan hangt kan hetv zijn dat UEFI/BIOS eerst daar gaat zoeken naar een bootloader. In dat geval is de opstartvolgorde verkeerd ingesteld.

[PKing]

Snap pakketten verwijderd op 1 spel na, opstartvolgorde is goed. Geen verbetering.
Ik laat het topic nog even open om te zien of er iemand nog een goed idee heeft, een verse installatie heb ik nog even geen behoefte aan

[Ron]

Wanneer het lang duurt, voordat grub geladen is, kan het zijn, dat de swap partitie opnieuw is geformatteerd.

Grub heeft geen weet van swap partities, dat speelt nog niet bij het initële laden.

Even een regel uit mijn /boot/grub/grub.cfg:
gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-5.3.0-42-generic-recovery-cc55de61-a7c2-41e6-a5bc-a42de715fcef
Dit soort verwijzingen komen meerdere malen voor in deze file...........

[Nero]

Dit soort verwijzingen komen meerdere malen voor in deze file...

Maar dan wel nadat de selectie is gemaakt, ttz ergens in een menuentry. Op dat ogenblik is grub geladen, maar is nog geen selectie in uitvoering. Deze verwijzingen worden pas actief na de selectie.

[rive gauche]

Met dit krijg je ostarttijd te zien

Code: [Selecteer]

systemd-analyze
met dit veel meer info

Code: [Selecteer]

systemd-analyze blame

Mvg

[Ron]

Dit soort verwijzingen komen meerdere malen voor in deze file...

Maar dan wel nadat de selectie is gemaakt, ttz ergens in een menuentry. Op dat ogenblik is grub geladen, maar is nog geen selectie in uitvoering. Deze verwijzingen worden pas actief na de selectie.

Nee dus ........
ik had (eergisteren) Debian op een andere partitie geïnstalleerd, die heeft de rotte eigenschap om de swappartitie te formatteren, terwijl dit niet was aangegeven!
Alle andere installaties bleven daarna 2 minuten wachten op de swap, dus grub weer op en oudere installatie gezet.
Het laten zien van het grub-menu duurde echter ruim één minuut, na het aanpassen van alle verwijzingen naar de juiste blok-id's in grub.cfg werkte het weer als vanouds.
Nu is mijn systeem wel een octal-boot systeem (2x Xuby 18.04, 2x Xuby 20.04, Peppermint 10, SolidX 10, Debian test en Mint XFCE 19.3).
Je zou zeggen, dat de swap partitie niet gebruikt wordt door grub, maar de blok-id komt meerdere malen voor in grub.cfg...........

[h2o]

Ik had (eergisteren) Debian op een andere partitie geïnstalleerd, die heeft de rotte eigenschap om de swappartitie te formatteren, terwijl dit niet was aangegeven!

Bij het installeren van Debian gebruik ik nooit een swappartitie. Als Debian bij de installatie hierom gaat zeuren, gewoon negeren en verder gaan met de installatie. Ik gebuik overigens altijd de expert installatie.

Naderhand, als Debian staat geïnstalleerd maak ik een swap file aan en zorg ervoor dat die in /etc/fstab staat vermeld:

fallocate -l 1G /swapfile
dd if=/dev/zero of=/swapfile bs=1024 count=1048576
chmod 600 /swapfile
mkswap /swapfile
#cp swapfile /
echo /swapfile  swap  swap  default  0  0 >> /etc/fstab
reboot

Een gedeelte van mijn installatie scriptje.
Dat is denk ik ook voor andere distributies mogelijk.

[Ron]

Bij het installeren van Debian gebruik ik nooit een swappartitie.

Die partitie was reeds op de HD, vorige versies gaven aan, dat er geformatteerd ging worden, maar bij deze was dat niet aangevinkt.
Laten we verder Ontopic blijven, we dwalen af.

[poj]

Ik ben benieuwd of er een oplossing is gevonden voor het langzaam opstarten. Zelf heb ik de volgende tijd:

Code: [Selecteer]

systemd-analyze
Startup finished in 18.709s (firmware) + 4.028s (loader) + 18.126s (kernel) + 20.797s (userspace) = 1min 1.661s
graphical.target reached after 7.626s in userspace

systemd-analyze blame
         11.117s apt-daily.service
          4.443s NetworkManager-wait-online.service
          3.702s motd-news.service
          2.281s apt-daily-upgrade.service
          1.798s dev-sda2.device
          1.733s fstrim.service
          1.225s systemd-journal-flush.service
          1.205s dev-loop0.device
          1.202s dev-loop3.device
          1.185s dev-loop5.device
          1.178s dev-loop4.device
          1.126s dev-loop1.device
          1.122s dev-loop2.device
           687ms ufw.service
           644ms snapd.service
           526ms systemd-hwdb-update.service
           480ms systemd-udevd.service
           371ms udisks2.service
           306ms systemd-logind.service
etc ...

Dus ook iets meer dan een minuut, waarbij ik - grotendeels - tegen een zwart scherm kijk  Ik heb ook een SSD.

Ik zie bij rive-gauche minder dan een halve minuut. ...

Bij "snap list" krijg ik het volgende:

Code: [Selecteer]

snap list
2020/03/05 15:24:07.952377 main.go:154: description of sign's "k" is lowercase: "naam van de te gebruiken sleutel, gebruik anders de standaardsleutel"
Name    Version     Rev   Tracking  Publisher   Notes
core18  20200124    1668  stable    canonical✓  base
noson   4.2.6.snap  303   stable    janbar      -
snapd   2.43.3      6434  stable    canonical✓  snapd

Vraag 1:
@PKing en anderen: Ik lees dat je "snaps" zou moeten verwijderen, maar ik kom niet helemaal goed uit de Engelse handleiding en wil mijn computer niet stuk maken. Is er iemand die de stappen hier in het Nederlands kan herhalen?

Als ik de opstart van PKing en rive-gauche vergelijk met de mijne dan zie dat de daily update een aanzienlijke tijd neemt. Bij PKing ook nog eens een proces dat "udisks2.service" heet (bijna een halve minuut).

Vraag 2: daily update niet daily zetten zou dus verbetering moeten geven?
Vraag 3: Wat doet "udisks2.service" en zou PKing, dat niet kunnen uitzetten?

[swake]

Ik ben benieuwd of er een oplossing is gevonden voor het langzaam opstarten. Zelf heb ik de volgende tijd:

Nog eentje met zoveel loop's wat allemaal systeemkopies zijn, die automatisch aangemaakt worden .

[swake]

Vraag 2: daily update niet daily zetten zou dus verbetering moeten geven?
Vraag 3: Wat doet "udisks2.service" en zou PKing, dat niet kunnen uitzetten?

Antwoord op vraag2 : dagelijks controleren op updates:
Dit is een keuze die je ook op wekelijks of maandelijks kan instellen

Antwoord op vraag 3:
Schijfstations/partities  automatisch aankoppelen

[poj]

@swake: dank je. Uitzetten van de automatische updates halveert inderdaad bij mij de opstarttijd.

die udisk2.service heb ik ook, maar doet er slechts 428ms over, heel wat anders dan bij PKing.

Hoe die loops uitzetten was nog een vraag?

[PKing]

Lijkt er toch op dat de tweede interne HDD waarschijnlijk het meeste tijd vraagt tijdens opstarten.
Mijn fstab file lijkt er verder goed uit te zien, ik ga eens testen zonder tweede disk.

[poj]

@PKing: Jij had toch die loops er uit gegooid? Hoe heb je dat gedaan?