The goal with Scrum is to have releasable code at the end of each sprint. Now that does not necessarily mean that you have to do a release every sprint. Just that the code you have is potentially releasable. It could be that your Product Owner does not want to release every sprint, but they should always have the choice available to them.
It may be worth considering having a staging environment that is effectively production-ready code. All production releases would take place from this staging environment and the release would involve no additional testing or configuration. In other words, your staging environment is production ready code that just happens not to be in production yet.
This staging environment represents the end of a release pipeline and it includes the integrated release code from all of the Scrum teams. Each team tests at the unit level, at the functional level plus they run full integration and regression tests on the main code trunk. This is done in each and every sprint.
It is usually impractical to do this using manual testing methods. A better approach is to have automated integration and regression tests that are maintained by all the teams (and run via continuous integration).
This may seem like a difficult approach, but it offers the substantial benefit of avoiding discovering bugs at the 11th hour (a problem you mention in your question). You could also run a parallel release pipeline for your service packs, using a separate code branch.
I would highly recommend you take a look at the book "Continuous Deliver" by Jez Humble and David Farley for a detailed description of this kind of setup.