Bugs as a class have inherently unbounded time and effort to fix (or rather, they size as either "trivial" or "infinite pending investigation") but effort for individual bugs can be bounded by an assessment of how much time and effort to invest. Help your manager make this assessment by clearly delineating trade-offs. Help your manager help you and the team by clearly communicating progress and flagging unknowns/blockers.
1. Clarify the motivation for the time-box. Is there an externally imposed deadline? An angry customer? A dependency impacting another team or teams in the business? Is it more a matter of boosting the team's sense of priority/urgency and keeping a project from getting off track?
2. Clarify what outcomes are acceptable as "fixed" for the immediate deadline and whether you can do a mitigation to buy time for further investigation. Can you disable a feature, support partial functionality, do some filthy hack, temporarily do something manually, etc.? Try to give your manager some sense of the time/effort required for each possible solution or mitigation.
3. Share clear plans for investigating the bug, progress and findings so far, and next steps after the root cause has been identified. Be specific: "We have researched X, Y, and Z so far. Today, Bob will investigate Thing A and Alice will investigate Thing B. We'll give you an update by 2pm this afternoon."
4. If applicable, flag areas where lack of information or co-operation is blocking the team. DO NOT throw your team members or partners under the bus here, however, you can get into issues like "We're having trouble finding where to escalate questions for Legacy Service" and ask your manager for help.
I've used the words "clear/clarify" and "communicate" a lot here because those are the core issues. For your manager this isn't a philosophical discussion about the unknowable nature of software defects, this comes down to how to allocate resources efficiently for the business and how to reflect status to various stakeholders.