http://bugs.winehq.org/show_bug.cgi?id=58529
Bug ID: 58529 Summary: Smartsuite 9.8 installer fails unless z: is removed (with caveats) Product: Wine Version: 10.12 Hardware: x86-64 URL: https://archive.org/download/lotus-smart-suite-9.8.2-m illennium-edition-9.8.2-2009-03-english-cd/Lotus%20Sma rtSuite.iso OS: Linux Status: NEW Keywords: download, Installer Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: imwellcushtymelike@gmail.com Distribution: Ubuntu
Created attachment 79002 --> http://bugs.winehq.org/attachment.cgi?id=79002 Wine 10.12 console output
The installer for Smartsuite 9.8 claims it is interrupted before it can complete a task.
0170:err:msi:execute_command can't find executable 2 0170:err:msi:ACTION_InstallFiles Failed to copy L"Z:\tmp\wine\ss\Lotus\Register\PMEMW.DLL" to L"Z:\lotus\Register\PMEMW.DLL" (3) 0170:err:msi:execute_script Execution of script 0 halted; action L"InstallFiles" returned 1603 0170:err:msi:ITERATE_Actions Execution halted, action L"InstallFinalize" returned 1603
There are two ways to work around this: 1. Remove the z: drive (and add a d: drive for the installation path) before installation. 2. Install to my internal disk(s).
I thought it might be related to the filesystem but I tried tmpfs, btrfs and ext4 and the result is the same.
I thought it might need to be on the same btrfs volume as Wine but installing it on another volume works fine.
I even tried adding a label to a thumb drive (btrfs) in case that was the issue but the result is the same - it fails no matter what when installing to the thumb drive, unless I do 1. above.
Permissions are correctly set in all cases.
I don't know what else I can try.
Went back to Wine 8.0.1 and tried Staging 10.12 but the result is always the same.
As can be seen from the log, the installer tries to install to the z: drive instead of c:, unless I install to an internal drive. Remove z: and I can install anywhere. Everything else remains the same.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- What's the z:\lotus\ ? And why is it copying from /tmp/* if you're installing from presumably mounted iso image?
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #2 from Ken Sharp imwellcushtymelike@gmail.com --- z: is automatically generated and links to /, so z:\lotus does not exist. A successful install puts the files in c:\lotus.
/tmp/wine/ss is the mounted iso. d: --> /tmp/wine/ss to make the workaround work. The mount could be anywhere.
http://bugs.winehq.org/show_bug.cgi?id=58529
Eric Pouech eric.pouech@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@gmail.com
--- Comment #3 from Eric Pouech eric.pouech@gmail.com --- when you write in #1 that you tried different fs, for which mount point was it?
maybe unrelated (but could be from symptoms), but would one of your mounted fs be btrfs with subvolumes used?
'mount | grep subv' would tell
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #4 from Hans Leidekker hans@meelstraat.net --- The installer runs a custom action that queries available drives with GetLogicalDriveStringsA() and then checks each for drive type and available space. Then it sets the INSTALLDIR property to a path on the selected drive. Looks like it picks the drive with the largest amount of free space.
I suspect it will fail in the same way on Windows if the chosen drive happens to be read-only. There's something to be said for not creating a z: drive mapping to a read-only root directory by default.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- We'll need this mapping anyway, in this case the best way I think is to script this drive removal unless it affects more installers.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #6 from Hans Leidekker hans@meelstraat.net --- (In reply to Nikolay Sivov from comment #5)
We'll need this mapping anyway, in this case the best way I think is to script this drive removal unless it affects more installers.
Is there anything in Wine that requires this mapping? I thought files outside of drive mappings could still be accessed through ??\unix paths. It certainly is convenient to have that mapping because you don't need to use 'wine start /unix ...' for example, but perhaps we could be smarter about that?
I'm not saying we shouldn't map root by default, I'm just pointing out that on Windows you're much more unlikely to hit this case.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #7 from Nikolay Sivov bunglehead@gmail.com --- System font files are accessed through it, don't know about anything else using it internally. But I think to access any file in your user home you would go through this mapping.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Hans Leidekker from comment #6)
Is there anything in Wine that requires this mapping? I thought files outside of drive mappings could still be accessed through ??\unix paths. It certainly is convenient to have that mapping because you don't need to use 'wine start /unix ...' for example, but perhaps we could be smarter about that?
Another possibility is to mark z: as a network drive. Would that make installer avoid choosing it as the installation target?
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #9 from Hans Leidekker hans@meelstraat.net --- (In reply to Dmitry Timoshkov from comment #8)
(In reply to Hans Leidekker from comment #6)
Is there anything in Wine that requires this mapping? I thought files outside of drive mappings could still be accessed through ??\unix paths. It certainly is convenient to have that mapping because you don't need to use 'wine start /unix ...' for example, but perhaps we could be smarter about that?
Another possibility is to mark z: as a network drive. Would that make installer avoid choosing it as the installation target?
Probably, since it checks the drive type, but I imagine this could trip other applications.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #10 from Ken Sharp imwellcushtymelike@gmail.com --- (In reply to Eric Pouech from comment #3)
when you write in #1 that you tried different fs, for which mount point was it?
I created multiple mount points (named btrfs, ext4, etc.) and pointed the wineprefix to them. Installation completes with z: removed.
maybe unrelated (but could be from symptoms), but would one of your mounted fs be btrfs with subvolumes used?
My test mount points didn't use subvolumes. My system uses subvolumes. / and /home span multiple SSDs, and another spinning disk which also uses subvolumes. The installation works when installing to either of these.
(In reply to Hans Leidekker from comment #4)
Looks like it picks the drive with the largest amount of free space.
Tested on Win 10 and this is exactly what happens.
I suspect it will fail in the same way on Windows if the chosen drive happens to be read-only.
In Win 10 it does indeed fail, but the installer actually tells you that it cannot write to the drive, allows you to cancel and claims to rollback, though it leaves c:\NotesSQL behind, which it always chooses c: (or maybe %systemdrive%) for.
So there's possibly an additional issue here: the installer isn't being told that the drive is readonly, or the installer doesn't know what to when it is told, OR it is related to how msiexec is run (/qf? /qb?). https://bugs.winehq.org/show_bug.cgi?id=37833#c1
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #11 from Hans Leidekker hans@meelstraat.net --- (In reply to Ken Sharp from comment #10)
(In reply to Hans Leidekker from comment #4)
I suspect it will fail in the same way on Windows if the chosen drive happens to be read-only.
In Win 10 it does indeed fail, but the installer actually tells you that it cannot write to the drive, allows you to cancel and claims to rollback, though it leaves c:\NotesSQL behind, which it always chooses c: (or maybe %systemdrive%) for.
How did you test this? Note that my comparison wasn't entirely accurate because the z: drive isn't actually read-only (and shouldn't be reported as read-only because certain parts of the tree will be writable). So to properly test this on Windows the drive should be writable but creating a folder in the root should fail with an access denied error.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #12 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 79010 --> http://bugs.winehq.org/attachment.cgi?id=79010 No c: drive shown
shouldn't be reported as read-only because certain parts of the tree will be writable
Good point!
How did you test this?
I made the whole disk read only as it was empty. diskpart select disk 1 att disk set readonly
Because the installer installs to \lotus I couldn't think how else to do it. There's no . for me to set the properties on. I'm sure there's a way but I simply don't know how.
However, I could choose the Custom setup rather than Complete, and manually enter c:\lotus. This is by far the easier workaround and something I should have worked out long before now. I can't select c: like I can in Windows (screenshot¹).
So I tried again and left the other disk writeable, but created a directory set to readonly for the application to install into. Of course it's Windows and readonly means very little so it installed into that directory without issue.
I then tried to add explicit Deny to that directory instead. However, Windows 10 cried and spat it's dummy out, then the whole disk became inaccessible. Then I gave up.
¹ In Windows when I attempt to go up a level from a drive, it doesn't do anything. In Wine it keeps adding z: to the drop-down list, but nothing else. Note there is no c: drive.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #13 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 79011 --> http://bugs.winehq.org/attachment.cgi?id=79011 Missing directories
Attaching this here in case it's related.
Wine choose z: (which of course should be linked to /) but many directories are missing. For example, there is no /bin, /home or /tmp. I don't know if this is the intended behaviour.
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #14 from Eric Pouech eric.pouech@gmail.com --- (In reply to Ken Sharp from comment #10)
(In reply to Eric Pouech from comment #3)
when you write in #1 that you tried different fs, for which mount point was it?
I created multiple mount points (named btrfs, ext4, etc.) and pointed the wineprefix to them. Installation completes with z: removed.
maybe unrelated (but could be from symptoms), but would one of your mounted fs be btrfs with subvolumes used?
My test mount points didn't use subvolumes. My system uses subvolumes. / and /home span multiple SSDs, and another spinning disk which also uses subvolumes. The installation works when installing to either of these.
There are cases when btrfs subvolumes inside the same volume have paths that overlap (typically / and /home), where the reverse lookup (unix path => mount point => drive letter doesn't work correctly as mountmgr doesn't find/use the relevant mount point - or confuses the two).
so if your setup has / and /home as subvolumes in the same btrfs volume, you could fall into the issue I'm thinking of. It's that's the case, I can share some hacks to deal with that (can't tell from here if that would be useful, and likely from the rest of the exchange, there could be some other issues)
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #15 from Ken Sharp imwellcushtymelike@gmail.com --- Indeed my / is from subvolume @ and /home from subvolume @home. I didn't plan it that way, it just did it!
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #16 from Eric Pouech eric.pouech@gmail.com --- Created attachment 79017 --> http://bugs.winehq.org/attachment.cgi?id=79017 Subvolume
you can try this; it may or not help
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #17 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 79018 --> http://bugs.winehq.org/attachment.cgi?id=79018 winecfg with patch
With the patch, the installation remains the same, but it makes winecfg very unhappy (screenshot attached).
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #18 from Eric Pouech eric.pouech@gmail.com --- (In reply to Ken Sharp from comment #17)
Created attachment 79018 [details] winecfg with patch
With the patch, the installation remains the same, but it makes winecfg very unhappy (screenshot attached).
that's not the intent for winecfg :-( can't repro here (even on fresh prefix) but that lower the likelyness subvolumes are the cause here (anyway if you have time, sharing a WINEDEBUG=+mountmgr could help maybe)
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #19 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 79019 --> http://bugs.winehq.org/attachment.cgi?id=79019 wine-10.12-135-g7c7b3e43047 +mountmgr
http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #20 from Ken Sharp imwellcushtymelike@gmail.com --- Created attachment 79020 --> http://bugs.winehq.org/attachment.cgi?id=79020 Patched wine-10.12-135-g7c7b3e43047 +mountmgr
Not sure if it helps but I've uploaded a +mountmgr with and without the patch applied.
-
WineHQ Bugzilla