Installation de Debian par USB, l’ordinateur se fige
19 réponses
Alban Gruin
Bonsoir =C3=A0 tous,
j=E2=80=99essaie d=E2=80=99installer Debian 9.6 sur une machine datant d=E2=
=80=99il y a une dizaine=20
d=E2=80=99ann=C3=A9es =C3=A0 l=E2=80=99aide d=E2=80=99une clef USB. Mais l=
=E2=80=99ordinateur se fige quasi-
instantan=C3=A9ment lorsque je connecte une clef avec un installateur de De=
bian=20
tant qu=E2=80=99il n=E2=80=99a pas d=C3=A9marr=C3=A9 un syst=C3=A8me d=E2=
=80=99exploitation. J=E2=80=99ai essay=C3=A9 avec=20
plusieurs installateurs, m=C3=AAme r=C3=A9sultat :
J=E2=80=99ai essay=C3=A9 d=E2=80=99utiliser deux clef, une en USB 3.0, une =
autre en USB 2.0.
J=E2=80=99ai aussi essay=C3=A9 de copier un installateur de FreeBSD 11.2 i3=
86, et celui-ci=20
ne plante pas (mais il n=E2=80=99arrive pas =C3=A0 localiser le noyau, appa=
remment).
J=E2=80=99ai un peu l=E2=80=99impression d=E2=80=99=C3=AAtre =C3=A0 court d=
e solutions, pourtant il me semble=20
avoir r=C3=A9ussi plusieurs installations via clef USB sur cette machine. =
Peut-
=C3=AAtre que certains d=E2=80=99entre vous savent d=E2=80=99o=C3=B9 =C3=A7=
a peut venir ?
La carte m=C3=A8re de la machine en question est une Gigabyte GA-73PVM-S2H.
Le Fri, Nov 30, 2018 at 12:06:14PM +0100, Eric Degenetais a écrit :
De mémoire, ce n'est pas une bonne idée de faire un dd brut sur un device monté, donc la paire mount/umount n'est impliquée dans cette opération.
A bah oui, je suis con ... Je serais étonné que les écriture soit asynchrone sur un block cela dit.
hamster
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
En effet, la destination n'est pas un système de fichiers. Par contre la destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne contiens pas de contradiction. Sous unix tout est fichier. Ma phrase s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
le système fichier racine.
Raté. /dev est un système de fichiers temporaire en mémoire distinct de la racine. $ df -hT /dev Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur udev devtmpfs 10M 0 10M 0% /dev
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un système de fichiers, mais il est bien dans un système de fichiers.
La destination, c'est un fichier, le fichier /dev/sdc dans ce cas.
Non. /dev/sdc est un fichier spécial qui représente un périphérique bloc, mais n'est pas le périphérique bloc. Quand on écrit dans /dev/sdc, on écrit sur le disque qu'il représente, pas dans le système de fichiers qui contient /dev. Facile à démontrer en remontant /dev en lecture seule par exemple : on peut encore écrire dans /dev/sdc.
Quand on écrit dans ce fichier, les données sont mises dans le cache du système de fichiers racine et sync permet de vider ce cache.
Non puisqu'on n'écrit pas dans un système de fichiers.
On peut s'amuser a faire rien que la commande dd. Ca travaille un moment, puis ca rend le prompt. A ce moment la, on fait a la main la commande sync, et on voit que de nouveau ca travaille un moment. C'est le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute sync, ça ne clignote pas plus. Par contre l'écriture n'est pas forcément finie lorsque dd rend la main. On le voit bien avec le clignotement qui continue. Il y a donc un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix. Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle
toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne
contiens pas de contradiction. Sous unix tout est fichier. Ma phrase
s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
le système fichier racine.
Raté. /dev est un système de fichiers temporaire en mémoire distinct
de la racine.
$ df -hT /dev
Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur
udev devtmpfs 10M 0 10M 0% /dev
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un
système de fichiers, mais il est bien dans un système de fichiers.
La destination, c'est un fichier, le fichier /dev/sdc dans ce cas.
Non. /dev/sdc est un fichier spécial qui représente un périphérique
bloc, mais n'est pas le périphérique bloc. Quand on écrit dans
/dev/sdc, on écrit sur le disque qu'il représente, pas dans le système
de fichiers qui contient /dev. Facile à démontrer en remontant /dev en
lecture seule par exemple : on peut encore écrire dans /dev/sdc.
Quand
on écrit dans ce fichier, les données sont mises dans le cache du
système de fichiers racine et sync permet de vider ce cache.
Non puisqu'on n'écrit pas dans un système de fichiers.
On peut s'amuser a faire rien que la commande dd. Ca travaille un
moment, puis ca rend le prompt. A ce moment la, on fait a la main la
commande sync, et on voit que de nouveau ca travaille un moment. C'est
le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais
justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes
un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute
sync, ça ne clignote pas plus.
Par contre l'écriture n'est pas forcément finie lorsque dd rend la
main. On le voit bien avec le clignotement qui continue. Il y a donc
un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?
En effet, la destination n'est pas un système de fichiers. Par contre la destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne contiens pas de contradiction. Sous unix tout est fichier. Ma phrase s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
le système fichier racine.
Raté. /dev est un système de fichiers temporaire en mémoire distinct de la racine. $ df -hT /dev Sys. de fichiers Type Taille Utilisé Dispo Uti% Monté sur udev devtmpfs 10M 0 10M 0% /dev
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un système de fichiers, mais il est bien dans un système de fichiers.
La destination, c'est un fichier, le fichier /dev/sdc dans ce cas.
Non. /dev/sdc est un fichier spécial qui représente un périphérique bloc, mais n'est pas le périphérique bloc. Quand on écrit dans /dev/sdc, on écrit sur le disque qu'il représente, pas dans le système de fichiers qui contient /dev. Facile à démontrer en remontant /dev en lecture seule par exemple : on peut encore écrire dans /dev/sdc.
Quand on écrit dans ce fichier, les données sont mises dans le cache du système de fichiers racine et sync permet de vider ce cache.
Non puisqu'on n'écrit pas dans un système de fichiers.
On peut s'amuser a faire rien que la commande dd. Ca travaille un moment, puis ca rend le prompt. A ce moment la, on fait a la main la commande sync, et on voit que de nouveau ca travaille un moment. C'est le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute sync, ça ne clignote pas plus. Par contre l'écriture n'est pas forcément finie lorsque dd rend la main. On le voit bien avec le clignotement qui continue. Il y a donc un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix. Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Pascal Hambourg
Le 30/11/2018 à 22:28, hamster a écrit :
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
En effet, la destination n'est pas un système de fichiers. Par contre la destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne contiens pas de contradiction.
Ne pas confondre un fichier spécial de périphérique avec le périphérique lui-même ou avec un fichier normal. Quand on crée ou écrit dans un fichier normal comme ton toto, on écrit dans le système de fichiers qui le contient. Quand on écrit dans un périphérique, on n'écrit pas dans le système de fichiers qui contient le fichier spécial de périphérique.
Sous unix tout est fichier.
Tout ou presque (pas les interfaces réseau) est traité comme un fichier, mais tout n'est pas fichier.
Ma phrase s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
Je ne vois pas le rapport avec le fait qu'un périphérique bloc n'est pas dans un système de fichiers.
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un système de fichiers, mais il est bien dans un système de fichiers.
Non, c'est le fichier spécial qui est dans le système de fichiers. Pas le périphérique. Un périphérique bloc est défini par ses nombres majeur et mineur. Un fichier spécial de périphérique est juste un descripteur qui contient ces deux numéros, visibles avec ls -l : $ ls -l /dev/sdb brw-rw---- 1 root disk 8, 16 nov. 30 23:36 /dev/sdb majeur=8, mineur Si je crée un autre fichier spécial de périphérique bloc contenant les mêmes nombres avec mknod, c'est un fichier différent (inodes différents, rien à voir les liens durs qui pointent vers un même inode) mais le même périphérique.
On peut s'amuser a faire rien que la commande dd. Ca travaille un moment, puis ca rend le prompt. A ce moment la, on fait a la main la commande sync, et on voit que de nouveau ca travaille un moment. C'est le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute sync, ça ne clignote pas plus. Par contre l'écriture n'est pas forcément finie lorsque dd rend la main. On le voit bien avec le clignotement qui continue. Il y a donc un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Pas besoin de connaître les subtilités. Il me suffit d'observer mon système et ce que je constate ne colle pas avec ce que tu écris.
Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter pendant plusieurs secondes après que sync a rendu la main. Chronométrée avec time, l'exécution de sync dure environ 0,1 s. Est-ce que tu as au moins fait l'essai ?
Le 30/11/2018 à 22:28, hamster a écrit :
Le 30/11/2018 à 22:03, Pascal Hambourg a écrit :
En effet, la destination n'est pas un système de fichiers. Par contre la
destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle
toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne
contiens pas de contradiction.
Ne pas confondre un fichier spécial de périphérique avec le périphérique
lui-même ou avec un fichier normal. Quand on crée ou écrit dans un
fichier normal comme ton toto, on écrit dans le système de fichiers qui
le contient. Quand on écrit dans un périphérique, on n'écrit pas dans le
système de fichiers qui contient le fichier spécial de périphérique.
Sous unix tout est fichier.
Tout ou presque (pas les interfaces réseau) est traité comme un fichier,
mais tout n'est pas fichier.
Ma phrase
s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
Je ne vois pas le rapport avec le fait qu'un périphérique bloc n'est pas
dans un système de fichiers.
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un
système de fichiers, mais il est bien dans un système de fichiers.
Non, c'est le fichier spécial qui est dans le système de fichiers. Pas
le périphérique. Un périphérique bloc est défini par ses nombres majeur
et mineur. Un fichier spécial de périphérique est juste un descripteur
qui contient ces deux numéros, visibles avec ls -l :
$ ls -l /dev/sdb
brw-rw---- 1 root disk 8, 16 nov. 30 23:36 /dev/sdb
majeur=8, mineur
Si je crée un autre fichier spécial de périphérique bloc contenant les
mêmes nombres avec mknod, c'est un fichier différent (inodes différents,
rien à voir les liens durs qui pointent vers un même inode) mais le même
périphérique.
On peut s'amuser a faire rien que la commande dd. Ca travaille un
moment, puis ca rend le prompt. A ce moment la, on fait a la main la
commande sync, et on voit que de nouveau ca travaille un moment. C'est
le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais
justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes
un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute
sync, ça ne clignote pas plus.
Par contre l'écriture n'est pas forcément finie lorsque dd rend la
main. On le voit bien avec le clignotement qui continue. Il y a donc
un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Pas besoin de connaître les subtilités. Il me suffit d'observer mon
système et ce que je constate ne colle pas avec ce que tu écris.
Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter
pendant plusieurs secondes après que sync a rendu la main. Chronométrée
avec time, l'exécution de sync dure environ 0,1 s.
En effet, la destination n'est pas un système de fichiers. Par contre la destination est dans un système de fichiers :
Tu n'as pas l'impression de te contredire dans la même phrase ?
Heu non. Fais donc touch toto, tu obtiendra un fichier qui s'appelle toto. Applique ma phrase a ce fichier, tu verra qu'elle est valide et ne contiens pas de contradiction.
Ne pas confondre un fichier spécial de périphérique avec le périphérique lui-même ou avec un fichier normal. Quand on crée ou écrit dans un fichier normal comme ton toto, on écrit dans le système de fichiers qui le contient. Quand on écrit dans un périphérique, on n'écrit pas dans le système de fichiers qui contient le fichier spécial de périphérique.
Sous unix tout est fichier.
Tout ou presque (pas les interfaces réseau) est traité comme un fichier, mais tout n'est pas fichier.
Ma phrase s'applique aussi bien a ce fichier "toto" qu'au fichier /dev/sdc.
Je ne vois pas le rapport avec le fait qu'un périphérique bloc n'est pas dans un système de fichiers.
OK. Et alors, qu'est-ce que ca change ? Le périphérique n'est pas un système de fichiers, mais il est bien dans un système de fichiers.
Non, c'est le fichier spécial qui est dans le système de fichiers. Pas le périphérique. Un périphérique bloc est défini par ses nombres majeur et mineur. Un fichier spécial de périphérique est juste un descripteur qui contient ces deux numéros, visibles avec ls -l : $ ls -l /dev/sdb brw-rw---- 1 root disk 8, 16 nov. 30 23:36 /dev/sdb majeur=8, mineur Si je crée un autre fichier spécial de périphérique bloc contenant les mêmes nombres avec mknod, c'est un fichier différent (inodes différents, rien à voir les liens durs qui pointent vers un même inode) mais le même périphérique.
On peut s'amuser a faire rien que la commande dd. Ca travaille un moment, puis ca rend le prompt. A ce moment la, on fait a la main la commande sync, et on voit que de nouveau ca travaille un moment. C'est le signe qu'il restait des choses a écrire sur la clef dans le cache.
Effectivement ce serait le signe si ça se passait ainsi, mais justement je ne l'ai jamais constaté avec mes clés USB qui ont toutes un voyant d'activité. Quand ça s'est arrêté de clignoter et j'exécute sync, ça ne clignote pas plus. Par contre l'écriture n'est pas forcément finie lorsque dd rend la main. On le voit bien avec le clignotement qui continue. Il y a donc un cache quelque part, mais distinct de celui sur lequel sync agit.
OK, tu connais mieux que moi les subtilités du fonctionnement d'unix.
Pas besoin de connaître les subtilités. Il me suffit d'observer mon système et ce que je constate ne colle pas avec ce que tu écris.
Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter pendant plusieurs secondes après que sync a rendu la main. Chronométrée avec time, l'exécution de sync dure environ 0,1 s. Est-ce que tu as au moins fait l'essai ?
hamster
Le 30/11/2018 à 23:45, Pascal Hambourg a écrit :
Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter pendant plusieurs secondes après que sync a rendu la main. Chronométrée avec time, l'exécution de sync dure environ 0,1 s. Est-ce que tu as au moins fait l'essai ?
Je connaissais meme pas l'existence de la commande time… J'avais trouvé (a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus ou moins synchro avec le moment ou sync rend le prompt. Une différence de quelques secondes d'accord, mais j'ai jamais vu de différences de plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros machin et que ca prend longtemps, par exemple une demi-heure, on peut très bien avoir dd qui se termine au bout d'un quart d'heure puis sync qui dure encore un quart d'heure avant de rendre la main. Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Le 30/11/2018 à 23:45, Pascal Hambourg a écrit :
Mais je persiste a trouver un avantage a sync : ca permet de savoir
quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce
que meme si le cache concerné n'est pas celui sur lequel agit sync,
cette commande ne rend pas le prompt tant que l'écriture n'est pas
finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à
clignoter pendant plusieurs secondes après que sync a rendu la main.
Chronométrée avec time, l'exécution de sync dure environ 0,1 s.
Est-ce que tu as au moins fait l'essai ?
Je connaissais meme pas l'existence de la commande time… J'avais trouvé
(a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus
ou moins synchro avec le moment ou sync rend le prompt. Une différence
de quelques secondes d'accord, mais j'ai jamais vu de différences de
plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros
machin et que ca prend longtemps, par exemple une demi-heure, on peut
très bien avoir dd qui se termine au bout d'un quart d'heure puis sync
qui dure encore un quart d'heure avant de rendre la main.
Mais alors j'ai une autre question : comment on sait quand on peut
débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Mais je persiste a trouver un avantage a sync : ca permet de savoir quand l'écriture est bien finie et qu'on peut débrancher la clef. Parce que meme si le cache concerné n'est pas celui sur lequel agit sync, cette commande ne rend pas le prompt tant que l'écriture n'est pas finie, contrairement a dd. A moins que la encore je me trompe ?
Il faut croire. Test effectué à l'instant : la clé continue à clignoter pendant plusieurs secondes après que sync a rendu la main. Chronométrée avec time, l'exécution de sync dure environ 0,1 s. Est-ce que tu as au moins fait l'essai ?
Je connaissais meme pas l'existence de la commande time… J'avais trouvé (a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus ou moins synchro avec le moment ou sync rend le prompt. Une différence de quelques secondes d'accord, mais j'ai jamais vu de différences de plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros machin et que ca prend longtemps, par exemple une demi-heure, on peut très bien avoir dd qui se termine au bout d'un quart d'heure puis sync qui dure encore un quart d'heure avant de rendre la main. Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
sTriX
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire, en ajoutant l'option status=progress à la commande dd. Bon week-end -- Gérard
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut
débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire,
en ajoutant l'option status=progress à la commande dd.
Bon week-end
--
Gérard
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire, en ajoutant l'option status=progress à la commande dd. Bon week-end -- Gérard
Pascal Hambourg
Le 01/12/2018 à 00:07, hamster a écrit :
Je connaissais meme pas l'existence de la commande time… J'avais trouvé (a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus ou moins synchro avec le moment ou sync rend le prompt. Une différence de quelques secondes d'accord, mais j'ai jamais vu de différences de plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros machin et que ca prend longtemps, par exemple une demi-heure, on peut très bien avoir dd qui se termine au bout d'un quart d'heure puis sync qui dure encore un quart d'heure avant de rendre la main.
Etrange, je n'ai jamais constaté un délai plus long que quelques secondes en écrivant une image sur une clé avec dd, quelle que soit la taille de l'image.
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Bonne question, à laquelle je n'ai pas de réponse.
Le 01/12/2018 à 00:07, hamster a écrit :
Je connaissais meme pas l'existence de la commande time… J'avais trouvé
(a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus
ou moins synchro avec le moment ou sync rend le prompt. Une différence
de quelques secondes d'accord, mais j'ai jamais vu de différences de
plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros
machin et que ca prend longtemps, par exemple une demi-heure, on peut
très bien avoir dd qui se termine au bout d'un quart d'heure puis sync
qui dure encore un quart d'heure avant de rendre la main.
Etrange, je n'ai jamais constaté un délai plus long que quelques
secondes en écrivant une image sur une clé avec dd, quelle que soit la
taille de l'image.
Mais alors j'ai une autre question : comment on sait quand on peut
débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Bonne question, à laquelle je n'ai pas de réponse.
Je connaissais meme pas l'existence de la commande time… J'avais trouvé (a l'oeil hein) que le moment ou la clef arrete de clignoter etait plus ou moins synchro avec le moment ou sync rend le prompt. Une différence de quelques secondes d'accord, mais j'ai jamais vu de différences de plusieurs minutes comme on peut le voir avec dd. Si on écrit un gros machin et que ca prend longtemps, par exemple une demi-heure, on peut très bien avoir dd qui se termine au bout d'un quart d'heure puis sync qui dure encore un quart d'heure avant de rendre la main.
Etrange, je n'ai jamais constaté un délai plus long que quelques secondes en écrivant une image sur une clé avec dd, quelle que soit la taille de l'image.
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Bonne question, à laquelle je n'ai pas de réponse.
Stephane Ascoet
Le 30/11/2018 à 10:07, hamster a écrit :
Ca c'est pas bete. Tu peux aussi la remettre complètement a zero, meme le MBR et la table de partitions, en faisant : dd bs=4M if=/dev/zero of=/dev/sdx bien sur, il faut adapter /dev/sdx avec la lettre qui correspond a ta clef. Pas la peine d'écraser ainsi toute la clef, seul le début est important pour tester le démarrage, tu laisse donc tourner quelques secondes puis tu arrete avec ctrl-C.
Bonjour, pour un arret plus propre de la procedure, il suffit d'ajouter "count=1" a la fin de la commande que tu as indique ;-) -- Cordialement, Stephane Ascoet
Le 30/11/2018 à 10:07, hamster a écrit :
Ca c'est pas bete. Tu peux aussi la remettre complètement a zero, meme
le MBR et la table de partitions, en faisant :
dd bs=4M if=/dev/zero of=/dev/sdx
bien sur, il faut adapter /dev/sdx avec la lettre qui correspond a ta clef.
Pas la peine d'écraser ainsi toute la clef, seul le début est important
pour tester le démarrage, tu laisse donc tourner quelques secondes puis
tu arrete avec ctrl-C.
Bonjour, pour un arret plus propre de la procedure, il suffit d'ajouter
"count=1" a la fin de la commande que tu as indique ;-)
--
Cordialement, Stephane Ascoet
Ca c'est pas bete. Tu peux aussi la remettre complètement a zero, meme le MBR et la table de partitions, en faisant : dd bs=4M if=/dev/zero of=/dev/sdx bien sur, il faut adapter /dev/sdx avec la lettre qui correspond a ta clef. Pas la peine d'écraser ainsi toute la clef, seul le début est important pour tester le démarrage, tu laisse donc tourner quelques secondes puis tu arrete avec ctrl-C.
Bonjour, pour un arret plus propre de la procedure, il suffit d'ajouter "count=1" a la fin de la commande que tu as indique ;-) -- Cordialement, Stephane Ascoet
hamster
Le 01/12/2018 à 19:01, sTriX a écrit :
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire, en ajoutant l'option status=progress à la commande dd.
Avec ou sans la barre de progression, la commande dd se terminera et rendra le prompt quand elle aura fini son boulot, mais ca ne permet pas de savoir si il reste des données a écrire dans un cache. Merci beaucoup pour l'astuce de status=progress que je ne connaissais pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas cette option dans le man, je me demande comment j'aurais pu faire pour la trouver moi meme ?
Le 01/12/2018 à 19:01, sTriX a écrit :
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut
débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire,
en ajoutant l'option status=progress à la commande dd.
Avec ou sans la barre de progression, la commande dd se terminera et
rendra le prompt quand elle aura fini son boulot, mais ca ne permet pas
de savoir si il reste des données a écrire dans un cache.
Merci beaucoup pour l'astuce de status=progress que je ne connaissais
pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas
cette option dans le man, je me demande comment j'aurais pu faire pour
la trouver moi meme ?
le samedi 01 décembre 2018 à 00:07 (+0100), hamster a écrit:
Mais alors j'ai une autre question : comment on sait quand on peut débrancher la clef si elle n'a pas de petite lumière qui clignotte ?
Peut être que l'affichage d'une barre de progression ferait l'affaire, en ajoutant l'option status=progress à la commande dd.
Avec ou sans la barre de progression, la commande dd se terminera et rendra le prompt quand elle aura fini son boulot, mais ca ne permet pas de savoir si il reste des données a écrire dans un cache. Merci beaucoup pour l'astuce de status=progress que je ne connaissais pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas cette option dans le man, je me demande comment j'aurais pu faire pour la trouver moi meme ?
Pascal Hambourg
Le 10/12/2018 à 18:58, hamster a écrit :
Le 01/12/2018 à 19:01, sTriX a écrit :
en ajoutant l'option status=progress à la commande dd.
(...)
Merci beaucoup pour l'astuce de status=progress que je ne connaissais pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas cette option dans le man, je me demande comment j'aurais pu faire pour la trouver moi meme ?
En consultant la page de manuel originale en anglais. La traduction française n'est pas à jour. man -L=C dd
Le 10/12/2018 à 18:58, hamster a écrit :
Le 01/12/2018 à 19:01, sTriX a écrit :
en ajoutant l'option status=progress à la commande dd.
(...)
Merci beaucoup pour l'astuce de status=progress que je ne connaissais
pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas
cette option dans le man, je me demande comment j'aurais pu faire pour
la trouver moi meme ?
En consultant la page de manuel originale en anglais. La traduction
française n'est pas à jour.
en ajoutant l'option status=progress à la commande dd.
(...)
Merci beaucoup pour l'astuce de status=progress que je ne connaissais pas et qui me sera fort utile pour d'autres cas. Vu que je ne trouve pas cette option dans le man, je me demande comment j'aurais pu faire pour la trouver moi meme ?
En consultant la page de manuel originale en anglais. La traduction française n'est pas à jour. man -L=C dd
