Hibernation et démarrage sous un autre système d'exploitation: mes systèmes de fichiers seront-ils corrompus?
IMPORTANT
Si vous êtes venu ici pour chercher une réponse à cette question, veuillez lire toutes les réponses ci-dessous. Certains témoignages de personnes qui ont perdu des données font cela. Si vous envisagez de le faire régulièrement, je vous recommande fortement de tester vous-même.
Question originale
Supposons que Windows et Linux soient installés sur le même ordinateur. Si je veille Windows, puis-je démarrer Linux sans corrompre le système de fichiers Windows lorsque je reprends Windows? Qu'en est-il de l'inverse? Que se passe-t-il si j'hiberne un, amorce l'autre et monte le système de fichiers hiberné en lecture/écriture? Lecture seulement? Si cela n’est pas sûr, existe-t-il un moyen de détecter l’état de veille prolongée de l’autre SE et d’empêcher le montage de son système de fichiers?
En gros, jusqu'où puis-je pousser ceci avant qu'il ne se casse, et quel est le danger près du bord? Je pense connaître les réponses à certaines des questions ci-dessus, mais pour d’autres, je n’en ai aucune idée et, pour des raisons évidentes, je n’ai pas testé cela sur mon propre ordinateur. Si quelqu'un les a testés, veuillez éclairer le reste d'entre nous. Je ne cherche pas nécessairement une réponse spécifique à chaque question; Je vais accepter toute réponse qui répond à une partie raisonnable.
MODIFIER
Permettez-moi de préciser que lorsque je parle de "veille prolongée", je parle du processus d’écriture du contenu de RAM sur le disque dur et de la mise hors tension complète de l’ordinateur. Dans cet état, la remise sous tension de l'ordinateur vous ramène à travers le BIOS et le chargeur de démarrage, et vous pouvez théoriquement sélectionner un autre système d'exploitation sur un système à démarrage multiple. Quoi qu'il en soit, passons à la question initiale:
Mes résultats
Ok, après que tout le monde m'ait assuré que cela fonctionnerait, je l'ai testé moi-même. J'ai configuré Ubuntu pour remonter tous les systèmes de fichiers ntfs et les lecteurs externes en lecture seule avant l'hibernation. Une configuration Windows similaire n’était pas nécessaire car Windows ne lit pas les systèmes de fichiers Linux. Ensuite, j'ai essayé alternativement d'hiberner un système d'exploitation et de le reprendre avec l'autre, dans les deux sens. J'ai même essayé de monter le système de fichiers Windows à partir d'Ubuntu en lecture-écriture et de créer quelques fichiers. Windows ne s'est pas plaint quand j'ai repris. En conclusion, vous pouvez donc hiberner plus ou moins librement dans un scénario Windows/Linux à double démarrage.
Notez que je n'ai pas testé une situation de co-hibernation double Linux/Linux. Si vous avez deux installations Linux ou plus et que vous hibernez l'une d'elles, vous pourrez peut-être corrompre le système de fichiers en le montant depuis un autre.
Démarrer Windows sur un Linux en hibernation n’est pas une bonne idée. Je viens de perdre 20 GiB de données dans une partition NTFS partagée ...
J'ai hiberné Ubuntu Lucid un jour et le lendemain, j'ai allumé mon ordinateur. Certaines mises à jour ont gâché l'option enregistrée dans Grub, donc au lieu de redémarrer Ubuntu comme il se doit, il a démarré Windows 7. Lorsque je suis revenu avec mon café, je l'ai simplement utilisé sans rappeler qu'Ubuntu était en mode baissier. J'ai probablement accédé à la musique, au profil Firefox, aux documents, aux téléchargements et aux jeux à partir de la partition partagée.
La prochaine fois que je suis passé sur Ubuntu, j'ai vu le message "se réveiller de son hibernation". Dang. Mais je m'attendais à ce qu'il échoue au réveil et à un redémarrage en douceur, comme ce fut le cas la dernière fois que j'ai "essayé" cela (à l'époque karmique). Mais non, ça s'est bien réveillé. Cool. Ou pas. J'ai rapidement réalisé qu'un répertoire à la racine de la partition partagée était maintenant vide. Je pense que les seuls programmes accédant à la partition partagée à la reprise étaient Quod Libet (lecteur de musique) et Transmission (client BitTorrent).
Je suis retourné à Windows, où je ne pouvais même pas ouvrir le répertoire. Essayer de "dir" dans Shell a produit "fichier non trouvé". Corrompu. Malgré tout, l’espace libre de la partition n’a pas augmenté et mes 20 GiB sont probablement toujours là, à l’abri de tout écrasement. Peut être. Mais comment y arriver?
Un peu de recherche m'aidait peu et rendait mes espoirs encore plus sombres.
J'ai exécuté Scandisk ("Vérifier les erreurs") sans réparation automatique, car je ne voulais pas risquer de la réparer en détruisant davantage mes données. Le résultat n'était pas très informatif: "Erreurs trouvées. Exécuter avec réparation automatique." Inconnu pour moi, apparemment, il a également marqué la partition à vérifier automatiquement au prochain démarrage. J'ai éteint et suis parti et je suis revenu avec EasyRecovery plus tard.
L'ordinateur a commencé avec moi, ne faisant pas attention, comme d'habitude, et quand j'ai regardé, chkdsk a déjà lancé des erreurs, ce qui l'a fait pendant une dizaine de minutes. Oh bien, rien ne va ici.
Heureusement, j'ai récemment allumé une bougie pour Santa Tecla et, après le démarrage de Windows, mes données ont été rétablies, pour autant que je sache, même si certains fichiers ont été retrouvés.
Alors oui, cela s'est bien terminé. Vous pardonnerez le suspense dramatique, mais c'est pour faire passer un message: sauvegardez vos données! Et (dans mon cas) garder la sauvegarde à jour! Et bien sûr, faites très attention à l'hibernation et aux partitions partagées ...
J'ai toujours hiberner Windows avant de lancer quoi que ce soit d'autre, Windows est tout simplement trop lent pour recommencer à zéro. Mais il est dangereux d’écrire sur la partition d’un système d’exploitation en veille prolongée, car certaines des tables FS sont encore en mémoire (enfin, dans le fichier d'hibernation, mais pas dans le système de fichiers), les applications ont toujours des descripteurs pour certains fichiers et l'état du système de fichiers est généralement instable.
Mais vous pouvez monter cette partition en lecture seule, de cette façon, elle restera exactement comme avant l'hibernation et Windows ne remarquera rien.
En ce qui concerne la suggestion de le monter normalement et de rester à l’écart des fichiers système, ce n’est pas une bonne idée. Le transfert du contenu d'un fichier peut survenir, la MFT peut être modifiée, les attributs de temps d'accès seront modifiés, tout cela pourrait gravement endommager un système de fichiers. Ce n'est pas si dangereux avec FAT, mais c'est vraiment très dangereux avec NTFS, car c'est beaucoup plus compliqué et beaucoup plus en mémoire.
Je passe régulièrement mon Windows XP en hibernation et je démarre via USB dans Ubuntu.
Fonctionne parfaitement.
Il existe une différence entre le mode "Veille" et le mode "Veille prolongée".
L’état du système d’exploitation est complètement vidé sur le disque et votre matériel est mis hors tension.
Si vous allumez la machine et démarrez un autre système d'exploitation, cela n'a aucun impact sur le système d'exploitation en veille prolongée.
Vous pouvez garder autant de systèmes d’exploitation hibernés que vous le souhaitez.
Par exemple,
Vous pouvez avoir plusieurs installations Ubuntu (une par clé USB),
Et mettez-les en veille prolongée, débranchez le lecteur et démarrez-en un autre.
Il n'y a pas de Edge ici car il n'y a pas d'effet d'empilement/chaînage.
Les clés USB en veille prolongée de cet exemple sont toutes indépendantes les unes des autres.
(sur une machine à cycle d'alimentation).
Un petit inconvénient d’un lecteur "C:\" hiberné et de l’amorçage dans un autre
vous ne pourrez pas monter la partition d’amorçage en hibernation dans le nouveau système d’exploitation.
La partition est verrouillée en veille prolongée.
Il sera corrompu si édité dans cet état.
Je peux confirmer le problème de perte de données avec une partition NTFS partagée. Double amorçage entre Lucid Lynx Ubuntu et Windows 7. Après avoir hiberné Windows 7 et démarré sous Ubuntu, j’ai construit trois machines virtuelles VirtualBox (sur une période de 7 jours) et y ai installé divers progiciels. Lors du redémarrage dans Windows 7, les fichiers ont disparu. Disparu. ntfsundelete et avant tout n'ont pas été en mesure de les trouver.
J'ai donc effectué une série de tests pour voir si c'était ce qui causait la perte de données. Lors de la fermeture de Windows 7, du démarrage d'Ubuntu, de l'écriture de certains fichiers, du redémarrage sous Windows 7, les fichiers sont toujours conservés. Lors de l'hibernation de Windows 7, du redémarrage dans Ubuntu, de l'écriture de certains fichiers, du redémarrage sous Windows 7, les nouveaux fichiers ont disparu.
Je ne sais pas s'il existe des modifications dans un fichier, qu'elles soient conservées ou perdues, mais les nouveaux fichiers et dossiers ajoutés à une partition NTFS partagée risquent fort d'être perdus dans cette situation.
C'est un peu vieux, mais étant un problème critique, un autre témoignage en vaut la peine.
J'ai un disque dur USB externe NTFS que j'utilise pour les données (aucun fichier lié au système d'exploitation) avec 2 ordinateurs différents. J'avais l'habitude de perdre constamment des données jusqu'à ce que je résolve le problème. L’un des PC est plutôt ancien et lent (Windows XP); j’utilisais donc le système de veille prolongée pour accélérer les temps de redémarrage, en déconnectant le disque dur et en écrivant des données avec l’autre PC (Windows 7). La perte de données ne se produisait pas à chaque fois, mais elle était certainement causée par ce scénario. Depuis que j'ai arrêté de le faire, cela ne s'est jamais reproduit.
Je viens de rencontrer un problème sur un lecteur physique partagé (FAT32) entre Windows XP et Windows 7. J'ai hiberné Windows XP, démarré sous Windows 7 pendant quelques jours, puis je suis retourné sous XP. Maintenant, j'ai un système de fichiers corrompu sur le lecteur partagé. Le vérificateur de disque est en cours d'exécution, et le résultat est plutôt mauvais Surtout des fichiers liés, mais des milliers.
Il n'y a rien de mal avec ce que vous avez mentionné. Même si vous avez monté le système de fichiers en veille prolongée, le contenu de celle-ci est enregistré dans un fichier volumineux sur le disque - tant que vous ne touchez pas ce fichier, ni aucun fichier système important (évidemment), rien ne se passera.
Si vous modifiez le contenu d'une partition à partir d'un autre système d'exploitation après avoir éteint le système, la partition d'origine démarrera toujours sans problème. C'est la même chose en hibernation.
Assurez-vous simplement que lors du montage/démontage de la partition, vous n'endommagez aucun fichier système ni aucune information d'en-tête de lecteur (par exemple, MBR, journaux de fichiers) - bien que ce point n'ait rien à voir avec l'hibernation et davantage un avertissement commun dont nous avons tous besoin. à savoir.
J'ai rencontré des problèmes d'hibernation et d'initialisation multiple. Situation: Ubuntu et WinxP Multboot mais la partition de données visible pour les deux systèmes d'exploitation. J'ai fait des tests ... dans les deux sens ... J'étais donc en train de modifier un fichier Word avec Word ... J'ai sauvegardé le fichier et fermé Word. Hiberné ... a commencé Ubuntu ... a modifié le même fichier avec OpenOffice ... hiberné.
Redémarré à l’hibernation WinXP. Word n'a pas "vu" les modifications ... Il a simplement été modifié comme un autre fichier ...
J'ai également fait ce test dans l'autre sens ... Le fichier de la deuxième fois a été corrompu ... Je ne pouvais pas ouvrir le fichier ni supprimer le fichier. Chkdsk a "résolu" le problème mais le fichier a été perdu ... Lors d'un autre test, Ubuntu n'a pas même voir le fichier édité.
Donc, lorsque vous utilisez l'hibernation et les mêmes partitions (il n'est PAS nécessaire que ce soit la partition d'où le système d'exploitation démarre ...), cela est très dangereux ... Les fichiers peuvent et vont être corrompus dans mes tests et je peux le répéter ... BTW: Dans mes tests, j'ai TOUJOURS sauvegardé le fichier et fermé l'application (Word et OpenOffice) avant d'entrer en veille prolongée ... !! Je pensais que monter la partition était le coupable mais maintenant je pense que le problème doit être quelque chose à propos de la mise en cache de fichiers ou autre ... Quoi qu'il en soit: soyez prudent avec l'hibernation multi-OS ... !! Cordialement, ArnoR
J'ai vécu l'expérience hautement destructive suivante avec le double démarrage de Windows (Vista) et Ubuntu (9, 10, 11). Je ne suis pas un utilisateur technique, même si j'ai une longue expérience de l’utilisation et de la configuration de Windows et de DOS. J'ai installé Ubuntu via un live CD sur une machine Win Vista. Cela a fonctionné sans faille et j'ai eu le double démarrage en marche en un rien de temps. Voyant qu'il n'y avait aucun avertissement attaché à l'installation Ubuntu, j'ai supposé (naïvement) que je pouvais hiberner (enregistrer sur le disque, pas suspendre) les deux systèmes et basculer librement entre eux. Cela a eu les résultats suivants:
1) J'ai fait l'erreur de modifier un fichier texte dans Ubuntu que j'avais oublié était ouvert dans Windows. Ensuite, le fichier était inaccessible à l'un ou l'autre système d'exploitation. Il ne pouvait même pas être supprimé. Chkdsk l'a finalement supprimé, mais mes données ont été perdues.
2) J'ai également essayé deux autres opérations de fichier d'Ubuntu directement sur la partition Win: générer un fichier pdf à partir d'OpenOffice et créer un répertoire/dossier sur le bureau Win. Les deux étaient inaccessibles à partir de Windows (bien qu'ils puissent être vus dans Win Explorer). Heureusement, ils pourraient être supprimés d’Ubuntu, bien que chkdsk ait dû être exécuté par la suite pour supprimer ensuite complètement de Windows.
3) Un grand fichier OpenOffice Writer (enregistré en tant que * .doc), qui a été édité d’abord dans un, puis plusieurs fois dans un autre système d’exploitation (il n’était pas ouvert dans l’autre système lorsque je l’ai édité), dont la taille a soudainement augmenté. environ 2 Mo à 7 Mo, ce qui rend presque impossible de charger et enregistrer. Lorsque j'ai enregistré le fichier en tant que document * .odt, sa taille a été considérablement réduite, mais les temps de sauvegarde/chargement n'ont pas été plus rapides. Lorsque j'ai décompressé le fichier, sa section "contenu" s'est avérée supérieure à 22 Mo. Lorsque j'ai accédé à cela avec un éditeur de texte, il s'est avéré que chaque mot et chaque espace du document étaient formatés séparément dans le même style! J'ai finalement résolu le problème en comparant la version géante avec une version antérieure du même fichier, en utilisant l'ancienne version comme base de comparaison, puis en acceptant toutes les modifications et en enregistrant.
4) À ce stade, j'ai effectué une mise à niveau d'Ubuntu 10 à Ubuntu 11 et découvert que le système 11 utilisait exclusivement la nouvelle interface Unity, ce qui était totalement inacceptable pour mes besoins. Lorsque j'ai découvert comment installer Gnome sur Ubuntu 11, il s'est avéré que Gnome 3 était bien inférieur à Gnome 2. J'ai donc décidé de désinstaller complètement Ubuntu et de faire une nouvelle installation de Karmic Koala, qui utilise Gnome 2 sans laisser de trace du nouveau Système Unity. Cela s’est avéré compliqué, mais après avoir trouvé exactement les mêmes instructions répétées dans plusieurs manuels en ligne, j’ai procédé. Tout s'est bien passé jusqu'à ce que je lance EasyBCD 2.1.2 (sous Windows), ce qui me permet de redémarrer directement sous Windows après la suppression du booter Grub d'Ubuntu. Lors du redémarrage, j’ai constaté que mon MBR était gravement endommagé et que la machine ne reconnaissait aucun disque dur amorçable. Je devais payer un technicien pour restaurer le MBR.
5) Je pouvais maintenant redémarrer Vista et je m'apprêtais à réinstaller Ubuntu, lorsque j'ai découvert qu'un certain nombre de fichiers avaient commencé à disparaître de mon système de manière aléatoire. De toute évidence, le système de fichiers était toujours corrompu. Seule une réinstallation complète de Windows a résolu le problème, et j’examine maintenant avec la plus grande attention ce que je devrais faire pour éviter des problèmes similaires à l’avenir, avant d’installer Karmic Koala. J'espère que mes problèmes sont liés au problème de l'hibernation, mais pour être sûr, j'envisage de créer une partition NTFS "de transfert" distincte, où je peux mettre les fichiers d’un système d’exploitation avant d’y accéder par l’autre. Pas pratique, mais ça devrait être sûr. J'espère.
Ne le fais pas (encore!)
J'ai hiberné sous Vista/NTFS et démarré Lucid, travaillé 3 jours sur la partition NTFS partagée et commencé à faire disparaître des fichiers et des répertoires ou à être verrouillés par de vilains messages d'erreur (dans lucid). Quand j'ai redémarré sous Windows, c'était un véritable gâchis, les dégâts causés par les ordinateurs de bureau, etc. Heureusement, chkdsk a été en mesure de réparer la majeure partie de ce problème et j'ai réussi à récupérer environ 98% de ce que j'avais auparavant.
Ce n'est donc certainement pas une bonne chose à faire.
Je me souviens en quelque sorte que cela n’était pas possible auparavant: les partitions "hibernated" ntfs n’étaient pas montables sous Linux pour une raison (apparemment bonne). J'aimerais revenir à ce vieux comportement
DANGER! Je peux également confirmer qu'il s'agit d'un problème grave pour les volumes FAT32 et NTFS, et uniquement lorsque Windows (j'ai Windows 7) est mis en veille prolongée. Je pense que cela est lié à la mise en cache et ai envisagé de configurer le lecteur pour un retrait rapide. Cela corrigera peut-être le problème, mais je ne l’ai pas encore essayé, car je ne souhaite créer qu’une partition de cette façon que Windows ne semble pas prendre en charge. Même mon pilote ntfs OSX prend en charge le contrôle du cache par partition, mais pas Windows. En outre, mon pilote ntfs OSX semble reconnaître que le lecteur ne doit pas être monté. Semble lié à ce problème. J'espère que cela pourra aider.
Je peux également confirmer que le partage d'une partition non système entre deux systèmes d'exploitation différents en état de veille prolongée entraîne une corruption du système de fichiers et une perte de données.
Scénario: J'ai 3 partitions NTFS: 1. Windows XP 2. Windows 7 3. Données (je dois toujours utiliser XP pour les anciennes applications qui ne fonctionnent pas bien en mode de compatibilité ).
Exemple: démarrez à partir de la partition 1 (XP) et exécutez Thunderbird qui stocke les fichiers sur 3. Ensuite, mettez le système en veille prolongée (dump du système d'exploitation RAM pour mettre le fichier en veille et éteindre le PC). Démarrez à partir de la partition 2 (7) et exécutez Thunderbird qui stocke les fichiers sur 3. Ici, le problème commence avec les fichiers d’accès, parfois avec ou sans chkdsk. Retour au démarrage à partir de la partition 1 et les fichiers corrigés par OS_2_7 sont à nouveau corrompus, même le pire des fichiers ouverts avant l'hibernation (ex. Firefox) sont maintenant corrompus.
Donc oui. Hibernate deux systèmes d'exploitation, peu importe qu'ils utilisent une partition système/non système va corrompre les données. Pourquoi ? Je suppose que la cause principale est le fichier LOCK et MFT. Après le réveil de l'hibernation, O/S n'actualise pas MFT, donc suppose toujours de trouver des fichiers dans d'anciens secteurs. Ainsi, tout fichier ayant changé de taille/de lieu sera corrompu.
Voici mon expérience. J'utilise un système à double démarrage avec Windows et Kubuntu (11.04). La plupart de mes fichiers se trouvent sur une partition Windows NTFS et je l’utilise principalement sous Linux. Il est monté en utilisant Fuse.
C'est ce qui s'est passé:
- Hiberné Windows
- Au prochain démarrage, démarré sous Linux et utilisé pendant quelques semaines - sans démarrer sous Windows
- Redémarrage sous Windows (car un test en ligne ne fonctionnait que dans Internet Explorer et rien d'autre, ie4linux n'était pas suffisant)
Lorsque Windows a repris, j'ai remarqué que tous les fichiers créés au cours de ces deux semaines étaient manquants. J'ai redémarré sous Linux pour ne vérifier que les fichiers manquants. J'imagine que Windows a restauré le système de fichiers NTFS à l'état où il était en veille prolongée et l'a restauré à ce moment-là.
J'ai essayé des outils comme ntfsundelete et testdisk. Ces fichiers manquants ne sont pas répertoriés. En outre, Linux monte ce lecteur en mode RW, même lorsque Windows était en veille prolongée et ne s'était pas arrêté. Je suppose que Linux avertit ou monte simplement le lecteur en mode lecture seule, mais cela n’est pas arrivé ici.
Je faisais exactement ça. Je n'ai jamais monté le lecteur système de la machine en hibernation pour éviter les accidents, et chaque système d'exploitation possède sa propre partition de swap. Cependant, j'avais une partition de données dédiée que je pourrais utiliser pour transférer des données entre les deux systèmes d'exploitation hibernants. J'y ai même mis mes profils Firefox et Thunderbird, je n'ai donc pas besoin de conserver deux profils distincts. Assurez-vous simplement de fermer Firefox sur une machine avant de l'hiberner.
Je ne me souviens pas d'avoir jamais eu de problèmes avec la configuration, et je l'ai également utilisée assez longtemps.
La réponse est que, avec NTFS, apparemment, oui (voir les autres réponses). Vous pouvez essayer avec des systèmes de fichiers plus anciens et plus simples tels que FAT. Mais ce serait un coup de poignard dans le noir.
Je veux juste ajouter que le problème peut être reproduit avec des machines virtuelles. J'utilise VirtualBox sur une machine à double démarrage. J'ai installé le logiciel VirtualBox Host dans les partitions Windows et Linux et enregistre les fichiers image sur une partition NTFS partagée. L'objectif était de pouvoir utiliser le même VM sous Windows et Linux.
Par habitude, j'ai utilisé la commande d'état "save machine" de VirtualBox lors de l'arrêt de la machine virtuelle. J'ai utilisé cette commande (qui enregistre l'état RAM pour le VM quelque part), redémarré mon ordinateur portable dans un autre système d'exploitation et utilisé à nouveau le même VM. Il n'y avait pas d'option de restauration dans VirtualBox, donc apparemment, VirtualBox n'est pas au courant de l'état enregistré d'un VM si l'état a été enregistré à l'aide d'une autre installation de VirtualBox. J'ai lu que VMware pourrait être plus intelligent à ce sujet, mais je ne l'ai pas essayé.
Finalement, toutes mes machines virtuelles ont été corrompues. Cependant, j’ai pu réparer la plupart des dégâts en utilisant fsck.
Cela signifie simplement que vous n'avez pas besoin de passer des heures à partitionner et à installer un système d'exploitation pour reproduire ce problème.
Ma solution? Hibernation désactivée sous Windows. Il est désactivé par défaut dans Ubuntu. De même, n'utilisez jamais l'état de sauvegarde de la machine pour une VM si vous prévoyez de lancer cette VM dans un contexte différent (système d'exploitation différent, installation de l'hôte différente, etc.).
Jusqu'à ce que quelqu'un trouve un système de fichiers (ou système d'exploitation, ou autre) qui n'est pas vulnérable à ce problème.
De plus, fermez tous les descripteurs ouverts sur la partition partagée (et effacez-les sur le disque) avant de mettre en veille (ou, je suppose, le démontage de la partition - il doit y avoir un moyen de le faire aussi dans Windows) si cela a été signalé pour éviter toute corruption (voir La réponse de Lie Ryan). Je préférerais cependant être en sécurité et ne pas utiliser d'hibernation du tout dans cette situation.