Closed DigNative closed 3 years ago
Thank you, this seems to be a special setup configuration. I cannot reproduce this bug with a regular installation. That said, I cannot work on this issue effectively.
The shared setup flag is stored in these places:
HKLM\SOFTWARE\MiKTeX.org\MiKTeX\Core
: SharedSetup=1
[Core]
: SharedSetup=1
Maybe this info helps you to investigate the issue.
The issue will be reopened when we have enough info in order to fix the bug.
Thank you for your very fast answer and the hints for further investigation.
I think the setup is not really special in that sense; I would rather assume you probably have no "old enough" installation at hand which triggers the issue. I also cannot reproduce it if the MiKTeX installation is only some months old --- the update will then work.
The systems are essentially installed using the CLI network installer (miktexsetup-4.1-x64.zip
) and the following arguments: --shared=yes --modify-path=yes --use-registry=no --common-install=c:\apps\MiKTeX\ --package-set=complete --local-package-repository=c:\apps\MiKTeX-packages\ --quiet install
. The path c:\apps\MiKTeX-packages\
is just a 1:1 copy of the /systems/win32/miktex/tm/packages/
directory on CTAN on one of our internal servers to relieve load from the CTAN servers and speed up installation.
I just checked the flag in the miktex.ini
file after ending up with the situation as described in my first post: The SharedSetup
flag is still set to 1
, so this is fine:
;;; DO NOT EDIT THIS FILE!
[Core]
LastAdminMaintenance=1625845499
NoRegistry=1
SharedSetup=1
[MPM]
AuthToken=[REDACTED]
AuthTokenNotValidAfter=1609867599
AutoInstall=0
LastAdminUpdate=1625845823
LastAdminUpdateCheck=1625845501
LastAdminUpdateDb=1625845499
LocalRepository=//[REDACTED]/software-dist/tex/systems/win32/miktex/tm/packages
RepositoryType=local
[Setup]
LastAdminDiagnose=1625845502
In principle, the registry should not have an effect as far as I understand, since we are using the --use-registry=no
option during installation. However, when checking the registry with the information you provided, I can see actually that there is a corresponding key, but also a difference: There is no HKLM\SOFTWARE\MiKTeX.org\MiKTeX\Core
key on the system: I can only find HKLM\SOFTWARE\MiKTeX.org\MiKTeX\2.9\Core
. Is it just a mistake that the 2.9
in the path is missing in your post or should the version number really not appear?
Thank you. I will try to reproduce it with the given info.
Thank you for the effort! My recommendation would be to use an installation as of November 2020. In case you would need the original package repository and setup utility versions of this time, you can use the following link: https://ctan.space-pro.be/repo/!svn/bc/1712/systems/win32/miktex/
It points to a SVN server of me, which creates a snapshot of CTAN every day. Revision 1712 is of November 24, 2020.
During startup, when the configuration is not yet known, miktex.ini
is also searched in c:\apps\MiKTeX\miktex\config
. So maybe this is a workaround for the issue:
mkdir c:\apps\MiKTeX\miktex
mkdir c:\apps\MiKTeX\miktex\config
echo [Core]> c:\apps\MiKTeX\miktex\config\miktex.ini
echo SharedSetup=1>> c:\apps\MiKTeX\miktex\config\miktex.ini
Thank you, I will try this in a couple of minutes. Another thing (I don't know if it is related or not, but probably you can say better than I): I noticed above that our automated deployment of MiKTeX is currently failing as well. I am in parallel debugging this on the same machines and the MiKTeX setup utility (miktexsetup_standalone
) is also throwing an error:
>miktexsetup_standalone.exe --shared=yes --modify-path=yes --use-registry=no --common-install=c:\apps\MiKTeX\ --package-set=complete --local-package-repository=c:\apps\miktex-packages\ --verbose install
this is MiKTeX Setup Service 4.2 (MiKTeX 21.1)
starting installer...
Loading package database...
starting package maintenance...
installation directory: c:\apps\MiKTeX\
package repository: c:\apps\miktex-packages\
visiting repository c:\apps\miktex-packages\...
repository type: local package repository
loading package repository manifest...
package repository digest: 4855bdc76af4c516884c58e8ae6c8565
going to install 196615 file(s) (4378 package(s))
extracting files from 12many.tar.lzma...
extracting files from a0poster.tar.lzma...
...
...
...
extracting files from zxjatype.tar.lzma...
extracting files from zztex.tar.lzma...
updating package manifests (c:\apps\MiKTeX\miktex/config\package-manifests.ini)...
installed 136 package manifests
visiting repository c:\apps\miktex-packages\...
repository type: local package repository
loading package repository manifest...
turning on administrator mode
MiKTeX encountered an internal error.
Data:
Source: Libraries\MiKTeX\Core\Session\texmfroot.cpp:238
MiKTeX encountered an internal error.
Info:
Source: Libraries\MiKTeX\Core\Session\texmfroot.cpp
Line: 238
Sorry, but "MiKTeX Configuration Utility" did not succeed.
log4cxx: No appender could be found for logger (initexmf).
log4cxx: Please initialize the log4cxx system properly.
initexmf: MiKTeX encountered an internal error.
Do you think it could be related or should I better open another issue for it?
I tried your suggestion, but had to add a space in the last command before the >>
:
mkdir c:\apps\MiKTeX\miktex mkdir c:\apps\MiKTeX\miktex\config echo [Core]> c:\apps\MiKTeX\miktex\config\miktex.ini echo SharedSetup=1 >> c:\apps\MiKTeX\miktex\config\miktex.ini
Indeed, this brought back the shared installation in the MiKTeX Console: I can see now all packages again and the configuration also seems normal as before. However, upon executing xelatex
, for example, I receive a couple of DLL errors:
I can see these files are in the C:\apps\MiKTeX\miktex\bin\x64
folder, but with a different version number:
I executed initexmf --admin --mkmaps --mklinks
since this was the aborted command during the update (at least the error I could see in the logs), but this doesn't cause the errors to disappear. Probably there are more commands to be executed in the regular process which I am not aware of.
Please try
initexmf --admin --mkmaps --mklinks --force
Executing the command
initexmf --admin --mkmaps --mklinks --force
as proposed by you worked and the installation is back to normal now. I cannot observe an issue anymore. 😀 I have a workaround now which a can apply to our systems. Thank you very much for your fast and very good support!
In parallel, I verified that this issue is actually reproducible on vanilla Windows systems (not integrated into our corporate systems, to exclude the possibility that our particular configuration of Windows/operational environment is contributing to the issue): If I repeat the steps from my original post using an MiKTeX installation in the repository state as of November 2020 on a newly installed vanilla Windows 10 VM, I observe the same issue after upgrading. So it will potentially affect many users with older MiKTeX installations trying to update at a particular point in time.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I can confirm that this issue still exists and also appears during new installations. As a workaround, we are currently manually adding a [SHARED_MIKTEX_INST_PATH]\miktex\config\miktex.ini
with the contents mentioned in https://github.com/MiKTeX/miktex/issues/868#issuecomment-877343381 above before starting the MiKTeX installation using the miktexsetup_standalone
installer.
If we don't do this, the installation fails on all of our computers, reproducible with different versions of Windows 10.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Submitting a MiKTeX problem report
Updating a shared installation of MiKTeX on Windows with the currently available official package versions leads to a corruption of the entire MiKTeX installation. I tried with five different computers with different installation dates (ranging from February 2020 to January 2021), and the issue is reproducible on all of the computers.
What I did:
initexmf
report to confirm that I have a shared installation on the computer.The following issues were detected: 1: minor issue: It has been a long time since a MiKTeX administrator has checked for updates.
GENERAL MIKTEX INFORMATION ReportDate: 2021-07-09 14:56:44 CurrentVersion: 20.12 SetupDate: 2021-01-06 15:14:00 SetupVersion: 20.12 Configuration: Regular GitInfo: 7017ca6 / 2020-12-13 20:26:45 OS: Windows 10 Enterprise, 64-bit, build 17763 SharedSetup: yes LinkTargetDirectory: C:\apps\MiKTeX\miktex\bin\x64 PathOkay: yes LastUpdateCheckAdmin: 2021-07-09 14:46:05 LastUpdateAdmin: 2021-07-09 14:51:44 LastUpdateDbAdmin: 2021-07-09 14:46:03 SystemAdmin: yes RootPrivileges: yes AdminMode: yes Root0: C:\ProgramData\MiKTeX Root1: c:\apps\MiKTeX\ CommonInstall: c:\apps\MiKTeX\ CommonConfig: C:\ProgramData\MiKTeX CommonData: C:\ProgramData\MiKTeX Invokers:
ERROR DETAILS Program: initexmf.exe Error: The executed process did not succeed. Details: fileName: c:\apps\MiKTeX\miktex\bin\x64\initexmf.exe exitCode: 1
2021-07-09 14:51:45,767+0200 INFO miktex-console.core - start process: initexmf --admin --mkmaps --mklinks 2021-07-09 14:51:47,486+0200 ERROR mainwindow - :0: The executed process did not succeed.(fileName="c:\apps\MiKTeX\miktex\bin\x64\initexmf.exe", exitCode="1") 2021-07-09 14:57:02,078+0200 WARN main - session.use_count() == 8 2021-07-09 14:57:02,078+0200 INFO main - finishing with exit code 0
initexmf --admin --mkmaps --mklinks Option --admin only makes sense for a shared MiKTeX setup.
Sorry, but "MiKTeX Configuration Utility" did not succeed for the following reason:
Option --admin only makes sense for a shared MiKTeX setup.
The following issues were detected: 1: major issue: So far, you have not checked for MiKTeX updates. 312 [0x00001d4c] INFO initexmf null - this process (9652) finishes with exit code 0