previous up next contents
Previous: 2 Exemples d'installation Up: Installx 101 Next: A. Pour mémoire   Contents

Subsections

3 Configuration après installation


3.1 Bootloader

  1. Le bootloader actuel est grub, après avoir été lilo.
  2. Lire les how-to et SuSE Admin Guide, ''The Boot Loader'' (Ch 8 pour la $ SuSE-9.3$). Bien comprendre que l'identification des disques est un problème tripartite : bios, unix, winxx. Noter l'ordre de boot déterminé par le bios. En cas de réinitialisation, par exemple panne de la pile cmos, ce qui fonctionnait avec un certain ordre de boot ne fonctionnera pas forcément avec l'ordre par défaut.
  3. Pour booter en mono-système, c'est à dire sans grub/lilo, il faut une partition active !!! (manoeuvre avec fdisk), et on constate que la racine "/" doit être active, tandis que "/boot" active ne sert à rien. Pour un disque linux+winxx, un bon endroit pour placer le secteur initial de grub/lilo est le boot record de la partition "\boot" qui, alors, doit être active. Sur un disque linux seul, le secteur initial de grub/lilo se place sur le MBR.
  4. ($ SuSE-9.3$) Le bon endroit, pour expérimenter sur le bootloader est le menu d'exécution lui-même. Taper $ \left[Esc\right]$ dans le menu grub donne accès à un éditeur sans enregistrement. Suppose de disposer d'une autre machine pour accéder à la documentation en ligne !
  5. La correspondance bios-unix est "pressentie" à l'installation, puis stockée dans /boot/grub/device.map. Éditer ce fichier en cas de problèmes. Sur Mona2 :
    (fd0) /dev/fd0 ¶(hd0) /dev/hda ¶(hd1) /dev/hde ¶(hd2) /dev/hdg

  6. L'option splash=silent règle le look du boot, en plus de vga=791 (ou =0x317)
  7. Le boot winxp suppose que le disque en train de booter est le premier (dans la liste bios). Il est donc utile de modifier la façon dont grub imite le bios vis à vis de winxx.
    title Windows  
    map (hd0) (hd1)  
    map (hd1) (hd0)  
    chainloader (hd1,0)+1

3.2 Accélérer la manoeuvre


3.2.1 Charger la distribution sur un disque dur

  1. Le bon endroit est /home/distrib. La sémantique est en effet une suite intensive de transferts entre la distrib et le disque système : il est préférable de loger cela sur un disque indépendant.
  2. Recopier tous les fichiers du premier disque dans /home/distrib/.
  3. Dans le cas d'une distrib sur CDROM, recopier les autres disques dans ce même/home/distrib/, soit
    mount /dev/cdrom 
    cp -vR /media/cdrom/* /home/distrib/
  4. Différents fichiers sont présents "en double" sur les divers disques. On constate que ces fichiers sont identiques, en particulier les fichiers index et pgp (exception : les checksum, cf infra).
  5. Pour une distribution en 5 cdrom, il faut ($ SuSE-10.2$) copier les répertoires distrib/media.x avec $ x\in[1,\,5]$. En les recopiant tous, on constate que YOU passe d'un disque à l'autre sans interruption (utiliser Yast2/Software/Sources pour déclarer cette distrib en remplacement des cdrom).
  6. Dans chaque sous répertoire, il y a une liste de checksum. On peut avoir envie de les recopier toutes. Il faut alors les changer de nom. On remarque alors que YOU ne les demande pas lors de l'installation des packages (un mécanisme de signature est de toutes façons contenu dans les packages *.rpm).

3.2.2 Utilisation d'une machine distante (*** $ SuSE-9.3$ vérifier tout cela)

  1. Il faut que les démons réseau soient actifs sur les deux machines. Commande admin/réseaux/services sous YaST. Valider inetd et portmap. Ne pas oublier d'exécuter les batchs qsi~ et qsn~ pour relancer les démons et faire prendre en compte les modifications.
  2. Pour utiliser des noms de machine au lieu des adresses ip, il faut un DNS ou bien renseigner le fichier /etc/hosts.
  3. Commencer par autoriser la création de terminaux X, en exécutant localement la commande  
    $ \triangleright$ xhost +remote_machine (ou bien xhost +).
  4. Utiliser un terminal local pour lancer
    $ \triangleright$ telnet remote_machine.
    On obtient l'affichage local d'un terminal distant. Depuis ce terminal, changer l'écran destinataire des commandes X par l'incantation :
    $ \triangleright$ export DISPLAY=local_machine:0
    ou par -display machine:0.0 en option du programme lancé.
  5. En pareil cas, on peut travailler sur un répertoire distant avec
    $ SuSE-7.3$ $ \triangleright$ kfmclient folder nom_du_répertoire.
    $ SuSE-8.1$ $ \triangleright$ kfmclient exec nom_du_répertoire.
    Ne pas oublier d'imposer l'affichage des fichiers cachés.
  6. On peut utiliser xftp ou vsftp pour transférer des fichiers. Ne pas céder à la tentation d'autoriser root à utiliser ftp (l'interdiction est située dans /etc/ftpusers).
  7. On peut aussi monter un répertoire nfs. (*** finir de documenter cela).

3.2.3 Dès que possible

  1. Installer les services réseau (YaST $ \triangleright$ Network_Services $ \triangleright$ NTP, Routing, Hostname_and_DNS)
  2. Installer vsftpd et valider ssh (qui démarrent désormais par les runlevels, et non plus par inet.d).
  3. Imprimante réseau. Utiliser cups et le bon pilote, avec recto-verso.
  4. ($ SuSE-8.x$) Imprimante réseau : l'installation sous YaST conduisait à un spooler lpd, avec
    /var/spool/lpd/192.168.50.250-mexico-remote pour répertoire de spool et remote pour alias. Pour en faire l'imprimante par défaut, il faut que $PRINTER pointe sur cette imprimante.

3.3 Arborescence de la distribution

3.3.1 Installation sources

  1. Ce qui s'affiche dans Yast/Software/Installation_Sources provient des fichiers contenus dans /var/lib/zypp/db/sources.
  2. Ces fichiers sont renseignés au format xml et contiennent les items suivants :

  3. Il est utile de surcharger la date servant d'alias par un texte plus facile à interpréter (cf le batch infra).
  4. Il est efficace de disposer de trois sources:

    1. copie locale de la distribution /home/distrib
    2. source distante de la distrib, par exemple ($ SuSE-10.2$) ftp://ftp.skynet.be//mirror2/opensuse.org/opensuse/distribution/10.2/repo/oss/suse/noarch
    3. répertoire des rpm importées /home/distrib/extra.rpm. Laisser tout ce qui n'est pas en usage dans le répertoire /home/distrib/extra.

3.3.2 Certification des packages

  1. La distribution $ SuSE-10.2$ est répartie dans les répertoires setup, noarch, i386, i586 et x86_64. Chaque fichier est vérifiable par comparaison avec la ligne correspondante dans le fichier MD5SUM situé dans le même répertoire.
  2. Le mécanisme de vérification lors de l'incorporation d'une source par YoU est différent. Il se fonde sur le fichier distrib/content qui contient les signatures pgp des fichiers clefs, i.e. packages, patterns, et *.pat. Le fichier packages contient entre autres les signatures pgp des fichiers *.rpm.
  3. Une fois la source acceptée, il se crée un répertoire /var/lib/zypp/cache/Source.xxxxxx contenant DATA/content et DATA/descr/*.pat. On peut alors surcharger DATA/descr/patterns et introduire les nouveaux fichiers. Ne pas oublier que ce répertoire est fragile: il faut créer un répertoire source et accéder par batches (LISTING 3).


    \begin{algorithm} % latex2html id marker 1050 [htbp] \vskip 0.5 em \par \verbati... ...t{Inclu_a_installx/mk_patterns.txt} \par \caption{mk\_patterns } \end{algorithm}

  4. YaST propose plusieurs sortes de groupement de packages à savoir Patterns, Groups, Language, Sources, Search, Summary.

3.3.3 Les Patterns de packages

  1. La ventilation des packages en Patterns est sous la dépendance des fichiers *.pat. Les Patterns existants sont:

  2. Les Patterns sont obtenus en reprenant les champs [=Cat:] des fichiers visibles, i.e. [=Vis: true]. Chaque item est présenté par son champ [=Sum:].
  3. Les champs significatifs sont

  4. Liste de packages à inclure :

3.3.4 Les Groups de packages

  1. Pour la $ SuSE-10.2$, la ventilation des packages en ''Groups'' est le fait du seul fichier /home/distrib/suse/setup/descr/packages. Celui contient, pour chaque package, des champs (=) et des listes [+open, - close].
  2. C'est ainsi que les paramètres de frozen-bubble sont :

    1. Liste ''Provides'' : +Prv: -Prv:

      fb_c_stuff.so()(64bit)

      (exactement comme ''Alternate Version)

    2. Liste ''Prerequires'' : +Prq: -Prq:

      rpmlib(PayloadFilesHavePrefix) <= 4.0-1

      (diverses conditions rpmlib)

      /bin/sh

    3. Liste ''Requires'' : +Req: -Req:

      (les mêmes conditions rpmlib)

      libc.so.6()(64bit)

      libc.so.6(GLIBC_2.2.5)(64bit)

      (exactement comme ''Alternate version'', mais dans un ordre différent)

    4. Liste ''Auteurs'': +Aut: -Aut:

      Guillaume Cottenceau <guillaume.cottenceau at free.fr>


3.3.5 Pour mémoire : les fichiers *.sel ($ SuSE-9.3$)

Le mécanisme décrit ci-dessous est celui de la $ SuSE-9.3.$ Selon un souvenir imprécis, il était en place depuis la $ SuSE-8.1$.

  1. Les sélections proposées sont stockées dans /DVD/suse/setup/descr.
  2. La sélection d'une source d'installation, par yast2 inst_source, conduit à la création d'un répertoire /var/adm/YaST/InstSrcManager/IS_CACHE_0x000000??/ qui mémorise diverses choses. En particulier, /DATA/descr contient une copie des descriptions. Cette copie est faite une fois pour toutes. Ne pas oublier de modifier simultanément l'original et cette copie. Ne pas supprimer le répertoire copie pour le recréer ensuite, car cela suppose d'avoir fait la sauvegarde au bon endroit...
  3. Ces fichiers sont des fichiers texte, contenant des paramètres (=) et des listes ouvertes (+) puis fermées (-).
  4. Selon le paramètre "=Cat:", il existe trois types de fichiers *.sel :

  5. Les sélections de base contiennent des noms de sélections addon (parenthésées par +Req, -Req), des noms de packages (parenthésés par +Ins, -Ins), des noms de packages par langue (parenthésés par +Ins.xx, -Ins.xx) et divers cosmétiques. Pour ce qui est des addon :

  6. Le paramètre "=Ord:" règle l'ordre d'affichage des sélections (qui doit être indépendant du message affiché). Pour les sélections de base, cet ordre est : 01 Minimal, 02 Minimal+X11, 03 default-Gnome, 04 default, 10 X11, 11 Kde-Desktop
    Pour les autres, cet ordre est : 00 Min, 12 Kde, 13 Gnome, 14 SuSE-Documentation, 15 Office, 16 Games, 17 Multimedia, 20 Voip, 25 Xen, 30 LAMP2, 35 LDAP-Server, 40 Network, 45 Laptop, 50 Mobile (plusieurs versions, dépendant de l'architecture), 60 Basis-Devel, 61 Kernel-Devel, 62 Kde-Devel, 63 Gnome-Devel, 64 Tcl-Development, 65 Java, 70 Hacker, 80 Latex, 85 Fonts, 91 DVD-Asia.
  7. On crée un fichier $ipse-9.3-83.noarch.sel sur le modèle de "Laptop" (= le plus petit). On lui donne les valeurs "=Cat: addon", "=Ord: 43". On indique les packages adhoc:
    apache2, gimp, gv, gftp, howtoenh, htdig, kdeutils3-extra, lyx, samba, telnet-server, webalizer, whois
  8. Un fichier est pris en compte lorsqu'il est déclaré dans le fichier selections. Le nom exact du package est nécessaire pour qu'il soit identifié, et apparaisse dans la liste. Le "nom exact" est le nom au sens de l'interpréteur YaST. Il y a sûrement des règles pour cela. Une expérimentation rapide est possible par la commande yast2 sw_single.
  9. Placer les rpm étrangères à la distribution dans /home/distrib/extra. Puis déclarer ce répertoire comme une source : cliquer sur l'un des fichiers rpm, puis valider "Use directory as source with YaST". Les rpm apparaissent alors, même lorsqu'elles ne sont pas installées.
  10. Importer les rpm suivantes (qui ne sont pas sur la distrib en 5 cdrom)
    gftp (2.0.18-3), howtoenh (2005.3.6-2), kdeutils3-extra (3.4.0-7), webalizer (2.01-728.2)
  11. Après avoir ajouté de nouvelles rpm dans /home/distrib/extra, il semble nécessaire de faire un yast/change_source/refresh, car un mécanisme de cache est en place.
A nouveau : il faut une sauvegarde des descripteurs dans /home/distrib, en plus de l'exemplaire actif dans /var/admin/.

3.3.6 Pour mémoire : compléments pour la $ SuSE-8.1$

3.3.7 Pour mémoire : anciens fichiers *.sel

Jusqu'à $ SuSE-7.3$, les *.rpm étaient classés en "groupes", et des modèles de sélection étaient proposés dans /usr/lib/YaST/default.sel. Remarque de l'époque : "choisir un peu plus de doc, tex (tex/te_ams, malgré la doc, est nécessaire), network". Avec au minimum : ap-enscript, gra-gimp, kpa-LyX, n-samba, tex-{latex, psutils l2h, etc.}, xsrv-mach(8/32/64).

Cette installation est enregistrée dans /var/adm/inst-log/. La "sélection en cours", i.e. la liste des packages installés à un moment donné, est copiable sur une disquette qui s'en trouvera (automatiquement, mais obligatoirement) formatée au standard minix.

Une telle sélection est un fichier texte. Utiliser qdd* pour obtenir les différences, et mettre au point une "bonne" sélection reproductible... Permet d'éviter les gcal, amor et autres sottises.
Format des fichiers *.sel :

# SusE-Linux Configuration YaST Version 1.01 - (c) 1994-99 SusE GmbH 
Description:  
Info: 
Ofni: 
Toinstall: 
*** liste triée des packages, un par ligne 
Llatsniot:

3.4 SCPM

  1. SCPM est l'acronyme de system configuration profiles manager. Est lancé par /etc/init.d/boot.scpm et utilise les données stockées en /var/lib/scpm/. Semble être surtout utile pour un portable, mais peut aussi servir à archiver une configuration.
  2. De toutes façons, tant que /sbin/scpm n'a pas été initialisé, on recueille des messages d'erreur. Modifier /etc/scpm.conf pour que les messages aillent dans /var/log/scpm.log.
  3. Lancer une fois (en tant que root) /sbin/scpm enable pour créer la base de données, puis /sbin/scpm disable pour s'en débarrasser.

3.5 Documentation

La documentation n'est utile que si on sait où elle se trouve. Ajouter les signets nécessaires dans les bookmarks. Une bonne configuration du serveur apache est également utile. En tout état de cause, voici quelques indications sur ces fichiers.

3.5.1 Fichiers man

  1. Les fichiers man viennent se positionner en /usr/share/man/manx/xxxxx.gz et les versions traduites vont en /usr/share/man/language/manx/xxxxx.gz. Virer tous les coucous rédigés dans des langues non souhaitées (scories *.rpm). Le batch qxm_purge_man fait cela.
  2. Avec $ SuSE-7.2$, les fichiers du package allman venaient se positionner dans un répertoire spécial... entraînant un lot de doublons. Encore plus, faire du ménage.
  3. Lecture en hypertexte man:xxxxx sous konqueror, impression par le batch pman ou pman7.
  4. Recherche par "SuSE Help" (indexation htdig)


3.5.2 HowTo

  1. Les fichiers HowTo sont accessibles à partir de /usr/share/doc/howto/en/html/. Placer un signet dans les favoris.
  2. Ces fichiers ne sont pas sur la sélection en 5 cdrom de la $ SuSE-9.3$. Les télécharger depuis ftp://anonymous@ftp.uni-kl.de:21/pub/linux/suse/i386/9.3/suse/noarch. Pour $ SuSE-10.2$, utiliser ftp://ftp.skynet.be//mirror2/opensuse.org/opensuse/distribution/10.2/repo/oss/suse/noarch
  3. Pour rechercher un HowTo particulier, utiliser le §5 (Single list of HowTo) de l'index
    /usr/share/doc/howto/en/html/HOWTO-INDEX/howtos.html.
  4. En tout état de cause, on peut en trouver une copie sur le site http://www.tldp.org/.

3.5.3 Documentation système

  1. Les descriptions du matériel étant éparpillées dans beaucoup de commandes et de fichiers, le risque de manquer une information importante, ou de rompre la cohérence de la "base de registre" est élevé. Il est indispensable de collecter ces éléments épars. Le principe (adapté à la $ SuSE-9.3$) de cette collecte est donné LISTING 4.


    \begin{algorithm} % latex2html id marker 1228 [htbp] \vskip 0.5 em \par \verbati... ...clu_a_installx/qys_docs_sys} \par \caption{qys\_docs\_systeme. } \end{algorithm}

  2. Une description des services en cours s'obtient en interrogeant tous les scripts du répertoire /etc/init.d par la commande /etc/init.d/xxx status. Attention aux scripts halt et stop qui ne testent pas les options... et qui arrêtent tout. Le principe (adapté à la $ SuSE-9.3$) de cette collecte est donné LISTING 5. Et son résultat LISTING 6.


    \begin{algorithm} % latex2html id marker 1239 [htbp] \vskip 0.5 em \par \verbati... ...lu_a_installx/qyS_docs_status} \par \caption{qyS\_docs\_status } \end{algorithm}


    \begin{algorithm} % latex2html id marker 1243 [tbph] \vskip 0.5 em \par \verbati... ...clu_a_installx/doc_all_status} \par \caption{État des services } \end{algorithm}

  3. Pour des raisons exposées LISTING 7 Subsection 3.6, le batch qyr_docs_reseau a du être réécrit en entier.


    \begin{algorithm} % latex2html id marker 1250 [htbp] \vskip 0.5 em \par \verbati... ...lu_a_installx/qyr_docs_reseau} \par \caption{qyr\_docs\_reseau } \end{algorithm}


3.6 Le mécanisme rc.status

  1. L'ensemble des fichiers /etc/init.d/xxx, qui commandent les runlevels, émettent des messages à travers un mécanisme compliqué, dépendant entre autres du fichier /etc/rc.status.
  2. Lors du boot, en effet, on voit défiler toute une suite de messages décrivant les étapes parcourues. Pour des raisons d'ergonomie, il est utile que chaque message se termine par un diagnostic rapide (eg: done, running, skipped, unused, dead) et c'est mieux encore si ce diagnostic est en couleur.
  3. Sur un terminal xterm, les couleurs sont commandées par des codes ansi, qui sont des séquences commençant par $ \backslash033$. L'utilisation de -e dans la commande
    echo -e "toto\033[31mtutu\033[30m"
    provoque l'interprétation de \033 comme étant le caractère $ \left[escape\right]$. Sur un terminal xterm, cela provoque l'affichage de "toto" en noir, puis de "tutu" en rouge. Envoyé dans un fichier par echo -e ... > qui, cela provoque la pollution du message par les séquences en question (qui, en plus sont de longueur variable selon les fonctions).

  4. Il faut donc que les batchs concernés permettent une double écriture, l'une pour xterm (en couleur, diagnostics alignés à droite) et l'autre pour dumb (les terminaux raw, ou ou l'écriture sur fichier). Il existe en fait deux mécanismes :

    1. Émission de messages sans retour à la ligne (par echo -n), et d'un code d'erreur (par return). Selon le cas, le diagnostic est alors émis sous sa forme simple ou sous sa forme couleur, puis on passe à la ligne
    2. Émission de messages avec retour à la ligne (et un code d'erreur). Sur un xterm, il faut alors mémoriser la position, remonter d'une ligne, émettre le diagnostic puis revenir à la position. Tandis que sur un dumb, il faut ...
  5. On constate que les messages émis par les différents scripts de /etc/init.d/ se diversifient les uns des autres, indiquant que chaque nouveau venu se contente d'un examen minimal de ce qui se passe.
  6. Sous $ SuSE-9.3$, ce mécanisme a été malmené de plusieurs façons, le rendant quasi inutilisable en mode dumb.


3.7 Cartes graphiques et SaX

3.7.1 Quand tout va bien

  1. En principe, le graphisme est géré par YaST2 lors de l'installation et il n'y a pas à s'en préoccuper. Mais, comme il se doit, la pratique est plus mouvementée que la théorie.
  2. Ne pas oublier les réglages bus AGP, irq pour la carte, etc. Il n'est pas bien clair si ces réglages sont conservés ou non par le login graphique.


3.7.2 Quand il faut y mettre les mains

  1. Le programme sous-jacent est sax.sh. Il se lance par un frontal.

    1. $ SuSE-10.2$ : lancement par le batch sax2. Alternative : sax2-vesa lorsqu'il faut imposer une basse résolution. Plus de détails par sax2 -h.
    2. anciennement : sax2 (depuis la $ SuSE-7.2$) conduisait à XFree86.4, tandis que sax conduisait à XFree86.3 (cf A.3).
  2. Documentation sax/x11 : n'arrête pas de changer de forme et de place.

    1. $ SuSE-10.2$ le package xorg-x11-doc installe un ensemble de fichiers *.ps.gz dans /usr/share/X11/doc/hardcopy/ tandis que /usr/X11R6/man/ reste vide.
    2. $ SuSE-8.1$ et $ SuSE-9.3$ ensemble de pages man dans /usr/X11R6/man/.
    3. $ SuSE-8.1$ pages man en html /usr/X11R6/lib/X11/doc/html/, non synchronisées avec les pages man ordinaires.
  3. Avant toute série de modifications, faire une copie de /etc/X11/xorg.conf (qui était, pour la $ SuSE-8.1$, /etc/X11/XF86Config et /etc/XF86Config jusqu'à la $ SuSE-7.1$). Il existe bien une sauvegarde automatique, mais... elle est écrasée à chaque modification.
  4. Tant que le graphisme ne fonctionne pas de façon fiable, il faut rester en mode "login console", avec passage au graphisme par la commande startx. Cela se règle dans YaST2/System/Runlevel Editor (3= console, 5= graphique). Auparavant, cela se réglait dans YaST/admin/login.

3.7.3 Les items proposés

Ils dépendent de la base de connaissance /usr/share/sax/api/data/cdb.


TAB. 8: Codes et drivers des cartes graphiques
\begin{tabular}{\vert c\vert c\vert c\vert c\vert\vert r\vert c\vert} \hline qu... ...mave& GeForce 7600GT& 10de:0391& ???& 256& \tabularnewline \hline \end{tabular}






3.7.4 Les problèmes


3.8 Cartes réseaux

3.8.1 Pour mémoire

  1. Utiliser les scripts LISTING 4 et LISTING 7
  2. La commande ifconfig n'est pas dans le path de l'utilisateur ordinaire. Placer un lien vers /bin/ifconfig.
  3. Jusqu'à $ SuSE-7.0$, YaST2 n'installe qu'une seule carte réseau. Pour les autres, faire à la main. Les deux cartes sont prises en compte par $ SuSE-7.2$.
  4. Variables utilisées par YaST ($ SuSE-7.x$)

    Ne pas déclarer les cartes comme modules préalables au boot (= laisser vide initrd_modules) !!!
    Caveat NETCONFIG prend un espace ....

    INITRD_MODULES="" 
    START_LOOPBACK="yes" 
    NETCONFIG="_0 _1" 
    IPADDR_0="90.0.0.186" 
    IPADDR_1="90.0.0.187" 
    NETDEV_0="eth0" 
    NETDEV_1="eth1" 
    IFCONFIG_0="90.0.0.186 broadcast 90.0.0.255 netmask 255.255.255.0 up" 
    IFCONFIG_1="90.0.0.187 broadcast 90.0.0.255 netmask 255.255.255.0 up" 
    IP_DYNIP="no" 
    IP_TCP_SYNCOOKIES="yes" 
    IP_FORWARD="yes" 
    START_INETD="yes" 
    START_PORTMAP="yes" 

3.8.2 Carte pci : Surecom EP-320X-R

  1. Code pci = 10EC/8139.
  2. Pilote rtl8139

3.8.3 Carte pci: Realtek RTL-8169 Gigabit

  1. Code pci = 10ec:8169
  2. Pilote r8169. Reconnue d'origine par $ SuSE-9.3$. Pour $ SuSE-8.1,$ il faut compiler un driver à partir des sources fournies avec la carte.

    1. Copier le fichier source en /opt/rpm/giga_card/2.4.x/r8169.c.
    2. Installer les sources du noyau.
    3. Vérifier que /lib/modules/`uname -r`/build existe et pointe vers les sources du noyau (ici /usr/src/linux-2.4.19.SuSE).
    4. Vérifier que /lib/modules/`uname -r`/build/include/linux/version.h est bien une copie à l'identique de /boot/vmlinuz.version.h
    5. Dans le fichier Makefile, remplacer l'option -I/usr/include/linux par -I/lib/modules/`uname -r`/build/include.
    6. Dans le fichier source, commentariser la ligne "timer" // typedef struct timer_list timer_t (comme indiqué dans le fichier readme.txt). Compiler.
    7. Copier le driver dans /lib/modules/`uname -r`/kernel/drivers/net/r8169.o et le lancer par insmod.
    8. Déclarer ce driver dans /etc/modules.conf.

3.8.4 Carte pci : DFE-530TX

  1. Code pci = 1106/3043. Marquée FDE-530TX sur le circuit.
  2. Sur la machine POTJEVLEISH, deux cartes réseau DFE-530TX sont prévues. Sous win98, difficultés pour différencier les irq (bios). Le "voisinage réseau" regroupe correctement ce qui est relié aux deux cartes. Par contre certains programmes hp n'interrogent qu'une seule carte (slot2) : l'imprimante est donc détectée pour la création d'un port (mais pas pour l'impression) ou bien figure dans le listage de JetAdmin (mais n'est pas accessible aux modifications par le même JetAdmin)



    slot carte irq port ip
    agp



  3. Reconnue par $ SuSE-6.3$, pilote via-rhine sans paramètres, conduisant à irq=10, io=6800.

3.8.5 Carte pci : ne3000

  1. Pas de code pci ? Marquée comme : sn3200ct : composants delta : 004005-5696AA
  2. Testée sous win95/win98. Reconnue comme RealTek RTL-8029. (irq=10, io=7f20).
  3. Reconnue par $ SuSE-6.2$, pilote ne2k-pci, sans paramètres. Est détectée comme clone RealTek RTL-8029 et fonctionne par exemple en irq=9, io=6C00 (ou en irq=12, io=7000)

3.8.6 Carte pci : carte Intel 82557

  1. Code pci : 8086/1229. Marquée comme : "mp 721502-005", "pb 721503-005", "Philippines gd82559"
  2. N'est pas auto-reconnue par Win98(1). Il faut déclarer son pilote (Intel Pro 100 - Tx). Est reconnue par Win98(2).
  3. Reconnue par $ SuSE-?$ : pilote eepro100. Fonctionne alors comme : irq 10, "Intel EtherExpress Pro 10/100" et 0xd800 "Intel Speedo3 Ethernet"

3.8.7 Carte isa : ne2000

  1. Marquée comme sn2000CT rev A1 : composants delta : 004005-187E36
  2. Fonctionne sous win95 (compatible Novel/Anthem ne2000) : irq=10, io=220.
  3. Pilote nullix = ne. Entre en conflit
Diagnostic vraisemblable : conflit avec une carte son (qui est déclarée " automatiquement" en io200 ???). Reconfiguration dans les configurations de base (10-240) pour ne2000 et (5-220,388,200,9-330) pour alsound.

  1. Passage 240->260, 220->240, 260->220 sous dos.
  2. Déclaration sous YaST
  3. On constate une modification de /etc/conf.modules
  4. La commande "modprobe ne" entraîne une recompilation des dépendances (depmod)
  5. Fonctionnement correct de ping, visibilité des serveurs sur le réseau

3.9 Souris

  1. Il arrive que la souris, après avoir fonctionné correctement, ne soit plus détectée. Ainsi ($ SuSE-7.0$) une souris série compatible M$, COM1, /dev/ttyS0. De même une souris intellimouse sur ps2 ($ SuSE-9.3$). La commande YaST2/hardware/Mouse/Tester, exécutable au clavier seul $ \left[M-T\right]$, rend la souris utilisable. On remarque que le type proposé est le bon.
    Créer un lien /dev/input/mice vers /dev/mouse semble un contournement efficace.
  2. Pour mémoire. Avec les versions antérieures (YaST), Il est indispensable de déclarer une souris (défaut=ms-like, com2= dev1), sinon : gros drame avec SaX. Refuser gmp (salades souris sous dos : conflit avec quelque chose en mode win).

previous up next contents
Previous: 2 Exemples d'installation Up: Installx 101 Next: A. Pour mémoire   Contents


douillet@ensait.fr
2007-12-06