Bueno, mucho que decir, hice el upgrade a Fedora 15 desde el 14. Resulta que Fedora tiene dos métodos de upgrade:
- vía yum:
rpm --import https://fedoraproject.org/static/069C8460.txt
yum update yum
yum clean all
yum --releasever=15 --disableplugin=presto distro-sync
Documentación:
- vía preupgrade
Documentación:
El método recomendado es "preupgrade", pero yum funcionó bien en mis testeos con máquinas virtuales.
Preupgrade es sorprendente como método de upgrade. Tenemos dos opciones, interfaz gráfica en X o interfaz modo texto en consola. Básicamente ejecutamos el programa, seguimos los pasos y empieza a descargar los paquetes que haga falta para actualizar la distro, al terminar nos va a avisar y al reiniciar entramos automáticamente en el modo de upgrade, "siguiente-siguiente" y luego un instalador Anaconda completamente booteado (el mismo que se usaría si descargamos un CD/DVD de upgrade), ejecuta el upgrade.
Lo diferente con respecto a bajar el CD/DVD y a utilizar yum es que si cerramos el programa (el de X o el de consola), al volver a ejecutarlo, el upgrade continuará desde el punto en que hubiera quedado. En la práctica el programa va a continuar bajando los paquetes que faltaban de la lista (sin tener que iniciar de vuelta la bajada). Cerré 4 veces el programa durante el upgrade, por diferentes motivos, y funcionó muy bien.
La performance?, el upgrade con preupgrade tardó bastante luego de rebootear (una hora para upgredear 1.01 GB de paquetes), lo bueno es que si en cualquier momento durante la bajada de paquetes decidía suspender el upgrade, podía hacerlo sin problemas.
Tiendo a pensar que el upgrade vía yum directo puede ser más rápido, pero puede ser el efecto de tener el sistema en uso hasta último momento antes de reiniciar y que al reiniciar ya están todos los paquetes instalados.
Al terminar el upgrade el sistema funcionó perfectamente y fui directo a bajar el driver STA Broadcom para compilarlo para el kernel de F15, ya que todavía no hay un paquete .rpm, me costó unos 15 minutos en total (incluyendo la bajada de kernel-dev, gcc, kernel-headers y el .tar.gz del driver).
Procedimiento:
Es una integración del howto de abajo con un par de cosas tomadas del muy buen README de Broadcom (hay procedimientos para Ubuntu ahí).
Documentación:
1) Dependiendo de tu sistema, elegir paquetes de 32 o 64 bits
2) Ir a una terminal donde bajaste el paquete.
tar -xvzf hybrid-portsrc-.tar.gz
3) Bajar y aplicar el parche para kernels mayores a 2.6.37:
patch -p0 < 5_100_82_38.patch
4) Instalar kernel headers y entorno de compilación
yum install kernel-dev kernel-headers gcc
5) make -C /lib/modules/`uname -r`/build M=`pwd`
Si no hubieron errores, probar así:
6) Descargar módulos (o drivers) conflictivos de memoria:
Mirando los módulos conflictivos:
# lsmod | grep "b43\|ssb\|wl"
Para removerlos
# rmmod b43
# rmmod ssb
# rmmod wl
Para ponerlos en la blacklist y prevenir que se carguen en el futuro:
# echo "blacklist ssb" >> /etc/modprobe.d/blacklist.conf
# echo "blacklist b43" >> /etc/modprobe.d/blacklist.conf
7) Insmod para cargar el driver:
(si es que no instalaste un driver wl previamente, necesitás cargar un módulo de seguridad antes de cargar el driver wl, muchos sistemas nuevos usan lib80211 y otros ieee80211_crypt_tkip. Fijáte cual funciona en tu sistema.)
# modprobe lib80211
o
# modprobe ieee80211_crypt_tkip
Luego:
# insmod wl.ko
8) Seguir estos pasos para cargar el driver en el proceso de booteo:
# cp wl.ko /lib/modules/`uname -r`/kernel/drivers/net/wireless
# depmod -a
# echo modeprobe wl >> /etc/rc.local (Fedora/SUSE)
Listo
Luego de la carga del driver (el insmod), NetworkManager en KDE4.6 inmediatamente tomó la wifi local y se logueó sin problemas.
Después me puse a mirar un poco Gnome 3 en directo (por fin), y a jugar con systemd que tiene un poco de documentación como pueden ver:
Sobre systemd se puede escribir muchísimo, es bastante nuevo, pero tiene todas las cartas para ser la siguiente evolución de sistemas de arranque, haciendo una salto y mejora radical de lo mejor que había hasta el momento, Upstart (introducido por Ubuntu). Hay varios puntos a revisar y hay una chance que systemd no llegue a convertirse en el manejador "del futuro", por varias razones técnicas bastante complicadas de explicar en pocas palabras, pero si se maneja bien el desarrollo, la arquitectura de la solución es impecable, veremos si la implementación está a la altura.
Para más datos, ver los comentarios y explicaciones (extensísimos y detallados):
Sigo usando Fedora ahora,
sldos.
yaco
No hay comentarios:
Publicar un comentario