I’ve added most common formats to this topic: Timer string format
I was trying to set the refresh timer to 1st Wednesday of the month at 13:00 and used the convention wed1,13:00
. I was expecting the next refresh timer to be set to 1st August which is two days from today (30th of July 2018) but it is set to Wednesday of the second week of August . Is this a bug or am I doing something wrong ?
Here is my commands
$ sudo snap set system refresh.timer=wed1,13:00
$ sudo snap get system refresh.timer
wed1,13:00
$ sudo snap refresh --time
timer: wed1,13:00
last: 11 days ago, at 12:33 IST
next: in 9 days, at 13:00 IST
Thanks for reporting this. This looks like a bug in calculating the time, I’ll look into it.
Edit: The fix is waiting for review atm.
Using the latest Edge image for Core, setting pi-config.display-rotate=1
(or manually editing /boot/uboot/config.txt) results in a dysfunctional system. According to the official documentation for config.txt video options, display_rotate
is deprecated and one should use display_hdmi_rotate
or display_lcd_rotate
. Setting either manually in /boot/uboot/config.txt
seems to have no effect.
Do I need to change any of the HDMI-related parameters as well, or is this a known issue in Edge? When I use Core stable, using the snap configuration hook for display_rotate
works as expected.
(ping @ogra for Pi-related things IIRC )
AFAIK the rotate options only apply to the raw framebuffer that the Pi firmware initalizes.
we default to use the kms/drm framebuffer driver in our pi gadgets though, can you try commenting dtoverlay=vc4-kms-v3d
in config.txt and see if the rotation options work then …
if this fixes it, we probably need to make sure the snapd code disables the overlay (at the cost of any accelerated graphics support) in case one of these rotate options gets set.
Will try out disabling the overlay as you suggested, but I’d be happy to use other methods if they preserve accelerated graphics support. Do you happen to have a solution for display rotation with kms/drm, preferably one that can be changed without a reboot?
Is there a preferred mechanism to unset a configuration item?
Let’s say that I want to set a proxy:
$ sudo snap set system proxy.https="localhost:9000"
And later on, I wish to remove that proxy by setting the key to an empty string:
$ sudo snap set system proxy.https=""
That item now still appears within the config:
$ sudo snap get system proxy.https
Key Value
proxy.https
Is it possible to delete the key?
refresh.hold
is not documented.
The timer string format link isn’t getting rendered properly, though I can’t see why. When it’s converted to HTML, it’s generated as an anchor tag with no href
property.
Oh, I see the problem. The URL is missing a /
at the beginning.
With sudo snap unset system proxy.https
?
There’s a new option to set the console log level.
system.kernel.printk.console-loglevel
Override the console log level which is a number between 0 and 7.
The configuration will be stored in /etc/sysctl.d/99-snapd.conf
and the default value is 4
Available since snapd 2.46.
Example to set the log level to 1:
$ snap set system system.kernel.printk.console-loglevel=1
$ cat /etc/sysctl.d/99-snapd.conf
kernel.printk = 1 4 1 7
Thanks so much for letting us know, and for the written description. I’ve updated the doc with your details.
Right after the “snap get system” example in the first section, I would add the variation of “snap get -d system”.
ping @degville: option swap.size
seems to be undocumented Relevant forum post: Snap refresh after system time is corrected - #5 by ijohnson
Excellent! Thanks for letting me know. Doc is now updated and I’ll copy this across to the Ubuntu Core docs too.
The link changed to here: https://www.raspberrypi.com/documentation/computers/config_txt.html
Thanks so much for letting us know, and for including the new link!
I think it’s worth mentioning that “snap get system” and “snap get core” are synonymous – I filed a bug for that:
Another note – while the “experimental” system option still exists, it’s moved on considerably from the example(s) presented on this page.
Not sure if those links are accurate or complete, it would be nice to have a list of what are still considered “experimental” system config options.