[Bug 58529] New: Smartsuite 9.8 installer fails unless z: is removed (with caveats)
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(a)winehq.org Reporter: imwellcushtymelike(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> --- What's the z:\\lotus\ ? And why is it copying from /tmp/* if you're installing from presumably mounted iso image? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #2 from Ken Sharp <imwellcushtymelike(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech(a)gmail.com --- Comment #3 from Eric Pouech <eric.pouech(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #4 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #5 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #6 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #7 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #8 from Dmitry Timoshkov <dmitry(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #9 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #10 from Ken Sharp <imwellcushtymelike(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #11 from Hans Leidekker <hans(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #12 from Ken Sharp <imwellcushtymelike(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #13 from Ken Sharp <imwellcushtymelike(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #14 from Eric Pouech <eric.pouech(a)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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #15 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Indeed my / is from subvolume @ and /home from subvolume @home. I didn't plan it that way, it just did it! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #16 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 79017 --> http://bugs.winehq.org/attachment.cgi?id=79017 Subvolume you can try this; it may or not help -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #17 from Ken Sharp <imwellcushtymelike(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #18 from Eric Pouech <eric.pouech(a)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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #19 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Created attachment 79019 --> http://bugs.winehq.org/attachment.cgi?id=79019 wine-10.12-135-g7c7b3e43047 +mountmgr -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #20 from Ken Sharp <imwellcushtymelike(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 Eric Pouech <eric.pouech(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #79017|0 |1 is obsolete| | --- Comment #21 from Eric Pouech <eric.pouech(a)gmail.com> --- Created attachment 79063 --> http://bugs.winehq.org/attachment.cgi?id=79063 tentative patch (V2) another attempt (looks like a couple of useful entries out of udisk2 were dropped in first version) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #22 from Eric Pouech <eric.pouech(a)gmail.com> --- (In reply to Ken Sharp from comment #20)
Created attachment 79020 [details] Patched wine-10.12-135-g7c7b3e43047 +mountmgr
Not sure if it helps but I've uploaded a +mountmgr with and without the patch applied.
thanks for both logs, that proved to be useful. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #23 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Created attachment 79074 --> http://bugs.winehq.org/attachment.cgi?id=79074 Patch 2 – wine-10.12-316-g17fb31af617 +mountmgr winecfg still complains it cannot find a c: drive, though the log suggests Wine is looking in the correct place(s). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=58529 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #24 from Ken Sharp <imwellcushtymelike@gmail.com> --- Finally figured it out... The installer automatically chooses the drive with the largest capacity. This is obvious when choosing a custom install. Confirmed the same behaviour on Windows 10. Because z: --> / it sees my root directory as the largest volume (or the one with the most free space), which it is. So when the installer tries to install to z:\lotus, it is trying to install to my root /. This fails for good reason. Choosing the custom install and pointing the installer back to c: works correctly, without needing to remove the z: drive. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla