Probleme de droit a la compilation du kernel

Bonjour,

j’ai voulu compiler mon noyaux 2.6.18, je le compile en utilisateur normal, car en root c’ets po bien, je passe la commande

make-kpkg --rootcmd fakeroot --append-to-version "custom" --initrd buildpackage

Mais après pas mal de temps de compile ca merde:

  INSTALL sound/usb/snd-usb-lib.ko
  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map -b /home/futex/Documents/Sources/Kernel/linux-source-2.6.18/debian/linux-image-2.6.18custom -r 2.6.18custom; fi
/bin/sh: /sbin/depmod: Permission non accordée
make[2]: *** [_modinst_post] Erreur 126
make[2]: quittant le répertoire « /home/futex/Documents/Sources/Kernel/linux-source-2.6.18 »
make[1]: *** [install/linux-image-2.6.18custom] Erreur 2
make[1]: quittant le répertoire « /home/futex/Documents/Sources/Kernel/linux-source-2.6.18 »
make: *** [stamp-buildpackage] Erreur 2

Problème de droit pour lancé depmod alors que j’utilise fakeroot :open_mouth:.

Ce qui fait que le package linux-image n’est pas généré :frowning:.

Quelqu’un a une idée pour depmod ne semble pas être lancé par fakeroot?

Merci

La procédure de compilation donnée dans les tuto nous indique d’être en root. Donc si on est pressé et on ne veut pas trop réfléchir on applique à la lettre le tuto. Mais si tu trouves le moyen de créer un kernel sans être root ça peut toujours inéresser la communauté.

En quoi est-ce pas bien de compiler en root ?

C’est juste une question de parano ou non ?

fakeroot
:laughing:

scorpio810.tuxfamily.org/kernel%202.6.21.html

[quote=“ymer”]En quoi est-ce pas bien de compiler en root ?

C’est juste une question de parano ou non ?[/quote]

[quote]
Linus Torvalds conseille de ne pas compiler le noyau dans le répertoire /usr/src/. Voici un extrait du mail qui explique pourquoi il ne faut pas compiler son noyau dans ce répertoire :

I would suggest that people who compile new kernels should:

  • NOT do so in /usr/src. Leave whatever kernel (probably only the
    header files) that the distribution came with there, but don’t touch
    it.

  • compile the kernel in their own home directory, as their very own
    selves. No need to be root to compile the kernel. You need to be root
    to install the kernel, but that’s different.

  • not have a single symbolic link in sight (except the one that the
    kernel build itself sets up, namely the “linux/include/asm” symlink
    that is only used for the internal kernel compile itself).

And yes, this is what I do. My /usr/src/linux still has the old 2.2.13
header files, even though I haven’t run a 2.2.13 kernel in a loong
time. But those headers were what glibc was compiled against, so those
headers are what matches the library object files.

And this is actually what has been the suggested environment for at
least the last five years. I don’t know why the symlink business keeps
on living on, like a bad zombie. Pretty much every distribution still
has that broken symlink, and people still remember that the linux
sources should go into “/usr/src/linux” even though that hasn’t been
true in a loong time.

Pour les anglophobes, voici une traduction de cet extrait :

Je suggère aux personnes qui compilent un nouveau noyau de :

  • ne pas le faire dans /usr/src. Quelque soit le noyau provenant de votre
    distribution (probablement les fichiers d’entêtes uniquement),
    mais en tout cas n’y touchez pas.

- compiler le noyau dans leur propre répertoire personnel. Il est inutile
d’être root pour compiler le noyau
. Vous avez besoin d’être root
pour installer le noyau, mais c’est différent
.

  • ne pas avoir l’intention de faire un lien symbolique (excepté celui que le
    noyau créé lui-même, à savoir le lien “linux/include/asm” qui est utilisé
    uniquement pour la compilation interne du noyau).

Et bien sûr, c’est ce que je fais. Mon /usr/src/linux a encore les
fichiers d’entêtes de mon ancien 2.2.13, malgré que je n’ai pas utiliser
le noyau 2.2.13 depuis très longtemps. Mais ces entêtes étaient ceux
qui avait compilé par glibc, donc ces entêtes sont ceux qui correspondent
aux fichiers de la bibliothèque objet.

Et c’est en fait ce qui a été l’environnement suggéré depuis au moins cinq
ans. Je ne sais pas pourquoi l’habitude de faire des liens symboliques
est restée ainsi. De nombreuses distributions ont ce lien symbolique cassé,
et les gens se souviennent que les sources du noyau devraient être dans
"/usr/src/linux" même si ce n’est pas vrai depuis très longtemps.[/quote]

[quote=“scorpio81”]fakeroot
:laughing:

scorpio810.tuxfamily.org/kernel%202.6.21.html[/quote]

j’utilise fakeroot, c’est bien la le soucis …

make-kpkg --rootcmd fakeroot --append-to-version "custom" --initrd buildpackage 

Je compilais sans fakeroot, je saisissais pas l’utilité …
Si tu déplaces les sources dans ton repertoire home comme conseillé, le soucis ne devrait plus se poser, non ?

Je crois que je me contentais d’un simple

(mais j’étais en root, et dans /usr/src/linux :stuck_out_tongue:)

salut,

pourquoi --rootcmd ?

ce ne serait pas :

vu ici

Que je fasse

fakeroot make-kpkg --append-to-version "custom" --initrd kernel_image kernel_headers

ou

make-kpkg --rootcmd fakeroot --append-to-version "custom" --initrd kernel_image kernel_headers

J’ai le même message d’erreur:

 INSTALL sound/pcmcia/vx/snd-vxpocket.ko
  INSTALL sound/soundcore.ko
  INSTALL sound/synth/emux/snd-emux-synth.ko
  INSTALL sound/synth/snd-util-mem.ko
  INSTALL sound/usb/snd-usb-audio.ko
  INSTALL sound/usb/snd-usb-lib.ko
  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map -b /home/futex/Documents/Sources/Kernel/linux-source-2.6.18/debian/linux-image-2.6.18custom -r 2.6.18custom; fi
/bin/sh: /sbin/depmod: Permission non accordée
make[1]: *** [_modinst_post] Erreur 126
make[1]: quittant le répertoire « /home/futex/Documents/Sources/Kernel/linux-source-2.6.18 »
make: *** [install/linux-image-2.6.18custom] Erreur 2
  

Et la compilation foire. :frowning:

Comme je l’ai dit je connais mal le comportement de fakeroot.

Cela dit, d’après delafond.org/traducmanfr/deb … oot.1.html

Tu peux voir ça. Même si je ne suis pas sûr qu’il puisse y avoir un rapport avec ton erreur d’accès à /sbin/depmod.

Ou tu peux essayer la commande sans fakeroot, en étant réellement root … ça n’est pas un drame.

Quel sont les droits sur vos machines sur le fichier /sbin/depmod?
moi c’est 750.

Je ne vois vraiment pas de solution à par ca. :frowning:

C’est bizarre sous etch /sbin/depmod est en 750 et sous ma sid en 755. Si on le met en 755 ca passe. Bon je sais pas si c’est normal d’avoir le droit d’executions sur un binaire dans /sbin …

je compile mon kernel sans être root avec la commande:

make-kpkg --rootcmd fakeroot --append-to-version "custom" --initrd buildpackage 

Est ce que quelqu’un qui est sous etch peut me dire les droits que /sbin/depmod a ?

/$ ls -al | grep sbin drwxr-xr-x 2 root root 4096 2007-06-13 18:29 sbin

/sbin$ ls -al /sbin/depmod -rwxr-xr-x 1 root root 37556 2007-05-20 21:24 /sbin/depmod

Merci :slightly_smiling:. C’est bizarre que j’avais pas les bons droits, peut etre du à bastille. ou du faite que je suis sous etch depuis qu’elle est en testing.