Only replace LED state of a single LED instead of removing the entire
/var/run/led.state file.
Fixes: 511e8f84d0 ("base-files: configure LED when added")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Currently LED configuration is only carried out once during boot.
Apply LED configuration also with a hotplug call when a new LED gets
added later.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Make it clear to users that they should not place a custom file
in /etc/sysctl.d/ for their values and expect it to survive a
reimage.
This change is needed since these directories (/etc/foo.d/) are
generally where such files are placed on other distros.
Signed-off-by: John Audia <therealgraysky@proton.me>
Link: https://github.com/openwrt/openwrt/pull/16543
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Old "interface" sections for bridges were mixing layer 2 and layer 3.
That syntax got deprecated and UCI section "device" is used for bridge
configuration now.
Backward compatibility may be dropped from netifd soon now so migrate
old configs using uci-defaults script.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
netifd supports more accurate "ports" option (instead of "ifname") for
years now. Relevant changes were even backported to OpenWrt 21.02. Add
uci-defaults script that translates config files using deprecated
syntax.
Identical commit f716c30241 ended up reverted back in 2021 by
80be798d4a due to breaking downgrades. With 19.07 support ended it
should no longer be an issue.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
For APK installation we don't have /usr/lib/opkg/info and user fixup are
handled dirrectly. Skip the script in such case.
Also remove this uci-defaults if we have CONFIG_USE_APK enabled.
Link: https://github.com/openwrt/openwrt/pull/15543
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reduce calls and pipes and read from urandom once directly with hexdump
for the necessary 5 bytes of random data to build the 48 bit ULA Prefix.
Fewer calls and forks; finish quicker; less memory used.
Tested on: 23.05.3
Signed-off-by: Paul Donald <newtwen+github@gmail.com>
Add the possibility that colored LEDs can also be configured via the uci.
config led 'led1'
option name '<name>'
option sysfs '<path>'
option trigger 'default-on'
option default '1'
--> option color_{$color} '<0-255>'
The supported names of the variable "${color}" for the selected LED can be
queried in the file with the name 'multi_index'.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Setting the trigger and checking whether the trigger can be set belong
together and should not be interrupted by other lines of code.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
There are monochrome LEDs that can only display one color. However, there
are also LEDs that can display multiple colors. This can be tested in the
led subsystem of the kernel if the files 'multi_index' and 'multi_intensity'
are present in the folder '/sys/class/leds/<ledname>'.
Until now it was not possible to reset the default color. This commit adds
the missing information in the file '/var/run/led.state' so that the bootup
color can be seen on the LED again when the LED configuration has been changed.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
The duplicate sections are caused by a race condition at boot, when board.json
is not available. In that case, the final phy name cannot be resolved, and extra
sections referring to the path are created.
Fix this by making sure that wifi config is not being run before board.json
is created.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Set net.core.bpf_jit_kallsyms=1 in /etc/sysctl.d/10-default.conf.
For privileged users, this exports addresses of JIT-compiled programs to
appear in /proc/kallsyms when present, allowing their use for debugging
and in traces.
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
On some devices the chip has RTC but no battery save time.
This leads back to getting the wrong time
and skipping the check of the last file modification date.
This commit ensures that the file time is checked even
if the RTC exists.
which would ordinarily return an approbiate
system time used for e.g. certificate generation.
Tested-on: NanoPi R2S
Signed-off-by: Yuan Tao <ty@wevs.org>
The heartbeat trigger has the option to be inverted, however
openwrt/uci/luci have no way to set this.
This patch adds this support.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
A service managed by procd does have a json object with usefull information.
This information could by dumped with the following command.
ubus call service list "{ 'verbose':true, 'name': '<service-name>)'". }"
This line is long and complicated to enter. This commit adds a wrapper
call to the procd service section tool to simplify the input and get the
output faster.
We could now enter the command /etc/initd/<service> info to get the info
faster.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
The service command belongs to the procd and does not belong in the
shinit. In the course of the move, the script was also checked with
shellcheck and cleaned up.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
OpenWrt uses a lot of (b)ash scripts for initial setup. This isn't the
best solution as they almost never consider syncing files / data. Still
this is what we have and we need to try living with it.
Without proper syncing OpenWrt can easily get into an inconsistent state
on power cut. It's because:
1. Actual (flash) inode and data writes are not synchronized
2. Data writeback can take up to 30 seconds (dirty_expire_centisecs)
3. ubifs adds extra 5 seconds (dirty_writeback_centisecs) "delay"
Some possible cases (examples) for new files:
1. Power cut during 5 seconds after write() can result in all data loss
2. Power cut happening between 5 and 35 seconds after write() can result
in empty file (inode flushed after 5 seconds, data flush queued)
Above affects e.g. uci-defaults. After executing some migration script
it may get deleted (whited out) without generated data getting actually
written. Power cut will result in missing data and deleted file.
There are three ways of dealing with that:
1. Rewriting all user-space init to proper C with syncs
2. Trying bash hacks (like creating tmp files & moving them)
3. Adding sync and hoping for no power cut during critical section
This change introduces the last solution that is the simplest. It
reduces time during which things may go wrong from ~35 seconds to
probably less than a second. Of course it applies only to IO operations
performed before /etc/init.d/boot . It's probably the stage when the
most new files get created.
All later changes are usually done using smarter C apps (e.g. busybox or
uci) that creates tmp files and uses rename() that is expected to be
atomic.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Acked-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>
In the default shadow file, as visible in the failsafe mode, the user
root has value of `0` set in the 3rd field, the date of last password
change. This setting means that the password needs to be changed the
next time the user will log in the system. `dropbear` server is ignoring
this setting but `openssh-server` tries to enforce it and fails in the
failsafe mode because the rootfs is R/O.
Disable the password aging feature for user root by setting the 3rd
filed empty.
Signed-off-by: Rucke Teg <rucketeg@protonmail.com>
fgrep is deprecated and replaced by grep -F. The latter is used
throughout the tree whereas this is the only usage of the former.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
The following command checks if a instance of a service is running.
/etc/init.d/<service> running <instance>
In the variable `$@`, which is passed to the function
`service_running`, the first argument is always the `instance` which
should be checked. Because all other variables where removed from `$@`
with `shift`.
Before this change the first argument of `$@` was set to the `$service`
Variable. So the function does not work as expected. The `$service`
variable was always the instance which should be checked. This is not
what we want.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
Reviewed-by: Sungbo Eo <mans0n@gorani.run>
Per FHS 3.0, /var/lock is the location for lock files [1].
However its current permissions (755) are too restrictive
for use by unprivileged processes.
Debian and Ubuntu set them to 1777, and now so do we.
[1] <https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varlockLockFiles>
Signed-off-by: Deomid Ryabkov <rojer@rojer.me>
[fixed typo in commit message, had to remove "rojer" due to git hooks]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The zoneinfo packages are not installed per default so neither
/tmp/localtime nor /tmp/TZ is generated.
This patch mostly reverts the previous fix and instead incooperates a
solution suggested by Jo.
Fixes "base-files: fix zoneinfo support " 8af62ed
Signed-off-by: Paul Spooren <mail@aparcar.org>
The system init script currently sets /tmp/localinfo when zoneinfo is
populated. However, zoneinfo has spaces in it whereas the actual files
have _ instead of spaces. This made the if condition never return true.
Example failure when removing the if condition:
/tmp/localtime -> /usr/share/zoneinfo/America/Los Angeles
This file does not exist. America/Los_Angeles does.
Ran through shfmt -w -ci -bn -sr -s
Signed-off-by: Rosen Penev <rosenp@gmail.com>
There are services that have only STOP value set. They are executed only
on shutdown and it is common to use them for system cleanup. There is
one such service shipped directly with base-files, it is 'umount'. Those
work the same way as those with START but enabled does not report them
as enabled although it should have as they can be enabled and disabled
as any other service.
This also changes check from check for executable to check for symbolic
link. The implementation depends on those being links to service file
and it is much cleaner and direct to check for them being links.
Signed-off-by: Karel Kočí <karel.koci@nic.cz>
This reverts commit f716c30241.
Migrating everyone to the new syntax could break downgrades. We may
reintroduce it way later if needed.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
