On 10/25/24 15:55, Jonathan Billings wrote:
On Oct 25, 2024, at 08:15, ToddAndMargo via users
<[email protected]> wrote:
# tune2fs -E force_fsck /dev/nvme0n1p4
tune2fs 1.47.0 (5-Feb-2023)
tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1p4
/dev/nvme0n1p4 contains a crypto_LUKS file system
That is most likely the NVME partition you use as the storage backend for your
LUKS volume.
This should go without saying, but you should only run the ext2/3/4 tools on
ext2/3/4 filesystems, and not the encrypted device used in your LUKS volume.
You can look at ‘mount’ to see what device that is, most likely in /dev/mapper/.
I could not find it in mount, but I did find it with df:
# df -kPT /
Filesystem Type 1024-blocks
Used Available Capacity Mounted on
/dev/mapper/luks-903bc691-a0f0-42bc-aa96-4233a7edc0e9 ext4 950971044
669182320 233408360 75% /
# tune2fs -E force_fsck
/dev/mapper/luks-903bc691-a0f0-42bc-aa96-4233a7edc0e9
It did run. Took about 10 seconds. Thank you!
Followup question: is there a flag to throw that tells fsck
to "repair"? I never found one in "man fsck".
-T
--
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
