Eure Meinung zu Fedora

M

MasterMito

Member
Themenstarter
Registriert
21 Nov. 2006
Beiträge
227
Hallo,

irgendwie finde ich hier im Forum recht wenig zum Thema Fedora (SuFu findet mir nix). Wie sind die Erfahrungen damit auf Thinkpads (speziell T400)? Überlege gerade von Ubuntu zu Fedora zu wechseln (mein Bauch sagt es ist richtig, mein Kopf zweifelt).

Wäre nett wenn der eine oder andere Fedora-Nutzer sich meldet.
 
Danke für die Hinweise. Ich habe jetzt sendmail entfernt, und die dicken Brocken tauchen in der Liste nach "systemd-analyze blame" nicht mehr auf. Trotzdem dauert Booten noch sehr lange (beachte: SSD und i7); es hat sich fast nicht oder garnicht verkürzt. Nach der Auswahl der kernelnummer dauert es gut 22 Sek. bis zum erscheinen der Loginmaske. Bevor der Bootsplash erscheint vergehen ca. 5 Sek., und ähnlich viel nochmal zwischen Verschwinden des Bootsplashs und der Erscheinen des GDM.
 
Und was zeigt:

Code: 
systemd-analyze time
Startup finished in 1773ms (kernel) + 7757ms (initramfs) + 4480ms (userspace) = 14011ms
 
Code: 
$ systemd-analyze time
Startup finished in 2243ms (kernel) + 2359ms (initramfs) + 9800ms (userspace) = 14403ms
Übrigens ist Mint 12 mit 20 Sek. auch nicht viel schneller als F16 (22 Sek.). Allerdings lagen Mint 11 und Ubuntu 10.10 eher so bei 12-14 Sek.
 
Bei mir gehen fast 8s für die initramfs drauf. Ich komme da noch auf 4s runter aber crypt/dm/btrfs usw. brauch ich eben....
Fast 10s Userspace.. da kannst du noch einiges herausholen.
1.) Dienste die nicht benötigt werden abschalten:
Code: 
systemctl list-units --all | grep running
2.) Programme aus dem Autostart nehmen die nicht benötigt werden:
Code: 
ls -la /etc/xdg/autostart
3.) Programme aus Cron nehmen die nicht benötigt werden
Code: 
 ls -l /etc/cron.*/
4.) Programme aus dem Networkmanager (dispatcher) nehmen die nicht benötigt werden
Code: 
ls -la /etc/NetworkManager/dispatcher.d/

Hier Mal als Beispiel (ein Teil) meiner /etc/rc.d/rc.local:
http://fpaste.org/EJyG/
 
Hallo kalibari, danke für die Tipps.

Ich habe einfach mal die Abschnitte bzgl. Autostart und Systemd in mein /etc/rc.d/rc.local kopiert. Habe auch /etc/mybackup/* angelegt. Aber nach dem Start sind diese Verzeichnisse weiterhin leer, obwohl das Verzeichnis /etc/xdg/autostart "voll" ist. Mache ich etwas falsch? Und abgesehen davon, was passiert, wenn ich die Dateien im autostart Verzeichnis lösche? Tauchen einige davon nach einer Zeit wieder auf?
 
Hallo, der Grund warum ich alles nach /etc/mybackup verschiebe, ist, dass es sich zur Not wieder leicht rückgängig machen lässt. Löschen kann man natürlich manuell auch. Bei einem Update des Programms wird der Starter allerdings dann wiederhegestellt. Man sollte aber wissen was man da löscht/verschiebt, es kann zu Problemen kommen oder eventuell fährt der Rechner nicht mehr vollständig hoch....

Das Grundgerüst der /etc/rc.d/rc.local sieht so aus:

Code: 
nano /etc/rc.d/rc.local
#!/bin/sh

# Script


exit 0

Danach ein chmod 700 /etc/rc.d/rc.local Zm Testen braucht man nich zwingend neu starten sondern einfach /etc/rc.d/rc.local in die Konsole eingeben.
 
Ich hab heute mal ein bißchen mit F17 herumgespielt:

  • Booten und Shutdown dauern ewig
  • DKMS tut nicht (das Binary heißt komischerweise /usr/sbin/dkms.old)
  • Die GUI für die Firewall ist nicht fertig, der firewalld aber schon installiert (na gut, ausschalten per systemctl geht immerhin)
Ich glaube das Thema braucht noch etwas Zeit ...
 
@kalibari

Ich hatte das "exit 0" weiter oben vergessen :facepalm:
 
linrunner schrieb:
Ich hab heute mal ein bißchen mit F17 herumgespielt:

  • Booten und Shutdown dauern ewig
  • DKMS tut nicht (das Binary heißt komischerweise /usr/sbin/dkms.old)
  • Die GUI für die Firewall ist nicht fertig, der firewalld aber schon installiert (na gut, ausschalten per systemctl geht immerhin)
Ich glaube das Thema braucht noch etwas Zeit ...
Zum Vergrößern anklicken....

Ja, die Beta lief noch vor einer Woche Besser als jetzt... Immerhin gibt es schon Bugreports wegen dem booten/shutdown/dkms
 
Zuletzt bearbeitet:
Also ich kann nicht behaupten, dass mich die Arbeiten an der Datei rc.local effektiv weitergebracht haben. Zwischendurch hat sich die Boot-Zeit sogar verlängert. :facepalm: Vielleicht schalte ich auch die falschen Services ab? Dabei sind in der blame-Liste einige dicke Brocken weggefallen. (Aber vielleicht sind es jetzt mehr?) Und selbst wenn ich es durch Aufwand um 0,5 Sek. beschleunigen kann, lohnt sich das m. E. nicht. Aber trotzdem vielen Dank für die Tipps.
 
OK, ich werde bei Gelegenheit Mal testen, wieviel es bei mir effektiv ausmacht. Der eigentliche Grund ist bei mir eigentlich nie die Zeitersparnis gewesen, sondern eher der Gedanke, es soll wenn möglich nur das Laufen, was ich auch benötige.
Der Zeitunterschied im Userspace (ich hab nochmal geschaut, unter F16 waren es bei mir 7017ms) also knapp 3s , kann aber auch andere Ursachen haben, eventuell andere Programme etc. Möglicherweise auch die Hardware aber mit einem X201 + Luks hab ich da vermulich keine Vorteile.. Bei der initramfs konnte ich durch Anpassen der /etc/dracut.conf und neues Erstellen effektiv ~2,5 s herausholen, aber da ist bei dir ja bedingt durch die Konfiguration kaum Luft nach oben.
 
ein 'sudo yum update' von heutemorgen bringt offensichlich eine Verbesserung der beschriebenen Probleme:

Code: 
May 02 07:13:33 Updated: 12:dhcp-libs-4.2.4-0.4.rc1.fc17.x86_64
May 02 07:13:33 Updated: 12:dhcp-common-4.2.4-0.4.rc1.fc17.x86_64
May 02 07:13:33 Updated: device-mapper-multipath-libs-0.4.9-25.fc17.x86_64
May 02 07:13:33 Updated: kpartx-0.4.9-25.fc17.x86_64
May 02 07:13:40 Updated: python-libs-2.7.3-6.fc17.x86_64
May 02 07:13:40 Updated: python-2.7.3-6.fc17.x86_64
[COLOR=#ff0000]May 02 07:13:40 Installed: systemd-sysv-44-7.fc17.x86_64[/COLOR]
May 02 07:13:40 Updated: libX11-common-1.4.99.901-2.fc17.noarch
May 02 07:13:41 Updated: libX11-1.4.99.901-2.fc17.x86_64
May 02 07:13:41 Updated: clutter-1.10.4-1.fc17.x86_64
May 02 07:13:41 Updated: device-mapper-multipath-0.4.9-25.fc17.x86_64
May 02 07:13:41 Updated: 12:dhclient-4.2.4-0.4.rc1.fc17.x86_64
May 02 07:13:41 Updated: ibus-hangul-1.4.1-2.fc17.x86_64



@linrunner
finde ich gut, dass du dir F17 mal näher angeschaut hast. und deine Krtik ist berechtigt.

P.S.
Code: 
systemd-analyze time
Startup finished in 1084ms (kernel) + 3035ms (initramfs) + 8620ms (userspace) = 12740ms
 
Zuletzt bearbeitet:
@kalibari

Wie auch immer, bei sowas lerne ich immer ein wenig dazu. Denn bei solchen Dingen habe ich sicherlich noch Nachholbedarf. Insofern sind solche Tipps so oder so hilfreich. :)
 
Also was auf jeden Fall Zeit kostet, wenn Dienste nicht richtig gestartet werden können und dann im Status failed stehen systemctl --failed. Unter F16 hatte ich das Problem aber eigentlich nicht, erst seit F17 Beta.
 
Stichwort UMTS/WWAN

im ThinkWiki heißt es zum Thema "Fedora Schnelleinstieg" sinngemäß, dass die meisten internen Karten out-of-the-box erkannt und unterstützt werden - dem ist leider nicht so.
habe hier eine Gobi 1000 und stelle folgendes fest:

- F16 erkennt die Karte nicht.
- F17 erkennt die Karte, der Networkmanager bietet jedoch kein mobiles Breitband an - hier die Ausgabe von lsusb:

Code: 
Bus 001 Device 003: ID 03f0:201d Hewlett-Packard un2400 Gobi Wireless Modem (QDL mode)

im Internet habe ich das hier gefunden:

http://vinzv.de/umts-mit-qualcomm-gobi-2000-unter-fedora-15/

allerdings bezieht sich der workaround auf eine Gobi 2000 und Fedora 15.

ich möchte die Karte gern unter Fedora 16 nutzen - für Tipps und Links etc. wie immer, besten Dank im voraus!
 
Das steht ja auch in einem Thinkwiki und bezieht sich vermutlich auch deshalb auf Thinkpads :-) Schau Mal hier: http://sanitarium.se/wiki/HP_un2400_3G_modem_in_Linux sollte so ähnlich funktionieren wie bei der Gobi 2000. Ist auch im Wiki beschrieben, Windows Firmware entpacken, die richtigen Dateien nach /lib/firmware/gobi kopieren und danach mit dem Gobi Loader die Firmware laden.
 
Die Karte hat noch keine Firmware geladen, was man am QDL Mode sieht. Wie Kalibari schon schrieb, brauchst Du die Firmware aus einer Windows-Installation. Danach analog Wiki vorgehen.

Das direkte Entpacken der Windows-Treiberdatei unter Wine könnte funktionieren, muss aber nicht. Bei den neuesten Gobi2000-Treibern geht es z.B. nicht mehr. Viel Erfolg!

simpel schrieb:
im ThinkWiki heißt es zum Thema "Fedora Schnelleinstieg" sinngemäß, dass die meisten internen Karten out-of-the-box erkannt und unterstützt werden - dem ist leider nicht so.
Zum Vergrößern anklicken....
Für ThinkPads hält die Aussage. Die Ausnahmen bei ThinkPads liste ich im Ubuntu Schnelleinstieg auf.
 
erstmal Danke für eure Antworten!

und was für eine Frickelei mit dieser 'Gobi1000' :mad:

meine Anmerkung in Bezug auf den 'Fedora Schnelleinstieg' im ThinkWiki ist so zu verstehen, dass die betreffende Karte eventuell auch in ThinkPads im Einsatz ist...
mir scheint fast, dass alle Gobi-Karten 'Designed for Windows' sind!?

doch zurück zu meinem Anliegen - den Versuch mittels Wine an die betreffenden Dateien ranzukommen habe ich abgebrochen, um dann extra für diesen Zweck eine Windows-Installation aufzusetzen. Doch wer meint, eine Basisinstallation würde genügen, der wird eines Besseren belehrt.

nachdem ich nun Windows die Firmware der Karte entlockt hatte - bei der Gobi1000 sind es die beiden Dateien amss.mbn und apps.mbn im Ordner 0 - musste nun in F16 der Gobi-Loader installiert werden, welcher in den Standard-Repos nicht verfügbar ist. Also mussten erstmal die 'Development Tools' installiert werden, um schließlich das benötigte rpm installieren zu können. bis dahin war es dann schon nach Mitternacht... :rolleyes:
dann der schnelle Versuch, ob die Karte nun wenigstens läuft - doch dem ist nicht so. na ja, am Abend geht es weiter...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben