OVH Cloud OVH Cloud

kernel 2.6.0 test9

5 réponses
Avatar
William
je viens de téléchargé le dernier en date je vois ceci :

# ll -a
total 36
drwxrwxr-x 9 1046 1046 4096 Nov 13 22:10 .
drwxrwxrwt 5 root src 4096 Nov 13 21:48 ..
drwxrwxr-x 22 1046 1046 4096 Oct 25 20:42 arch
drwxrwxr-x 13 1046 1046 4096 Oct 25 20:45 Documentation
drwxrwxr-x 43 1046 1046 4096 Oct 25 20:44 drivers
drwxrwxr-x 52 1046 1046 4096 Oct 25 20:45 fs
drwxrwxr-x 33 1046 1046 4096 Nov 13 22:01 include
drwxrwxr-x 32 1046 1046 4096 Oct 25 20:44 net
drwxrwxr-x 6 1046 1046 4096 Nov 13 22:00 scripts

est ce normal ?

--
William.

5 réponses

Avatar
Julien Delange
On Thu, 13 Nov 2003 22:13:11 +0100, William wrote:

est ce normal ?


Non.

[ :/usr/src/linux ] ll -a
total 9380
drwxrwxr-x 20 1046 1046 4096 2003-11-09 02:04 .
drwxrwsr-x 3 root src 4096 2003-10-28 17:57 ..
drwxrwxr-x 22 1046 1046 4096 2003-10-25 20:42 arch
-rw-r--r-- 1 root root 26712 2003-11-06 22:42 .config
-rw-r--r-- 1 root root 4370 2003-11-06 22:42 .config.cmd
-rw-r--r-- 1 root root 26712 2003-10-28 17:46 .config.old
-rw-r--r-- 1 root root 492 2003-10-28 17:46 conf.vars
-rw-r--r-- 1 1046 1046 18691 2003-10-25 20:43 COPYING
-rw-r--r-- 1 1046 1046 84912 2003-10-25 20:44 CREDITS
drwxrwxr-x 2 1046 1046 4096 2003-10-28 17:58 crypto
drwxr-xr-x 2 root root 4096 2003-10-28 17:57 debian
drwxrwxr-x 41 1046 1046 4096 2003-10-25 20:45 Documentation
drwxrwxr-x 43 1046 1046 4096 2003-10-28 17:58 drivers
drwxrwxr-x 52 1046 1046 4096 2003-10-28 17:58 fs
drwxrwxr-x 34 1046 1046 4096 2003-10-28 17:46 include
drwxrwxr-x 2 1046 1046 4096 2003-10-28 17:58 init
drwxrwxr-x 2 1046 1046 4096 2003-10-28 17:58 ipc
drwxrwxr-x 3 1046 1046 4096 2003-10-28 17:58 kernel
drwxrwxr-x 4 1046 1046 4096 2003-10-28 17:58 lib
-rw-r--r-- 1 1046 1046 50600 2003-10-25 20:43 MAINTAINERS
-rw-r--r-- 1 1046 1046 32208 2003-10-28 17:46 Makefile
drwxrwxr-x 2 1046 1046 4096 2003-10-28 17:58 mm
-rw-r--r-- 1 root root 107 2003-11-01 11:57 .__modpost.cmd
drwxrwxr-x 32 1046 1046 4096 2003-10-28 17:58 net
-rw-r--r-- 1 1046 1046 14489 2003-10-25 20:44 README
-rw-r--r-- 1 1046 1046 2815 2003-10-25 20:43 REPORTING-BUGS
drwxrwxr-x 6 1046 1046 4096 2003-11-06 22:41 scripts
drwxrwxr-x 3 1046 1046 4096 2003-10-28 17:58 security
drwxrwxr-x 15 1046 1046 4096 2003-10-28 17:58 sound
-rw-r--r-- 1 root root 5 2003-10-28 17:46 stamp-configure
-rw-r--r-- 1 root root 5 2003-10-28 17:46 stamp-debian
-rw-r--r-- 1 root root 5 2003-10-28 17:58 stamp-image
-rw-r--r-- 1 root root 5 2003-10-28 17:46 stamp-kernel-configu re
-rw-r--r-- 1 root root 164204 2003-10-28 17:52 .tmp_kallsyms1.o
-rw-r--r-- 1 root root 479313 2003-10-28 17:52 .tmp_kallsyms1.S
-rw-r--r-- 1 root root 164204 2003-10-28 17:52 .tmp_kallsyms2.o
-rw-r--r-- 1 root root 479313 2003-10-28 17:52 .tmp_kallsyms2.S
drwxr-xr-x 2 root root 4096 2003-11-01 11:57 .tmp_versions
-rwxr-xr-x 1 root root 3855968 2003-10-28 17:52 .tmp_vmlinux1
-rwxr-xr-x 1 root root 4019941 2003-10-28 17:52 .tmp_vmlinux2
drwxrwxr-x 2 1046 1046 4096 2003-10-28 17:58 usr
-rw-r--r-- 1 root root 2 2003-10-28 17:52 .version
[ :/usr/src/linux ]



je pense que ça parle de lui-même ;-)

Avatar
William
On Fri, 14 Nov 2003 00:38:45 +0100, Julien Delange wrote:

est ce normal ?
Non.



merci :)

je viens de redécompacter le bousin sans le mettre en tache de fond :

# tar xfj linux-2.6.0-test9.tar.bz2

bzip2: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
bzip2: Inappropriate ioctl for device
Input file = (stdin), output file = (stdout)

It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.

tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now


--
William.


Avatar
Bertrand Masius
Bonjour,


je viens de téléchargé le dernier en date je vois ceci :

# ll -a
total 36
drwxrwxr-x 9 1046 1046 4096 Nov 13 22:10 .
drwxrwxrwt 5 root src 4096 Nov 13 21:48 ..
drwxrwxr-x 22 1046 1046 4096 Oct 25 20:42 arch
drwxrwxr-x 13 1046 1046 4096 Oct 25 20:45 Documentation
drwxrwxr-x 43 1046 1046 4096 Oct 25 20:44 drivers
drwxrwxr-x 52 1046 1046 4096 Oct 25 20:45 fs
drwxrwxr-x 33 1046 1046 4096 Nov 13 22:01 include
drwxrwxr-x 32 1046 1046 4096 Oct 25 20:44 net
drwxrwxr-x 6 1046 1046 4096 Nov 13 22:00 scripts

est ce normal ?


Oui, parce que quand tu déballes l'archive des sources du noyau, tous
les fichiers appartiennent à l'utilisateur et au groupe qui a emballé
l'archive, cad UID=GID46 dans ton cas. C'est toujours comme ça.

un petit chown -R root:root /usr/src/repertoires_des_sources_kernel
devrait régler ça.
--
"Ce que l'on conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément."

(Nicolas Boileau, l'Art poétique)

Avatar
Jean-Francois Billaud
scripsit William :

je viens de redécompacter le bousin sans le mettre en tache de fond :

# tar xfj linux-2.6.0-test9.tar.bz2
[...]
It is possible that the compressed file(s) have become corrupted.


Pour vérifier :

1) ls -l

[...] 33226512 oct 25 19:14 linux-2.6.0-test9.tar.bz2

2) gpg (voir http://www.kernel.org/signature.html)

$ gpg --verify linux-2.6.0-test9.tar.bz2.sign linux-2.6.0-test9.tar.bz2
gpg: Signature faite sam 25 oct 2003 21:23:36 CEST avec une clé DSA ID 517D0F0E
gpg: Bonne signature de "Linux Kernel Archives Verification Key "
gpg: ATTENTION: Cette clé n'est pas certifiée avec une signature de confiance !
gpg: Rien ne dit que la signature appartient à son propriétaire.
Empreinte de clé principale: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E


JFB

--
All syllogisms have three parts, therefore this is not a syllogism.

Avatar
William
On Fri, 14 Nov 2003 18:30:25 +0100, Bertrand Masius wrote:

Oui, parce que quand tu déballes l'archive des sources du noyau, tous les
fichiers appartiennent à l'utilisateur et au groupe qui a emballé l'archive,
cad UID=GID46 dans ton cas. C'est toujours comme ça.


si c'est le cas, je te conseille de changer vivement de version de tar
parce que ta version de tar est buggée et fait n'importe quoi.

En effet, il suffit de compiler un programme malicieux qui ferait un execute en
gros un "rm -fr /", il lui suffit de le mettre le setuid et de le faire n coup
de tar puis de détarré sur la mchine à effacer.

un petit chown -R root:root /usr/src/repertoires_des_sources_kernel devrait
régler ça.


c'est pas trop ça qui pose problème.

--
William.