# WoeUSB sur Bullseye

**URL:** <https://www.debian-fr.org/t/woeusb-sur-bullseye/85396>\
**Category:** Support Debian\
**Created:** [Septembre 23, 2021, 12:38 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396 "2021-09-23T12:38:40Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 23, 2021, 12:38 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/1 "2021-09-23T12:38:40Z")

</div>

Pour installer une clé DBAN purgée par erreur on m’a recommandé d’utiliser WoeUSB plutôt que dd (parce que avec dd la clé ne marchait pas ensuite).

WoeUSB n’a pas l’air d’être dans les dépôts et le snap n’a pas marché je sais pas pourquoi.  
[Ici](https://www.how2shout.com/linux/how-to-install-woeusb-on-debian-10-buster-bootable-usb-creator/) ils proposent de le faire par pip (ce qui ne m’enthousiasme pas beaucoup plus, mais au moins dans un virtual env ça devrait pas casser le reste du système).

Par contre quand je tente leur méthode ça marche pas non plus, les erreurs semblent se plaindre que gtk3 ne soit pas là (pourtant MATE utilise bien GTK3 non ?) :

```
 ERROR: Command errored out with exit status 1:
     command: /home/lutech/WoeUSB/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/setup.py'"'"'; __file__ ='"'"'/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)( __file__ );code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__ , '"'"'exec'"'"'))' install --record /tmp/pip-record-g996ltxh/install-record.txt --single-version-externally-managed --compile --install-headers /home/lutech/WoeUSB/include/site/python3.9/wxPython
         cwd: /tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/
    Complete output (144 lines):
    running install
    running build
    WARNING: Building this way assumes that all generated files have been
    generated already. If that is not the case then use build.py directly
    to generate the source and perform the build stage. You can use
    --skip-build with the bdist_* or install commands to avoid this
    message and the wxWidgets and Phoenix build steps in the future.
    
    "/home/lutech/WoeUSB/bin/python3" -u build.py build
    Will build using: "/home/lutech/WoeUSB/bin/python3"
    3.9.2 (default, Feb 28 2021, 17:03:44)
    [GCC 10.2.1 20210110]
    Python's architecture is 64bit
    cfg.VERSION: 4.1.1
    
    Running command: build
    Running command: build_wx
    wxWidgets build options: ['--wxpython', '--unicode', '--gtk3']
    Configure options: ['--enable-unicode', '--with-gtk=3', '--enable-sound', '--enable-graphics_ctx', '--enable-display', '--enable-geometry', '--enable-debug_flag', '--enable-optimise', '--disable-debugreport', '--enable-uiactionsim', '--enable-autoidman', '--with-sdl']
    /tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/ext/wxWidgets/configure --enable-unicode --with-gtk=3 --enable-sound --enable-graphics_ctx --enable-display --enable-geometry --enable-debug_flag --enable-optimise --disable-debugreport --enable-uiactionsim --enable-autoidman --with-sdl
    checking build system type... x86_64-pc-linux-gnu
    checking host system type... x86_64-pc-linux-gnu
    checking for toolkit... gtk
    checking for gcc... gcc
    checking whether the C compiler works... yes
    checking for C compiler default output file name... a.out
    checking for suffix of executables...
    checking whether we are cross compiling... no
    checking for suffix of object files... o
    checking whether we are using the GNU C compiler... yes
    checking whether gcc accepts -g... yes
    checking for gcc option to accept ISO C89... none needed
    checking whether we are using the Intel C compiler... no
    checking how to run the C preprocessor... gcc -E
    checking for grep that handles long lines and -e... /usr/bin/grep
    checking for egrep... /usr/bin/grep -E
    checking whether gcc needs -traditional... no
    checking for g++... g++
    checking whether we are using the GNU C++ compiler... yes
    checking whether g++ accepts -g... yes
    checking whether we are using the Intel C++ compiler... no
    checking whether we are using the Sun C++ compiler... no
    checking for ar... ar
    checking for ANSI C header files... yes
    checking for sys/types.h... yes
    checking for sys/stat.h... yes
    checking for stdlib.h... yes
    checking for string.h... yes
    checking for memory.h... yes
    checking for strings.h... yes
    checking for inttypes.h... yes
    checking for stdint.h... yes
    checking for unistd.h... yes
    checking for langinfo.h... yes
    checking for wchar.h... yes
    checking for sys/select.h... yes
    checking for cxxabi.h... yes
    checking for an ANSI C-conforming const... yes
    checking for inline... inline
    checking size of short... 2
    checking size of void *... 8
    checking size of int... 4
    checking size of long... 8
    checking size of size_t... 8
    checking size of long long... 8
    checking size of wchar_t... 4
    checking for va_copy... yes
    checking for _FILE_OFFSET_BITS value needed for large files... 64
    checking if large file support is available... yes
    checking for _LARGEFILE_SOURCE value needed for large files... no
    checking whether byte ordering is bigendian... no
    checking for std::wstring in <string>... yes
    checking for std::istream... yes
    checking for std::ostream... yes
    checking for type_traits... yes
    checking for __sync_fetch_and_add and__ sync_sub_and_fetch builtins... yes
    checking for libraries directories... /usr/lib/x86_64-linux-gnu /usr/lib
    checking for cos... no
    checking for floor... no
    checking if floating point functions link without -lm... no
    checking for sin... yes
    checking for ceil... yes
    checking if floating point functions link with -lm... yes
    checking for strtoull... yes
    checking for pkg-config... /usr/bin/pkg-config
    checking pkg-config is at least version 0.9.0... yes
    configure: WARNING: Defaulting to the builtin regex library for Unicode build.
    checking for zlib.h >= 1.1.4... yes
    checking for zlib.h... (cached) yes
    checking for deflate in -lz... yes
    checking for png.h > 0.90... no
    checking for png.h... (cached) no
    configure: WARNING: system png library not found or too old, will use built-in instead
    checking whether png.c file exists... yes
    checking for jpeglib.h... no
    configure: WARNING: system jpeg library not found, will use built-in instead
    checking whether jpeglib.h file exists... yes
    checking lzma.h usability... no
    checking lzma.h presence... no
    checking for lzma.h... no
    checking for jbg_dec_init in -ljbig... no
    checking for LIBTIFF... not found via pkg-config
    checking for tiffio.h... no
    configure: WARNING: system tiff library not found, will use built-in instead
    checking whether tiff.h file exists... yes
    checking for expat.h... yes
    checking if expat.h is valid C++ header... yes
    checking for XML_ParserCreate in -lexpat... yes
    checking for GTK+ version...
    checking for pkg-config... (cached) /usr/bin/pkg-config
    checking pkg-config is at least version 0.16... yes
    checking for GTK+ - version >= 3.0.0... Package gtk+-3.0 was not found in the pkg-config search path.
    Perhaps you should add the directory containing `gtk+-3.0.pc'
    to the PKG_CONFIG_PATH environment variable
    No package 'gtk+-3.0' found
    Package gthread-2.0 was not found in the pkg-config search path.
    Perhaps you should add the directory containing `gthread-2.0.pc'
    to the PKG_CONFIG_PATH environment variable
    No package 'gthread-2.0' found
    no
    *** Could not run GTK+ test program, checking why...
    *** The test program failed to compile or link. See the file config.log for the
    *** exact error that occurred. This usually means GTK+ is incorrectly installed.
    configure: error:
    The development files for GTK+ were not found. For GTK+ 2, please
    ensure that pkg-config is in the path and that gtk+-2.0.pc is
    installed. For GTK+ 1.2 please check that gtk-config is in the path,
    and that the version is 1.2.3 or above. Also check that the
    libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
    --libs' are in the LD_LIBRARY_PATH or equivalent.
    
    Error running configure
    ERROR: failed building wxWidgets
    Traceback (most recent call last):
      File "/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/build.py", line 1510, in cmd_build_wx
        wxbuild.main(wxDir(), build_options)
      File "/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/buildtools/build_wxwidgets.py", line 372, in main
        exitIfError(wxBuilder.configure(dir=wxRootDir, options=configure_opts),
      File "/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/buildtools/build_wxwidgets.py", line 85, in exitIfError
        raise builder.BuildError(msg)
    buildtools.builder.BuildError: Error running configure
    Finished command: build_wx (0m2.388s)
    Finished command: build (0m2.388s)
    Command '"/home/lutech/WoeUSB/bin/python3" -u build.py build' failed with exit code 1.
    ----------------------------------------
ERROR: Command errored out with exit status 1: /home/lutech/WoeUSB/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/setup.py'"'"'; __file__ ='"'"'/tmp/pip-install-bolo_biv/wxpython_b2449af196fc41869914b992fb32daae/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)( __file__ );code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__ , '"'"'exec'"'"'))' install --record /tmp/pip-record-g996ltxh/install-record.txt --single-version-externally-managed --compile --install-headers /home/lutech/WoeUSB/include/site/python3.9/wxPython Check the logs for full command output." 

```

Quelle est la bonne méthode pour installer WoeUSB alors ?  
Ou bien il y a une meilleure méthode pour installer l’ISO sur la clé ?  
Etcher c’est non vues toutes les saletés qu’il trimballe, et Ventoy c’est très bien mais pour du multi-boot, pas pour un truc aussi simple que DBAN ?

---

<div class="post-metadata">

**Author:** ![ylag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/3bc359/32.png) [@ylag](https://www.debian-fr.org/u/ylag)\
**Post date:** [Septembre 23, 2021, 1:46 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/2 "2021-09-23T13:46:32Z")

</div>

Bonjour,

Sans être un expert dans ce domaine, j’utilise **dd** depuis fort longtemps pour créer ce genre de clés.  
Après l’utilisation de dd, Il faut recréer une table de partition et une nouvelle partition sur la clé pour pouvoir la réutiliser comme périphérique de stockage ; j’utilise Gparted en général pour le faire, mais il existe d’autres méthodes tout aussi valables pour restaurer ces clés à leur état original.

Ayant découvert Ventoy récemment, je m’en suis créé une clé, histoire de voir ce qu’il en est : J’aime beaucoup! 🙂  
Ça devrait aussi bien fonctionner avec une seule image iso qu’avec plusieurs.  
C’est pratique, puisqu’il suffit d’ajouter ou de supprimer directement les images iso dans la partition dédiée de la clé une fois la clé configurée, sans avoir à reprendre le processus de création depuis le début.

Quant à dire quelle méthode est la meilleure, c’est plutôt une question de choix personnel amha…

A+

---

<div class="post-metadata">

**Author:** ![littlejohn75](https://www.debian-fr.org/user_avatar/www.debian-fr.org/littlejohn75/32/3840_2.png) [@littlejohn75](https://www.debian-fr.org/u/littlejohn75)\
**Post date:** [Septembre 23, 2021, 5:59 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/3 "2021-09-23T17:59:58Z")

</div>

> [@Iutech](#):
>
> quand je tente leur méthode ça marche pas non plus, les erreurs semblent se plaindre que gtk3 ne soit pas là

Le paquet `libgtk-3-0` est certainement là 🙂 Mais

> [@Iutech](#):
>
> `The development files for GTK+ were not found.`

Et cela c’est le paquet `libgtk-3-dev` et c’est une autre paire de manches.

```auto
& fp2@debpacha:~ $ apt-cache depends libgtk-3-dev
libgtk-3-dev
  Dépend: gir1.2-gtk-3.0
  Dépend: libatk-bridge2.0-dev
  Dépend: libatk1.0-dev
  Dépend: libcairo2-dev
  Dépend: libegl1-mesa-dev
  Dépend: libepoxy-dev
  Dépend: libfontconfig1-dev
    libfontconfig-dev
  Dépend: libfribidi-dev
 |Dépend: libgdk-pixbuf-2.0-dev
  Dépend: libgdk-pixbuf2.0-dev
  Dépend: libglib2.0-dev
  Dépend: libpango1.0-dev
  Dépend: libwayland-dev
  Dépend: libx11-dev
  Dépend: libxcomposite-dev
  Dépend: libxcursor-dev
  Dépend: libxdamage-dev
  Dépend: libxext-dev
  Dépend: libxfixes-dev
  Dépend: libxi-dev
  Dépend: libxinerama-dev
  Dépend: libxkbcommon-dev
  Dépend: libxrandr-dev
  Dépend: pkg-config
    pkg-config:i386
    pkgconf:i386
    pkgconf
  Dépend: wayland-protocols
 |Dépend: dconf-gsettings-backend
  Dépend: <gsettings-backend>
    dconf-gsettings-backend
    gconf-gsettings-backend
  Dépend: libgtk-3-common
  Dépend: libgtk-3-0
  Suggère: libgtk-3-doc
1& fp2@debpacha:~ $ 

```

Autrement dit, si vous installez depuis les sources via _pip_ vous devez prendre une casquette de développeur.

> [@Iutech](#):
>
> Pour installer une clé DBAN purgée par erreur

C’est quoi une clé DBAN ? Un petit lien n’aurait pas été de trop.

> [@Iutech](#):
>
> Ou bien il y a une meilleure méthode pour installer l’ISO sur la clé ?

Dédé est ton ami. J’avais vu quelque part qu’un développeur DEbian avait créé un logiciel pour être sûr de ne pas se tromper de périphérique quand on veut mettre une ISO sur une clé USB. Malheureusement je n’arrive pas à retrouver le nom.

Cordialement,  
Regards,  
Mit freundlichen Grüßen,  
مع تحياتي الخالصة

* * *

F. Petitjean  
Ingénieur civil du Génie Maritime.

« On ne perd pas son temps en aiguisant ses outils. »  
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 24, 2021, 7:18 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/4 "2021-09-24T07:18:51Z")

</div>

> [@ylag](#):
>
> Après l’utilisation de dd, Il faut recréer une table de partition et une nouvelle partition sur la clé pour pouvoir la réutiliser comme périphérique de stockage

Là je veux juste pouvoir booter sur [Daris’ Boot And Nuke](https://dban.org/)…  
J’avais créé une clé bootable CentOS (et je crois une debian aussi ?) juste avec un dd de l’ISO, mais on m’a dit effectivement que pour une [ISO prévue pour Windows](https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_i586.iso/download) ça pouvait ne pas marcher.

Il y aurait aussi une manip à faire avec Gparted dans ce cas ?  
Laquelle ?

Le problème de Ventoy est qu’il ajoute une étape au boot, c’est la clé d’un collègue (enfin, les deux clés) que j’ai effacé par erreur, je voudrais les lui rendre aussi simple d’utilisation qu’elles l’étaient au départ.

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 24, 2021, 7:20 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/5 "2021-09-24T07:20:24Z")

</div>

> [@littlejohn75](#):
>
> Dédé est ton ami.

Oui mais comme dit plus haut ça marche pas dans mon cas (la clé créée avec un dd de l’ISO ne boote pas, je viens de retester).  
Ou bien ce serait l’ISO qui serait pas bonne ?  
Pourtant récupérée sur le site officiel : [https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0\_i586.iso/download](https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_i586.iso/download) (lien trouvé sur le site [dban.org](http://dban.org)).

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 24, 2021, 8:12 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/6 "2021-09-24T08:12:29Z")

</div>

Je viens de tester l’ISO avec KVM, elle est bonne.  
C’est donc bien le dd sur la clé qui n’est pas suffisant pour rendre la clé bootable.

---

<div class="post-metadata">

**Author:** ![ylag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/3bc359/32.png) [@ylag](https://www.debian-fr.org/u/ylag)\
**Post date:** [Septembre 24, 2021, 12:09 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/7 "2021-09-24T12:09:51Z")

</div>

Bonjour,

> [@Iutech](#):
>
> Ou bien ce serait l’ISO qui serait pas bonne ?  
> Pourtant récupérée sur le site officiel : [Download Darik’s Boot and Nuke from SourceForge.net](https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_i586.iso/download) (lien trouvé sur le site [dban.org](http://dban.org)).

L’so est bonne, mais je crois que ce n’est pas un fichier iso hybride du type que l’utilitaire Ventoy puisse lancer,  
Désolé pour la fausse piste, si c’est le cas…

A+

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 27, 2021, 11:06 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/8 "2021-09-27T11:06:22Z")

</div>

Alors en fait en la mettant sur Ventoy, ça marche.  
Mais toujours pas avec un dd.  
Je pige pas…

---

<div class="post-metadata">

**Author:** ![ylag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/3bc359/32.png) [@ylag](https://www.debian-fr.org/u/ylag)\
**Post date:** [Septembre 27, 2021, 2:34 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/9 "2021-09-27T14:34:34Z")

</div>

Bonjour,

> [@Iutech](#):
>
> Alors en fait en la mettant sur Ventoy, ça marche.  
> Mais toujours pas avec un dd.

Faudrait voir ta commande **dd** complète pour se faire une idée de ce qui pourrait clocher ?

Par exemple, chez-moi, j’ai téléchargé l’iso _dban-2.3.0\_i586.iso_ dans mon dossier  
/home/$USER/Téléchargements.

Brancher la clé que tu utiliseras pour y graver l’iso et déterminer avec une commande du genre de _lsblk_ quel est son identifiant de périphérique.  
Pour fin d’exemple, supposons que la clé soit reconnue comme étant le périphérique _sdc_ avec une partition nommée _sdc1_.

On commnece par démonter un éventuel système de fichiers sur sdc1 :

`udisksctl unmount -b /dev/sdc1`

On passe ensuite à la création de la clé dban avec la commande **dd** :

```plaintext
sudo dd if=/home/$USER/Téléchargements/dban-2.3.0_i586.iso of=/dev/sdc bs=4M && sync

```

…où la variable $USER représente le nom d’utilisateur de la session en cours.  
**Attention** à bien identifier la clé avant de lancer **dd** , sinon destruction assurée du contenu du périphérique ciblé !

En espérant que ça puisse t’être utile ?

A+

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 28, 2021, 2:03 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/10 "2021-09-28T14:03:55Z")

</div>

J’avoue que je n’ai pas pensé à démonter sdc1, faudra que je réessaye…  
Mais sur la clé il y a bien tous les répertoires de dban en tous cas.

Mon dd n’avait pas de bs ni de && sync, est-ce que cela peut jouer ?  
L’option block size je comprends ce qu’elle fait mais le && sync pas vraiment.

---

<div class="post-metadata">

**Author:** ![anon29980398](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/f4b2a3/32.png) [@anon29980398](https://www.debian-fr.org/u/anon29980398)\
**Post date:** [Septembre 28, 2021, 3:27 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/11 "2021-09-28T15:27:07Z")

</div>

Bonjour

S’il n’y a pas le `&& sync`  
alors la commande `dd` va rendre le prompt dès qu’elle aura bien terminé son travail,  
ce qui pourrait laisser penser que la copie est terminée,

… mais en fait, le système n’aura peut-être pas encore fini de vider les tampons d’entrée/sortie,  
ce qui fait que la copie sur la cible n’est pas encore réellement terminée.

Par contre, avec le `&& sync` final,  
dès que la commande `dd` a terminé sa copie et s’il n’y a pas eu d’erreur retournée par `dd`  
alors la commande `sync` va vider tous les tampons d’entrée/sortie qui n’auraient pas encore fini d’être transférés, et c’est seulement quand tout aura été copié que le prompt s’affichera.

* * *

Voir la page man de la commande `sync`

```nohighlight
man sync

```

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 29, 2021, 7:46 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/12 "2021-09-29T07:46:06Z")

</div>

> [@ylag](#):
>
> udisksctl unmount -b /dev/sdc1

Testé tes commandes, ça ne change rien, la clé n’est toujours pas bootable.

---

<div class="post-metadata">

**Author:** ![ylag](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/y/3bc359/32.png) [@ylag](https://www.debian-fr.org/u/ylag)\
**Post date:** [Septembre 29, 2021, 10:12 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/13 "2021-09-29T10:12:17Z")

</div>

Bonjour,

Est-tu certain que ta clé est bien identifiée comme étant sdc, avec une partition sdc1 ?  
C’était seulement à titre d’exemple, il faut le déterminer et ajuster en conséquence avant de lancer la commande…

A+

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Septembre 29, 2021, 1:49 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/14 "2021-09-29T13:49:21Z")

</div>

Non, c’était sdb (et j’ai bien sûr fait un dd vers sdb comme le unmount avant) mais je n’ai pas vu de partition sdb1 (lsblk me montrait seulement sdb).

---

<div class="post-metadata">

**Author:** ![Iutech](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/i/67e7ee/32.png) [@Iutech](https://www.debian-fr.org/u/Iutech)\
**Post date:** [Mai 18, 2022, 9:27 UTC](https://www.debian-fr.org/t/woeusb-sur-bullseye/85396/15 "2022-05-18T09:27:00Z")

</div>

J’ai eu le même problème avec une ISO windows10 32 bits, un dd ne rend pas la clé bootable (enfin ça boote mais y’ juste un curseur clignotant, quoi) alors que Rufus (utilisé par un collègue windowsien mais gentil quand même) avec la même ISO boote sans problèmes…