System-boot/config.txt from RPI 3 on ubuntu core 18 gets overwritten

I try to set custom HDMI resolution for my RPI3 in system-boot/config.txt like so:

# uncomment to force a specific HDMI mode (here we are forcing 800x480!)
hdmi_cvt=800 480 60 6 0 0 0

But after a reboot i find them like this:

# uncomment to force a specific HDMI mode (here we are forcing 800x480!)
hdmi_cvt=800 480 60 6 0 0 0

First the system loads the new config, the HDMI has the new 800x480 resolution, but after a later reboot, the config.txt auto comments those lines.
Any ideea why?

i would not expect snapd (or any other part of a core18 install) to touch config.txt unless you are using any of the system config option defaults in your gadget.yaml like:

do you happen to use any of there ?
(beyond this, you perhaps should use them and ask for additional integration of hdmi_cvt)

I have set the hdmi-* options as you said with

snap set system ...

The hdmi_cvt remained uncommented in config.txt.

It seems it worked.

1 Like

Here’s a PR to snapd which will let you do snap set system pi-config.hdmi_cvt="...":


I’m trying to configure the HDMI mode as well. I am running core20 on a RPI4.
I made sure to include @ijohnson 's PR (snap refresh snapd --edge), and I’m now running snapd 2.49.2+git1051.ge408012.
What worked was using the dash hdmi-cvt and not the underscore hdmi_cvt
snap set system pi-config.hdmi-cvt="1024 600 60 6 0 0 0"

However, I haven’t had success in confirming if any of these HDMI changes are being applied (the screen looks the same with and without). I can confirm my values are being set by seeing them listed with snap get system pi-config.

The obvious visual confirmation if the modes are being applied is a 90 Deg rotation (pi-config.display-rotate=1), which I do not see.

Furthermore, I don’t know where to find the config.txt file, can someone let me know the full path to the file? By looking around I found /writable/system-data/var/lib/snapd/seed/config.txt, but from what I understand I should not make changes in this file in Core20 (as it gets re-created at boot?).

in UC20 it moved to /run/mnt/ubuntu-seed/

Ah if you are running on UC20, you are running into, which will be fixed with

Thanks for the fast response. I’ll keep an eye out for when that PR gets merged. In the meantime I’m trying out the manual editing of /run/mnt/ubuntu-seed/config.txt, I think I’m seeing some screen changes (the resolution seems different), but the rotation is not happening—It’s staying in portrait.

Just to make sure here, I’m looking at the UbuntuCore welcome text “The host key fingerprints are… To login ssh …” to confirm if the rotation’s being applied. I am assuming this text will be rotated.

Are there logs I can look for to see if the options from config.txt are being ignored/ if the options are failing and it’s rolling back?

the rotation might not work if the fkms overlay is active …
(just guessing though)

1 Like

That was spot-on, thanks!
In case someone else encounters this, comment-out vc4-fkms-v3d and replace with vc4-kms-v3d (I also removed the cma-128) from /run/mnt/ubuntu-seed/config.txt:


If the pi-gadget updates itself, will the update overwrite config.txt? I am asking because it looks like the fkms fix only works by editing config.txt since it affects the dtparam/ dtoverlay parameters, and I can’t find any integration of pi-config system options for these options (besides maybe making my own gadget, I wouldn’t know how to reliably change them).

Would it be considered bad practice to directly edit the config.txt file as I see fit (and just skip using the snap set system ... method)?

If you edit values in config.txt which are simultaneously set with snap set system, then upon the next snap refresh or the next snap set (even for an unrelated system config, not necessarily something pi related), you could have you manual changes undone or overwritten by the ones that are saved in snapd. You are best off having no config set for pi-config on the system if you wish to manually control config.txt entirely.

Regarding if a gadget asset update would overwrite the config.txt, it is technically possible via gadget asset updates, but these must be manually opted into by the gadget snap maintainer when they update the gadget by adding specific values to the gadget.yaml referencing which files should be updated. By default just changing the assets themselves (like the DTBs, overlays, config.txt etc.) and rebuilding and uploading a new revision of the gadget snap will not update the files on existing installations.

Additionally, it is highly unlikely that Canonical’s gadget snap maintainers would ever actually deliver a gadget asset update to the config.txt even if technically possible, specifically because of the issue with it being modifiable via snap config settings, and so it would have to be done very carefully and probably require changes in snapd so that if the config.txt was updated by a gadget asset update, then snapd would automatically re-apply the config on top of the config.txt before rebooting to apply the effects of the gadget asset update. The complexity here means we are extremely unlikely to do this except perhaps in the most dire of cases like where not doing so means bricked devices or critical security vulnerabilities which would be very surprising to see happen at the level of config.txt.