Je cherche le moyen de faire un système sur clé usb de façon à pouvoir
installer (upgrader) ma mdk en 10.0 sur mon portable qui n'a pas de
lecteur de disquette.
J'avais réussi sans aucun problème pour la mdk 9.1 dont le boot tenait
sur 1 disquette, par un :
dd if=network.img of=/dev/sda1
Mais maintenant qu'il me faut 2 disquettes, comment faire ?
De plus, je ne veux pas sacrifier ma clé usb 256 à ça, et j'ai donc
choisi de la partitionner.
J'ai donc fait 5Mo (fat16) + 251Mo(fat32) en me disant que je pourrais
mettre le contenu des 2 disquettes sur la première partition, mais
comment ?
Si j'utilise dd, ben je ne peux plus mettre la deuxième évidemment.
Si je place manuellement le contenu des 2 disquettes, ben ça ne boote pas.
J'ai éventuellement pensé à mettre 2 partition de 1.4Mo au lieu des
5Mo, et mettre chaque image de disquette sur l'une, mais j'imagine que la
procédure d'install n'ira jamais chercher sur la deuxième partition (non
testé).
Certes, je pourrais faire l'install avec les CD, mais ce n'est pas mon
choix.
Si vous avez une astuce à me proposer, je suis preneur.
Merci d'avance.
Une question peut-être idiote, ça fait quelle différence, au niveau du résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture de la fin d'un CD-ROM n'est pas fiable (mais les ISO ont toujours du remplissage à la fin pour compenser).
Youri wrote in message
<414d7574$0$15748$7a628cd7@news.club-internet.fr>:
Une question peut-être idiote, ça fait quelle différence, au niveau du
résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture
de la fin d'un CD-ROM n'est pas fiable (mais les ISO ont toujours du
remplissage à la fin pour compenser).
Une question peut-être idiote, ça fait quelle différence, au niveau du résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture de la fin d'un CD-ROM n'est pas fiable (mais les ISO ont toujours du remplissage à la fin pour compenser).
Christophe PEREZ
Le Fri, 17 Sep 2004 08:43:28 -0400, Christophe PEREZ a écrit:
Une idée ?
euh... même pas une ? Est-ce le genre de cas où je doive installer un bootloader ? Lilo conviendrai ? avec la config qui va bien pour qu'il boote sans attendre sur /dev/sda1 ? Faut déjà que je vérifie que la clé est reconnue comme /dev/sda lors du boot.
-- Christophe PEREZ Écrivez moi sans _faute !
Le Fri, 17 Sep 2004 08:43:28 -0400, Christophe PEREZ a écrit:
Une idée ?
euh... même pas une ?
Est-ce le genre de cas où je doive installer un bootloader ?
Lilo conviendrai ? avec la config qui va bien pour qu'il boote sans
attendre sur /dev/sda1 ?
Faut déjà que je vérifie que la clé est reconnue comme /dev/sda lors
du boot.
Le Fri, 17 Sep 2004 08:43:28 -0400, Christophe PEREZ a écrit:
Une idée ?
euh... même pas une ? Est-ce le genre de cas où je doive installer un bootloader ? Lilo conviendrai ? avec la config qui va bien pour qu'il boote sans attendre sur /dev/sda1 ? Faut déjà que je vérifie que la clé est reconnue comme /dev/sda lors du boot.
-- Christophe PEREZ Écrivez moi sans _faute !
no_spam
On Sun, 19 Sep 2004 14:48:38 +0000, Nicolas George wrote:
Youri wrote in message <414d7574$0$15748$:
Une question peut-être idiote, ça fait quelle différence, au niveau du résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture de la fin d'un CD-ROM n'est pas fiable
Hein ? J'aimerai une explication, car à ma connaissance, les systèmes d'écriture, de lecture, etc... sont les mêmes au début et à la fin du CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
(mais les ISO ont toujours du remplissage à la fin pour compenser).
? Il y a du remplissage à la fin: - pour aligner sur 2048 octets - eventuellement pour remplir l'espace vide si la taille totale des données est moins grande que celle du CD. C'est souvent le cas, mais rien n'interdit d'optimiser le remplissage du CD et de l'utiliser jusqu'au dernier octet.
On Sun, 19 Sep 2004 14:48:38 +0000, Nicolas George wrote:
Youri wrote in message
<414d7574$0$15748$7a628cd7@news.club-internet.fr>:
Une question peut-être idiote, ça fait quelle différence, au niveau du
résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture
de la fin d'un CD-ROM n'est pas fiable
Hein ?
J'aimerai une explication, car à ma connaissance, les systèmes
d'écriture, de lecture, etc... sont les mêmes au début et à la fin du
CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est
pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
(mais les ISO ont toujours du
remplissage à la fin pour compenser).
?
Il y a du remplissage à la fin:
- pour aligner sur 2048 octets
- eventuellement pour remplir l'espace vide si la taille totale des
données est moins grande que celle du CD. C'est souvent le cas, mais rien
n'interdit d'optimiser le remplissage du CD et de l'utiliser jusqu'au
dernier octet.
On Sun, 19 Sep 2004 14:48:38 +0000, Nicolas George wrote:
Youri wrote in message <414d7574$0$15748$:
Une question peut-être idiote, ça fait quelle différence, au niveau du résultat sur la clé USB, par rapport à 'dd if=boot.iso of=/dev/sda' ?
Aucune, si ce n'est qu'il manquera la fin de l'ISO, parce que la lecture de la fin d'un CD-ROM n'est pas fiable
Hein ? J'aimerai une explication, car à ma connaissance, les systèmes d'écriture, de lecture, etc... sont les mêmes au début et à la fin du CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
(mais les ISO ont toujours du remplissage à la fin pour compenser).
? Il y a du remplissage à la fin: - pour aligner sur 2048 octets - eventuellement pour remplir l'espace vide si la taille totale des données est moins grande que celle du CD. C'est souvent le cas, mais rien n'interdit d'optimiser le remplissage du CD et de l'utiliser jusqu'au dernier octet.
Nicolas George
no_spam wrote in message :
J'aimerai une explication, car à ma connaissance, les systèmes d'écriture, de lecture, etc... sont les mêmes au début et à la fin du CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
Sur la partie non gravée d'un CD, il n'y a rien à lire pour la tête de lecture, qui ne peut ainsi pas se synchroniser. Au bout de la partie gravée, il y a de la partie non-gravée, ce qui provoque parfois des problèmes de lecture, surtout (mais pas seulement) quand le read-ahead est activé (ce qui est le défaut).
Pour t'en convaincre, la prochaine fois que tu viens de graver un CD-R, essaie simplement ceci :
Tu verras que le résultat est de quelques secteurs plus petit pour /dev/cdrom que pour le fichier ISO d'origine.
Il y a du remplissage à la fin: - pour aligner sur 2048 octets
C'est inutile, car tous les fichiers sont déjà complétés à 2048 octets.
- eventuellement pour remplir l'espace vide si la taille totale des données est moins grande que celle du CD.
Ça ne veut rien dire, il n'y a pas de taille du CD, tout ce qu'il y a, c'est une certaine surface dotée de pigment photosensible capable de recevoir de la gravure. Si tu graves une image ISO de 2 Mo sur le CD, tu auras bien 2 Mo en tout et pour tout. D'ailleurs, on voit bien, sur un CD-R qui n'est pas complètement saturé, où s'arrête la partie gravée, c'est une couleur légèrement différente.
Mais il y a autre chose. Laisse-moi citer mkisofs(1) :
-pad Pad the end of the whole image by 150 sectors (300 kB). [...]
To avoid problems with I/O error on the last file on the filesystem, the -pad option has been made the default.
no_spam wrote in message <pan.2004.09.19.18.42.07.916588@magic.fr>:
J'aimerai une explication, car à ma connaissance, les systèmes
d'écriture, de lecture, etc... sont les mêmes au début et à la fin du
CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est
pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
Sur la partie non gravée d'un CD, il n'y a rien à lire pour la tête de
lecture, qui ne peut ainsi pas se synchroniser. Au bout de la partie
gravée, il y a de la partie non-gravée, ce qui provoque parfois des
problèmes de lecture, surtout (mais pas seulement) quand le read-ahead
est activé (ce qui est le défaut).
Pour t'en convaincre, la prochaine fois que tu viens de graver un CD-R,
essaie simplement ceci :
Tu verras que le résultat est de quelques secteurs plus petit pour
/dev/cdrom que pour le fichier ISO d'origine.
Il y a du remplissage à la fin:
- pour aligner sur 2048 octets
C'est inutile, car tous les fichiers sont déjà complétés à 2048 octets.
- eventuellement pour remplir l'espace vide si la taille totale des
données est moins grande que celle du CD.
Ça ne veut rien dire, il n'y a pas de taille du CD, tout ce qu'il y a,
c'est une certaine surface dotée de pigment photosensible capable de
recevoir de la gravure. Si tu graves une image ISO de 2 Mo sur le CD, tu
auras bien 2 Mo en tout et pour tout. D'ailleurs, on voit bien, sur un
CD-R qui n'est pas complètement saturé, où s'arrête la partie gravée,
c'est une couleur légèrement différente.
Mais il y a autre chose. Laisse-moi citer mkisofs(1) :
-pad Pad the end of the whole image by 150 sectors (300 kB). [...]
To avoid problems with I/O error on the last file on the
filesystem, the -pad option has been made the default.
J'aimerai une explication, car à ma connaissance, les systèmes d'écriture, de lecture, etc... sont les mêmes au début et à la fin du CD... Si la lecture de la fin n'est pas fiable, celle du début ne l'est pas plus, à mon sens, ce qui rend les CD inutilisables. Or ils marchent...
Sur la partie non gravée d'un CD, il n'y a rien à lire pour la tête de lecture, qui ne peut ainsi pas se synchroniser. Au bout de la partie gravée, il y a de la partie non-gravée, ce qui provoque parfois des problèmes de lecture, surtout (mais pas seulement) quand le read-ahead est activé (ce qui est le défaut).
Pour t'en convaincre, la prochaine fois que tu viens de graver un CD-R, essaie simplement ceci :
Tu verras que le résultat est de quelques secteurs plus petit pour /dev/cdrom que pour le fichier ISO d'origine.
Il y a du remplissage à la fin: - pour aligner sur 2048 octets
C'est inutile, car tous les fichiers sont déjà complétés à 2048 octets.
- eventuellement pour remplir l'espace vide si la taille totale des données est moins grande que celle du CD.
Ça ne veut rien dire, il n'y a pas de taille du CD, tout ce qu'il y a, c'est une certaine surface dotée de pigment photosensible capable de recevoir de la gravure. Si tu graves une image ISO de 2 Mo sur le CD, tu auras bien 2 Mo en tout et pour tout. D'ailleurs, on voit bien, sur un CD-R qui n'est pas complètement saturé, où s'arrête la partie gravée, c'est une couleur légèrement différente.
Mais il y a autre chose. Laisse-moi citer mkisofs(1) :
-pad Pad the end of the whole image by 150 sectors (300 kB). [...]
To avoid problems with I/O error on the last file on the filesystem, the -pad option has been made the default.
