[SOLVED] XFS on an ODroid-C2

[WorMzy]

Hey guys,

I've just upgraded to an ODroid-C2 (replacing my ageing 2012 RPi model B) and was surprised to see that the XFS I have on an external drive won't mount, complaining of incompatible features:

$this->bbcode_second_pass_code('', '# mount /dev/mapper/twotera-lvbackup /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/twotera-lvbackup, missing codepage or helper program, or other error.

# dmesg | tail
[ 352.883842] squeak kernel: XFS (dm-0): Superblock has unknown incompatible features (0x2) enabled.
[ 352.892046] squeak kernel: XFS (dm-0): SB validate failed with error 22.
')

I note that ALARM runs a 3.16 kernel on the ODroid-C2, and it seems this kernel is too old to mount modern XFS. Alarmingly, it cannot mount an XFS image created by itself, using mkfs.xfs defaults.

To reproduce:

$this->bbcode_second_pass_code('', '# dd bs=512 count=100000 if=/dev/zero of=test
100000+0 records in
100000+0 records out
51200000 bytes (51 MB, 49 MiB) copied, 1.21251 s, 42.2 MB/s

# mkfs.xfs test
meta-data=test isize=512 agcount=2, agsize=6250 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=0
data = bsize=4096 blocks=12500, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=855, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

# mount test /mnt
Password:
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

# dmesg | tail
[176109.198319] XFS (loop0): Superblock has unknown incompatible features (0x2) enabled.
Filesystem can not be safely mounted by this kernel.
[176109.198332] XFS (loop0): SB validate failed with error 22.
')

It seems that "(0x2)" translates to metadata CRCs, as creating an XFS iamge with `-m crc=0` passed to mkfs.xfs results in a filesystem that can be mounted:

$this->bbcode_second_pass_code('', '
# mkfs.xfs -m crc=0 -f test
meta-data=test isize=256 agcount=2, agsize=6250 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0, rmapbt=0
= reflink=0
data = bsize=4096 blocks=12500, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

# mount test /mnt
# findmnt -n /mnt
/mnt /dev/loop0 xfs rw,relatime,attr2,inode64,noquota')

I'm confused though, as (according to the Arch Wiki) metadata CRCs were considered stable as of kernel 3.15, so I'd expect a 3.16 kernel to be able to handle them.

Unfortunately metadata CRCs cannot be disabled (even if they could, this filesystem has all my backups on it, so I'd rather not mess around with filesystem features if I can avoid it) so it seems there's no easy fix for this.

One possible solution may be to boot the mainline kernel, but so far my attempts at that have resulted in an unbootable odroid (or else a booted odroid with no video or networking, and no journal for that session...).

Has anyone got a CRC-enabled XFS working on an ODroid-C2?

[graysky]

No real info but general question: is there kernel support for XFS on aarch64 for C2?

On my C2:
$this->bbcode_second_pass_code('', '% zgrep -i xfs /proc/config.gz
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_VXFS_FS is not set
')

And on an x86_64 box:
$this->bbcode_second_pass_code('', '% zgrep -i xfs /proc/config.gz
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
CONFIG_XFS_ONLINE_SCRUB=y
CONFIG_XFS_ONLINE_REPAIR=y
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_VXFS_FS is not set
')

[WorMzy]

Well the only differences between the ODroid and the Pi kernel configs is that the Pi has the module built in, and has realtime support:

$this->bbcode_second_pass_quote('RPi model B', '
')$this->bbcode_second_pass_code('', 'build@meep[pts/0]~$ zgrep -i xfs /proc/config.gz
CONFIG_XFS_FS=y
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y
# CONFIG_XFS_ONLINE_SCRUB is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_VXFS_FS is not set
')

[summers]

on the odroid-c2 you can update to the latest kernel. IIRC you have to update uboot first; and then can go to the latest kernel.

the mainline kernel has been getting a lot better with the odroid-c2; mainly due to the effort baylibre has been putting in. So most thinks work, there *may* be an issue with usb - it what IIRC was one of the outstanding issues.

I think what you want is:
$this->bbcode_second_pass_code('', 'pacman -Rs uboot-odroid-c2
pacman -S uboot-odroid-c2-mainline linux-aarch64')

[WorMzy]

Thanks, summers, that's what I tried before, but I ended up with a unbootable system with no HDMI output so I couldn't even see what was failing. I'll have another play around with it at the weekend, see if there's anything I can tweak in boot.txt

[summers]

Ah yes my c2 has no screen. When you upgrade can you ssh into the machine? Thats what I do. If so the machine has come up, and just graphics is the problem. Means you could check if xfs works, and look into the hdmi problem.

Now on the hardkernel forum: https://forum.odroid.com/viewtopic.php?f=135&t=22717&start=1050 seems main place updates to mainline kernel are discussed. About page 19 or so there was some discussion on hdmi.

For me, I can see the basics of hdmi coming up, but as I've no screen attached can see whats actually happening:
$this->bbcode_second_pass_code('', '[summers@odroid-c2 ~]$ dmesg | egrep "drm|hdmi"
[ 6.728083] meson-drm d0100000.vpu: Queued 2 outputs on vpu
[ 6.753378] meson-drm d0100000.vpu: Failed to create d0100000.vpu debugfs directory
[ 6.755418] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 6.762022] [drm] No driver support for vblank timestamp query.
[ 6.768201] meson-drm d0100000.vpu: CVBS Output connector not available
[ 6.806410] meson-dw-hdmi c883a000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)
[ 6.811293] meson-dw-hdmi c883a000.hdmi-tx: registered DesignWare HDMI I2C bus driver
[ 6.819198] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops meson_dw_hdmi_ops [meson_dw_hdmi])
[ 6.827352] [drm] Cannot find any crtc or sizes
[ 6.832094] [drm] Initialized meson 1.0.0 20161109 for d0100000.vpu on minor 0
[ 6.886415] rc rc1: dw_hdmi as /devices/platform/soc/c883a000.hdmi-tx/rc/rc1
[ 6.891713] input: dw_hdmi as /devices/platform/soc/c883a000.hdmi-tx/rc/rc1/input1
[ 7.876344] [drm] Cannot find any crtc or sizes
')

[WorMzy]

Nope, after rebooting, I get a heatbeat, but no networking.USB works, so I can connect a keyboard. I can issue C-A-D and reboot it, but this happens instantly. Also, blindly trying to log in as root and issue 'poweroff' does not accomplish anything, so I guess ALARM isn't booting. Either uboot is failing to boot the kernel, or the kernel is panicking.

My only recourse at this point is to remove the eMMC, mount it on my laptop, copy over the install image /boot, and reinstall the stock uboot.

Is boot.txt documented anywhere? To me it looks like a script with variables that never get set anywhere, so I guess they're internal uboot vars. I figure configuring uboot is the only step I'm missing here, but I'm struggling to find any useful information about configuring it.

EDIT:
Interestingly, if I copy boot.ini.pacsave to /boot/boot.txt, run the mkscr script, and re-run sd-fusing.sh, the result is that I don't even get the heartbeat any more, so whatever the odroid is doing with the default boot.txt is definitely along the right lines. It's either a kernel panic, or it can't mount the eMMC. I guess my next thing to try would be booting the stock odroid kernel with mainline uboot...

EDIT2:
No luck with that. End up with no heartbeat. So I guess I can't eliminate either uboot-odroid-c2-mainline or linux-aarch64 as the problem.

[summers]

I half have to wonder if the problem is the eMMC - there have been quite a few issues with eMMC on the board; I have to down clock mine; other recently have reported voltage problems.

What happens if you try and install on a sD card? Do you get the same problems?

If that works, then try mounting the eMMC so you can see what errors happen.

Also note that modern uboot uses the /boot/boot.scr - so first you have to edit /boot/boot.txt then run the mkscr script to create the .scr file ...

[WorMzy]

Good idea, I'll see if I can get a cheap SD card to play around with. I don't have one to hand (other than the one in the RPi).

Out of interest, could you elaborate on "clocking down" the eMMC? Is there a kernel command line option for that?

[summers]

For me I down clocked the eMMC by changing the /boot/boot.txt to:
$this->bbcode_second_pass_code('', '# After modifying, run ./mkscr

test -n "${distro_bootpart}" || setenv distro_bootpart 1
part uuid ${devtype} ${devnum}:${distro_bootpart} uuid
setenv bootargs "console=ttyAML0,115200n8 root=PARTUUID=${uuid} rw rootwait earlycon"

if load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} /boot/Image; then
if load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
fdt addr ${fdt_addr_r}
fdt set /soc/apb@d0000000/mmc@74000 max-frequency <0x08f0d180>
if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
booti ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi
')
Where I added the fdt lines and then convered it to boot.scr. This set the card speed to 150MHz which worked for me. The mainline kernel though, a few version later, seeing the timing problem set the default speed down to 100MHz; so the speed change should already be slow enough that it works.

The recent problem others seem to have is the eMMC voltage it set wrong, this hasn't happened on my c2 so I don't know the problem. Its not clear on the other threads in the eMMC voltage is a device tree or a kernel bug.

Anyway if you can boot from an sD card you can see the errors, sD cards these days are fairly cheap - you can get a good quality one of say 32GB for ~£5 on Amazon. I use a 32GB Samsung EvoPlus UHS-I card - which speed the C2 can handle. After getting the C2 to boot, and then moving to the eMMC, I used the sD card as my /home directory - so save the eMMC for the OS.