Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Dual boot partitions Windows et DataCommuns (NTFS)montées en root [RE]

Coeur Noir

@Phil17 - pour expliquer la remarque de moko :

Par défaut un système windows récent utilise la fonction « démarrage rapide », qui est une forme d'hibernation ( les disques sont alors protégés en écriture ). On peut manuellement désactiver cette fonction ( ce que tu avais fait ) afin de s'assurer que le système windows soit complètement éteint et, en quelque sorte, « libère » les disques de son emprise.

Or au cours des mises à jour « normales » du système windows, il est assez fréquent que des paramètres système soient ramenés à leur valeur initiale par défaut : tu avais manuellement désactivé démarrage rapide & hibernation, une m.à.j windows les aura plus tard réactivé.

Phil17

J'entends bien, on est d'accord tous les trois sur ce point que Windows rétablit les paramètres par défaut de son système sans prévenir et en écrasant les paramètres utilisateur, ce qui est "un peu" intrusif. Mais bon, MicroMou n'en est pas à une dérive.
Je cherche comment m'affranchir (sans avoir de VM que je n'arrive pas à faire correctement fonctionner) de cet OS boulet qui en plus me prend 50Go d'espace disque. Mais ce n'est pas important.
Bonne fin de dimanche à vous deux !
Phil

Pit38f

Bonjour

J'ai aussi eu ce souci (système pari en hibernation, on revient plusieurs après : écran noir, on ne souvient pas qu'on était avant sur Windows, donc démarrage sur Linux).
Auparavant dans une version précédente d'Ubuntu le verrouillage était signalé clairement par le système, donc on quittait Linux, on lançait Windows et on le fermait proprement par un shutdown /s /t 0.
Avec la version actuelle il faut aller dans les propriétés de la partition pour voir qu''on n'a pas le droit d'écrire sur la partition
Cela fait perdre du temps, l'avertissement d'avant était très utile.
Nous sommes, malheureusement, nombreux à devoir rester avec un dual boot, et je ne pense pas que cela change, donc revenir à la méthode de la version d'avant, ce serait bien.

Phil17

Comme je l'écrivais plus haut : " Tous les répertoires et fichiers qui la composent sont cadenassée. Je peux lire ou copier mais et c'est un peu gênant, je ne peux pas mettre à la corbeille un fichier ou répertoire.
Je suis le propriétaire de cette partition et j'ai accès en lecture et écriture, je fais partie de mon groupe (phil) mais c'est tout ce que je constate."

Maintenant que tout est revenu dans l'ordre, je constate que les propriétés de cette partition "DataCommun"" sont identiques, mêmes droits pour le même propriétaire à lire, écrire, seul indice, le cadenas qui n'est plus sur les noms des répertoires. Pas facile à comprendre. Possible que dans le Terminal on verra bien d'autres indices sous forme de lettres, mais je n'arrive pas à les comprendre de mon côté.

Coeur Noir

Ce qui est montré dans DataCommun provient d'une partition de disque formatée en NTFS, utilisée par ton Windows.
Lorsque Windows passe en mode hibernation / démarrage rapide, il « gèle » alors l'état de toutes les données qu'il était en train d'utiliser à ce moment là ( disques, ram ), en enlevant la possibilité d'y écrire.
Ça lui ( Windows ) permet au démarrage suivant d'être plus rapide car il n'a pas à re-lire et re-monter toutes ces ressources, il les retrouve immédiatement dans le même état, en quelque sorte pré-chargées.

C'est donc Windows qui a agi, sur son système de fichiers à lui, NTFS, en enlevant la possibilité d'y écrire.

Si, après que Windows ait « gelé » telle partition NTFS, tu démarres un Linux et essaies d'accéder à cette partition, bah Linux ne saura pas non plus y écrire quand bien même ton utilisateur sous Linux aurait les droits nécessaires sur cette partition : l'écriture est bloquée au niveau du NTFS ( et non par ton Linux ) et c'est tout ce qu'il saura te dire : au mieux accès en lecture seule, au pire pas d'accès du tout. Le cadenas indiquait l'absence du droit écriture ( modification impossible ). Une petite croix indiquera l'absence d'exécution ( sur un dossier ça veut dire pas d'accès du tout, impossible de l'ouvrir ).

Chez toi, cette partition NTFS est inscrite dans le fichier fstab afin d'être montée dans ton système Linux dans le dossier DataCommun dès le démarrage.
On pourrait sans doute mieux gérer l'éventuelle indisponibilité de cette partition ( quand elle est « gelée » par hibernation / démarrage rapide ) via une ou des options adéquates sur sa ligne de montage dans le fstab.
Pour ça faudrait que je fouille un peu. Ou demander de l'aide à ce sujet - Moko 😃 ? - je pense aux options nofail et errors=remount-ro, s'appliquent-elles à du NTFS ?

Bref, le plus simple pour l'instant : quand tu quittes ton Windows, s'assurer de vraiment l'éteindre ( et pas le mettre en démarrage rapide / hibernation ).

Phil17

Merci Cœur Noir des explications complémentaires à la compréhension de l'accès Linux sur une partition NTFS bloquée par Win.
J'ai (j'avais) bloqué toute hibernation ou mise en veille sous Win, mais comme je l'écris au dessus, suite à une MàJ, WIn a dû remettre les pendules à zéro (sauf l'hibernation mais je n'ai pas vérifié).
J'irai vérifier ces réglages d'hibernation et mise en veille, et de toute façon, chercher un moyen de ne faire QUE les MàJ de sécurité (genre anti-virus intégré) et les MàJ des pilotes. Là, il veut faire toutes les MàJ et ça ne me plaît pas vraiment...
Heureusement, je ne m'en sers que rarement de cet OS.

Coeur Noir

T'as vu, je fais du SAV à long terme :lol:

Pour Win10, je crois bien que c'est tout ou rien pour les mises à jour.

Je lis dans ta signature Usage à 99,9% de Xubuntu : quels sont donc les logiciels dont tu n'arrives pas à te passer sous Windows ?

Notes :
⋅ tant que tu utilises une ou des partitions NTFS, il faut impérativement te garder un Windows opérationnel sous le coude car il est le seul à savoir correctement réparer ce système de fichiers.
⋅ si un jour tu bascules à 100% Linux, il est inutile voire risqué de conserver des partitions NTFS dans un contexte sans Windows.

Phil17

Et encore merci pour le SAV !
:-)
Il y a quelques logiciels spécifiques nautisme, et uniquement sous Windoze, et éventuellement Captv, mais rarement.
Pour Win, je confirme qu’effectivement, maintenant, les "mises à jours" de L'OS sont en fait le téléchargement et l'installation de la nouvelle image, direct ! Avec, cerise sur le gâteau, mise en back-up de l'ancien OS windows (windows.old), ce qui fait que je me demande si MicroMou ne travaille pas avec les vendeurs de disques dur !
Pour NTFS, j'ai regardé un peu de littérature, sous Linux pur, oui, aucun besoin d'une partition NTFS. Tout en Ext4.

Coeur Noir

Ton ordi a l'air taillé pour la virtualisation, tu devrais regarder ce domaine.
Je ne saurais pas t'aider, trop peu pratiqué. Un truc comme gnome-boxes pour lancer depuis Linux, un Windows depuis son image .iso ( celui dont tu as la licence, livré avec ton pc ).

moko138

Phil17 a écritPossible que dans le Terminal on verra bien d'autres indices sous forme de lettres, mais je n'arrive pas à les comprendre de mon côté.

Oui, quand un NTFS est monté et que tu lances

mount -l | grep fuseb

La réponse est soit
/dev/sdxn on /media/Data-1To type fuseblk (rw, +les options) [ÉTIQUETTE]
(read write, lecture écriture)
soit
/dev/sdxn on /media/Data-1To type fuseblk (ro, +les options) [ÉTIQUETTE]
(read only, lecture seule).

[center]= =[/center]

Coeur Noir a écrit On pourrait sans doute mieux gérer l'éventuelle indisponibilité de cette partition ( quand elle est « gelée » par hibernation / démarrage rapide ) via une ou des options adéquates sur sa ligne de montage dans le fstab.
Pour ça faudrait que je fouille un peu. Ou demander de l'aide à ce sujet - Moko 😃 ? - je pense aux options nofail et errors=remount-ro, s'appliquent-elles à du NTFS ?

Oui, nofail fonctionne sur du ntfs (et sur une swap) et était bien pratique avant, pour éviter que le démarrage ne soit gelé 90 secondes (après quoi il poursuivait sans monter le ntfs ou sans activer la swap).
À présent, nofail est moins intéressant sur du ntfs.

Je suis presque sûr d'avoir lu qu"à partir de 20.04, Ubuntu pouvait forcer le remontage du ntfs en "rw", en retirant à la main le "dirty bit". Mais je ne le conseille pas !
Car si le "dirty bit" a été posé par Windows pour signaler un problème requérant une vérification du système de fichiers avant tout remontage (et c'est, à ma connaissance, la première fonction du "dirty bit" !), alors le retirer à la main et écrire sur un ntfs en vrac, c'est courir au-devant de la perte de fichiers.

Coeur Noir

[ HS, pour moko ]
Oui, nofail fonctionne sur du ntfs (et sur une swap) et était bien pratique avant, pour éviter que le démarrage ne soit gelé 90 secondes (après quoi il poursuivait sans monter le ntfs ou sans activer la swap).
À présent, nofail est moins intéressant sur du ntfs.
Donc faut-il le laisser en exemple, là → https://forum.ubuntu-fr.org/viewtopic.php?pid=22354480#p22354480 → ou au moins indiquer quelque part les intérêt et limite de nofail sur ntfs ?
Je le ferais volontiers - si je savais quoi dire ;-)
[ / HS ]

moko138

[HS] Oui, nofail est toujours utile !
Si une ligne de fstab est erronée, l'option nofail évite de patienter 90 secondes pour rien. (Et cela vaut aussi pour de l'ext* et pour du linux-swap).

Là où nofail a perdu de son intérêt, c'est pour les FS verrouillés par Windows :
il y a quelques années (quand Win8 est sorti), Ubuntu figeait le démarrage pendant 90 secondes. Mais les versions récentes d'Ubuntu, sauf erreur de ma part, n'attendent plus et montent ces FS en lecture seule.
[/HS]

Edit : orthographe.

« Page précédente