A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Windows is hibernating



 
 
Thread Tools Rate Thread Display Modes
  #1  
Old February 9th 19, 01:57 AM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only". I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

# ntfsfix -d device (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off. Then I ran a

chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T
Ads
  #2  
Old February 9th 19, 05:46 AM posted to alt.comp.os.windows-10,comp.os.linux.misc
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default Windows is hibernating

On 09/02/2019 01.57, T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?


When I want to be sure, I tell Windows to reboot, not to poweroff.


--
Cheers, Carlos.
  #3  
Old February 9th 19, 05:50 AM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/8/19 8:46 PM, Carlos E.R. wrote:

What am I doing wrong?


When I want to be sure, I tell Windows to reboot, not to poweroff.



I used

shutdown /r /f /t 00

from the Windows command line at least twice.

:'(

  #4  
Old February 9th 19, 06:06 AM posted to alt.comp.os.windows-10,comp.os.linux.misc
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows is hibernating

T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only". I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

# ntfsfix -d device (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off. Then I ran a

chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


https://askubuntu.com/questions/7028...t-as-read-only

"The system might not have the files for writing to
NTFS partitions installed.

Try this in terminal:

sudo apt-get remove ntfsprogs && sudo apt-get install ntfs-3g

This removes ntfsprogs if it's present on the system, and
installs ntfs-3g which should allow you to write properly
to NTFS partitions.

Then reboot your system, and attempt to open the NTFS drive
for write access. You should now be able to write to the
NTFS drive.
"

Fedora is supposed to have an $MFTMIRR fix. Namely, it ignored
MFTMIRR and removed the normal check. Windows 10, when it creates
partitions, makes them each with a $MFTMIRR problem. Other Linux
distros trip over this. Win7 CHKDSK can fix it (silently, no status
message during CHKDSK run).

This utility is available on a lot of distros, but is not
part of the default install. You'll need to install it.

http://disktype.sourceforge.net/

sudo disktype /dev/sdX

It might indicate there's some problem.

NTFS might not mount if:

1) Hibernation:

Windows: powercfg /h off

disables both Fast Boot and hibernation to hiberfil.sys

2) NTFS doesn't know how to handle the USN Journal, so it
has the option of invalidating it. Such a thing happens
if you're in write mode and write something. You can erase
the USN Journal while in Windows, although I doubt this would
change anything in a positive way. The Search Indexer will need
to start indexing all over again, on Windows.

3) The NTFS driver may not know what to do with 4Kn disks.
Probably works just fine with 512n and 512e drives.

4) Windows 10 changed cluster size support to 64K. *Don't*
use this feature. It ruins compatibility across Windows systems.
A Windows 7 OS is not going to know what to do when a 2MB cluster
size shows up. Windows 10 uses 4KB clusters for the OS (this became
mandatory part way through the releases). At one time, I had
Windows 10 on a 64KB cluster partition, and it was running fine,
until one day an OS Upgrade came in and said "nuh uh" and I had
to change it. You can make data partitions with 64KB clusters,
and this will work across OSes.

5) Disks can be set up MBR or GPT. I don't know if there are any
issues with partitions on such. I've never seen a problem because
of it. fdisk for mbr, gdisk for gpt.

6) Windows 10 uses Reparse Points, with at least three types of
Reparse Points, if not more. A Junction Point is the oldest custom
NTFS mod. A more recent introduction was a second form of NTFS
compression, uses on WinSXS materials or a few files in System32
seem to be using it, even after the compression has been disabled.
"Normal" NTFS driver response is "I/O error" when an attempt it
made to stat the NTFS files in question. The Linux file manager
will refuse to finish painting the directory contents screen
on the first "I/O error" file it sees.

Lots of these things should not stop mounting in read/write.
They can cause problems when accessing various parts of the disk.

You can start with "powercfg /h off" then go back to Linux
for a look. Next, I'd check whether the packages are set up
properly for what you're doing.

The partition can't be encrypted, because you probably would
not have got as far as you did, if it was. It's not normal
for encryption systems to leave filenames exposed. Options
would be BitLocker (which can use disk drive encryption if it
detects it), TrueCrypt/Veracrypt, or builtin Windows EFS. EFS
might leave the filenames visible. In Windows normally,
compressed and encrypted files are "colored" in File Explorer.
The NTFS new compression might not have a color. Don't know of
any other flavors with colored indicators.

GetFileAttributes function:

FILE_ATTRIBUTE_READONLY = 1 (0x1)
FILE_ATTRIBUTE_HIDDEN = 2 (0x2)
FILE_ATTRIBUTE_SYSTEM = 4 (0x4)
FILE_ATTRIBUTE_DIRECTORY = 16 (0x10)
FILE_ATTRIBUTE_ARCHIVE = 32 (0x20)
FILE_ATTRIBUTE_NORMAL = 128 (0x80)
FILE_ATTRIBUTE_TEMPORARY = 256 (0x100)
FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200)
FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400) Extended attribute used for "new" compression
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800) Original NTFS compression
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000)

File attributes can be read with

fsutil usn readdata C:\path\to\some\file.ext

*******

You can also use the "second opinion" method. Boot
up a Ubuntu USB key and check whether you can examine
C: from there. You should start with being denied because
of $MFTMIRR damage (chkdsk, Win7, to fix) or the perception
of being hibernated (powercfg /h off, verify C:\hiberfil.sys
is gone). Then Ubuntu should at least allow casual examination
of /media/mount/Win10/users/username/Downloads or similar.
Fiddling with System32 or WinSXS is less certain.

And CHKDSK is a bit of a bear, in that some forms of
damage *do not* leave a message on the screen during
a run. You examine the "fluffy" options you don't normally
use, and switch those on when a partition "seems" to have
a problem, but running a repair doesn't seem to be helping.
Note that Win7 CHKDSK on a Win10 volume really isn't ideal,
but how the hell else are you going to fix MFTMIRR ? It
seems Win7 CHKDSK really wasn't backported for Win10 changes,
and it *does* mess around with stuff that it should not. But
visually, the storage volume still works afterwards. That's
the best that I can manage :-/

In an Administrator Command Prompt while in Windows 10

compact /compactOS:query # shows whether "OS wants to compress"
compact /compactOS:never # user tells OS to screw off. This allows
# at least some of WinSXS or System32 files
# to be accessed. I failed today to make
# System32 completely visible this way!

Paul
  #5  
Old February 9th 19, 06:57 AM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/8/19 9:06 PM, Paul wrote:
T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


https://askubuntu.com/questions/7028...t-as-read-only


Â*Â* "The system might not have the files for writing to
Â*Â*Â* NTFS partitions installed.

Â*Â*Â* Try this in terminal:

Â*Â*Â*Â*Â*Â* sudo apt-get remove ntfsprogs && sudo apt-get install ntfs-3g

Â*Â*Â* This removes ntfsprogs if it's present on the system, and
Â*Â*Â* installs ntfs-3g which should allow you to write properly
Â*Â*Â* to NTFS partitions.

Â*Â*Â* Then reboot your system, and attempt to open the NTFS drive
Â*Â*Â* for write access. You should now be able to write to the
Â*Â*Â* NTFS drive.
Â*Â* "

Fedora is supposed to have an $MFTMIRR fix. Namely, it ignored
MFTMIRR and removed the normal check. Windows 10, when it creates
partitions, makes them each with a $MFTMIRR problem. Other Linux
distros trip over this. Win7 CHKDSK can fix it (silently, no status
message during CHKDSK run).

This utility is available on a lot of distros, but is not
part of the default install. You'll need to install it.

http://disktype.sourceforge.net/

Â*Â* sudo disktype /dev/sdX

It might indicate there's some problem.

NTFS might not mount if:

1) Hibernation:

Â*Â* Windows:Â* powercfg /h off

Â*Â* disables both Fast Boot and hibernation to hiberfil.sys

2) NTFS doesn't know how to handle the USN Journal, so it
Â*Â* has the option of invalidating it. Such a thing happens
Â*Â* if you're in write mode and write something. You can erase
Â*Â* the USN Journal while in Windows, although I doubt this would
Â*Â* change anything in a positive way. The Search Indexer will need
Â*Â* to start indexing all over again, on Windows.

3) The NTFS driver may not know what to do with 4Kn disks.
Â*Â* Probably works just fine with 512n and 512e drives.

4) Windows 10 changed cluster size support to 64K. *Don't*
Â*Â* use this feature. It ruins compatibility across Windows systems.
Â*Â* A Windows 7 OS is not going to know what to do when a 2MB cluster
Â*Â* size shows up. Windows 10 uses 4KB clusters for the OS (this became
Â*Â* mandatory part way through the releases). At one time, I had
Â*Â* Windows 10 on a 64KB cluster partition, and it was running fine,
Â*Â* until one day an OS Upgrade came in and said "nuh uh" and I had
Â*Â* to change it. You can make data partitions with 64KB clusters,
Â*Â* and this will work across OSes.

5) Disks can be set up MBR or GPT. I don't know if there are any
Â*Â* issues with partitions on such. I've never seen a problem because
Â*Â* of it. fdisk for mbr, gdisk for gpt.

6) Windows 10 uses Reparse Points, with at least three types of
Â*Â* Reparse Points, if not more. A Junction Point is the oldest custom
Â*Â* NTFS mod. A more recent introduction was a second form of NTFS
Â*Â* compression, uses on WinSXS materials or a few files in System32
Â*Â* seem to be using it, even after the compression has been disabled.
Â*Â* "Normal" NTFS driver response is "I/O error" when an attempt it
Â*Â* made to stat the NTFS files in question. The Linux file manager
Â*Â* will refuse to finish painting the directory contents screen
Â*Â* on the first "I/O error" file it sees.

Lots of these things should not stop mounting in read/write.
They can cause problems when accessing various parts of the disk.

You can start with "powercfg /h off" then go back to Linux
for a look. Next, I'd check whether the packages are set up
properly for what you're doing.

The partition can't be encrypted, because you probably would
not have got as far as you did, if it was. It's not normal
for encryption systems to leave filenames exposed. Options
would be BitLocker (which can use disk drive encryption if it
detects it), TrueCrypt/Veracrypt, or builtin Windows EFS. EFS
might leave the filenames visible. In Windows normally,
compressed and encrypted files are "colored" in File Explorer.
The NTFS new compression might not have a color. Don't know of
any other flavors with colored indicators.

GetFileAttributes function:

FILE_ATTRIBUTE_READONLY = 1 (0x1)
FILE_ATTRIBUTE_HIDDEN = 2 (0x2)
FILE_ATTRIBUTE_SYSTEM = 4 (0x4)
FILE_ATTRIBUTE_DIRECTORY = 16 (0x10)
FILE_ATTRIBUTE_ARCHIVE = 32 (0x20)
FILE_ATTRIBUTE_NORMAL = 128 (0x80)
FILE_ATTRIBUTE_TEMPORARY = 256 (0x100)
FILE_ATTRIBUTE_SPARSE_FILE = 512 (0x200)
FILE_ATTRIBUTE_REPARSE_POINT = 1024 (0x400)Â* Extended attribute used for
"new" compression
FILE_ATTRIBUTE_COMPRESSED = 2048 (0x800)Â*Â*Â*Â* Original NTFS compression
FILE_ATTRIBUTE_OFFLINE = 4096 (0x1000)
FILE_ATTRIBUTE_NOT_CONTENT_INDEXED = 8192 (0x2000)
FILE_ATTRIBUTE_ENCRYPTED = 16384 (0x4000)

File attributes can be read with

Â*Â* fsutil usn readdata C:\path\to\some\file.ext

*******

You can also use the "second opinion" method. Boot
up a Ubuntu USB key and check whether you can examine
C: from there. You should start with being denied because
of $MFTMIRR damage (chkdsk, Win7, to fix) or the perception
of being hibernated (powercfg /h off, verify C:\hiberfil.sys
is gone). Then Ubuntu should at least allow casual examination
of /media/mount/Win10/users/username/Downloads or similar.
Fiddling with System32 or WinSXS is less certain.

And CHKDSK is a bit of a bear, in that some forms of
damage *do not* leave a message on the screen during
a run. You examine the "fluffy" options you don't normally
use, and switch those on when a partition "seems" to have
a problem, but running a repair doesn't seem to be helping.
Note that Win7 CHKDSK on a Win10 volume really isn't ideal,
but how the hell else are you going to fix MFTMIRR ? It
seems Win7 CHKDSK really wasn't backported for Win10 changes,
and it *does* mess around with stuff that it should not. But
visually, the storage volume still works afterwards. That's
the best that I can manage :-/

In an Administrator Command Prompt while in Windows 10

Â*Â* compact /compactOS:queryÂ*Â*Â*Â*Â*Â*Â*Â*Â* # shows whether "OS wants to
compress"
Â*Â* compact /compactOS:neverÂ*Â*Â*Â*Â*Â*Â*Â*Â* # user tells OS to screw off. This
allows
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # at least some of WinSXS or
System32 files
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # to be accessed. I failed today
to make
Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* Â*Â*Â*Â*Â*Â*Â*Â*Â*Â*Â* # System32 completely visible this
way!

Â*Â*Â* Paul


Thank you!

  #6  
Old February 9th 19, 03:04 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
😉 Good Guy 😉
external usenet poster
 
Posts: 1,483
Default Windows is hibernating

On 09/02/2019 04:46, Carlos E.R. wrote:
When I want to be sure, I tell Windows to reboot, not to poweroff.


There no such things as reboot in Windows 10 unless you have something
like this:

[ alt-No ] https://i.imgur.com/YV345Kb.jpg


In Windows 10 there is something called "Restart" and everybody should
use it once a week.

You may not know but the OP (who goes by the name of "T", "Tiger" and
"Todd & Margo") is a known Rogue Trader who is always trying to find new
ways to defraud customers who are old and very new to computers.


--
With over 950 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

  #7  
Old February 9th 19, 03:13 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
Paul[_32_]
external usenet poster
 
Posts: 11,873
Default Windows is hibernating

T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only". I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

# ntfsfix -d device (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off. Then I ran a

chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


I put Fedora-Workstation-Live-x86_64-29-1.2.iso on
a USB stick (by direct dd), and when booted, I had
no problem clicking on a Win10 volume and it mounted
RW as you would expect. I checked /etc/mtab to see
the mount arguments.

The Win10 volume uses my standard "powercfg /h off"
as configuration.

Paul
  #8  
Old February 9th 19, 05:26 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
dillinger
external usenet poster
 
Posts: 1
Default Windows is hibernating

On 2/9/19 1:57 AM, T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


You have to turn off hibernating completely, run

powercfg.exe /hibernate off

at an administrator command prompt

  #9  
Old February 9th 19, 11:41 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/9/19 6:04 AM, 😉 Good Guy 😉 wrote:


Thank you for helping me update my killfile. Bye, Bye, forever.

:')

  #10  
Old February 9th 19, 11:44 PM posted to comp.os.linux.misc,alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote:
In comp.os.linux.misc T wrote:
After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?


Are you mounting, in Linux, as ntfs or ntfs-3g?

The 'ntfs' Linux driver is read only.

The 'ntfs-3g' Linux driver is the read/write driver.

But, unless you ask mount to use ntfs-3g specifically, the
auto-detected default (at least on the one system I've got where I
mount an ntfs formatted USB drive [left as ntfs for compatibility with
a winblows system]) is 'ntfs'.


Depends on the distribution; for example on openSUSE the default is
ntfs-3g.


This is the only instance I have not been able to mount an NTFS
read/write with Fedora.

$ cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

$ rpm -qa ntfs\*
ntfs-3g-2017.3.23-8.fc29.x86_64
ntfsprogs-2017.3.23-8.fc29.x86_64

This is something windows is doing. I am going to try Rich's and
Paul's tips next time this happens.
  #11  
Old February 9th 19, 11:44 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/9/19 6:13 AM, Paul wrote:
T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


I put Fedora-Workstation-Live-x86_64-29-1.2.iso on
a USB stick (by direct dd), and when booted, I had
no problem clicking on a Win10 volume and it mounted
RW as you would expect. I checked /etc/mtab to see
the mount arguments.

The Win10 volume uses my standard "powercfg /h off"
as configuration.

Â*Â* Paul



Thank you!

  #12  
Old February 9th 19, 11:44 PM posted to alt.comp.os.windows-10,comp.os.linux.misc
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/9/19 8:26 AM, dillinger wrote:
On 2/9/19 1:57 AM, T wrote:
Dear Windows and Linux newsgroups,

I have a cross platform issue so I am cross posting.

Last week I booted two separate Windows 10 computer off a
Fedora 29 Xfce Live USB stick. I was able to
mount the Windows NTFS main drive, but only as
"read only".Â* I could see everything and did (I was
not in one of those screw ball hidden Windows
partitions), but could not touch anything.

After unmounting, I went to clear the dirty flag (from linux),

Â*Â*Â*Â* # ntfsfix -d deviceÂ*Â*Â* (/dev/sda1)

I got as message as that the dirty flag could not
be cleared because "Windows is hibernating".

I went back into Windows, made sure the "Fast Boot"
option was off (I had been on these machines before)
and it was still off.Â* Then I ran a

Â*Â*Â*Â* chkdsk c: /f

from Windows and rebooted, letting chkdsk run its course.

After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Many thanks,
-T


You have to turn off hibernating completely, run

powercfg.exe /hibernate off

at an administrator command prompt



Thank you!



  #13  
Old February 10th 19, 03:53 AM posted to comp.os.linux.misc,alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default Windows is hibernating

On 09/02/2019 23.44, T wrote:
On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote:
In comp.os.linux.misc T wrote:
After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Are you mounting, in Linux, as ntfs or ntfs-3g?

The 'ntfs' Linux driver is read only.

The 'ntfs-3g' Linux driver is the read/write driver.

But, unless you ask mount to use ntfs-3g specifically, the
auto-detected default (at least on the one system I've got where I
mount an ntfs formatted USB drive [left as ntfs for compatibility with
a winblows system]) is 'ntfs'.


Depends on the distribution; for example on openSUSE the default is
ntfs-3g.


This is the only instance I have not been able to mount an NTFS Â*Â*
read/write with Fedora.

$ cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

$ rpm -qa ntfs\*
ntfs-3g-2017.3.23-8.fc29.x86_64
ntfsprogs-2017.3.23-8.fc29.x86_64


That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of
the kernel.

You have to issue "mount" to see how it is really mounted. Maybe it says
"fuse", then it is correct.

--
Cheers, Carlos.
  #14  
Old February 10th 19, 05:54 AM posted to comp.os.linux.misc,alt.comp.os.windows-10
T
external usenet poster
 
Posts: 4,600
Default Windows is hibernating

On 2/9/19 6:53 PM, Carlos E.R. wrote:
On 09/02/2019 23.44, T wrote:
On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote:
In comp.os.linux.misc T wrote:
After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Are you mounting, in Linux, as ntfs or ntfs-3g?

The 'ntfs' Linux driver is read only.

The 'ntfs-3g' Linux driver is the read/write driver.

But, unless you ask mount to use ntfs-3g specifically, the
auto-detected default (at least on the one system I've got where I
mount an ntfs formatted USB drive [left as ntfs for compatibility with
a winblows system]) is 'ntfs'.

Depends on the distribution; for example on openSUSE the default is
ntfs-3g.


This is the only instance I have not been able to mount an NTFS
read/write with Fedora.

$ cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

$ rpm -qa ntfs\*
ntfs-3g-2017.3.23-8.fc29.x86_64
ntfsprogs-2017.3.23-8.fc29.x86_64


That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of
the kernel.

You have to issue "mount" to see how it is really mounted. Maybe it says
"fuse", then it is correct.


# mount -t ntfs /dev/sdc1 /mnt/MyCDs

# mount | grep /dev/sdc1
/dev/sdc1 on /mnt/MyCDs type fuseblk
(rw,relatime,user_id=0,group_id=0,allow_other,blks ize=4096)

  #15  
Old February 10th 19, 10:58 AM posted to comp.os.linux.misc,alt.comp.os.windows-10
Carlos E.R.[_3_]
external usenet poster
 
Posts: 1,356
Default Windows is hibernating

On 10/02/2019 05.54, T wrote:
On 2/9/19 6:53 PM, Carlos E.R. wrote:
On 09/02/2019 23.44, T wrote:
On 2/9/19 12:22 PM, Carlos E.R. wrote:
On 09/02/2019 16.14, Rich wrote:
In comp.os.linux.misc T wrote:
After shutting Windows back down and rebooting into Linux,
I still could not mount the C: drive as read/write.

What am I doing wrong?

Are you mounting, in Linux, as ntfs or ntfs-3g?

The 'ntfs' Linux driver is read only.

The 'ntfs-3g' Linux driver is the read/write driver.

But, unless you ask mount to use ntfs-3g specifically, the
auto-detected default (at least on the one system I've got where I
mount an ntfs formatted USB drive [left as ntfs for compatibility with
a winblows system]) is 'ntfs'.

Depends on the distribution; for example on openSUSE the default is
ntfs-3g.


This is the only instance I have not been able to mount an NTFS
read/write with Fedora.

$ cat /etc/redhat-release
Fedora release 29 (Twenty Nine)

$ rpm -qa ntfs\*
ntfs-3g-2017.3.23-8.fc29.x86_64
ntfsprogs-2017.3.23-8.fc29.x86_64


That doesn't mean much, as the 'ntfs' driver is not an rpm, but part of
the kernel.

You have to issue "mount" to see how it is really mounted. Maybe it says
"fuse", then it is correct.


# mount -t ntfs /dev/sdc1 /mnt/MyCDs

# mount | grep /dev/sdc1
/dev/sdc1 on /mnt/MyCDs type fuseblk (rw,relatime,user_id=0,group_id=0,allow_other,blks ize=4096)


Ok, that is ntfs-3g, mounted read/write apparently.


--
Cheers, Carlos.
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 11:18 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 PCbanter.
The comments are property of their posters.