Unnötige Dienste deaktivieren bei Fedora-Linux mit Systemd auf älteren Systemen

[morromett]

Das ist richtig. Das relinken wird aber im Hintergrund durchgefuehrt.

Ja, das (/bin/ksh /usr/libexec/reorder_kernel
, ld, ctfconv) passiert sofort nach dem booten und dauert einige Minuten. Während dieser Zeit (einige Minuten) ist der Rechner nicht zu gebrauchen, weil der CPU-Verbrauch fast 100% ist, ... und das auch bei neuer Hardware. Ich habe damit kein Problem, weil ich diese Zeit (einige Minuten) abwarten kann.
Beim TE, mit alter Hardware wird es anders sein.

 

[CommanderZed]

Ich hab das mal spaßeshalber beobachtet in einer linux-qemu-vm auf meinen älteren bastelhost (8 kerne zugewiesen vom ca. 10 Jahre alten* E5-2680 v4, 16GB Ram, qcow2 image auf einem ZFS mit alten klassischen SAS-HDDs)

Dort braucht das reordering knapp 50 Sekunden, belegt nur einen der 8 Kerne für kurze seit (15-20 sekunden) zu 100% und den rest der Zeit so mittel-zweistellig und parallel 2,3 der anderen kerne zu wenigen 5-10%, das lässt noch viel Spielraum für andere paralele Prozesse. Als "load" angabe ging es nicht über 0.5 heraus. Villeicht hat der ein oder andere ja lust das mit etwas neuerer als 10 Jahre alter Hardware zu vertesten

(Auch son ganz gutes beispiel, der ist alterstechnisch ja garnicht mal sooooo weit auseinander vom Cabriomodell** (2014 vs 2016 release) aber lt. kurzem googeln nach nem Benchmark kriegt der Atom dort 388 ST und 542 MT Punkte und der Xeon 1931 ST (5x schneller) und 17238 MT (32x schneller)

**(Villeicht auch ein beispiel für etwas anderes - wie man so entscheidungen trifft womit man arbeiten möchte in bezug auf den OP und knappen mitteln.
Ich nutz ja primär zwei Notebooks + einen kleine Homeserver, aber letztes Jahr reifte bei mir der Gedanke "ich brauchte was separates für diverse Bastelprojekte" wie z.B. ein festplattenausleseprojekt (Think alte IDE-Platte, alte 500MB SCSI-Platten), ein paar SAS-Platten + Controller mal für ZFS-Bastelkrams usw.
Ich hatte noch eine Board/CPU/Ram/Tower/Netzteilkombi mit nem i5 4. gen, ein weiteres mit nem AthlonXP für IDE-Festplatten und ein paar passiv-gekühlte Systeme aber keins hat sich als so richtig stabil mehr erwiesen und es ging mir echt auf den Keks das gelegentliche Basteln immer wieder fürs Troubleshooten der Hardware zu verwenden um die es garnicht gehen sollte. Also dachte ich kaufst du mal ein paar neue Komponenten und ein paar gebraucht komponenten um da auch für gelegentliches basteln nicht zu viel zu investieren. Nen gescheites neues Markennetzteil und ein "offenes" Gehäuse waren schnell gefunden, nen PCIe IDE Controller habs auch noch billig aber ne CPU/Mainboard/Ram-Kombi fand ich schwierig zu finden. Ne halbwegs okaye neue Kombi sollte so um die 200€ kosten, das war aber eigentlich mehr als ich im Budget hatte. Ich wollte gerne so richtung i5. 8. gen aber alles was ich auf ebay und ebay-ka gefunden habe war entweder absurd teuer (Schnell mal mehr als 150€, das ist im Preisabstand zum neukauf komplett banane) oder im "ungeprüft" und "ohne Garantie" zustand was für mich oft heißt "Ich verkaufe hier Schrott" - und selbst da noch meist so um die 100€ - und ich wollte ja gerade nicht mehr ein System mit möglichen Mainboardfehlern z.B.
Da kam mir aber in erinnerung das ich auf einem youtube-channel gesehen hatte das in China so Bundles mit neuen Boards und alter mutmaßlich gebrauchter Server-CPU als "Gaming" Bundle verkauft werden. Dafür eher weniger geeignet und zurecht kritisiert, aber ja eigentlich ungefähr was ich gesucht hatte.
Neues Board mit mutmaßlich wenig Fehlern, gerne ein paar mehr CPUs für Multi-OS-Qemu-Workloads und das für unter 80€ - inkl. Board, CPU und 32GB Ram - perfekt!
Ich hab dann später noch 32GB gebraucht Ram (Letzten Herbst war DDR4-ECC noch recht günstig) ein paar Monate später für 20€ dazu gesteckt da ich das ding immer mehr für so bastel VMs zusätzlich genutzt hab.
Für mich war das ein sehr guter kauf, ich bin damit momentan sehr zufrieden als ergänzung meines "Zoos" - würde das aber nur für sehr sehr spezifische Fälle empfehlen.
Aber worauf ich mit dem langen Text eigentlich hinaus möchte - das richtige System für den richtigen Zweck, sich vor dem Kauf bzw Nutzung auch wenns schon da ist Gedanken machen wie "was brauch ich", "was möchte ich", "was kann ich mir evtl. leisten," "wo kann ich evtl. abstriche machen und wo nicht", wo muss ich mich evtl. erstmal schlau lesen.
Ich hätte natürlich auch einfach die i5-4.gen Kombo auf teufel-komm-raus und kopf-durch-die-wand weiterlaufen lassen können. Es ist ja nur ein Bastelprojekt wo das Geld nicht so locker sitzt. Aber in meinen Augen macht das einfach 0,0 sinn. Wer als Hobby gerne Näht und nur noch eine halbkaputte Nähmaschine hat die mal näht und mal unsauber usw ist wird sicher auch schauen die wenn eine reparatur nicht mehr sinnvoll möglich ist auszutauschen.

 

[cabriofahrer]

Leute, es ist ja nicht so, dass ich das alles nicht selber sehe. Dass dieses Teil Müll ist (ich weiss gar nicht, wo es eigentlich herkommt, mein Vater gab es mir vor Jahren und ich hoffe, dass er sich das nicht gekauft hatte, sondern dass das vielleicht ein Werbegeschenk für den Abschluss eines Vertrages oder sonst etwas in der Richtung war), ist mir schon klar. Natürlich ist es irgendwo ein "mit dem Kopf durch die Wand gehen", aber irgendwie habe ich Spass daran, mich mit solchen Dingen zu beschäftigen. Und es bereitet mir sogar Empören und Unverständnis, dass ein namhafter Hersteller wie Intel so etwas überhaupt produziert und dass es damals wohl unzählige unschuldige Opfer gegeben hat, die sich so einen Mist für womöglich ein paar hundert Euro zugelegt haben. Sogar HP hat diesen SoC verbaut. Eigentlich brauche ich gar kein Laptop, Arbeiten tue ich nur mit meinem PC. Aber "tagelang" ist ja auch auch nicht richtig, Fedora war relativ schnell und einfach installiert. Und etwas Tuning ist halt auch etwas interessant. Das mit zwap hatte ich auch festgestellt und deaktiviert und ein traditionelles swap eingerichtet. Und wie ich sehe, gehen die Meinungen zu 32-bit und 64-bit hier auch auseinander.
Letztendlich ist es aber auch meine Sache, wie ich meine Freizeit verbringen will und welchen Zweck ich so einem Teil oder einem Raspi noch verpassen will. Ich bin Musikfan und wenn irgendein Teil noch gut genug dafür ist, es über die Kopfhörerbuchse mit einer Stereoanlage verbinden zu können, ist das OK für mich (ein Gerät mit 4 GB wäre dafür schon wieder ein Overkill). Oder damit mal kurz ins Internet zu gehen, ohne meinen PC benutzen zu müssen.
Es war ja auch nicht falsch, mal über meinen Tellerrand zu gucken und OpenBSD auf gut Glück auszuprobieren und ein Custom-Partitionieren durchzuführen und hier etwas über das besondere Sicherheitsfeature des "Relinking" zu erfahren.
So, jetzt weiter im Text. Leider habe ich hier keine Aussage mehr darüber gelesen, welche Dienste konkret vielleicht noch deaktiviert werden könnten. Auf Plymouth war ich selber gekommen, der Vorschlag hier zu TPM war sehr hilfreich.
Was mir noch einfällt, um die Bootzeit zu verkürzen, wäre auf grub zu verzichten und direkt Booten zu können. Denn wozu braucht man grub eigentlich, wenn man nicht zwischen verschiedenen Betriebsystemen auswählen will?
Dazu habe ich spontan in der Suchmaschine das hier gefunden:

Die ersten beiden Methoden scheinen interessant, welche der beiden würdet Ihr empfehlen, sowohl im Hinblick auf die Bootzeit als auch auf künftige Major-Upgrades von Fedora?

 

[CommanderZed]

Die bootzeit von grub ist doch vermutlich selbst auf dem sehr langsamen system nur 1-2 sekunden, eher weniger, das lohnt sich doch 0 daran rumzubasteln. Wenn dich die meist konfigurierte "Wartezeit" stört kannst du die in der grub config auf 1 sekunde oder so runtersetzen

Der systemd-boot wird kaum schneller sein und das direkte booten ist meine ich keineswegs ein standardweg sondern ganz im gegenteil enorm bastellig.

Eine gute Übersicht der Boatloader die es so gibt findet du hier zb

Arch boot process - ArchWiki

(Bei Archlinux kann man sich ja während der installationen seinen "liebling" aussuchen.

Aber so richtig "lohnen" wird sich das kaum.

Einen bootloader zu haben bei dem man zb auf ältere Kernelversionen zurück gehen kann oder zb etwas an den Bootoptionen ändern kann macht auf jedenfall gerade bei älterer, fehleranfälliger Hardware sinn.

 

[midnight]

Ja und vor allem ist Grub kein Dienst, der im Hintergrund irgendwelche Ressourcen verbraucht. Grub wird nur fuer den Boot benoetigt.

 

[CommanderZed]

Ich vermute am längsten dauert einfach der Kernel-Boot usw - eigentlich ist Linux ja eh sehr Boot-Optimiert und macht dann noch etwas im Hintergrund so das der user schnell angemeldet ist, dtl. mehr als zb OpenBSD würde ich sagen.

Ich bin auch über deine Liste drübergegangen @cabriofahrer aber sowas richtig spannendes hab ich da nicht entdeckt.

Tendenziell sind optimiertere Distros wo du dazu noch sehr viel granularer auswählen kannst was du installierst wie zb Archlinux, Alpine oder Gentoo evtl. da etwas für dich, teilweise bietet auch debian viele Optionen, bei Debian muss man die aber uu manuell auswählen und sind nicht im "Standard" wenn man einfach nur Desktop xyz auswählt (Also zb minimale Installation lieber machen und dann manuell den Loginmanager und Desktop auswählen.) Alle haben eine recht steile Lernkurve insbesondere wenn man während der installation auch noch auf besondere Details achten möchte. Ich empfehle ein ausprobieren und umschauen erst in einer VM und dann das gelernte auf ein echtes Gerät zu übertragen.
Man könnte wenn man das alles gemacht hat schauen ob man den Kernel selbst baut mit Optionen die die Bootzeit verkürzt, aber das ist eine sehr komplexe Wissenschaft für sich wo ich ehrlich gesagt auch raus bin (und auch da ist es fragwürdig ob es überhaupt etwas bringt - gilt für alle diese sachen)

Und es bereitet mir sogar Empören und Unverständnis, dass ein namhafter Hersteller wie Intel so etwas überhaupt produziert und dass es damals wohl unzählige unschuldige Opfer gegeben hat, die sich so einen Mist für womöglich ein paar hundert Euro zugelegt haben. Sogar HP hat diesen SoC verbaut.

Da stimm ich so ein bisschen zu, auch heute noch kann man absurd langsame Geräte noch neu kaufen und Intel & Co vermarkten die auch explizit für Desktop-Geräte und nicht nur für Firewalls oä. Das ist imho schon neu produzierter Elektroschrott. Und auch das es nahmenhafte Hersteller gibt die das dann mit wirklich weiteren sehr sehr billigen Komponenten zu einen PC verarbeiten wie zb HP, halte ich auch für sehr fragwürdig.
Wir hatten so grob in der Zeit mal ein paar ähnlich schnelle Tablets mit ähnlichen Intel-Prozessor auf der Arbeit weil man "unbedingt Tablets" wollte, die sind dann auch irgendwann kaum benutzt in den Elektroschrott gewandert.
Man muss den Kapitalismus einfach gern haben.

 

[berni51]

Im Herbst 2025 hat mir ein Freund von seiner China-Reise drei Boards mitgebracht: Nagelneu, original verpackt, Hersteller MACHINIST, B550-Clones, elegant in weissem Design. Haben zusammen ca. 50 € umgerechnet gekostet.
Alle drei Boards funktionieren einwandfrei und bereiten bis heute keine Probleme. Hab dann ein paar AM4 Ryzen 5 mit VEGA Grafik gebraucht in den Kleinanzeigen gekauft, etliche 32GB DDR4 RAM-Riegel - und jetzt hab ich hier wunderbare Test- und Bastelobjekte auf dem Tisch.
Auf den Kisten ist das Kernel-Reordering quasi überhaupt nicht spürbar, braucht nur einen Kern und ist in wenigen Sekunden beendet.

 

[cabriofahrer]

Ja und vor allem ist Grub kein Dienst, der im Hintergrund irgendwelche Ressourcen verbraucht. Grub wird nur fuer den Boot benoetigt.

War mir schon klar.

Also ich habe mal etwas weiter recherchiert und es scheint wohl doch so zu sein, dass systemd-boot schon was bringen soll, und nicht nur bezüglich der Bootzeit. Allerdings ist es wesentlich einfacher, es mittels der Fedora Everything Netinst ISO Bei einer Frischinstallation einfach auszuwählen, als zu versuchen, es bei einer bestehenden Installation von grub umzustellen. Die Anleitung dazu ist sehr lang und haarig. Außerdem soll Fedora 43 einen anerkannten Bug haben, der diese Option nicht auswählen lässt. Es wird daher empfohlen, 42 zu installieren und auf 43 upzugraden oder auf 44 zu warten. Da ich noch auf 41 bin, werde ich ersteren Weg gehen. Das wird aber wohl nicht in den nächsten Tagen geschehen, da ich wirklich noch Wichtigeres zu tun habe. Melde mich dann zurück, wenn es soweit ist.

Wir hatten so grob in der Zeit mal ein paar ähnlich schnelle Tablets mit ähnlichen Intel-Prozessor auf der Arbeit weil man "unbedingt Tablets" wollte, die sind dann auch irgendwann kaum benutzt in den Elektroschrott gewandert.

Ich hasse Tablets, vor allen Dingen wegen Android.

Man muss den Kapitalismus einfach gern haben.

Ich bin kein Sozialist oder so, aber manche Hersteller gehören wirklich bestraft. Wie oft muss man das Rad neu erfinden, bei Sound- oder Wifichips? Wenn man bedenkt, dass es vor über 30 Jahren schon gute Soundchips gab, die sogar noch für der ISA-Bus waren...
Schade ist auch, dass es bei Notebooks nie die Möglichkeit der Selbstzusammenstellung gab, wie eben bei Desktop-PC's. Aber das bringt jetzt auch nichts.

 

[medV2]

So, jetzt weiter im Text. Leider habe ich hier keine Aussage mehr darüber gelesen, welche Dienste konkret vielleicht noch deaktiviert werden könnten. Auf Plymouth war ich selber gekommen, der Vorschlag hier zu TPM war sehr hilfreich.

Poste doch mal die Ausgabe der systemd-analyze Befehle, die ich hier schon geposted habe.

 

[CommanderZed]

Also ich habe mal etwas weiter recherchiert und es scheint wohl doch so zu sein, dass systemd-boot schon was bringen soll, und nicht nur bezüglich der Bootzeit.

Die Bootzeit vom Bootloader ist wirklich wirklich nur sehr sehr kurz, egal welcher Bootloader
Danach übergeben beide direkt an den kernel der dann den rest übernimmt, was ab diesem moment passiert ist größtenteils komplett unabhängig vom verwendeten Bootloader. Es geht hier also wirklich maximal um wenige Sekunden, vermutlich selbst auf der alten Hardware eher um eine Sekunde oder zwei.
Ich vermute sehr stark das der Kernel dann recht lange braucht bei dir zum Booten, allein schon weil er dabei das initramfs entpackt und das bei der Kombi aus langsamer CPU und langsamer eMMC einfach relativ lange braucht. Da wirst du 875x den Bootloader tauschen können, der Kernel entpackt das immer gleich schnell. Danach initialisiert der Kernel die devices usw was halt auch einfach ne gewisse zeit braucht, mountet das echte root-filesystem und startet dann systemd für den restlichen boot, servicestart und login-prozess. Die Zeit zwischen "Kernel start" und "systemd" ist kaum irgendwie zu verkürzen, außer villeicht mit einem oben erwähnten optimierten kernel und initramfs usw. Aber nochmal: Das geht wirklich sehr stark in die Tiefe und erfordert sehr tiefes Verständniss vom Linux Boot Prozess.

Ps/edit: Ich weiß nicht wie gesprächig der Kernel bei Fedora ist, aber wenn der verschiedene sichtbare ausgaben hat könntest du auch mal nen Video vom gesamten Boot-Prozess bis zum login machen dann kann ich dir evtl (großes evtl!) sagen ob das "normal" aussieht.

 

[cabriofahrer]

"systemd-analyze time" bzw. "systemd-analyze blame" könnten hier sinnvolle Befehle für dich sein. Letzterer zeigt auch die Startuptimes, was alleine nicht immer Aussagekräftig ist, ev noch ein "systemd-analyze critical-chain" hinterher.

Hier die drei Befehle hintereinander:

werner@fedora:~$ systemd-analyze time
Startup finished in 7.630s (firmware) + 8.917s (loader) + 2.405s (kernel) + 7.721s (initrd) + 20.204s (userspace) = 46.878s
graphical.target reached after 20.142s in userspace.
werner@fedora:~$ systemd-analyze blame
11.677s sys-module-fuse.device
11.218s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
11.218s dev-ttyS2.device
11.209s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
11.209s dev-ttyS3.device
11.202s sys-devices-pnp0-00:02-00:02:0-00:02:0.0-tty-ttyS0.device
11.202s dev-ttyS0.device
11.183s dev-ttyS1.device
11.183s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
11.169s sys-devices-platform-80860F0A:01-80860F0A:01:0-80860F0A:01:0.0-tty-ttyS5.device
11.169s dev-ttyS5.device
11.069s sys-module-configfs.device
10.702s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart2.device
10.702s dev-disk-by\x2dpartuuid-fd6bb2cc\x2dfe23\x2d44bf\x2da053\x2da66ac61213bb.device
10.702s dev-disk-by\x2did-mmc\x2dT52732_0x0a79854b\x2dpart2.device
10.702s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2duuid-8618ff13\x2d03cd\x2d439b\x2da728\x2db87f98f98962.device
10.702s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartnum-2.device
10.702s dev-disk-by\x2ddiskseq-1\x2dpart2.device
10.702s dev-mmcblk1p2.device
10.702s dev-disk-by\x2duuid-8618ff13\x2d03cd\x2d439b\x2da728\x2db87f98f98962.device
10.701s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1-mmcblk1p2.device
10.701s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartuuid-fd6bb2cc\x2dfe23\x2d44bf\x2da053\x2da66ac61213bb.device
10.660s dev-mmcblk1boot0.device
10.660s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1-mmcblk1boot0.device
10.660s dev-disk-by\x2ddiskseq-2.device
10.660s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dboot0.device
10.639s dev-disk-by\x2ddiskseq-1\x2dpart1.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartuuid-c6678e2b\x2df59d\x2d44ec\x2dbdf7\x2ddfcad9d89241.device
10.639s dev-disk-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device
10.639s dev-disk-by\x2duuid-50ae05bd\x2d4704\x2d478c\x2da1cf\x2d2ead15a9ee47.device
10.639s dev-disk-by\x2did-mmc\x2dT52732_0x0a79854b\x2dpart1.device
10.639s dev-disk-by\x2ddiskseq-1\x2dpart3.device
10.639s dev-mmcblk1p1.device
10.639s dev-disk-by\x2duuid-00E2\x2dFD2B.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2duuid-00E2\x2dFD2B.device
10.639s dev-disk-by\x2dpartuuid-c6678e2b\x2df59d\x2d44ec\x2dbdf7\x2ddfcad9d89241.device
10.639s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1-mmcblk1p1.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart1.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartlabel-EFI\x5cx20System\x5cx20Partition.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartnum-1.device
10.639s dev-mmcblk1p3.device
10.639s dev-disk-by\x2dpartuuid-77dacd45\x2d1158\x2d4b5e\x2db61b\x2dc96c0a4512eb.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartuuid-77dacd45\x2d1158\x2d4b5e\x2db61b\x2dc96c0a4512eb.device
10.639s dev-disk-by\x2did-mmc\x2dT52732_0x0a79854b\x2dpart3.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2dpartnum-3.device
10.639s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1-mmcblk1p3.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart3.device
10.639s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dpart-by\x2duuid-50ae05bd\x2d4704\x2d478c\x2da1cf\x2d2ead15a9ee47.device
10.630s dev-disk-by\x2dpath-platform\x2d80860F14:00\x2dboot1.device
10.630s dev-disk-by\x2ddiskseq-3.device
10.630s dev-mmcblk1boot1.device
10.630s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1-mmcblk1boot1.device
10.620s sys-devices-platform-80860F14:00-mmc_host-mmc1-mmc1:0001-block-mmcblk1.device
10.620s dev-disk-by\x2ddiskseq-1.device
10.620s dev-disk-by\x2did-mmc\x2dT52732_0x0a79854b.device
10.620s dev-mmcblk1.device
10.620s dev-disk-by\x2dpath-platform\x2d80860F14:00.device
 4.186s initrd-switch-root.service
 3.753s upower.service
 3.481s NetworkManager-wait-online.service
 3.330s accounts-daemon.service
 3.302s udisks2.service
 3.076s firewalld.service
 2.075s NetworkManager.service
 1.623s polkit.service
 1.579s abrtd.service
 1.578s chronyd.service
 1.017s systemd-rfkill.service
 1.012s systemd-tmpfiles-setup.service
  979ms systemd-resolved.service
  885ms systemd-udev-trigger.service
  884ms systemd-logind.service
  874ms user@1000.service
  856ms ModemManager.service
  715ms systemd-journal-flush.service
  711ms bluetooth.service
  646ms systemd-tmpfiles-setup-dev-early.service
  620ms systemd-udevd.service
  611ms var-lib-nfs-rpc_pipefs.mount
  547ms unbound-anchor.service
  547ms switcheroo-control.service
  518ms systemd-vconsole-setup.service
  499ms systemd-oomd.service
  468ms rtkit-daemon.service
  467ms systemd-journald.service
  450ms lm_sensors.service
  448ms avahi-daemon.service
  405ms systemd-hostnamed.service
  354ms dracut-cmdline.service
  340ms rsyslog.service
  333ms dracut-shutdown.service
  319ms systemd-homed.service
  296ms dbus-broker.service
  292ms dracut-pre-pivot.service
  261ms lvm2-monitor.service
  259ms systemd-tmpfiles-setup-dev.service
  257ms audit-rules.service
  243ms dev-mqueue.mount
  239ms dev-hugepages.mount
  239ms sys-kernel-debug.mount
  235ms sys-kernel-tracing.mount
  228ms kmod-static-nodes.service
  222ms smartd.service
  203ms modprobe@drm.service
  201ms initrd-parse-etc.service
  197ms systemd-fsck@dev-disk-by\x2duuid-00E2\x2dFD2B.service
  194ms gssproxy.service
  193ms systemd-backlight@backlight:intel_backlight.service
  185ms dracut-pre-udev.service
  178ms boot-efi.mount
  163ms systemd-userdbd.service
  150ms systemd-modules-load.service
  148ms cups.service
  148ms systemd-network-generator.service
  137ms systemd-remount-fs.service
  133ms auditd.service
  126ms systemd-udev-load-credentials.service
  112ms systemd-sysctl.service
  112ms systemd-update-utmp.service
  101ms wpa_supplicant.service
   99ms initrd-cleanup.service
   98ms dev-disk-by\x2duuid-8618ff13\x2d03cd\x2d439b\x2da728\x2db87f98f98962.swap
   88ms systemd-fsck-root.service
   86ms lightdm.service
   78ms plymouth-start.service
   71ms initrd-udevadm-cleanup-db.service
   71ms user-runtime-dir@1000.service
   66ms modprobe@efi_pstore.service
   65ms modprobe@dm_mod.service
   61ms systemd-random-seed.service
   52ms systemd-update-utmp-runlevel.service
   52ms rpc-statd-notify.service
   51ms modprobe@configfs.service
   51ms systemd-hibernate-resume.service
   49ms systemd-user-sessions.service
   48ms systemd-sysusers.service
   42ms modprobe@loop.service
   39ms tmp.mount
   39ms modprobe@fuse.service
   39ms sys-fs-fuse-connections.mount
  511us systemd-homed-activate.service
werner@fedora:~$ systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @20.142s
└─lightdm.service @20.053s +86ms
  └─systemd-user-sessions.service @19.968s +49ms
    └─remote-fs.target @19.954s
      └─remote-fs-pre.target @16.799s
        └─nfs-client.target @16.799s
          └─gssproxy.service @16.602s +194ms
            └─network.target @16.590s
              └─wpa_supplicant.service @16.487s +101ms
                └─basic.target @9.500s
                  └─dbus-broker.service @9.192s +296ms
                    └─dbus.socket @9.117s
                      └─sysinit.target @9.083s
                        └─systemd-vconsole-setup.service @8.561s +518ms
                          └─run-credentials-systemd\x2dvconsole\x2dsetup.service.mount @8.617s
                            └─systemd-journald.socket
                              └─system.slice
                                └─-.slice
werner@fedora:~$

Die Bootzeit vom Bootloader ist wirklich wirklich nur sehr sehr kurz, egal welcher Bootloader
Danach übergeben beide direkt an den kernel der dann den rest übernimmt, was ab diesem moment passiert ist größtenteils komplett unabhängig vom verwendeten Bootloader. Es geht hier also wirklich maximal um wenige Sekunden, vermutlich selbst auf der alten Hardware eher um eine Sekunde oder zwei.

Gut, das mag ja sein, ich werde es wie gesgt ausprobieren, wenn ich wieder Zeit dazu habe. Mir geht es aber nicht nur darum, sondern auch um den ästhetischen Aspekt. Ich finde grub einfach hässlich und wenn ich ein Gerät einschalte, welches nur ein OS installiert hat, brauche und will ich das einfach nicht. Windows z.B. wirkt ja auch elegant dadurch, dass es sofort bootet. Ist aber nur meine Meinung.

 

[CommanderZed]

Auch Windows hat nen Bootloader der eingaben / ausgaben akzeptiert, ältere Versionen haben den sogar noch angezeigt (2000 z.B.) bei neueren muss man den mit einer Taste beim start anzeigen. Er hat dann sehr ähnliche funktionen und aufgaben wie Bootloader beim Linux.

Eigentlich ist das unabhängig vom Betriebsystem sehr praktisch um halt wenn etwas nicht bootet Kernelparamenter usw mitzugeben die evtl. einen boot wieder ermöglichen. Ich weiß gerade nicht, aber ich meine das man manche auch optisch etwas anpassen kann wenn einen das wichtig ist.

Sowohl bei Grub als auch bei anderen kann man das auch sehr "kurz" einstellen so das es kaum sichtbar ist, die Option aber zu haben lege ich dir wirklich sehr sehr sehr intensiv ans Herz. Wie gesagt, gerade wenn man ein Gerät hat das sich schon öfters als eher zickig dagestellt hat.

Ich kann heute nur kurz draufgucken, aber:

Das einzige was man evtl. optimieren könnte ist das NetworkManager nen moment braucht, da könnte man gucken ob es bei dir reicht das im Hintergrund zu machen. Das ist natürlich aber alles erst die ausgabe NACHDEM der Kernel gebootet ist.

Das hier scheint ja einmal der größte Brocken zu sein:
10.620s dev-disk-by\x2dpath-platform\x2d80860F14:00.device
4.186s initrd-switch-root.service
Das dürfte das mounten des root-filesystems zu sein. Das wird man 0 optimieren können fürchte ich.

Der rest ist ... erstmal sinnvoll und braucht halt auf dem alten System lange.

 

[cabriofahrer]

Das einzige was man evtl. optimieren könnte ist das NetworkManager nen moment braucht, da könnte man gucken ob es bei dir reicht das im Hintergrund zu machen. Das ist natürlich aber alles erst die ausgabe NACHDEM der Kernel gebootet ist.

Das klingt interessant. Wie macht man das?

Sowohl bei Grub als auch bei anderen kann man das auch sehr "kurz" einstellen so das es kaum sichtbar ist, die Option aber zu haben lege ich dir wirklich sehr sehr sehr intensiv ans Herz. Wie gesagt, gerade wenn man ein Gerät hat das sich schon öfters als eher zickig dagestellt hat.

Klingt vernünftig. Ich sehe auch gerade, dass es hunderte von mehr oder weniger schönen Themes für grub gibt, also denke ich, ein schönes Theme und eine verkürzte Bootzeit wären dann auch die einfachste und schnellste Lösung, zumal ich auch keine große Lust habe, nochmal eine Frischinstallation durchzuführen. Ein Major-Upgrade auf 42 oder 43 wäre dann wohl OK. So wie ich das sehe, unterstützt der Prozessor bis x86 x64 v2, richtig? Ich kenne jetzt gerade die Voraussetzungen für Fedora 42 und 43 nicht, aber vor ein paar Tagen hatte ich gesehen, dass das neue Rocky Linux x86 x64 v3 voraussetzt, obwohl es nur Kernelversion 6.12 hat? Oder hatte ich beim kurzen Überfliegen der Webseite da was falsch verstanden? Hatte mich jedenfalls sehr gewundert.

 

[medV2]

Hier die drei Befehle hintereinander:

Wie @CommanderZed schon schrieb, größter Brocken ist hier das RootFS. Ich denke aber da kann man schon noch optimieren, und zwar beim FS. Fedora nimmt standardmäßig btrfs, wenn du eventuell mal neu installierst könntest du das auf XFS abändern. Es braucht weniger Speicher, ist bei der Initialisierung schneller, und du hast nicht andauernd Checksumberechnungen bei Schreib- und Lesevorgängen. Wohlgemerkt alles in nem Umfang, der sich auf halbwegs aktuellen Systemen nicht bemerkbar macht, aber bei deinem Gerät könnte es bemerkbar sein.

Was ich auch noch sehe ist das remotefs.target bzw. nfsclient.target. Letzteres könntest du mal deaktivieren wenn du es nicht brauchst, ersteres ist eh nur ne Abhängigkeit darauf (in der Defaultinstall). Also "systemctl disable nfs-client.target".

edit: Ad CPU Architecture Version: Fedora hat v2, das hat nichts mit der Kernelversion zu tun, sondern wie der Kernel (und die Binaries darum rum) kompiliert werden.

 

[medV2]

Ich hab noch nen zweiten Nachtrag, jetzt als eigener Post: Was mir noch eingefallen ist: Fedora hat default auch SELinux aktiviert, das verursacht auch nochmal Metadaten Reads and Writes. Das kannst du unter /etc/selinux/config deaktivieren, mit "SELINUX=disabled". Danach rebooten.

 

[Andy_m4]

Wobei man sich natürlich fragen sollte, wieviel Sinn es macht Fedora zu nutzen, wenn man alles so verbiegen muss damit es halbwegs läuft.
Mal davon abgesehen, das wegen 64-Bit ohnehin sinnloserweise Ressourcen verbraten werden ohne wirklich von den Vorteilen zu profitieren, weil die Hardware das nicht her gibt.

Statt also ein 64-Bit-Fedora zu nehmen und das dann irgendwie so weit abzurüsten, bis alles passt
würde ich eher mit einem 32-Bit-Linux in Minimal-Installation loslaufen und mir Stück für Stück die Dinge dazu holen, die ich haben will.

Aber das nur so als Idee. :-)
Und ja. Ich hab mitbekommen, das Neuinstallation nicht gewünscht ist. Aber wenn die Alternative ist, tagelang herumzubasteln, dann hätte man in der Zeit schon 10x neu installieren können. :-)

 

[CommanderZed]

Da ich momentan viel Archlinux verwende würde ich ein Archlinux als Basis empfehlen, aber evtl. wäre ein Debian besser da etwas einsteigerfreundlicher.

Ich wäre abe rauch eher für 64bit muss ich sagen, der Speichermehrverbrauch ist in der Praxis oft sehr viel geringer als angenommen, es wird heute fast alles für 64bit optimiert und getestet und der langsame Prozessor wird mit 64bit vermutlich noch ne idee schneller sein als unter 32bit.

De-Facto wird jeder Browser das ding zum Swappen bringen (egal ob 32bit oder 64bit) und das will man nicht, erst recht will man das nicht mit ner ultra-langsamen eMMC

(ich frag mich generell etwas ob wir die langsame 32gb eMMC evtl. bei dem Performancedebakel evtl. zu wenig ins licht rücken)

 

[cabriofahrer]

Wie @CommanderZed schon schrieb, größter Brocken ist hier das RootFS. Ich denke aber da kann man schon noch optimieren, und zwar beim FS. Fedora nimmt standardmäßig btrfs, wenn du eventuell mal neu installierst könntest du das auf XFS abändern. Es braucht weniger Speicher, ist bei der Initialisierung schneller, und du hast nicht andauernd Checksumberechnungen bei Schreib- und Lesevorgängen. Wohlgemerkt alles in nem Umfang, der sich auf halbwegs aktuellen Systemen nicht bemerkbar macht, aber bei deinem Gerät könnte es bemerkbar sein.

Ich hatte damals ext4 ausgewählt.

edit: Ad CPU Architecture Version: Fedora hat v2, das hat nichts mit der Kernelversion zu tun, sondern wie der Kernel (und die Binaries darum rum) kompiliert werden.

Ist mir schon klar. Aber was mich eben gewundert hatte, ist dass Rocky Linux einerseits schon für v3 optimiert ist, aber andererseits noch eine so alte Kernelversion (6.12) hat.

De-Facto wird jeder Browser das ding zum Swappen bringen (egal ob 32bit oder 64bit) und das will man nicht, erst recht will man das nicht mit ner ultra-langsamen eMMC

(ich frag mich generell etwas ob wir die langsame 32gb eMMC evtl. bei dem Performancedebakel evtl. zu wenig ins licht rücken)

Nun, wenn man nicht zu viele Tabs offen hat, dann nicht. An der eMMC kann man leider nichts machen, die ist im SoC fest verbaut, dass hatte ich damals schon nachgeguckt in der Hoffnung, dass man die vielleicht auswechseln könnte. Das ist mal wieder so ein Punkt, wo die Hersteller manchmal "bestraft" gehören. Ich glaube kaum, dass man mit einer externen MicroSD-Karte (der Steckplatz ist ja vorhanden) mehr erreichen könnte.
Im Übrigen teile ich auch die Meinungen hier zugunsten von 64-bit.
Und nochmal zum Argument "tagelang". Wir sind hier zwar seit Tagen am Plaudern, aber die Ratschläge, die ich hier sammele, sind in ein paar Minuten oder gar Sekunden umgesetzt. Seinerzeit hat man ja auch immer an Windows herumgetuned, um bessere Performance und mehr Speicher zu bekommen. Jahrelang haben Computerzeitschriften sich dem Thema Windows-Tuning gewidmet und irgendwelche Tools sogar auf CD mitgeliefert.
Ist jetzt also auch nicht weiter schlimm. Und es gibt auch noch andere Gründe, warum mir Fedora einfach besser gefällt.

 

[medV2]

Ich hatte damals ext4 ausgewählt.

Ich kenne jetzt die ext4 Defaults auf Fedora nicht, aber normal nutzt ext4 ein komplettes Journaling aller Daten, was man aus Performancegründen auf reines Metadatenjournaling umstellen kann (Default bei XFS).

Dazu musst du in der fstab bei deinem root-Mount unter Options "data=writeback" einfügen. Für die Bootgeschwindigkeit dürfte das aber nichts beitragen, das wirkt sich nur auf Schreibvorgänge aus.

Ich würde auf jedenfall SELinux deaktivieren wie ich geschrieben habe, zumindest früher mal, war das langsam unter ext4 (uA ein Grund, wieso RHEL auf XFS als Defaultdateisystem gewechselt ist, aber ist schon Jahre her, ob das noch relevant ist, weiß ich nicht).

 

[Andy_m4]

der Speichermehrverbrauch ist in der Praxis oft sehr viel geringer als angenommen

Mag sein. Trotzdem kann das entscheidend sein.

und das will man nicht, erst recht will man das nicht mit ner ultra-langsamen eMMC

Eben. Insbesondere deshalb zählt da jedes Megabyte.

De-Facto wird jeder Browser das ding zum Swappen bringen

Mag sein. Aber wenn schon Mozilla selbst für seinen 64-Bit-Firefox doppelt so viel RAM veranschlagt wie für die 32-Bit-Variante, dann kann man das auch schlecht ignorieren. Selbst wenn man davon aus geht, das es im Real-Life nur 30% mehr ist.
Bei 2GB hast Du halt wenig Luft.
Soviel kannst Du über CPU und optimierten 64-Bit-Code gar nicht rausholen, als das auch nur ein kleiner Swap-Bedarf damit wettgemacht wird.

Wobei bezüglich Browser ohnehin die Frage ist, ob man dann nicht einen der üblichen Verdächtigen nutzt, sondern eher einen schlanken Browser wie beispielsweise Midori oder Epiphany.

Im Übrigen teile ich auch die Meinungen hier zugunsten von 64-bit.

Man braucht da keine "Meinung" zu haben.
Man kann einfach nachschauen. Kommt es beim Betrieb nennenswert zu Swapping dann ist 32-Bit schneller. Wenn nicht, dann kann man getrost bei 64-Bit bleiben.

Ich hab hier ein 32-Bit Debian mit LXQt-Desktop. Hab den RAM auf 2GB begrenzt.
Wenn ich das frisch starte und dazu noch einen leeren Firefox öffne bin ich bei 950 MB RAM-Bedarf (das System genehmigt sich dann noch zusätzlich ein paar hundert Megabye für Cache und Buffer).

Jetzt mal so als Referenzwert für etwaige eigene Beobachtungen/Messungen.

 

[Azazyel]

Ist mir schon klar. Aber was mich eben gewundert hatte, ist dass Rocky Linux einerseits schon für v3 optimiert ist, aber andererseits noch eine so alte Kernelversion (6.12) hat.

Rocky Linux ist ein RHEL-Klon. RHEL unterstützt eine Kernel-Version über den gesamten Lebenszyklus (mindestens 13 Jahre).

RHEL 10 ist im Juni 2025 erschienen. Damals war 6.12 die neueste LTS-Version des Kernels (erschienen November 2024).

Optimierung für v3 heißt, jede CPU ab 2013-2015 zu unterstützen.

Der Kernel ist also deutlich neuer als die unterstütze Hardware sein darf.