Le 2.6.8.1 n'est pas encore arrivé sur kernel.org, mais ne va pas tarder.
Mise à jour : Colin rajoute « attention, Linux 2.6.8 a un gros problème de fuite mémoire lors de la gravure de CD audios. Les utilisateurs de graveurs devraient attendre un 2.6.8.2. Alternativement, le dernier noyau exempt de ces problèmes est le 2.6.8-rc2. La liste des changements, comme souvent, est impressionnante. Elle comprend, entre autres, deux nouvelles plateformes ppc32 (e500 et 85xx), une mise à jour massive de l'architecture MIPS, quelques tonnes de réparations trouvées par sparse (Static Parser, un outil développé par Linus pour trouver les déréférencements de pointeurs user-space dans le noyau); les pilotes ne sont pas en reste, avec l'arrivée du support du chipset SATA d'nVidia, des mises à jour (bugfixes, optimisations) de différents framebuffers (radeonfb, rivafb, ...), des réparations du sous-système USB (Oopses, nettoyages de code, mises à jour de différents pilotes comme ceux des lecteurs de cartes, cdc-acm (modem GPRS), usblp (imprimantes), contrôleurs (ehci), ...).
Le 2.6.8.1 a quant à lui un Changelog beaucoup plus réduit: "[PATCH] Fix NFS client screw-up in fcntl f_op removal: Fix stupid thinkos in the fcntl f_op removal code." et répare un bug assez gênant trouvé juste après la sortie du 2.6.8.
Le patch 2.6.7-2.6.8 fait 4Mo, les changements continuent donc à arriver à un rythme soutenu. Cependant, la méthode de travail trouvée, avec le couple Linus Torvalds / Andrew Morton, fait ses preuves. Linux 2.6 est la branche la plus stable comparativement aux autres au même âge, tellement qu'un nouveau modèle de développement est envisagé, plus de changements dans la branche stable, avec les essais dans la branche -mm (celle d'Andrew Morton), et le 2.7.x n'est pas encore prévu.
Aller plus loin
- Changelog (5 clics)
- Miroirs kernel.org pour le téléchargement (4 clics)
- Nouveau modèle de développement pour Linux (4 clics)
- DLFP : Faille de sécurité critique dans les noyaux 2.4 et 2.6 (11 clics)
- DLFP : Nouveau modèle de développement pour Linux (11 clics)
- Annonce LKML du 2.6.8.1 (4 clics)
# commentaires des journaux
Posté par Krunch (site web personnel) . Évalué à 2.
http://linuxfr.org/~Acetik/14946.html(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: commentaires des journaux
Posté par Stephen Amar . Évalué à -1.
[^] # Re: commentaires des journaux
Posté par TazForEver . Évalué à -1.
# Le bug NFS
Posté par Serge Rossi (site web personnel) . Évalué à 10.
La modif ne tient qu'a un seul caractère :
http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.1/2049.html(...)
--- 1.40/fs/nfs/file.c 2004-08-09 11:58:00 -07:00
+++ edited/fs/nfs/file.c 2004-08-14 03:35:11 -07:00
@@ -89,7 +89,7 @@
int res;
res = nfs_check_flags(filp->f_flags);
- if (!res)
+ if (res)
return res;
lock_kernel();
C'est fou ce qu'un petit ! mal placé peut faire comme boxon :-)
[^] # Re: Le bug NFS
Posté par Raoul Volfoni (site web personnel) . Évalué à 9.
Quand vous étiez petit? ;-) Comment faites-vous pour lire un changelog aussi gros, et décider d'installer un nouveau kernel en si peu de temps? Une telle réactivité m'épate autant qu'elle me conforte une fois de plus dans l'idée qu'il est rarement nécessaire de se jeter comme un mort de faim sur la toute dernière version d'un kernel.
<Mode papy on> Ca n'est en rien le propre du kernel ou même de l'OS, il y a 20 ans déjà avec VMS sur PDP11 on attendait plusieurs semaines avant de valider un patch de l'OS. Et combien de fois cette règle nous a donné raison. </Mode papillon>
[^] # Re: Le bug NFS
Posté par Serge Rossi (site web personnel) . Évalué à 9.
(et moi aussi j'ai été admin VMS depuis la V4.7 ;-)
[^] # Re: Le bug NFS
Posté par Thierry . Évalué à 2.
Ah, ça a existé, ça ? J'ai toujours cru que VMS (Virtual Memory System) avait commencé sa carrière sur les VAX (Virtual Address eXtension)...
tth.
[^] # Re: Le bug NFS
Posté par Serge Rossi (site web personnel) . Évalué à 4.
l'OS des Vax, c'est VMS (et Ultrix, NetBSD, voire même Linux, entre autres)
Les OS du PDP 11 sont RSX-11M (OS Tems réel), RSTS-11(Time Sharing, multi utilisateurs), RT-11(OS light, single user, temps réel), Ultrix-11 et éventuellement TSX/11 pour créer plusieurs machines virutelles RT-11.
Y'a aussi un certain Tompson et un certain Ritchie qui on écrit un petit truc sur cette bécanne :-)
[^] # Re: Le bug NFS
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
Parce qu'il y a eu des -rc qui fonctionnait trés bien avant
> Une telle réactivité m'épate autant qu'elle me conforte une fois de plus dans l'idée qu'il est rarement nécessaire de se jeter comme un mort de faim sur la toute dernière version d'un kernel
Et si tout le monde attends 3 semaines avant de tester un nouveau, ben c'est au bout de 3 semaines que le bug est découvert et ça fait un belle jambe a tout le monde.
Au lieu de s'interroger sur pourquoi quelqu'un teste un noyau dés qu'il sort en se demandant s'il est pas mort de faim sur un ton légèrement pérojatif, il vaudrait mieux lui dire merci d'être aventurier et de tester le noyau afin que d'autres puisse l'utiliser sans risque et sans avoir à piquer une petite suée.
[^] # Re: Le bug NFS
Posté par Richard Van Den Boom . Évalué à 4.
Exemple pour moi : l'accès au système de fichier ISO9660 a été modifié pour que l'option "cruft" ne soit pas utilisée par défaut pour des systèmes de fichiers de plus de 850Mo. Du coup, on peut lire correctement des DVD gravés sous Mac (je suppose que sous Mac, on peut graver en UDF mais mes interlocuteurs m'envoient régulièrement des DVD gravés en ISO).
Voila, c'est pas grand chose, mais ça aide.
De toutes façons, je garde toujours au moins un autre kernel qui marche. Si le nouveau est instable, je peux donc toujours revenir en arrière.
Richard
[^] # Re: Le bug NFS
Posté par Ramso . Évalué à -2.
Houlà ! un troll sur la syntaxe du (à la) C qui débute ?
[^] # Re: Le bug NFS
Posté par Anonyme . Évalué à 1.
[^] # Re: Le bug NFS
Posté par Ramón Perez (site web personnel) . Évalué à 2.
Rien de tel pour tout embrouiller, et pour faire chier quand tu t'apperçois finalement que ton if tu veux le décaler 10 lignes plus bas.
[^] # Re: Le bug NFS
Posté par Anonyme . Évalué à 1.
----->[ ]
[^] # Re: Le bug NFS
Posté par pasBill pasGates . Évalué à 5.
[^] # Re: Le bug NFS
Posté par Simon Mathieu (site web personnel) . Évalué à 1.
Si c'est possible répondre par message privée de templeet car je passe rarement sur DLFP et encore moin deux fois sur le même thread.
Merci bien.
sime le curieux
[^] # Re: Le bug NFS
Posté par Colin Leroy (site web personnel) . Évalué à 2.
if ((res=nfs_check_flags(filp->f_flags) != 0)
...
ça fait une notation un peu lourde, du coup.
# et toujours pas de support natif de multideskOS...
Posté par toctoc . Évalué à -7.
ok... je sors par la porte des étoiles.. --------->[**]
[^] # Re: et toujours pas de support natif de multideskOS...
Posté par Dalton joe . Évalué à -5.
# sparse
Posté par mickabouille . Évalué à 7.
> développé par Linus pour trouver les déréférencements de pointeurs user-space
> dans le noyau)
Un peu limitatif. Je crois que sparse est destiné à être un peu plus que ça. Il devrait être un outil du genre du stanford checker, et repérer toutes sortes d'erreurs.
Mais forcément, il faut lui dire quel genre d"erreur on cherche, et comment les trouver. Alors peut être que pour le moment, il est un peu limité.
Par exemple, je crois que les erreurs o!=NULL dont il avait été question ici avaient été cherchées via sparse.
[^] # Re: sparse
Posté par Bertrand Jacquin (site web personnel) . Évalué à -1.
ps : sinon, je trouve regrettable que l'on puisse trouvé de la pub pour des téléphones portable sur la LKML : http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.1/0003.html(...)
ca m'agace, encore plus quand ce sont des français
[^] # Re: sparse
Posté par mickabouille . Évalué à 5.
Ici, sur lwn : http://lwn.net/Articles/87538/(...) avec effectivement des commentaires sur les utilisations incorrectes de pointeurs en usermode. Mais il est surtout question d'interfaces (? backends?) pour le système. Et plus bas, il y a d'autres exemples (switch vides, constantes...).
Et ici, sur les NULL :
http://lwn.net/Articles/93574/(...)
[^] # Re: sparse
Posté par Bertrand Jacquin (site web personnel) . Évalué à 1.
je jete un coup d'oeil a tes liens :)
merci
[^] # Re: sparse
Posté par Fanf (site web personnel) . Évalué à 3.
Le but de l'analyse statique est de repérer tout un tas d'erreurs de programmation en dehors de l'exécution, principalement : des déférencement de pointeur (NULL en particulier), du code mort (càd qui ne devrait jamais être exécuté, mais qui est quand même là), de l'analyse sur les boucles (valeurs utilisées...), etc...
Bref, l'analyse statique est un outils très puissant, mais malheureusement complexe est qui a tendance à manger beaucoup de temps proc. Certains compilos l'utilise en particulier pour enlever le code mort ou remplacer des variables constantes par leur valeur, mais guère plus. Et on utilise alors un outils séparé si l'on veut aller plus loin.
Il doit y avoir pleins d'autres info sur le net (regarder les cours d'ulm je crois, ou sinon chercher treillis, correspondance de Gallois, ce genre de choses)
[^] # Re: sparse
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 3.
Disons Lundi à 10h du matin. tous ensemble...
[^] # Re: sparse
Posté par Bertrand Jacquin (site web personnel) . Évalué à 2.
[^] # Re: sparse
Posté par _PinG _ . Évalué à 2.
A mon avis ils vont péter un cable.
[^] # Re: sparse
Posté par Christophe Merlet (site web personnel) . Évalué à 4.
# Enfin une gestion correcte des touchpads synaptics !
Posté par gerard delafond . Évalué à 6.
Testé sur 2 portables complètement différents en marque, âge, etc.
Il s'agit des portables équipés d'une souris synaptics (voir cat /proc/bus/input/devices), qui perd la synchro de temps en temps (voir dans /var/log/messages s'il n'y a pas des messages du genre synaptics lost syn --- resync)
Comme quoi, ça vaut le coup de se précipiter sur un kernel tout neuf, puisque ça fait au moins 3 ans que ce bug traînait et pourrissait la vie des utilisateurs de portables.
[^] # Re: Enfin une gestion correcte des touchpads synaptics !
Posté par tgl . Évalué à 2.
[^] # Re: Enfin une gestion correcte des touchpads synaptics !
Posté par gerard delafond . Évalué à 3.
Les symptômes sont un peu différents selon les machines et les versions du noyau/serveur X. Parfois, c'est assez discret. Le juge de paix, dans ce cas, est le fichier /var/log/messages
Je n'ai pas d'expérience avec des IBM.
Il y a eu des échanges récemment à ce sujet sur le noyau, et une modification a été faite dans le noyau 2.6.7, sans résultat pour tout le monde.
Les deux machines défaillantes testées semblent bien fonctionner depuis hier (il y avait parfois plusieurs décrochages de la souris en une minute, d'autres fois un décrochage toutes les quelques minutes).
Beaucoup de gens ne pensaient pas à faire remonter ce bug, hésitant entre une défaillance du matériel, un défaut du serveur X, etc.
En tous cas, c'est un très ancien bug qui semble enterré.
A+
Gérard
[^] # Re: Enfin une gestion correcte des touchpads synaptics !
Posté par Sébastien Laoût . Évalué à 1.
Quand j'avais testé le 2.6, dès que je bougeait la souris (ou le touchpad Synapsis) ben ça avancait de quelques pixels vers le haut (12 pixels ? dans ces eaux là mais la distance était fixe), puis de quelques pixels vers la droite, puis ça cliquait... puis ça recommençait tant que je l'utilisait. Si je relachait la souris était immobile.
C'est ce bug là ?
Bon par contre je vais encore attendre un bail pour passer au 2.6 (avec toutes les m***** que j'ai ma philosophie est devenue "tant que ça marche, touche surtout à RIEN").
Sinon, reste un seul problème avant que je reteste un 2.6 : que le driver du modem Connexant marche. Là j'ai la dernière version beta (illégale ? peut-être) *gratuite*.
À ce propos : ya du neuf ? Des personnes arrivent à l'utiliser sur le 2.6 (je veux dire à 56K réel : pas les 14.4k du shareware) ?
[^] # Re: Enfin une gestion correcte des touchpads synaptics !
Posté par sebmil . Évalué à 1.
J'ai pu observer le problème du Synapsis à plusieurs reprises sur mon portable (un vieux Dell Latitude), et à chaque fois le symptome était le même : curseur qui se "téléporte" en haut à gauche de l'écran, et qui y reste bloqué quelques fractions de secondes (durée variable) avec parfois un clic gauche de la durée du problème.
Ce qui m'a toujours le plus étonné c'est que ce bug se manifeste même si le touchpad n'est pas utilisé, par exemple en utilisant à la place une souris connectée sur le port PS/2.
[^] # Re: Enfin une gestion correcte des touchpads synaptics !
Posté par Pierre Tourbeaux . Évalué à 1.
Personnellement je me suis pas mal acharné sur le problème avec des 2.4, 2.6 et même le 2.6.8.1 me fait toujours pareil dans les logs :
Aug 16 15:59:24 portable kernel: psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched.
Aug 16 15:59:30 portable kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1
J'ai essayé différentes versions de synaptics et toutes font la même chose... A croire que mon portable a un touchpad "spécial" :(
Par contre en effet on dirait que le pointeur saute moins, et c'est pas si mal ! Faudra juste penser à virer les logs encombrants un coup de tps en tps :)
# Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 1.
En le lançant en tant que root, il plante et en le lançant en temps que user avec cdwrap, il sort un message idiot comme quoi il n'arrive pas à "prevent media removal, SCSI sendcmd error" alors que j'utilise ATAPI...
J'ai besoin de mon graveur et j'ai pas le temps de chercher donc retour en 2.6.7-ck6...
Mais si y'en a que ça inspire... :-)
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 2.
http://seclists.org/lists/linux-kernel/2004/Aug/index.html(...)
[^] # Re: Problème cdrecord.prodvd
Posté par wismerhill . Évalué à 2.
[^] # Re: Problème cdrecord.prodvd
Posté par maher b . Évalué à 2.
je repasse au 2.6.7
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 6.
Ca fait bien logntemps que la situation n'est pas claire du tout concernant le gravage sous Linux et ça c'est nettement empiré avec les graveurs de DVD. Y'a un jour ou il faudra que ça pête. C'est peut-être maintenant que ça va arriver...
Quelque part, l'absence d'une appli GPL permettant de tout faire en gravage me gène bien plus que l'absence de driver 3D GPL pour les cartes ATI ou NVidia.
Ces drivers sont closed source mais au moins ils sont suivi par de grosses sociètés qui maintenant y mettent les moyens alors que pour le gravage, ça ne tient qu'a une seule personne : Georg Schilling, qui n'est pas particulièrement coopératif. Il suffit de voir comment ça part en vrille dans LKML, rien que parce qu'il utilise mailx pour poster qui casse systématiquement les threads de discussion ou il participe....
[^] # Re: Problème cdrecord.prodvd
Posté par gallenza . Évalué à -2.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 2.
Retour à la case départ.
[^] # Re: Problème cdrecord.prodvd
Posté par gallenza . Évalué à 1.
Je peux juste dire qu'avec k3b on grave tout sans problème, y compris les dvd, et donc que ça marche déjà facilement....
[^] # Re: Problème cdrecord.prodvd
Posté par x0ra . Évalué à 1.
[^] # Re: Problème cdrecord.prodvd
Posté par oliv . Évalué à 2.
[^] # Re: Problème cdrecord.prodvd
Posté par mickabouille . Évalué à 4.
C'est lui les messages "l'interface atapi, c'est mal" et tout?
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 2.
Bon en fait, y'a moyen de s'arranger avec les versions de cdrecord patchées et les forks genre dvdrtools mais ça part un peu dans toutes les directions.
[^] # Re: Problème cdrecord.prodvd
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Ca doit être ses 20 ans de connaissances de différents OS qui font cela!!
Linus en est à plus de 10, espérons qu'il ne tournera pas ainsi ;-)
Bonne journée.
- Christophe
[^] # Re: Problème cdrecord.prodvd
Posté par Yann KLIS (site web personnel) . Évalué à 5.
http://icculus.org/burn/(...)
[^] # Re: Problème cdrecord.prodvd
Posté par Christophe Lucas (site web personnel) . Évalué à 3.
D'une parce que ce projet _semble_ jeune, de deux parce qu'il faudrait que les distributions changent leurs outils de gravure sous Linux et qu'aujourd'hui un environnement utilisateur dans lequel la gravure de CD-ROM ne fonctionnerait que partiellement serait dommageable.
Maintenant à la vue de l'API, l'écriture de programme de gravure ne semble pas être d'une difficulté insurmontable.
Christophe
[^] # Re: Problème cdrecord.prodvd
Posté par dguihal . Évalué à 4.
Des que ceux-ci commenceront a supporter ce genre de librairies, les distributions inclueront le support, car il devient optionnel est peut etre utilise a cote des cdrecord & co.
[^] # Re: Problème cdrecord.prodvd
Posté par tgl . Évalué à 5.
En même temps, je pense que quand libburn sera suffisament fonctionnelle, les différent frontends (existants ou nouveaux) se feront une joie de coder avec une vraie API plutôt qu'en parsant la sortie de cdrecord. D'autant plus si y'a des bindings qui font leur apparition, ce dont je ne doute pas (y'en a déjà au moins pour Ruby je crois).
[^] # Re: Problème cdrecord.prodvd
Posté par Christophe Lucas (site web personnel) . Évalué à 2.
Et j'espère en effet que cette librairie fera son chemin à la vue de l'humeur de M. cdrecord. Peut-être qu'il a été pousser dans ses retranchements. Mais l'attitude qu'il abore sur le sujet de l'API du sous-système SCSI me fait un peu peur, compte-tenu, qu'il possède une grande connaissance dans le domaine(cdrecord est son bébé) et qu'il serait dommage qu'il arrête de se consacrer à la partie Linux de cdrecord.
Maintenant, je pense que je suis un peu parano.
--
Christophe.
[^] # Re: Problème cdrecord.prodvd
Posté par wismerhill . Évalué à 2.
Uh?
cdrecord est GPL, dvd+rw-tools aussi.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 3.
Mais c'est vrai que maintenant, on peut quasiment tout faire avec dvd+rw-tools (à part les DVD Disk-at-once) donc la situation est moins bloquée qu'avant.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 2.
http://lkml.org/lkml/2004/8/19/18(...)
If no one has noticed yet, thanks to the additional license
restrictions Joerg Schilling has added to cdrecord (due to this
thread), it may be now moved to non-free in Debian in the near future.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 2.
/*
* You are not allowed to modify or remove the call to "linuxcheck()".
* I am sorry that I am forced to do things like this, but defective
* versions of cdrecord cause a lot of work load to me and it seems
* to be impossible to otherwise convince SuSE to cooperate.
* As people contact me and bother me with the related problems,
* it is obvious that SuSE is violating subsection 6 in the preamble of
* the GPL.
*
* The reason for including a test against SuSE's private
* distribution environment is only that SuSE violates the GPL for
* a long time and seems not to be willing to follow the requirements
* imposed by the GPL. If SuSE starts to ship non defective versions
* of cdrecord or informs their customers that they would need to
* compile cdrecord themselves in order to get a working cdrecord,
* they should contact me for a permission to change the related test.
*
* Note that although the SuSE test is effective only for SuSE, the
* intention to have non bastardized versions out is not limited
* to SuSE. It is bad to see that in special in the "Linux" business,
* companies prefer a model with many proprietary differing programs
* instead of cooperating with the program authors.
*/
linuxcheck();
if (flags & F_VERSION)
exit(0);
linuxcheck()
{
#if defined(linux) || defined(__linux) || defined(__linux__)
#ifdef HAVE_UNAME
struct utsname un;
if (uname(&un) >= 0) {
/*
* I really hope that the Linux kernel developers will soon
* fix the most annoying bugs (as promised). Linux-2.6.8
* has still much more reported problems than Linux-2.4.
*/
if ((un.release[0] == '2' && un.release[1] == '.') &&
(un.release[2] == '5' || un.release[2] == '6')) {
errmsgno(EX_BAD,
"Warning: Running on Linux-%s\n", un.release);
errmsgno(EX_BAD,
"There are unsettled issues with Linux-2.5 and newer.\n");
errmsgno(EX_BAD,
"If you have unexpected problems, please try Linux-2.4 or Solaris.\n");
}
}
#endif
if (streql(HOST_VENDOR, "suse")) {
errmsgno(EX_BAD,
"SuSE Linux is known to ship bastardized and defective versions of cdrecord.\n");
errmsgno(EX_BAD,
"SuSE is unwilling to cooperate with the authors.\n");
errmsgno(EX_BAD,
"If you like to have a working version of cdrtools, get the\n");
errmsgno(EX_BAD,
"original source from ftp://ftp.berlios.de/pub/cdrecord/\n(...)");
}
#endif
}
[^] # Re: Problème cdrecord.prodvd
Posté par eltatio . Évalué à 3.
cdrecord -scanbus dev=ATAPI me donne
....
....
0,0,0 0) 'LITE-ON ' 'COMBO LTC-48161H' 'KH0N' Removable CD-ROM
0,1,0 1) '_NEC ' 'DVD_RW ND-2500A ' '1.07' Removable CD-ROM
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
=> cdrecord blank=fast dev=ATAPI:0,1,0 (effacement rapide)
Par contre effectivement, en tant que user, cela se termine avec le même message que celui que tu mentionnes..
NB : depuis le 2.6.7.1, gros changements dans la labellisation de tout ce qui touche aux unités SCSI (cf disques SATA).
[^] # Re: Problème cdrecord.prodvd
Posté par Gilles Crebassa . Évalué à 1.
Cherche sur google, plein de gens l'ont fait. Le plus dur est de trouver des DVD 9Go.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 1.
[^] # Re: Problème cdrecord.prodvd
Posté par Colin Leroy (site web personnel) . Évalué à 4.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 3.
http://lkml.org/lkml/2004/8/16/38(...)
http://lkml.org/lkml/2004/8/15/189(...)
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 3.
http://lkml.org/lkml/2004/8/14/103(...)
http://lkml.org/lkml/2004/8/14/107(...)
http://lkml.org/lkml/2004/8/14/125(...)
http://lkml.org/lkml/2004/8/14/156(...)
[^] # Re: Problème cdrecord.prodvd
Posté par Colin Leroy (site web personnel) . Évalué à 4.
http://lkml.org/lkml/2004/8/14/103(...)
Oui, c'est moi ;)
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 4.
Donc tu aura surement vu la solution (pas encore essayé moi même) :
http://lkml.org/lkml/2004/8/16/104(...)
Due to the newly added command filtering, you now need to run cdrecord as
root. Since cdrecord will drop root privileges before accessing the drive,
setuid root won't help.
This means you will have to run cdrecord *and* k3b as root!
IMHO it is more secure to simply disable filtering, and run the software as non-root.
This patch restores the behaviour of previous kernels, security issues included:
--- linux-2.6.8/drivers/block/scsi_ioctl.c~ 2004-08-16 14:16:57.000000000 +0200
+++ linux-2.6.8/drivers/block/scsi_ioctl.c 2004-08-16 14:36:22.562908552 +0200
@@ -196 +196 @@
- if (verify_command(file, cmd))
+/* if (verify_command(file, cmd))
@@ -198 +198 @@
-
+*/
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 1.
Je vais attendre que ça se décante là...
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 3.
En fait, j'avais mal appliqué le patch (fait à l'éditeur et j'ai oublié de commenter une des 2 lignes vitales).
En fait, le patch fonctionne très bien et résoud le problème d'accès au graveur avec toutes les applis de gravage.
A lire le dernier message d'Alan Cox dans LKML, ce patch n'est qu'une solution temporaire... mais bien utile !
http://lkml.org/lkml/2004/8/16/130(...)
Ca y'est, j'ai tout qui fonctionne en 2.6.8, elle aura été chaude cette mise à jour pour un noyau stable !
[^] # Re: Problème cdrecord.prodvd
Posté par tgl . Évalué à 4.
Tous ces embêtements viennent en fait de l'ajout d'un contrôle sur les commandes scsi, pour éviter que des utilisateurs ayant trop de droits (en gros, les utilisateurs du groupe cdrw sur pas mal de distribs) ne les utilisent pour fusiller le graveur. Bon, je veux bien croire que ce soit une avancée pour des machines en libre services, mais pour nos chez-nous respectifs on s'en fout un peu.
La solution à plus long termes, c'est d'avoir de mieux identifié l'ensemble des commandes sûres mais nécéssaires à une utilisation normale d'un graveur. La dernière fois que j'ai regardé aujourd'hui la lkml, il y en avait déjà une petite dizaine d'identifiées comme manquantes à la liste qui est dans le 2.6.8. Perso, je les ai rajoutées mais ça n'a pas suffit à retrouver un cdrecord pleinement fonctionel, donc j'ai finallement opté pour la solution temporaire qui désactive tout le contrôle. Au moins, ça marche.
[^] # Re: Problème cdrecord.prodvd
Posté par Serge Rossi (site web personnel) . Évalué à 3.
J'espère qu'ils en feront une option de compil (filtrer les commandes SCSI Oui/Non) comme ça, les paranos pouront activer ça si ça leur chante et pas les autres.
[^] # Re: Problème cdrecord.prodvd
Posté par tgl . Évalué à 2.
Un contrôle dans /proc serait encore plus pratique, genre pour les désactiver on ferait :
# echo 0 > /proc/sys/dev/scsi/check_commands
Parceque les options de compil, c'est bien, mais c'est pas la panacée pour les gens qui utilisent le noyau de leur distrib (et là, je sais pas quel choix feraient des packageurs de distrib, mais ils ne pourraient pas faire le bon pour tout le monde).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.