[Problème MAKEDEV]New instal Debian Sarge 3.1r0a (nuxusb)

Support Debian
#1

Salut tout le monde. Et une Debian d’installée de plus. Une !
Je débute donc avec cette fabuleuse distribution.
Dans le but de partager mon petit bout de chemin, je posterai de temps en temps mes avancées, les choses incomprises et comprises. Bref, ceci pourra être utile aux nouveaux qui débutent, et je les encouragent à en faire autant.

Une pensée de reconnaissance pour les admins et modérateurs de ce forum, et pour tous ceux qui ont postés. Une vrai mine d’or !!! 8)

Cela fait quelques semaines que je vous lis, de long en large, principalement les posts parlant de la compilation de noyau.
N’hésitez pas à me baffer si un post répondant à mon problème m’a échappé … (Vu la simplicité de la chose exposée ici, vous pouvez m’en mettre plusieurs)

J’aimerai avoir votre avis sur ceci :

1/ Installation d’une Debian toute fraiche à partir d’un CDROM Debian Sarge 3.1r0a
2/ Choix de l’installation des packages par le net. 75 Mo environ à télécharger, soit à peu près 6 heures avec une ligne RTC. :confused:
3/Ensuite une fois le tout terminé et quelques vérifs au niveau des logs m’indiquant que l’opération s’est bien passé, un petit reboot histoire de.
4/Je me relog en root
5/ un apt-get update
Quelques mises à jour de security.debian.org
6/ un apt-get upgrade
et là il me dit qu’un package est à MAJ. Je répond Oui

le package en question est kernel-image-2.4.27-2-386 (2.4.27-10sarge1)

Puis j’ai le message suivant :

Un peu inquiet, je regarde ma version en cours du noyau dans une autre console :

Et je me dis : Tiens bizarre quand même, une MAJ d’une meme version de noyau :question:

Bref, le truc qui m’inquiete vraiment est le re-built dans le message.

J’ai protégé la touche entrée du clavier par une cage adaptée, et fermée par un gros cadenas en attendant vos lumières … :slightly_smiling:

#2

La cage a sauté et le cadenas avec.

Après avoir validé, j’ai le message :

Voilà, donc faut t’il faire quelque chose avant de rebooter ou d’éteindre cette vieille bonne machine ?

Bon, c’est peut-être parce qu’il est tard :open_mouth: J’en vois déjà qui rigolent :blush:

Réponse : Il suffit de redémarrer pour que le calcul des dépendances se fasse.

Reboot …

Login en vue de nouveau …

Bon après cette petite blague, je posterai la suite de mon aventure sur Debian après avoir remis quelques neurones à l’endroit :open_mouth:

#3

Newbizz que je suis et la compilation d’un noyau venant du site officiel kernel.org sur une Debian sarge 3.1r0a toute fraiche.

Vu que j’aime bien me prendre la tete, la compilation d’un noyau se fera à partir du site kernel.org ici : kernel.org/pub/linux/kernel/v2.6/

J’ai choisi le dernier à ce jour, celui là : kernel.org/pub/linux/kernel/ … .16.tar.gz

mais avant ca, tout doit être à jour (voir posts sur ces forums):

apt-get update
apt-get upgrade
apt-get install debconf-utils dpkg-dev debhelper (inutile si c'est déjà installer)
apt-get install build-essential kernel-package (inutile si c'est déjà installer)
apt-get install libncurses5-dev (pour le make menuconfig)

et pour ne pas être embeté si la commande tar xjvf ne fonctionne pas, c’est surement à cause de l’absence de bzip2.
Remède : apt-get install bzip2

on continue en root (oui oui on fait simple) :
le répertoire /usr/src doit etre vide puisque vous êtes comme moi avec une debian sarge toute fraiche.

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.tar.gz
tar xjvf linux-2.6.16.tar.gz
ln -s linux-2.6.16 linux-2.6
rm linux-2.6.16.tar.gz
cd linux-2.6
make menuconfig

… Faites comme moi, renseignez vous sur le matériel de votre machine, et visiter la configuration noyau (Y’en a du peuple ! :stuck_out_tongue: )

…la suite bientot …

#4

Sinon, la raison précise de la gueulante lors de l’install de la nouvelle version de ton noyau, c’est qu’il s’apprète à installer une nouvelle version des modules de ton nouveau noyau. Alors, même si ton noyau qui tourne risque d’accepter que tu en inseres un ( ils ont bien le même numero de version que ton noyau qui tourne), ils n’ont pas été fait pour lui, donc, si jamais le noyau a besoin de monter un nouveau module (par exemple si tu branches un peripherique USB à ce moment la), celà risque de faire “planter ton noyau”, et rebooter sans passer par la case extinction.
D’ou le conseil, lors de l’installation d’un noyau qui est le même que celui que tu utilises, de redemarrer vite fait, pour te retrouver homogène entre le module et le noyau.

#5

[quote=“zadmalck”]Vu que j’aime bien me prendre la tete, la compilation d’un noyau se fera à partir du site kernel.org ici : kernel.org/pub/linux/kernel/v2.6/

J’ai choisi le dernier à ce jour, celui là : kernel.org/pub/linux/kernel/ … .16.tar.gz
(…)
[/quote]Il est préférable de prendre directement les noyaux fournis par debian. voir les posts.
forum.debian-fr.org/viewtopic.php?t=1728
forum.debian-fr.org/viewtopic.php?t=1806

[quote=“MattOTop”][quote=“fsoumil”][quote=“MattOTop”]non: les sources de kernel.org sont à éviter, car elles ne sont pas préparées pour debian. Il faut les charger avec apt-get.
[/quote]
En quoi ces sources posent problèmes ? C’est toujours celles-là que j’utilisent et je n’ai jamais eu de problème…[/quote]
comme il est dit dans “Debian Linux Kernel HandBook” ( kernel-handbook.alioth.debian.org/ch-source.html ), la fabrication des sources debian noyaux sont patchées en plusieurs étapes:
1/prune-non-free, qui supprimme les parties sous license douteuse et les mets dans des paquetages à part (ca, c’est un peu precautionneux, et ca peut etre génant, mais bon),
2/installation de patchs variés spécifique debian, qui comblent des failles, OU FOURNISSENT DES FONCTIONNALITES SPECIFIQUES ESSENTIELLES POUR DEBIAN.
En fait, c’est cette dernière étape qui rend spécifique le noyau debian. Il y a des patchs “de sécurité” dont on peu se passer, mais il y a parfois des patchs essentiels pour la logique debian, comme le patch cramfs, qui est désormais intègré au noyaux kernel.org, mais qui a longtemps été nécessaire au bon fonctionnement des outils d’initrd debian.
Ca n’empêche pas de trouver des solutions “à la main” qui permettent de compiler des noyaux avec les sources kernel.org, mais autant rester en sources debian, que les equipes debian-kernel ne bossent pas pour rien… :laughing:[/quote]PS: j’en ai chier pour le retrouvé ce post :smiley:

#6

Salut vous deux. Respect, pour les infos et le partage de connaissance. Ici, je trouve toutes les infos qui me manque. Encore merci à tous pour le taf que vous faites.

En fait, le noyau linux que je vais préparer va venir sur une clé USB. J’y mettrai ensuite busybox (busybox.net), pour avoir un système trés trés petit. Après je verrai…

Mais pour l’instant, c’est ce que j’aimerai faire. Le linux dans une clé USB. Mon portable qui est un hp pavillon ze4111s peut justement booter sans problème sur une clé USB, une grosse, de 1 Go. J’ai vu qu’il exitait des grosses capa (8 Go) sur usb. Avec 8Go, on peut en faire des choses … :wink:
Mon dada est de me faire un petit système de développement (gcc, uclibc, etc) sur USB.

Voilà, je sais bien qu’il y a plein de distrib qui se mette sur clé USB. Mais c’est plus enrichissant de le faire soi-même.

Alors, comme je suis un gros newbizz sur Debian (j’ai commencé hier), je laisserai un petit topo de mon aventure sur ce topic.

Debian, c’est vraiment la distrib pour bidouiller, pour développer. Ya pas photo !

:laughing:

#7

Au début de l’installation de cette debian sarge 3.1r0a, j’ai choisi le partitionnement automatique multi utilisateur.

Tout le disque de 10 Go était donc occupé.

Il me fallait pour continuer ma petite expérience une partition de libre primaire pour pouvoir créer mon futur micro système linux. C’est à dire faire une partition dédiée sur le système de développement.

J’ai choisi de maigrir la /home (3Go sur /dev/hda9).
Dans le home, un seul répertoire : zadmalck
Evidemment, puisque je suis tout seul :laughing:
1 Go pour la home me parait largement suffisant.
C’était donc parti :

tar cvzf zad.home.archive.tar.gz /home/zadmalck/
umount /dev/hda9

un coup de cfdisk (trés pratique), et me voilà avec une nouvelle partition logique (effacer et recréée) /dev/hda9 de 1Go et une nouvelle partition primaire de 888 Mo (/dev/hda3) dédiée pour le futur système.
Il me reste donc environ 1,2Go d’espace libre, pour d’eventuelles autres besoins.

mke2fs -j /dev/hda9
mount /dev/hda9 /home
cd /home
tar xvzf /root/zad.home.archive.tar.gz

on vérifie que tout est correct… et petit reboot histoire de avec un account sous l’utilisateur zadmalck. Mais bon, je suis sur que ce n’est pas la peine… mais je préfère …

REMARQUE : Ne tarez surtout pas le home entier. dans le home vous avez un fichier se nommant lost+found. Quand vous détarerez ensuite vous ecraserez ce fichier créé par votre mke2fs. Et votre partition ne pourra se monter correctement.
En effet la doc dit ceci : Le répertoire lost+found est utilisé par le pilote du système de fichier pour stocker les portions de fichiers récupérées en cas de problème grave sur la partition.
Utilisé par le système de fichier ? Donc pas toucher ! :blush:

Création et montage de la partition primaire dédié (/dev/hda3) dans /mnt/nuxusb :

mkdir /mnt/nuxusb
mke2fs -j /dev/hda3
tune2fs -i 0 /dev/hda3
tune2fs -c 0 /dev/hda3
mount /dev/hda3 /mnt/nuxusb

Le système de fichier ext2 est systèmatiquement vérifié à intervalle régulier, nous sommes en ext3, donc pas besoin. Donc inhibition des vérifs par tune2fs

Pour me simplifier un peu la manip pour le montage, je la rajoute dans /etc/fstab :

/dev/hda3      /mnt/nuxusb     ext3    noauto          0       0

Il me suffira juste de faire un :

pour monter la partoche à la demande.

A ce stade, j’ai le dernier noyau pret à etre compilé sur le système de développement (cette fabuleuse Sarge), et une partition dédié primaire /dev/hda3 monté dans /mnt/nuxusb qui recevra le futur micro système linux tenant sur une USB d’au moins 1Go.

#8

Il faut maintenant préparer le futur système.
On va creer les répertoires nécessaires et suffisants en root :

mount /mnt/nuxusb (si c pas déja fait)
cd /mnt/nuxusb
mkdir bin boot dev etc lib proc root sbin tmp usr var
chmod a+rw tmp
mkdir -p usr/lib/kbd/keytables
mkdir -p var/log/ var/run
mkdir -p etc/sysconfig
mkdir -p extra/bin extra/lib

on va rajouter dans le premier export PATH de /etc/profile le chemin :
/mnt/nuxusb/extra/bin

on se délogue et relogue en root

on créé avec nano le fichier /etc/ld.so.conf en lui mettant /mnt/nuxusb/extra/lib

(/etc/ld.so.conf : liste de répertoires où chercher les bibliothèques, séparés par des blancs, des virgules ou des deux-points. File containing a list of colon, space, tab, newline, or comma spearated)

on sauve, et on valide la modification par un ldconfig

#9

Il faut maintenant creer les noeuds principaux sur le répertoire /mnt/nuxusb/dev

La commande :

 /sbin/MAKEDEV -v -d /mnt/nuxusb/dev generic console

retourne comme erreur :

Une idée ?

#10

[quote]REMARQUE : Ne tarez surtout pas le home entier. dans le home vous avez un fichier se nommant lost+found. Quand vous détarerez ensuite vous ecraserez ce fichier créé par votre mke2fs. Et votre partition ne pourra se monter correctement.
En effet la doc dit ceci : Le répertoire lost+found est utilisé par le pilote du système de fichier pour stocker les portions de fichiers récupérées en cas de problème grave sur la partition.
Utilisé par le système de fichier ? Donc pas toucher [/quote]

Si si on peut même le supprimer. Lors de graves lantades, il se peut que des inodes deviennent orphelins sans repertoire d’attache. Le repertoire lost+found sert à cela et à rien d’autres, e2fsck y met les inodes orphelins du volume. Si le répertoire n’existe plus, il le crée. On peut même y mettre des choses dedans, le mettre en archive, tout cela n’est pas important: Quand il yt a des fichiers dans /lost+found: soit il faut les identifier et les remettre à leur place, soit les supprimer.

#11

[quote=“fran.b”][quote]REMARQUE : Ne tarez surtout pas le home entier. dans le home vous avez un fichier se nommant lost+found. Quand vous détarerez ensuite vous ecraserez ce fichier créé par votre mke2fs. Et votre partition ne pourra se monter correctement.
En effet la doc dit ceci : Le répertoire lost+found est utilisé par le pilote du système de fichier pour stocker les portions de fichiers récupérées en cas de problème grave sur la partition.
Utilisé par le système de fichier ? Donc pas toucher [/quote]

Si si on peut même le supprimer. Lors de graves lantades, il se peut que des inodes deviennent orphelins sans repertoire d’attache. Le repertoire lost+found sert à cela et à rien d’autres, e2fsck y met les inodes orphelins du volume. Si le répertoire n’existe plus, il le crée. On peut même y mettre des choses dedans, le mettre en archive, tout cela n’est pas important: Quand il yt a des fichiers dans /lost+found: soit il faut les identifier et les remettre à leur place, soit les supprimer.[/quote]

Salut fran.b
j’ai taré le /home entier. Ensuite démonté. Ensuite effacer et recréé avec cfdisk (conservant toujours le lien /dev/hda3). Ensuite formater avec mk2efs. Remonter. Détarer le home (ecrasant le lost+found). Et patatrac, au prochain reboot, la partition /dev/hda3 corrompue. Donc logiquement, la modification du lost+found ne lui a pas plu au remontage.
Qu’est t’en penses ?

Remarque : Il m’aurait donc suffit une fois la restauration d’effacer ce foutu lost+found :smiling_imp:

Merci de tes lumières