Le blog de llaumgui - Balise - kernel

CentOS 5.2 et DédiBoite V1

llaumgui — Tue, 24 Jun 2008 20:17:00 +0200

Aujourd'hui, la version 5.2 de CentOS est sortie.
Vous pouvez consulter l'annonce sur le site francophone (je suis fan de l'admin qui a posté cette news;-)) et consulter les notes de version officielles (très conseillé avant de vous lancer dans un yum update frénétique !).

A noter que j'ai fais ma mise à jour très rapidement pendant ma pause déjeuné et que j'ai lancé le reboot de ma DédiBoite V1 avant de partir en réunion et ce de façon un peu légère... Bilan : interruption du service tout l'après-midi...

Après une rapide discussion avec l'ami Remi sur le chan IRC de fedora-fr (faut qu'on fasse un chan CentOS -Fr !) il semblerait que le problème vienne encore et toujours de l'initrd...

Pour citer un sage :

RemiFedora : surement un initrd vérolé...
RemiFedora : la maladie des migrations

Bref, après une petite étude de l'initrd de CentOS 5.2 comparé à celui de la 5.1, il semblerait que les seules différences soient (merci Remi pour les lignes de commandes) :

llaumgui@enterprise ~/Bureau> gunzip -dc 5.2/initrd-2.6.18-9*.img | cpio -id

llaumgui@enterprise ~/Bureau> gunzip -dc 5.1/initrd-2.6.18-53*.img | cpio -id

llaumgui@enterprise ~/Bureau> diff 5.1/init  5.2/init 

43,46d42

< echo "Loading uhci-hcd.ko module"

< insmod /lib/uhci-hcd.ko 

< echo "Loading ohci-hcd.ko module"

< insmod /lib/ohci-hcd.ko 

48a45,48

> echo "Loading ohci-hcd.ko module"

> insmod /lib/ohci-hcd.ko 

> echo "Loading uhci-hcd.ko module"

> insmod /lib/uhci-hcd.ko

Bilan de la situation actuelle : en attendant une piste, llaumgui.com (et scenario-paintball.com) tournent sur une CentOS 5.2 avec un kernel de 5.1 (2.6.18-53.1.21.el5 )...

A suivre...

Fedora 9 a.k.a Sulphur est là !

llaumgui — Tue, 13 May 2008 20:14:00 +0200

La grande famille de Fedora est heureuse de vous annoncer la naissance de « Sulphur » (Fedora 9).
Cette version majeure, dans le développement de la distribution Fedora, va vous offrir un grand nombres de nouveautés destinées à vous simplifiez la vie comme vous en avez rêvé.

Plusieurs mots symbolisent cette version

Énergie : 7 mois de développement intense
Rayonnement : Unanimité des utilisateurs et journalistes des avancés de Fedora
Futur : Perpétuelle avance sur les nouvelles technologies

Quelques nouveautés

Coté environnement graphique

KDE 4.0.3 : L'arrivée de KDE4 et la constitution du groupe d'intérêt KDE au sein de Fedora Project est l'occasion de faire de KDE un citoyen de première classe dans le projet.
Fedora 9 est la première distribution installer par défaut KDE 4.0.3 et ceci constitue le premier pas vers un meilleur bureau KDE sous Fedora.
Gnome 2.22 : Une importante sortie pour Fedora Project avec le développement de gvfs principalement par le développeur Fedora Alexander Larsson, Fedora a également réécrit GDM pour une meilleure intégration avec Console Kit & Policy Kit.

Coté bureautique

OpenOffice 2.4

Coté réseau

NetworkManager : Configuration réseau filaire, Wifi, GSM/CDMA et PPP en une seul interface.
Configuration d'accès VPN (OpenVPN & Compatible Cisco VPN Client (VPNC)).

Coté internet

Firefox 3 (Béta5).
Swfdec : Greffon libre qui vous permet de lire du contenu Flash depuis votre navigateur. Celui-ci s'appuie sur GSTREAM pour la restitution du son

Coté système

PreUpgrade : Système de mise à jours automatique de la nouvelle version Fedora sans média (cd/dvd).
Kernel 2.6.25
Upstart : Remplacement du vieillissant ''init'' ce qui a pour résultat immédiat un démarrage et une extinction du système très rapide.
Xorg 7.3 : Dans la continuité de l'opération "Need For Speed", Fedora a consciencieusement traqué les goulot d'étranglement dans Xorg afin d'accélérer son démarrage.
Fedora introduit le support optionnel du modsetting pour les cartes Intel ! La version incluse est une pré-version de Xserver 1.5 qui en combinaison avec le noyau 2.6.25 introduit une meilleure collaboration entre Xorg et le noyau, une meilleure gestion du sous-système PCI et également un meilleur support du hotplug.
Désormais, le double-écran ne sera plus aussi douloureuse qu'avant avec la super applet de gestion
Gestion centralisée des dictionnaires : Un seul et unique dictionnaire pour chaque langue, mais pour toutes les applications (OpenOffice, FireFox, Thunderbird, Gnome, KDE, ...).
Anaconda : (Gestionnaire d'installation amélioré)
- Redimentionnement de partition dont le NTFS.
- Support du système de fichier Ext4 (expérimental).
- Chiffrement de partition.
- Abandon de Kudzu pour udev/hal pour meilleur reconnaissance des composants matériels.
PackageKit : Implémentation d'un nouveau gestionnaire de paquets alternatif.
L'objectif de PackageKit est de fournir un cœur commun à tout les systèmes de paquetage et faciliter la vie des distributions.
RPM Fusion : RPM Fusion ne fait pas à proprement parler partie de FedoraProject, mais c'est une initiative importante au sein de la communauté.
Trois des principaux dépôts tiers (Dribble, Freshrpms et Livna) ont décidés de fusionner pour fournir plus de paquets, partager des ressources communes et améliorer la qualité.
K12Linux : Fedora intègre la distribution LTSP K12ltsp en tant que saveur officielle sous le nom de K12Linux. K12Linux est l'intégration de LTSP-5 dans FedoraProject en collaboration avec la communauté LTSP.org.
Un grand merci à Eric Harrison (core developer de LTSP et fondateur de K12ltsp) et à Warren Togami (Fondateur du projet Fedora).
FUNC : (Fedora Unified Controller) Module en langage Python afin de facilité la gestion d'un parc informatique. Système utilisant XML-RPC/SSL.
LivePersistence :Vous pourrez distribuer des clés usb Fedora pré-chargées et conserver vos paramètres et données personnelles.
OpenJDK :Remplacement de IceTea.

Coté développeur

GCC 4.3 : Intégration de GCC 4.3 avec le support expérimental de C++ 0x, un mode parallèle de la STL, Fedora 9 fournira à sa sortie.
Eclipse 3.3 (Europa) Cette version est fournir par défaut mais la mise à jour vers Eclipse 3.4 (Ganymède) est prévue ultérieurement.

Cette opus 9 est le premier avec Paul Frields en tant que Project Leader de Fedora et premier Project Leader issu de la communauté Fedora elle même.

Afin d'obtenir cette nouvelle version, vous pouvez aller sur cette page.

Concernant le support des francophones, l'équipe ainsi que les membres de Fedora-FR seront heureux de vous accueillir à cette adresse.

La spb-box sous CentOS 5.1

llaumgui — Mon, 03 Dec 2007 21:39:00 +0100

Petit rappel, la spb-box est la Dedibox qui héberge entre autre Scénario-PaintBall et llaumgui.com (ce blog).

Cette nuit, à l'heure des tâches cron de maintenance, j'ai reçu un mail de ma spb-box (sous CentOS 5.0), pour m'indiquer une mise à jour de 115 paquets ! Intrigué, je consulte la liste d'annonces CentOS qui m'informe de la sortie de CentOS 5.1.

Il faut savoir que pour passer d'une version X.n vers une version X.(n+1) de CentOS (5.0 vers 5.1 dans mon cas), c'est aussi simple qu'un yum update : il n'y a rien à changer ni à configurer vu que les changements restes mineurs. Un yum update plus tard donc :

root@spb-box ~> cat /etc/redhat-release

CentOS release 5 (Final)

"CentOS 5 (Final)" ? ! ? ! ? ! Suis je toujours sur CentOS 5.0 ? Après un passage sur #centos et après avoir pris connaissance de ce bug, je me lance dans un :

root@spb-box ~> rpm -qa centos-release

centos-release-5-1.0.el5.centos.1

Cette dernière commande me confirme que je suis bien sous l'opus 5.1 de ma distro serveur préférée (la distro bureau étant bien entendu Fedora).

Rassuré, je reboot sous CentOS 5.1 tout en gardant le kernel de Centos 5.0 « made for Dedibox » et tout ce passe bien. Étant en début de soirée et ayant du temps (à perdre) pour tester le système de secours des Dedibox, je tente alors de booter sur le kernel de CentOS 5.1... Et bien là, contre toute attente : le kernel officiel de CentOS supporte pleinement les Dedibox et leur processeur VIA exotique...
C'est pas aujourd'hui que je testerais le système de secours des Dedibox.

Voici donc llaumgui.com propulsé par une spb-box sous CentOS 5.1.

LLaumgui plus fort que cpuspeed ?

llaumgui — Sun, 19 Nov 2006 00:05:00 +0100

Pour ceux qui ont suivie ma précédente aventure sous Fedora Core 6 avec mon portable, vous avez pus remarquer que j'avais eu de gros problèmes. Et bien ils sont, depuis peu, tous résolus !

Je vais faire un rapide résumé des problèmes mineurs puis je m'attarderais sur le cas de cpuspeed qui part en vrille sur mon Centrino.

1er problème, un kernel i586 -> Bon, bien qu'il existe une solution, cette fois si je me suis retrouvé avec un vrai i686... Va comprendre !
2ème problème, Bios bug -> Le bug est toujours là (c'est un bug des BIOS Intel) mais avec le nouveau kernel (2.6.18-1.2849.fc6), je ne m'arrête pas 30 secondes dessus (ça c'était un bug du premier kernel 2.6.18) et je mets pas 2 minutes à lancer mon portable.
4ème problème, Plus de WiFi -> Suffisait de récupérer mes fichiers de conf de FC5 ;-).

Maintenant que les menus problèmes sont réparés, attardons nous sur cpuspeed... J'ai tout tenté, même d'installer la dernière version dans le dépôt testing, mais rien ! Pour ceux qui n'ont pas suivie mon aventure sur les forums de fedora-fr, en voici un petit résumé :

Le symptômes :

root@defiant /home/llaumgui> service cpuspeed start

root@defiant /home/llaumgui> service cpuspeed status

cpuspeed est arrêté...

root@defiant /home/llaumgui> /usr/sbin/cpuspeed

Pas de problème ni de message...
Je me tourne vers le fichier de lancement du service cpuspeed (/etc/init.d/cpuspeed) et compare les versions FC5 et FC6

Version FC5 :

#!/bin/sh

# Startup script for cpuspeed

#

# chkconfig: 12345 06 99

# description: Run dynamic CPU speed daemon



# Source function library.

. /etc/rc.d/init.d/functions



[ -f /usr/sbin/cpuspeed ] || exit 0



prog="cpuspeed"



# Get config.

if [ -f /etc/cpuspeed.conf ]; then

        . /etc/cpuspeed.conf

fi



start() {

    if [ ! -f /var/lock/subsys/cpuspeed ]; then

        # Attempt to load scaling_driver if not loaded but it is configured

        for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver; do

            # We want to run the code below only if the

            # wildcard above got no matches.

            [ ! -f "$file" ] || break



            if [ -n "$DRIVER" ]; then

                /sbin/modprobe "$DRIVER"

            else

                # use ACPI as a fallback if its available.

                if [ -f /proc/acpi/processor/CPU0/throttling ]; then

                    # Check we have throttling states available.

                    thr=`head -n1 -q /proc/acpi/processor/CPU*/throttling | uniq`

                    if [ "$thr" != "<not supported>" ]; then

                        /sbin/modprobe acpi-cpufreq

                    fi

                fi

            fi

        done



        # If we get this far with no driver, we must have no ACPI. We're doomed.

        [ ! -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver ] && return 0



        echo -n $"Starting $prog: "



        daemon cpuspeed -d $OPTS

        RETVAL=$?

        echo

        [ $RETVAL = 0 ] && touch /var/lock/subsys/cpuspeed

    else

        return 0

    fi

    return $RETVAL

}



stop() {

    if test "x`pidof cpuspeed`" != x; then

        echo -n $"Stopping $prog: "

        killproc cpuspeed -USR1

        killproc cpuspeed -INT

        echo

    fi

    if test "x`pidof cpuspeed`" != x; then

        killproc cpuspeed

    fi

    RETVAL=$?

    [ $RETVAL = 0 ] && rm -f /var/lock/subsys/cpuspeed

    return $RETVAL

}



case "$1" in

    start)

        start

        ;;

    

    stop)

        stop

        ;;

    

    status)

        status cpuspeed

        ;;

    restart)

        stop

        start

        ;;

    condrestart)

        if test "x`pidof cpuspeed`" != x; then

        stop

        start

        fi

        ;;

    

    *)

        echo $"Usage: $0 {start|stop|restart|condrestart|status}"

        exit 1



esac



exit $RETVAL

Version FC6 :

#!/bin/sh

# Startup script for cpuspeed

#

# chkconfig: 12345 06 99

# description: Run dynamic CPU speed daemon



# Source function library.

. /etc/rc.d/init.d/functions



[ -f /usr/sbin/cpuspeed ] || exit 0



prog="cpuspeed"



# Get config.

if [ -f /etc/cpuspeed.conf ]; then

        . /etc/cpuspeed.conf

fi



start() {

    if [ ! -f /var/lock/subsys/cpuspeed ]; then

        # Attempt to load scaling_driver if not loaded but it is configured

        for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver; do

            # We want to run the code below only if the

            # wildcard above got no matches.

            [ ! -f "$file" ] || break



            if [ -n "$DRIVER" ]; then

                /sbin/modprobe "$DRIVER"

            else

                if [ -d /proc/acpi ]; then

                    EST=`grep flags /proc/cpuinfo | grep est`

                    if [ "$EST" ]; then

                        # use ACPI as a fallback

                        /sbin/modprobe acpi-cpufreq

                        # even ACPI didn't work, remove it, and bail out.

                        if [ -d /sys/devices/system/cpu/cpu0/cpufreq ]; then

                            /sbin/rmmod acpi-cpufreq

                        fi

                    fi

                else

                    # This is a no-ACPI machine. Just exit.

                    return 0

                fi

            fi

        done



        # If we get this far with no driver, we must have no ACPI. We're doomed.

        [ ! -f /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver ] && return 0



        drv=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)



        case "$drv" in

        centrino|powernow-k8)

            /sbin/modprobe cpufreq-ondemand

            for i in /sys/devices/system/cpu/cpu*

            do

                echo ondemand > $i/cpufreq/scaling_governor

            done

            RETVAL=0

            ;;

        *)

            echo -n $"Starting $prog: "

            daemon cpuspeed -d $OPTS

            RETVAL=$?

            echo

            [ $RETVAL = 0 ] && touch /var/lock/subsys/cpuspeed

        esac

    else

        return 0

    fi

    return $RETVAL

}



stop() {

    drv=$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver)

    case "$drv" in

    centrino|powernow-k8)

        /sbin/rmmod cpufreq-ondemand

        RETVAL=0

        ;;

    *)

        if test "x`pidof cpuspeed`" != x; then

            echo -n $"Stopping $prog: "

            killproc cpuspeed -USR1

            killproc cpuspeed -INT

            echo

        fi

        if test "x`pidof cpuspeed`" != x; then

            killproc cpuspeed

        fi

        RETVAL=$?

        [ $RETVAL = 0 ] && rm -f /var/lock/subsys/cpuspeed

    esac



    return $RETVAL

}



case "$1" in

    start)

        start

        ;;



    stop)

        stop

        ;;



    status)

        status cpuspeed

        ;;

    restart)

        stop

        start

        ;;

    condrestart)

        if test "x`pidof cpuspeed`" != x; then

        stop

        start

        fi

        ;;



    *)

        echo $"Usage: $0 {start|stop|restart|condrestart|status}"

        exit 1



esac



exit $RETVAL

Je remarque de suite une nuance, les centrino sont passé en monde ondemand :

case "$drv" in

        centrino|powernow-k8)

            /sbin/modprobe cpufreq-ondemand

            for i in /sys/devices/system/cpu/cpu*

            do

                echo ondemand > $i/cpufreq/scaling_governor

            done

            RETVAL=0

            ;;

Il suffit donc de modifier les lignes en question en virant centrino pour que cpuspeed se lance sans problème comme sous Fedora Core 5...

La question est : pourquoi un ordinateur dont l'architecture est orientée mobilité est forcé en mode ondemand ? ? ? ! ! !
Je vais étudier la question et peut être rapporter un bug... Je reste cependant ouvert à vos remarques...
En attendant, la fréquence de mon ordinateur varie sans problème comme avant...

Fedora Core 6, bonjour et à bientôt

llaumgui — Sun, 22 Oct 2006 16:14:00 +0200

Alors que Zod n'a pas encore pointé officiellement le bout de son nez, en vu de l'install party de Samedi, j'ai tenté de faire un migration de mon portable de FC5 vers FC6. Puis devant les problèmes, une complète réinstallation. Puis devant les nouveaux problèmes une pose, une réflexion et un tour sur le Chan avec les copains.

1er problème, un kernel i586 :

Grâce aux indices du docteur, je me suis rendu compte que j'étais en i586 sur mon Intel Centrino... Anaconda dans son infinie délire m'avais affublé d'un kernel i585.

[root@defiant llaumgui]# file /lib/modules/2.6.18-1.2798.fc6/build

/lib/modules/2.6.18-1.2798.fc6/build: symbolic link to `../../../usr/src/kernels/2.6.18-1.2798.fc6-i586'

Bref la solution fut donc pour moi :

rpm -ivh --force '/root/Desktop/kernel-2.6.18-1.2798.fc6.i686.rpm'

2ème problème, Bios bug :

Dès le boot :

PCI: BIOS bug: MCFG area@e0000000 is not E820 reserved

PCI: not using MMCONFIG

Apparemment je suis en présence d'un bug du kernel Linux. La solution attendre un nouveau kernel...

3ème problème, acpi_cpufreq bug :

ksign: module signed with unknow public key

FATAL: Error inserting acpi_cpufreq

(/lib/modules/2.6.18.../kernel/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.ko):

No such device

Dans la ligné de mes problèmes de bios je présume...

4ème problème, Plus de WiFi :

J'avoue ne pas avoir trop cherché la solution, trop mare !

Solution générale

Une réinstallation de Fedora Core 5 qui elle marche nickel ! En attendant une mise à jour...

Je trouve quand même dommage que pas assez de personnes participent à la Rawhide et rapportent les bugs. Plus on sera nombreux à déboguer Fedora Core, plus Fedora Core avancera et sera stable à sa sortie. J'irais même jusqu'à dire qu'à cause de ça, les 2 premières semaines d'existences d'une version Fedora correspondent à une séance de débug massive.

Directive installonlypkgs et mise à jour du kernel et de ses kernel-modules

llaumgui — Wed, 03 May 2006 23:42:00 +0000

Aujourd'hui vient de sortir un nouveau kernel (2.6.16-1.2107_FC5) pour Fedora Core 5. Les kernel-modules (kmod) de Livna sont d'ors et déjà disponible mais pas ceux de chez ATrpms (lirc-kmdl dans mon cas).
Cas pratique : si l'on met à jour sont kernel via yum, ce n'est pas une réelle mise à jour (rpm -Uvh) mais une installation du nouveau kernel (rpm -ivh) et ce afin de pouvoir booter sur plusieurs kernel via GRUB. Cela n'est valable que pour le kernel et malheureusement pas pour les kmods qui eux sont réellement mis à jour. On se retrouve alors avec 2 kernels et une liste de kmods incomplète pour chacun d'eux.

Après avoir évoqué ce problème sur les forums de Fedora-Fr, Remi a apporté une solution : la directive installonlypkgs de /etc/yum.conf, pour ma config :

installonlypkgs = kernel, kernel-smp, kmod-nvidia, kmod-fglrx, kmod-ntfs, lirc-kmdl

Je me retrouve donc à booter sur mon ancien kernel avec tous ses kmods mais en ayant déjà le future de prêt n'attendant que le kmod lirc-kmdl