Eure Meinung zu Fedora

[MasterMito]

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.

 

[yatpu]

ah, it's not a bug, it's a feature

 

[Bentallica]

Hallo,

ist hier zufällig jemand dabei, der Fedora 16 mit XFCE benutzt. Aus irgendeinem Grund haben im Laufe der letzten Woche
diverse Hotkeys ( für die Batterieinfos, Suspend und Helligkeitsregelung) aufgehört zu funktionieren. Und das komischerweise
nur, wenn ich eingeloggt bin, im GDM funktioniert das ganze hingegen einwandfrei, ist also ein XFCE Problem würde ich mal sagen.

Es kamen keine Updates für XFCE in den letzten Tagen rein, soweit ich das über yum history nachvollzogen habe. Folgende Dinge habe
ich getestet:

1. yum reinstall bash, kein Witz, habe ich irgendwo im Netz gefunden, hat aber nichts gebracht
2. dem Kernel die folgende Bootoption mitgegeben "acpi_backlight=vendor", dadurch funktioniert zumindest
die Helligkeitsregelung wieder

Jetzt weiß ich nicht weiter und dachte, ich frage mal hier nach. Ansonsten mache ich einen neuen Thread auf.

Gruß

 

[tuxor1337]

sehr rätselhaft. ich würde sagen. lege einen neuen benutzer an, logge dich mit dem in xfce ein und schaue, ob es da geht. dann kannst du immernoch in deinem home-verzeichnis sämtlich xfce-einstellungen entfernen und beim nächsten login neu erstellen lassen. aber welche dateien und verzeichnisse du da jetzt genau löschen müsstest, kann ich dir natürlich nicht auf anhieb sagen.

 

[simpel]

bin mir nicht ganz sicher und kann es von hier auch nicht überprüfen, ich meine jedoch, dass erst kürzlich X11-Pakte aktualisiert wurden...

 

[Bentallica]

Der Hinweis mit einem neuen Benutzer hat die Lösung gebracht, denn bei einem neuen Benutzer hat alles funktioniert.
Anschließend habe ich das Verzeichnis ~/.config/xfce4 komplett gelöscht, einmal ab- und angemeldet und schon ging wieder
alles. Ich musste nur alle Einstellungen wieder herstellen, welche natürlich gelöscht wurden.

Jetzt fragt aber nicht, woran das gelegen hat bzw. was ich da verstellt haben soll?!?

Danke und Gruß

 

[simpel]

schau dir doch spasseshalber mal das letzte Update an, bevor das Problem aufgetreten ist...jeweils mit Root-Rechten:

yum history

...und du erhälst in Spaltenübersicht die history list als Ausgabe.
unter Verwenung der ID der ersten Spalten bekommst du genaue Infos angezeigt...

yum history info "ID"

vielleicht lässt sich so die Ursache finden?


P.S.
ich lese gerade, so klug warst du selbst schon, hast du alles schon gecheckt...gut dann.

 

[simpel]

Die Frage hatte ich auch schonmal. Da ich auf F16 LVM verwende, ist die Frage (für mich) nicht so leicht zu beantworten. Mir wurde hier im Forum gesagt, das ginge in Ordnung. Aber da ich die Vorgaben der Partitionsgrößen beim Installieren geändert habe, wäre ich da nicht 100pro sicher, auch wenn ich darauf geachtet habe, dass alle Zahlen durch 2048 teilbar waren, falls das überhaupt einen Unterschied macht. Ähnlich ist es mit TRIM. Aber wenn du nicht LVM benutzt, sollte alles sowieso kein Problem sein.

hatte mal bei der Installation von Debian stable als Dualboot-Systen LVM als Dateisystem gewählt, dass war das absolute Chaos hinterher - seitdem habe ich von LVM die Finger gelassen.

für eine SSD soll ja btrfs optimal sein - dass wird wohl leider noch 3-5 Jahre dauern, bis die Entwicklungsphase abgeschlossen ist. vielleicht sollte ich solange mit der Anschaffung warten. dann gibts die SSD ab 19,90

 

[dirkk]

Fazit: moderne Distris machen anscheinend alles automatisch richtig .

Wie kommst du zu diesem Fazit? (Ich meine: in Bezug auf LVM.)

 

[kalibari]

Ich hab ein dkms Paket erstellt und es im Wiki http://thinkwiki.de/Fedora_Schnelleinstieg#Akku-Ladeschwellen_setzen ergänzt. Unter F17 Beta ist noch bedingt durch einen Bug zuvor ein "mv /usr/sbin/dkms.old /usr/sbin/dkms" notwendig. Das mit dem akmod ist mir nicht klar. Warum heisst das Paket akmod-tp_smapi..i686.rpm und nicht noarch? Vielleicht kann das jemand im Wiki aktualisieren. Mfg kalibari

 

[linrunner]

Cool. Allerdings solltest Du besser noch die aktuelle von Zhenech gepflegte Version 0.41 verwenden: https://github.com/evgeni/tp_smapi

 

[kalibari]

OK und ich hab mich schon gewundert wie manche Pakete auf 0.41 kommen.

 

[simpel]

habe jetzt F17 auf einer Intel G2 Postville installiert. das Booten und auch sonst geht nun alles sehr flott - einzig das Runterfahren dauert manchmal sehr lange, bis zu einer Minute. woran mag es wohl liegen?

hier mal meine /etc/fstab:

# /etc/fstab
# Created by anaconda on Wed Apr 25 18:54:49 2012
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
tmpfs                                     /tmp                    tmpfs   nodev,nosuid,size=1G    0 0
UUID=1101fac5-3fe6-4752-8a58-9ac9e9dbedc3 /                       ext4    defaults,discard,data=writeback,noatime,commit=15     1 1
UUID=d7dd90ea-b6a0-45f0-8687-15e238075747 /home                   ext4    defaults,discard,data=writeback,noatime,commit=15     1 2
UUID=f08c4404-a38a-4731-8e2c-8fd082c634f2 swap                    swap    defaults        0 0

und hier die Ausgabe von /bin/mount:

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel)
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=1519848k,nr_inodes=379962,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
/dev/sda1 on / type ext4 (rw,noatime,seclabel,user_xattr,commit=15,barrier=1,data=writeback,discard)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel)
configfs on /sys/kernel/config type configfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=1048576k)
/dev/sda3 on /home type ext4 (rw,noatime,seclabel,user_xattr,commit=15,barrier=1,data=writeback,discard)
gvfs-fuse-daemon on /run/user/adore/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

 

[dirkk]

Bei mir dauern Boot und Shutdown bei F16 beide deutlich länger als bei Mint 12. Von der Theorie her sollte Systemd doch eigentlich schneller sein, oder? Und selbst Mint 12 ist da deutlich langsamer als Mint 11. Liegt es an den gewachsenen Kernels?

P.S. Ich bin mir noch nicht sicher, ob ich F17 installieren werde (wenn, dann erst in 2-3 Monaten), oder bis F18 warte.

 

[kalibari]

@simpel falls du tp_smapi_dkms-0.41-1dkms.noarch.rpm installiert hast, dann deinstalliere es und installiere es erneut. Mit dem letzten Kernelupdate wurde das Modul zwar installiert aber nicht neu gebaut. Das liegt wohl an der Standart common.postinst. Ich werde das sobald ich Zeit hab korrigieren.

 

[Bentallica]

Nabend!

Bei mir dauern Boot und Shutdown bei F16 beide deutlich länger als bei Mint 12. Von der Theorie her sollte Systemd doch eigentlich schneller sein, oder? Und selbst Mint 12 ist da deutlich langsamer als Mint 11. Liegt es an den gewachsenen Kernels?

P.S. Ich bin mir noch nicht sicher, ob ich F17 installieren werde (wenn, dann erst in 2-3 Monaten), oder bis F18 warte.

Zeig mal bitte die Ausgabe von "systemd-analyze blame".

Gruß

 

[dirkk]

Zeig mal bitte die Ausgabe von "systemd-analyze blame".

$ systemd-analyze blame
 60442ms sm-client.service
 60121ms sendmail.service
  3466ms bluetooth.service
  2991ms console-kit-log-system-start.service
  2850ms NetworkManager.service
  2642ms avahi-daemon.service
  2523ms abrt-vmcore.service
  2507ms rsyslog.service
  2452ms yum-updatesd.service
  2441ms irqbalance.service
  2426ms sshd-keygen.service
  2391ms mcelog.service
  2300ms abrt-ccpp.service
  2293ms acpid.service
  2201ms iptables.service
  2194ms ip6tables.service
  2175ms auditd.service
  1886ms udev-settle.service
  1611ms dbus.service
  1555ms livesys.service
  1472ms fedora-wait-storage.service
   674ms systemd-tmpfiles-setup.service
   665ms systemd-logind.service
   307ms netfs.service
   288ms iscsid.service
   163ms fedora-storage-init.service
   156ms fcoe.service
   155ms udev-trigger.service
   144ms systemd-readahead-collect.service
   131ms fedora-loadmodules.service
   127ms systemd-remount-api-vfs.service
   123ms remount-rootfs.service
    97ms systemd-readahead-replay.service
    91ms systemd-sysctl.service
    85ms fedora-storage-init-late.service
    85ms systemd-vconsole-setup.service
    77ms mdmonitor-takeover.service
    69ms sandbox.service
    69ms dev-mqueue.mount
    68ms media.mount
    58ms dev-hugepages.mount
    55ms sys-kernel-security.mount
    50ms lvm2-monitor.service
    48ms sys-kernel-debug.mount
    44ms boot.mount
    42ms fedora-readonly.service
    34ms sys-kernel-config.mount
    28ms rc-local.service
    28ms udev.service
    23ms colord.service
    23ms livesys-late.service
    19ms console-kit-daemon.service
    18ms tmp.mount
    10ms systemd-user-sessions.service
     6ms home.mount
     4ms accounts-daemon.service
     3ms rtkit-daemon.service
     0ms sys-fs-fuse-connections.mount

Mir scheint, das sieht verbesserungsfähig aus...

 

[linrunner]

@simpel: schalte mal probehalber vor dem Herunterfahren den Funk (Bluetooth, WLAN, ...) aus.

 

[simpel]

@kalibari
danke für den Hinweis - tp_smapi ist nicht installiert.

@linrunner
IRDA ist im BIOS deaktiviert - Bluetooth und WLAN sind standardmäßig abgeschaltet, und wird eingeschaltet, wenn es benötigt wird.

merkwürdig ist ja, dass das Herunterfahren nicht immer so lange dauert, sondern nur hin und wieder...

P.S.
wie managt ihr eigentlich eure SSD unter Fedora/Linux?
leider gibt es die Intel Tool Box, sowie andere SSD Tools nur für Windows. und ich sehe ja nicht ein, dass ich mir deshalb ein Windows OS auf die SSD installiere.

 

[kalibari]

Also, tp_smapi_dkms hab ich aktualisiert und es hat fehlerfrei gegen zwei neue Kernels gebaut.
@simpel zu dem shutdown- Thema gibt es schon einen Bugreport https://bugzilla.redhat.com/show_bug.cgi?id=816842
@dirkk also eigentlich kannst du alle Dienste abschalten, die du nicht brauchst Sendmail hab ich sogar komplett entfernt "yum erase --remove-leaves sendmail".
Andere Dienste deaktiviere ich dauerhaft über die rc.local als Beispiel iscid.service:

case "$(systemctl is-active iscsid.service)" in active* )
systemctl stop iscsid.service
systemctl disable iscsid.service;esac

P.S. und Grub2 hat es auch erwischt https://bugzilla.redhat.com/show_bug.cgi?id=817187

 

[yatpu]

@ simpel:
entweder die dateisysteme mit der mount-option "discard" mounten, oder gelegentlihc fstrim ausführen. das geht auch per cron-job. beide varianten sorgen dafür, dass der ssd gelöschte sektoren per trim-befehl gemeldet werden. die erstere varianteper fstab mögen allerdings nicht alle ssds: meine crucial c300 wurde richtig träge dadurch und das gesamte system ebenfalls. seitdem benutze ich fstrim.