Debian 32 bits

Bonjour.
Un partenaire local se voit proposer 3 eeePC 32 bits, qu’il souhaite utiliser pour des formations pour débutants, notamment du fait de leur faible encombrement.
Rien n’est décidé mais il semble accepter l’idée de passer une partie de son parc sous Linux (même si pour l’instant c’est quand même un échec cuisant).

Il y a quelque chose de particulier à faire pour installer un Debian 32 bits ?
(à part récupérer la bonne ISO bien sûr)

Il faut une clé USB dédiée ou simplement mettre l’ISO sur une clé Ventoy suffit ?

Bonjour
Quel type de formation ?
Ces machines là sont trop faibles en ressources, souvent avec 1 Go de RAM seulement : ça sera très lent avec un navigateur web.

Non rien de particulier tu crées une clé bootable comme tu as l’habitude de faire.
Ventoy je ne l’utilise pas alors je sais pas.

La bonne vieille commande dd de Linux devrait faire l’affaire:

dd if=/home/vincent/mon_iso of=/dev/sdx

Où x est à remplacer par la lettre correspondant à ta clef USB. ATTENTION !!!, toute mauvaise lettre est susceptible d’effacer le mauvais support. Bien évidemment le chemin et le nom de l’image donnés sont à remplacer.

D’expérience, dd est très lent si on ne spécifie pas une taille de bloc d’au moins 4096. Le manuel d’installation recommande d’utiliser la commande cp qui est plus simple et marche aussi bien.
Ventoy devrait marcher aussi.

D’accord avec la réserve concernant la performance de ces machines.

1 J'aime

dd signifie « data dump » tandis que cp fait référence à « copy » de fichiers.
Il est donc préférable de faire appel à la commande dd si l’on souhaite mettre en avant le fait que l’on fait abstraction à la structure de fichiers mais pas à la structure du support physique.

Je réserve l’usage de cp à la simple copie de fichiers et de dossiers tandis que j’utilise dd au remplissage d’une zone d’un support à partir d’un endroit précis. Il est clair que pour ce genre d’opération dd et cp sont aussi simples. La commande dd est adaptée pour le stockage à un emplacement physique précis sur un support, notamment avec ses options d’offsets. Il est bon de connaître dd car lorsqu’on travail au niveau du boot, des partitions, la commande cp peut vite montrer ses limites.
Si le manuel emploi cp, c’est uniquement pour le débutant. Si l’on connaît déjà la commande cp, ça vaut la peine de se pencher sur dd particulièrement bien approprié pour la création et la restauration de « snapshots » et aussi très simple d’utilisation.
En ce qui concerne la vitesse, c’est lié au type de support et à sa structure physique, notamment à la taille de sa mémoire cache. Je n’ai pas rencontré de problème de vitesse avec dd pour des tailles de blocs de moins de 4096 octets avec des disques durs classiques mais je ne doute pas un instant que cela puisse se produire avec des SSD ou des clefs USB au regard des technologies mises en œuvre. Les tailles de blocs doivent être des multiples de puissance de 2: pour des raisons de performance, ne pas descendre en dessous de 512 octets correspondant à la taille d’un secteur.

Test d’écriture sur un disque dur SATA :

# dd of=/dev/vg/lv if=/dev/zero
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 62,0877 s, 17,3 MB/s

# dd of=/dev/vg/lv if=/dev/zero bs=4096
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 17,4417 s, 61,6 MB/s

Spectaculaire.

Dans le deuxième cas bs est 8 fois plus important car par défaut bs est à 512. Avec 8 fois moins de cycle de démarrage d’écriture on arrive à environ une vitesse 3 fois plus rapide. Cela s’explique par le temps considérable qu’il faut pour une tête à se positionner au bon endroit. J’ai souvenir qu’en gros les déplacements mécaniques de tête sont 1000 fois plus lents que la vitesse d’enregistrement magnétique. Pour les SSD et les clefs USB, le goulot d’étranglement est du côté de la taille de la mémoire cache, de la qualité du microcode, du type de protocole USB . Comme il n’y a pas de pièces mécaniques en mouvement, on arrive à d’excellents taux de transferts

Non, le temps d’accès n’intervient que marginalement en écriture séquentielle.

Le temps d’accès et le débit s’expriment dans des unités différentes (temps et vitesse), on ne peut pas les comparer.

Non, le temps d’accès n’intervient que marginalement en écriture séquentielle.

Sauf que l’écriture séquentielle est interrompue et doit être resynchronisée à chaque fin de bs !

Le temps d’accès et le débit s’expriment dans des unités différentes (temps et vitesse)

On peut très facilement les comparer, il te suffit d’exprimer le déplacement mécanique par sa vitesse et non pas par son temps d’accès si cela te pose problème

Qu’entends-tu par « resynchronisée » ?

La vitesse de déplacement en m/s ? Ça n’aurait toujours aucun sens de la comparer avec une vitesse d’écriture en octets/s.

Sauf que pour chaque m correspond un certain nombre d’octets, bien faible si on le compare à ce que peut sortir une tête d’écriture en une fraction de seconde: la mécanique étant extrêmement lente comparée à la propagation de l’électricité ou de la lumière pour faire simple. Cela trouve ainsi pleinement un sens que de comparer une vitesse de déplacement avec une vitesse d’écriture car on est dans des proportions très différentes l’une de l’autre. Je sais que pour des raisons pédagogiques ou de rigueur on veut sur les banc d’école une rigueur dans les unités mais c’est une bêtise monumentale lorsqu’un paramètre est négligeable par rapport à l’autre car cela empêche alors toute simplification et freine la réflexion, en tout cas en physique. Et puis avec les années et l’expérience on arrive à comparer aisément des choux avec des carottes ce qui serait un non sens en primaire, voire en secondaire, quand l’un est négligeable sur l’autre ! Heureusement que lorsqu’on câble des composants on est pas sans arrêt à faire appel aux équations de Maxwell ! Pourtant cela ne choque personne de travailler avec des expressions fausses et qui donne un résultat juste ou de travailler avec des abaques qui peuvent être incompréhensibles pour certains…

Pour la synchro regarde du côté du principe de fonctionnement d’un lecteur de disquette et de son index optique et regarde ce qui se passe si tu dois par exemple enregistrer sur le secteur physique 1 puis sur le secteur 3 et tu comprendras: il faudra très probablement refaire un tour de piste pour se repositionner correctement ! Sur les DD magnétiques, c’est le même principe mais l’index n’est pas optique mais magnétique en début de chaque piste.

Si je fais un dd vers ma clé Ventoy, je crois qu’elle va pas aimer…
De ce que je comprends Emmabuntu utilise la même clé Ventoy pour ses ISO 32 bits et les 64 bits donc ça devrait passer j’imagine de simplement copier l’ISO 32 bits vers une Ventoy classique.

(Ventoy c’est très bien ! je recommande vivement)

@LibreFaso, pourquoi une clef USB n’aimerait-elle pas dd ?
Ventoy est une application. Avec dd ou cp, il n’y a rien besoin d’installer.