# [er]Interne SSD M.2 SATA - Sinnvoll für Gentoo? Erfahrungen?

## flammenflitzer

Hallo, macht es vom Gewinn an Geschwindigkeit Sinn, Gentoo auf einer internen SSD M.2 SATA zu installieren? Und wie sieht es mit der Haltbarkeit bei der Nutzung mit Gentoo aus, da durch die regelmäßigen Updates m.E. doch mehr auf der SSD geschrieben wird als beispielsweise unter Windows?Last edited by flammenflitzer on Sun Aug 09, 2020 7:34 am; edited 1 time in total

----------

## pietinger

 *flammenflitzer wrote:*   

> Hallo, macht es vom Gewinn an Geschwindigkeit Sinn, Gentoo auf einer internen SSD M.2 SATA zu installieren? 

 

JA !! Ich habe in meinem Notebook nur eine SSD; am Hauptrechner eine SSD und eine HD. Die HD dient nur als Datengrab für große Dateien (und als Sync für die SSD).

Die Bootzeiten machen einfach nur noch Spass  :Smile:  Genauso toll ist es wenn Du auf etwas größeres klickst - wie z.B. libreoffice-calc - und es ist instant gestartet / offen.

 *flammenflitzer wrote:*   

> Und wie sieht es mit der Haltbarkeit bei der Nutzung mit Gentoo aus, da durch die regelmäßigen Updates m.E. doch mehr auf der SSD geschrieben wird als beispielsweise unter Windows?

 

Genau das hat mir (damals) auch Sorgen bereitet und ich habe deshalb die /usr/portage (war 2016 noch dort) als eigene partition auf die HD gelegt. Ich habe aber schon verschiedene Stimmen gehört die meinten, selbst ein täglicher "emerge --sync" würde der SSD nicht so zusetzen und sei kein Problem. Ich kann leider keine Erfahrungwerte geben, da meine älteste SSD erst 4 Jahre alt ist. Was auf alle Fälle empfehlenswert ist: Nimm mindestens 16 GB RAM damit Du alle compiles in tmpfs durchführen kannst.

----------

## mike155

Ich habe meine Maschinen vor etwas über einem Jahr von SATA SSDs auf M.2 NVMe SSDs umgestellt (Achtung: M.2 NVMe, nicht M.2 SATA. Von M.2 SATA halte ich nicht viel). 

Gefühlt sind sie dadurch ein ganzes Stück schneller geworden. Man merkt es beim Booten und beim Starten von Programmen. 

Wenn ich mit "smartctl" oder "nvme" auf die restliche Lebenszeit der NVMe SSDs schaue, steht dort: 100%. Geschrieben wurden bisher ein paar Hundert GB. Das ist nichts! Von der Schreiblast werden die NMVe SSDs also noch Jahrhunderte halten  :Smile: 

Ich kompiliere ausschließlich im RAM. 

Hier ist ein gute Seite mit vielen weiteren Informationen: https://www.pc-experience.de/hardwareuntermenupunkt/nvme-m-2-faqs-tipps-und-fakten.html?showall=1Last edited by mike155 on Fri Aug 07, 2020 12:18 pm; edited 1 time in total

----------

## mike155

Nachdem ich meinen Post geschrieben habe, habe ich mich der aktuellen c't zugewendet. Dort gibt es einen Test von PCIe-SSDs, erstaunlicherweise mal wieder ohne Samsung. Ich verstehe nicht, warum die c't Samsung SSDs regelmäßig außen vor lässt. Das ist mehr jetzt mehrfach aufgefallen. Samsung ist Marktführer und ich mag Samsung SSDs sehr!

Jedenfalls scheint es bei SSDs ein neues, außerordentlich wichtiges Kriterium zu geben, das ich bisher noch gar nicht auf dem Schirm hatte:

 *Quote:*   

> Der Trend zur steuerbaren Beleuchtung von PC-Komponenten macht auch vor SSDs nicht halt. In diesem Test ist wieder einmal eine SSD vertreten, die automatisch in verschiedenen Farben leuchtet.

 

Okay, dann wird man sich in Zukunft neben Geschwindigkeit, Stromverbrauch und Haltbarkeit auch noch um die Beleuchtung kümmern müssen.   :Confused: 

----------

## l3u

Ich hab Ende letztes Jahr einen neuen Rechner gebaut, und eine 500-GB-NVMe-SSD und eine 500-GB-HD reingebaut (beide WD Black). Portage und sämtliche git-Repositorys liegen auf der HD, alles andere auf der SSD (teils via bind-mounts, teils per Symlinks). Bisher kann ich nicht klagen. Da RAM recht billig geworden ist, würde ich sogar mein Vorgehen empfehlen und 32 GB reinbauen. 10 davon nutze ich für ein tmpfs für's Kompilieren. Läuft alles recht schnell, wobei ich einen alten Intel Core sowieso mit vier Kernen gegen einen Ryzen 5 3600 getauscht habe. Also von daher kann ich nicht genau abgrenzen, wieviel vom Geschwindigkeitszuwachs auf das Konto der SSD geht (ich hab ja allein schon -j4 gegen -j12 getauscht, und im RAM bauen ist doch etwas flotter als auf einer HD ;-)

Für Langzeitberichte fehlt natürlich noch die Nutzungsdauer. Aber bisher läuft alles 1A.

Da mittlerweile ja scheinbar SSDs selbst in (Hochlast-)Servern verbaut werden, braucht man sich vielleicht über die begrenzten Schreibzyklen nicht mehr allzu viele Gedanken machen. Aber eine fachkundige Aussage kann ich dazu nicht treffen …

----------

## ManfredB

Ich habe in meinem PC 2 SSDs und 2 HDDs.

SSD 1 mit Linux-Distributionen

SSD 2 mit /home-Paritionen für die Linux-Distributionen

Die HDDs sind für Daten - Downloads - Isos - MediaThek usw.

Da ich viele Gentoo-Installationen habe, ist es mit den SSDs wunderbar.

```

System:    Host: gamk_a6 Kernel: 5.7.10 x86_64 bits: 64 Desktop: KDE Plasma 5.19.4 Distro: Gentoo Base System release 2.7 

Machine:   Type: Desktop System: CSL- & KG product: A0000001 v: N/A serial: PCCSL2018038241 

           Mobo: ASUSTeK model: TUF B450-PLUS GAMING v: Rev X.0x serial: 180937167304657 UEFI: American Megatrends v: 0409 

           date: 08/24/2018 

CPU:       Topology: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP L2 cache: 3072 KiB 

           Speed: 1379 MHz min/max: 1550/3400 MHz Core speeds (MHz): 1: 1377 2: 1436 3: 1547 4: 1546 5: 1439 6: 1381 7: 1443 

           8: 1539 9: 1419 10: 1416 11: 1375 12: 1375 

Graphics:  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nouveau v: kernel 

           Display: x11 server: X.org 1.20.8 driver: nouveau unloaded: modesetting resolution: <xdpyinfo missing> 

           OpenGL: renderer: NV136 v: 4.3 Mesa 20.1.4 

Audio:     Device-1: NVIDIA GP106 High Definition Audio driver: snd_hda_intel 

           Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel 

           Sound Server: ALSA v: k5.7.10 

Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 

           IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: 40:b0:76:0b:96:a6 

Drives:    Local Storage: total: 8.87 TiB used: 1.03 TiB (11.6%) 

           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB 

           ID-2: /dev/sdb vendor: Seagate model: ST4000DM004-2CV104 size: 3.64 TiB 

           ID-3: /dev/sdc vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB 

           ID-4: /dev/sdd vendor: Seagate model: ST4000DM000-1F2168 size: 3.64 TiB 

           ID-5: /dev/sde type: USB model: TO Exter nal USB 3.0 size: 465.76 GiB 

           ID-6: /dev/sdf type: USB model: ATA FUJITSU MHZ2250B size: 232.89 GiB 

Partition: ID-1: / size: 19.56 GiB used: 6.60 GiB (33.8%) fs: ext4 dev: /dev/sda6 

           ID-2: /home size: 19.56 GiB used: 2.67 GiB (13.6%) fs: ext4 dev: /dev/sde6 

           ID-3: swap-1 size: 14.77 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sdd1 

Sensors:   Missing: Required tool sensors not installed. Check --recommends 

Info:      Processes: 244 Uptime: 9m Memory: 15.62 GiB used: 849.2 MiB (5.3%) Shell: bash inxi: 3.0.38

```

Gruß

Manfred

----------

## forrestfunk81

Ich kann SSDs auch nur empfehlen. Meine erste habe ich um 2009/2010 rum gekauft und in der Zwischenzeit waren es wahrscheinlich ca 8 auf 5 unterschiedlichen Gentoo Installationen. Mindestens zwei SSDs liefen davon gut über 4 Jahre als Hauptdisk (privater Laptop und Router im 24/7 Betrieb). Der Router hat außerdem mangels genügend RAM mit /var/tmp/portage auf der SSD gebaut. Ausgetauscht wurden die SSDs nur, weil die verfügbare Speichergröße doch enorm zugenommen hat. Die letzten 3 SSDs waren ebenfalls NVMe und das gibt schon nochmal einen deutlichen Boost, wobei auch SATA SSDs spürbar schneller waren als HDs. Hersteller habe ich Samsung, OCZ und vielleicht auch eine Intel. Bin sehr zufrieden mit allen. 

Anfangs war ich auch skeptisch wegen der Schreibzyklen, aber das hat sich als grundlos erwiesen. Smartctl schaue ich mir nur noch sehr selten mal an. Aktuell hier auf einem über 3 Jahre alten Gentoo Laptop mit Samsung SATA SSD in werktäglicher Benutzung:

Power_On_Hours: 7298 (entspricht 912 Arbeitstagen)

Wear_Leveling_Count: 89 %

Media_Wearout_Indicator: 88 %

Auf diesem Gerät wird nicht nur Gentoo kompiliert (das meiste im RAM), sondern auch Software Entwicklung betrieben, mit ebenfalls vielen Kompiliervorgängen täglich (nicht im RAM), Minikube, einige Docker Container, Application Server, Code Analyse Tools, diverse Datenbanken, Elasticsearch, automatisierte Test und was so dazu gehört. Kurz: es gibt wohl wenige Anwendungsszenarien, in welchen End User Systeme mehr Disk IO aushalten müssen. Dafür sind 88 % Wearout (also 12 % verbraucht) nach 3 Jahren ganz ok, denke ich.

[Edit]

Auf allen SSDs war/ist auch eine LUKS Festplattenverschlüsselung im Einsatz, auch für die root Partition. Davon wurde in Kombination mit SSD (zumindest früher immer) abgeraten. Aber soweit ich weiß, wurden auch dort einige Verbesserungen eingeführt und abgeraucht ist mir noch keine.

Aber wie immer gilt: es ist sinnvoll aktuelle Backups zu haben  :Wink: 

----------

## flammenflitzer

Ich habe eine gekauft. Danke an alle.   :Very Happy: 

----------

## ManfredB

Viel Freude mit der neuen SSD.

Gruß

Manfred

----------

## musv

 *pietinger wrote:*   

> Nimm mindestens 16 GB RAM damit Du alle compiles in tmpfs durchführen kannst.

 

Mach ich zwar auch, aber beim nächsten System werd ich das nochmal überdenken. 

Der Grund dafür ist einfach, dass man ccache nicht mit tmpfs nutzen kann. Und bei einigen dicken Brocken (chromium, webkit) ist das tatsächlich hilfreich.

Mit den begrenzten Schreibzyklen hab ich keine Probleme. Ich hatte 2011 mal 3 OCZ, die mir allesamt abgeraucht sind. Seitdem hatte ich nie wieder Probleme mit Platten/SSDs jeglicher Art. Ich würde schon davon ausgehen, dass die Dinger mittlerweile einen den HDDs ebenbürtigen Reifegrad erreicht haben. 

Genau wie Mike155 würde ich aber wohl eher auf NVMe anstatt SATA setzen.

----------

## flammenflitzer

Ich habe 1TB Kingston NVMe SSD. Zur Probe habe ich auch kubuntu installiert. Da ist der Desktop nach wenigen Sekunden da. Gefühlt 4x so schnell wie mein Gentoo (mitPlasma/kde5), welches in etwa gleich auf liegt wie Windows10 (dort ist das schnelle Herunterfahren deaktiviert, sonst wäre Gentoo das langsamste System beim Start).

----------

## mike155

Dann solltest Du Dich auf die Ursachenforschung begeben. Es kann ja nicht so stehenbleiben, dass Gentoo das langsamste System ist!  :Smile: 

Ich nehme an, dass Du sowohl unter Kubuntu, als auch unter Gentoo Systemd verwendest?

Verwendest Du KDE/Plasma sowohl unter Kubuntu, als auch unter Gentoo?

Welche Zeit gibt

```
dmesg | grep "crng init done"
```

unter Gentoo und unter Kubuntu aus?

Du könntest mal schauen, nach wie viel Sekunden nach dem Start des Bootens X11 unter Kubuntu und unter Gentoo gestartet wird. 

Wenn es unter Gentoo länger als unter Kubuntu dauert, gibt es ein Problem im Boot-Prozess. Dann könntest Du prüfen, ob es Fehlermeldungen gibt vom Kernel oder von Systemd, die das Booten verzögern. 

Falls X11 auf Gentoo und Kubuntu nach der gleichen Zeit gestartet wird, liegt das Problem in X11 oder in KDE/Plasma. Auch da kann so einiges schief gehen, was zu Verzögerungen führen kann.

----------

## flammenflitzer

5.7.11-gentoo

systemd-analyze time

```

Startup finished in 22.992s (firmware) + 10.529s (loader) + 2.583s (kernel) + 4.459s (userspace) = 40.565s 

graphical.target reached after 4.446s in userspace
```

dmesg | grep "crng init done"

```
[    3.600678] random: crng init done
```

systemd-analyze blame

```

2.300s dev-nvme0n1p7.device                                                                     

1.899s systemd-remount-fs.service                                                               

 765ms *******\x2d4.mount                                                         

 622ms *******.mount                                                                        

 581ms *******.mount                                                                  

 558ms *******\x2d1.mount                                                         

 552ms *******\x2d2.mount                                                         

 546ms *******\x2d3.mount                                                         

 544ms systemd-networkd.service                                                                 

 495ms systemd-resolved.service                                                                 

 487ms systemd-timesyncd.service                                                                

 446ms systemd-logind.service                                                                   

 396ms upower.service                                                                           

 304ms systemd-journald.service                                                                 

 249ms systemd-modules-load.service                                                             

 236ms *******.mount                                                      

 227ms systemd-binfmt.service                                                                   

 224ms udisks2.service                                                                          

 202ms NetworkManager.service                                                                   

 201ms systemd-udevd.service                                                                    

 196ms systemd-udev-trigger.service                                                             

 169ms colord.service                                                                           

 152ms systemd-userdbd.service                                                                  

 120ms user@1000.service                                                                        

 109ms dev-hugepages.mount                                                                      

 109ms dev-mqueue.mount                                                                         

 109ms sys-kernel-debug.mount                                                                   

 108ms sys-kernel-tracing.mount                                                                 

 108ms kmod-static-nodes.service                                                                

  88ms systemd-fsck-root.service                                                                

  84ms systemd-fsck@dev-disk-by\x2duuid-45f71e3f\x2d754a\x2d4368\x2d90ef\x2d3980ae2596dd.service

  49ms systemd-journal-flush.service                                                            

  42ms polkit.service                                                                           

  40ms home*******.mount                                                                          

  39ms sys-kernel-config.mount                                                                  

  31ms bluetooth.service                                                                        

  29ms tmp.mount                                                                                

  27ms systemd-sysctl.service                                                                   

  25ms dev-disk-by\x2dpartuuid-000388cb\x2d72b0\x2dc772\x2dc2ec\x2df71996110700.swap            

  20ms proc-sys-fs-binfmt_misc.mount                                                            

  16ms sys-fs-fuse-connections.mount                                                            

  15ms systemd-tmpfiles-setup.service                                                           

  15ms systemd-rfkill.service                                                                   

  14ms user-runtime-dir@1000.service                                                            

  11ms systemd-tmpfiles-setup-dev.service                                                       

  10ms systemd-random-seed.service                                                              

   9ms alsa-restore.service                                                                     

   8ms systemd-update-utmp.service                                                              

   6ms wpa_supplicant.service                                                                   

   5ms systemd-update-utmp-runlevel.service                                                     

   3ms systemd-user-sessions.service                                                            

   2ms rtkit-daemon.service  
```

----------

## mike155

@flammenflitzer: das sind schon mal sehr interessante Zahlen. Jetzt wären natürlich die Vergleichs-Zahlen unter Kubuntu interessant. Bis die vorliegen, können wir mit meinem System vergleichen - wobei ich ganz andere Hardware habe.

Der Random Number Generator ist's nicht. Ich habe einen ähnlichen Wert:

```
[    3.136962] random: crng init done
```

Interessant ist die Ausgabe von "systemd-analyze time". Bei mir kommt:

```
# systemd-analyze time

Startup finished in 1.069s (kernel) + 4.692s (userspace) = 5.761s 

graphical.target reached after 4.685s in userspace
```

Bei Dir kommen da doch ganz erhebliche Werte (40 Sekunden statt 6 Sekunden) zusammen!

Für die beiden Top-Werte in Deiner Ausgabe von "systemd-analyze blame" habe ich andere Werte:

```
# systemd-analyze blame | egrep "(nvme|systemd-remount)"

 352ms dev-nvme0n1p2.device                

   6ms systemd-remount-fs.service
```

Das kann auf ein Problem hindeuten, kann aber auch Zufall oder harmlos sein - es ist sicherlich nicht die Haupt-Ursache für die Verzögerung bei Dir.

----------

## flammenflitzer

Folgende Fehlermeldungen habe ich

```
13.08.20 15:08   bluetoothd   RFCOMM server failed for Message Notification: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for Message Access: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for Phone Book Access: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for Synchronization: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for File Transfer: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for Object Push: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   bluetoothd   RFCOMM server failed for Headset Voice gateway: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   pulseaudio   [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files

13.08.20 15:08   bluetoothd   RFCOMM server failed for :1.36/Profile/HSPHSProfile/00001108-0000-1000-8000-00805f9b34fb: socket(STREAM, RFCOMM): Protocol not supported (93)

13.08.20 15:08   pulseaudio   [pulseaudio] pid.c: Daemon already running.

13.08.20 15:08   /hp-systray   hp-systray(qt5)[3527]: error: Unable to find hp-upgrade --notify on PATH.

13.08.20 15:08   pulseaudio   [alsa-sink-ALCS1200A Analog] alsa-sink.c: ALSA weckte uns auf, um neue Daten auf das Gerät zu schreiben, doch es gab nichts zum Schreiben!

13.08.20 15:08   pulseaudio   [alsa-sink-ALCS1200A Analog] alsa-sink.c: Dies ist höchstwahrscheinlich ein Fehler im ALSA-Treiber »snd_hda_intel«. Bitte melden Sie diesen Fehler den ALSA-Entwicklern.

13.08.20 15:08   pulseaudio   [alsa-sink-ALCS1200A Analog] alsa-sink.c: Wir wurden durch das POLLOUT-Set geweckt, allerdings lieferte ein anschließender snd_pcm_avail() den Wert 0 oder einen anderen Wert < min_avail.

13.08.20 15:08   akonadi_control   org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"

13.08.20 15:08   akonadi_control   org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"

13.08.20 15:08   akonadi_control   org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"

13.08.20 15:08   akonadi_control   org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"

13.08.20 15:08   akonadi_control   org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"
```

```
Startup finished in 22.992s (firmware) + 10.529s (loader) 
```

Ich denke, das sind die rund 33 Sekunden, die dein System schneller ist. Damit kann ich nichts anfangen....

Der Rest 2.583s (kernel) + 4.459s (userspace) = 7,042

----------

## mike155

 *flammenflitzer wrote:*   

> 
> 
> ```
> Startup finished in 22.992s (firmware) + 10.529s (loader) 
> ```
> ...

 

Was heißt "damit kann ich nichts anfangen?". Das ist doch genau der Ort, an dem man ansetzen kann. Man kann Google fragen:

```
systemd analyze firmware loader
```

Und schon findet man ein paar Artikel, in denen beschrieben wird, wie man die Zeiten für "firmware" und "loader" deutlich verringern kann.  :Smile: 

Beispiele: 

https://bbs.archlinux.org/viewtopic.php?id=238414

https://askubuntu.com/questions/869841/long-firmware-boot-time-ubuntu-16-04

...

----------

## flammenflitzer

Den ersten und einige andere habe ich gelesen. So wie ich das verstehe soll ich die BIOS Einstellungen optimieren. Ist das richtig? Warum sollte ich die BIOS Einstellungen für Gentoo Boot optimieren, wenn es für Kubuntu nicht nötig ist. Oder habe ich da etwas falsch verstanden?

----------

## mike155

Ja, BIOS Einstellungen alleine können es nicht sein, weil dann auch Kubuntu betroffen wäre. Aber der letzte Post im ersten Link sagt:

 *Quote:*   

> I reduced it from 10s to 2s by doing following:
> 
> 1. Enable fastboot in BIOS.
> 
> 2. https://wiki.archlinux.org/index.php/GR … workaround
> ...

 

Also könnte es beispielsweise sein, dass die BIOS-Einstellung stimmt, aber der Bootloader-Workaround nur unter Kubuntu, aber nicht unter Gentoo konfiguriert ist.

Ich wünschte, ich könnte Dir genau sagen, was Du tun musst. Aber das kann ich nicht. Ich vermute, dass "22.992s (firmware) + 10.529s (loader)" die Stelle ist, an der man suchen muss. Ich würde mir ansehen, was unter Kubuntu anders ist - und versuchen, das auch auf das Gentoo System zu übernehmen. Schau Dir beispielsweise mal an, wie GRUB unter Kubuntu konfiguriert ist und mit welchen Command Line Argumenten der Kernel gestartet wird.

Wie bootest Du Dein System? Über BIOS? Oder über UEFI? Evtl. mit CSM? Falls Du unter UEFI bootest, könntest Du testweise mal CSM an oder abschalten oder auf BIOS umschalten. UEFI ist nicht ganz einfach und erfordert einige Einstellungen (auch in GRUB, im Kernel und im Betriebssystem), bis es sauber läuft. Es könnte sein, dass auf Deinem Gentoo System etwas noch nicht stimmt.

----------

## flammenflitzer

kubuntu:~$ systemd-analyze time

```
Startup finished in 21.622s (firmware) + 5.109s (loader) + 3.599s (kernel) + 7.252s (userspace) = 37.584s 

graphical.target reached after 7.245s in userspace
```

kubuntu:~$ systemd-analyze blame

```
6.239s NetworkManager-wait-online.service                   

 903ms systemd-logind.service                               

 860ms udisks2.service                                      

 781ms snapd.service                                        

 419ms dev-loop1.device                                     

 336ms dev-loop4.device                                     

 334ms dev-loop3.device                                     

 329ms dev-loop2.device                                     

 289ms dev-nvme0n1p5.device                                 

 245ms snap-snapd-8790.mount                                

 245ms snap-core18-1885.mount                               

 244ms snap-gtk\x2dcommon\x2dthemes-1506.mount              

 243ms snap-keepassxc-978.mount                             

 242ms snap-snapd-8542.mount                                

 196ms man-db.service                                       

 188ms fwupd.service                                        

 158ms accounts-daemon.service                              

 149ms dev-loop0.device                                     

 140ms upower.service                                       

 140ms networkd-dispatcher.service                          

 117ms user@1000.service                                    

 112ms bluetooth.service                                    

 109ms avahi-daemon.service                                 

 106ms boot-efi.mount                                       

 102ms NetworkManager.service                               

 100ms polkit.service                                       

  86ms dev-nvme0n1p6.swap                                   

  83ms logrotate.service                                    

  75ms apport.service                                       

  75ms thermald.service                                     

  74ms systemd-journald.service                             

  72ms wpa_supplicant.service                               

  70ms systemd-resolved.service                             

  60ms systemd-timesyncd.service                            

  60ms grub-common.service                                  

  59ms dev-sde7.swap                                        

  58ms gpu-manager.service                                  

  57ms systemd-udev-trigger.service                         

  57ms systemd-journal-flush.service                        

  52ms ModemManager.service                                 

  42ms rsyslog.service                                      

  36ms secureboot-db.service                                

  36ms grub-initrd-fallback.service                         

  33ms systemd-udevd.service                                

  32ms keyboard-setup.service                               

  32ms packagekit.service                                   

  29ms e2scrub_reap.service                                 

  29ms systemd-rfkill.service                               

  27ms apparmor.service                                     

  25ms pppd-dns.service                                     

  22ms systemd-fsck@dev-disk-by\x2duuid-04FE\x2d56A1.service

  21ms snapd.seeded.service                                 

  18ms snapd.apparmor.service                               

  13ms plymouth-start.service                               

  13ms systemd-modules-load.service                         

  12ms plymouth-read-write.service                          

  11ms plymouth-quit.service                                

  11ms systemd-tmpfiles-setup.service                       

  11ms kerneloops.service                                   

  10ms systemd-sysusers.service                             

   9ms systemd-random-seed.service                          

   8ms modprobe@drm.service                                 

   7ms alsa-restore.service                                 

   6ms dev-hugepages.mount                                  

   6ms dev-mqueue.mount                                     

   6ms systemd-sysctl.service                               

   5ms sys-kernel-debug.mount                               

   5ms systemd-user-sessions.service                        

   5ms setvtrgb.service                                     

   5ms user-runtime-dir@1000.service                        

   5ms sys-kernel-tracing.mount                             

   5ms systemd-update-utmp-runlevel.service                 

   5ms systemd-remount-fs.service                           

   4ms systemd-update-utmp.service                          

   4ms systemd-tmpfiles-setup-dev.service                   

   3ms kmod-static-nodes.service                            

   2ms console-setup.service                                

   2ms sddm.service                                         

   2ms rtkit-daemon.service                                 

   2ms sys-fs-fuse-connections.mount                        

   1ms sys-kernel-config.mount                              

   1ms ufw.service                                          

   1ms snapd.socket 
```

Ist nur gefühlt schneller. Allerdings erscheint bei gentoo nicht

```
2ms sddm.service 
```

Ich habe das Gefühl, das sddm unter Gentoo langsamer ist.

----------

## flammenflitzer

Ich habe etwas am Kernel geändert:

systemd-analyze time

```

Startup finished in 19.194s (firmware) + 8.288s (loader) + 2.043s (kernel) + 4.526s (userspace) = 34.053s 

graphical.target reached after 4.513s in userspace
```

Schnelles booten war im BIOS schon aktiviert. Ich denke, ich mache da mal eine neue Diskussion zum Thema auf.

----------

