In a public-key infrastructure, there are two ways a public key can be trusted: either because it's signed by a certificate authority that you trust, or because you already have it in a list of trusted public keys. That's where the chain of signatures ends: in a list of pre-trusted public keys.
These pre-trusted public keys are usually called “root CAs” or “trust store”. They come with the operating system, with the application, or in a configuration.
Sometimes the OS/application/configuration might have its own special-purpose set of root CAs which are obtained via a different PKI provided by the operating system where the OS/application/configuration is installed. This might not be the same system where the application that relies on the PKI will run. For example, if you download firmware for an embedded device on your PC, then the PKI that your browser uses guarantees the authenticity of the firmware image. You trust the root CAs for PKI on the embedded device because they came as part of that firmware image that you trust.
But ultimately, it comes down to a public key that you trust, not because it has a digital signature made by a certificate authority, but because you obtained it from someone you trust by means that you trust. Usually it's the same entity that also provides the code that performs signature verification, and you have to trust that anyway: if the code to verify signatures might accept invalid signatures then it doesn't matter who didn't actually make these signatures. And often it's the same entity that also provides the hardware, and again if the hardware isn't executing the signature verification correctly then it doesn't matter whether the code and data are good.
For example, if you buy a computer with an operating system preinstalled that includes a web browser with HTTPS support, the reason you trust it to verify keys has nothing to do with cryptography. Cryptography is how that browser verifies the authenticity of connections, not why you trust it to do so.
That's in fact a general thing with cryptography: cryptography doesn't actually create security properties from scratch. Cryptography is a mathematical means to extend security properties to cover more ground. For example, encryption alone can't make data confidential: all encryption does is to extend the confidentiality of the key into the confidentiality of the data. A digital signature extends the confidentiality of the private key into the authenticity of the data. Likewise, a hash doesn't guarantee the integrity of data of its own, but extends the integrity of the hash into the integrity of the data. At the root, there has to be some non-cryptographic means of securing the key or hash.
I didn't find a duplicate question on this site, but this has been covered several times on Security Stack Exchange, in particular: