salut, c'est encore moi...
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
J'avoue que là je ne comprends pas ...
salut, c'est encore moi...
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
marc@marc-uzinagaz:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
J'avoue que là je ne comprends pas ...
salut, c'est encore moi...
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
J'avoue que là je ne comprends pas ...
Le Sun, 16 Mar 2008 14:53:10 +0100, markorki a écrit:salut, c'est encore moi...
Salut,
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
Il y a sans doute une erreur ici, car tu enregistres le MBR dans
le fichier "MBR-backup1" pour restaurer ce MBR à partir du fichier
"MBR-backup". Lapsus toccati ?
exact, il s'agit dans les 2 cas de MVR-backup1
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
On lit beaucoup de choses sur internet, ne pourrait-on pas avoir un
lien ?et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
en fait le sudo semble inutile dans mon cas parce que je suis sous
Le sudo n'est pas inutile, le fait que tu aie la même erreur avec et
sans n'est pas normal.
Chez moi, en user sans droits d'administration:
$ grub-install /dev/hda
/dev/hda: Not found or not a block device.
Normal puisque je n'ai pas de disque hda, mais sda:
$ grub-install /dev/sda
rm: cannot remove `/boot/grub/stage1': Permission denied
Peut être grub-install est-il suid-root ? à vérifier par
'ls -l /usr/sbin/grub-install' qui afficherait alors "-rwsr-sr-x" au lieu
de "-rwxr-xr-x":~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
Je ne connais pas l'origine de ce message. Plusieurs pistes:
* Ton disque est référencé par /dev/sda au lieu de /dev/hda (et ça n'a
rien à voir avec le SATA ou autre embrouille, la gutsy qui tourne sur
mon PC de 6 ans voit le disque maître en /dev/sda)
La commande 'mount' te dira par quel dev ton disque est piloté.
oui tout mes DD (uniquement PATA) sont vus en hdx, curieux, gutsy c'est
* Ton BIOS est foireux.
* Tu as effectivement un disque SATA, mais je n'y connais rien car je
n'en utilise pas.
non, je n'ai que des vieilleries (IDE parallèle, SCSI)
J'avoue que là je ne comprends pas ...
Moi non plus.
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
Le Sun, 16 Mar 2008 14:53:10 +0100, markorki a écrit:
salut, c'est encore moi...
Salut,
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
Il y a sans doute une erreur ici, car tu enregistres le MBR dans
le fichier "MBR-backup1" pour restaurer ce MBR à partir du fichier
"MBR-backup". Lapsus toccati ?
exact, il s'agit dans les 2 cas de MVR-backup1
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
On lit beaucoup de choses sur internet, ne pourrait-on pas avoir un
lien ?
et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
en fait le sudo semble inutile dans mon cas parce que je suis sous
Le sudo n'est pas inutile, le fait que tu aie la même erreur avec et
sans n'est pas normal.
Chez moi, en user sans droits d'administration:
$ grub-install /dev/hda
/dev/hda: Not found or not a block device.
Normal puisque je n'ai pas de disque hda, mais sda:
$ grub-install /dev/sda
rm: cannot remove `/boot/grub/stage1': Permission denied
Peut être grub-install est-il suid-root ? à vérifier par
'ls -l /usr/sbin/grub-install' qui afficherait alors "-rwsr-sr-x" au lieu
de "-rwxr-xr-x"
marc@marc-uzinagaz:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
Je ne connais pas l'origine de ce message. Plusieurs pistes:
* Ton disque est référencé par /dev/sda au lieu de /dev/hda (et ça n'a
rien à voir avec le SATA ou autre embrouille, la gutsy qui tourne sur
mon PC de 6 ans voit le disque maître en /dev/sda)
La commande 'mount' te dira par quel dev ton disque est piloté.
oui tout mes DD (uniquement PATA) sont vus en hdx, curieux, gutsy c'est
* Ton BIOS est foireux.
* Tu as effectivement un disque SATA, mais je n'y connais rien car je
n'en utilise pas.
non, je n'ai que des vieilleries (IDE parallèle, SCSI)
J'avoue que là je ne comprends pas ...
Moi non plus.
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
Le Sun, 16 Mar 2008 14:53:10 +0100, markorki a écrit:salut, c'est encore moi...
Salut,
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
toujours avec mon pb
- DD IDE prim master: DD windows 98SE, avec boot grub en tête
- ubuntu 7.10 sur le DD primary slave
ça boote sur les 2 OS, un plaisir, sauf que mon 98SE a besoin d'une
reconstitution: j'en ai une image ghost, qui me cassera le mbr ;-)
J'ai donc tenté dans un terminal :
$dd if=/dev/hda of=MBR-backup1 bsQ2 count=1
(pour une éventuelle restauration par
$dd if=MBR-backup of=/dev/hda bsQ2 count=1)
Il y a sans doute une erreur ici, car tu enregistres le MBR dans
le fichier "MBR-backup1" pour restaurer ce MBR à partir du fichier
"MBR-backup". Lapsus toccati ?
exact, il s'agit dans les 2 cas de MVR-backup1
cependant, j'ai lu sur un forum qu'en cas de repartitionnement entre
sauvegarde et restauration, la restauration casserait la table des
partitions,
On lit beaucoup de choses sur internet, ne pourrait-on pas avoir un
lien ?et qu'il était préférable de procéder comme suit après le
ghost (bon, le sudo est inutile, j'ai le même pb avec et sans):
en fait le sudo semble inutile dans mon cas parce que je suis sous
Le sudo n'est pas inutile, le fait que tu aie la même erreur avec et
sans n'est pas normal.
Chez moi, en user sans droits d'administration:
$ grub-install /dev/hda
/dev/hda: Not found or not a block device.
Normal puisque je n'ai pas de disque hda, mais sda:
$ grub-install /dev/sda
rm: cannot remove `/boot/grub/stage1': Permission denied
Peut être grub-install est-il suid-root ? à vérifier par
'ls -l /usr/sbin/grub-install' qui afficherait alors "-rwsr-sr-x" au lieu
de "-rwxr-xr-x":~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
que je réparais mon mbr simplement
Ok, sauf que j'obtiens ce message, que j'ai trouvé sur des tas de forums
également, mais correspondant en général à des situations bien
différentes de la mienne:
/dev/hda does not have any corresponding BIOS drive
Je ne connais pas l'origine de ce message. Plusieurs pistes:
* Ton disque est référencé par /dev/sda au lieu de /dev/hda (et ça n'a
rien à voir avec le SATA ou autre embrouille, la gutsy qui tourne sur
mon PC de 6 ans voit le disque maître en /dev/sda)
La commande 'mount' te dira par quel dev ton disque est piloté.
oui tout mes DD (uniquement PATA) sont vus en hdx, curieux, gutsy c'est
* Ton BIOS est foireux.
* Tu as effectivement un disque SATA, mais je n'y connais rien car je
n'en utilise pas.
non, je n'ai que des vieilleries (IDE parallèle, SCSI)
J'avoue que là je ne comprends pas ...
Moi non plus.
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
On Mon, 17 Mar 2008 00:32:38 +0100, YBM :4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
C'est réparable, mais il vaut effectivement mieux éviter.
Perso, quand je fais un truc douteux sur un disque, je note sur papier
les détails de la table de partitions.
On Mon, 17 Mar 2008 00:32:38 +0100, YBM <ybmess@nooos.fr>:
4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
C'est réparable, mais il vaut effectivement mieux éviter.
Perso, quand je fais un truc douteux sur un disque, je note sur papier
les détails de la table de partitions.
On Mon, 17 Mar 2008 00:32:38 +0100, YBM :4. la méthode de sauvegarde du MBR à coup de dd va effectivement
écraser la table des partitions... donc si elle a changé
entretemps : catastrophe...
C'est réparable, mais il vaut effectivement mieux éviter.
Perso, quand je fais un truc douteux sur un disque, je note sur papier
les détails de la table de partitions.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
pour les 4 premiers points (mais ça ne me parait pas idiot de tester des
commandes tant que je suis sur un système qui tourne sur ses propres
ressources disque: je peux réparer pas mal de conneries tant que je
n'arrête pas la bête, alors que si je casse le grub un jour de ghost, il
me faut une disquette ou une clé pour booter et réparer, avec les pb que
ça implique: un boot sur disquette part souvent en clavier qwerty, etc...),
ok, mais sur ta vision de mes pb SCSI, là pas d'accord.
L'installation débute du live-CD
Le live-Cd tourne parce que **le_BIOS** (carte mère + carte SCSI) sait
accéder au SCSI, et que l'amorce du live-CD crée un système avec le/les
fs nécessaire(s) en ram.
voici un extrait de mon post du 4/10/2007 (à l'époque c'était la 7.04,
j'espérais une éventuelle amélioration en 7.10) :
--->
J'ai donc essayé ce live-CD (<ubuntu-7.04-desktop-amd64.iso) avec mon PC
"puissant" (!) actuellement sous 98SE, 3 DD (ide 0:0, 0:1, 1:0), 4
lecteurs optiques SCSI (dont 2 graveurs), donc en boot sur SCSI.
La bonne nouvelle est que le live-CD est détecté tout seul par le BIOS
de la carte SCSI, ensuite j'ai testé les choix "boot and install" et
"boot in safe graphic mode", et les 2 coincent au même moment (parce que
départ sur SCSI?)
le message d'erreur est :
/bin/sh "can't access tty"; job control turned off
la mention "Busy box v1.1.3(debian 1:1.1.3-3ubuntu3)
et en-dessous, le prompt (initramfs)
<---- fin extrait post 04/10/07
Noter le prompt iniramfs
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu ne
voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de lecture
de mémoire de masse) me fait penser que Ubuntu a fait l'impasse sur le
SCSI, tout simplement.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
pour les 4 premiers points (mais ça ne me parait pas idiot de tester des
commandes tant que je suis sur un système qui tourne sur ses propres
ressources disque: je peux réparer pas mal de conneries tant que je
n'arrête pas la bête, alors que si je casse le grub un jour de ghost, il
me faut une disquette ou une clé pour booter et réparer, avec les pb que
ça implique: un boot sur disquette part souvent en clavier qwerty, etc...),
ok, mais sur ta vision de mes pb SCSI, là pas d'accord.
L'installation débute du live-CD
Le live-Cd tourne parce que **le_BIOS** (carte mère + carte SCSI) sait
accéder au SCSI, et que l'amorce du live-CD crée un système avec le/les
fs nécessaire(s) en ram.
voici un extrait de mon post du 4/10/2007 (à l'époque c'était la 7.04,
j'espérais une éventuelle amélioration en 7.10) :
--->
J'ai donc essayé ce live-CD (<ubuntu-7.04-desktop-amd64.iso) avec mon PC
"puissant" (!) actuellement sous 98SE, 3 DD (ide 0:0, 0:1, 1:0), 4
lecteurs optiques SCSI (dont 2 graveurs), donc en boot sur SCSI.
La bonne nouvelle est que le live-CD est détecté tout seul par le BIOS
de la carte SCSI, ensuite j'ai testé les choix "boot and install" et
"boot in safe graphic mode", et les 2 coincent au même moment (parce que
départ sur SCSI?)
le message d'erreur est :
/bin/sh "can't access tty"; job control turned off
la mention "Busy box v1.1.3(debian 1:1.1.3-3ubuntu3)
et en-dessous, le prompt (initramfs)
<---- fin extrait post 04/10/07
Noter le prompt iniramfs
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu ne
voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de lecture
de mémoire de masse) me fait penser que Ubuntu a fait l'impasse sur le
SCSI, tout simplement.
5. Pour tes problèmes SCSI, rien ne sert de changer de distribution.
Toutes les distris récentes fournissent en gros le même jeu de
pilotes. Et si l'installation débute (et te permet bien de
voir les disques SCSI à un moment) ce n'est pas un problème
de pilotes absents. Il faut regarder de plus près la sortie
de commandes comme : dmesg, lspci, etc. pour investiguer.
pour les 4 premiers points (mais ça ne me parait pas idiot de tester des
commandes tant que je suis sur un système qui tourne sur ses propres
ressources disque: je peux réparer pas mal de conneries tant que je
n'arrête pas la bête, alors que si je casse le grub un jour de ghost, il
me faut une disquette ou une clé pour booter et réparer, avec les pb que
ça implique: un boot sur disquette part souvent en clavier qwerty, etc...),
ok, mais sur ta vision de mes pb SCSI, là pas d'accord.
L'installation débute du live-CD
Le live-Cd tourne parce que **le_BIOS** (carte mère + carte SCSI) sait
accéder au SCSI, et que l'amorce du live-CD crée un système avec le/les
fs nécessaire(s) en ram.
voici un extrait de mon post du 4/10/2007 (à l'époque c'était la 7.04,
j'espérais une éventuelle amélioration en 7.10) :
--->
J'ai donc essayé ce live-CD (<ubuntu-7.04-desktop-amd64.iso) avec mon PC
"puissant" (!) actuellement sous 98SE, 3 DD (ide 0:0, 0:1, 1:0), 4
lecteurs optiques SCSI (dont 2 graveurs), donc en boot sur SCSI.
La bonne nouvelle est que le live-CD est détecté tout seul par le BIOS
de la carte SCSI, ensuite j'ai testé les choix "boot and install" et
"boot in safe graphic mode", et les 2 coincent au même moment (parce que
départ sur SCSI?)
le message d'erreur est :
/bin/sh "can't access tty"; job control turned off
la mention "Busy box v1.1.3(debian 1:1.1.3-3ubuntu3)
et en-dessous, le prompt (initramfs)
<---- fin extrait post 04/10/07
Noter le prompt iniramfs
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu ne
voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de lecture
de mémoire de masse) me fait penser que Ubuntu a fait l'impasse sur le
SCSI, tout simplement.
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu
ne voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de
lecture de mémoire de masse) me fait penser que Ubuntu a fait
l'impasse sur le SCSI, tout simplement.
pas du tout. Ubuntu est capable d'utiliser tout périphérique SCSI pour
lequel il y a un pilote, et des pilotes SCSI il en a tout un tas.
voilà, on est presque d'accord ;-)
À mon avis tu es dans un de ces quatre cas :
- contrôleur SCSI rare dont le pilote n'a jamais existé pour Linux
- contrôleur SCSI très ancien dont le pilote a été viré du noyau
- contrôleur SCSI très récent pour lequel il n'y a pas de pilote
- contrôleur SCSI bizarre pour lequel il faut passer une option
quelconque à un pilote ou au noyau pour qu'il le voit.
Ma carte SCSI est une carte "bootable" Advansys, ce qui est le plus
C'est pourquoi changer de distri n'apportera sans doute rien,
par contre à partir de ton système installé tu as tous les
outils pour examiner la situation et remonter les infos
pour résoudre le problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu
ne voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de
lecture de mémoire de masse) me fait penser que Ubuntu a fait
l'impasse sur le SCSI, tout simplement.
pas du tout. Ubuntu est capable d'utiliser tout périphérique SCSI pour
lequel il y a un pilote, et des pilotes SCSI il en a tout un tas.
voilà, on est presque d'accord ;-)
À mon avis tu es dans un de ces quatre cas :
- contrôleur SCSI rare dont le pilote n'a jamais existé pour Linux
- contrôleur SCSI très ancien dont le pilote a été viré du noyau
- contrôleur SCSI très récent pour lequel il n'y a pas de pilote
- contrôleur SCSI bizarre pour lequel il faut passer une option
quelconque à un pilote ou au noyau pour qu'il le voit.
Ma carte SCSI est une carte "bootable" Advansys, ce qui est le plus
C'est pourquoi changer de distri n'apportera sans doute rien,
par contre à partir de ton système installé tu as tous les
outils pour examiner la situation et remonter les infos
pour résoudre le problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Le fait qu'une fois installé (à partir d'un graveur sur IDE), Ubuntu
ne voie aucun périf SCSI ni ne mentionne aucune carte SCSI dans son
inventaire matériel (alors qu'on y trouve le chipset et des tas de
détails moins perceptibles par un utilisateur que des unités de
lecture de mémoire de masse) me fait penser que Ubuntu a fait
l'impasse sur le SCSI, tout simplement.
pas du tout. Ubuntu est capable d'utiliser tout périphérique SCSI pour
lequel il y a un pilote, et des pilotes SCSI il en a tout un tas.
voilà, on est presque d'accord ;-)
À mon avis tu es dans un de ces quatre cas :
- contrôleur SCSI rare dont le pilote n'a jamais existé pour Linux
- contrôleur SCSI très ancien dont le pilote a été viré du noyau
- contrôleur SCSI très récent pour lequel il n'y a pas de pilote
- contrôleur SCSI bizarre pour lequel il faut passer une option
quelconque à un pilote ou au noyau pour qu'il le voit.
Ma carte SCSI est une carte "bootable" Advansys, ce qui est le plus
C'est pourquoi changer de distri n'apportera sans doute rien,
par contre à partir de ton système installé tu as tous les
outils pour examiner la situation et remonter les infos
pour résoudre le problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
:)",
[...]
en fait le sudo semble inutile dans mon cas parce que je suis sous
"marc", premier utilisateur créé lors de l'installation à partir du
live-Cd, qui semble avoir une grande partie des privilèges de root.
[...]
:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
bon, j'aurais dû répéter l'autre post:
avant install linux : DD maitre sur IDE primaire avec 98SE (1,8GO) et 3
partitions de données derrière.
install linux sur un DD 15GO ancien, branché en esclave sur IDE primaire
... donc sur le DD windows, vu comme hda par Ubuntu, grub casse le mbr
d'origine windows, qui contient paraît-il la table des partitions.
J'ai trouvé ça sur un forum HTTP :
"If you are wanting to back up the partition table then I would use sfdisk:
sfdisk -d /dev/hda > part_layout.txt
Then you can restore with:
sfdisk /dev/hda < part_layout.txt"
J'ai pu le tester, mais je n'ai pas retrouvé le forum où j'ai péché ça ;
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
volontés si je suis trop long ;-)
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
En fait, avant de reconstituer la première partition du DD "hda" par
restauration d'une image ghost de la partition C: de mon Windows (ce qui
me cassera le mbr, puisque chaque fois que je fais ce genre de
restauration, mon BIOS me demande si c'est bien moi qui modifie le mbr),
Je voulais tester la commande de réparation du mbr par grub-install, qui
d'après plusieurs forums, ne modifierait que le début du mbr (un peu
plus de 460 octets) et reconduirait la table de partition inchangée.
[...]
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
intervient très peu: tous mes pb sont purement linux
- capacité à lancer le CDlive sous SCSI, mais perte du SCSI dès qqu'on
utilise le système installé
- pb de commande grub-install refusée alors que
1 j'ai les droits
2 je ne me trompe pas de nom de périf (ou alors il faut viser plus
précisément hda1, mais j'ai éssayé également et eu le même message ;-(
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
je le crains à "pas d'Ubuntu si on a du SCSI"
, ce qui explique mon post d'aujourd'hui "Linux et SCSI"
C'est n'importe quoi !
Tu dis ça parce que tu es à court d'arguments.
Comment peut-on être à court de quelque chose dont on n'a pas besoin ?
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
:)",
[...]
en fait le sudo semble inutile dans mon cas parce que je suis sous
"marc", premier utilisateur créé lors de l'installation à partir du
live-Cd, qui semble avoir une grande partie des privilèges de root.
[...]
marc@marc-uzinagaz:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
bon, j'aurais dû répéter l'autre post:
avant install linux : DD maitre sur IDE primaire avec 98SE (1,8GO) et 3
partitions de données derrière.
install linux sur un DD 15GO ancien, branché en esclave sur IDE primaire
... donc sur le DD windows, vu comme hda par Ubuntu, grub casse le mbr
d'origine windows, qui contient paraît-il la table des partitions.
J'ai trouvé ça sur un forum HTTP :
"If you are wanting to back up the partition table then I would use sfdisk:
sfdisk -d /dev/hda > part_layout.txt
Then you can restore with:
sfdisk /dev/hda < part_layout.txt"
J'ai pu le tester, mais je n'ai pas retrouvé le forum où j'ai péché ça ;
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
volontés si je suis trop long ;-)
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
En fait, avant de reconstituer la première partition du DD "hda" par
restauration d'une image ghost de la partition C: de mon Windows (ce qui
me cassera le mbr, puisque chaque fois que je fais ce genre de
restauration, mon BIOS me demande si c'est bien moi qui modifie le mbr),
Je voulais tester la commande de réparation du mbr par grub-install, qui
d'après plusieurs forums, ne modifierait que le début du mbr (un peu
plus de 460 octets) et reconduirait la table de partition inchangée.
[...]
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
intervient très peu: tous mes pb sont purement linux
- capacité à lancer le CDlive sous SCSI, mais perte du SCSI dès qqu'on
utilise le système installé
- pb de commande grub-install refusée alors que
1 j'ai les droits
2 je ne me trompe pas de nom de périf (ou alors il faut viser plus
précisément hda1, mais j'ai éssayé également et eu le même message ;-(
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
je le crains à "pas d'Ubuntu si on a du SCSI"
, ce qui explique mon post d'aujourd'hui "Linux et SCSI"
C'est n'importe quoi !
Tu dis ça parce que tu es à court d'arguments.
Comment peut-on être à court de quelque chose dont on n'a pas besoin ?
Petite précision: je trouve ton message vraiment confus et je ne suis
pas sûr d'avoir compris ton problème.
En fait ce post était un peu la suite de "réparer un biboot ubuntu (déjà
:)",
[...]
en fait le sudo semble inutile dans mon cas parce que je suis sous
"marc", premier utilisateur créé lors de l'installation à partir du
live-Cd, qui semble avoir une grande partie des privilèges de root.
[...]
:~$ sudo grub-install /dev/hda
ce qui ne modifierait qu'une partie du mbr, laissant la fin (table des
partitions) intacte.
J'ai donc fait ça avant le ghost,
C'est là que je ne comprends plus. Quand tu dis "j'ai fait ça avant le
ghost", tu parles de quelle commande ? Celle ci-dessus ou celle
ci-dessous.
bon, j'aurais dû répéter l'autre post:
avant install linux : DD maitre sur IDE primaire avec 98SE (1,8GO) et 3
partitions de données derrière.
install linux sur un DD 15GO ancien, branché en esclave sur IDE primaire
... donc sur le DD windows, vu comme hda par Ubuntu, grub casse le mbr
d'origine windows, qui contient paraît-il la table des partitions.
J'ai trouvé ça sur un forum HTTP :
"If you are wanting to back up the partition table then I would use sfdisk:
sfdisk -d /dev/hda > part_layout.txt
Then you can restore with:
sfdisk /dev/hda < part_layout.txt"
J'ai pu le tester, mais je n'ai pas retrouvé le forum où j'ai péché ça ;
Le problème ne se poserait pas si tu aérais ton message par des sauts de
ligne ou si tu étais plus explicite. Sur usenet, il faut parfois être
bourin au risque d'alourdir le style.
J'ai déjà lu certains de tes messages auquel je pense que j'aurais pu
apporter une réponse... si j'en avais compris la teneur.
En ne faisant pas plus d'effort de rédaction dans l'énoncé de ton
problème, tu te coupes d'une partie des contributeurs du forum et donc
de l'aide qu'ils t'auraient apportée.
hum, je fais des efforts, mais j'ai peur de décourager les bonnes
volontés si je suis trop long ;-)
espérant vérifier par la même commande
$dd if=/dev/hda of=MBR-backup2 bsQ2 count=1
puis
cmp MBR-backup1 MBR-backup2
Tu cherches donc à comparer octets par octets les fichiers "MBR-backup1"
et "MBR-backup2", mais je ne comprends pas comment tu as obtenus ces
deux fichiers. Plus exactement je ne comprends pas la différence entre
les deux configurations dans lesquelles se trouvait ton PC quand tu as
obtenu ces deux fichiers.
Le fichier "MBR-backup1" a-t-il été obtenu avant la restauration par
ghost et le fichier "MBR-backup2" après cette restauration ?
(Dans ce cas, je ne comprends pas l'objet du message, car si tu as pu
lancer la commande 'dd' après la restauration par ghost, c'est que tu
disposes d'un linux fonctionnel et il n'y as plus de problème)
En fait, avant de reconstituer la première partition du DD "hda" par
restauration d'une image ghost de la partition C: de mon Windows (ce qui
me cassera le mbr, puisque chaque fois que je fais ce genre de
restauration, mon BIOS me demande si c'est bien moi qui modifie le mbr),
Je voulais tester la commande de réparation du mbr par grub-install, qui
d'après plusieurs forums, ne modifierait que le début du mbr (un peu
plus de 460 octets) et reconduirait la table de partition inchangée.
[...]
Ton message aurait plus sa place sur fr.comp.sys.pc en ce qui concerne
les histoires de partition de disque dur, ou sur fr.comp.os.ms-windows
en ce qui concerne le fonctionnement de ghost.
pourquoi ? à part le mbr modifié par grub, mon environnement windows
intervient très peu: tous mes pb sont purement linux
- capacité à lancer le CDlive sous SCSI, mais perte du SCSI dès qqu'on
utilise le système installé
- pb de commande grub-install refusée alors que
1 j'ai les droits
2 je ne me trompe pas de nom de périf (ou alors il faut viser plus
précisément hda1, mais j'ai éssayé également et eu le même message ;-(
Selon moi, le seul problème concernant linux est la sauvegarde de la
table des partitions et du MBR (et je ne suis pas sûr qu'il s'agisse de
la même chose) à l'aide de la commande 'dd', puis le rédémarrage via un
live-cd ou autre méthode, et enfin la restauration du MBR.
Tester si tu pourras effectivement restaurer ta sauvegarde du MBR est
une précaution louable, mais je ne comprends vraiment pas ta procédure
de test et donc ton problème.
en fait, j'ai initié 3 ou 4 fils depuis le 7/3 à 16h46, qui se résument
je le crains à "pas d'Ubuntu si on a du SCSI"
, ce qui explique mon post d'aujourd'hui "Linux et SCSI"
C'est n'importe quoi !
Tu dis ça parce que tu es à court d'arguments.
Comment peut-on être à court de quelque chose dont on n'a pas besoin ?
[snip]
C'est pourquoi changer de distri n'apportera sans doute rien, par
contre à partir de ton système installé tu as tous les outils pour
examiner la situation et remonter les infos pour résoudre le
problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Je ne doute pas qu'après installation, je puisse troouver un package qui
ajoute la gestion du SCSI, mais en cas de casse, je devrai encore
déposer un DD et démonter le graveur IDE du boitier USB et l'installer
sur IDE pour pouvoir repartir du live-CD... Voilà une semaine que ma
machine a les tripes à l'air, ce n'est pas très sain, je n'ai pas envie
de faire ça trop souvent.
Pour moi tant que je ne renonce pas au SCSI, le choix c'est une distrib
avec live-Cd bootable sur SCSI: soit une autre distrib, soit un
"alternate CD" Ubuntu (pas testé), je ne me sens pas la compétence pour
me faire un live-CD étendu à partir du live-Cd officiel ;-)
[snip]
C'est pourquoi changer de distri n'apportera sans doute rien, par
contre à partir de ton système installé tu as tous les outils pour
examiner la situation et remonter les infos pour résoudre le
problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Je ne doute pas qu'après installation, je puisse troouver un package qui
ajoute la gestion du SCSI, mais en cas de casse, je devrai encore
déposer un DD et démonter le graveur IDE du boitier USB et l'installer
sur IDE pour pouvoir repartir du live-CD... Voilà une semaine que ma
machine a les tripes à l'air, ce n'est pas très sain, je n'ai pas envie
de faire ça trop souvent.
Pour moi tant que je ne renonce pas au SCSI, le choix c'est une distrib
avec live-Cd bootable sur SCSI: soit une autre distrib, soit un
"alternate CD" Ubuntu (pas testé), je ne me sens pas la compétence pour
me faire un live-CD étendu à partir du live-Cd officiel ;-)
[snip]
C'est pourquoi changer de distri n'apportera sans doute rien, par
contre à partir de ton système installé tu as tous les outils pour
examiner la situation et remonter les infos pour résoudre le
problème.
Entre autres :
sortie de lspci (uniquement la ligne qui parle de ton contrôleur)
dmesg (uniquement la partie qui semblerait parler d'un contrôleur
SCSI).
Je ne doute pas qu'après installation, je puisse troouver un package qui
ajoute la gestion du SCSI, mais en cas de casse, je devrai encore
déposer un DD et démonter le graveur IDE du boitier USB et l'installer
sur IDE pour pouvoir repartir du live-CD... Voilà une semaine que ma
machine a les tripes à l'air, ce n'est pas très sain, je n'ai pas envie
de faire ça trop souvent.
Pour moi tant que je ne renonce pas au SCSI, le choix c'est une distrib
avec live-Cd bootable sur SCSI: soit une autre distrib, soit un
"alternate CD" Ubuntu (pas testé), je ne me sens pas la compétence pour
me faire un live-CD étendu à partir du live-Cd officiel ;-)