Buscar en este blog

18.2.12



Un error al actualizar, es decir al ejecutar la siguiente orden:
pacman -Syu
La respuesta:
error: error al realizar la transacción (archivos en conflicto)
filesystem: /etc/mtab existe en el sistema de archivos
Ocurrieron errores, no se actualizaron paquetes
Para solucionar este error es necesario forzar la instalación de la nueva versión del paquete que en este momento es filesystem-2011.12-2:

pacman -S filesystem --force

16.2.12

Pacman 4

Me atrevo a decir que ha empezado un nuevo capítulo en la historia de ArchLinux; luego de mucho tiempo de polémica y especulaciones, la firma de paquetes PGP ha llegado a Pacman 4, la nueva versión del administrador de paquetes de nuestra querida distro.
A pesar de que el arribo de de Pacman 4 al repositorio [core] tiene apenas unas horas, este cambio no ha sido de la noche a la mañana. Desde abril de 2011 se empezaron a subir paquetes con firmas PGP, y desde noviembre pasado era ya algo obligatorio.
En este momento, 100% de los paquetes en [core] cuentan con firma PGP, y aproximadamente el 71% en [extra] y el 45% en [community], porcentajes que en los siguientes días y semanas irán incrementándose, hasta alcanzar todos el 100%.

Actualizar a Pacman 4

Como ya se lo están imaginando, se trata de una actualización delicada, y lo más seguro es que requiera de especial atención por parte de cada usuario, dependiendo de los paquetes que cada quien tenga instalados.
¿Qué hacer primero? Intentemos actualizar normalmente:
sudo pacman -Syu
Si tu actualización se realiza sin problema, ¡felicidades!, quiere decir que tienes un sistema limpio con sólo los paquetes necesarios para tu trabajo diario.
Pero como buenos usuarios de ArchLinux, es casi seguro que tengamos instalado una multitud de aplicaciones, así que el comando anterior nos arrojará algo similar a lo siguiente:
Actualizando a Pacman - Imagen 1
En la captura de pantalla previa podemos apreciar que hay conflicto con un paquete, lo cual puede variar de usuario a usuario (es probable que tengas más paquetes en conflicto, pero no te preocupes).
¿Qué hacer ahora? Es sencillo: Eliminar los paquetes que nos estén ocasionando conflictos, y después de la actualización a Pacman 4, volverlos a instalar. Incluso, si al tratar de eliminar algún paquete, aparece otro conflicto, también debes eliminar el (los) paquete(s) que lo ocasionen, y así sucesivamente.
Por ejemplo (mi caso particular): Al tratar de eliminar el paquete package-query, apareció en conflicto el paquete yaourt (el cual necesita al primero), por lo que tuve que desinstalar ambos con:
sudo pacman -R package-query yaourt
Ahora, intentamos nuevamente la actualización a Pacman 4:
sudo pacman -Syu
Si obtienes otro conflicto, repite el procedimiento anterior. Si ya todo está correcto, obtendrás lo siguiente:
Actualizando a Pacman - Imagen 1
¡No olvides volver a instalar los paquetes que hayas desinstalado!

Habilitar la verificación de firmas de paquetes

De manera predeterminada, la verificación de firmas de paquetes está deshabilitada. Mi recomendación es mantener dicha configuración y dejar pasar un tiempo para empezar a validar paquetes… pero cómo estoy seguro harán caso omiso de mi recomendación, procedamos a habilitar el nuevo juguete ;-)
Primero, debemos inicializar nuestro pacman keyring usando el comando:
sudo pacman-key --init
Lo anterior crea los archivos de llaves pubring.gpg y secring.gpg con los permisos necesarios, actualiza la base de datos de confianza (vacía en este momento) y genera el archivo básico de configuración /etc/pacman.d/gnupg/gpg.conf, en el cual se recomienda cambiar el keyserver predeterminado (hkp://keys.gnupg.net) por el usado por los desarrolladores de ArchLinux (hkp://pgp.mit.edu).
sudo vim /etc/pacman.d/gnupg/gpg.conf
Contenido final del archivo:
no-greeting
no-permission-warning
lock-never
#keyserver hkp://keys.gnupg.net
keyserver hkp://pgp.mit.edu
keyserver-options timeout=10
Ahora, procedemos a modificar el archivo de configuración de pacman… ¡pero cuidado!, el archivo /etc/pacman.conf actual no contiene las opciones que necesitamos, ya que éstas fueron creadas en el nuevo archivo /etc/pacman.conf.pacnew. ¿Qué hacer? Respaldamos el viejo pacman.conf y renombramos el nuevo:
sudo mv /etc/pacman.conf /etc/pacman.conf.old
sudo mv /etc/pacman.conf.pacnew /etc/pacman.conf
¡Ojo! Si en tu viejo pacman.conf tenías alguna configuración personal (yo por ejemplo, tenía agregado el repositorio [archlinuxfr] para instalar yaourt), debes copiar dichas opciones manualmente.
Ahora sí, procedemos a modificar el archivo de configuración de pacman:
sudo vim /etc/pacman.conf
Primero debemos buscar el parámetro SigLevel, el cual en este momento tiene asignado el valor “Never“; se recomienda usar el valor “Optional TrustedOnly” (para que verificación de firmas sea opcional, pues aún hay paquetes no firmados, pero en caso de existir la firma, debe ser de una fuente confiable):
...
# PGP signature checking
# NOTE: None of this will work without running `pacman-key --init` first.
# The compiled in default is equivalent to the following line. This requires
# you to locally sign and trust packager keys using `pacman-key` for them to be
# considered valid.
SigLevel = Optional TrustedOnly
# If you wish to check signatures but avoid local sign and trust issues, use
# the following line. This will treat any key imported into pacman's keyring as
# trusted.
#SigLevel = Optional TrustAll
# For now, off by default unless you read the above.
#SigLevel = Never
...
También debemos especificar el nivel de verificación en cada repositorio:
...
[core]
SigLevel = PackageRequired
Include = /etc/pacman.d/mirrorlist
 
[extra]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist
 
[community]
SigLevel = PackageOptional
Include = /etc/pacman.d/mirrorlist
...
Noten el uso de PackageRequired en [core] pues es el único repositorio en este momento con el 100% de sus paquetes firmados, motivo por el cual se usa PackageOptional para [extra] y [community].
Guarden los cambios realizados en /etc/pacman.conf, y traten de ejecutar nuevamente pacman -Syu… obtendrán errores al final, pues las firmas aún no pueden ser verificadas. ¿Por qué? Aún necesitamos importar las firmas PGP confiables a nuestro keyring.
Para no hacer ésto último manualmente (con el comando pacman-key –lsign) con cada firma PGP de los 35 desarrolladores y los 30 usuarios confiables, basta con importar las 5 Master Keys, ya que ellas fueron usadas para firmar todas las demás.
Para hacerlo más sencillo, se recomienda crear un bash script para automatizar el proceso:
vim master-keys.sh
Obviamente, puedes ponerle el nombre que gustes. Lo importante es su contenido:
for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
    pacman-key --recv-keys $key
    pacman-key --lsign-key $key
    printf 'trust\n3\nquit\n' | gpg --homedir /etc/pacman.d/gnupg/ \
        --no-permission-warning --command-fd 0 --edit-key $key
done
Le cambiamos el atributo correspondiente para que sea ejecutable:
chmod a+x master-keys.sh
Y lo ejecutamos:
sudo ./master-keys.sh
Cuando finalice, ¡ya podrás instalar paquetes y actualizar normalmente el sistema!
sudo pacman -Syu
Un poco laborioso, sin duda, pero es un procedimiento que sólo realizaremos una vez, con el cual obtendremos un sistema con paquetes provenientes de fuentes seguras.

Más Información

Debido a su importancia, los invito a leer más sobre el tema:

19.11.10

Poner GRUB grafico en archlinux

Bueno hoy quise colocar una imagen en mi grub, pero me acordé que arch necesita un parche en el mismo para poder funcionar, hace un tiempo quise instalarlo pero falle y me daba kernel panic, desde ahí no lo toqué mas :P. Pero es muy sencillo de hacerlo...

Hacen un backup del actual menu.lst:

# cp /boot/grub/menu.lst /boot/grub/menu.lst.backup

Desinstalan el grub actual:

# pacman -R grub

Instalan el grub grafico:

# pacman -S grub-gfx

Vuelven a instalarlo en el mbr de su disco

# grub-install /dev/sda

En mi caso al reiniciar el menú de grub quedaba negro y unos segundos después saltaba un kernel panic. Verifiqué el nuevo menu.lst con el menu.lst.backup y lo solucioné de esta manera:

El kernel panic era un error de partición, esto mostraba menu.lst:

kernel /vmlinuz26 root=/dev/sda4


pero en realidad era la segunda partición:

kernel /vmlinuz26 root=/dev/sda2

Y el problema de la pantalla negra era porque el actual (menu.lst) decía:

splashimage /boot/grub/arch.xpm.gz

pero tenía que ser en realidad:

splashimage /grub/arch.xpm.gz