A problem is anything that occurs that gets in the way of achieving your aim. Problems can be bugs, unknowns, or anything else large or small that blocks your intended path.
Much of software development and release are ultimately about solving problems. Some problems are easy to solve. It's a bug, so you fix it. There are two candidate designs on the table, so you prototype them to see which is better. Some problems are less easy to solve, or have no apparent solution. Sometimes we just don't know.
These are the kinds of problems that can stop an effort (or a release, or a product, or even a company) dead in its tracks. Things are going along just fine, then a problem arises, and days or weeks pass while you seek a solution, the release date goes by, other work is piling up, and we're all stuck on a problem without a solution.
Problems without solutions are not problems. They are simply circumstances.
Until and unless you have a solution, a problem is simply a fact. It's something that you have to handle but cannot change (at least, not immediately), just like you have to handle the operating system you chose to deploy on, and the market in which you compete.
Can these things be changed? Yes. Over time, we can chose to stop deploying on Red Hat Linux and start deploying on Windows. We can chose to leave the healthcare market and enter the financial market. We can find a workaround or change the nature of the problem. But until we do, that problem is simply a circumstance with which we have to deal.
For example, I had a problem once where there was a massive bug in the production deployment tool we were using. We simply couldn't use the tool any more. Of course, we discovered this late in the release, and we couldn't immediately solve the problem. So for that release, the problem had no solution. It was simply a circumstance of the release. Instead of spending a lot of time and effort worrying about it, we simply assessed the situation, determined there was no immediate solution, and accepted that in this circumstance we would be going with a new deployment methodology.
Once we accepted that, we were able to keep going on the release. It wasn't the prettiest deployment (we ended up doing it by hand with some quick tooling for validation), but we got through it and we got through it on time. All because we didn't waste time worrying about a problem we couldn't solve.
Oh, and for the following release, we solved the problem: we switched deployment tools.