Un changement de kernel peut-il entra=c3=aener une corruption du syst=c3=a8me de partition =3f
58 réponses
Pierre www.zetrader.info
Hello, je pose la question parce que j'ai eu une erreur bizarre sous
kubuntu 18.10, après avoir changé de kernel (à 4.18.20) tout semblait
aller bien, puis avant hier, une erreur de lecture sur le disque, cela a
commencé par thunderbird qui était soi-disant lancé quand j'essayais de
le lancer, mais pourtant absent dans le gestionnaire de tâche, et
impossible de basculer dessus, ensuite en redémarrant, système planté,
kernel impossible à charger, une erreur de lecture, et je me retrouve en
ligne de commande sous "busybox", je tape help pour voir les commmandes
puis je ne sais plus quelle commande (je crois que c'était fsck, qui
m'avait été suggéré lors du message d'erreur) qui a corrigé les erreurs
de partition sur le disque, puis j'ai pu lancer le système.
J'ai remis le kernel 4.18.0-11 (d'origine), mais l'erreur s'est
reproduite plus tard, application thunderbird impossible à lancer,
système à nouveau planté au redémarrage, le kernel d'origine non plus ne
se lançait pas et il y avait une erreur sur le disque.
Est-ce possible que le changement de kernel avec ukuu foute le boxon
dans le système de fichiers ?
En attendant j'ai tout reformaté et mis xubuntu 18.10, et je suis sous
kernel 4.18.0-12 (kernel de la distribution, mis à jour par l'OS),
depuis hier, pas de problème pour le moment, mais bon j'ai pas testé de
changement de kernel avec ukuu.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en cherchant de kernel normalement j'installe a priori d'autres versions de modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le matos n'était pas dans le kernel (même sans pilotes propriétaires) ? Je m'explique : est-ce qu'il y a des fichiers de configurations qui sont mis à jour par le kernel, et qui peuvent ne plus être adaptés en changeant de kernel ? Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs que dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé de kernel ?
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en
cherchant de kernel normalement j'installe a priori d'autres versions de
modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le
matos n'était pas dans le kernel (même sans pilotes propriétaires) ?
Je m'explique : est-ce qu'il y a des fichiers de configurations qui sont
mis à jour par le kernel, et qui peuvent ne plus être adaptés en
changeant de kernel ?
Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs que
dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé de
kernel ?
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en cherchant de kernel normalement j'installe a priori d'autres versions de modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le matos n'était pas dans le kernel (même sans pilotes propriétaires) ? Je m'explique : est-ce qu'il y a des fichiers de configurations qui sont mis à jour par le kernel, et qui peuvent ne plus être adaptés en changeant de kernel ? Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs que dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé de kernel ?
Le 07/12/2018 à 17:11, Pierre www.zetrader.fr a écrit :
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en cherchant de kernel normalement j'installe a priori d'autres versions de modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le matos n'était pas dans le kernel (même sans pilotes propriétaires) ? Je m'explique : est-ce qu'il y a des fichiers de configurations qui sont mis à jour par le kernel, et qui peuvent ne plus être adaptés en changeant de kernel ? Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs que dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé de kernel ?
À titre d'anecdote par exemple, j'avais remarqué que sous kernel 4.18 en général, pour les paramètres de mon module rtl8723be, si je mets la sélection d'antenne 1, cela coupe carrément le wifi, plus d'accès au wifi (plus aucun wifi n'apparaît, c'est comme si j'avais désactivé le module), 0 ou 2, cela tourne. Sous les kernels 4.15, que ce soit sous sélection d'antenne 0, 1 ou 2, aucun des paramètres ne coupe carrément le wifi, la réception sera a priori plus ou moins bonne selon la sélection d'antenne, mais c'est tout, la liste des wifis qui m'entoure apparaît toujours et je peux toujours me connecter. J'avais vu un gars dire que selon la version de kernel, telle ou telle sélection d'antenne était plus appropriée. C'est à ce genre de détail auquel je pense : et si cela concernait globalement le matériel ? Le fichier de configuration en question pour le module rtl8723be, n'est pas dans le kernel. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 07/12/2018 à 17:11, Pierre www.zetrader.fr a écrit :
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en
cherchant de kernel normalement j'installe a priori d'autres versions
de modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le
matos n'était pas dans le kernel (même sans pilotes propriétaires) ?
Je m'explique : est-ce qu'il y a des fichiers de configurations qui
sont mis à jour par le kernel, et qui peuvent ne plus être adaptés en
changeant de kernel ?
Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs
que dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé
de kernel ?
À titre d'anecdote par exemple, j'avais remarqué que sous kernel 4.18 en
général, pour les paramètres de mon module rtl8723be, si je mets la
sélection d'antenne 1, cela coupe carrément le wifi, plus d'accès au
wifi (plus aucun wifi n'apparaît, c'est comme si j'avais désactivé le
module), 0 ou 2, cela tourne.
Sous les kernels 4.15, que ce soit sous sélection d'antenne 0, 1 ou 2,
aucun des paramètres ne coupe carrément le wifi, la réception sera a
priori plus ou moins bonne selon la sélection d'antenne, mais c'est
tout, la liste des wifis qui m'entoure apparaît toujours et je peux
toujours me connecter.
J'avais vu un gars dire que selon la version de kernel, telle ou telle
sélection d'antenne était plus appropriée.
C'est à ce genre de détail auquel je pense : et si cela concernait
globalement le matériel ?
Le fichier de configuration en question pour le module rtl8723be, n'est
pas dans le kernel.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 07/12/2018 à 17:11, Pierre www.zetrader.fr a écrit :
Le 07/12/2018 à 17:08, Pierre www.zetrader.fr a écrit :
Le kernel contenant les modules pour faire reconnaître mon matos, en cherchant de kernel normalement j'installe a priori d'autres versions de modules pour faire reconnaître ce matos.
Pardon, en *changeant* de kernel
J'ai pensé à ce que tu dis à un moment : et si tout ce qui concerne le matos n'était pas dans le kernel (même sans pilotes propriétaires) ? Je m'explique : est-ce qu'il y a des fichiers de configurations qui sont mis à jour par le kernel, et qui peuvent ne plus être adaptés en changeant de kernel ? Idem pour les drivers, est-ce qu'il y a des infos réparties ailleurs que dans le kernel, qui peuvent devenir inadaptées lorsqu'on a changé de kernel ?
À titre d'anecdote par exemple, j'avais remarqué que sous kernel 4.18 en général, pour les paramètres de mon module rtl8723be, si je mets la sélection d'antenne 1, cela coupe carrément le wifi, plus d'accès au wifi (plus aucun wifi n'apparaît, c'est comme si j'avais désactivé le module), 0 ou 2, cela tourne. Sous les kernels 4.15, que ce soit sous sélection d'antenne 0, 1 ou 2, aucun des paramètres ne coupe carrément le wifi, la réception sera a priori plus ou moins bonne selon la sélection d'antenne, mais c'est tout, la liste des wifis qui m'entoure apparaît toujours et je peux toujours me connecter. J'avais vu un gars dire que selon la version de kernel, telle ou telle sélection d'antenne était plus appropriée. C'est à ce genre de détail auquel je pense : et si cela concernait globalement le matériel ? Le fichier de configuration en question pour le module rtl8723be, n'est pas dans le kernel. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Rambo
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée
par la distribution, google en regorge, c'est pas que moi, donc dire
que c'est moi la cata pour un bug sur un simple test de kernels
"stables", c'est vouloir nier l'évidence, être de mauvaise foi face à
l'avalanche de plantages et de bugs qu'on peut voir sur certaines
versions "stables" de kernel et d'ubuntu : gel du système, cassage du
bios, pc qui ne démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du
délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM
.. une eprom, ou autre, oui.
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Pierre www.aribaut.com
Le 07/12/2018 à 17:49, Rambo a écrit :
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios." Quoi ? Ubuntu 17.10 n'est pas classé dans les virus ? Ah pardon ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 07/12/2018 à 17:49, Rambo a écrit :
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée
par la distribution, google en regorge, c'est pas que moi, donc dire
que c'est moi la cata pour un bug sur un simple test de kernels
"stables", c'est vouloir nier l'évidence, être de mauvaise foi face à
l'avalanche de plantages et de bugs qu'on peut voir sur certaines
versions "stables" de kernel et d'ubuntu : gel du système, cassage du
bios, pc qui ne démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du
délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM
.. une eprom, ou autre, oui.
Il existe des virus qui savent modifier le BIOS, 2 exemples :
"Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur,
Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le
disque dur est formaté ou remplacé. Le fonctionnement est assez simple :
le programme va sauvegarder le BIOS, modifier quelques routines internes
et ensuite flasher le nouveau BIOS, sans que ce soit visible pour
l’utilisateur. Une fois que c’est fait, il va infecter automatiquement
le MBR (qui est la carte des partitions sur le disque dur)."
"EDIT du 4 décembre et changement de titre:
Il est maintenant certain que l'installation de la 17.10 casse le bios
de nombreux laptop Lenovo. Bug #1734147
Après installation, de la 17.10, le bios est corrompu et il devient
impossible de booter par lecteur externe (USB, Lecteur dvd...), et il
est impossible de sauvegarder les modifications apportées au bios."
Quoi ? Ubuntu 17.10 n'est pas classé dans les virus ? Ah pardon ;)
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios." Quoi ? Ubuntu 17.10 n'est pas classé dans les virus ? Ah pardon ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Michel
Le 07/12/2018 à 17:49, Rambo a écrit :
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Une eprom, non, on l'efface aux UV avant de la reprogrammer.
Le 07/12/2018 à 17:49, Rambo a écrit :
denis.paris wrote on 07-12-18 10:47:
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée
par la distribution, google en regorge, c'est pas que moi, donc dire
que c'est moi la cata pour un bug sur un simple test de kernels
"stables", c'est vouloir nier l'évidence, être de mauvaise foi face à
l'avalanche de plantages et de bugs qu'on peut voir sur certaines
versions "stables" de kernel et d'ubuntu : gel du système, cassage du
bios, pc qui ne démarre plus etc...
Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit
rappel pour rafraîchir la mémoire à certains :
https://www.google.fr/search?q=ubuntu+17.04+bios
https://www.google.fr/search?q=kernel+freeze
https://www.google.fr/search?q=kernel+freeze+4.15
Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du
délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM
.. une eprom, ou autre, oui.
Une eprom, non, on l'efface aux UV avant de la reprogrammer.
Le 07/12/2018 à 08:21, Pierre www.zetrader.fr a écrit :
Et des problèmes suite à une simple mise à jour de kernel suggérée par la distribution, google en regorge, c'est pas que moi, donc dire que c'est moi la cata pour un bug sur un simple test de kernels "stables", c'est vouloir nier l'évidence, être de mauvaise foi face à l'avalanche de plantages et de bugs qu'on peut voir sur certaines versions "stables" de kernel et d'ubuntu : gel du système, cassage du bios, pc qui ne démarre plus etc... Je ne l'ai pas eu personnellement ni l'un ni l'autre, mais un petit rappel pour rafraîchir la mémoire à certains : https://www.google.fr/search?q=ubuntu+17.04+bios https://www.google.fr/search?q=kernel+freeze https://www.google.fr/search?q=kernel+freeze+4.15 Etc etc...
Un kernel qui "casserait" le bios, là franchement ça devient du délire. C'est du hardware, il faut "flasher" la ROM pour le modifier.
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Une eprom, non, on l'efface aux UV avant de la reprogrammer.
denis.paris
Le 07/12/2018 à 17:49, Rambo a écrit :
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Oui, je pense que tout le monde avait compris l'idée...
Le 07/12/2018 à 17:49, Rambo a écrit :
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM
.. une eprom, ou autre, oui.
Oui, je pense que tout le monde avait compris l'idée...
D'abord vous racontez n'importe quoi, personne ne sait flasher une ROM .. une eprom, ou autre, oui.
Oui, je pense que tout le monde avait compris l'idée...
denis.paris
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là puisque la plupart des constructeurs prévoient des programmes pour la mise à jour des BIOS, mais un OS destiné à tourner sur un très grand nombre de BIOS différents n'est pas censé "attaquer" directement le matériel. Alors un gros bug qui fait partir le code n'importe comment, c'est toujours imaginable, mais je me demande aussi s'il n'y aurait pas une part d'intox d'utilisateurs mécontents ou même de concurrents, dans l'intention de nuire à linux. Est-ce que ce phénomène s'est déjà produit avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme une seconde nature pour eux!
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples :
"Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur,
Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le
disque dur est formaté ou remplacé. Le fonctionnement est assez simple :
le programme va sauvegarder le BIOS, modifier quelques routines internes
et ensuite flasher le nouveau BIOS, sans que ce soit visible pour
l’utilisateur. Une fois que c’est fait, il va infecter automatiquement
le MBR (qui est la carte des partitions sur le disque dur)."
"EDIT du 4 décembre et changement de titre:
Il est maintenant certain que l'installation de la 17.10 casse le bios
de nombreux laptop Lenovo. Bug #1734147
Après installation, de la 17.10, le bios est corrompu et il devient
impossible de booter par lecteur externe (USB, Lecteur dvd...), et il
est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là
puisque la plupart des constructeurs prévoient des programmes pour la
mise à jour des BIOS, mais un OS destiné à tourner sur un très grand
nombre de BIOS différents n'est pas censé "attaquer" directement le
matériel.
Alors un gros bug qui fait partir le code n'importe comment, c'est
toujours imaginable, mais je me demande aussi s'il n'y aurait pas une
part d'intox d'utilisateurs mécontents ou même de concurrents, dans
l'intention de nuire à linux. Est-ce que ce phénomène s'est déjà produit
avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme
une seconde nature pour eux!
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là puisque la plupart des constructeurs prévoient des programmes pour la mise à jour des BIOS, mais un OS destiné à tourner sur un très grand nombre de BIOS différents n'est pas censé "attaquer" directement le matériel. Alors un gros bug qui fait partir le code n'importe comment, c'est toujours imaginable, mais je me demande aussi s'il n'y aurait pas une part d'intox d'utilisateurs mécontents ou même de concurrents, dans l'intention de nuire à linux. Est-ce que ce phénomène s'est déjà produit avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme une seconde nature pour eux!
Philippe Weill
Le 07/12/2018 à 18:27, denis.paris a écrit :
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là puisque la plupart des constructeurs prévoient des programmes pour la mise à jour des BIOS, mais un OS destiné à tourner sur un très grand nombre de BIOS différents n'est pas censé "attaquer" directement le matériel.
pour moi c'est surtout un bug du ship nvram voir du bios associé aux bugs du pilote INTEL SPI ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
Alors un gros bug qui fait partir le code n'importe comment, c'est toujours imaginable, mais je me demande aussi s'il n'y aurait pas une part d'intox d'utilisateurs mécontents ou même de concurrents, dans l'intention de nuire à linux. Est-ce que ce phénomène s'est déjà produit avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme une seconde nature pour eux!
non sur ce coup là il n'y a pas d'intox pour windows , il n'y a pas besoin de probleme de bios pour que ca ne redemarre pas ;-)
Le 07/12/2018 à 18:27, denis.paris a écrit :
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples :
"Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur
même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier
quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est
fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)."
"EDIT du 4 décembre et changement de titre:
Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147
Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur
dvd...), et il est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là puisque la plupart des constructeurs prévoient des
programmes pour la mise à jour des BIOS, mais un OS destiné à tourner sur un très grand nombre de BIOS différents n'est pas censé
"attaquer" directement le matériel.
pour moi c'est surtout un bug du ship nvram voir du bios associé aux bugs du pilote INTEL SPI
ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de
firmware de disque sur une autre fonction rarement utilisé de la norme IDE
ca a pas loupé sous linux , un jour tous ses disques ont dégagés
Alors un gros bug qui fait partir le code n'importe comment, c'est toujours imaginable, mais je me demande aussi s'il n'y aurait pas
une part d'intox d'utilisateurs mécontents ou même de concurrents, dans l'intention de nuire à linux. Est-ce que ce phénomène s'est
déjà produit avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme une seconde nature pour eux!
non sur ce coup là il n'y a pas d'intox
pour windows , il n'y a pas besoin de probleme de bios pour que ca ne redemarre pas ;-)
Le 07/12/2018 à 18:00, Pierre www.aribaut.com a écrit :
Il existe des virus qui savent modifier le BIOS, 2 exemples : 1) https://www.tomshardware.fr/2011/09/22/mebromi-le-virus-qui-remplace-votre-bios/ "Contrairement à CIH qui effaçait totalement le BIOS de l’ordinateur, Mebromi le modifie pour pouvoir rester dans l’ordinateur même si le disque dur est formaté ou remplacé. Le fonctionnement est assez simple : le programme va sauvegarder le BIOS, modifier quelques routines internes et ensuite flasher le nouveau BIOS, sans que ce soit visible pour l’utilisateur. Une fois que c’est fait, il va infecter automatiquement le MBR (qui est la carte des partitions sur le disque dur)." 2) https://forum.ubuntu-fr.org/viewtopic.php?id 17786 "EDIT du 4 décembre et changement de titre: Il est maintenant certain que l'installation de la 17.10 casse le bios de nombreux laptop Lenovo. Bug #1734147 Après installation, de la 17.10, le bios est corrompu et il devient impossible de booter par lecteur externe (USB, Lecteur dvd...), et il est impossible de sauvegarder les modifications apportées au bios."
Évidemment que c'est /techniquement/ possible, la question n'est pas là puisque la plupart des constructeurs prévoient des programmes pour la mise à jour des BIOS, mais un OS destiné à tourner sur un très grand nombre de BIOS différents n'est pas censé "attaquer" directement le matériel.
pour moi c'est surtout un bug du ship nvram voir du bios associé aux bugs du pilote INTEL SPI ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
Alors un gros bug qui fait partir le code n'importe comment, c'est toujours imaginable, mais je me demande aussi s'il n'y aurait pas une part d'intox d'utilisateurs mécontents ou même de concurrents, dans l'intention de nuire à linux. Est-ce que ce phénomène s'est déjà produit avec des versions de Windows? Pourtant, fabriquer des bugs, c'est comme une seconde nature pour eux!
non sur ce coup là il n'y a pas d'intox pour windows , il n'y a pas besoin de probleme de bios pour que ca ne redemarre pas ;-)
denis.paris
Le 07/12/2018 à 18:47, Philippe Weill a écrit :
pour moi c'est surtout un bug du ship nvram voir du bios associé aux bugs du pilote INTEL SPI ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
C'est intéressant, parce qu'en effet en cas de plantage c'est la dernière couche installée qu'on suspecte, donc l'OS, alors qu'il s'appuie sur le BIOS du constructeur de la machine qui est du code, donc possiblement buggé... Raison de plus de ne pas se ruer sur la dernière versions d'un OS ou d'un kernel, s'il a déjà tourné plusieurs mois la plupart des plâtres sont déjà essuyés. Pour ma part, j'en reste paisiblement à des versions éprouvées et LTS que j'upgrade tous les 2 ans mais parfois 4, et depuis plus de 10 ans je ne me souviens pas avoir eu le moindre comportement suspect, en tout cas non provoqué. Parfois un programme se bloque dans l'interface graphique (par exemple en lisant une vidéo), je passe en mode console et je le tue, mais ça ne déstabilise pas le noyau. En fait les machines les plus fragiles sont celles qui sont en "dual boot" car la gestion des partitions en Windows et en linux ne sont pas toujours en phase et il m'est arrivé de flinguer des partitions linux simplement en manipulant une partition NTFS avec l'outil Windows. J'ai simplement tout réinstallé en linux pur sur tout le disque. Avoir deux systèmes sur le même disque c'est jouer avec le feu, de toutes façons.
Le 07/12/2018 à 18:47, Philippe Weill a écrit :
pour moi c'est surtout un bug du ship nvram voir du bios associé aux
bugs du pilote INTEL SPI
ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un
contructeur de disque dur avait codé une fonction de flash de firmware
de disque sur une autre fonction rarement utilisé de la norme IDE
ca a pas loupé sous linux , un jour tous ses disques ont dégagés
C'est intéressant, parce qu'en effet en cas de plantage c'est la
dernière couche installée qu'on suspecte, donc l'OS, alors qu'il
s'appuie sur le BIOS du constructeur de la machine qui est du code, donc
possiblement buggé...
Raison de plus de ne pas se ruer sur la dernière versions d'un OS ou
d'un kernel, s'il a déjà tourné plusieurs mois la plupart des plâtres
sont déjà essuyés. Pour ma part, j'en reste paisiblement à des versions
éprouvées et LTS que j'upgrade tous les 2 ans mais parfois 4, et depuis
plus de 10 ans je ne me souviens pas avoir eu le moindre comportement
suspect, en tout cas non provoqué. Parfois un programme se bloque dans
l'interface graphique (par exemple en lisant une vidéo), je passe en
mode console et je le tue, mais ça ne déstabilise pas le noyau.
En fait les machines les plus fragiles sont celles qui sont en "dual
boot" car la gestion des partitions en Windows et en linux ne sont pas
toujours en phase et il m'est arrivé de flinguer des partitions linux
simplement en manipulant une partition NTFS avec l'outil Windows. J'ai
simplement tout réinstallé en linux pur sur tout le disque. Avoir deux
systèmes sur le même disque c'est jouer avec le feu, de toutes façons.
pour moi c'est surtout un bug du ship nvram voir du bios associé aux bugs du pilote INTEL SPI ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
C'est intéressant, parce qu'en effet en cas de plantage c'est la dernière couche installée qu'on suspecte, donc l'OS, alors qu'il s'appuie sur le BIOS du constructeur de la machine qui est du code, donc possiblement buggé... Raison de plus de ne pas se ruer sur la dernière versions d'un OS ou d'un kernel, s'il a déjà tourné plusieurs mois la plupart des plâtres sont déjà essuyés. Pour ma part, j'en reste paisiblement à des versions éprouvées et LTS que j'upgrade tous les 2 ans mais parfois 4, et depuis plus de 10 ans je ne me souviens pas avoir eu le moindre comportement suspect, en tout cas non provoqué. Parfois un programme se bloque dans l'interface graphique (par exemple en lisant une vidéo), je passe en mode console et je le tue, mais ça ne déstabilise pas le noyau. En fait les machines les plus fragiles sont celles qui sont en "dual boot" car la gestion des partitions en Windows et en linux ne sont pas toujours en phase et il m'est arrivé de flinguer des partitions linux simplement en manipulant une partition NTFS avec l'outil Windows. J'ai simplement tout réinstallé en linux pur sur tout le disque. Avoir deux systèmes sur le même disque c'est jouer avec le feu, de toutes façons.
Nicolas George
Philippe Weill , dans le message <puebnu$26b$, a écrit :
ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
C'étaient des graveurs LG, vers le début des années 2000, et c'était un patch expérimental incorporé par Mandrake qui avait révélé le bug.
Philippe Weill , dans le message <puebnu$26b$1@shakotay.alphanet.ch>, a
écrit :
ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un
contructeur de disque dur avait codé une fonction de flash de firmware
de disque sur une autre fonction rarement utilisé de la norme IDE ca a
pas loupé sous linux , un jour tous ses disques ont dégagés
C'étaient des graveurs LG, vers le début des années 2000, et c'était un
patch expérimental incorporé par Mandrake qui avait révélé le bug.
Philippe Weill , dans le message <puebnu$26b$, a écrit :
ceci dit j'ai déjà vu un précedent moins mediatique à savoir qu'un contructeur de disque dur avait codé une fonction de flash de firmware de disque sur une autre fonction rarement utilisé de la norme IDE ca a pas loupé sous linux , un jour tous ses disques ont dégagés
C'étaient des graveurs LG, vers le début des années 2000, et c'était un patch expérimental incorporé par Mandrake qui avait révélé le bug.
