N900: Provided images use ext4 features which may cause problems

[dderby]

This doesn't affect me as I'm now creating my own filesystems and unpacking the tar.gz so I'm opening this at the request of @enyc00000000 and for other users that may potentially be affected by these issues...

Creating an ext4 filesystem on recent versions of Debian/Devuan e2fsprogs will enable ext4 features metadata_csum and 64bit which have been set by default in /etc/mke2fs.conf.

With metadata_csum enabled, the filesystem cannot be mounted under Fremantle (kernel-power).

With 64bit enabled, the filesystem cannot be booted directly from U-Boot. This doesn't affect the default configuration of the provided image which is set up to boot off a separate vfat slice before the ext4 fs is mounted. It may affect users who do not want to have a separate /boot and use dd to copy the ext4 slice only and then try to boot off that (as I initially tried).

These features can be disabled by creating the fs as follows:

mke2fs -t ext4 -O ^metadata_csum,^64bit <device>

The ext4(5) manual contains a description of these features.

metadata_csum is useful for detecting and correcting fs corruption so it's questionable whether we should disable it. We've lived without it in Fremantle and Harmattan and it arguable causes an inconvenience. I don't see it being a big deal to disable it until Leste reaches stable if people really want to mount under Fremantle.

As for 64bit, well 2^32 x 512B = 2TB. I don't think we need to worry about supporting >2TB microSD cards for some time.

Perhaps the best solution would be to document these on the wiki when it's ready (#101) so people can create their own filesystems if they desire.

[dderby]

The 64bit feature is supported in mainline U-Boot. The N900 build in Fremantle/extras is older than this commit:

http://git.denx.de/?p=u-boot.git;a=commit;h=b4976b49a01ac68f7dbb33657a44dcffe584fa4a

@pali no rush for this, but could we get a new build at some point?

[pali]

N900 support for U-Boot is fully upstreamed. Therefore just build last version of U-Boot.

[dderby]

Thanks pali!

[enyc00000000]

My understanding is that leste images have now had these problematic ext4 features sensibly turned-off for now [bearing in mind this is nowhere near a completed/finished system at the moment!].

FWIW, 64bit is needed only for >16TB disks!!! [4kb blocks are normally used, rather than 512b!]

Can pali in any case rebuild 'new' U-boot for existing maemo/fremantle package database? Would be it be appropriate if u-boot was built with the 'power' kernel attached [so its' compatible with Thumb systems] rather than the original 2.6.28 omap kernel [or would that prevent restoring/booting fremantle to old image if ever needed]?

[pali]

Attached kernel image into U-Boot needs to have installed appropriate kernel modules in target filesytem. And because kernel-power is not part or Maemo, kernel modules are not (pre)installed and thefore it cannot be as attached image for U-Boot. Attached image is just fallback when there is nothing more to boot; e.g. because external SD card is damaged or when you removed needed kernel image from MyDocs. In both cases is default Maemo system valid and bootable, so I need to provide image which would boot always.

Users of kernel-power can install kernel-power-bootimg package and also configure it as default boot image for U-Boot. So I do not see any reason for having kernel-power image as attached in U-Boot.

But you are free to compile your own U-Boot image with any attached kernel. All tools/scripts are available for it.

[enyc00000000]

In any case, issue given is FIXED! I can't seem to do it myself but this Issue can be CLOSED please =).
I'll help with wiki as mentioned above when ready, need to think about Users/Testers/Developers etc.].
With thanks again to getting this sorted-for-now.