Instead of board_detect generating the config as a side effect, let
config_generate call board_detect as needed.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
/etc/init.d/boot tried to create /dev/root based on the kernel's
cmdline which won't work on any recent targets. Remove that code now
that fstools can detect the mounted rootfs based on
/proc/self/mountinfo and /dev/root was long gone anyway.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Network drivers typically allocate memory in atomic context. For that to
be reliable, there needs to be enough free memory. Set the value
heuristically based on the total amount of system RAM.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Previous implementation was blocking the init and
breaking halt/reboot/sysupgrade (reported by Daniel Golle)
v2: use procd logging, use set -e + trap for error handling
Signed-off-by: Etienne CHAMPETIER <champetier.etienne@gmail.com>
Tested-by: Daniel Golle <daniel@makrotopia.org>
This commit:
1) seed /dev/urandom with the saved seeds as early as possible
(see /lib/preinit/81_urandom_seed)
2) save a seed at /etc/urandom.seed if it doesn't exists
3) save a new seed each boot at "system.@system[0].urandom_seed"
(see /etc/init.d/urandom_seed)
We use getrandom() so we are sure /dev/urandom pool is initialized
Seed size is 512 bytes (ie /proc/sys/kernel/random/poolsize / 8)
it's the same size as in ubuntu 14.04 and all systemd systems
Seeding /dev/urandom doesn't change entropy estimation, so we still have
"random: ubus urandom read with 4 bits of entropy available"
messages in the logs, but we can now ignore them if
after "urandom-seed: Seeding with ..." message
Saving a new seed on each boot is disabled by default to avoid too much
writes without user consent
v2: log preinit messages to /dev/kmsg
v3: use non generic function name for logging, as /lib/preinit/ files
are all sourced together in /etc/preinit
v4: after a lot of discussion on the ML, use a uci config param
v5: config param is now the path of the seed
Signed-off-by: Etienne CHAMPETIER <champetier.etienne@gmail.com>
Acked-by: Jo-Philipp Wich <jo@mein.io>
dnsmasq's dnssec time checking method now uses a ntp hotplug mechanism,
therefore dnsmasq.time is redudant and no longer needs to be explicitly
excluded from sysfixtime.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
Record the state of any hardware LED configured through UCI and use that
information to revert the state when applying updated settings while
maintaining default behaviour of system LEDs.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Attempt to reset all LED states before applying the UCI configuration to
avoid leaving disabled LEDs behind in lingering glowing state, e.g. when
changing the sysfs entry in the config from one hardware LED to another.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Typo, missing space before ] in previous commit caused shell syntax
failure and incorrect restoration of time.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
This patch adds extra parameter to switch LED trigger initialization
functions. New functionality maintains backward compatibility, so
calling functions without setting new speed_mask parameter works
as expected.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
SVN-Revision: 48776
On systems that have an RTC prefer it to the file-based time fixup (i.e.
use hwclock when there is a permanent clock instead of the faked up time
logic that is needed when there is not RTC).
We can't rely on hctosys kernel feature either as we're usually using
RTC as kernel modules which are usually being loaded after hctosys was
run, leading in the following error:
hctosys: unable to open rtc device (rtc0)
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
SVN-Revision: 48661
LEDs which are controlled by a PWM need to use the supplied
max_brightness instead. Otherwise they might appear to be
very dim / broken.
Signed-off-by: Chris R Blake <chrisrblake93@gmail.com>
SVN-Revision: 47854
FHS mandates presence of /var/tmp on compliant systems.
The lack of /var/tmp was discovered when using MIT Kerberos libraries
which default to that location for storing credentials cache.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
SVN-Revision: 47219
We need a+x rights on the path to the root of the jails
so we can use users other than root (like nobody)
This partly fixes jailed dnsmasq
Signed-off-by: Etienne CHAMPETIER <champetier.etienne@gmail.com>
SVN-Revision: 46466
Internal GPIO pins are used for PoE passthrough setups in multi-port
routers. This patch implemnets control over this hardware feature for
Ubiquiti Nanostations and TP-Link CPE510.
Signed-off-by: Lars Kruse <lists@sumpfralle.de>
SVN-Revision: 46271
This changes makes it possible to store custom settings
in individual files inside the directory /etc/sysctl.d/.
Signed-off-by: Stefan Tomanek <stefan.tomanek+openwrt@wertarbyte.de>
SVN-Revision: 46239
Depending on configuration, disable the LED before writing the trigger
and enable it after writing it. Fixes LEDs where the value defaults to 1
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45463
Use xattr to store the filesystem initialization state of the overlay.
As long as the filesystem is not marked as initialized yet (happens in
/etc/init.d/done), all overlay data (except for sysupgrade.tgz) will be
discarded before the system is allowed to boot
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 44942
somebody started to set a function returncode in the validation
stuff and everybody copies it, e.g.
myfunction()
{
fire_command
return $?
}
a function automatically returns with the last returncode,
so we can safely remove the command 'return $?'. reference:
http://tldp.org/LDP/abs/html/exit-status.html
"The last command executed in the function or script determines the exit status."
Signed-off-by: Bastian Bittorf <bittorf@bluebottle.com>
SVN-Revision: 42278
this allows targets to use the new uci-default helper which will generate
a file called /etc/board.json. a tool called /bin/config_generate can then
be used to generate the default uci settings.
Signed-off-by: John Crispin <blogic@openwrt.org>
SVN-Revision: 42185
Seems like the reverse order relies on GNU specific getopt hackery which
musl does not replicate
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 41045
Simply scan for the most recent file in /etc and set
system time to this file modification time if it's in the future
It allow some time dependent program to work immediatly
without waiting for ntpd to sync
v1: v2: bad approach
v3: simply scan /etc, thanks to Bastian Bittorf for the idea
v4: use sort -n, thanks to Catalin Patulea
v5: use [] instead of [[]], thanks to Andreas Mohr
v6: use openwrt style, thanks to Bastian Bittorf
Signed-off-by: Etienne CHAMPETIER <etienne.champetier@free.fr>
SVN-Revision: 39422
Only reload hostname and timezone config on /etc/init.d/boot restart.
Module loading and basic boot setup is only done during boot.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
SVN-Revision: 38670
The behaviour of calling 'mount' differed depending on whether it called
the busybox-mount, the mount of util-linux, the mount defined in
/lib/functions.sh and /lib/functions/boot.sh
/etc/preinit even included /lib/functions.sh and /lib/functions/boot.sh,
both re-defining 'mount'.
SVN-Revision: 34792
Write "delay" and "message" options to their respective files,
allowing Morse code message configuration through UCI.
The delay (dit length) defaults to 150ms (about 8 words per minute,
suitable for beginners).
Signed-off-by: Petr Viktorin <encukou@gmail.com>
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 34380
Without this, /etc/init.d/led will try to set the non-existing 'rssi' trigger.
This doesn't harm as the kernel will refuse this setting, but it outputs some
ugly log-lines:
Jun 24 10:15:19 OpenWrt user.info sysinit: setting up led RSSILOW
Jun 24 10:15:19 OpenWrt user.info sysinit: sh: write error: Invalid argument
...
In order to avoid this, skip LEDs with trigger = "rssi" in /etc/init.d/led
Signed-off-by: Daniel Golle <dgolle@allnet.de>
SVN-Revision: 33717
On slower devices wifi drivers might take too long for detecting
devices, resulting in the wifi detect call not seeing them.
This was observed on a bcm6348 with bcm4318 wifi. Adding a one second
pause was enough for b43 to expose the device.
SVN-Revision: 31639
hi
Another version, in this one the enable_server option is in the timeserver ntp part of the "system" config file
You can patch trunk and bacfire (tested both)
You can put busybox ntpd in client mode (if you put server), in client & server (by putting enable_server to 1, ntpd listen to udp 123), and also in server mode only (if you didn't put any servers in the config and still put enable_server 1, ntpd will answer with the time of the router)
I've replaced "config_foreach getpeers timeserver" with "config_get peers ntp server" because we want ntp timeserver, not random ones (to pre-answer if someone want to say that it's intrusive ...)
Signed-off-by: Etienne CHAMPETIER <etienne.champetier@free.fr>
Le 27/03/2012 20:41, Etienne Champetier a écrit :
> I've now tested my trunk patch and it works fine
> But I still can't find were $PROG is defined (is this a mistake, or some sort of built in variable???)
> (I've made some grep and nothing)
>
> Le 23/03/2012 02:19, Philip Prindeville a écrit :
>> Maybe:
>>
>> [ -n "$PROG" -a -x "$PROG" ] || return 1
>>
>> instead?
>>
>>
>> On 3/22/12 4:34 PM, Etienne Champetier wrote:
>>> Hi
>>>
>>> The 2 attached patchs (trunk & bacfire) add busybox ntpd enable_server option, as busybox ntpd server is compiled by default.
>>> We only need 1 client/server daemon (olipro patch was launching 2 daemons)
>>> I've fully tested the bacfire patch, and as i don't have a running openwrt trunk i'm not sure for the trunk patch (i'm sure about my modifications, but i'm not sure about "[ -x $PROG ] || return 1", as "$PROG" isn't defined ?!)
>>>
>>> Signed-off-by: Etienne CHAMPETIER <etienne.champetier@free.fr>
>>>
>>>
>>> Le 16/01/2012 01:57, Philip Prindeville a écrit :
>>>> On 1/14/12 11:37 AM, Olipro wrote:
>>>>> On Saturday 14 Jan 2012 02:45:59 Philip Prindeville wrote:
>>>>>> Don't we already have a 'disabled' option? Now we're adding an
>>>>>> 'enable_server' option?
>>>>>>
>>>>>> That seems confusing for no useful reason.
>>>>>>
>>>>> have you bothered to read what I originally wrote? your response would make
>>>>> me inclined to believe that you didn't.
>>>>>
>>>>> currently the ntpd initscript only runs it as a CLIENT - this patch enables
>>>>> you to have one instance running as a client and another as a SERVER that
>>>>> other hosts can synchronise with.
>>>>>
>>>>> Or perhaps I'm misunderstanding, what would you propose for allowing the
>>>>> built-in busybox ntpd to be utilised as a server? a separate init script
>>>>> entirely perhaps?
>>>> Or separate config sections... instead of 'config ntp' have 'config ntp-server' and 'config ntp-client'.
>>>>
>>>> -Philip
>>>>
>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel@lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
SVN-Revision: 31374
The script tests for the existance of /dev/root with test -e which fails if
/dev/root is a dangling symlink making the call to ln fail.
Signed-off-by: Justus Winter <4winter@informatik.uni-hamburg.de>
SVN-Revision: 26483
Setting the system variable "foreground" to yes causes the system to run
the init scripts in series and wait for completion.
This is useful if (a) you don't want the user getting into the console
until the system is initialized, or (b) you have things going on in your
scripts that require strict ordering (and no possible race conditions).
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
SVN-Revision: 20841
