message bizarre sur grub-install

YBM wrote:

Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...

Tu as essayé un live cd en 32 bits ?

non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un

Athlon xp1500 et pas de scsi

ou cela peut-il avoir été viré par une tentative d'install ratée, si
installation d'applis KDE sur gnome par exemple ?

non

ou une tentative d'utilisation de "alien" ? j'en ai tentée une, qui a
abouti à un message comme quoi il manquait quelque chose, et à la
question "continuer ou pas" j'ai répondu que je laissais tomber
(mais je ne me souviens pas de l'appli concernée)

malheureux : ne touche pas à ça !

message reçu (la raison c'était je crois justement le 64 bits)

YBM wrote:

Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...

Tu as essayé un live cd en 32 bits ?

non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un

Athlon xp1500 et pas de scsi

Essaye déjà ça... On trouve sur Google quelques trace d'une suppression
du pilote advansys sous Debian à partir d'une certaine version du
noyau où il a cessé de compiler.

On peut peut-être trouver un patch qui le rétablit, mais si ça marche
en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser
une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent
plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de
mémoire et des applis qui ont besoin d'utiliser à elle seule plus de
4 Go de mémoire virtuelle... et c'est rare.

YBM wrote:

YBM wrote:

Il semble donc que le pilote advansys ne soit pas présent en amd64,
c'est rare, mais il y a des pilotes qui sont présent en i386 mais pas
en adm64...

Tu as essayé un live cd en 32 bits ?

non, mais j'en ai un, gravé pour mon "autre" machine, qui n'a qu'un

Athlon xp1500 et pas de scsi

Essaye déjà ça... On trouve sur Google quelques trace d'une suppression
du pilote advansys sous Debian à partir d'une certaine version du
noyau où il a cessé de compiler.

On peut peut-être trouver un patch qui le rétablit, mais si ça marche
en 32 bits, à mon avis faut pas se prendre la tête. L'intérêt d'utiliser
une version 64 bits sur une 32 bits est quasi-nul (c'est même souvent
plus rapide en 32 qu'en 64), sauf à avoir nettement plus de 4Go de
mémoire et des applis qui ont besoin d'utiliser à elle seule plus de
4 Go de mémoire virtuelle... et c'est rare.

J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...


Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),

Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.

J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...

Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),

J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.

Maintenant, rester en version 64 bits signifie que ton Ubuntu ne
pourra jamais accéder à aucun des périphériques SCSI... à toi de
voir...

Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.

Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en
32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre
d'amélioration des perfs sous Linux en étant en 32 bits.

À ta place j'installerai une version 32 bits à la place de la 64
en place (choisir un partitionnement personnalisé, associé la partoche
Linux à "/" en demandant de reformater, l'autre au swap et basta).

En plus en étant en version 32 bits, tu auras pas de manip particulières
à faire pour installer les quelques applis (non libres) qui n'existent
qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des
applis Windows sera aussi plus facile.

YBM wrote:

J'ai essayé la version 32bits : ça boote sans pb sur SCSI, donc en
solution de sauvetage en cas de pb...

Y a-t-il un inconvénient à laisser installée la version 64 bits et à
n'utiliser le live-Cd 32 bits que pour des réparations du style
grub/grub-install ? D'autant plus que dès que Linux boote, il est en
ligne en wifi chez moi (ce que je n'ai jamais obtenu en W98 sur cette
machine qui est à l'étage et à 15m de la LiveBox),

J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.

hum, grub ça écrit juste une amorce et une table des disque bootables
par cette amorce... quelle raison y aurait-il que ça dépende du
processeur utilisé ?

Maintenant, rester en version 64 bits signifie que ton Ubuntu ne
pourra jamais accéder à aucun des périphériques SCSI... à toi de
voir...

ça c'est un argument massue

Parce qu'en traitement d'images, par exemple, avec les mêmes outils
(plus récents que W98) sur mes 2 machines Windows98, tout ce qui est
application de filtres (gamma, contraste, niveaux) va énormément plus
vite sur le 64 bits 3Ghz que sur le 32 bits 1,5Ghz, le rapport étant à
mon avis bien supérieur à 4. Le passage à 64 bits a également impliqué
un changement d'architecture et l'apparition d'instructions de
"parallèlisation" de traitements de données.

Windows 98 n'existant pas en version 64 bits, tu tournes de A à Z en
32 bits sur ton 3Ghz, applis comprises. Tu auras le même genre
d'amélioration des perfs sous Linux en étant en 32 bits.

Je ne jurerais pas qu'une appli ne puisse pas être compilée pour
détecter si le processeur possède des instructions particulières, même
si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne
travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis
juste pour **accéder** à la mémoire.

Du temps que j'étais jeune, je bossais sur une famille de minis où les
"pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous
les programmes de calcul étaient compilés pour utiliser le coprocesseur
(enfin, les compilateurs utilisaient systématiquement les instructions
du coprocesseur) parce que l'OS gérait parfaitement l'interruption
"instruction non reconnue" et dans ce cas la routine d'interruption
consistait en une émulation de l'instruction manquante. Tout le monde y
gagnait : une seule version d'exec, compacité maxi, la séquence
éventuellement longue étant "centralisée" dans l'OS, le tout étant
transparent, juste plus lent sur les machines "pauvres".

Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise
des moteurs de calcul rusés à ce point, et le 32 bit est donc la
meilleure solution.

À ta place j'installerai une version 32 bits à la place de la 64
en place (choisir un partitionnement personnalisé, associé la partoche
Linux à "/" en demandant de reformater, l'autre au swap et basta).

En plus en étant en version 32 bits, tu auras pas de manip particulières
à faire pour installer les quelques applis (non libres) qui n'existent
qu'en version 32 bits. Faire joujou avec Wine pour faire tourner des
applis Windows sera aussi plus facile.

ben voilà, si un jour je suis frustré d'avoir 2 OS 32 bits sur un PC 64
bits, j'installe un 2ème linux, en 64 bits ;-)

J'ai un gros gros doute sur la possibilité de réparer un GRUB d'une
distri 64bits à partir d'un CD d'une version 32. C'est pas impossible,
vu que la phase de boot pré-noyau doit être identique, mais c'est
à vérifier.

hum, grub ça écrit juste une amorce et une table des disque bootables
par cette amorce... quelle raison y aurait-il que ça dépende du
processeur utilisé ?

L'amorce + le reste de GRUB c'est quand même du code machine du
processeur... dans le cas du i86 et du adm64, comme il bootent
tous deux en "mode réel", c'est du code 8086 donc ça pourrait
bien marcher, ou non... D'autre part il y a l'outil en ligne
de commande grub qui pourrait trouver bizarre qu'on lui demande
d'installer une amorce pour une autre archi que celle sous laquelle
elle tourne.

Je ne jurerais pas qu'une appli ne puisse pas être compilée pour
détecter si le processeur possède des instructions particulières, même
si l'exec est conforme à Win98, système 32 bits. Une appli graphique ne
travaille qu'en mémoire, quand elle calcule elle ignore l'OS, hormis
juste pour **accéder** à la mémoire.

C'est pas seulement des instructions en plus, c'est carrément un
mode global de fonctionnement du processeur avec un jeu d'instructions
différentes. Certes, le mode 64 permet de passer au mode 32, mais
il faut que ce soit pris en compte par l'OS, qu'il existe un jeu
de DLL en double compilé en 64 bits, etc.

Du temps que j'étais jeune, je bossais sur une famille de minis où les
"pas chers" n'avaient pas de coprocesseur, les chers en avaient. Tous
les programmes de calcul étaient compilés pour utiliser le coprocesseur
(enfin, les compilateurs utilisaient systématiquement les instructions
du coprocesseur) parce que l'OS gérait parfaitement l'interruption
"instruction non reconnue" et dans ce cas la routine d'interruption
consistait en une émulation de l'instruction manquante.

C'est justement ce qu'on faisait autrefois avec Linux quand il y
avait encore des machines PC sans copro ("Emulate 80387").

Mais bon, tu as raison, rien ne garantit que XnView par exemple utilise
des moteurs de calcul rusés à ce point, et le 32 bit est donc la
meilleure solution.

C'est une question de recompilation surtout, et souvent d'adaptation
du code pour vraiment profiter du 64 bits - sinon ça peut même être
plus lent.