La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix.
Les réponses multiples sont interdites pour les mêmes raisons.
Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses.
76,78 % des personnes sondées estiment que ces sondages sont ineptes.
[x] Courir chercher le CD d'install. Nan parce qu'upgrader une 10.1 en 2006.0 avec urpmi --auto-select, c'était pas une bonne idée. Du tout.
[x] Reboire. Juste après.
Ah? Je l'ai fait il y a quelques mois pourtant, et ça s'était plutôt bien passé.
Enfin comme une mise à jour de Mandriva quoi...
C'est dans la 10.1 que le rpm de la glibc prétendait apporter une version supérieure à la réelle ?
Après avoir désinstallé la libc, c'est comme après avoir désinstallé le noyau: il faut rebooter pour en profiter pleinement.
Mathias
PS: les puristes preferreront encore détruire tout ses backups, casser les CD d'instal et désinstaller bash en supprimant la libc, histoire de vraiment en profiter a fond. Evidement, le faire la veille de rendre un rapport est encore un cran au dessus...
Je crée une arborescence parallele (je crée un usr, etc, ... dans /tmp). Je fait des manips desus, tout va bien, puis au bout d'un moment, mon arborescence parallele est completement cassée => je veux la supprimer.... => Et la, pas de chance, je suis en root et sans doute une question d'habitude, au lieux de taper "rm -Rf ./", je tape "rm -Rf /"...
Et c'est la que l'on se dit que la suppression de fichiers est super optimisée sous Linux! Le temps de me dire que quelque chose ne va pas, taper CTL+C, et je constate les dégats:
"ls /" me donne "command not found", ce qui n'est pas hyper rassurant. Idem pour a peu pres tout les utilitaires... Je ne peux meme pas dire quelle etait l'ampleur des dégats, je n'ais meme pas pu parcourir le disque...
Bilan: en une fraction de seconde mon Linux est totalement détruit, ma partition de Windows que je conservais à l'époque n'est plus qu'un bel espace vide et évidement j'ai besoin de mon ordinateur en état de marche très rapidement!
</ma vie>
Mathias
PS: a titre d'excuses, c'était il y a longtemps, lors de mes débuts sous Linux
PPS: par contre, les manips du style supprimer un executable critique en cours de fonctionnement pour le remplacer par une autre version pour le prochain reboot, ça je continue gaillardement à pratiquer... Question frissons, c'est mieux que le saut à l'élastique! Il me semble l'avoir meme fait sur le noyau car je n'avais pas assez de place dans /boot pour mon noyau en cours et le nouveau noyau que je voulais mettre.
«les manips du style supprimer un executable critique en cours de fonctionnement ... Il me semble l'avoir meme fait sur le noyau car je n'avais pas assez de place dans /boot»
Sauf que, sous unix, les fichiers sont des inodes, et que tant que ton inode est ouvert (donc que ton fichier est exécuté), les blocs ne sont pas libérés, et si tu supprime le dernier lien entre temps, ils ne seront libérés que lorsque l'inode sera fermé. Donc rien de gaillard, c'est fait pour que ca fonctionne.
Pour le noyau, si un jour il doit se relire apès le chargement de l'image au boot, je m'inquièterais : pour un bon vieux monolithique comme linux ca ferait désordre.
Par contre, un truc qui a l'air anodin comme le déchargement de module et rechargement d'une autre version , sans reboot, techniquement c'est beaucoup plus gaillard :)
Perso, le truc le plus téméraire que j'ai jamais fait, c'est :
(je vous rassure le système de machine2 n'est pas sur hda)
<le temps passe>
ssh machine2
su
mkdir /mnt/new_root
mount /dev/hda /mnt/new_root
mount /dev /mnt/new_root/dev -o bind
mount /proc /mnt/new_root/proc -o bind
mount /tmp /mnt/new_root/tmp -o bind
mount /sys /mnt/new_root/sys -o bind
chroot /mnt/new_root
<... quelques trucs dont je me rapelle plus mais qui justifient les bind de sys et tmp>
grub-intall /dev/hda
reboot
Et la machine n'a pas rébooté (pourtant sur du matos identique)
- Il faut attendre que la copie du disque de la machine 1 vers la machine 2 se termine sinon bof
- Le "mount /dev/hda" est louche. Normalement, tu fais des partitions dans ton disque et tu ne l'utilise pas directement en vrac comme ça.
Et si tu fais des partitions, ta commande "cat /dev/hda | ssh ..." va changer la liste des partitions. Il n'y a rien de mal à ça mais à aucun moment tu ne dis au système de relire la table des partitions du disque. Du coup, quand tu fais "mount /dev/hdaX /mnt/new_root", tu ne prends pas la nouvelle partition hdaX et ça va faire n'importe quoi.
Il y a un ioctl pour demander au noyau de relire la table des partitions. C'est quelque chose que fdisk fait automatiquement, dans la mesure du possible.
«- Il faut attendre que la copie du disque de la machine 1 vers la machine 2 se termine sinon bof»
il y a une élipse :)
indice : "<le temps passe>"
«Le "mount /dev/hda" est louche. Normalement, tu fais des partitions dans ton disque et tu ne l'utilise pas directement en vrac comme ça.»
Bien vu, je n'y avais pas pensé, mais en y réfléchissant :
- La nouvelle table de partition était identique a l'ancienne, sur du même matériel.
- j'ai retenté de tout mettre propre après un re-reboot avec une image réseau, et ca n'a jamais fonctionné.
- et mount aurait sans doute refusé de me monter quoique ce soit de toute manière.
Moi aussi ça m'est déjà arrivé (il y a 4 ans à peu près) :
en tapant vite, je n'ai pas fait attention, et j'ai dérapé de la touche '*' du pavé numérique vers la touche '/', ce qui a eu pour résultat 'rm -fr /' au lieu de 'rm -fr *'. Mon intention était de supprimer tout le contenu d'un répertoire...
C'est à ce moment là que j'ai vraiment compris l'importance des sauvegardes...
Bah si tu dois désinstaller la glibc c'est rarement pour rigoler hein..
Ca peut être parce quelque chose ne marche plus : par exemple si tu te compiles une version maison de glibc mais qu'elle provoque des segfaults, il faudra bien remettre l'ancienne version ^^
Le "ls" qui dit "command not found" au lieu de la liste des fichiers ca donne un petit frisson d'effroi pas la franche gaudriole :)
Heureusement, rpm -Uvh marchait encore </mavie>
...mais c'est le coup que nous a fait l'admin de notre système. C'était il y a quelques années sur des stations IBM, "pour faire de la place"....
Résultat, le monsieur d'IBM est venu et ça nous a couté la peau des rouleaux.
Pour vérifier que la recompilation en statique (ou liée à la µclibc, ou à une autre libc) a entièrement réussi. Ben oui, sous Linux, on peut réellement supprimer la libc par défaut, si on veut...
Un indice : c'est peut-être lié au fait que c'est un système libre.
Rebooter après voir désinstallé la glibc serait une grave erreur : vous pouvez être sûr de ne pas récupérer le système.
Mieux vaut réinstaller une nouvelle glibc avant de rebooter quoi que ce soit.
# Faut il rebooter quand le clavier se blo
Posté par mansuetus (site web personnel) . Évalué à 10.
# minilien
Posté par gc (site web personnel) . Évalué à 10.
# Et sur une Mandriva...
Posté par ナイコ (site web personnel) . Évalué à 3.
[x] Reboire. Juste après.
[^] # Re: Et sur une Mandriva...
Posté par Nicolas Melay . Évalué à 1.
Enfin comme une mise à jour de Mandriva quoi...
C'est dans la 10.1 que le rpm de la glibc prétendait apporter une version supérieure à la réelle ?
[^] # Re: Et sur une Mandriva...
Posté par Yves Martin . Évalué à 1.
# Trivial
Posté par Mathias Bavay (site web personnel) . Évalué à 10.
Mathias
PS: les puristes preferreront encore détruire tout ses backups, casser les CD d'instal et désinstaller bash en supprimant la libc, histoire de vraiment en profiter a fond. Evidement, le faire la veille de rendre un rapport est encore un cran au dessus...
[^] # Re: Trivial
Posté par z a . Évalué à 1.
[^] # Re: Trivial
Posté par Miod in the middle . Évalué à 0.
[^] # Re: Trivial
Posté par Gael . Évalué à 1.
enfin c'était comme ça quand j'installais glibc à la main à l'époque, pas besoin de redémarrage en tout cas.
Je pense que les scripts de postinstall des distribs utilisent cette commande.
[^] # Re: Trivial
Posté par med . Évalué à 1.
[^] # Re: Trivial
Posté par Mathias Bavay (site web personnel) . Évalué à 4.
Je crée une arborescence parallele (je crée un usr, etc, ... dans /tmp). Je fait des manips desus, tout va bien, puis au bout d'un moment, mon arborescence parallele est completement cassée => je veux la supprimer.... => Et la, pas de chance, je suis en root et sans doute une question d'habitude, au lieux de taper "rm -Rf ./", je tape "rm -Rf /"...
Et c'est la que l'on se dit que la suppression de fichiers est super optimisée sous Linux! Le temps de me dire que quelque chose ne va pas, taper CTL+C, et je constate les dégats:
"ls /" me donne "command not found", ce qui n'est pas hyper rassurant. Idem pour a peu pres tout les utilitaires... Je ne peux meme pas dire quelle etait l'ampleur des dégats, je n'ais meme pas pu parcourir le disque...
Bilan: en une fraction de seconde mon Linux est totalement détruit, ma partition de Windows que je conservais à l'époque n'est plus qu'un bel espace vide et évidement j'ai besoin de mon ordinateur en état de marche très rapidement!
</ma vie>
Mathias
PS: a titre d'excuses, c'était il y a longtemps, lors de mes débuts sous Linux
PPS: par contre, les manips du style supprimer un executable critique en cours de fonctionnement pour le remplacer par une autre version pour le prochain reboot, ça je continue gaillardement à pratiquer... Question frissons, c'est mieux que le saut à l'élastique! Il me semble l'avoir meme fait sur le noyau car je n'avais pas assez de place dans /boot pour mon noyau en cours et le nouveau noyau que je voulais mettre.
[^] # Re: Trivial
Posté par Anonyme . Évalué à 3.
Sauf que, sous unix, les fichiers sont des inodes, et que tant que ton inode est ouvert (donc que ton fichier est exécuté), les blocs ne sont pas libérés, et si tu supprime le dernier lien entre temps, ils ne seront libérés que lorsque l'inode sera fermé. Donc rien de gaillard, c'est fait pour que ca fonctionne.
Pour le noyau, si un jour il doit se relire apès le chargement de l'image au boot, je m'inquièterais : pour un bon vieux monolithique comme linux ca ferait désordre.
Par contre, un truc qui a l'air anodin comme le déchargement de module et rechargement d'une autre version , sans reboot, techniquement c'est beaucoup plus gaillard :)
Perso, le truc le plus téméraire que j'ai jamais fait, c'est :
ssh machine1
sreen
cat /dev/hda | ssh machine2 "cat > /dev/hda"
^A d
^D
(je vous rassure le système de machine2 n'est pas sur hda)
<le temps passe>
ssh machine2
su
mkdir /mnt/new_root
mount /dev/hda /mnt/new_root
mount /dev /mnt/new_root/dev -o bind
mount /proc /mnt/new_root/proc -o bind
mount /tmp /mnt/new_root/tmp -o bind
mount /sys /mnt/new_root/sys -o bind
chroot /mnt/new_root
<... quelques trucs dont je me rapelle plus mais qui justifient les bind de sys et tmp>
grub-intall /dev/hda
reboot
Et la machine n'a pas rébooté (pourtant sur du matos identique)
Tant pis, fallait juste le tenter :)
[^] # Re: Trivial
Posté par Zorro (site web personnel) . Évalué à 3.
[^] # Re: Trivial
Posté par Alban Crequy (site web personnel) . Évalué à 2.
- Il faut attendre que la copie du disque de la machine 1 vers la machine 2 se termine sinon bof
- Le "mount /dev/hda" est louche. Normalement, tu fais des partitions dans ton disque et tu ne l'utilise pas directement en vrac comme ça.
Et si tu fais des partitions, ta commande "cat /dev/hda | ssh ..." va changer la liste des partitions. Il n'y a rien de mal à ça mais à aucun moment tu ne dis au système de relire la table des partitions du disque. Du coup, quand tu fais "mount /dev/hdaX /mnt/new_root", tu ne prends pas la nouvelle partition hdaX et ça va faire n'importe quoi.
Il y a un ioctl pour demander au noyau de relire la table des partitions. C'est quelque chose que fdisk fait automatiquement, dans la mesure du possible.
[^] # Re: Trivial
Posté par Anonyme . Évalué à 2.
il y a une élipse :)
indice : "<le temps passe>"
«Le "mount /dev/hda" est louche. Normalement, tu fais des partitions dans ton disque et tu ne l'utilise pas directement en vrac comme ça.»
Bien vu, je n'y avais pas pensé, mais en y réfléchissant :
- La nouvelle table de partition était identique a l'ancienne, sur du même matériel.
- j'ai retenté de tout mettre propre après un re-reboot avec une image réseau, et ca n'a jamais fonctionné.
- et mount aurait sans doute refusé de me monter quoique ce soit de toute manière.
[^] # Re: Trivial
Posté par seginus . Évalué à 2.
à oui quand même, sympa comme habitude :-D
c'est une commande que je n'ai encore jamais tappée
[^] # Re: Trivial
Posté par Mathias Bavay (site web personnel) . Évalué à 2.
Mathias
[^] # Re: Trivial
Posté par gromf . Évalué à 1.
en tapant vite, je n'ai pas fait attention, et j'ai dérapé de la touche '*' du pavé numérique vers la touche '/', ce qui a eu pour résultat 'rm -fr /' au lieu de 'rm -fr *'. Mon intention était de supprimer tout le contenu d'un répertoire...
C'est à ce moment là que j'ai vraiment compris l'importance des sauvegardes...
[^] # Re: Trivial
Posté par Nicolas Melay . Évalué à 2.
[^] # Re: Trivial
Posté par gromf . Évalué à 1.
[^] # Re: Trivial
Posté par Bastoon . Évalué à 2.
(cf camelote pour ceux qui ne comprennent pas !)
[^] # Re: Trivial
Posté par N\'Kari . Évalué à 1.
[^] # Re: Trivial
Posté par Benoît Déchamps (site web personnel) . Évalué à 4.
[^] # Re: Trivial
Posté par Nicolas Melay . Évalué à 1.
[^] # Re: Trivial
Posté par Antoine Büsch . Évalué à 3.
Je suis sûr que ça aurait aussi marché avec vi :)
[^] # Re: Trivial
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
# RTFM !
Posté par j (site web personnel) . Évalué à 10.
==> http://www.pafoo.net/uninstallglibc/uninstglibc.html
[^] # Re: RTFM !
Posté par Nicolas (site web personnel) . Évalué à 1.
J'ai de la peine à me reprendre...
[^] # Re: RTFM !
Posté par hex . Évalué à -1.
Ca peut être parce quelque chose ne marche plus : par exemple si tu te compiles une version maison de glibc mais qu'elle provoque des segfaults, il faudra bien remettre l'ancienne version ^^
Le "ls" qui dit "command not found" au lieu de la liste des fichiers ca donne un petit frisson d'effroi pas la franche gaudriole :)
Heureusement, rpm -Uvh marchait encore </mavie>
# Ne jamais croiser les glibc
Posté par Obsidian . Évalué à 1.
Sinon, je n'ai qu'une seule chose à ajouter : Que celui qui vient de passer dans la première catégorie d'admins UNIX se dénonce ! :-)
# Ne riez pas...
Posté par kurun . Évalué à 2.
Résultat, le monsieur d'IBM est venu et ça nous a couté la peau des rouleaux.
Depuis, on a changé d'admin...
# [X] Oui
Posté par CoinKoin . Évalué à 1.
Un indice : c'est peut-être lié au fait que c'est un système libre.
[^] # Re: [X] Oui
Posté par VoixOff . Évalué à 3.
# grave erreur
Posté par ookaze . Évalué à -4.
Mieux vaut réinstaller une nouvelle glibc avant de rebooter quoi que ce soit.
[^] # Re: grave erreur
Posté par fork_bomb . Évalué à 3.
[^] # Re: grave erreur
Posté par Pol' uX (site web personnel) . Évalué à 1.
Adhérer à l'April, ça vous tente ?
[^] # Re: grave erreur
Posté par Zakath (site web personnel) . Évalué à 5.
J'espère que c'était du pied gauche...
# Aider moi
Posté par khalifa . Évalué à -1.
[^] # Re: Aider moi
Posté par Nicolas (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.