Error when mount: can't find valid F2FS filesystem in ** superblock

[James_ZHANG]

Hi all, I am facing an error when I tried to mount a USB(let me call it USB_2) device.

background:
I extracted the image which is downloaded from official site, and I wrote the "openwrt-21.02.1-x86-64-generic-ext4-combined.img" into a USB(let me call it USB_1) and I boot from it on my X86 PC successfully (model: HP T520).

I want to mount that USB_2 because I want to write the image into my local SSD on T520, just like the guidance in https://openwrt.org/docs/guide-user/installation/openwrt_x86 . However, it had an unexpected error as the screenshot...

(it's same when I tried to mount on /mnt/***)

and I searched some answers, maybe relative to :

F2FS on USB stick does not work

Thanks @Plonk34 Your patch working with octeon soc.

my question is : is that same situation for my issue? how to identify ? is that mean that I have to change the source code and compile for my device?

your kindly help is important for me and other X86 users, thanks very much!

[slh]

What filesystem is on your USB_2?

Did you check if the filesystem was mounted nevertheless (f2fs is quite dominant and chatty, the real fs driver might still have succeeded silently afterwards).

[James_ZHANG]

Yes, I suspected my USB_2 files system before, so I tried FAT32 & exFAT but neither of them made this situation better, same err came. What's more, the err msg seems the issue is on the SSD side.

and let me attach the filesystem on SSD:

it's also matching the official site's introduction, which is ext4, which should be writable & readable.

[_FailSafe]

@James_ZHANG

I extracted the image which is downloaded from official site, and I wrote the "openwrt-21.02.1-x86-64-generic-ext4-combined.img" into a USB(let me call it USB_1) and I boot from it on my X86 PC successfully (model: HP T520).

I want to mount that USB_2 because I want to write the image into my local SSD on T520, just like the guidance in https://openwrt.org/docs/guide-user/installation/openwrt_x86 . However, it had an unexpected error as the screenshot...

Sorry if I'm misunderstanding, but your goal is to write the openwrt-21.02.1-x86-64-generic-ext4-combined.img to your T520's SSD--is that correct?

If so, what I do is grab a lightweight "live" USB distro like Gparted (https://gparted.org/download.php). Write the distro (you can use Rufus or balenaEtcher if you like) you choose to your USB disk (likely FAT32 formatted). Then before you boot from it, copy the openwrt-21.02.1-x86-64-generic-ext4-combined.img file directly to the root of that same USB with the live distro on it.

After the copy completes, boot from the live USB you just created and launch a shell. Assuming /dev/sda is your SSD and /dev/sdb is your USB you booted from, run the following:

sudo su -
mkdir -p /mnt/usb
mount /dev/sdb1 /mnt/usb
dd if=/mnt/usb/openwrt-21.02.1-x86-64-generic-ext4-combined.img of=/dev/sda bs=4M; sync;
reboot

Remove the USB and you should be booting into OpenWrt from your SSD after the reboot.

[James_ZHANG]

Hi bro, thanks for your new idea, firstly yes my final goal is to write into T520's SSD, and I used a centos live USB and performed all necessary operations.

well I attempted what I want to but we didn't resolve this problem directly, we used another way.

anyway, problem resolved, thanks very much!

[mk24]

The mount command by default has all the filesystem drivers probe the partition until one recognizes it is is its type and mounts it. That error message is just a warning from the f2fs kmod that during the process a f2fs filesystem was not found. Which is expected behavior if the partition is formatted with a different filesystem. The other drivers silently ignore finding a different filesystem.

If you aren't going to be using any f2fs partitions at all, you could remove kmod-fs-f2fs. Note that the squashfs images for x86, Raspberry Pi, and a few other platforms use f2fs as the overlay, so f2fs must be in the kernel. The optional ext4 image does not use f2fs, but it runs the same kernel with f2fs built into the initial load, so it's going to be there unless you make a custom kernel build.