Re: mdadm "not large enough to join array " et fdisk incohérent
Bonjour à tous, Le 28/10/2010 16:29, Jean-Yves F. Barbier a écrit : On Thu, 28 Oct 2010 15:57:09 +0200, Yves Rutschle wrote: On Thu, Oct 28, 2010 at 03:05:00PM +0200, Jean-Yves F. Barbier wrote: rien de personnel, c'est juste une constatation de longue date. Ok, j'imagine que tu vas donc également ignorer ma demande de sources sur ton affirmation que chiffrer 2 fois pose problème: j'en ai parlé à mon cryptographe favori, dont la première remarque a été de dire que 3DES, c'était DES fait 3 fois, et c'était plus robuste que DES. Couplé avec le fait Par contre 3DES ne chiffre pas 3 fois le même bloc mais applique 3 fois l'algorithme à 3 blocs consécutifs. Il ne s'agit pas d'une surcouche de chiffrement. il a juste oublié de te parler des attaques MITM qui font sauter un niveau, laissant 2x56 bits d'encryption et non 3x56. que je n'ai jamais rien lu de tel, je vais considérer pour le moment que ton affirmation est gratuite et fausse. tu considères et tu penses ce que tu peux, je m'en tamponne: je ne me suis jamais déterminé par rapport aux autres. Bonne journée à vous, Mathieu -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4cc98c1c.7060...@gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
On Thu, 28 Oct 2010 15:57:09 +0200, Yves Rutschle wrote: > On Thu, Oct 28, 2010 at 03:05:00PM +0200, Jean-Yves F. Barbier wrote: > > rien de personnel, c'est juste une constatation de longue date. > > Ok, j'imagine que tu vas donc également ignorer ma demande > de sources sur ton affirmation que chiffrer 2 fois pose > problème: j'en ai parlé à mon cryptographe favori, dont la > première remarque a été de dire que 3DES, c'était DES fait 3 > fois, et c'était plus robuste que DES. Couplé avec le fait il a juste oublié de te parler des attaques MITM qui font sauter un niveau, laissant 2x56 bits d'encryption et non 3x56. > que je n'ai jamais rien lu de tel, je vais considérer pour > le moment que ton affirmation est gratuite et fausse. tu considères et tu penses ce que tu peux, je m'en tamponne: je ne me suis jamais déterminé par rapport aux autres. -- It's all right letting yourself go as long as you can let yourself back. -- Mick Jagger -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028162906.62c89...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
On Thu, 28 Oct 2010 14:53:11 +0200, "JF Straeten" wrote: > > Re, > > On Thu, Oct 28, 2010 at 02:11:39PM +0200, Jean-Yves F. Barbier wrote: > > [...] > > > > Tu aurais l'un ou l'autre lien ? > > > marrant ça, mais surtout typique des forums/mls fr: systématiquement > > on quémande les links en évitant soigneusement les effort personnels > > de recherche - l'école est finie... > > Hophophop, permettez ! :-) rien de personnel, c'est juste une constatation de longue date. -- Many a woman hasn't realized that she was raped until the check bounced. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028150500.7680d...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Re, On Thu, Oct 28, 2010 at 02:11:39PM +0200, Jean-Yves F. Barbier wrote: [...] > > Tu aurais l'un ou l'autre lien ? > marrant ça, mais surtout typique des forums/mls fr: systématiquement > on quémande les links en évitant soigneusement les effort personnels > de recherche - l'école est finie... Hophophop, permettez ! :-) Je ne "quémande" rien du tout, certainement pas en évitant un effort personnel, et encore moins "soigneusement". Demander si le colistier a l'un ou l'autre lien sous la main ne veut pas automatiquement dire que l'autre n'en foutra pas une pour chercher lui-même. Je ne peux pas t'empêcher de le penser mais, en toute révérence, ça n'en relève pas moins d'une interprétation de mes intentions (qui vire même au procès d'intention...). Je suis (encore) capable de chercher et le ferai, ce n'est pas la question. J'appliquais "Don't reinvent the Wheel" qui me semblait cher au monde libre ; n'y vois rien d'autre. > non, je n'ai pas de links; [...] Merci beaucoup quand même. A+ -- JFS. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028125311.ga6...@hohenhole.jfs.dt
Re: mdadm "not large enough to join array" et fdisk incohérent
On Thu, 28 Oct 2010 13:22:12 +0200, "JF Straeten" wrote: > > > utiliser le lecteur d'empreintes digitales intégré ? :-) > > > > mauvaise option: la plupart embarquent une eeprom qui conserve des infos > > qui ne devraient pas l'être (sans compter certains enfoirés de > > constructeurs, tel sony, qui modifient le firmware des lecteurs - qui > > deviennent donc incompatibles avec les pgms standards) > > Aha, savais pas du tout... > > Tu aurais l'un ou l'autre lien ? marrant ça, mais surtout typique des forums/mls fr: systématiquement on quémande les links en évitant soigneusement les effort personnels de recherche - l'école est finie... non, je n'ai pas de links; vu le nombre de pages que je lis par jour, je ne bookmark que ce qui a un réel intérêt et que je risque d'oublier. -- Eisenhower was very nice, Nixon was his only vice. -- C. Degen -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028141139.429bd...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Re, On Wed, Oct 27, 2010 at 07:48:23PM +0200, Jean-Yves F. Barbier wrote: > > utiliser le lecteur d'empreintes digitales intégré ? :-) > > mauvaise option: la plupart embarquent une eeprom qui conserve des infos > qui ne devraient pas l'être (sans compter certains enfoirés de > constructeurs, tel sony, qui modifient le firmware des lecteurs - qui > deviennent donc incompatibles avec les pgms standards) Aha, savais pas du tout... Tu aurais l'un ou l'autre lien ? Tia, -- JFS. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028112212.ga5...@hohenhole.jfs.dt
Chiffrement de fichiers [Etait: Re: mdadm "not large enough to join array " et fdisk incohérent]
On Wed, Oct 27, 2010 at 07:48:23PM +0200, Jean-Yves F. Barbier wrote: > ça n'est pas du tout conseillé: il peut y avoir des effets de bord en > superposant 2 encryptions qui rendent le total moins sûr qu'une seule > couche. Tu as des sources là dessus? Ça serait embêtant, mettre des tunnels dans des tunnels est extrèmement commun (du https dans ssh, ou n'importe quoi dans ipsec) > > utiliser le lecteur d'empreintes digitales intégré ? :-) > > mauvaise option: la plupart embarquent une eeprom qui conserve des infos > qui ne devraient pas l'être (sans compter certains enfoirés de > constructeurs, tel sony, qui modifient le firmware des lecteurs - qui > deviennent donc incompatibles avec les pgms standards) +1, tout ce qui est biométrie est loin d'être maitrisé. Y. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101028054936.gm7...@naryves.com
Re: mdadm "not large enough to join array" et fdisk incohérent
On Wed, 27 Oct 2010 19:32:22 +0200, "JF Straeten" wrote: > > Non, ici, je voulais dire "dans le cas de Jean-Yves" (utilisation > ponctuelle, à la demande), y a-t-il une raison de crypter plutôt toute > une partition que de monter un répertoire avec encfs ? non, pas spécialement, à part qu'on peut varier les clés suivant le répertoire. ... > > Ça n'est pas incompatible avec re-chiffrer les fichiers sensibles, > > en ne les déchiffrant qu'au moment où on veut les utiliser (ça ne > > protège pas contre la même chose: l'une protège du vol de disque, > > l'autre réduit la potentialité d'un malware qui vole tes données). > > Tout à fait, oui. ça n'est pas du tout conseillé: il peut y avoir des effets de bord en superposant 2 encryptions qui rendent le total moins sûr qu'une seule couche. ... > - ça marche avec tous les (ou indépendamment du) FS ? ça dépend ... > Mais quid du suspend to ram ? Il devient impossible, ou il se fait à > travers la couche de chiffrement ? à travers, ce qui ne change rien puisqu'il faut en Gal la clé au démarrage. > - et enfin, pour déchiffrer, on doit introduire un mot de passe au > boot, toujours en mode texte, je suppose ? Dans l'affirmative, > comment fait-on sur une tablette ? (Pure slate, donc pas de > clavier.) bonne question > Existe-t-il un moyen de forcer la lecture de la clé depuis un stick > USB ou de la lire via une smartcard, ou (encore mieux) de pouvoir oui, dans le BIOS, en Gal en bootant sur la clé > utiliser le lecteur d'empreintes digitales intégré ? :-) mauvaise option: la plupart embarquent une eeprom qui conserve des infos qui ne devraient pas l'être (sans compter certains enfoirés de constructeurs, tel sony, qui modifient le firmware des lecteurs - qui deviennent donc incompatibles avec les pgms standards) -- It's important that people know what you stand for. It's more important that they know what you won't stand for. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101027194823.0ad2f...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Re, On Wed, Oct 27, 2010 at 04:23:00PM +0200, Yves Rutschle wrote: [...] > > Tant que le déchiffrement ne se fait pas, les datas sont safe, non ? > > Oui. Ah, ça me rassure :-) Pour le reste, je partage ton avis. Mais dans un cas particulier comme celui-ci (une question en amène une autre...), n'est-ce pas un peu lourd de chiffrer toute une partition ? Encfs, basé sur FUSE, permet de chiffrer assez simplement un répertoire. Y a-t-il une raison de lui préférer le chiffrement complet d'une partoche ? A+ -- JFS. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101027145312.ga24...@hohenhole.jfs.dt
Re: mdadm "not large enough to join array" et fdisk incohérent
Re, On Wed, Oct 27, 2010 at 03:33:45PM +0200, Yves Rutschle wrote: > Le chiffrement du disque n'a aucun effet sur le reste des > menaces que tu listes. Modulo quand même le fait que Jean-Yves ne déchiffre qu'en fonction de ses besoins d'accès aux datas et uniquement pour le temps limité de leur consultation... Tant que le déchiffrement ne se fait pas, les datas sont safe, non ? A+ -- JFS. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101027140200.ga23...@hohenhole.jfs.dt
Re: mdadm "not large enough to join array" et fdisk incohérent
On Wed, 27 Oct 2010 08:28:27 +0200, Yves Rutschle
wrote:
> On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote:
> > Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré
> > l'entièreté du volume avec luks
>
> Au fait, vous (Goldy, Kevin, JY) utilisez luks pour vous
> protéger de quoi au juste?
De tous les ptits yeux cupides, rapaces et indiscrets qui pourraient
trainer par là, pour protéger certaines transactions, une partie de mon
carnet d'adresses, mon agenda réel, etc.
Perso, je n'utilise pas une partition entière, juste ce qu'il faut pour
protéger les infos les plus sensibles; mis en route seulement lorsque
c'est nécessaire, puis arrêté de suite après.
> (je vois l'intérêt sur un ordinateur portable, mais sur un
> serveur je suis un peu sec).
Hé bien, le svr est sur le LAN, lequel est raccordé à la box, laquelle est
relativement obscure question sécurité - pense à certains chipsets intel
qui permettent de contacter une machine *pendant* le boot - il est clair
qu'avec une communauté non-w$ grandissante, certains services exercent
des pressions de plus en plus fortes sur les fondeurs pour qu'ils ouvrent
des backdoors.
Pense aussi à l'histoire de cisco lorsqu'une faille profonde a été
révélée (me rappelle +le nom du type): qui a d'abord proposé $120,000 pour
qu'il se taise, puis a obtenu une injonction d'un juge pour lui faire
retirer toutes les infos du net - il-y-a plus dur qu'un virus ou un worm à
concevoir: une faille bien cachée nécessite nettement plus de travail...
Il n'y a qu'à voir la réaction du NSA à l'hadopi: ils font une gueule de
15km de long parce qu'ils ont compris que répression débile = encryption
facile (tout en oubliant que les vrais terroristes n'ont jamais fait
confiance à quelque moyen de comm que ça soit et qu'ils font passer leurs
infos par courriers humains, mais ceci est une autre histoire.)
Penses-tu que le fait qu'israel se soit, en partie, spécialisé dans les
technologies (hard & soft) de comm soit un hasard...?
Sans même aller jusque là (quoique: le NSA est mnt plus spécialisé dans
l'extraction économique que dans le militaire; et il est bien content de
trouver ton agenda si tu bosses chez un concurrent direct d'une boîte us),
le politicard moyen a très peur de ce qu'il-y-a sur ton micro, et rien que
sa curiosité malsaine peut le faire facilement déraper - surtout ici, où les
contrôles ont la portion congrue (yaka voir ce qui se passe avec le STIC...)
Et l'Internet a amplifié tout cela par un facteur inimaginable ('gade la
vitesse à laquelle les vidéos se retrouvent en ligne: dès fois moins de
10 minutes après l'évènement; plus les gens qui les récupère et les rendent
dispos ailleurs.)
Pour faire court :), je préfère prévenir que guérir.
--
A hand in the bush is worth two on the bird.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20101027140436.4a0ee...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 27 octobre 2010 08:28, Yves Rutschle a écrit : > On Tue, Oct 26, 2010 at 11:30:35PM +0200, Goldy wrote: >> Depuis j'ai rajouté un disque pour faire du raid6, et j'ai chiffré >> l'entièreté du volume avec luks > > Au fait, vous (Goldy, Kevin, JY) utilisez luks pour vous > protéger de quoi au juste? > Bonne question. Je n'ai aucune réponse valable à te donner sinon "parce que c'est possible". -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim9qa7x7w0uy7s9w0+738js+tx24uir4yzm5...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 27 octobre 2010 10:38, Sylvain L. Sauvage a écrit : > > Oui euh, mais là, ce qui m’intéressait, c’était les tables > complètes. Suivant le logiciel et le mode utilisé (p.ex. > compatibilité avec DOS pour fdisk), le secteur de début de > partition diffère. En mode « cylindre », c’est toujours 1 mais > en mode « secteur », ça peut varier grandement (1, 32 et 2048 > sont les valeurs par défaut que j’ai observées). La commande > parted suivante permet de tout avoir : > > parted /dev/sdb print unit s print unit chs print Ah je n'avais pas compris comme ça. Je ne connaissais pas non plus cette commande > Bon, ça explique les fdisks, pas le mdadm. Dommage que t’aies > pas gardé la table de partition. En effet. Je pourrais casser mon disque et recommencer mais ca va le vieillir inutilement. Le prochain disque qui merde, promis je ferais ça :) >> Et je gagne 2Mo environ.[…] > > Ce qui fait beaucoup je trouve… Oui je trouve aussi ... Enfin parlant de cryptsetup/luksFormat c'est peut être normal 2Mo d'après fdisk : (1000203833344 - 1000201188352) / 1024 = 2583 ko / 1024 =~ 2.52 Mo >> L'autre piste que j'aurais suivi ensuite aurais été de faire >> un dd complet d'un disque à l'autre. > > Euh, suis pas sûr que ça fonctionne, ça : ya pas deux-trois > données spécifiques par disque ? (les UUID sont stockées ou > calculées ?) Elles peuvent être régénérées d'après ce que j'ai lu ailleurs. Avec tune2fs par exemple. J'ai lu aussi une méthode qui expliquait comment le faire en bidouillant directement les premiers octets du disque dans un éditeur hexa. -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin-3+zbew82ur61ajf-tvfhyp9azat1qywx-...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
Le mardi 26 octobre 2010 à 22:00:13, Kevin Hinault a écrit : >[…] > La on a la même chose partout : > > fdisk de base : > > # /sbin/fdisk.distrib -l /dev/sdb > Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes >[…] Oui euh, mais là, ce qui m’intéressait, c’était les tables complètes. Suivant le logiciel et le mode utilisé (p.ex. compatibilité avec DOS pour fdisk), le secteur de début de partition diffère. En mode « cylindre », c’est toujours 1 mais en mode « secteur », ça peut varier grandement (1, 32 et 2048 sont les valeurs par défaut que j’ai observées). La commande parted suivante permet de tout avoir : parted /dev/sdb print unit s print unit chs print (même si parted n’est pas franchement pratique, il a le mérite de gérer les GPT). Ou avec fdisk : fdisk -lu /dev/sdb Bon, finalement, la différence, c’est que, pour calculer la taille en secteurs, gnu-fdisk utilise la bonne vieille méthode : taille = nb_têtes × nb_cylindres × nb_secteurs_par_piste fdisk et parted utilisent : taille = taille_en_octets / taille_secteur Et comme le nombre de têtes, de secteur par piste et de cylindres sont faux (truqués pour compatibilité CHS), et que la taille en octets est donnée directement par le disque, ce sont fdisk et parted qui ont raison. Bon, ça explique les fdisks, pas le mdadm. Dommage que t’aies pas gardé la table de partition. >[…] > Mais comment sait-on comment sont organisés les lv sur le vg > ? Ah ha ! La bonne question. Rien ne dit que les extents libérés se retrouvent à la fin du pv. En revanche, dans le man de pvresize, il est indiqué que l’on ne peut pas réduire plus bas que les extents utilisés (qu’un jour, pvresize sera capable de les redescendre automatiquement s’il y a de la place). Donc on doit peut-être pouvoir y arriver par essai-erreur… Le mardi 26 octobre 2010 à 23:02:59, Kevin Hinault a écrit : >[…] > Tes excellentes questions viennent de me sauver. […] Tant mieux. > Et je gagne 2Mo environ.[…] Ce qui fait beaucoup je trouve… > L'autre piste que j'aurais suivi ensuite aurais été de faire > un dd complet d'un disque à l'autre. Euh, suis pas sûr que ça fonctionne, ça : ya pas deux-trois données spécifiques par disque ? (les UUID sont stockées ou calculées ?) -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201010271038.16761.sylvain.l.sauv...@free.fr
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 22:30:10 +0200, JC wrote: > > ça n'est pas une question de bug, il suffit qu'un seul bit saute au > > mauvais endroit et c'est râpé (loi de Murphy oblige, ça arrive plus > > souvent que les stats ne le suppute.) > > sans compter que la réunion de 2 couches "sensibles" n'entraine pas une > > évolution linéaire des PBs, mais plutôt exponentielle. > > Bonjour, > Moi aussi, je suis étonné d'apprendre que RAID + LVM ne font pas bon > ménage. J'utilise du RAID1 + LVM depuis 2 ou 3 ans et je n'ai jamais eu de > soucis. > Sans mettre en doute vos dire et juste pour mon information personnelle > (éventuellement avant de revenir sur du simple RAID1 logiciel), sur quoi > se base une telle affirmation ? sur du vécu, un HD qui saute et des données irrécupérables après son remplacement: en fait une impossibilité de récupérer les données malgré que le LVM ne soit pas strippé. Un arrêt normal du système et au démarrage pouf, une erreur et plus rien... une chose est toute fois à noter: depuis l'apparition du SATA et *surtout* de ses connecteurs d'alim (quasiment aucune poss. de rupture de continuité par vibrations, contrairement aux molex semi-circulaires), le risque a pas mal reculé (j'ai même un vieux svr avec 6 HDz qui ont des câbles d'alim soudés, sinon il fallait resserrer les connecteurs d'alim toutes les semaines sous peine d'erreurs à répétition à cause des vibrations basse-fréquences.) sinon, pour la mathématique Murphyenne c'est simple: chaque couche a la capacité de parasiter l'autre (DONC, elle le fera!) ce qui fait que tu multiplies les possibilités d'échec par bien plus que le taux d'erreur unitaire (et si tu as un bit qui saute au mauvais endroit c'est le (hi)jackpot) -- In these matters the only certainty is that there is nothing certain. -- Pliny the Elder -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026232212.3a546...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 26 octobre 2010 23:05, Jean-Yves F. Barbier <12u...@gmail.com> a écrit : > On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault wrote: > >> Hum moi c'est ce qui m'a permis de sauver mes données et de détecter >> mon problème de disque rapidement : >> la couche physique du disque était abimée, ce qui générait des erreurs >> logiques dans la couche chiffrement et donc mon raid voyait des >> différences entre les luks, mais je n'ai perdu aucune donnée puisqu'il >> les corrigeait. >> Dans le cas d'un seul chiffrement, les erreurs logiques auraient peut >> être été reportés sur les deux disques et j'aurais perdu mes données >> puisque la structure des deux luks aurait été abimée. > > alors, puisque TU SAIS, ne poses pas une question dont TU as la réponse > CQFD. Je viens juste d'y songer, ce n'est pas du savoir, c'est de la réflexion à chaud. > entre-parenthèses, ton raisonnement est faux puisque la couche RAID > logicielle effectue un checksum, au même titre qu'un contrôleur hardware, et > est donc à même de détecter une disparité entre données fournies et écrites. J'ai dit "peut-être". -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimiex1ro9gkf+9pgg7e9rsrtg=ayog=-8nrz...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 22:31:59 +0200, Kevin Hinault wrote: > Hum moi c'est ce qui m'a permis de sauver mes données et de détecter > mon problème de disque rapidement : > la couche physique du disque était abimée, ce qui générait des erreurs > logiques dans la couche chiffrement et donc mon raid voyait des > différences entre les luks, mais je n'ai perdu aucune donnée puisqu'il > les corrigeait. > Dans le cas d'un seul chiffrement, les erreurs logiques auraient peut > être été reportés sur les deux disques et j'aurais perdu mes données > puisque la structure des deux luks aurait été abimée. alors, puisque TU SAIS, ne poses pas une question dont TU as la réponse CQFD. entre-parenthèses, ton raisonnement est faux puisque la couche RAID logicielle effectue un checksum, au même titre qu'un contrôleur hardware, et est donc à même de détecter une disparité entre données fournies et écrites. -- Psychoanalysis is that mental illness for which it regards itself a therapy. -- Karl Kraus -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026230555.62275...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 26 octobre 2010 22:00, Kevin Hinault a écrit : > Le 26 octobre 2010 20:56, Sylvain L. Sauvage > a écrit : > > Donc a priori il suffirait de trouver où j'ai perdu les 512ko... Piste > intéressante merci !! > >> Tu utilises directement /dev/sd. ou tu as fait une partition >> /dev/sd.1 ? > > Oui j'ai créé une partition de type primaire sur sdb donc sdb1. > >> Si partition, est-ce que c’est bien la même table ? (Je pense >> p.ex. à une différence de taille entre une table ms-dos et une >> GPT.) Tes excellentes questions viennent de me sauver. J'ai tenté dans un premier temps de copier la table de partition d'un disque à l'autre pour être certain d'avoir les mêmes puis j'ai retenté un luksFormat sur sdb1 ... ... et manque de pot je revient exactement au même chiffre sur /dev/dm-4. A mon avis il y a eu une mise à jour de cryptsetup ou luks depuis le début de l'année qui doit maintenant utiliser un entête plus grand sur le disque. (Ce n'est qu'une supposition mais je ne vois pas d'autres possibilités). # fdisk -l /dev/mapper/raid_disk1 Disk /dev/mapper/raid_disk1: 1000.2 GB, 1000201188352 bytes Par contre ça m'a permis de trouver une parade, j'ai fait le luksFormat directement sur le disque /dev/sdb # cryptsetup luksFormat -c aes -h sha256 /dev/sdb Et je gagne 2Mo environ. # fdisk -l /dev/mapper/raid_disk1 Disk /dev/mapper/raid_disk1: 1000.2 GB, 1000203833344 bytes Et donc je peux reconstruire mon array !!! : # mdadm --manage /dev/md0 --add /dev/dm-5 mdadm: added /dev/dm-5 # mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Thu Feb 11 22:39:46 2010 Raid Level : raid1 Array Size : 976759360 (931.51 GiB 1000.20 GB) Used Dev Size : 976759360 (931.51 GiB 1000.20 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Oct 26 22:52:05 2010 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1 Rebuild Status : 0% complete UUID : e6d41a96:ca63711a:333fb2a5:6fcb4886 (local to host loki) Events : 0.1151744 Number Major Minor RaidDevice State 2 25350 spare rebuilding /dev/dm-5 1 25341 active sync /dev/dm-4 L'autre piste que j'aurais suivi ensuite aurais été de faire un dd complet d'un disque à l'autre. -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinnmhqttgd-aj+_jh32bd-xk2q8obcrskn_d...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
> On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle > wrote: >> On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote: >> > Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y >> > ait le moindre problème sur le disque, uniquement en le sortant et en le >> > réintégrant à l'array (raid5 + lvm + chiffrement). >> >> Comment ça se fait, LVM et raid marchent bien séparément >> mais ne couchent pas bien ensemble sans que ça ai jamais été >> débuggé? >> Le 26 octobre 2010 22:19, Jean-Yves F. Barbier <12u...@gmail.com> a écrit : > ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais > endroit et c'est râpé (loi de Murphy oblige, ça arrive plus souvent que > les stats ne le suppute.) > sans compter que la réunion de 2 couches "sensibles" n'entraine pas une > évolution linéaire des PBs, mais plutôt exponentielle. Hum moi c'est ce qui m'a permis de sauver mes données et de détecter mon problème de disque rapidement : la couche physique du disque était abimée, ce qui générait des erreurs logiques dans la couche chiffrement et donc mon raid voyait des différences entre les luks, mais je n'ai perdu aucune donnée puisqu'il les corrigeait. Dans le cas d'un seul chiffrement, les erreurs logiques auraient peut être été reportés sur les deux disques et j'aurais perdu mes données puisque la structure des deux luks aurait été abimée. -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktintyusk-wdydoyixvwhuvfdq3c1rxnxjjhhb...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 22:19:53 +0200 "Jean-Yves F. Barbier" <12u...@gmail.com> wrote: > ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais > endroit et c'est râpé (loi de Murphy oblige, ça arrive plus souvent que > les stats ne le suppute.) > sans compter que la réunion de 2 couches "sensibles" n'entraine pas une > évolution linéaire des PBs, mais plutôt exponentielle. Bonjour, Moi aussi, je suis étonné d'apprendre que RAID + LVM ne font pas bon ménage. J'utilise du RAID1 + LVM depuis 2 ou 3 ans et je n'ai jamais eu de soucis. Sans mettre en doute vos dire et juste pour mon information personnelle (éventuellement avant de revenir sur du simple RAID1 logiciel), sur quoi se base une telle affirmation ? Merci de vos lumières. Cordialement. -- Salutations. Jean-Claude PSYCHOLOGUE : c'est celui qui regarde les autres quand une jolie femme entre dans une pièce. Pierre DESPROGES -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026223010.65b14...@debian1-home.aygalenq.net
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 26 octobre 2010 22:12, Jean-Yves F. Barbier <12u...@gmail.com> a écrit : >> Donc tu as d'abord créé ton raid et puis tu l'a chiffré et mis du lvm >> par-dessus c'est bien ça ? >> C'est juste pour mon info perso et pour le futur puisque dans le cas >> présent > > Une meilleure question à se poser: au prix où sont les HDz actuels et vu > les capacités, quel est l'intérêt d'utiliser LVM alors qu'on peut > "agrandir" autant qu'on veut sans cette couche, en montant simplement un > nouvel array sur un point situé dans l'original. Oh j'ai bien une réponse qui tient en trois : 1 / si les disques semblent illimités, les ports ne le sont pas sur une même machine. 2 / il faut connaître cette technique dont je n'ai pas connaissance. Tu parlais d'expérience qui n'éclaire que le porteur. Je suis d'accord avec toi si le porteur garde la lumière pour lui. On est dans le cas où le manque de doc est flagrant et où l'expérience est limité. Alors oui j'explore, oui je me plante, oui je suis humble et parfois demande mon chemin quand ma lanterne ne suffit pas. Le fait d'en parler suffira peut être à empêcher d'autres de faire la même bêtise. 3 / L'intérêt est la facilité de modification des lv à chaud. -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikfguaclgg8m0hs++s10dqjqtsb-j_pcbk1w...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 21:42:02 +0200, Yves Rutschle wrote: ça n'est pas une question de bug, il suffit qu'un seul bit saute au mauvais endroit et c'est râpé (loi de Murphy oblige, ça arrive plus souvent que les stats ne le suppute.) sans compter que la réunion de 2 couches "sensibles" n'entraine pas une évolution linéaire des PBs, mais plutôt exponentielle. > On Tue, Oct 26, 2010 at 09:39:51PM +0200, Goldy wrote: > > Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y > > ait le moindre problème sur le disque, uniquement en le sortant et en le > > réintégrant à l'array (raid5 + lvm + chiffrement). > > Comment ça se fait, LVM et raid marchent bien séparément > mais ne couchent pas bien ensemble sans que ça ai jamais été > débuggé? > > Y. > -- Obviously the only rational solution to your problem is suicide. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026221953.3dfc4...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 21:53:14 +0200, Kevin Hinault wrote: ... > Quant à la RAM et au CPU, les performances sont très bonnes de ce côté > là. Wai, c'est aussi le leit-motiv de ceux qui font les javascripts qui bloquent 100% de mon vieux CPU (mais 1% sur un 8 cores avec 100MB de RAM...) Plus sérieusement, c'est aussi multiplier les risques (perte de clé(s), glitch électrique, etc.) > Par contre, je ne suis pas d'accord avec toi, je ne vois pas en > quoi c'est une erreur de mixer lvm+raid. Les deux n'ont pas la même > utilité et peuvent être très bien utilisés en commun. Comme l'a dit Lao Zi, l'expérience est une lanterne qui n'éclaire que le chemin de celui qui la porte. Une (ou ptêt deux) fois que tu auras perdu toutes tes données à cause du couple infernal, tu sauras pourquoi (V. aussi le post de Goldy; perso, j'ai aussi eu le même cas, et ça énerve passablement qd ça arrive.) > Le 26 octobre 2010 21:39, Goldy a écrit : > > > Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y > > ait le moindre problème sur le disque, uniquement en le sortant et en le > > réintégrant à l'array (raid5 + lvm + chiffrement). > > > > Pareil en ce qui concerne le chiffrement, un seul chiffrement sur le > > volume raid est suffisent, chiffrer les deux volumes est d'une > > redondance inutile. > > Donc tu as d'abord créé ton raid et puis tu l'a chiffré et mis du lvm > par-dessus c'est bien ça ? > C'est juste pour mon info perso et pour le futur puisque dans le cas > présent Une meilleure question à se poser: au prix où sont les HDz actuels et vu les capacités, quel est l'intérêt d'utiliser LVM alors qu'on peut "agrandir" autant qu'on veut sans cette couche, en montant simplement un nouvel array sur un point situé dans l'original. -- A figure with curves always offers a lot of interesting angles. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026221223.2ec00...@anubis.defcon1
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 26 octobre 2010 20:56, Sylvain L. Sauvage a écrit : > > Soit 524288 octets = 512 kio de différence. > > Que disent(-ils sur) les couches inférieures (notamment les > /dev/sd*) ? Bonne idée, je n'ai pas pensé à vérifer : La on a la même chose partout : fdisk de base : # /sbin/fdisk.distrib -l /dev/sdb Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes # /sbin/fdisk.distrib -l /dev/sdc Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes gnu-fdisk : # fdisk -l /dev/sdb GNU Fdisk 1.2.4 Disk /dev/sdb: 1000 GB, 1000202273280 bytes # fdisk -l /dev/sdc GNU Fdisk 1.2.4 Disk /dev/sdc: 1000 GB, 1000202273280 bytes Donc a priori il suffirait de trouver où j'ai perdu les 512ko... Piste intéressante merci !! > Tu utilises directement /dev/sd. ou tu as fait une partition > /dev/sd.1 ? Oui j'ai créé une partition de type primaire sur sdb donc sdb1. > Si partition, est-ce que c’est bien la même table ? (Je pense > p.ex. à une différence de taille entre une table ms-dos et une > GPT.) Non je n'ai pas pensé a garder la table de partition. (Mais quel couillon par moment) >_< >> Mes deux questions sont : >> Qui dois-je croire ? > > Sais pas. D’un côté, tout le monde dit que fdisk (le vrai) est > moins fiable que cfdisk ou sfdisk (notamment sa propre page de > man),. De l’autre, j’ai toujours plus de facilité avec lui > qu’avec les autres… > >> Si c'est fidsk.distrib qui a raison, comment je peux dire à >> mon raid d'utiliser un disque légèrement plus petit ? > > Comme ça, on ne peut pas. Tu peux utiliser un disque plus grand > en perdant la différence. Donc tu pourrais à la rigueur essayer > de réduire successivement les couches du haut (ext3 + lv + vg + > pv) pour finalement réduire le md, En faisant bien attention de > récupérer l’espace à la fin. Mais comment sait-on comment sont organisés les lv sur le vg ? -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim2u_npstha-ozseuz9okyy+opn581lkn6ep...@mail.gmail.com
Re: mdadm "not large enough to join array" et fdisk incohérent
Le 26/10/2010 20:47, Jean-Yves F. Barbier a écrit : > > pas terr comme organisation, mixer raid & lvm, c'est multiplier > les risques de pertes de données par au moins 10 - Sans compter > l'overhead rajouté par le fait que chaque membre de l'array a sa > propre encryption (quel intérêt, à part bouffer de la RAM et du CPU, > l'exercice de style peut-être?) Non parce que je pensais que c'était la seule solution. Tout simplement. Quant à la RAM et au CPU, les performances sont très bonnes de ce côté là. Par contre, je ne suis pas d'accord avec toi, je ne vois pas en quoi c'est une erreur de mixer lvm+raid. Les deux n'ont pas la même utilité et peuvent être très bien utilisés en commun. Le 26 octobre 2010 21:39, Goldy a écrit : > Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y > ait le moindre problème sur le disque, uniquement en le sortant et en le > réintégrant à l'array (raid5 + lvm + chiffrement). > > Pareil en ce qui concerne le chiffrement, un seul chiffrement sur le > volume raid est suffisent, chiffrer les deux volumes est d'une > redondance inutile. Donc tu as d'abord créé ton raid et puis tu l'a chiffré et mis du lvm par-dessus c'est bien ça ? C'est juste pour mon info perso et pour le futur puisque dans le cas présent -- Kévin -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=dh3rqupga4=wva_vrrwldc-0j2ydnyxnsk...@mail.gmail.com
Re: mdadm "not large enough to join array " et fdisk incohérent
Le 26/10/2010 20:47, Jean-Yves F. Barbier a écrit : > > pas terr comme organisation, mixer raid & lvm, c'est multiplier > les risques de pertes de données par au moins 10 - Sans compter > l'overhead rajouté par le fait que chaque membre de l'array a sa > propre encryption (quel intérêt, à part bouffer de la RAM et du CPU, > l'exercice de style peut-être?) Je confirme, j'ai perdu un système comme ça une fois, sans même qu'il y ait le moindre problème sur le disque, uniquement en le sortant et en le réintégrant à l'array (raid5 + lvm + chiffrement). Pareil en ce qui concerne le chiffrement, un seul chiffrement sur le volume raid est suffisent, chiffrer les deux volumes est d'une redondance inutile. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4cc72e87.2010...@goldenfish.info
Re: mdadm "not large enough to join array" et fdisk incohérent
Le mardi 26 octobre 2010 à 20:32:20, Kevin Hinault a écrit : > Bonjour à tous, ’soir, >[…] > gnu-fdisk me dit ça : >[…] > Disk /dev/dm-4: 1000 GB, 1000194048000 bytes >[…] > Alors que le fdisk de base sur Debian me dit : > > # /sbin/fdisk.distrib -l /dev/dm-4 > Disk /dev/dm-4: 1000.2 GB, 1000201188352 bytes >[…] > # /sbin/fdisk.distrib -l /dev/dm-5 > Disk /dev/dm-5: 1000.2 GB, 1000201712640 bytes Soit 524288 octets = 512 kio de différence. Que disent(-ils sur) les couches inférieures (notamment les /dev/sd*) ? Tu utilises directement /dev/sd. ou tu as fait une partition /dev/sd.1 ? Si partition, est-ce que c’est bien la même table ? (Je pense p.ex. à une différence de taille entre une table ms-dos et une GPT.) > Mes deux questions sont : > Qui dois-je croire ? Sais pas. D’un côté, tout le monde dit que fdisk (le vrai) est moins fiable que cfdisk ou sfdisk (notamment sa propre page de man),. De l’autre, j’ai toujours plus de facilité avec lui qu’avec les autres… > Si c'est fidsk.distrib qui a raison, comment je peux dire à > mon raid d'utiliser un disque légèrement plus petit ? Comme ça, on ne peut pas. Tu peux utiliser un disque plus grand en perdant la différence. Donc tu pourrais à la rigueur essayer de réduire successivement les couches du haut (ext3 + lv + vg + pv) pour finalement réduire le md, En faisant bien attention de récupérer l’espace à la fin. Perso, j’essaierai d’abord de savoir pourquoi. -- Sylvain Sauvage -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/201010262056.54005.sylvain.l.sauv...@free.fr
Re: mdadm "not large enough to join array" et fdisk incohérent
On Tue, 26 Oct 2010 20:32:20 +0200, Kevin Hinault wrote: > J'ai un RAID 1 tout bête (en mirroring donc) depuis quelques mois qui > tournait pas mal mais il est un peu spécial : chacun des deux disques > est chiffré avec luks et le raid contient des LVM, c'est à dire un pas terr comme organisation, mixer raid & lvm, c'est multiplier les risques de pertes de données par au moins 10 - Sans compter l'overhead rajouté par le fait que chaque membre de l'array a sa propre encryption (quel intérêt, à part bouffer de la RAM et du CPU, l'exercice de style peut-être?) > Si c'est fidsk.distrib qui a raison, comment je peux dire à mon raid > d'utiliser un disque légèrement plus petit ? c'est impossible: on ne peut rajouter un disque|partoche dans un array que s'il est de taille >= à l'existant (et c'est logique.) -- good scout, n.: Someone who knows the lay of the land and will take you to her. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/20101026204730.6ed23...@anubis.defcon1
