Bootzeit ca. 3 min

  • Hallo zusammen,


    mein System auf 12.2.1 benötigt ziemlich genau 2:50 min zum booten ab Open Core.

    Die Suche habe bereits gequält und diesen Beitrag gefunden in der über TRIM Problematik berichtet wird:


    Luxusproblem: Bootzeit. Pause von 40Sek bei "bootroot" in Monterey 12.1


    Meine SSD ist eine Samsung 960 EVO NVMe 250GB, aber ein Update auf OC 0.7.9 und SetApfsTrimTimeout auf -1 oder 0 ändert nicht eine Sekunde beim booten.

    Woran könnte das noch liegen?

    Dateien

    • EFI.zip

      (12,96 MB, 74 Mal heruntergeladen, zuletzt: )
  • Anbei die Ausgabe:


    Ich habe dennoch einmal das System auf eine alte Kingston SATA SSD geklont und gebootet, das holt die Bootzeit auf 1:18 min runter.

    Ist zwar immer noch viel, aber deutet dann wohl doch auf ein Problem mit der Samsung SSD



  • Damit hattest du schonmal recht, ich habe auf die aktuellste verklinkte Version aktualisiert und nun spuckt er es so aus:


    Code
    1. 2022-02-26 11:08:15.934139+0100 0x343 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk4 scan took 0.000000 s, trims took 0.000000 s


    ABER: Der Bootvorgang dauert jetzt 5:18 min, dabei bleibt er sehr lange an der Stelle im Bild hängen.

    Bilder

  • Ja klar. Die Serial habe ich oben schon vergessen rauszunehmen, werde ich dann neu generieren sobald ich hier am Ziel bin.

    Dateien

    • EFI.zip

      (12,96 MB, 57 Mal heruntergeladen, zuletzt: )
  • Ich hab jetzt noch nicht testen können, aber ocvalidate zeigt 2 fehler in der config an die du noch verbessern solltest.



    edit: Bei mir bootet deine EFI schnell durch. Ich hab die Atheros kext deaktiviert. Du hast wie es aussieht 2x LAN an board, aber probier vielleicht auch mal mit deaktivierter Kext.

    btw. den Bootstrap Ordner kannst du löschen, da bootstrap jetzt anders geregelt wird.

  • das boot problem ist leider bekannt mit den Samsung ... betrifft den trim wie schon erwähnt , ich bin jetzt dazu übergegangen und hab mir ne andere SSD verbaut


    KEIN SUPPORT PER PN!

    julian2_pic.png

  • Jawoll, nachdem ich einmal "Erste Hilfe" im DiskUtility verwendet habe bin ich innerhalb von 16 sekunden im System :)

    War ja doch naheliegend, da mit der Kingston SATA SSD schon eine Minute erreicht wurde.


    Laut Stoppuhr habe ich jetzt 47 min mit booten verbracht :D


    Vielleicht Upgrade ich die SSD dann mal.. ist das ein reines Samsung Problem? Jede andere SSD vergleichbare SSD kann ich kaufen?


    Ich hab jetzt noch nicht testen können, aber ocvalidate zeigt 2 fehler in der config an die du noch verbessern solltest.



    ist ocvalidate ein Terminal tool? OCAuxiliaryTools und Config-Validator melden keine Probleme...

    Bilder

  • Also einmal hast du es 16 sek. und dann wieder in 47 sek. geschafft?

    Ja, die Samsung NVMEs haben das Problem, die Samsung satas hingegen nicht.

    Hier hast du eine nicht ganz vollständige Übersicht. https://github.com/dortania/bugtracker/issues/192


    Ocvalidate findest du hier und wird in den terminal gezogen und dann nach einem leerzeichen deine config.

    OCAT nutzt das auch, aber nicht unbedingt immer den neuesten commit.

  • Nein, 47 MIN ist die Gesamtzeit der einzelnen Bootvorgänge, du musst auf die "Rundenzeiten" gucken.

    Er braucht jetzt zuverlässig gleichbleibend 16 Sekunden.

  • Kleines Update meinerseits:


    Ich habe die Samsung 960 Evo 250GB gegen eine Corsair MP510 mit 960GB aufgerüstet und TRIM wieder mit -1 aktiviert.

    Ergebnis ist jetzt eine Bootzeit von 11 Sekunden ab OpenCore und folgende Ausgabe zu log show --debug --last boot --predicate "processID == 0" | grep spaceman:


    Edit: Ach ja und die zwei Fehler welche ocvalidate meldet habe ich ausgemerzt, die Einträge werden von OCAuxTools aber wieder gelöscht wenn ich die Config.plist damit öffne und speichere, denke da muss OCAuxTools angepasst werden.

    Code
    1. 2022-03-01 21:21:38.257264+0100 0x3d2 Default 0x0 0 0 kernel: (apfs) spaceman_metazone_init:191: disk4 metazone for device 0 of size 2617462 blocks (encrypted: 0-1308731 unencrypted: 1308731-2617462)
    2. 2022-03-01 21:21:38.257268+0100 0x3d2 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 1 blocks starting at paddr 61898752
    3. 2022-03-01 21:21:38.257271+0100 0x3d2 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 2 blocks starting at paddr 61440000
    4. 2022-03-01 21:21:38.257274+0100 0x3d2 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 3 blocks starting at paddr 61472768
    5. 2022-03-01 21:21:38.257277+0100 0x3d2 Default 0x0 0 0 kernel: (apfs) spaceman_datazone_init:625: disk4 allocation zone on dev 0 for allocations of 4 blocks starting at paddr 61505536
    6. 2022-03-01 21:21:38.282836+0100 0x74 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3171: disk4 scan took 0.025537 s (no trims)
    7. 2022-03-01 21:21:38.519540+0100 0x74 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3153: disk4 scan took 0.236699 s, trims took 0.199026 s
    8. 2022-03-01 21:21:38.519544+0100 0x74 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3155: disk4 178784414 blocks free in 8405 extents
    9. 2022-03-01 21:21:38.519547+0100 0x74 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3163: disk4 178784414 blocks trimmed in 8405 extents (23 us/trim, 42230 trims/s)
    10. 2022-03-01 21:21:38.519550+0100 0x74 Default 0x0 0 0 kernel: (apfs) spaceman_scan_free_blocks:3166: disk4 trim distribution 1:6387 2+:491 4+:843 16+:242 64+:197 256+:245