Security implication of deriving key with fixed salt for files authentication Context: 
I need to calculate MAC for a collection of files just for future integrity and authentication verification. 

This is the conceptual order of steps:


Derive a 64 bytes key from user input password, using PBKDF2 (with sha512) with 10k iterations and fixed salt.
Then, use this derived key to calculate the MAC using HMAC+BLAKE2b(512) and store the output for possible future verification.


PBKDF2 is used instead of HKDF because I can't ensure that the input will have enough entropy.

The key derivation step happens once (on app initialization) and later used multiple times to calculate MAC of arbitrary number of files. Generating an random IV is not possible because I don't want (as far as possible) generate a derived key for every file. Having duplicated MAC digests for duplicated files it is not an issue.

Question: For that purpose, are there some security implications having that salt as a fixed byte string?

Answer: As @SEJPM pointed me, the general security model of MAC algorithms assumes that the keys will be reused for calculate arbitrary number of MAC's, so this scheme should be secure.
For that purpose, are there some security implications having that
  salt as a fixed byte string?


The key re-use is fine here, because the standard model for MACs allows the attacker to request an arbitrary (polynomially bounded) amount of authenticated messages while still not being able to forge new MACs.

As a bonus, you may want to consider using the built-in MAC mode for Blake2, because it reduces code complexity and improves speed while providing a comparable security level (thanks to Richie here)