MikTeX Windows 7 64-bit, can't download packages
mcovington
64-bit system, and neither of them can download packages (from any of
several of the FTP servers on the menu). Is this a known problem?
MikTeX 2.6 would actually report failure downloading; MikTeX 2.8 is
less explicit. Conceivably, this could be a firewall problem (I'm
using Microsoft Security Essentials) -- but I can FTP to and from
other sites, and I'm not getting any security warnings. Any other
ideas?
J. Muennix
Do you run MikTeX with admin rights?
mcovington
No... didn't have to in 32-bit Vista... but will try it.
mcovington
> > Do you run MikTeX with admin rights?
>
> No... didn't have to in 32-bit Vista... but will try it.
That isn't it. MiKTeX Package Manager automatically elevates to admin
level when it needs to (and I get the UAC prompt). Rather, what I'm
getting looks like simple inability to download, like what is shown
below. I am wondering if it's a firewall issue after all and will
investigate along those lines.
Or is MiKTeX systematically mistaken about where it is supposed to be
downloading from?
======================================================================
starting package maintenance...
installation directory: "C:\Program Files\MiKTeX 2.8"
package repository: http://mira.sunsite.utk.edu/CTAN/systems/win32/miktex/tm/pac
kages/
lightweight database digest: 306f464d4aeed0da8a27784ea3ab33de
going to download 357469 bytes
going to install 28 file(s) (1 package(s))
downloading http://mira.sunsite.utk.edu/CTAN/systems/win32/miktex/tm/packages/pr
eprint.cab...
latex.exe: Error response from server: 404
======================================================================
Robert Heller
>
>
> > > Do you run MikTeX with admin rights?
> >
> > No... didn't have to in 32-bit Vista... but will try it.
>
> That isn't it. MiKTeX Package Manager automatically elevates to admin
> level when it needs to (and I get the UAC prompt). Rather, what I'm
> getting looks like simple inability to download, like what is shown
> below. I am wondering if it's a firewall issue after all and will
> investigate along those lines.
>
> Or is MiKTeX systematically mistaken about where it is supposed to be
> downloading from?
A 404 error would not be a firewall issue (I firewall would block
access and you would get a connection failure of some sort). It seems
that the URL MiKTeX Package Manager is using is wrong:
sauron.deepsoft.com% lynx -head -mime-header http://mira.sunsite.utk.edu/CTAN/systems/win32/miktex/tm/packages/preprint.cab
HTTP/1.1 404 Not Found
Date: Wed, 25 Nov 2009 02:54:43 GMT
Server: Apache/2.2.3 (Red Hat)
Connection: close
Content-Type: text/html; charset=iso-8859-1
There isn't a preprint.cab file there. There is a preprint.tar.lzma
file there instead.
>
> ======================================================================
> starting package maintenance...
> installation directory: "C:\Program Files\MiKTeX 2.8"
> package repository: http://mira.sunsite.utk.edu/CTAN/systems/win32/miktex/tm/pac
> kages/
> lightweight database digest: 306f464d4aeed0da8a27784ea3ab33de
> going to download 357469 bytes
> going to install 28 file(s) (1 package(s))
> downloading http://mira.sunsite.utk.edu/CTAN/systems/win32/miktex/tm/packages/pr
> eprint.cab...
> latex.exe: Error response from server: 404
> ======================================================================
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Download the Model Railroad System
http://www.deepsoft.com/ -- Binaries for Linux and MS-Windows
hel...@deepsoft.com -- http://www.deepsoft.com/ModelRailroadSystem/
mcovington
to go to the wrong places? I've tried several different sources (when
it let me select them) and had problems with all.
This is a fresh download of MiKTeX. Maybe I need to run updates or
something?
mcovington
downloading and installing preprint.tar.lzma. But when MiKTeX was
trying to obtain "preprint" on the fly, it looked for preprint.cab,
which doesn't exist. I actually don't know if there would have been a
problem downloading anything else.
Looks like the problem is that MiKTeX is misinformed about the
filename of preprint.tar.lzma. The specific situation is that I was
LaTeXing a file that used "fullpage" for the first time.
Ulrike Fischer
> Backhanded good news. The MiKTeX Package Manager had no trouble
> downloading and installing preprint.tar.lzma. But when MiKTeX was
> trying to obtain "preprint" on the fly, it looked for preprint.cab,
> which doesn't exist. I actually don't know if there would have been a
> problem downloading anything else.
>
> Looks like the problem is that MiKTeX is misinformed about the
> filename of preprint.tar.lzma.
That can happen when a package is updated and gets another format.
Synchronize the repository in such case (package-manager->menu
repositories).
--
Ulrike Fischer
Robin Fairbairns
i suspect not. i would guess that on-the-fly assumes you have an
up-to-date database; downloading the package by hand would refresh the
database.
(preprint has been updated recently; this wasn't announced since it
was merely a licence change to allow it to appear in tex live.)
--
Robin Fairbairns, Cambridge
Robert Heller
It looks like the repository 'metadata' is wrong, that is, MiKTeX idea
of the repository is incorrect. Either the hard-coded (?) data is
out-of-date or the meta-data MiKTeX is fetching is out-of-date or
something like that.
mcovington
Thanks! That sounds like the right solution and I will do it, and
also let our support people know, so that all the other users hear
about it.
Is there an easy way to do the synchronize from the command line, so
we could put it in a script on our install disk?
Ulrike Fischer
>> That can happen when a package is updated and gets another format.
>> Synchronize the repository in such case (package-manager->menu
>> repositories).
> Thanks! That sounds like the right solution and I will do it, and
> also let our support people know, so that all the other users hear
> about it.
> Is there an easy way to do the synchronize from the command line, so
> we could put it in a script on our install disk?
Miktex->manual->reference of mpm.
--
Ulrike Fischer
Josef Kleber
> Is there an easy way to do the synchronize from the command line, so
> we could put it in a script on our install disk?
mpm --help and --update-db in special
Josef
--
Keine Sicherheit ohne Sch�uble:
GNUPG/PGP-Key unter http://www.josef-kleber.de/pgp/Josef_Kleber_News.asc
DSA 1024 / 0xF4B1EA2A / F832 6058 319E FFD4 0EFF 088C 521B 40D4 F4B1 EA2A
mcovington
Tom P.
> > we could put it in a script on our install disk?
>
> mpm --help and --update-db in special
I've been struggling with this, too, around the time this thread got
going. I just came back to it today and saw the thread had more
info. Alas, I get similar results with this path as well... Vista64,
tons of memory, tons of disk.
[14:29] c:\Program Files (x86)\MiKTeX 2.8\miktex\bin
> mpm --update-db
mpm: LZMA decoder error.
mpm: Data: hr=1
When in the Package Manager UI, Repository->Synchronize returns the
same information inside a window titled "MiKTeX Problem Report". This
window also comes up if I try to update or install any package in the
UI. (I was trying to get dblatex installed, so my specific need at
present was to follow the step:
Installing MiKTeX
Install the minimal distribution, and add the following packages:
changebar,
colortbl, fancybox, fancyhdr, fancyvrb, listings, overpics,
rotating, subfigure,
titlesec, bibtopic, enumitem, eepic, lm, lastpage, helvetic,
times, symbol, courier.
I've tried installing a number of the listed packages and I get the
same error.
It's a bummer, because I've used pdflatex for a long time at home and
was thinking it'd be great to start using it at work for document
generation but it seems a non-starter at this time. I wish I knew
where to start looking for a solution, but unfortunately I suspect
that building MiKTeX myself is not straight forward and I also suspect
that the corporate overlords would just have us use Distiller to get
the current needs covered.
Anyway- thanks for all of the suggestions. Unfortunately it just
doesn't seem to work. I even tried 2.6 and I think I got the same
problem. It /could/ be a firewall problem, I know for example that
our firewall doesn't let bz2 files through for some reason, but the
error message is unhelpful on that topic to say the least.
I also tried this package on a 32-bit WinXP virtual machine, hosted on
aforementioned Vista box, but it crashed during the installation. The
error message box that was behind the "fatal error" box disappeared so
I didn't get a chance to see it, but I thought I'd move on to the net
installer. This is the log:
MiKTeX Setup 2.8.3553 Report
Date: Tuesday, December 08, 2009
Time: 15:04:48
OS version: Microsoft Windows XP Professional Service Pack 3 (build
2600)
SystemAdmin: yes
PowerUser: false
Setup path: C:\Documents and Settings\tom\My Documents\Downloads
\setup-2.8.3553.exe
starting download...
repository: http://ctan.binkerton.com/systems/win32/miktex/tm/packages/
download directory: "C:\Documents and Settings\tom\My Documents
\Downloads\MiKTeX"
visiting repository http://ctan.binkerton.com/systems/win32/miktex/tm/packages/...
repository type: remote package repository
loading lightweight database...
downloading http://ctan.binkerton.com/systems/win32/miktex/tm/packages/miktex-zzdb1-2.8.tar.lzma...
2813 bytes, 5.96 KB/Sec
An error occurred:
source file: Libraries\MiKTeX\Core\LzmaStream.cpp
source line: 299
message: LZMA decoder error.
info: hr=-2147024882;props=60-33-68-79-67
<<<Cancel? Yes!>>>
Robin Fairbairns
>> > Is there an easy way to do the synchronize from the command line, so
>> > we could put it in a script on our install disk?
>>
>> mpm --help and --update-db in special
>
>I've been struggling with this, too, around the time this thread got
>going. I just came back to it today and saw the thread had more
>info. Alas, I get similar results with this path as well... Vista64,
>tons of memory, tons of disk.
>
>[14:29] c:\Program Files (x86)\MiKTeX 2.8\miktex\bin
>> mpm --update-db
>mpm: LZMA decoder error.
>mpm: Data: hr=1
at a wild guess i would suggest deleteing miktex-zzdb1-2.8.tar.lzma
(and ...zzdb2...) and telling it to have another go.
at worst it will re-download them, but it may be that one of them is
the corrupt object.
--
Robin Fairbairns, Cambridge
