General issues regarding F2FS rootfs partition


levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
14,781
Location
Somewhere off the coast of the EU
Yes, it's reported earlier in this thread that gparted, and by correlation plain old parted crap on f2fs partitions. And I thought it was standard procedure that you can't mess around too much with currently mounted partitions, certainly that's my assumption before intrinsically changing the shape of any partition, and if it's my home partition or boot or something, I need to boot from external media before messing around with them.
 

yeoldegrove

Member
Joined
Mar 9, 2011
Messages
54
Location
Germany
Code:
/boot/config-5.6.19-daveiii-pyradef-aufs|grep f2fs
CONFIG_CMDLINE="coherent_pool=1M twl4030_charger.allow_usb=1 fsck.repair=yes rootfstype=f2fs  rootwait ignore_loglevel"

It seems that f2fs is hardwired into our current kernel.
This is why my sdcard with a ext4 root filesystem cannot be mounted inside the initrd.
Overwriting this via /boot/extlinux/linux.cfg also does not work, as this file comes first in cmdline
Do we really need this hardwired parameter?
What would be the official way to submit a pull request to our current kernel?
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
14,781
Location
Somewhere off the coast of the EU
If it's reading the initrd it means it's already mounted the boot filesystem. I think you probably mean it can't be mounted by uboot or something at that early stage of boot, which is possible; the one we had on the pandora only handled fat and up to ext3, but I'd expect the one in the Pyra to be newer; the only reason I think the one in the Pandora didn't was because it predated the invention of ext4.
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
233
Yeah, f2fs shouldn't be hardwired in that config. and the kernel default cmdline should be empty by default.
Uboot does change the cmdline though, so check /proc/cmdline for what it's actually using

I did change that ages ago, but if it's still there I must have forgotten to push the version with the right config onto the official repo, and kept using the test kernels from my private repo.
I'll have a look.

I do have a half working f2fs partition resizer config for the initramfs somewhere, but haven't had the time to properly test everything.
That would resize the partition to fill the sd card on the first boot.


That resize.f2fs error is caused by resize.f2fs being older than the f2fs in the kernel , it seems they made a change to the kernel parts, but didn't update the release version of the f2fs tools.
It's only a problem on distros that keep updating the kernel versions, like arch.

I ran into it a while ago too, found the problem and the fix though :
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
233
Ext4 works fine. It's what I used for the root partition before moving to f2fs.
f2fs just seemed slightly more optimized for flash based storage.
The current images are mostly meant for installation onto the emmc , being able to boot from sd card is just something to make testing easier.

The only issue the uboot on pyra has (or had, I haven't checked if that bug is still there) is that it doesn't like ext4 partitions created with the 64bit option enabled (which is default on pretty much everything now).
Uboot would then load the wrong data instead of a kernel/initramfs, and things would obviously go wrong.
That's the reason I'm using an ext2 formatted boot partition. After the kernel has loaded it can run from whatever filesystem it supports.
(Although in earlier version I've also used a single ext4 (created with "mkfs.ext4 -O ^64bit") for everything.)

Another problem you might run into when trying to do things yourself, is that some partition tools (gparted) write some x86 boot code in the first block that the omap also sees as a bootloader, so it locks up when the card is in the pyra.
Also something to take care of is that the uboot MLO has to be written to a specific place on the disk. Most partitioners these days allign the partition to MB sizes blocks, so I dump it onto the disk directly, in that free first MB.
The "official" method of copying it as the first file on a fat32 partition also works, but requires telling the partitioner not to align the partitions to any MB multiple. (and you're forced to have a fat32 boot partition then, which has some issues when packages try to create symlinks in the /boot directory, or try to set file attributes fat doesn't support).

I could create a script that makes a self resizing ext4 sd card image like the raspberry pi does it. but the problem is that it's just me working on everything, and there's quite a lot of other stuff to do too (like cleaning all the packages up for the big move to debian bullseye), and it's all done in whatever spare time I have.
 

szr

Member
Joined
Feb 5, 2014
Messages
93
Age
41
Also something to take care of is that the uboot MLO has to be written to a specific place on the disk. Most partitioners these days allign the partition to MB sizes blocks, so I dump it onto the disk directly, in that free first MB.
The "official" method of copying it as the first file on a fat32 partition also works, but requires telling the partitioner not to align the partitions to any MB multiple. (and you're forced to have a fat32 boot partition then, which has some issues when packages try to create symlinks in the /boot directory, or try to set file attributes fat doesn't support).
Can you elaborate on this? Using fat32 for a Linux boot disk seems wrong on so many levels...
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,092
Can you elaborate on this? Using fat32 for a Linux boot disk seems wrong on so many levels...
used to be more common long time ago, remember almost every arm distribution on the beagleboard generally had a fat32 boot partition and the rootfs was some flavo(u)r of ext.
 
Top