I suspect that both errors are related to web.config modifications that are failing either because

1. The ASP.Net worker process account does not have the needed write/modify permissions on web.config or web.config's readonly attribute is set or

2. The structure of web.config includes a <location> . . . </location> element making it impossible for the web.config nodes needing modification to be found.

You can see what web.config changes are being attempted by looking at the xml file \Install\Config\05.01.00.config or at the .dnn manifest file in Install\Provider\CorePermissionProvider_05.01.00_Install.zip

As for looking at the log file that would be \Providers\DataProviders\SqlDataProvider\05.01.00.log but errors of this sort were usually not logged back at the time of the earlier 5.x versions of DotNetNuke.

Joe,

The <location> . . . </location> elements are usually added to allow another aspx application to reside in a sub-folder without inheriting web.config settings from the main application. You may be able to temporarily remove the <location> . . . </location> (possibly two sets of these), perform the upgrade then replace them. However, there is a particularly nasty issue with these should you change the Application Pool for the site to run under ASP.Net 4.0. Essentially the modifications to web.config necessary to run under 4.0 will automatically be triggered over and over again causing the web.config file and Eventlog to grow rapidly and severely impacting performance of the site. I see in Gemini that the issue with <location> elements and DNN's XmlMerge utility will finally be addressed in 6.01.02.

If possible, I would try to avoid running a second aspx application in a sub-folder of the DNN install (or a DNN install in a sub-folder of another aspx application.