Si c'est comme avec les autres logiciels, ça fonctionne 1x sur 10...
C'est largement plus rapide d'utiliser dd ou ddrescue.
tu topes le sd(x) de ta clef usb et tu dd if=chemin/vers/ton/iso of=/dev/sd(usb)
Tu peux rajouter un argument bs=512 ou bs=1M pour gagner du temps.
Tu auras une clef parfaitement fonctionnelle 100x du temps.

Et si tu te gourres de cible... Ouille !

Qui ne s'est jamais gourré de cible dans une commande dd ?

moi.
ton périphérique est généralement le dernier de la liste.
tu réfléchis 2 secondes, tu vérifies et tu te lances.
pas besoin de faire un doctorat pour ça.

de nombreux utilitaires de ce type posent problèmes (pour Debian en tout cas).
et je conseille d’arrêter l'utilisation de unetbootin.
dd, cp et autres sont uniquement dispo sous Linux donc c'est pas forcément adapté.
dans la doc Debian, on nous propose win32diskimager pour Windows.
https://www.debian.org/releases/jessie/amd64/ch04s03.html.en#usb-copy-flexible

Je ne me suis jamais trompé non plus avec dd.

@nIQnutn

On n'est jamais à l'abri d'une erreur. Même la personne la plus prudente du monde pourra un jour se planter.

Sinon, unetbootin est devenue une sombre... au fil des années.

Sinon, il y a rufus qui fait bien le boulot sous MS-Windows.

moi non plus, jamais gourré de cible... Mais bon, venant de Frederic Bezies , ça m'étonne pas cet argument...
Avec toi, faut toujours aller au plus primaire, ne visualisant que l'utilisateur final et en le considérant comme un demeuré...
Ta vision des choses, c'est pas une "simplification", c'est une vision linux d'idiocratie...

"On n’est jamais à l’abri d’une erreur. Même la personne la plus prudente du monde pourra un jour se planter."
Donc, en fait, d'après toi, mieux vaut ne rien faire que de risquer de se planter. Je note, niveau philosophique, ça se défend...
Mais en fait, pourquoi migrer sous linux du coup? Si tu te plantes?

@metasystem :

Avec toi, faut toujours aller au plus primaire, ne visualisant que l’utilisateur final et en le considérant comme un demeuré…

C'est vrai que je prends les personnes qui me suivent pour des attardés.

Ta vision des choses, c’est pas une “simplification”, c’est une vision linux d’idiocratie…

Non, celle d'une personne qui sait qu'on est en 2017, et qu'il existe des codeurs qui savent faire des applications qui fonctionnent. Et je n'ai commencé à tater du linux qu'à partir de 1996.

Limiter les risques, c'est mal ? En quoi cela serait une idiocratie ?

Donc, en fait, d’après toi, mieux vaut ne rien faire que de risquer de se planter.

Oh, la belle bleue ;)

Je dis simplement que personne n'est infaillible.

Mais en fait, pourquoi migrer sous linux du coup? Si tu te plantes?

On apprend de ses erreurs. Mais les personnes qui m'affirment ne s'être jamais planté avec des opérations liées à dd, ça me fait dire que la modestie n'est pas franchement partagé par tout le monde.

Dès qu'on fait une commande en root ou avec sudo, il faut juste faire gaffe avant de valider la ligne.

Ça me fait comprendre pourquoi Brian Lunduke a fait sa série "Linux sucks" entre 2009 et 2017.

Mais les personnes qui m’affirment ne s’être jamais planté avec des opérations liées à dd, ça me fait dire que la modestie n’est pas franchement partagé par tout le monde.

peut être qu'on fait attention et qu'on prend les précautions nécessaires quand on fait se genre d'opération.
je connais les conséquences, donc j'évite de faire le con.

si tu avançais de vrais arguments en expliquant pourquoi cette commande n'est pas parfaite plutôt que de faire de longues phrases sans grand intérêt.

c'est vrai qu'avec une interface graphique, on ne peut pas se tromper. c'est bien connu.

encore l'aspect pédant de Frederic.
Il pense avoir la vérité absolue.
Sinon, tu sais, dd ça existe depuis une blinde, et c'est correctement codé. Contrairement aux applications graphiques qui foirent régulièrement dans la production de clefs usb de boot.
J'arrive toujours pas à comprendre comment tu as put te faire une place dans la communauté linux avec des raisonnements si primaires et qui estiment que si eux merdent, alors les autres aussi.

Sinon, au passage, limiter les risques, c'est faire un lsblk avant de faire un dd pour afficher quel /dev/sd(x) correspond à quoi, c'est le principe de base avant de lancer des commandes ou des actions que de se renseigner un minimum. Mais bon, venant d'un gars qui passe 1h sur virtualbox à faire du distro hopping et se pense apte à juger le travail des autres, rien ne m'étonne.

@nIQnutn :

peut être qu’on fait attention et qu’on prend les précautions nécessaires quand on fait se genre d’opération.

Le risque zéro n'existera jamais.

je connais les conséquences, donc j’évite de faire le con.

Moi aussi.

si tu avançais de vrais arguments en expliquant pourquoi cette commande n’est pas parfaite plutôt que de faire de longues phrases sans grand intérêt.

Ce n'est pas la commande qui n'est pas parfaite, c'est juste qu'elle est dangereuse comme toutes les commandes qui touchent aux supports de stockage.

c’est vrai qu’avec une interface graphique, on ne peut pas se tromper. c’est bien connu.

Où ai-je dit cela ? J'aime bien la ligne de commande, mais par moment, une interface graphique n'est pas à rejeter.

@metasystem : et je suis pédant, maintenant ?

Si j'avais la vérité absolue, je serais déjà engagé en politique :)

Sinon, tu sais, dd ça existe depuis une blinde, et c’est correctement codé. Contrairement aux applications graphiques qui foirent régulièrement dans la production de clefs usb de boot.

Je n'ai que rarement utilisé ce genre d'outil, mais à chaque utilisation, je n'ai jamais eu le moindre problème :)

Si tu évites cette antiquité de Unetbootin, tu évites 95% des emmerdes.

J’arrive toujours pas à comprendre comment tu as put te faire une place dans la communauté linux avec des raisonnements si primaires et qui estiment que si eux merdent, alors les autres aussi.

Et toi comment fais-tu pour ne lire que ce qui t'intéresse dans mes remarques ? :)

Ce que j'ai fait depuis une vingtaine d'années ? Installer des distributions quand faire fonctionner Xfree tenait du casse-tête. Ou encore quand on devait se configurer tous les fichiers de pulse audio.

Bref, des trucs formateurs :)

@metasystem :

Sinon, au passage, limiter les risques, c’est faire un lsblk avant de faire un dd pour afficher quel /dev/sd(x) correspond à quoi, c’est le principe de base avant de lancer des commandes ou des actions que de se renseigner un minimum.

Prends-moi pour un débile profond maintenant... :D

Mais bon, venant d’un gars qui passe 1h sur virtualbox à faire du distro hopping et se pense apte à juger le travail des autres, rien ne m’étonne.

Toujours cette basse attaque ? Tu ne trouves pas que cela fait un peu disque rayé ?

Quant à une heure sur virtualbox à faire du distro hopping ?

fred@fredo-arch ~ % head /var/log/pacman.log
[2015-06-21 08:15] [PACMAN] Running 'pacman -r /mnt -Sy --cachedir=/mnt/var/cache/pacman/pkg --noconfirm base base-devel'
[2015-06-21 08:15] [PACMAN] synchronizing package lists
[2015-06-21 08:17] [ALPM] transaction started
[2015-06-21 08:17] [ALPM] installed linux-api-headers (4.0-1)
[2015-06-21 08:17] [ALPM] installed tzdata (2015e-1)
[2015-06-21 08:17] [ALPM] installed iana-etc (2.30-5)
[2015-06-21 08:17] [ALPM] installed filesystem (2015.02-1)
[2015-06-21 08:17] [ALPM] installed glibc (2.21-4)
[2015-06-21 08:17] [ALPM] installed attr (2.4.47-1)
[2015-06-21 08:17] [ALPM] installed acl (2.2.52-2)

C'est vrai que je ne sais faire que du distro-hoping... Nulle aide à des projets comme Arch-Anywhere, Mozilla, Archlinux et combien d'autres encore.

Y a pas à dire, mais tes arguments comme le "1 heure sur virtualbox", ils sont courts de nos jours.

Je retourne à la Archlinux OpenRC que j'ai installé en virtuel et qui m'a demandé une heure de vidéo pour en faire la présentation et l'installation en live.

https://www.youtube.com/watch?v=YHZjfaQvAGA