WhiteCat a écrit 704 commentaires

je suis pas super chaud pour màj le bios. J’ai un pote qui a briqué sa cm asus comme ça.

C'est pourtant bien une chose extrêmement importante à faire dans ton cas. Si ça se trouve le BIOS corrige un bug errata du chipset… comment savoir, les changelogs ASUS sont complètement bidons.
Je suis partisan de mettre à jour son BIOS quand il y a une mise à jour (sauf si le changelog est suffisamment explicite pour voir que cela n'est pas pertinent bien sûr).

À moins d'avoir une coupure électrique pendant les 2 minutes que dure le flash (grosso modo), c'est difficile de bousiller sa carte mère en mettant à jour son BIOS. Je me demande comment ton pote s'y est pris. Depuis des années j'ai mis à jour plusieurs dizaines de BIOS, de façon bien différente sans problème (màj via utilitaire Windows, via utilitaire DOS, via le BIOS + clé USB, via l'utilitaire flahsrom sur Linux sur des cartes mères déjà testées ou non, sur Linux avec les utilitaires HP et IBM pour serveurs, etc.).

Assures-toi juste de prendre une clé USB FAT32 que tu estimes fiable, copie ton BIOS dessus, fais un checksum du BIOS sur ton HDD et sur ta clé pour vérifier qu'elle est bien copiée dessus.

avec le noyau 4.6.0-0.bpo.1-686-pae (backports).

Tu as une raison particulière de fonctionner en 32 bits ?

J’ai aussi testé avec un livecd fedora

En 32 ou 64 bits ?

alors ma sortie audio est la mini jack vert de la carte mère

OK donc tu est bien sûr que tes enceintes ou casque fonctionne bien aussi ? :-)

visiblement il faudrait que j'installe une autre version de linux

C'est sûr que c'est un test essentiel pour déboguer ton problème. Surout que le noyau de ta version de Linux est relativement ancien. Bon normalement ça devrais fonctionner car ton chip son n'est pas très récent. Essaye quand même avec Fedora 24 ou Ubuntu 16.04/16.10 par exemple.

Deux choses supplémentaires :
- quelle est le modèle de ta carte mère ? Le constructeur a mal fait son boulot et l'information n'apparait pas dans ce que tu as fournis. Connaitre le modèle de ta carte mère permettrait de savoir s'il y a une mise à jour du BIOS disponible.
- Ton Linux est actuellement installé en 32 bits, ce qui n'est vraiment pas approprié car tu disposes d'un processeur 64 bits et de 8 Go de RAM. Actuellement ton PC est limité à 4 Go de RAM en fait, car en 32 bits c'est le maximum gérable.

Bonsoir,

Tu utilises quelle sortie audio ? Celle de la carte mère (mini jack vert) ou l'audio via l'HDMI de ta carte graphique ?

Il y a un outil sur Linux, qui s'appelle efibootmgr. Il est surement disponible sur le LiveCD d'Ubuntu.
Il permet de gérer les entrées de boot UEFI.

Donc démarres ton Uubntu, et supprimes l'entrée correspondante à ton ancien Ubuntu, ensuite mets l'entrée correspondant à Windows en primaire :

$ sudo efibootmgr
Cela va t'afficher l'état actuel du boot UEFI, par exemple (exemple pris du wiki d'Ubuntu fr car je ne suis pas sur un PC UEFI actuellement pour tester) :

BootCurrent: 0001
Timeout: 2 seconds
BootOrder: 0001,3001,0002,2001,2002,2004
Boot0000* Disque dur USB (UEFI) - Generic Flash Disk ACPI(a0341d0,0)PCI(14,0)USB(1,0)HD(1,3e,3b5b92,000bb565)RC
Boot0001* ubuntu HD(1,145800,82000,393abc6a-5b46-4392-a2fa-aebd5ee7d640)File(\EFI\ubuntu\shimx64.efi)
Boot0002* Windows Boot Manager HD(1,145800,82000,393abc6a-5b46-4392-a2fa-aebd5ee7d640)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS…….
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot3001* Internal Hard Disk or Solid State Disk RC

$ sudo efibootmgr --delete-bootnum 0001
Pour supprimer l'entrée UEFI d'Ubuntu (en prenant la sortie de l'exemple ci-dessus).

$ sudo efibootmgr --bootorder 3001,0002,2001,2002,2004
Pour mettre l'ordre de boot que tu veux. Ce qui compte c'est d'enlever l'ancien d'entrée d'Ubuntu (0001) si la commande "delete-bootnum" ne l'avait pas fait, et de mettre Windows dans les 1er choix aussi.

Par contre ce sera à toi de « gérer les dépendances » manuellement. Si tu veux installer un packageA qui dépend de packageB et packageC, il faudra d’abord installer B et C, etc… Pour être clair, s’il n’y a pas trop de dépendances cette méthode est viable mais s’il y en a beaucoup ce sera l’enfer.

Même pas ! Il suffit de télécharger les RPM, les mettre tous dans un même dossier, et lancer le gestionnaire de paquets (dnf) pour installer le paquet principal. dnf va trouver automatiquement les dépendances en utilisant les paquets présents dans le même dossier.

Non j'ai fais le test hier avec mdadm et deux HDD :
1,5To et 3To et j'ai une partition de 4,5To (comme JBOD).
Je l'ai signalé dans ce message :)

Ah c'est vrai tu as raison ! Je ne le savais pas et je viens de faire le test sur une clé USB, apparemment (comme le dit "wismerhill") l'espace "en trop" n'est donc pas stripé.

Les logs noyaux parlent de "zones", dans mon test j'ai créé un RAID0 sur une partition de 64 Mo et de 100 Mo ce qui donne ces logs :

[ 4092.082890] sdd: sdd1 sdd2
[ 4095.086370] sdd: sdd1 sdd2
[ 4132.927349] md: bind
[ 4132.936888] md: bind
[ 4133.127778] md: raid0 personality registered for level 0
[ 4133.128204] md/raid0:md0: md_size is 317440 sectors.
[ 4133.128207] md: RAID0 configuration for md0 - 2 zones
[ 4133.128208] md: zone0=[sdd1/sdd2]
[ 4133.128211] zone-offset= 0KB, device-offset= 0KB, size= 122880KB
[ 4133.128212] md: zone1=[sdd2]
[ 4133.128214] zone-offset= 122880KB, device-offset= 61440KB, size= 35840KB
[ 4133.128224] md0: detected capacity change from 0 to 162529280

On voit donc que la 1ère zone est stripée sur 2 partitions pour 120 Mo et le reste (35 Mo) sur une partition.
Par contre je ne comprends pas pourquoi ma 1ère zone (celle qui est stripée) fait 120 Mo au lieu de 128 Mo (2 * 64 Mo) ?

Tout ceci n'a pas l'air documenté dans la doc kernel.org ni le man.

Ah, je ne connais pas encore celui-là. Tu as un petit retour d'expérience dessus? :)

Absolument aucun :-) J'en ai juste entendu parler récemment, ça avait l'air sympa comme idée. En gros tu peux avoir 2 disques avec chacun leur arborescence. Donc là on parle au niveau filesystem. Et avec AuFS tu peux créer un point de montage qui va fusionner ces 2 filesystem.
À part ça je peux pas vraiment t'en apprendre plus.

puis-je faire du non stripped (je ne veux pas que les fichiers soient découpé mais répartis)

Non, le RAID0 est bas niveau. Il ne voit pas tes fichiers. Si tu veux répartir tes fichiers faut gérer ça à plus haut niveau, par exemple avec GlusterFS ou AuFS.

puis-je ajouter/retirer des disques

Oui, d'après le man mdadm, tout ceci est possible.

les données présentent sur les autres disques sont-elles encore valable/utilisable si un disque crash

Non, c'est le principe du RAID0.

est-ce stable?

Oui.

puis-je additionner les disques comme un JBOD afin d'utiliser tout l'espace disponible ou suis-je limité par l'équation 2xplus petit disque = espace disponible -il se passe quoi si un disque (ou plusieurs) n'est pas présent au boot

Le RAID0 aura la taille du plus petit disque oui. Tu ne peux pas simplement agréger les disques comme en JBOD.
En revanche ce que tu peux faire, si imaginons que tu ais 4 disques :
2 disques de 750 Go
2 disques de 1 To

Tu fais un RAID0 de 3 To (= 4 tranches de 750 Go)
Il te reste donc 250 Go inutilisés sur chaque disque de 1 To. Tu peux très bien y faire un RAID0 de 500 Go (= 2 tranches de 250 Go) avec les espaces libres sur les 2 disques de 1 To.

il se passe quoi si un disque flanche en cours de fonctionnement?

Le RAID0 tombe et tu perds les données.

C'est pas faux.
Junior fait spécifiquement référence à la jeunesse, je n'y avais pas pensé.

Ça fait pas du tout référence à l'age, mais à l'expérience professionnelle.

C'est dans quelle ville ?
On peut faire du télé-travail ?

Ah et j'oubliais. Si tu veux faire ça encore plus proprement, tu peux même intervertir les câbles SATA du HDD et du SSD entre l'étape 7 et 8 (avant de booter Windows quoi). Comme ça Windows sera un peu moins perturbé car il sera toujours sur le même port SATA qu'avant.

Ceci dit il va quand même voir que le disque a changé et va sûrement te demander de rebooter au 1er démarrage.

Aucune idée désolé. Je connais trop peu Windows 8/10.

OK c'est bien ce que j'en avais déduis.

Du coup, voilà comment j'aurais procéder personnellement.
Cela va sans dire que je te conseille vivement de faire une sauvegarde du HDD avant, car les opérations ci-dessous sont non réversibles. Notamment j'ai un léger doute sur le fait que Windows retrouve vraiment bien la partition D (cf. ma remarque au point 8).

1) Réduire la partition C:
Tu peux le faire directement depuis le Windows en cours de fonctionnement, avec l'outil de gestion de disque Windows. Il te permet de réduire la taille de la partition C. Il va te dire de combien tu peux le réduire au maximum.
Il faudrait la réduire au minimum à un peu moins de la taille du SSD, mais en fait le mieux est carrément de réduire la partition au maximum possible. Ça évitera de copier trop de données vers le SSD lors du transfert (si on peut éviter "d'user" les cellules du SSD c'est pas plus mal, et la copie sera forcément plus rapide aussi).
Si tu ne peux pas réduire la partition à la taille du SSD, ben… va falloir supprimer des trucs sur le C. Ou alors essayer la réduction offline avec GParted LiveCD par exemple.
Une défragmentation du C peut être utile aussi je pense.

2) Copier le MBR sur le SSD
Tu bootes avec un LiveCD quelconque, afin de copier le MBR du HDD vers le SSD.
Perso je fais ça avec dd.

Tu repères avec parted qui est /dev/sda et /dev/sdb entre le HDD et le SSD.
# parted -l

(dans la suite je pars du principe que sdY = HDD, et sdX = SSD)
(et que la partition 1 correspond à la partition cachée Windows, 2 au C: et 3 au D:)

Et tu fais la copie du MBR :
# dd if=/dev/sdY of=/dev/sdX bs=4M count=1 && sync

Ouais je sais le MBR ne fait pas 4 MB mais disons que c'est pour être sûr de tout copier le début du disque en fait, on s'en fou de copier "trop" à ce moment-là.

Maintenant si tu refais un parted -l tu devrais voir que ton SSD dispose des mêmes partitions que le HDD. Là par contre je ne sais pas si tu vas avoir un message d'erreur ou pas étant donné que la partition D devrait être complètement hors du SSD.

3) Supprimer la partition D: du SSD
La partition D sur le SSD ne doit pas exister.

Tu repères quel est le numéro de partition D du SSD avec parted :
# parted -l

Tu supprimes avec parted :
# parted /dev/sdX (tu remplaces sdX avec ce qui correspond au SSD)
> rm 3 (correspond au numéro de partition de D:, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

4) Copier la partition cachée Windows
Comme d'hab', tu repères avec parted que le numéro de partition qui correspond à la partition cachée de Windows, et tu la copies avec dd du HDD vers le SSD :
# dd if=/dev/sdY1 of=/dev/sdX1 bs=8M && sync

5) Copier la partition C
Là, pareil qu'au-dessus :
# dd if=/dev/sdY2 of=/dev/sdX2 bs=8M && sync

6) Supprimer la partition cachée du HDD
Tu supprimes avec parted :
# parted /dev/sdY (tu remplaces sdY avec ce qui correspond au HDD)
> rm 1 (correspond au numéro de partition cachée de Windows, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

7) Supprimer la partition C du HDD
Tu supprimes avec parted :
# parted /dev/sdY (tu remplaces sdY avec ce qui correspond au HDD)
> rm 2 (correspond au numéro de partition de C:, à toi d'adapter le numéro en fonction de ce qu'il y aura chez toi)
> q (pour quitter)

8) Rebooter sur Windows (SSD)
Il est possible qu'il y ai chkdsk qui se lance au boot de Windows, rien d'anormal.
Une fois sur Windows il suffit de vérifier que ça fonctionne :-) et que le disque D est opérationnel aussi. Je pense que Windows devrait s'y retrouver mais j'ai pas testé donc peut-être que je suis trop optimiste…

9) Agrandir les partitions C et D
Tu peux le faire soit en online depuis Windows comme pour l'étape 1.
Ou bien en offline avec un LiveCD de GParted par exemple.
Pour l'agrandissement du D, penses à laisser 1 ou 2 Mio de dispo au début du disque, pour être sûr que le système de fichiers soit bien aligné sur les secteurs du HDD.

10) Faire un chkdsk sur C et D
Ça mange pas de pain.

Si je comprends bien, il n'y a pas de Linux sur ce HDD ?
Et tu veux transférer sur le SSD la partition "réservée" Windows (celle qui fait une centaine de Mo) ainsi que la partition Windows elle-même (C:). Mais laisser la dernière partition sur le HDD ?

Et il dit justement qu'à part "l'usage de logiciels libres", c'est générique (ça pourrait être une boite qui fait des ménages ou une boite qui vend des gadgets ou du logiciel non libre, c'est pareil) et qu'il n'y a rien qui soit spécifique au libre. Le libre ici est comme la couleur des cheveux du personnage principal d'un roman, c'est de la description optionnelle qui n'apporte rien au sujet.

Détrompes-toi. J'aime beaucoup sa série de témoignage justement parce qu'il raconte son histoire vis-à-vis d'une entreprise qui essaye de vivre du libre.
Il aurait raconté la même histoire pour sa boite qui fait du logiciel propriétaire, j'en aurais eu strictement rien à foutre, quand bien même il aurait rencontré les mêmes difficultés et problématiques.

Bonsoir,

Pour répondre à tes questions, je te conseille vivement de regarder ces 2 excellentes vidéos :
Le Bitcoin et la Blockchain (avec Heu?Reka) — Science étonnante #31
Bitcoin - Heu?reka #13

Pour ta dernière question je ne vois pas de quoi tu parles. Il n'y a pas de serveur à choisir pour entrer dans le réseau Bitcoin.

Si tu peux, prends une distrib' 64 bits. Ça te fera des performances "gratuites" en plus.

Et vérifie si ton BIOS est à jour, c'est toujours une bonne chose de le mettre à jour.

Par rapport à tes disques, il serait pas mal de vérifier leur "état de santé". Sous Linux, tu peux exécuter ces commandes :

# smartctl --all /dev/sda ; smartctl --all /dev/sdb

(si tu as 2 disques, il est très probable qu'il soit nommé sda et sdb, sinon tu adaptes la commande)
Dans le résultat de la commande, il faut surtout vérifier le nombre de secteurs défectueux.

Enfin, tu peux vérifier s'il n'y a pas de problème d'accès avec cette commande :

# dmesg |grep ata

J'espère juste que t'as pas pris un SSD Corsair Force LS.

Bonsoir,

Vu le message, moi je me serais dit que c'est un problème de lecture de la clé USB.
Essaye avec une autre clé USB si tu peux, voire même un CD/DVD.

Essaye dans un autre port USB aussi, notamment si c'est du USB 3.0 là, essaye dans un port USB 2.0.

Vérifie que ton BIOS est à jour aussi.

Et aussi l’anecdotique Windows XP x64, en 2005, basé sur XP SP2.

Basé sur Windows 2003 Server plutôt (noyau NT 5.2).

Un benchmark honnête serait par exemple de faire tourner x265 sans le code optimisé à la main… Enfin si phoronix savait comment faire des benchs ça se saurait :P

Ça s'appelle pas un benchmark honnête, mais simplement un autre benchmark.
Phoronix est plutôt irréprochable sur la méthodologie de ses benchmarks. Personnellement je ne vois pas trop quoi y redire. Après c'est le choix des benchmarks qui semblent te poser problème, mais c'est un autre problème qui n'a rien à voir avec la méthodologie elle-même.

Ça en fait toujours une de moins qu'en 64bits ;-)

C'est pas faux ;)

En l'occurrence, ça m'étonnerait pas que x265 soit plus rapide en i386.

Je n'ai aucune raison rationnelle de croire cela.
Donc j’attends de voir un benchmark pour te croire sur parole.

Le problème du trésorier: quelle est la version de linux la plus compatible à offrir à mon publique -> satisfaction de Mme Michu.

Et c'est bien pour ça que j'ai posté sur ce forum. Pour dire qu'à mon sens il se trompe. S'il veut veut offrir la meilleure expérience à Mme Michu, c'est certainement pas en lui installant un Linux 32 bits sur son portable Haswell 8 Go…

Le problème de Linus: comment faire pour avoir un système le plus performant sur le matériel actuel -> est-ce vraiment pour Mme Michu ?

Et aussi le moins bugué. Or quand on essaye de faire tourner un OS sur une machine récente (avec beaucoup de RAM, genre + de 2 Go), l'AMD64 semble plus simple à gérer du point de vue de l'OS, donc moins de bug.

ben si ça se trouve i386 ou x32 sur du matos 64bit avec PAE activé sera plus performant qu'une autre solution.

En x32 c'est bien possible. En PAE j'en doute étant donné que le PAE rajoute une 3ème indirection mémoire que le CPU doit traiter en plus.