Manjaro booten duurt erg lang

[Limhes]

Mijn vraag
Sinds een (standaard) update lang geleden duurt het ineens enkele minuten voordat m'n systeem naar de desktop boot. (Na een clean install duurt het maar een fractie daarvan.) Tijdens booten is het scherm volledig zwart, maar lijkt het wel te knipperen (alsof het iets probeert te detecteren). Sinds die update heb ik ook het probleem dat wanneer de laptop op de batterij uitvalt, ik fysiek de batterij en de RTC moet losmaken van het moederbord om 'm uberhaupt weer aan te krijgen.
* Hoe debug ik een dergelijk bootprobleem?
* Enig idee wat dit zou kunnen zijn?

Relevante software en hardware die ik gebruik
Manjaro KDE op een Lenovo Thinkpad E15 (redelijk oud beestje), alles up-to-date, geen drivers geinstalleerd na install.

Wat ik al gevonden of geprobeerd heb
* Het standaard probleem met de sleep functie in Linux bij deze laptops lijkt niet relevant, want geen van die fixes werkt wanneer de laptop in slaap op batterij uitvalt.

[Room42]

Druk tijdens het bootscherm op escape om de actieve log te zien. Dan kun je wellicht zien of er iets niet soepel loopt. Soms hangt ie op een device/network/disk dat niet goed initieert.

Daarnaast kun je even 'quiet' en 'splash' uit de bootregel halen in Grub. Dit kan in het bootmenu (dat zie je normaal niet, je moet een toets drukken om het te onderbreken, vlak na de POST van het systeem), of je kunt de regel GRUB_CMDLINE_LINUX_DEFAULT= aanpassen in /etc/default/grub waarna je een sudo update-grub draait.

[deHakkelaar]

Ik ben niet bekend met Manjaro maar het ziet er naar uit dat dit een systemd distro is.
Kijk met onder ofdat je kunt ontdekken wat zo lang duurt:

code:

systemd-analyze blame

En zoek in de journal/logs voor de huidige --boot naar hints waarom:

code:

sudo journalctl --full --catalog --boot

Of op <UNIT_NAME>:

code:

sudo journalctl --full --catalog --boot --unit <UNIT_NAME>

EDIT: Ter info:

$ man systemd-analyze
[..]
   systemd-analyze blame
       This command prints a list of all running units, ordered by the time
       they took to initialize. This information may be used to optimize
       boot-up times. Note that the output might be misleading as the
       initialization of one service might be slow simply because it waits for
       the initialization of another service to complete. Also note:
       systemd-analyze blame doesn't display results for services with
       Type=simple, because systemd considers such services to be started
       immediately, hence no measurement of the initialization delays can be
       done. Also note that this command only shows the time units took for
       starting up, it does not show how long unit jobs spent in the execution
       queue. In particular it shows the time units spent in "activating"
       state, which is not defined for units such as device units that
       transition directly from "inactive" to "active". This command hence
       gives an impression of the performance of program code, but cannot
       accurately reflect latency introduced by waiting for hardware and
       similar events.

       Example 2. Show which units took the most time during boot

           $ systemd-analyze blame
                    32.875s pmlogger.service
                    20.905s systemd-networkd-wait-online.service
                    13.299s dev-vda1.device
                    ...
                       23ms sysroot.mount
                       11ms initrd-udevadm-cleanup-db.service
                        3ms sys-kernel-config.mount

[ Voor 68% gewijzigd door deHakkelaar op 01-03-2024 15:21 ]

[Limhes]

Cool, thanks, ga ik morgen even proberen!

[deHakkelaar]

@Limhes , uit nieuwschierigheid, Wat stelt je avatar voor?
Limiet van Planck naar e^S ???

[Limhes]

@deHakkelaar het is een stom grapje: mijn nickname als formule. Ziet er interessant uit, maar betekent niets 😊. Limhes komt van Laat Ik Mijn Hoofd Eens Schillen, de vrij obscure titel van een Vrij Nederland artikel dat op ons bureau open lag toen ik, een jaar of 25 geleden, een emailadres moest verzinnen.

En volgens mij stamt de avatar uit de tijd dat ik op de uni voor de eerste keer met LaTeX bezig was.

[ Voor 14% gewijzigd door Limhes op 01-03-2024 17:32 ]

[deHakkelaar]

Aha, het leek op iets reeel
Wikipedia: Limit (mathematics)

[Limhes]

Nou, ik heb volledige output aanstaan en kan dan zien dat de "dode tijd" in de bios of (begin van) grub zit. Kan ik er nog achter komen waar hij "hangt"?

Ik voer nu memory test etc. uit in de bios of daar iets fout zit:
Resultaat: volledige systeemtest levert overall " pass" op

Hoe kan ik grub debuggen of diagnostics aanzetten? Ik kan het zo snel niet vinden...

[ Voor 25% gewijzigd door Limhes op 02-03-2024 09:37 ]

[Klippy]

Het systemd-analyze blame commando van @deHakkelaar kan je gewoon na het booten uitvoeren, daar zou je wat moeten zien.
Ben ook niet bekend met Manjaro, maar laatst wel op deze manier op Ubuntu een vervelende boot vertraging kunnen vinden.

[Limhes]

Klopt. Maar als ik die run zie ik (logischerwijs) alleen dingen van ná het booten, dus als 'ie al door grub heen is. En de vertraging lijkt dus nu juist in grub te zitten, vermoed ik

[Klippy]

Ik had gemist dat het in de boot loader zit.
Heb je iets van encryptie op je schijven?

[Hero of Time]

Zie je wel Grub tijdens het opstarten of dat niet? Want als het namelijk even duurt voordat je überhaupt Grub ziet, dan heeft het weinig van doen met het OS dat aan het starten is, maar juist je UEFI dat Grub moet laden.

Weet je zeker dat er bij de updates die je hebt uitgevoerd niet nog iets van een firmware update zat die je met fwupd hebt toegepast?

[Limhes]

Geen encriptie, firmware geupdate volgens mij ook niet. Ik zie tijdens het zwarte scherm vóór grub wel twee keer een stukje witte tekst heel snel voorbij komen, maar dat kan ik niet lezen.

Ik denk dat ik eens aan de slag moet met alternatieve bootmedia, om zo te kijken of het aan uefi/bios of grub ligt...

[Hero of Time]

Lees je even in wat er tijdens het boot proces allemaal gebeurt voordat het OS wordt geladen. Want pas vanaf het punt dat de bootloader het OS aanroept heeft het OS er niks mee te maken. Dat is puur de hardware en bootloader.

Desktops met DDR5 geheugen hebben wel eens de neiging, zeker in het begin van AM5, om best lang te doen over geheugen trainen. Dan zit je ook meerdere seconden tot zelfs een halve minuut naar een blanco scherm te staren waar ogenschijnlijk niks gebeurt. En opeens zie je je login scherm.

Is je E15 trouwens een eerste gen of later? Want er zijn meerdere modellen en generaties hiervan. Zowel Intel als AMD is ermee beschikbaar. De exacte config kan nogal uitmaken.

[ninjazx9r98]

Limhes schreef op zaterdag 2 maart 2024 @ 14:46:
Geen encriptie, firmware geupdate volgens mij ook niet. Ik zie tijdens het zwarte scherm vóór grub wel twee keer een stukje witte tekst heel snel voorbij komen, maar dat kan ik niet lezen.

Ik denk dat ik eens aan de slag moet met alternatieve bootmedia, om zo te kijken of het aan uefi/bios of grub ligt...

Probeer het boot proces eens te filmen met je mobiel, vervolgens kun je rustig 'scrollen' door alle frames en mogelijk wel de snelle witte tekst lezen.

[Limhes]

(Duurde even voordat ik weer aan de bewuste laptop kon werken.)

Het is een 20RD-001FMH uit 2019, geen idee welke generatie. In ieder geval een Intel i5 10th gen CPU.

Ik heb een fimpje gemaakt tijdens booten en zie dan:
- 00 sec: Het BIOS bootscherm
- 15 sec: "ThinkVantage Active Protection sensor diagnostics start. |"
- 45 sec: "Welcome to GRUB!"
- dan zit 'ie in het OS en gaat alles goed

Na wat zoeken op dat "sensor diagnostics" bericht heb ik in de BIOS de boot type naar "quick" gezet (stond op "diagnostic") en dit lijkt het probleem grotendeels op te lossen! Waarschijnlijk heb ik dit euvel dus zelf veroorzaakt...

Dank voor al jullie hulp. @Hero of Time wat mij betreft mag je het topic verplaatsen, want het heeft niets met Linux te maken.

.edit: Owja, wat ik nog vergeten was te melden: een deel van de vertraging zat ook nog in een set oude network shares die Manjaro probeerde te mounten tijdens startup

[ Voor 9% gewijzigd door Limhes op 07-03-2024 09:39 ]