You are not logged in.
I am following the instructions to set up hibernation on the Arch Linux Wiki. I am using a Swapfile and I have created my Swapfile on an HDD at a location called /data/swapfile. The steps before 4.3 work fine for me, but when I try to acquire the swap file offset using:
$ sudo filefrag -v /data/swapfile
Filesystem type is: 65735546
File size of /data/swapfile is 12884901888 (3145728 blocks of 4096 bytes)
Discontinuity: Block 4086 is at 152506732 (was 152494432)
Discontinuity: Block 8170 is at 152519020 (was 152510816)
Discontinuity: Block 12254 is at 152547692 (was 152523104)
Discontinuity: Block 16338 is at 152555880 (was 152551776)
Discontinuity: Block 20426 is at 152572264 (was 152559968)
Discontinuity: Block 24514 is at 152576365 (was 152576352)
Discontinuity: Block 28597 is at 152580463 (was 152580448)
Discontinuity: Block 32678 is at 152592748 (was 152584544)
(and so on…)
Discontinuity: Block 3129686 is at 176034163 (was 176013664)
Discontinuity: Block 3133763 is at 176066929 (was 176038240)
Discontinuity: Block 3137842 is at 176087404 (was 176071008)
/data/swapfile: 757 extents foundClearly, my format does not match the format given in the example's output and I don't have a single numeric offset which I can flush to /sys/power/resume_offset.
Is this output something I should be concerned about?
How do I get the offset value required for further steps?
Details: The disk which is mounted to /data has NTFS-3 filesystem. Let me know if any other details need to be mentioned to fix this issue.
Last edited by mr_kaddy (2025-11-23 08:25:51)
Offline
https://wiki.archlinux.org/title/Power_ … ile_offset
The disk which is mounted to /data has NTFS-3 filesystem
Have you tried this w/ an extfs ?
PSA: 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Offline
Have you tried this w/ an extfs ?
No, I have not. The reason is that the SSD I have which has extfs is not very large and I cannot afford to have 12 gigs of swap file reserved on it, so I have chosen to keep my swapfile on an HDD. The HDD already had important data on it, so wiping it to convert it from NTFS to a more Linux-friendly FS wasn't an option.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
I wiped off my Windows when I installed Arch. I cannot boot up to Windows to disable fast startup from the Windows cmd as mentioned in the link. The only trace of Windows I still have seems to be a 16 MB partition on my HDD which contains some Windows FS data. Is there any way I can modify the same settings from Arch or from my BIOS settings?
Offline
Is there any way I can modify the same settings from Arch or from my BIOS settings?
No, but it's probably also no longer relevant.
convert it from NTFS to a more Linux-friendly FS wasn't an option
I highly suspect that's what's causing you the problems - and I'd not even advise to shrink it to make place for a swap partition etc. - certainly not w/o windows shrinking the NTFS (shrinking the partition w/o shrinking the FS first will lead to data corruption!)
The most reasonable approach would be to get an external drive, backup the contents (don't format that NTFS
) of the NTFS HDD there, nuke the HDD and setup a POSIX filesystem - idk whether it's even theoretically possible to use NTFS for this and given the errrr… "mercurial" state of the NTFS support, I'd also rather not bet on it for practical purposes.
Offline
I highly suspect that's what's causing you the problems - and I'd not even advise to shrink it to make place for a swap partition etc. - certainly not w/o windows shrinking the NTFS (shrinking the partition w/o shrinking the FS first will lead to data corruption!)
The most reasonable approach would be to get an external drive, backup the contents (don't format that NTFS
) of the NTFS HDD there, nuke the HDD and setup a POSIX filesystem - idk whether it's even theoretically possible to use NTFS for this and given the errrr… "mercurial" state of the NTFS support, I'd also rather not bet on it for practical purposes.
Let's assume I do have an external HDD which can fit the contents of my internal HDD. Why does the FS of the external HDD matter when I'm backing up my internal HDD data? Let's say it is formatted as NTFS while I wipe off my internal HDD and format it to exFAT or ext4. Does that mean I won't be able to copy the original contents back to this HDD?
It seems like the nuclear option is the only case here, but theoretically when you run the commands on Windows, it's not really doing some magic, right? It's just changing some config file, modifying some setting or on the lowest level, flipping some bits. Why should it be impossible to replicate the effects from Linux when you have access to the entire device and file system which Windows has? Am I missing something here?
Offline
Why does the FS of the external HDD matter when I'm backing up my internal HDD data?
It does not, the point was to not cause yourself more headaches by formatting a new drive NTFS again.
You'd lose posix permissions by backing up a POSIX FS onto NTFS but NTFS to NTFS won't change anything.
Why should it be impossible to replicate the effects from Linux
given the errrr… "mercurial" state of the NTFS support, I'd also rather not bet on it for practical purposes
NTFS is a proprietary FS, MS never provided any specification for it, all filesystem/tool implementations that are not provided by MS are reverse engineered and to the extent where any low-level manipulation is even possible (ntfsfix from ntfs-3g) they're rather hazardous.
NTFS is borderline unmaintainable if you don't have a windows system.
Offline
Why does the FS of the external HDD matter when I'm backing up my internal HDD data?
It does not, the point was to not cause yourself more headaches by formatting a new drive NTFS again.
You'd lose posix permissions by backing up a POSIX FS onto NTFS but NTFS to NTFS won't change anything.Why should it be impossible to replicate the effects from Linux
given the errrr… "mercurial" state of the NTFS support, I'd also rather not bet on it for practical purposes
NTFS is a proprietary FS, MS never provided any specification for it, all filesystem/tool implementations that are not provided by MS are reverse engineered and to the extent where any low-level manipulation is even possible (ntfsfix from ntfs-3g) they're rather hazardous.
NTFS is borderline unmaintainable if you don't have a windows system.
I have decided to go ahead with the backup-format-restore method as suggested and since there do not seem to be any alternatives. I've been reading up on the best way to do this and it seems like the most convenient option seems to be creating a backup as a disk image using dd on an external disk, formatting with mkfs and restoring from the disk image. However, one crucial piece of missing information is whether the disk image is filesystem dependent. I couldn't find a straightforward answer to this on reliable sources but from my understanding, since a disk image is a bit-by-bit copy of a disk, it should also contain filesystem-specific metadata stored on the disk, right? This means that if I follow the instructions to restore a disk from a disk image, it'll most likely lead to bad things due to a bit-level filesystem mismatch.
IS this right? I really don't want to find out the hard way after creating a disk image.
If I am, are there any alternatives to backing up each file one-by-one?
Offline
it should also contain filesystem-specific metadata stored on the disk, right?
Yes and that's not necessarily a good idea when the goal is to later restore the data onto a different FS anyway (while you could mount the image and copy the data over you're left with the disk image)
I'd also be careful with nesting an NTFS image on an NTFS disk.
What speaks against "cp -a"?
Offline
Sure, so let's say I've mounted my interval HDD at /data and my external HDD at /extdata. Then a simple:
cp -a /data /extdata
<expand all partitions in the internal HDD to a single partition and mkfs with whatever FS I choose, mostly ext4>
mount /dev/nameofthedevice /data
cp -a /data /extdata
This should work in theory?
Offline
The final step will be more like "cp -a /extdata/data/* /data" and there's probably gonna be some transactional data (typically starting w/ a $ on NTFS/windows) you don't necessarily want to backup/restore
You'll also have to unmount /data before repartitioning the disk
You also *might* want to use rsync instead of cp to get some visual progress indicator (assuming it's a lot of data, this might take a moment)
https://wiki.archlinux.org/title/Rsync
Offline
While time-consuming, this solution did work out eventually. Working with ext4 on my HDD makes many things much easier. Thanks a lot and marking this as solved.
Offline