Emacs in Raspberry Pi OS has unexpected behavior with custom-set-faces

I am trying to set up Emacs to work on a Raspberry Pi 4 with Raspberry Pi OS installed, Raspbian GNU/Linux 10 (buster). I am running GNU Emacs 26.1 (build 2, arm-unknown-linux-gnueabihf, GTK+ Version 3.24.5) of 2021-02-06, modified by Debian. This appears to be the most recent version built. I have set the "Default Font" using the interactive menus and by editing the .emacs file directly. In either case what I think are the appropriate values are saved in .emacs but when I start the GUI version of Emacs, it opens with a small font, gets momentarily larger as I've specified in my .emacs file, but only for a split second. Then it changes again to a small font. I have reduced the .emacs file to contain only the custom-set-faces function, and still see this behavior. I have no idea what is causing this to happen. I am using the same function in an Emacs install on Windows 10, and on the current release of MacOS successfully, both have a more recent version of Emacs however. Here is what was in the minimum .emacs file that caused the undesired behavior: (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(default ((t (:family "DejaVu Sans Mono" :foundry "PfEd" :slant normal :weight normal :height 241 :width normal))))) Any suggestions of what to look into? I have googled every way of phrasing it I can think of, and haven't succeeded in finding anyone talking about this.

What's the value of `custom-file`? Is it a different file with different faces set in it?

[deleted]

custom-file is set to nil

Same question, but `user-init-file` instead of `custom-file`.

user-init-file is set to the .eMacs file in my directory which is the file I’ve been editing. Thanks for the suggestions, but I’m still stumped.

There are likely multiple calls to `custom-set-faces` in your init files. Poke around in them, or perhaps you can put a `debug-on-entry` call near the beginning of your init and that'll help you find the second place.