General issues regarding F2FS rootfs partition

[levi]

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.

 

[NetBLOKS]

the only logical step is to switch to zfs for all the Pyra partitions and Sd cards.

 

[yeoldegrove]

/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]

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.

 

[Phlyra]

Is it possible to run u-boot on the Pyra?

 

[aTc]

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 :

FS#71801 : [f2fs-tools] resize.f2fs always fails with Error: Device size is not sufficient for F2FS volume..

Flyspray, a Bug Tracking System written in PHP.

bugs.archlinux.org

resize.f2fs: fix wrong ovp calculation - kernel/git/jaegeuk/f2fs-tools.git - Userland tools for the f2fs filesystem

git.kernel.org

 

[levi]

It's only a problem on distros that keep updating the kernel versions, like arch.

Why are people using uboot on the pyra having difficulty booting ext4 partitions then?

 

[aTc]

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.

 

[levi]

That could well explain it, yes.

 

[szr]

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]

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.

 

[Phlyra]

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.

Sounds the same for RPi boards

 

[F_Slim]

That allows you to mount the SD card on a Windows machine and edit the bootscript. Makes the device more accessible to people who do not have a Linux running on their Laptop/PC, but still want to mess around with it.

 

[levi]

What does, sorry?

 

[Letalis Sonus]

Windows ignores the partition table on certain devices like SD cards and USB thumbdrives, it will only show the very first partition (IIRC it even expects it to start at a certain offset). Therefore using the first partition as a dedicated FAT32 boot partition will allow you to access it from within Windows while the system isn't even able to see the actual system partition behind it.

 

[Phlyra]

What does, sorry?

FAT32, I’m guessing?

 

[TrashyMG]

That allows you to mount the SD card on a Windows machine and edit the bootscript. Makes the device more accessible to people who do not have a Linux running on their Laptop/PC, but still want to mess around with it.

Well it's also dependent of how the bootloader is defined to boot off the SD card, I remember there being distinct boot arguments for ext and fat file systems. It's not really just a convenience thing.