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 la rupture et à quel point est-ce dangereux 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 la 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 Go 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. Ainsi, 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 un shell produit "fichier non trouvé". Corrompu. Malgré tout, l’espace libre de la partition n’a pas augmenté et mes 20 Gio 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 allez pardonner 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 hiberné, car certaines des tables FS sont encore en mémoire (en fait, dans le fichier d'hibernation mais pas dans le système de fichiers), les applications ont toujours des descripteurs sur certains fichiers et l'état du système de fichiers est généralement correct. d'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 veille régulièrement sur Windows XP et démarre via Ubuntu via USB.
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 (par exemple, une par clé USB),
puis hiberner chacune d'elles, débranchez le lecteur et démarrez-en un autre.
Il n'y a pas de bord ici car il n'y a pas d'effet d'empilement / chaînage.
Les clés USB hibernées dans cet exemple sont toutes indépendantes les unes des autres
(sur une machine à cycle de fonctionnement).

Un petit inconvénient d'un C:\lecteur " " en hibernation et du démarrage dans un autre système d'exploitation est que
vous ne pourrez pas monter la partition de démarrage en hibernation dans le nouveau système d'exploitation.
La partition est verrouillée en veille prolongée.
Il sera corrompu s'il est modifié 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 de 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.

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 qu'un avertissement commun dont nous avons tous besoin. à savoir.

Je viens de rencontrer un problème sur un disque physique partagé (FAT32) entre Windows XP et Windows 7. J'ai hiberné Windows XP, démarré sous Windows 7 pendant quelques jours, puis repris 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.

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 d'obtenir une perte de données constante 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 mode hibernation pour accélérer les temps de redémarrage, en déconnectant le disque dur dans cet état 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.

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 ... en hibernation.

Redémarré à l’hibernation WinXP. Word n'a pas "vu" les modifications ... Il a simplement été traité 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 quoi que ce soit ... Quoi qu'il en soit: soyez prudent avec l'hibernation multi-OS ... !! Cordialement, ArnoR

J'ai eu l'expérience très destructrice 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 l'explorateur Windows). 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é), puis sa taille a 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.

5) Maintenant, je pouvais redémarrer Vista et je me préparais à 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’envisage 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 à la question de la mise en veille prolongée, mais pour être sûr, j'envisage la création d' une partition NTFS « transfert » séparée, où je peux mettre des fichiers d'un système d'exploitation avant d' y accéder de 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 à y ê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 le bureau, etc. En espérant que chkdsk ait pu réparer la majeure partie de ce problème, 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 ntfs «hibernées» 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 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 ça t'as aidé.

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é:

1. Hiberné Windows
2. Au prochain démarrage, démarré sous Linux et utilisé pendant quelques semaines - sans démarrer sous Windows
3. 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 disque en mode lecture seule, mais cela n’est pas arrivé ici.

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 en veille prolongée (la mémoire de sauvegarde du système d’exploitation (OS dump) pour mettre en veille prolongée le fichier 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.

Je faisais exactement ça. Je n'ai jamais monté le lecteur système de la machine en veille prolongée 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 hôte VirtualBox 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 ordinateur virtuel 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 de la RAM pour la machine virtuelle quelque part), redémarré mon ordinateur portable dans l'autre système d'exploitation et utilisé à nouveau la même machine virtuelle. Il n'y avait pas d'option de restauration dans VirtualBox, donc apparemment, VirtualBox n'a pas connaissance de l'état enregistré d'une machine virtuelle 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? Veille prolongé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 machine virtuelle si vous prévoyez de lancer cette machine virtuelle dans un contexte différent (système d'exploitation différent, installation d'hôte différente, etc.).

Jusqu'à ce que quelqu'un trouve un système de fichiers (ou un 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.

Je ne pense pas que ce soit possible.

Lorsque vous hibernez, l’ordinateur est «verrouillé» (faute d’un meilleur terme) sur ce système d’exploitation. Vous n'hibernez pas le système d'exploitation, vous hibernez l'intégralité de l'ordinateur. À partir du moment où vous quittez le mode veille prolongée, vous ne revenez plus dans le BIOS ni dans le POST.