Description of problem: If you used sleep during a Windows 10 session, even if you then awoke from it and shut down Windows properly, Linux thinks that Windows was shut down unsafely. Version-Release number of selected component (if applicable): 2.38.1-1 How reproducible: Always Steps to Reproduce: 1. Make sure that fstab has Windows mounted normally. (This is Windows 10. UEFI is not being used. I don't know if that affects it.) # Entry for /dev/sda2 : UUID=01D06E56E0E37430 /media/windows ntfs-3g defaults,nofail,umask=000 0 0 2. In Windows, make sure that "Turn on fast startup (recommended)" is off. 3. Reboot a couple of times (shutdown -r now in Linux, Power and Restart in Windows) and confirm that the Windows partition is mounted rw in Linux. 4. Reboot to Windows. Put Windows in sleep mode. Awaken Windows from sleep mode. 5. Reboot to Linux. Notice that the partition is mounted ro. 6. If you manually try to umount and mount it you get: Windows is hibernated, refused to mount. Falling back to read-only mount because the NTFS partition is in an unsafe state. Please resume and shutdown Windows fully (no hibernation or fast restarting.) Could not mount read-write, trying read-only Windows had been put into sleep mode in the middle of the Windows session, but it had then been awakened and shut down properly. It is not recognized as having been shut down properly.
Thank you for the report. Can we take it that if you do not 'sleep' Win, and shut it down properly, that Mageia does indeed then mount the NTFS partition r/w ? It does look as if despite the precautions you take that Win shuts down correctly, it must be leaving its filesystem in an abnormal state after a sleep. Is it indeed cleanly and completely shut down? "Turn on fast startup" is off; maybe there is something more. Can you try: - Win session, sleep, wakeup, shut down correctly - Another Win session, no sleep, shut down correctly. - Boot Mageia: how is the NTFS filesystem mounted, r or rw ?
CC: (none) => lewyssmith
I've already done these things as stated in the bug report. The results are as described above: Win session, sleep, wakeup, shut down correctly: mounted ro Another Win session, no sleep, shut down correctly: mounted rw
Thank you for that confirmation. Looking into ensuring Win10 shuts down properly: 1) As you already do: disable Fast Startup This is cited everywhere, and should apparently be effective. However, there are other methods cited which would be worth exploring as they are easy: 2) hold Shift as you click “Shut Down” to perform a full shutdown You can also perform a full shut down by pressing and holding the Shift key on your keyboard while you click the “Shut Down” option in Windows. This works whether you’re clicking the option in the Start menu, on the sign-in screen, or on the screen that appears after you press Ctrl+Alt+Delete 3) click the “Restart” option in the menu instead of the “Shut Down” option. Windows restarts your computer, but it performs a full shut down first “Restart” option performs a more complete shut down than the “Shut Down”. For rebooting directly from Win to Mageia, this looks the best bet - if it works! 4) you can instead perform a full shutdown by using the shutdown command from a Command Prompt: > shutdown /s /f /t 0 The shutdown command will always perform a full shutdown (unless you add the /hybrid option). If it’s something you want to keep handy, you can also make a shortcut that executes this command. All you have to do then is double-click the shortcut to perform a full shutdown It would be worth knowing whether any of these avoids the problem you report; they are all easy to try.
Holding shift doesn't help. I was using restart anyway; it doesn't help. The command prompt shutdown doesn't help.
Did you disable the fastboot feature in windows 10?
I literally said that in the first post. 2. In Windows, make sure that "Turn on fast startup (recommended)" is off.
This look like an old headache with windows partitions https://askubuntu.com/questions/145902/unable-to-mount-windows-ntfs-filesystem-due-to-hibernation https://wiki.manjaro.org/index.php/How_to_mount_Windows_(NTFS)_filesystem_due_to_hibernation In resume, you should always power off from windows before boot windows
(In reply to katnatek from comment #7) > This look like an old headache with windows partitions > > https://askubuntu.com/questions/145902/unable-to-mount-windows-ntfs- > filesystem-due-to-hibernation > https://wiki.manjaro.org/index.php/ > How_to_mount_Windows_(NTFS)_filesystem_due_to_hibernation > > In resume, you should always power off from windows before boot windows before boot windows -> before boot linux
@Ken Thank you for trying the various ways of shutting down Windows - in vain; it made no difference, but that is worth knowing. I have let this run in the hope of finding a neat solution, but that remains: - Stop fast Windows startup. - Windows session with sleep, resume, close down cleanly. - Another (if null) Windows session with no sleep, shut it down cleanly. - Linux session, should mount common NTFS partitions 'rw'. This is clearly a Windows problem. The best we can do is ERRATA it for M9, and add a RELEASE NOTE for M10.
Keywords: (none) => FOR_ERRATA9, FOR_RELEASENOTES10Resolution: (none) => INVALIDStatus: NEW => RESOLVED
It turns out that powercfg /h off in Windows does actually fix it. But given how Windows is supposed to work, this should not be necessary; fast startup is not on and Windows is being turned off in a way that does not lead to any hibernation.
This (powercfg /h off) is an excellent discovery - well done; I saw no mention of it in my search. If you can make a shortcut to the command, that would be easy to execute. We can certainly document it.
Change to WorksForMe due comment#10
Resolution: INVALID => WORKSFORME
Change keyword to flag status
Flags: (none) => in_release_notes10?Keywords: FOR_RELEASENOTES10 => (none)
(In reply to Lewis Smith from comment #11) > This (powercfg /h off) is an excellent discovery - well done; I saw no > mention of it in my search. > If you can make a shortcut to the command, that would be easy to execute. We > can certainly document it. This is in addition to disable fast startup right?
Flags: in_release_notes10? => in_errata10+
Keywords: FOR_ERRATA9 => IN_ERRATA9
Hold horses a bit. _________Regarding the errata entries I have been dual boooting for two decades and it still works splendid on my MSWindows XP / Mageia 9 lxde setup, tested right now: Boot XP, let it hibernate. Boot mga9, edit a file on windows drive OK, try save: it protest = Perfect. Shut down mga9, Boot XP (it restores session), shut it down. Boot mga9, edit a file on windows drive OK, try save: OK = Perfect. Yes one usability bug is in later Windows UI is tah users are fooled to believe system is shut down when in reality it is hibernated: that is an upstream issue at Microsoft. Another usability thing is that some tools in Mageia protest, other just silently (invisible to the user) mount the drive readonly, and user do not notice until they want to save a file there. What i think we should have in errata is a *very short* note something like: "To access Microsoft Windows files in dual boot setups see <here>" <here> = https://wiki.mageia.org/en/Mageia_in_dual_boot_with_Windows8_and_over#Cannot_mount_NTFS_partition_even_though_secure_boot_and_fast_boot_are_disabled_in_Windows - and improve that page as you wish :-) We also seem to have another similar page too https://wiki.mageia.org/en/Installation_of_Mageia_in_dual_boot_with_Windows _________Back to *this* bug As I understand it, Ken experienced that after Windows 10 had been suspended then woken, then hibernated - then linux mounted it ro. So that is an anomaly, and if it exist it is probably in Windows 10... and that release is EOL anyway. Se we keep this bug closed worksforme.
Keywords: IN_ERRATA9 => FOR_ERRATA9Flags: in_errata10+ => in_errata10?Status comment: (none) => revise errata entries pleaseCC: (none) => fri