F2FS Root Corrupted Upon Normal Reboot

[airend]

After cloning Btrfs /dev/root to F2FS, and changing cmdline.txt/fstab appropriately, everything boots fine, and behaves as expected. If I force power cycle, XBian still boots the new F2FS root as expected.

However, as soon as I do a proper reboot or poweroff, the system doesn't boot any longer. I noticed the issue a few months back; after a regular update, that F2FS-based card stopped booting. Anyway, I'm only mentioning the issue now because I see a consistent pattern, probably due to a fairly recent change in Xbian's custom scripts. Maybe it's due to some assumption on root being Btrfs? I couldn't find anything relevant in the shutdown scripts yet.

[f1vefour]

I will leave this open but changing the filesystem type is beyond the scope of XBian support in my opinion, maybe someone can chime in and help with your issue.

[airend]

I understand, but this functionality has been at least tolerated, if not supported, based on forum posts by mk01, IriDium, etc. Any help is appreciated. Whatever is clobbering F2FS root upon the first reboot, must have happened in the past few months.

[f1vefour]

That's why I leave it open, I was just trying to say you may not receive a resolution. Everything is tolerated just not formally supported, XBian is meant to fit every niche best it can :)

If I knew where to look for something specific to your use case I would try and help. Are you running a custom kernel as I don't recall if F2FS is supported in our stock kernel? I ask because others are suffering through some kernel bugs lately, if you're running a stock kernel perhaps you are as well.

[airend]

Thanks, kernel is stock here. I actually tested with a completely clean image (March 21st), by moving and converting root to F2FS; same pattern, all good till the first proper reboot/poweroff (whereas, yanking the cord allows it to boot again).

Not a high priority bug on its own, but could be indicative of something more serious. XBian has been great for the past year I've been using it, and I can certainly live with btrfs.

[mk01]

@airend

yes, XBian should be rootfstype in dependable. probably what makes trouble here is auto kicked (or unkicked :) ) initramfs boot. check it and let me know. some basics I would expect (or XBian scripts expect)

-- 1) f2fs support is provided as module
(probably can be inkernel too without any changes,
but at the time of testing f2fs support, it was module)

-- 2) f2fs.ko gets properly bundled into initramfs.gz. 
(can be checked by unpacking initramfs.gz like this:

**mkdir /tmp/initram; cd /tmp/initram
gunzip -cd < /boot/initramfs.gz | cpio -i**

-- 3) because of 1) and 2), f2fs rootfstype system
should be booted via initramfs usage. 

-- 4) normally 3) is controlled "automatically", xbian
sets initramfs (or not) boot during powering down 
(or rebooting). it checks if root is nfs4, or btrfs 
(multi device), or zfs, or .... ? 

don't remember all the conditions. if condition met,
initramfs.gz is kept with it's name (next boot will use it),
otherwise is renamed to nitramfs.gz.notinuse (and kernel will boot directly).

now I have the feeling test for f2fs is not there (check /etc/xbian-initramfs/initram.switcher.sh). there is also /etc/default/xbian-initramfs config file, which can override this auto control by forcing initramfs.gz be always used).

currently can't think of a different option (of failure to boot).

[airend]

Thanks, @mk01, this is great information. I didn't realize boot settings change dynamically, and assumed initramfs can't be the culprit since it boots once. Anyway, I checked and F2FS is actually built in, not a module in 3.18.8 (also, CONFIG_F2FS_FS=y in /proc/config.gz).

Looking at initram.switcher.sh, I can see that it comments the first line in /boot/config.txt, whereas initramfs initramfs.gz 0x1000000 is active/uncommented with a fresh install. So, for some reason F2FS root will not boot directly, despite the in-kernel F2FS support.

The easiest solution for now was to set FORCEINITRAM=yes, which fixes my reboot/poweroff issue. Thanks again for helping with this.

[mk01]

kernel directly mounting ROOTFS do require support for particular FS be compiled in, but it is not the ONLY condition.

so don't be surprised it can't boot directly. this applies for NFS4, multi-device BTRFS (for sure others).

you are right with the commenting line in config.txt. of course I was describing by mistake the way IMX6 is handled (there it is rename). RPI is not testing physical presence of initramfs.gz (once present in config.txt, it try to load it and fails booting if missing). so different approach is used.

btw: feel free to add f2fs test into initramfs.switcher conditions/logic which leads to setting ramfs=yes (so initramfs will be used). If you do that, just add the same also for imx6 platform. then open a change request. I will merge and retest the imx6 path.

[airend]

Thanks again! Pull request submitted.

[boecko]

This is still an issue.

1. I copied a fresh xbian installation from sdcard to ssd on a Raspi4 via 'Xbian copier'
2. removed the sdcard and booted with the usb-mounted ssd. That worked fine, but..
3. after reboot the system is dead

The problem FORCEINITRAM=no in /etc/default/xbian-initramfs modifies /boot/config.txt and disables initramfs initramfs.gz followkernel

The Xbian copier should at least warn about this issue, because it causes a lot of headaches.

thanks