Fedora 18

Code:
#
UUID=eca5180c-1b62-4ece-aedd-34ddbd898ffe /                       btrfs   ssd,subvol=root,noatime     1 1
UUID=7c985711-aaac-44d2-ae4b-5160a693fc13 /boot                   ext4    defaults        1 2
UUID=eca5180c-1b62-4ece-aedd-34ddbd898ffe /home                   btrfs   ssd,subvol=home,noatime,comment=systemd.automount     1 2
UUID=fbb032a0-ca9d-44f8-ba47-0b3a117dbe5f swap                    swap    defaults        0 0
tmpfs       /tmp        tmpfs    defaults,noatime,size=20%,mode=1777    0  0
tmpfs       /var/tmp    tmpfs    defaults,noatime,size=5%,mode=1777     0  0

vielen Dank, dass ich mir deine fstab näher anschauen konnte.

für meine Zwecke plane ich die Installation wie folgt:

- eine separate Boot-Partition soll ab Grub2 V. 1.99-6 nicht mehr erforderlich sein.
- wer suspend-to-disk (Hibernation) nicht benutzt und über >3 GB RAM verfügt, kann auf die Swap-Partition ebenfalls verzichten.
- eine separate Home-Partition ist für ein Test-System nicht erforderlich.

die Installation der Btrfs-Tools (btrfs-progs) ist zu empfehlen - das darin enthaltene Tool btrfsck kann Probleme im Dateisystem beheben.

https://wiki.archlinux.org/index.php/Btrfs

https://btrfs.wiki.kernel.org/index.php/Getting_started
 
Wow, hätte nicht gedacht, dass das schon so viele benutzen - wo es doch noch nichtmal offiziell raus ist.
Ich glaube ich warte noch ein paar Wochen, verfolge gespannt euren Thread und werde es dann auch mal ausprobieren.

Das Problem mit dem Lag nach der Windowstaste in der Gnomeshell hatte ich bis jetzt bei Gnome 3.0, 3.2 und 3.4 schon - ihr auch?
 
ich konnte es mir nicht verkneifen und habs mal installiert. Allerdings bekomme ich bei der Installation des tp-smapi Kernelmoduls für TLP folgenden Fehler:13:19:48 : ERROR: Abhängigkeitsauflösung wurde mit Fehlern beendet13:19:48 : ERROR: Paket: glibc-2.16-24.fc18.i686 (fedora) Benötigt: glibc-common = 2.16-24.fc18 Installiert: glibc-common-2.16-28.fc18.x86_64 (@updates-testing) glibc-common = 2.16-28.fc18 Verfügbar: glibc-common-2.16-24.fc18.x86_64 (fedora) glibc-common = 2.16-24.fc1813:19:48 : ERROR: Paket: rpm-build-4.10.1-3.fc18.x86_64 (fedora) Benötigt: rpm = 4.10.1-3.fc18 Installiert: rpm-4.10.2-1.fc18.x86_64 (@updates-testing) rpm = 4.10.2-1.fc18 Verfügbar: rpm-4.10.1-3.fc18.x86_64 (fedora) rpm = 4.10.1-3.fc18
 
ich konnte es mir nicht verkneifen und habs mal installiert. Allerdings bekomme ich bei der Installation des tp-smapi Kernelmoduls für TLP folgenden Fehler:13:19:48 : ERROR: Abhängigkeitsauflösung wurde mit Fehlern beendet13:19:48 : ERROR: Paket: glibc-2.16-24.fc18.i686 (fedora) Benötigt: glibc-common = 2.16-24.fc18 Installiert: glibc-common-2.16-28.fc18.x86_64 (@updates-testing) glibc-common = 2.16-28.fc18 Verfügbar: glibc-common-2.16-24.fc18.x86_64 (fedora) glibc-common = 2.16-24.fc1813:19:48 : ERROR: Paket: rpm-build-4.10.1-3.fc18.x86_64 (fedora) Benötigt: rpm = 4.10.1-3.fc18 Installiert: rpm-4.10.2-1.fc18.x86_64 (@updates-testing) rpm = 4.10.2-1.fc18 Verfügbar: rpm-4.10.1-3.fc18.x86_64 (fedora) rpm = 4.10.1-3.fc18

Da du keine Code Tags eingesetzt hast und ich mich nicht durch solchen Kauderwelsch quälen will: sieht nach nem typischen Fehler aus, der auftritt, wenn man updates-testing nutzt und damit nicht alle Pakete auf dem richtigen Stand sind.
 
Merkwürdigerweise war Updates-Testing per default aktiviert - was sicher nicht Sinn der Sache ist.
 
Vielen Dank, vor allem dir, buddabrod. Jetzt hats geklappt. TLP und tp_smapi (akmod-tp_smapi-0.41-1.fc18.x86_64) ist installiert.Allerdings kann ich das Kernelmodul trotzdem nicht laden; TLP sogar, dass es nichtmal installiert sei.
 
Vielen Dank, vor allem dir, buddabrod. Jetzt hats geklappt. TLP und tp_smapi (akmod-tp_smapi-0.41-1.fc18.x86_64) ist installiert.Allerdings kann ich das Kernelmodul trotzdem nicht laden; TLP sogar, dass es nichtmal installiert sei.

Evtl. neu starten oder depmod -a etc.
In /lib/module/blablubb irgendwo sollten die Module zu finden sein.
 
@PaterPeng

Nein, bei Gnome 3.2 und 3.4 hatte ich diesen Lag nicht, jedenfalls nicht in diesem Ausmaß. Aber auch jetzt ist die Wartesekunde nicht wirklich schlimm (ist ja nur einmal).

Zu der anderen Problematik, schau doch mal in den TLP-Thread. Da wurden ähnliche Probleme gelöst. Welchen Kernel hast du?
 
Die Firefox Gui ist bei mir seit Version 18 ziemlich träge. Das hat mit der Anzahl der Lesezeichen zu tun.

Code:
# cat bookmarks.html | grep HREF | wc
    410

410 sind wohl zu viel für Firefox 18.....
 
Hab seit gestern die längste Installationsorgie in den letzten 5 Jahren hinter mir. Aktuell läßt sich Fedora 18 Final (die Beta ging noch....) ohne weiteres nicht auf einem X230 installieren, https://bugzilla.redhat.com/show_bug.cgi?id=893892

P.S. und ich geb den Kritiken Recht. Der Installer ist ziemlich unreif mit etlichen BUGS, die Partitionierung nicht auf Anhieb verständlich.
 
Zuletzt bearbeitet:
Warum hast du denn nicht die Beta behalten? Ist doch jetzt identisch mit Release.

Wenn man diese Anaconda-Problematik mal rausnimmt, ist F18 aber richtig gut. F17 war schon besser als F17, aber F18 ist wohl nochmal besser. :)
 
Weil die Beta Installation noch auf meiner Test Partition gelegen ist und ich noch kurz mit dem Gedanken spielte, auf BTRFS umzusteigen - ich habs dann doch gelassen und war froh das alles wieder läuft. Länger hab ich für eine Installation nur mal mit Archlinux auf einem Macbook gebraucht, 2007 und da war auch ein häßlicher BUG im Spiel aber der ist ja auch kaum zu toppen. Ansonsten war/ist Fedora 18 Top.
 
Das kommt ja jetzt genau passend für meinen M72e tiny, der morgen geliefert werden soll. :thumbup:
 
Es häufen sich Berichte, dass F18 nicht installierbar sei. Das ist schade, und schon reine Ironie, wenn man bedenkt, dass gerade Anaconda der Grund für die Aufschiebung war, weil es verbessert werden sollte und nun möglicherweise nach Release noch schlechter funktioniert als bei der Beta. :facepalm:
 
Es ist auch quasi-nicht installierbar, wenn man (wie auf TPs hoffentlich üblich) verschlüsselte Partitionen nutzt.

Es kommt beim Upgrade kein Eingabefenster, um den Schlüssel einzugeben und man kann ihn auch nicht eingeben.

Workaround: für das Upgrade die entsprechenden Partitionen aus der crypttab und fstab auskommentieren.
Auf meinem T61 macht der prefdm Probleme, denn er startet keinen Displaymanager. Fehlermeldung gibt es keine brauchbare.
 
ich hab letzte nacht ein upgrade per fedup probiert. bis zum reboot ging alles glatt, das hd-passwort wurde auch brav abgefragt, doch auch 8 stunden später ist die ssd immer noch am ackern. leider ist die einzige ausgabe, die ich erhalte der rotierende kreis, des cursors und x. außer ihm ist aber nichts zu sehen. ein login per konsole ist nicht möglich. -> null infos vor dem start von x gab es eine fortschrittsanzeige, die bei 0% stand, dann erschien eine zeiel text, die ich nicht schnell genug lesen konnte und dann kam x.

es kann gut sein, dass ichs selbst verbockt hab. ich hab das upgrade per chroot von ubuntu aus angestoßen und /boot vergessen zu mounten. beim ersten reboot kam daher nicht die vorgesehene initrd zum einsatz, sondern das system versuchte normal zu starten mehr als einige fehlermeldungen wegen nicht gestarteter dienste aufgrund von nicht erfüllten abhängigkeiten und anschließend dem rotierenden cursor bekam ich nichts zu sehen. ich hab den fehler behoben und wie vorgesehen kernel und initrd von fedup gebootet. das resultat steht oben. auch mit normalem kernel war die hdd-led wild am flackern. gut möglich, dass systemd da schon pakete aktualisiert hat. abschalten ging nur per einschalter gedrückthalten. :pinch:
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben