Bug 1651282 - Latex fails to run because of missing latex.fmt file
Summary: Latex fails to run because of missing latex.fmt file
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: texlive (Show other bugs)
(Show other bugs)
Version: 29
Hardware: x86_64 Linux
unspecified
medium
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-19 15:32 UTC by Frank Ansari
Modified: 2018-12-07 17:52 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-12-06 20:44:27 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
installed tex packages (10.01 KB, text/plain)
2018-11-26 18:05 UTC, Frank Ansari
no flags Details

Description Frank Ansari 2018-11-19 15:32:21 UTC
Description of problem:
Latex fails to run. It complains about some missing latex.fmt file.

[fansari@bat briefe]$ latex gvd3.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded format=latex)
 restricted \write18 enabled.

kpathsea: Running mktexfmt latex.fmt
mktexfmt: mktexfmt is using the following fmtutil.cnf files (in precedence order):
mktexfmt: mktexfmt is using the following fmtutil.cnf file for writing changes:
mktexfmt:   /home/fansari/.texlive2018/texmf-config/web2c/fmtutil.cnf
mktexfmt [INFO]: writing formats under /var/home/fansari/.texlive2018/texmf-var/web2c
mktexfmt [INFO]: did not find entry for byfmt=latex, skipped
mktexfmt [INFO]: Total formats: 0
mktexfmt [INFO]: exiting with status 0
I can't find the format file `latex.fmt'!

Same issue running this:

[fansari@bat briefe]$ fmtutil-user --byfmt latex
fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /home/fansari/.texlive2018/texmf-config/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/home/fansari/.texlive2018/texmf-var/web2c
fmtutil [INFO]: did not find entry for byfmt=latex, skipped
fmtutil [INFO]: Total formats: 0
fmtutil [INFO]: exiting with status 0


Version-Release number of selected component (if applicable):
texlive-latex-20180414-27.fc29.noarch
texlive-tetex-20180414-27.fc29.noarch


How reproducible:
Try to compile a latex file.

Steps to Reproduce:
1.
2.
3.

Actual results:
Compilation fails.

Expected results:
Compilation should work.

Additional info:
Fedora 29 Silverblue

Comment 1 Tom "spot" Callaway 2018-11-26 17:34:46 UTC
I do not have a Silverblue setup, but I cannot reproduce this on stock Fedora 29. Can you try removing your cache (~/.texlive2018) and trying again?

Comment 2 Frank Ansari 2018-11-26 18:05:17 UTC
I have tried this before and again now but it gives the same error.

This is a fresh Silverblue installation. Maybe something is different on Silverblue or I miss some package.

Unfortunatly I have no idea how to create this missing latex.fmt file

I add a list of installed packages.

Comment 3 Frank Ansari 2018-11-26 18:05 UTC
Created attachment 1508627 [details]
installed tex packages

Comment 4 Tom "spot" Callaway 2018-11-26 18:26:01 UTC
Huh, my best guess is that something in the read-only nature of Silverblue/ostree is clashing with texlive's desire to write/manipulate itself. You have texlive-kpathsea installed, but your logs do not show any attempt to read /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf.

I'm downloading Fedora 29 Silverblue ISO now, to see if I can figure anything out from a VM.

Comment 5 Frank Ansari 2018-12-04 07:37:18 UTC
I could identify the problem.

I had to run "sudo texconfig rehash".

But this tries to write to /usr/share/texlive - so this fails.

I could force it to work doing "sudo mount -o remount,rw /usr".

But I guess the changes it does in /usr/share/texlive will only remain until the next os-tree commit.

But the latex.fmt file was now written to my homedir - so at least this will stay.

So my conclusion is that the way texlive works does is not usable with Silverblue.

Comment 6 Frank Ansari 2018-12-04 07:48:54 UTC
[fansari@bat pdftex]$ sudo texconfig rehash
mktexlsr: /usr/share/texlive/texmf-config: directory not writable. Skipping…
mktexlsr: /usr/share/texlive/texmf-dist: directory not writable. Skipping…
mktexlsr: /usr/share/texlive/texmf-local//: directory not writable. Skipping…
mktexlsr: /usr/share/texlive/texmf-var: directory not writable. Skipping…
mktexlsr: Done.

Comment 7 Frank Ansari 2018-12-04 08:07:19 UTC
On approach could be like this:

/etc/texlive/web2c/mktex.cnf

Here I can set:
TEXMFROOT = /usr/local/texlive

But this means I have to put all the content of /usr/share/texlive there.

When I do this: how is this maintainable for updates?

So this seems to be only a temporary fix.

Comment 8 Colin Walters 2018-12-05 15:53:08 UTC
I would install texconfig in a container personally, not on the host.  You might want to try out https://github.com/debarshiray/fedora-toolbox/

One thing isn't clear to me - are you installing 3rd party texlive "packages"?
Is this like dropping a 3rd-party libfoo.so in /usr/lib64 and then needing to run `ldconfig`?

Comment 9 Frank Ansari 2018-12-05 16:54:08 UTC
I tried to setup a container and installed texlive there and it is working. But this is not the behaviour I am used to and what I have expected.

What do you mean "3rd-party" packages?

I just did "rpm-ostree install texlive".

I guess the problem is that not all software packages assume that /usr is a read-only mount.

Comment 10 Tom "spot" Callaway 2018-12-06 20:44:27 UTC
Given that texlive is hardwired in a number of places to assume /usr is read-write, I think I have to close this CANTFIX.

Comment 11 Colin Walters 2018-12-06 23:15:20 UTC
Tom, one thing I want to emphasize: `/usr` is mounted read-write while e.g. RPM %post scripts are running.

For example, it works to install a 3rd party RPM that drops /usr/lib64/libfoo.so have its `%post` run `ldconfig` etc.

(Just like how all the existing RPM %post in RPMs we ship work)

However, some scripts and filesystem layout may need adjustment; see https://bugzilla.redhat.com/show_bug.cgi?id=1352154

Comment 12 Tom "spot" Callaway 2018-12-07 16:41:26 UTC
(In reply to Colin Walters from comment #11)
> Tom, one thing I want to emphasize: `/usr` is mounted read-write while e.g.
> RPM %post scripts are running.
> 
> For example, it works to install a 3rd party RPM that drops
> /usr/lib64/libfoo.so have its `%post` run `ldconfig` etc.
> 
> (Just like how all the existing RPM %post in RPMs we ship work)
> 
> However, some scripts and filesystem layout may need adjustment; see
> https://bugzilla.redhat.com/show_bug.cgi?id=1352154

Thanks for the clarification. The issue here is that texlive, in the course of normal operation (not just scriptlets) is making writes under /usr/share/texlive (TEXMFROOT). I'm sure it is possible to setup texlive to have its root in a Silverblue friendly space, but it would:

A) Be really hard
B) Be a massive difference from what other Linux distros do
C) Probably break lots of corner cases in texlive that would not be noticed for YEARS

Comment 13 Colin Walters 2018-12-07 17:52:16 UTC
Ah, OK.  Yep, sounds like stuff that should go in `/var`.  But I'd believe you that it's hard.

Bigger picture though again texlive is something I'd install in a container, not the host; this is part of the whole idea is that any where you read instructions to "yum install xyz" you generally think "is this something that *really* needs to be on my host" -> rpm-ostree, otherwise do it in a container.

The fact that `yum` works basically the same as it always has in a container is for exactly these types of reasons.


Note You need to log in before you can comment on or make changes to this bug.