Auf zur nächsten Updaterunde – diesmal Fedora 16

Knapp nach Kubuntu ist nun auch Fedora 16 (aka Verne) bereit zur Installation.

3 Systeme stehen zum Update bereit

• Ein Tablet mit Fedora 15 von einem durchschnittlichem Normalbenutzer (Mailkonto; massives Surfverhalten)
• Ein Powerlap mit Fedora 16 Beta von einem Programmierwahnsinnigem mit ausgeprägtem Drang nach Mail (bisher Thunderbird); Surfen
• Ein Entwicklungsrechner wo echte Programme rausfließen und der unter extremen Datendurchsatz leidet. Eine der weiteren Hauptaufgaben sind Videoschnitt (Kdenlive)

Vorbemerkung zu den Updates: Als Updatemethode wähle ich bei Fedora die „yum upgrade yum“-Methode ( hier zu finden ), da ich damit auch in der Vergangenheit schon gute Erfahrungen gemacht hatte.

Tablet von Fedora 15 auf Fedora 16

Als erstes kommt der Tablet dran, hier erwartet der geneigte Admin die wenigsten Probleme. Es hätte so schön sein können, aber die Updatepakete tröpflen nur mit ~70K/sec. auf die SSD….

Ein beherztes deaktiveren des ausgewählten Mirrors (durch yum-plugin-fastestmirror) in der Configdatei /etc/yum/pluginconf.d/fastestmirror.conf behebt das Problem.

–snip–

exclude=be.mirror.eurid.eu

–snip–

Der nächste Mirror gibt was die Leitung aushält 🙂

So wie auch schon beim Kubuntu-Update störten beim ersten Start von KDE die fehlenden Akonadi-Quellen. Alle entfernen die ein „X“ drinnen haben (oder ihr legt halt die fehlenden Dateien an) und die Migration klappt ohne weitere Probleme.

2 Stunden nach Übergabe an die Anwenderin war fast schon Begeisterung zu vermelden. Keine Probleme beim Umgang – die neu gewohnenen Einblicke in die Termine (durch CalDav ermöglicht) entlockten fast schon einen kleinen Jauchzer

Powerlap von Fedora 16 Beta auf Release

Als nächstes kommt eine Laptop mit Core i7 / 8GB RAM / SSD dran. An sich nichts Weltbewegendes, aber er wird halt so dringend gebraucht (und ja – ich disktuiere andauernt mit dem Programmierer dass er gefälligst nicht dauernd auf Beta´s arbeiten soll Er hatte halt noch keine kravierenden Probleme damit).

Na gut – trotzdem kommt er als nächstes dran – ich weiss was ich mach

Geschlagene 7 Minuten später ist der Lap auch schon fertig – ein beherztes yum distro-sync sorgt dafür dass auch die letzten Pakete auf den Releasestand gebracht werden und er kann schon wieder weiterarbeiten.

Hier war sogar die Migration schon erledigt, also gab es keinen weiteren Einrichtungsaufwand

auf zum nächsten Kandidaten

Entwicklerrechner mit Hang zum Videoschnitt

für diesen Rechner hab ich mir mehr Zeit reserviert. Aus dem einfachem Grund: Er ist der am meisten hergenommene Rechner mit einigen Repositories zusätzlich und noch dazu selbst übersetzten Programmpaketen. Apropo Programmpakete: Bevor ich hier loslegen konnte musste ich erst noch folgende installierten entfernen:

yum remove libmtp-hal gnochm klamav libnih mumble murmur fawkes-doc fawkes player ffmpeg-devel kino ffmpeg2dirac ffmpeg2theora gstreamer-ffmpeg transcode xine-lib-extras-freeworld  kdenlive ffmpeg libavfilter2 libavdevice53 vlc  vlc-core libpostproc51 libavformat53 libswscale2 libavcodec53 blender opencore-amr openshot wxsvg motion gstreamer-plugins-ugly k3b-extras-freeworld gnome-mplayer-common faac-devel mlt-python mlt libavdevice52 avidemux-qt avidemux avidemux-cli avidemux-libs smplayer guvcview gnome-mplayer mplayer gpac gpac-libs libavformat52 libavcodec52 faac libdvbpsi libfaac0 libopencore-amrnb0 libopencore-amrwb0 libavutil51 lame faad2-devel faad2 libfaad2 lame-devel libmp3lame0

Einige kannte ich noch, aber ich geb zu da waren Pakete dabei die hab ich noch nie im Leben bewusst wargenommen Die meisten mussten entfernt werden weil die Pakete in FC16 neue Namen bekommen haben und ein paar davon weil HAL nun entgültig rausgefallen ist.

Nachdem das erledigt war lief das Update fürs erste mal durch. Vor dem Reboot hatte ich vorsichtshalber noch folgendes durchgeführt

grub2-mkconfig -o /boot/grub2/grub.cfg # => erstellen einer Grub2 config aus dem alten Grub

/sbin/grub2-install /dev/sda # => MBR neu schreiben

Der Neustart war eher ernüchternd. Grund war die eingebaute Nvidia-Grafikkarte. Also – natürlich nicht die Karte selbst, sondern die Config die diese ertragen musste. Es waren die kmod-nvidia eingerichtet die das bekannte Problem haben das dass GLX-Modul nicht gestartet werden kann (symlink von /usr/lib64/xorg/modules/extensions/nvidia/libglx.so auf  /usr/lib64/xorg/modules/extensions/libglx.so setzen). Danach hat die NVidia zwar inkl. GLX gestartet, aber der nächste Update kommt bestimmt. Ein beherztes yum remove kmod-nvidia* entfernte die „störenden“ Pakete und die Installation von yum install akmod-nvidia sorgte beim nächsten Neustart für ein klares / zukunftsträchtiges Bild inkl. GLX. Die akmod-nvidia-Variante prüft beim Systemstart auf das vorhandensein der Kernelmodule und übersetzt diese im Bedarfsfall.

Nachdem diese Hürde genommen war, kam die Wiederherstellung der entfernten Pakete dran (soweit diese nicht eh schon durch andersnamige vorhanden waren).

Was leider nicht gelang war die Wiederherstellung von Kdenlive wegen des MLT-SDL-Fehlers. Die schon bekannten Hinweise ( hier ) halfen leider nicht weiter. Naja – es ist ja sowieso gerade die Version 0.8.4 rausgekommen – mal sehen wie lange es dauert….

Zur Not muss ich halt wieder mit dem Build-Script arbeiten das auf www.mltframework.org zu finden ist.

Soweit so gut für heute – 3 Stunden hat das letzte/größte Upgrade gebraucht. Aktuell kann der Besitzer mal arbeiten und scheint einen recht zufriedenen Eindruck zu machen …..

Sollte ich noch was negatives finden, werd ich selbstredent aktualisieren….