-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MountImage: Get error when try to dismount after mounting iso #226
Comments
Hi @NemoDima , sorry for the delay in getting back to you. This is by design and is how DSC should be used. This was discussed in #154. I do understand the requirement though. In general, I'd recommend just leaving the ISO mounted permanently. @johlju - any thoughts you can share here? E.g. what do other users of SqlServerDsc tend to do? Do they just leave the ISO mounted? The gist is that DSC is designed to define a desired state. So creating a configuration that has two different states for a resource defined is considered illegal - e.g. in this case, having an ISO both mounted and unmounted is a conflict. |
@PlagueHO thank you for the answer and explanation. Now I understand DSC logic quite better. For my purpose, I'll try to look on Script(https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/scriptresource) or xScript from xPSDesiredStateConfiguration (https://github.com/dsccommunity/xPSDesiredStateConfiguration). Thanks again |
@PlagueHO normally I would say you don’t mount an ISO. I would say that the normal production scenario is instead to extracted the ISO into an UNC path and the SourcePath parameter of SqlSetup resource is pointed to that UNC path. Mounting an ISO is probably best used in lab environments where you change SQL Edition very often and don’t want to change the configuration for whatever reason. Although it seems for whatever reason the normal scenario is mounting an iso. Not sure if that is by old habit from click-install processes. @NemoDima is there a reason you mount the image instead of using an UNC share. Interested if the normal scenario I describe above is not as normal as I expect. 😊 |
@johlju We have a scenario where we host clients on bare metal machines which only have Windows Server installed and we need to install everything else, most notably SQL Server. Our ideal workflow would be: download ISO file, mount, run SQL Server setup, unmount image, delete file. I'm aware it's much more imperative than declarative :-) @NemoDima, the way we work around this is that we have a set of partial DSC configurations used for "initial configuration" - these involve bootstrapping our custom DSC resources module, setting up some very basic prerequisites (e.g. setting timezone, machine name, etc). That configuration set also contains a "one-off" partial configuration which sets up our SQL Server: downloads SQL Server ISO file, mounts it and runs SQL Server setup. For SQL Server 2017 and later, it also downloads and installs SSRS. That configuration set is run only once, against a brand-new machine. After that, we have another set of partial configurations, which is a superset of the "initial configuration" partial configurations, with the one-off partial configuration removed. @johlju, our approach does hit a snag at the moment, though. Our regular configuration unmounts the SQL Server ISO file and deletes it (no need to keep a few GB permanently mounted). Unfortunately, I think the simplest solution would be for |
Another approach i've used in the past is to use a Script resource to install SQL based on a configuration file - see the example here: https://colinsalmcorner.com/install-and-configure-sql-server-using-powershell-dsc/ You do lose visibility within DSC with this approach, it used to be my go-to method when the install resource was less mature. Now, the approach i typically take is to create a template that includes the SQL media already in situ, which could be kept up to date using something like packer (or a script). Understand this means you've got ISOs copied everywhere, but in this age of de-duplicated storage and other wizardry it wasn't a worry for us. |
I think you will also hit a problem in SqlSetup if it is used since |
Details of the scenario you tried and the problem that is occurring
Get error when try to dismount after mounting iso.
Verbose logs showing the problem
Suggested solution to the issue
N/A
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
Version and build of PowerShell the target node is running
Version of the DSC module that was used ('dev' if using current dev branch)
current
The text was updated successfully, but these errors were encountered: