View previous topic :: View next topic |
Author |
Message |
hceline n00b
Joined: 30 Aug 2015 Posts: 36
|
Posted: Sun Oct 28, 2018 6:27 pm Post subject: tip/warning/request: Getting fsck.f2fs to run on root-fs |
|
|
Was not quite sure where to put this, pleas mods move it as see fit.
At the moment fsck.f2fs will not ever run on the root mount if it is formatted f2fs. I discovered this when I got write errors after several power-failures/hangs that cumulatively error-ed out my root-fs to the point where when I finally got a initramfs with fsck.f2fs made; it was too late.
The issue is that a f2fs formatted root fails if you mount it read only, and you can not fsck a mounted f2fs filesystem. And since genkernel does not include fsck.f2fs, it does not get run in initramfs by default either.
That was the tip/warning, here comes the request;
I have reported this here: https://bugs.gentoo.org/666657 but it is still UNCONFIRMED, if you are running f2fs root, please verify my findings and report.
Thanks. |
|
Back to top |
|
|
Perfect Gentleman Veteran
Joined: 18 May 2014 Posts: 1255
|
Posted: Sun Oct 28, 2018 11:57 pm Post subject: |
|
|
cannot confirm
Code: | fsck |Info: Fix the reported corruption.
fsck |Info: Mounted device!
fsck |Info: Check FS only due to RO
fsck |Info: [/dev/sdd1] Disk Model: PLEXTOR PX-G256M1.06
fsck |Info: Segments per section = 1
fsck |Info: Sections per zone = 1
fsck |Info: sector size = 512
fsck |Info: total sectors = 500116111 (244197 MB)
fsck |Info: MKFS version
fsck | "Linux version 4.15.0-20-generic (buildd@lgw01-amd64-039) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018"
fsck |Info: FSCK version
fsck | from "Linux version 4.19.0-gentoo (root@De-Humanizer) (gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)) #1 SMP PREEMPT Tue Oct 23 14:10:49 +07 2018"
fsck | to "Linux version 4.19.0-gentoo (root@De-Humanizer) (gcc version 8.2.0 (Gentoo 8.2.0-r3 p1.4)) #1 SMP PREEMPT Tue Oct 23 14:10:49 +07 2018"
fsck |Info: superblock features = 0 :
fsck |Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
fsck |Info: total FS sectors = 500116104 (244197 MB)
fsck |Info: CKPT version = 7960b352
fsck |Info: checkpoint state = 55 : crc fsck compacted_summary unmount
fsck |
fsck |[FSCK] Unreachable nat entries [Ok..] [0x0]
fsck |[FSCK] SIT valid block bitmap checking [Ok..]
fsck |[FSCK] Hard link checking for regular file [Ok..] [0xe0]
fsck |[FSCK] valid_block_count matching with CP [Ok..] [0x67d7d9]
fsck |[FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0xe7e6a]
fsck |[FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0xe7e6a]
fsck |[FSCK] valid_inode_count matched with CP [Ok..] [0xe71ea]
fsck |[FSCK] free segment_count matched with CP [Ok..] [0x1a6ea]
fsck |[FSCK] next block offset is free [Ok..]
fsck |[FSCK] fixing SIT types
fsck |[FSCK] other corrupted bugs [Ok..]
fsck |
fsck |Done. |
|
|
Back to top |
|
|
hceline n00b
Joined: 30 Aug 2015 Posts: 36
|
Posted: Mon Oct 29, 2018 4:39 am Post subject: |
|
|
Thank you, something must have changed since last I tried to boot with root mounted read-only (a very long time ago). I'll have to do some new tests, this is promising.
Edit: Did a test, and there is still one issue as far as I can understand, this line:
Code: |
fsck |Info: Check FS only due to RO
|
..says that it will not fix errors since fs is mounted ro. |
|
Back to top |
|
|
hceline n00b
Joined: 30 Aug 2015 Posts: 36
|
Posted: Mon Oct 29, 2018 10:00 am Post subject: |
|
|
Did some more tests, and now I know why I could not boot with root ro before:
I have to remove rw from ROOTFLAGS on kernel command-line, NOT replace it with ro.
If I put ro in ROOTFLAGS i get kernel panic that says "shed: Unexpected reschedule of offline CPU". There are also more errors before that one but they scrolled off screen; I'll have to try hooking up a serial port to get the whole log...
Edit: Got serial hooked up, and the first error was:
Code: | F2FS-fs (nvme0n1p3): Unrecognized mount option "ro" or missing value |
Guess, I'll have to take this to the f2fs mailing list.... |
|
Back to top |
|
|
hceline n00b
Joined: 30 Aug 2015 Posts: 36
|
Posted: Mon Apr 22, 2019 7:23 am Post subject: |
|
|
Edit: Correction, the part about failing to open RO mounted partition proved to be user error in the end. The patch is not needed anyway. But the part about not fixing a RO mounted partition seems to be a correct assessment.
After a delay due to hardware issues, I finally got this reported to the f2fs-ml. I got a patch for the failed-to-open-RO-partition (attached to my https://bugs.gentoo.org/666657). And I got confirmation that fsck.f2fs does not fix an RO mounted partition, it only check it: https://sourceforge.net/p/linux-f2fs/mailman/message/36645996/
Last edited by hceline on Mon Apr 22, 2019 10:14 am; edited 1 time in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54584 Location: 56N 3W
|
Posted: Mon Apr 22, 2019 9:24 am Post subject: |
|
|
hceline,
Being unable to fix a volume mounted read only is expected behaviour.
Looking at the filesystem metadata when files may be open is safe.
Changing it because its not self consistent can break the open files, so its not safe.
All fscks, guess what should be there and make the filesystem metadata self consistent. They do nothing for user data.
When they guess wrong, things go from bad to worse. That's what backups are for. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
hceline n00b
Joined: 30 Aug 2015 Posts: 36
|
Posted: Tue Apr 23, 2019 4:50 pm Post subject: |
|
|
NeddySeagoon wrote: | hceline,
Being unable to fix a volume mounted read only is expected behaviour.
Looking at the filesystem metadata when files may be open is safe.
Changing it because its not self consistent can break the open files, so its not safe.
All fscks, guess what should be there and make the filesystem metadata self consistent. They do nothing for user data.
When they guess wrong, things go from bad to worse. That's what backups are for. |
Well, I never had a problem with other filesystems not repairing even if all Linux-distros I've ever used has mounted root RO and done fsck before remounting RW.
And the developers seem to agree that f2fs should behave more like other filesystems in this regard:
Patch for the real issue, from f2fs-ml is now attached to https://bugs.gentoo.org/666657. |
|
Back to top |
|
|
|