Archlinux.fr [Forums]

Salut !

Je cherche actuellement à ne charger que les modules, pilotes, etc, nécessaires à mon PC au démarrage.

(je ne veux pas non plus me compiler un kernel perso, car je veux pouvoir mettre à jour avec pacman sans trop bidouiller)

Mon ordi :
Gericom Webgine
Proc AMD Athlon 1,7GHz (1667MHz), FSB 266MHz
512Mo SDRAM
Graphique : S3 savage4, 32Mo mémoire partagée
DD en IDE (sûr)
CD en IDE (? pas sûr mais serait logique)

Voici mon mkinitcpio.conf et mon rc.conf

Code : Tout sélectionner

# vim:set ft=sh

MODULES="pata_acpi pata_via ata_generic"

BINARIES=""

FILES=""

MODULES

HOOKS="base udev autodetect pata scsi keymap filesystems"

Code : Tout sélectionner

# /etc/rc.conf - Main Configuration for Arch Linux

LOCALE="fr_FR.UTF-8"
HARDWARECLOCK="localtime"
USEDIRECTISA="yes"
TIMEZONE="Europe/Paris"
KEYMAP="fr-latin1"
CONSOLEFONT="lat9w-16"
CONSOLEMAP="8859-15"
CONSOLETRANSLATION="8859-15_to_uni"
USECOLOR="yes"

# HARDWARE

MOD_AUTOLOAD="yes"

MODULES=(mii slhc via-rhine ac97_bus snd-mixer-oss snd-pcm-oss 
snd-seq-oss snd-seq-device snd-seq-midi-event snd-seq snd-page-alloc 
snd-pcm snd-rawmidi snd-timer snd snd-mpu401-uart snd-ac97-codec 
snd-via82xx-modem snd-via82xx soundcore powernow-k7)

USELVM="no"

HOSTNAME="webgine"

lo="lo 127.0.0.1"
eth0="eth0 192.168.0.[caché] netmask 255.255.255.0 broadcast 192.168.0.255"
INTERFACES=(lo eth0)

gateway="default gw 192.168.0.254"
ROUTES=(gateway)
 
DAEMONS=(syslog-ng acpid cpufreq network @alsa hal netfs crond lisa cups)

VERBOSEONFAIL="yes"

(je vous ai épargné les 3 pages de commentaires ^^)

Si je vire scsi de mkinitcpio, et que le lecteur CD ne fonctionne pas, j'aurai qu'à le remettre ? Est-ce aussi simple que ça ?

La grosse question du post : qu'est-ce que je peux virer ?

(j'ai déjà viré usbinput, sata et euh... des trucs inutiles de façon flagrante.)

La solution la plus simple est d'essayer : tu décharges tes modules un par un jusqu'à avoir une config qui te satisfasse, et tu modifies tes fichiers de conf en conséquence.

Sinon, en dehors de virer certains hooks, je ne vois pqs trop quoi retirer.
Tu peux zyeuter de ce coté-là si tu veux pour de la bidouille...

Pour ton lecteur de CD, déjà tu regqrde dans la sortie de dmesg pour voir comment il est reconnu, mais vu ta conf, ça doit être de l'IDE.

Est-ce que virer scsi peur poser des problèmes lors de l'utilisation de périphériques externes USB ou firewire émulant du scsi ?

Au pire t'as toujours l'image fallback avec tous les hooks

Jettes un coup d'oeil à ce sujet : mon premier message n'a rien a priori rien à voir avec ce que tu veux faire, mais la méthode que je suggère bricole avec mkinitcpio. Cela devrait pouvoir t'aider.

Depuis lors, j'ai améliorer un peu ma recette (et je suis notamment revenu aux anciens pilotes IDE suite à quelques soucis avec hdparm). Mon mkinitcpio.conf pour le noyau 2.6.25.6 est désormais :

Code : Tout sélectionner

MODULES="ide_core atiixp ide_disk ext3"
HOOKS="base keymap"

On peut même virer keymap mais on se retrouve avec un clavier qwerty en cas d'échec de la création de la partition racine au démarrage. Ce n'est de toute façon pas bien embêtant pour taper "exit"...

warnaud a écrit :Au pire t'as toujours l'image fallback avec tous les hooks

Euh..."négatif ghost rider"...la seule différence entre l'image principale et le fallback réside dans la non-utilisation du hook autodetect. À part ça, ce sont strictement les mêmes hooks qui sont utilisés, ce que je trouve au passage complètement débile.
Pour avoir un vrai initrd de secours, il faut définir un fichier de conf propre au fallback et configurer en conséquence mkinitcpio. Ou s'en faire un à la main qui ne sera jamais touché pas des mises à jours foireuses, avec une entrée spéciale dans Grub.

Je vais faire une copie de mon image actuelle pour la lancer si besoin depuis grub si ça foire.

Mes hooks sont nickel, adaptés à mon ordi.

J'aimerais revenir sur un point, c'est les modules.

J'ai un DD IDE en reiserfs, et j'ai ceci dans mon mkinitcpio.conf :

Code : Tout sélectionner

# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES="pata_acpi pata_via ata_generic"

J'ai trouvé aucune page qui liste les modules et à quoi ils servent...
Ici, ils n'en parlent même pas... http://wiki.archlinux.org/index.php/Con ... mkinitcpio

Et puis d'abord puisque j'ai rien touché, pourquoi j'ai pas ce qui est conseillé en commentaire au-dessus... (hwd a choisi pour moi, je crois)

Donc j'aimerais bien connaître le rôle des différents modules, en gros pour mettre seulement ce qui est indispensable, et spécialisé. (il me semble que je devrais mettre reiserfs)

Genre, arriver à un truc comme ça me satifairait :

Code : Tout sélectionner

MODULES="ide_disk reiserfs"
#Avec reiserfs dans les modules je vais pouvoir virer filesystems des hooks !!

(c'est sûrement pas viable, mais alors que manque-t-il ? Je veux comprendre ! Mais j'ai pas trouvé de page de wiki sur les modules)

Il y a plusieurs façon de procéder. J'y vais à tâton, à coup d'essais successifs, mais sans faire le bourrin, comme décharger un à un les modules d'un système installé par défaut, pour voi lesquels sont indispensables :S, surtout que cette méthode mélange deux choses : le chargement de l'initrd qui au démarrage créée la partition racine et lance le noyau, et tout ce qui est lancé par le système, et notamment udev.

Bref, commencons avec lsmod : cette commande liste tous les modules chargés, dans l'ordre décroissant de lancement (les premiers sont les derniers lancés, le bas de liste désigne ceux lancés au démarrage par l'initrd). Chez moi, cela donne :

Code : Tout sélectionner

ext3                  124040  2
jbd                    44052  1 ext3
mbcache                 7172  1 ext3
ide_disk               12928  4
atiixp                  3716  0 [permanent]
ide_core              103584  3 ide_cd_mod,ide_disk,atiixp

Cela permet de voir que ide_core est utilisé par 3 autres modules, et notamment par ide_disk et atiixp (c'est le module qui correspond à ma carte mère, pour toi ce serait un truc en *via* (par ex pata_via) qui eux n'ont pas de liens de dépendance entre eux. et on voit que ma partition root est formatée en ext3 et que le module correspondant est chargé, et qu'il fait appel à jdb et mbcache.

Donc, pour avoir une liste de modules nécessaires et suffisants dans le mkinitcpio.conf, on prend le résultat de lsmod dans l'ordre inverse, et en faisant le tri comme je viens de le faire.

Pour avoir plus d'info sur un module particulier, il y a la commande modinfo :

Code : Tout sélectionner

$ modinfo ext3
filename:       /lib/modules/2.6.25-ARCH/kernel/fs/ext3/ext3.ko
license:        GPL
description:    Second Extended Filesystem with journaling extensions
author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others
depends:        mbcache,jbd
vermagic:       2.6.25-ARCH SMP preempt mod_unload 686

Elle perme de voir que pour moi, je pourrais me passer de lister ide_core, car c'est une dépendance de ide_disk. Cela fait pour ma machine, avec les pilotes IDE classiques (non ata) :
MODULES="atiixp ide_disk ext3"

À partir du moment où les modules nécessaires pour créer la partition root sont donnés, aucun hook n'est nécessaire à part base.

Tous les autres modules seront lancés par udev en fonction des besoins de ton système, tu n'as pas à t'en occuper.

Wahou, merci !

Je crois qu'on peut copier ton message dans le wiki !

Y'a du ménage à faire chez moi alors !!

Code : Tout sélectionner

[root@webgine ~]# lsmod
Module                  Size  Used by
ipv6                  256196  8
savage                 31616  2
drm                    72472  3 savage
usbhid                 42944  0
hid                    39296  1 usbhid
ff_memless              5128  1 usbhid
joydev                 10048  0
pcmcia                 33068  0
ppdev                   7556  0
lp                      9444  0
ppp_generic            24348  0
psmouse                36880  0
pcspkr                  2816  0
serio_raw               5508  0
firewire_ohci          16512  0
firewire_core          36928  1 firewire_ohci
crc_itu_t               2304  1 firewire_core
i2c_viapro              7956  0
i2c_core               19348  1 i2c_viapro
via_ircc               18324  0
irda                  114104  1 via_ircc
crc_ccitt               2304  1 irda
uhci_hcd               22288  0
shpchp                 29460  0
vt8231                 15372  0
ohci1394               28720  0
usbcore               129776  3 usbhid,uhci_hcd
parport_pc             34884  1
parport                31596  3 ppdev,lp,parport_pc
ieee1394               79288  1 ohci1394
pci_hotplug            26276  1 shpchp
via_agp                 8448  1
agpgart                28244  2 drm,via_agp
yenta_socket           23436  1
rsrc_nonstatic         11264  1 yenta_socket
pcmcia_core            33172  3 pcmcia,yenta_socket,rsrc_nonstatic
sg                     27188  0
thermal                15260  0
processor              32096  2 thermal
evdev                   9472  5
fan                     4356  0
button                  6416  0
battery                10372  0
ac                      4484  0
snd_via82xx_modem      11400  1
snd_via82xx            23192  3
gameport               11020  1 snd_via82xx
snd_ac97_codec         97828  2 snd_via82xx_modem,snd_via82xx
snd_mpu401_uart         7168  1 snd_via82xx
snd_rawmidi            19840  1 snd_mpu401_uart
snd_seq_oss            30336  0
snd_seq_midi_event      6656  1 snd_seq_oss
snd_seq                48432  4 snd_seq_oss,snd_seq_midi_event
snd_seq_device          6796  3 snd_rawmidi,snd_seq_oss,snd_seq
snd_pcm_oss            38656  0
snd_pcm                68228  5 snd_via82xx_modem,snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_timer              19848  3 snd_seq,snd_pcm
snd_page_alloc          8072  3 snd_via82xx_modem,snd_via82xx,snd_pcm
snd_mixer_oss          14848  1 snd_pcm_oss
snd                    46628  18 snd_via82xx_modem,snd_via82xx,snd_ac97_codec,snd_mpu401_uart, snd_rawmidi,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_pcm, snd_timer,snd_mixer_oss
soundcore               6496  1 snd
ac97_bus                2048  1 snd_ac97_codec
via_rhine              20360  0
slhc                    6016  1 ppp_generic
mii                     4992  1 via_rhine
rtc_cmos                9120  0
rtc_core               15516  1 rtc_cmos
rtc_lib                 2944  1 rtc_core
reiserfs              229760  1
sr_mod                 15300  0
cdrom                  33952  1 sr_mod
sd_mod                 23320  3
ata_generic             5636  0
pata_via                8580  2
pata_acpi               4992  0
libata                142096  3 ata_generic,pata_via,pata_acpi
scsi_mod               92204  4 sg,sr_mod,sd_mod,libata
dock                    7952  1 libata

Il semble que je peux virer pata_acpi, et je vois pas la nécessité de garder ata_generic", puisqu'ils ne sont utilisés par rien... Non ?

Code : Tout sélectionner

# Mon mkinitcpio.conf actuel
MODULES="pata_acpi pata_via ata_generic"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi keymap filesystems"

Et donc je peux faire ceci :

Code : Tout sélectionner

# Projet de mkinitcpio.conf
MODULES="pata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect scsi keymap"

Ou bien j'ai encore trompé ?

Clark a écrit :
warnaud a écrit :Au pire t'as toujours l'image fallback avec tous les hooks
Euh..."négatif ghost rider"...la seule différence entre l'image principale et le fallback réside dans la non-utilisation du hook autodetect. À part ça, ce sont strictement les mêmes hooks qui sont utilisés, ce que je trouve au passage complètement débile.

c'est les même hooks, mais pas le même contenu, du fait de l'omission de autodetect, tous les modules sont disponibles pour tous les hooks installés.

l'image fallback est une image de secours au cas où le système détécte mal les périphériques, mais le choix de ce qui est lancé reste à l'appréciation de l'utilisateur, ce n'est donc pas un initrd générique censé fonctionner partout, sinon je vois pas l'intéret d'en générer un, il n'y a qu'à fournir un paquet tésté pour pleins d'ordi et c'est plié, et ca revient à avoir l'initrd du cd d'install d'arch qui fait dans les ~30mo.

> Tuxce : yes, c'est bien ce que je dis : donc quand on veut jouer avec les hooks et qu'on se plante, le fallback n'est d'aucune utilité, la machine ne démarrera pas (avec la conf par défaut de mkinitcpio).

> Calimero : non, il n'y aura pas tant de ménage que ça : l'immense majorité des modules est lancée par udevd. Ça ne concerne en rien la création d'une image initrd. Si c'est vraiment par là que tu veux aller, il faut jouer avec la liste des modules dans le rc.conf et là, je te souhaite bien du plaisir, sachant que ces derniers temps le masquage de modules par ce moyen peut ralentir le démarrage (cf une discussion sur la liste de discussion des dev)(c'est peut-être ne passe d'être réglé ?).
Pour finir, tu as besoin de lister ata_generic : il n'est certes utilisé par rien mais c'est lui qui appelle libata. Remarque commexe pour pata_acpi : il n'est peut-être pas utile, mais pour le savoir il faut faire l'essai et lire le résultat (au moins le début...)de la commande dmesg après le démarrage pour voir si ça crie quelque part (si ça démarre ! J'insiste : bien créer une image "sécuritaire" en secours avant toute manip').
Bien sûr, je parle dans un contexte ou tu vises HOOKS="base". Si tu y laisse udev et quelques autres trucs, ça ne sert pas à grand chose de jouer avec MODULES (sauf si hwd merdoie sur ta machine).

En fait, il faut définir clairement ce que tu veux avec ton système. Si tu veux décider exactement à la main (en rigide) quel module doit démarrer et quand, avec Arch, tu es obligé de fixer MOD_AUTOLOAD="no" dans le rc.conf, ce qui te privera du hotplug...Ou alors j'ai raté quelque chose dans la doc : si quelqu'un a un avis sur la question, je suis preneur.

Clark a écrit :> Tuxce : yes, c'est bien ce que je dis : donc quand on veut jouer avec les hooks et qu'on se plante, le fallback n'est d'aucune utilité, la machine ne démarrera pas (avec la conf par défaut de mkinitcpio).

tout à fait

mais c'était plus sur la remarque que j'ai répondu, dans le sens où je trouve que ce n'est pas débile de prévoir un mauvais fonctionnement de autodetect lors d'une maj, par contre prévoir une mauvaise action de l'utilisateur...

sinon rien n'empeche de se garder une copie d'un kernel qu'on est sur qu'il fonctionne dans un coin à part (avec les modules bien sur, en gros, un pkgbuild modifié).

Un "cp /boot/kernel26.img /boot/kernel26bak.img" suffit ?
Je veux dire pour avoir une image qui fonctionne au cas où.

Sinon : y'a moyen que mkinitcpio ne crée pas l'image fallback, qu'il se borne à créer l'image principale quoi, sans rebuilder le fallback... ?

Comme ça, c'est un vrai fallback, qu'on crée une fois pour toutes. (et qu'on refait normalement, une fois que la config testée est stable)

A la limite (synthèse de mes 2 questions) :
Est-ce que ça marche de laisser mkinitcpio créer son fallback qui sert à rien (dans mon cas) puisqu'il est "pareil" que l'image principale, et de copier de côté une image (principale) qui fonctionne en remplaçant dans grub la ligne du fallback par celle-ci ?

il suffit d'enlever fallback de la ligne PRESETS du fichier:
/etc/mkinitcpio.d/kernel26.preset
mais dans ce cas, ton image fallback ne sera plus valable à la prochaine maj du kernel, par contre mettre un fichier de config sécifique pour générer ce que vous entendez par image fallback serait meilleur

sinon pour répondre à la question, ca fonctionne tant que tu ne changes pas de kernel

OK c'est nickel, je peux faire toutes les bêtises que je veux avec mes modules et mes hooks alors, tant que je garde une copie d'image.

Je confirme : cherche mes différents posts, et tu verras que je me suis déjà battu avec mkinitcpio.

De toute façon, même si tu plantes ton kernel, tu boot avec un CD d'install, tu montes tes partitions, tu chroot dans ton /, et tu remodifie ton mkinitcpio et regénère un initrd...

Archlinux.fr [Forums]

[kernel&init] Optimisation

[kernel&init] Optimisation