Other Multiple system data recovery

J

jaymax

I have a dual boot system, Win 10 with a FreeBSD bootable Ext.Drive.

The Win module has an ext. NTFS storage disk that has failed apparently- lost partition & bad clusters. CHKDSK and similar tools have been ineffective as neither the disk nor the partition is seen.

Booting with a KNOPPIX USB drive shows up the disk and file content (or at least. a major portion of it). Probing revealed a dirty file system and apparently superblock issues, probably others too,

Can I add a new replacement drive and boot with FreeBSD; format the new drive into two partitions, one negligible just a few MB's. Then lay down a BSD filesystem in the small partition and an NTFS in the larger partition. Then proceed to either 'tar' or 'dd' the files from the failed disk to the new NTFS partition on the new volume.

Or would I have to run 'fsck; on the failed disk ?

Thanks!
 
When you get Win 10 up and running again, I suggest running powercfg /h off with administrator privileges to turn off the hibernate on shutdown "feature." Hibernate on shutdown does allow for a somewhat faster Windows shutdown and/or reboot, but it also sidesteps doing a proper shutdown every time, and this, in turn, apparently leaves your Windows partition(s) in an unstable state.
 
Vull said:
When you get Win 10 up and running again, I suggest running powercfg /h off with administrator privileges to turn off the hibernate on shutdown "feature." Hibernate on shutdown does allow for a somewhat faster Windows shutdown and/or reboot, but it also sidesteps doing a proper shutdown every time, and this, in turn, apparently leaves your Windows partition(s) in an unstable state.
Click to expand...
The problem is on an external storage disk, not the system drive
 
Sorry, I wasn't paying attention:

jaymax said:
… lost partition …
Click to expand...

jaymax said:
… or 'dd' the files …
Click to expand...

With neither the partition table nor the file system detectable, you could copy as much as possible from the failing device, to a partition of a working device; then (I guess) proceed to attempt recovery of the partition table, then attempt CHKDSK repair of the file system.

When I last performed data recovery for a colleague, I used (amongst other things) DDRescue-GUI. From my notes at the time: "Booted instead from a USB flash drive with the latest image for Kubuntu, with gparted and DDRescue-GUI added.".

gitlab.com

Hamish McIntyre-Bhatty / ddrescue-gui · GitLab

This repository holds DDRescue-GUI, a simple GUI frontend to make gddrescue easier to use. (Unstable, see launchpad.net for stable releases)
gitlab.com gitlab.com
 
jaymax said:
The problem is on an external storage disk, not the system drive
Click to expand...
On my Windows 10 system, the hibernate on shutdown feature leaves all NTFS drives to which Windows has access in an improperly shutdown state. From what I've read, this is now a default feature until you explicitly turn it off.
 
jaymax said:
I have a dual boot system, Win 10 with a FreeBSD bootable Ext.Drive.
Click to expand...
Well there's your first problem. :)
jaymax said:
The Win module has an ext. NTFS storage disk that has failed apparently- lost partition & bad clusters. CHKDSK and similar tools have been ineffective as neither the disk nor the partition is seen.
Click to expand...
So you have two external disks or one with both NTFS and FFS on it?

jaymax said:
Booting with a KNOPPIX USB drive shows up the disk and file content (or at least. a major portion of it). Probing revealed a dirty file system and apparently superblock issues, probably others too,
Click to expand...
I don't know what knoppix is, but what is it probing? The NTFS or FFS? I'm confused.


jaymax said:
Can I add a new replacement drive and boot with FreeBSD; format the new drive into two partitions, one negligible just a few MB's. Then lay down a BSD filesystem in the small partition and an NTFS in the larger partition. Then proceed to either 'tar' or 'dd' the files from the failed disk to the new NTFS partition on the new volume.
Click to expand...

Of course, but how are you to copy data from a disk you state above is unresponsive to your attempts to chkdsk it?


jaymax said:
Or would I have to run 'fsck; on the failed disk ?
Click to expand...

fsck != chkdsk.
jaymax said:
Thanks!
Click to expand...

No problem I think... :oops:
 
jaymax for now, ignore my <https://forums.FreeBSD.org/threads/81807/post-528408>, you'll probably not need any recovery utility.

Instead, try:
  1. pkg install sysutils/fusefs-ntfs sysutils/lsblk && kldload fusefs
  2. lsblk
  3. ntfsfix /dev/da⋯p1
– for ⋯ above, use the appropriate number.

Looking ahead: you can avoid this type of problem by disabling fast startup.

[Windows 10] How to disable Fast Startup in Windows | Official Support | ASUS Global

<https://www.freshports.org/sysutils/fusefs-ntfs/>

Whilst <https://sourceforge.net/p/ntfs-3g/mailman/ntfs-3g-news/> has nothing more recent than 2016, I assume (from speeding through various web pages) that ntfsfix does work with $LogFile format version 2.0.

<https://en.wikipedia.org/wiki/NTFS#Journaling>

Postscript

Windows Fast Startup dangerous for dual boot systems | The FreeBSD Forums
 
Last edited:
Vull said:
On my Windows 10 system, the hibernate on shutdown feature leaves all NTFS drives to which Windows has access in an improperly shutdown state. From what I've read, this is now a default feature until you explicitly turn it off.
Click to expand...
This has been true since the mid 90s. And it is true for other operating systems too; I used to run dual-boot machines with Windows and Linux, and Linux was just as guilty.

Operating systems are designed to be efficient. That for example means caching what is on disk, both on reading and on writing. Having to write back all the caches when hibernating is inefficient, as is invalidating all the read caches when waking up from hibernation. Operating systems are designed to have unlimited access to the hardware. If you boot an OS and give it a disk, in most cases it will assume that it has complete control over that disk. Nearly all file systems will have a fit if the disk gets modified while they think they have control over the disk. This can for example happen because the OS has gone into hibernation and another OS is running on the same hardware, or it can happen because the disk is multi-initiator, and can get modified from another OS.

If you want to modify a disk from multiple OSes, you either have to explicitly dismount the file system before handing the disk to another OS, or you have to use a file system that is aware of other writers (such file systems are typically known as SAN or cluster file systems). None of the common single-node file systems (NTFS, ext2/3/4, UFS, ZFS, HFS, ...) can work with disks getting modified behind their back.

My suggestion: If you share disks between OSes, do a full unmount of the disk before switching to the other OS. I've posted about this several times.
 
ralphbsz said:
This has been true since the mid 90s. And it is true for other operating systems too; I used to run dual-boot machines with Windows and Linux, and Linux was just as guilty.

Operating systems are designed to be efficient. That for example means caching what is on disk, both on reading and on writing. Having to write back all the caches when hibernating is inefficient, as is invalidating all the read caches when waking up from hibernation. Operating systems are designed to have unlimited access to the hardware. If you boot an OS and give it a disk, in most cases it will assume that it has complete control over that disk. Nearly all file systems will have a fit if the disk gets modified while they think they have control over the disk. This can for example happen because the OS has gone into hibernation and another OS is running on the same hardware, or it can happen because the disk is multi-initiator, and can get modified from another OS.

If you want to modify a disk from multiple OSes, you either have to explicitly dismount the file system before handing the disk to another OS, or you have to use a file system that is aware of other writers (such file systems are typically known as SAN or cluster file systems). None of the common single-node file systems (NTFS, ext2/3/4, UFS, ZFS, HFS, ...) can work with disks getting modified behind their back.

My suggestion: If you share disks between OSes, do a full unmount of the disk before switching to the other OS. I've posted about this several times.
Click to expand...
I probably read one or more of those posts, thanks. Not surprising; just something one might have to deal with in multi-boot systems. It's useful to at least be aware of such side-effects.

Maybe this is also true of Linux or FreeBSD, but if so, I haven't noticed it. I haven't played with any Linux distros outside of the Debian branch for over 20 years. I think it would be more straightforward for Windows to say "hibernate" instead of "fast shutdown" or "fast reboot," but I don't think they much care what I think, or about any such concerns, and would no doubt prefer it if all computers just used Windows exclusively.

I have friends who use Windows exclusively and have bad habits like turning the machine off when it becomes unresponsive. For them I recommend turning off the hibernate on shutdown option because, as end-users only, they are, understandably enough, completely unaware of it.
 
ralphbsz said:
… None of the common single-node file systems (NTFS, ext2/3/4, UFS, ZFS, HFS, ...) can work with disks getting modified behind their back.

My suggestion: If you share disks between OSes, do a full unmount of the disk before switching to the other OS.
Click to expand...

Extending the ZFS case a little: if it's a single-disk pool, better to export the pool.

(Without an export: there's no impact on integrity of the file system, however an import elsewhere will require force.)
 
SirDice said:
fsck(8) only works on UFS filesystems.
Click to expand...

From the manual page, with added emphasis:

… If the -t or -T flags are not specified, fsck will attempt to determine the file system type and call the appropriate file system check utility. …
Click to expand...

– ignoring a typo in the quoted text.​

Maybe the quickest way to observe this is in single user mode, with any installation of FreeBSD that is UEFI boot-capable (and has the customary EFI system partition (ESP)):
  1. fsck -fy
  2. observe the check of the FAT file system (not UFS).

1641369036321.png


<https://www.freebsd.org/cgi/man.cgi?query=fsck&sektion=8&manpath=FreeBSD#SEE_ALSO> ▶ fsck_msdosfs(8)

Note, this is not to suggest that fsck(8) will call a utility that can handle NTFS.
 
fsck_ext2fs(8)

Vull said:
?… 13.0-RELEASE also has /sbin/fsck_ext2fs …
Click to expand...

Nit: it's from the ports collection, not in FreeBSD.

Possible disorientation as a result of MAN markup in XenForo.

<https://www.freebsd.org/cgi/man.cgi?query=fsck_ext2fs&sektion=8&manpath=FreeBSD> correctly finds nothing.

Code: 
% pkg provides /sbin/fsck_ext2fs
Name    : e2fsprogs-roothardlinks-1.46.4_1
Desc    : Utilities & library to manipulate ext2/3/4 filesystems
Repo    : FreeBSD
Filename: usr/local/sbin/fsck_ext2fs
          sbin/fsck_ext2fs

Name    : e2fsprogs-nobootfsck-1.46.4_1
Desc    : Utilities & library to manipulate ext2/3/4 filesystems
Repo    : FreeBSD
Filename: usr/local/sbin/fsck_ext2fs

Name    : e2fsprogs-1.46.4_1
Desc    : Utilities & library to manipulate ext2/3/4 filesystems
Repo    : FreeBSD
Filename: usr/local/sbin/fsck_ext2fs
          sbin/fsck_ext2fs
%

fsck.zfs(8)

FreeBSD bug 260962 – sysutils/openzfs fsck.zfs(8) does not detect OpenZFS pool degradation
 
You must log in or register to reply here.
Back
Top