(kali) Pdf report is empty while other format (cvs, xml) are ok


I have greenbone installed on Kaili, it was working fine till I did upgrade and dist-upgrade. I started getting empty pdf reports while other formats are Ok, below is my gvm-check-setup:

gvm-check-setup 21.4.3
Test completeness and readiness of GVM-21.4.3
Step 1: Checking OpenVAS (Scanner)…
OK: OpenVAS Scanner is present in version 21.4.4.
OK: Server CA Certificate is present as /var/lib/gvm/CA/servercert.pem.
Checking permissions of /var/lib/openvas/gnupg/*
OK: _gvm owns all files in /var/lib/openvas/gnupg
OK: redis-server is present.
OK: scanner (db_address setting) is configured properly using the redis-server socket: /var/run/redis-openvas/redis-server.sock
OK: redis-server is running and listening on socket: /var/run/redis-openvas/redis-server.sock.
OK: redis-server configuration is OK and redis-server is running.
OK: _gvm owns all files in /var/lib/openvas/plugins
OK: NVT collection in /var/lib/openvas/plugins contains 101963 NVTs.
Checking that the obsolete redis database has been removed
OK: No old Redis DB
OK: ospd-OpenVAS is present in version 21.4.4.
Step 2: Checking GVMD Manager …
OK: GVM Manager (gvmd) is present in version 21.4.5.
Step 3: Checking Certificates …
OK: GVM client certificate is valid and present as /var/lib/gvm/CA/clientcert.pem.
OK: Your GVM certificate infrastructure passed validation.
Step 4: Checking data …
OK: SCAP data found in /var/lib/gvm/scap-data.
OK: CERT data found in /var/lib/gvm/cert-data.
Step 5: Checking Postgresql DB and user …
OK: Postgresql version and default port are OK.
gvmd | _gvm | UTF8 | en_US.UTF-8 | en_US.UTF-8 |
OK: At least one user exists.
Step 6: Checking Greenbone Security Assistant (GSA) …
OK: Greenbone Security Assistant is present in version 21.4.4.
Step 7: Checking if GVM services are up and running …
OK: ospd-openvas service is active.
OK: gvmd service is active.
OK: gsad service is active.
Step 8: Checking few other requirements…
OK: nmap is present in version 21.4.4.
OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
OK: xsltproc found.
WARNING: Your password policy is empty.
SUGGEST: Edit the /etc/gvm/pwpolicy.conf file to set a password policy.

It seems like your GVM-21.4.3 installation is OK.

1 Like

This problem has been thoroughly discussed here:


It is still unclear if this is a bug in some never LaTeX packages published in Kali or some incompatibilities on GVM side with that never versions.

@cfi it’s bug in latex packages.


1 Like

Ah, indeed. But it could be a little bit unclear if this package is still required at all in GVM or if it just could be dropped (a few comments in that issue seems to indicate this).

@cfi I think it’s required or do you mean that generate might work without it?


If i understand Error in pre-release-4 with utf8x and hyperref · Issue #833 · latex3/latex2e · GitHub correctly:

At the time ucs/utf8x were written the core inputenc files were very conservative in the characters they support, however by now most accented latin letters are supported by default and utf8 support is preloaded in the format, so in most cases simply not loading uf8x will solve the issue.

it might be possible that the affected package is not required anymore nowadays. That’s what i have tried to point out above.

@cfi ok. Please test, if its not required anymore.


Unfortunately i’m not able to do any testing for this as i neither have the knowledge, capabilities or setup to do this.

This would be probably needs to be done by either the team working on GVM or by some one from the community.

@cfi OK. I might be able to test it.


1 Like

@cfi well. my testing shows that removing this line


from file: /var/lib/gvm/gvmd/report_formats/d45f0655-c486-4312-ad85-8b6fbe6f5b45/c402cc3e-b531-11e1-9163-406186ea4fc5/latex.xsl

does not affect on pdf generation and it works fine.

can you verify on your installation?


Tested same modification on Debian also and looks like it works fine also.

@DeeAnn can some on at greenbone verify this fix and apply it sourcecode?

@y0urself ?


I thought this issue has been addressed with https://github.com/greenbone/report-formats/pull/31

Will create an internal issue for this.

1 Like


1 Like

@y0urself can you open a bit content of this issue. it looks like non public?


I also encountered the empty pdf report issues. I have 22.4.0~dev1 installed on a Ubuntu 22.04.1 LTS. All components (including latex) were verified to be installed properly but pdf reports were always empty. I had NIS (ypbind) installed on the machine. Once I removed NIS, everything worked like a charm. This might not be what my friends are experiencing but its something to check for and mention in the installation document that NIS and GVM do not play well.

@SKhatry this really can’t be related to NIS, unless it uses some latex packages.


So, no solution in sight yet?

There are a few options for a solution:

  1. According to / if i understand the last part of the comment Error in pre-release-4 with utf8x and hyperref · Issue #833 · latex3/latex2e · GitHub correctly this seems to be an issue in the utf8x part of the inputenc package. Identifying the issue / bug tracker of that package and creating a sane bug report (with a reference to the previous linked one) could help in getting a fixed version of that LaTeX package into Kali

  2. Monitor 0007957: GVM Report exported in PDF format results to 0 byte document - Kali Linux Bug Tracker to see if the affected LaTeX package is somehow directly patched in Kali

  3. Use the workaround to remove the buggy LaTeX package mentioned in PDF, XML reports are empty on Kali Linux - #4 by Eero

  4. As a last resort (no guarantee for success):

Note: Options 3. and 4. might not work as expected for all cases where the inputenc package is still required. This would need to be tested by some one more thoroughly.

Can confirm that your workarround fixes 0kb PDF reports on my Kali system. Location of latex.xsl is a little differnet though. Found it with “locate”

Any news on a possible solution?
The workaround does not work for me…