Fail to emulate TL-WR940N

[zr950624]

Hi,

When I try to emulate the firmware of TL-WR940N_v6 (https://static.tp-link.com/2020/202004/20200430/TL-WR940N(US)_V6_200316.zip).
I get the following error messages during running

Step 8. Emulate firmware 1 with the inferred network configuration. This will modify the configuration of the host system by creating a TAP device and adding a route.
./scratch/1/run.sh

[    2.356000] No filesystem could mount root, tried:  ext3 ext2 ext4 cramfs squashfs vfat iso9660 romfs udf
[    2.356000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

The previous steps are executed smoothly. (except I get a empty set during inferNetwork.sh)
I do not see the reason for this error. Could you please give me some help about it?

BTW, The firmware was extracted by
./sources/extractor/extractor.py -b TP-Link -sql 127.0.0.1 -np -nk "TL-WR940N(US)_V6_200316.zip" images.
Thanks.

[liuliqaz]

same problem,need help, Thanks

[extremecoders-re]

Please have a look at this issue #60

[adi0x90]

The kernel panic is the first thing to resolve here. With Unable to mount root fs on unknown-block(8,1), the guest hasn't reached a point where a working network or web interface can be expected.

FAT 2 prepares images and selects kernels differently on its native system path, but port forwarding can't fix a root filesystem the kernel won't mount.

Please share a v2 run for the same TL-WR940N v6 image, including its hash, backend/kernel profile, preflight output, and serial log. I need a successful root mount and service startup before calling this one fixed.

[adi0x90]

I tested TL-WR940N(US)_V6_200316.zip from your download link, including both the ZIP itself and its .bin member. PR #108 now recovers the rootfs through both entry paths, and all 576 regular files and symlink targets matched independent reference extraction. These extraction checks used case-sensitive APFS.

Please retry with FAT 2.0.1 in a fresh FAT project so an old extraction manifest is not reused. Keep the executable and its matching share directory together. Use case-sensitive output storage if the image contains filenames that differ only by case.

Your original report concerns the root-mount kernel panic, so I'm keeping this open until that boot step is checked. If it still fails, please attach the new serial log and include the kernel/backend used. That will let me distinguish the remaining boot failure from the extraction problem that is now fixed.