Hibernation et démarrage sous un autre système d'exploitation: mes systèmes de fichiers seront-ils corrompus?

52

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.

Ryan Thompson
la source
1
J'aimerais préciser que je recherche quelqu'un qui a réellement testé ces questions et une question similaire de manière empirique . Mais, à défaut, n'hésitez pas à spéculer. Si personne n’a de vrais résultats de test, j’accepterai la spéculation la plus plausible après un certain temps.
Ryan Thompson
Eh bien, je vais essayer de tester certaines de ces idées bientôt. Si je me retrouve avec une machine qui démarre encore, je reviendrai et accepterai une réponse. ;)
Ryan Thompson
@RyanThompson, comment vérifieriez-vous cette fiabilité? Bien sûr, cela peut sembler fonctionner, jusqu'à ce que ça ne fonctionne pas.
Pacerier
C'est pourquoi j'ai marqué la réponse «Ne le faites pas, vous perdrez des données».
Ryan Thompson

Réponses:

17

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

Chema
la source
5
Je vais marquer ceci comme la réponse acceptée, juste pour pécher par excès de prudence pour les nouveaux utilisateurs qui lisent cette question.
Ryan Thompson
Les mises à jour causées par un système d'exploitation affectant l'autre sont plutôt normales et ne sont pas réellement causées par des problèmes d'hibernation. L'état d'hibernation est traité comme tout autre fichier du système de fichiers. Je ne vois pas pourquoi cette réponse a été acceptée.
Matt H
1
Un répertoire complet disparaissant dans les limbes FAT n'est pas une "mise à jour causée par un système d'exploitation", ni une intentionnelle du moins. J'ai constaté une corruption de données dans une partition NTFS partagée après l'hibernation de Linux, le démarrage de Windows, puis le réveil de Linux, aussi simple que cela.
Chema
2
Mettre en veille prolongée un système d'exploitation et monter la même partition sur un autre revient à ce que deux systèmes d'exploitation accèdent au disque en même temps. Ils ne sont pas au courant des changements que l'autre a apportés, ce qui entraînerait la corruption.
Psusi
2
Il me semble que le problème est que le système d'exploitation laisse la partition dans un état "impur". Il existe une option dans Windows pour ne pas mettre en cache les écritures, peut-être que cela aide, peut-être existe-t-il une option similaire sous Linux. Ou peut-être pouvons-nous trouver un moyen de faire en sorte que le système "nettoie" la partition avant de dormir.
Rolf
23

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.

vava
la source
1
Etes-vous sûr que le montage en lecture seule est correct? D'après ce que je comprends, avec les systèmes de fichiers journalisés, même un montage en lecture seule relit le journal et entraîne donc une modification du système de fichiers. D'autre part, le seul système de fichiers Linux auquel vous pouvez accéder à partir de Windows est ext2, ce qui est non-logique, comme FAT, et Linux effectue probablement un véritable montage NTFS en lecture seule, pour des raisons historiques. Donc , il peut - être est sûr. Dans tous les cas, j'aimerais que quelqu'un ait des résultats de test concrets.
Ryan Thompson
2
Non, lorsque FS est monté en lecture seule, rien n'y a été changé. C’est pourquoi il s’appelle lecture seule :) Il n’est pas nécessaire d’avoir un journal, car il garantit toujours que l’état de FS est toujours correct, mais lorsque l’état ne change pas, il n’est pas nécessaire, le journal n’est donc pas utilisé. Et cela fonctionne pour moi pendant un bon
bout de
1
"Windows est trop lent pour recommencer à zéro" Êtes-vous sérieux? Je dois faire quelque chose de mal alors, car lorsque mon ordinateur portable est en veille, il ajoute environ 2 minutes ou plus à mon temps de démarrage.
thepaulpage
1
Je parlais de XP et oui, il est très lent compte-tenu du temps qu'il faut pour que les applications fonctionnent. Ubuntu 9.04 tournait autour de lui. Ubuntu 9.10 est beaucoup plus lent pour une raison quelconque.
vava
depuis Windows 8 et plus, le démarrage de Windows est extrêmement rapide. Lorsque j'utilisais Windows 7, il se chargeait lentement jusqu'à ce que je puisse obtenir le navigateur pour démarrer le réseau est déjà disponible. Ensuite, j'ai mis à niveau vers Windows 8 et, depuis mon retour à la maison, allumez le routeur, allumez l'ordinateur portable et les navigateurs. Je dois attendre longtemps avant de pouvoir accéder à Internet. Puisque Windows 10 est encore plus rapide, appuyez sur le
bouton d'
9

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.

nik
la source
En fait, vous vous trompez, dans le bon sens! J'ai essayé d'hiberner Windows et de démarrer sous Ubuntu et de monter le système de fichiers Windows, et cela fonctionne, sans corruption lorsque vous relancez Windows à partir de l'hibernation! Ça m'a étonné.
Ryan Thompson
IMHO dont parlent les personnes corrompues est très probablement lié au fait que le pilote Linux NTFS n'est pas totalement compatible avec toutes les fonctionnalités NTFS. Il est préférable de monter en lecture seule.
Matt H
Ok, vous voudriez aussi lire Est-ce que NTFS sur Ubuntu est stable?
Nik
nik a raison - ne montez pas la partition à partir de l'autre système d'exploitation, elle est toujours montée dans le système d'exploitation en veille prolongée. Vous ne monteriez pas la même partition sur deux machines virtuelles (utilisant un accès direct à une partition) s'exécutant en même temps, n'est-ce pas?
Ben Voigt
8

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.

CtC
la source
4

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.

Percée
la source
3
Expérience de pensée: que se passe-t-il si un document ou un fichier est ouvert dans une application Windows (par exemple, vous modifiez un document Word), puis vous mettez en veille prolongée et démarrez sous l'autre système d'exploitation. Il n'y a plus de verrou de fichier actif, donc autant que sache Linux, il peut tout faire en toute sécurité. Par conséquent, si vous décidez que le fichier est mal classé et que vous le déplacez dans un autre répertoire, Linux vous le permet. Lorsque vous redémarrez Windows, que fait Word si son fichier a soudainement disparu? Maintenant, imaginez ce qui se passerait si ce fichier était plus vital qu'un document Word? Le montage en lecture seule sera beaucoup plus sûr.
GAThrawn
1
Cela s'avère être la réponse la plus précise. En fait, vous pouvez monter et apporter des modifications au lecteur Windows C pendant l'hibernation de Windows, sans vous plaindre. Je n'ai pas testé cela avec Linux, mais je soupçonne que cela ne fonctionnera pas.
Ryan Thompson
@ Ryan, c'est possible, mais ce n'est pas sûr à 100%. NTFS pourrait être cassé beaucoup trop facilement. Un autre problème est que Linux et Windows utilisent NTFS légèrement différents de sorte que ce qui fonctionne avec Windows peut ne pas fonctionner avec Linux. Ces différences pourraient aboutir à une corruption de FS, en particulier dans un tel état d'extrémité de FS.
Vava
@GAThrawn - Que fait Word? Essayez de modifier de force un document Word sous Windows et voyez ce qui se passe. Des programmes existent pour supprimer les verrous de fichiers. @vava - Tant que vous utilisez un programme / système d'exploitation conforme à NTFS MFT et au Journal, tout devrait bien se passer.
Percée
Je sais que ce n'est pas sûr à 100%, mais le fait est que si je monte accidentellement le système de fichiers Windows sous Linux après avoir hiberné Windows, le résultat n'est pas une corruption instantanée et irrécupérable. En d'autres termes, je devrais en fait faire un effort si je voulais me tirer une balle dans le pied.
Ryan Thompson
4

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.

Daniel
la source
3
En d'autres termes ... Si vous passez en veille prolongée sur disque, n'utilisez pas de lecteur partagé. (ou, si vous utilisez Linux, démontez ce lecteur avant de passer en hibernation)
Denilson Sá Maia
4

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.

utilisateur3671607
la source
La chose la plus effrayante pour moi: cela semble être un disque de données, non? Donc, ce n'est même pas l'état de l'OS lui-même qui est en hibernation sur ce disque USB, mais seulement des données? Dans ce cas, je m'attendrais à ce que les logiciels écrivent correctement sur le disque lorsqu'ils reçoivent le signal que le système d'exploitation est sur le point de passer en veille prolongée. Mais apparemment pas ...
Arjan le
1
Exactement. C'est un disque de données. Aucun fichier lié au système d'exploitation. Désolé de ne pas insister là-dessus. En fait, c’est la raison pour laquelle j’ai senti le besoin d’ajouter ma contribution. Quand j'ai diagnostiqué cela pour la première fois, on m'a dit qu'il était logique de ne pas le faire, mais bien que je sois un professionnel, cela ne semble pas évident du tout et c'est un scénario si susceptible de se produire avec des disques externes. Je suppose que la raison pour laquelle on n'en parle pas couramment est que peu de gens se donnent vraiment beaucoup de mal pour l'analyser et le diagnostiquer. Laissez seul signaler.
user3671607
Peut-être une question idiote: avez-vous retiré le lecteur en toute sécurité (c'est-à-dire, le gestionnaire de fichiers, un clic droit sur le périphérique et l'éjecter) avant de mettre en veille prolongée ou avez-vous simplement tiré le lecteur?
Jeu
Oui, c'est un commentaire idiot: comment retirer un lecteur en toute sécurité lorsque l'ordinateur est en veille prolongée?
user3671607
3

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


la source
3

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.

Finlandais
la source
2

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


la source
2

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


la source
1
Oui, c'est lié à la mise en cache, et non, "optimiser pour une suppression rapide" ne vous aidera pas. Cela permet à Windows d'écrire immédiatement les modifications, mais Windows présumera toujours (dangereusement) que son cache de lecture est valide à 100% et ne verra pas les modifications apportées par d'autres systèmes d'exploitation au disque.
Ben Voigt
1

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.

spa
la source
2
Les métadonnées du système de fichiers indiquent si elles sont correctement montées ou non ... Je pense également que le comportement correct est que le pilote Linux NTFS vérifie cet indicateur.
Ben Voigt
1

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.

Varso
la source
Eh bien, quels fichiers ont été corrompus? Seulement ceux appartenant à Thunderbird ou à plusieurs fichiers indépendants? Il peut sembler logique que si Thunderbird est exécuté à partir du même emplacement dans la partition 3, il existe deux ensembles de données différents dans deux systèmes différents. L'un tentera de forcer l'autre.
Doktoro Reichard
0

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.

Lie Ryan
la source
Quel FS utilisez-vous sur la partition partagée? Je commence à penser que peut-être NTFS a quelque chose à voir avec cela, tout le monde se plaint que leur partition NTFS partagée est corrompue.
Rolf
@Rolf: NTFS avec pilote ntfs-3g sous Linux. En outre, il s’agissait uniquement d’une partition de données, à l’exception d’applications telles que Firefox / Thunderbird, qui, je le sais, contient des avertissements relatifs à un arrêt non propre, et que je fermerais toujours avant de changer de système d’exploitation.
Lie Ryan
Peut-être que FAT ferait l'affaire? NTFS est préférable, mais dans ce cas, il semble ne pas bien fonctionner, pour le moins. En outre, si nous pouvons faire en sorte que le système vide tout le tampon sur le disque avant de passer en hibernation, cela aidera peut-être. Mais je suppose qu'il serait préférable d'expérimenter différents systèmes de fichiers (EXT ou d'autres peuvent également être des options) pour la partition partagée. Si quelqu'un est prêt à le faire :) Peut-être dans une machine virtuelle? BTW j'ai rencontré le même problème en utilisant une machine virtuelle, en sauvegardant l'état, puis en utilisant la même machine virtuelle (même fichier) mais sous un autre système d'exploitation. L'hôte VM n'était pas au courant de l'état enregistré.
Rolf
1
Donc, ce que vous dites, c'est que si nous nous souvenons de fermer tous les descripteurs de fichiers sur la partition partagée avant de mettre en hibernation, cela devrait alors être OK.
Rolf
0

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.

Rolf
la source
L'état de sauvegarde de Virtual Box est totalement différent de l'hibernation. Enregistrer l'état est une fonctionnalité de la machine virtuelle, pas une fonctionnalité du système d'exploitation. Le système d'exploitation ignore totalement quand une sauvegarde est en cours. L'état de sauvegarde n'est pas stocké dans l'image du disque virtuel, mais dans un autre fichier. Virtual Box peut en réalité restaurer l'état enregistré sur un autre ordinateur, cela s'appelle la téléportation.
Lie Ryan
-3

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.

Josh Hunt
la source
Je ne parle pas de suspendre à la RAM, je veux dire hibernation sur disque. Je vais modifier la question pour qu'elle soit plus précise.
Ryan Thompson
7
Cela me semble faux. En hibernation, l'ordinateur est éteint. Lorsque vous le redémarrez, il passe par le BIOS et le POST. Ce n’est que lorsque le chargeur de système d’exploitation voit qu’il a été mis en veille prolongée qu’il charge le fichier contenant l’état de la mémoire (hiberfil.sys pour Windows) et restaure le système d’exploitation.
Snark
Non, cela entraînera des problèmes de cohérence du système de fichiers. Voir mon post ci-dessus.
Nathan Osman
@ George: Il y aura des problèmes de cohérence des systèmes de fichiers si vous partagez des systèmes de fichiers entre les deux systèmes d'exploitation. Mais vous pouvez certainement exécuter un système d'exploitation différent qui possède son propre ensemble de partitions, contrairement à cette réponse.
Ben Voigt
S'il ne passait pas par le BIOS et le POST, il ne serait pas possible de choisir le système d'exploitation au démarrage et de faire des messages tels que ceux décrits ici. Hibernate n'est pas suspendu à bélier.
Rolf