You should be able to get SQL started.
However, I would start to build this environment incrementally. Start with a unclustered server at your primary and secondary, and debug all the issues with that. Then use your clustered machine as the primary and see what goes wrong. Depending on what is in Master, you may have problems starting a unclustered machine using a Master from a clustered machine.
I think you should be able to get SQL started because we do something vaguely similar to you and it works reliably.
We use Double-Take to replicate all our databases from our primary to secondary sites. SQL is up on the primary, down on the secondary. When we fail over, we stop SQL on the primary and start it on the secondary. We have to reset @@servername, but otherwise have no problems. Some of our pairs are on SQL7, the rest on SQL2K.
All SQL instances were originally installed independantly of each other, then when D-T replication was first turned on everything on the target was overwritten. We use D-T for replication as our apps have a lot of flat file data as well as databases and we need to keep all the replication in step.
This scenario seems close enough to your Master db restore to show that you should be able to get SQL running with what you are trying to do.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara