Skip to content

Fail to emulate TL-WR940N #58

Description

@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.

Activity

  1. liuliqaz commented on Nov 5, 2020

    @liuliqaz

    same problem,need help, Thanks

  2. extremecoders-re commented on Nov 9, 2020

    @extremecoders-re
    Contributor

    Please have a look at this issue #60

  3. adi0x90 commented on Sep 25, 2026

    @adi0x90
    Member

    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.

  4. adi0x90 commented on Sep 26, 2026

    @adi0x90
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions