Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien essayé
la procedure décrite dans les docs pour fixer le disque root en modifiant
le kernel (http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante:
config: /usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not
likely to be correct
*** Error code 1
Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien essayé
la procedure décrite dans les docs pour fixer le disque root en modifiant
le kernel (http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante:
config: /usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not
likely to be correct
*** Error code 1
Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien essayé
la procedure décrite dans les docs pour fixer le disque root en modifiant
le kernel (http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante:
config: /usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not
likely to be correct
*** Error code 1
Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien
essayé la procedure décrite dans les docs pour fixer le disque root en
modifiant le kernel
(http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante: config:
/usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not likely
to be correct *** Error code 1
Dans la page plus haut, je lis ça :
| Vous aurez probablement à changer la cible afin de la faire correspondre
| à
| l'ID SCSI de votre disque dur. Vous devrez aussi forcer l'entrée scbus0
| afin de l'ajuster à votre contrôleur. Par exemple, si vous avez un
| contrôleur 15xx de chez Adaptec, vous changerez
| controller scbus0
| en
| controller scbus0 at aha0
As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Fred
Merci de ta réponse,
Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien
essayé la procedure décrite dans les docs pour fixer le disque root en
modifiant le kernel
(http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante: config:
/usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not likely
to be correct *** Error code 1
Dans la page plus haut, je lis ça :
| Vous aurez probablement à changer la cible afin de la faire correspondre
| à
| l'ID SCSI de votre disque dur. Vous devrez aussi forcer l'entrée scbus0
| afin de l'ajuster à votre contrôleur. Par exemple, si vous avez un
| contrôleur 15xx de chez Adaptec, vous changerez
| controller scbus0
| en
| controller scbus0 at aha0
As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Fred
Merci de ta réponse,
Y a-t-il un moyen de dire à umass de démarrer plus tard??? J'ai bien
essayé la procedure décrite dans les docs pour fixer le disque root en
modifiant le kernel
(http://www.freebsd.org/doc/fr_FR.ISO8859-1/articles/zip-drive
article.html) mais sans succès. J'obtiens l'erreur suivante: config:
/usr/src/sys/i386/conf/AKIRA:108: devices with zero units are not likely
to be correct *** Error code 1
Dans la page plus haut, je lis ça :
| Vous aurez probablement à changer la cible afin de la faire correspondre
| à
| l'ID SCSI de votre disque dur. Vous devrez aussi forcer l'entrée scbus0
| afin de l'ajuster à votre contrôleur. Par exemple, si vous avez un
| contrôleur 15xx de chez Adaptec, vous changerez
| controller scbus0
| en
| controller scbus0 at aha0
As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Fred
Merci de ta réponse,
F. Senault wrote:As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Merci de ta réponse,
Suivant tes conseils, j'ai lancé camcontrol devlist:
<COMPAQ HD0093172C 3207> at scbus0 target 5 lun 0 (pass0,da0)
<IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1)
j'avais oublié, mais j'ai ajouté "controller scbus0 at ahc0" et voilà ce que
ça donne:
/.../
config: AKIRA:109: syntax error.
Enfin on finira par trouver ce qui ne va pas...
En regardant ce que me dit camcontrol, je me demande comment les différents
dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait quoi et dit
quoi à qui?
Encore merci.
F. Senault wrote:
As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Merci de ta réponse,
Suivant tes conseils, j'ai lancé camcontrol devlist:
<COMPAQ HD0093172C 3207> at scbus0 target 5 lun 0 (pass0,da0)
<IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1)
j'avais oublié, mais j'ai ajouté "controller scbus0 at ahc0" et voilà ce que
ça donne:
/.../
config: AKIRA:109: syntax error.
Enfin on finira par trouver ce qui ne va pas...
En regardant ce que me dit camcontrol, je me demande comment les différents
dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait quoi et dit
quoi à qui?
Encore merci.
F. Senault wrote:As-tu fait ça ? En particulier le premier point ? (camcontrol devlist
devrait te donner les infos qui vont bien.)
Merci de ta réponse,
Suivant tes conseils, j'ai lancé camcontrol devlist:
<COMPAQ HD0093172C 3207> at scbus0 target 5 lun 0 (pass0,da0)
<IBM DDRS-34560 S97B> at scbus0 target 6 lun 0 (pass1,da1)
j'avais oublié, mais j'ai ajouté "controller scbus0 at ahc0" et voilà ce que
ça donne:
/.../
config: AKIRA:109: syntax error.
Enfin on finira par trouver ce qui ne va pas...
En regardant ce que me dit camcontrol, je me demande comment les différents
dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait quoi et dit
quoi à qui?
Encore merci.
Il faudrait plutôt regarder du côté de /boot/device.hints (man
device.hints), peut-être. Là, si un spécialiste pouvait confirmer, ce
serait peut-être mieux.
En regardant ce que me dit camcontrol, je me demande comment les
différents dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait
quoi et dit quoi à qui?
Alors, scbus, c'est le bus SCSI en lui-même. Ensuite, ahc, c'est le
driver de la carte SCSI adaptec. Viennent da, pour direct access, qui
est le type de device (tu peux avoir sa pour les tapes, cd pour les cd,
etc). Le pass est le passthrough driver, qui permet à certains
programmes très spécifiques de s'adresser directement aux devices en
utilisant la même interface quel que soit le matériel derrière.
Pour savoir qui parle à qui, heu, a priori, les contrôleurs s'accrochent
à scbus, et les périphériques au contrôleur...
Je me demande quand même si le BIOS ne continue pas à jouer un certain rôle
Sinon, un truc que j'ai trouvé fabuleusement ludique (sisi) avec
FreeBSD, c'est le fait que tous ces devices ont une page de man. Même
si c'est juste pour lire la description (et la signification des
initiales), ça vaut la peine de taper man scbus, man da, etc.
Effectivement, très instructif.
Encore merci.
Padkoi.
Si si!
Fred
Il faudrait plutôt regarder du côté de /boot/device.hints (man
device.hints), peut-être. Là, si un spécialiste pouvait confirmer, ce
serait peut-être mieux.
En regardant ce que me dit camcontrol, je me demande comment les
différents dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait
quoi et dit quoi à qui?
Alors, scbus, c'est le bus SCSI en lui-même. Ensuite, ahc, c'est le
driver de la carte SCSI adaptec. Viennent da, pour direct access, qui
est le type de device (tu peux avoir sa pour les tapes, cd pour les cd,
etc). Le pass est le passthrough driver, qui permet à certains
programmes très spécifiques de s'adresser directement aux devices en
utilisant la même interface quel que soit le matériel derrière.
Pour savoir qui parle à qui, heu, a priori, les contrôleurs s'accrochent
à scbus, et les périphériques au contrôleur...
Je me demande quand même si le BIOS ne continue pas à jouer un certain rôle
Sinon, un truc que j'ai trouvé fabuleusement ludique (sisi) avec
FreeBSD, c'est le fait que tous ces devices ont une page de man. Même
si c'est juste pour lire la description (et la signification des
initiales), ça vaut la peine de taper man scbus, man da, etc.
Effectivement, très instructif.
Encore merci.
Padkoi.
Si si!
Fred
Il faudrait plutôt regarder du côté de /boot/device.hints (man
device.hints), peut-être. Là, si un spécialiste pouvait confirmer, ce
serait peut-être mieux.
En regardant ce que me dit camcontrol, je me demande comment les
différents dev interragissent entre eux (ahc,scbus,pass,da,...)? Qui fait
quoi et dit quoi à qui?
Alors, scbus, c'est le bus SCSI en lui-même. Ensuite, ahc, c'est le
driver de la carte SCSI adaptec. Viennent da, pour direct access, qui
est le type de device (tu peux avoir sa pour les tapes, cd pour les cd,
etc). Le pass est le passthrough driver, qui permet à certains
programmes très spécifiques de s'adresser directement aux devices en
utilisant la même interface quel que soit le matériel derrière.
Pour savoir qui parle à qui, heu, a priori, les contrôleurs s'accrochent
à scbus, et les périphériques au contrôleur...
Je me demande quand même si le BIOS ne continue pas à jouer un certain rôle
Sinon, un truc que j'ai trouvé fabuleusement ludique (sisi) avec
FreeBSD, c'est le fait que tous ces devices ont une page de man. Même
si c'est juste pour lire la description (et la signification des
initiales), ça vaut la peine de taper man scbus, man da, etc.
Effectivement, très instructif.
Encore merci.
Padkoi.
Si si!
Fred
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce que
je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Merci d'avance...
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce que
je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Merci d'avance...
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce que
je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Merci d'avance...
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce
que je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Tiens, je viens de tomber sur ça sur la mailing-list FreeBSD :
Under 5.x you have a very similar syntax using sysctl 'hints' -- see
/usr/src/sys/conf/NOTES, but the above example would be something like:
hint.scbus.0.at="ahc0"
hint.da.0.at="scbus0"
hint.da.0.target="0"
hint.da.0.unit="0"
which you should be able to set from the loader.
Donc, apparemment, tu peux décider que ton bus SCSI Adaptec doit être
parcouru en premier (scbus.0.at="ahc0"), puis que le disque da0 va être
sur le scbus0 (donc l'ahc plus haut), sur la target 0 (dans ton cas, 5),
et l'unité, je sais pas trop. Il est dit que ça devrait marcher avec 0.
Ces options peuvent se taper telles quelles dans le fichier
/boot/loader.conf.
Au passage, quand tu vois que le loader se met en route (c'est lui qui
dessine la petite barre qui tourne), si tu fais une touche, tu tomberas
dans un prompt, qui te permet éventuellement d'annuler une bourde. Note
soigneusement les variables que tu changes, et puis, au besoin, tu peux
déjà faire "unset variable" pour les effacer à ce prompt, puis boot (-s
pour débarquer en single user)...
Au contraire, si tu te sens courageux, tu peux dans un premier temps
taper les trois lignes plus haut à la main pour tester une fois sans
risques avant de les rajouter à loader.conf...Merci d'avance...
Fred
Un grand merci, ça doit résoudre le pb, faut juste que je trouve pourquoi il
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce
que je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Tiens, je viens de tomber sur ça sur la mailing-list FreeBSD :
Under 5.x you have a very similar syntax using sysctl 'hints' -- see
/usr/src/sys/conf/NOTES, but the above example would be something like:
hint.scbus.0.at="ahc0"
hint.da.0.at="scbus0"
hint.da.0.target="0"
hint.da.0.unit="0"
which you should be able to set from the loader.
Donc, apparemment, tu peux décider que ton bus SCSI Adaptec doit être
parcouru en premier (scbus.0.at="ahc0"), puis que le disque da0 va être
sur le scbus0 (donc l'ahc plus haut), sur la target 0 (dans ton cas, 5),
et l'unité, je sais pas trop. Il est dit que ça devrait marcher avec 0.
Ces options peuvent se taper telles quelles dans le fichier
/boot/loader.conf.
Au passage, quand tu vois que le loader se met en route (c'est lui qui
dessine la petite barre qui tourne), si tu fais une touche, tu tomberas
dans un prompt, qui te permet éventuellement d'annuler une bourde. Note
soigneusement les variables que tu changes, et puis, au besoin, tu peux
déjà faire "unset variable" pour les effacer à ce prompt, puis boot (-s
pour débarquer en single user)...
Au contraire, si tu te sens courageux, tu peux dans un premier temps
taper les trois lignes plus haut à la main pour tester une fois sans
risques avant de les rajouter à loader.conf...
Merci d'avance...
Fred
Un grand merci, ça doit résoudre le pb, faut juste que je trouve pourquoi il
Ca marche peut être dans mon cas, mais j'ai déjà un peu de sueur au front
rien qu'en pensant à taper reboot après la manip... Je ne trouve pas de
page de man sur ces variables et je me demande si dois donner à value
da0s1a ou da0 at ahc0 target 0 lun 0, avec ou sans guillemets???
Une autre question, si la numérotation des disque est foireuse, est-ce
que je ne vais pas simplement forcer la valeur par défaut et me retrouver
devant le même problème? (Etant donné que ma clé USB par définition se
balade et ne risque pas d'être présente à chaque démarrage....)
Tiens, je viens de tomber sur ça sur la mailing-list FreeBSD :
Under 5.x you have a very similar syntax using sysctl 'hints' -- see
/usr/src/sys/conf/NOTES, but the above example would be something like:
hint.scbus.0.at="ahc0"
hint.da.0.at="scbus0"
hint.da.0.target="0"
hint.da.0.unit="0"
which you should be able to set from the loader.
Donc, apparemment, tu peux décider que ton bus SCSI Adaptec doit être
parcouru en premier (scbus.0.at="ahc0"), puis que le disque da0 va être
sur le scbus0 (donc l'ahc plus haut), sur la target 0 (dans ton cas, 5),
et l'unité, je sais pas trop. Il est dit que ça devrait marcher avec 0.
Ces options peuvent se taper telles quelles dans le fichier
/boot/loader.conf.
Au passage, quand tu vois que le loader se met en route (c'est lui qui
dessine la petite barre qui tourne), si tu fais une touche, tu tomberas
dans un prompt, qui te permet éventuellement d'annuler une bourde. Note
soigneusement les variables que tu changes, et puis, au besoin, tu peux
déjà faire "unset variable" pour les effacer à ce prompt, puis boot (-s
pour débarquer en single user)...
Au contraire, si tu te sens courageux, tu peux dans un premier temps
taper les trois lignes plus haut à la main pour tester une fois sans
risques avant de les rajouter à loader.conf...Merci d'avance...
Fred
Un grand merci, ça doit résoudre le pb, faut juste que je trouve pourquoi il