| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
whats taking time, as there is usually little to cleanup involved
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Only write if changed or missing.
Vast majority of reboots will not have a change so don't hit the file system with a needless write. RAM disk enabled systems will always write due to missing the file on boot up.
|
| |
|
|
|
|
|
| |
Use a single file for vendor MAC retention (vendor_mac).
a) Writes only one file during boot up rather than a file for each interface.
b) More efficient than numerous tiny files.
c) Friendlier to write cycle sensitive media in a RAM disk disabled system.
|
| |
|
|
|
|
| |
Relocate the vendor MAC retention file to /var/db directory.
a) It's more at home here with other network interface stuff.
b) Friendlier to write cycle sensitive media in a RAM disk enabled system.
|
| | |
|
| |
|
|
|
|
|
| |
Include Logs
Restoring the RAM disk as soon as it is available will make it easier to include additional content that needs to persist across reboots for packages etc.
Include the logs in the RAM disk store so they will persist across reboots.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Treat the RAM disk more like a permanent storage device with content managed/restored by the system and made available at boot up, before needed by any services.
a) Handle saving and restoring RAM disk content at reboot/shutdown/boot centrally in more of a system manged fashion.
b) If it's in the RAM disk store it gets restored early in the pfSense startup so it's available for whatever needs to use it.
c) Services utilizing RAM disk don't need to be aware that their content is on a RAM disk, and handling content restore individually.
2) Has the benefit of eliminating some issues with the previous code as well. Such as...
a) Restoring RRD multiple times during boot, potentially at least 3 times, by rc.newwanip, rc.newwanipv6, and rc.boot. Some even overlapping.
b) Not removing the backups if/when not being utilized. Such as on a full install with the RAM disk option not enabled.
c) Eliminate some duplicate code.
3) Looking forward.
a) The more centrally system managed approach may crack the door open to making it easier to include some of the logs in the RAM disk store. As well as anything else that may be useful/desirable to retain in the RAM disk across reboots.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
During boot local_sync_acocunts() should be able to access LDAP server
on a non-local network or also resolve LDAP server hostname. To make it
possible move calls to create static routes and start dnsmasq/unbound
to run earlier
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
- Retire system_console_configure()
- Replace above call on rc.bootup by setup_serial_port()
|
| |
|
|
|
|
|
|
| |
If ramdisk is enabled keep a copy of the alias tables to restore at boot time. Otherwise unpredictable behavior may occur due to some aliases not being available when the firewall rules load.
Because alias tables are typically somewhat static, the following strategies are employed to keep write cycles to a minimum for SSD and flash drive type devices friendliness.
1) Back up during reboot/shutdown only if a backup copy of the alias table does not already exists. This is typically during the reboot when ramdisk is first enabled.
2) Update the backup copy only when the alias table is updated with a new download, typically 1 or more days, as configured in the firewall alias.
|
| | |
|
| |
|
|
|
|
|
|
| |
- Do not call ntpdate before start ntpd, ntpd -g parameter is enough
- Deprecate /usr/local/sbin/ntpdate_sync_once.sh
- Remove system_ntp_configure parameter and always start ntpd
(cherry picked from commit 5a758355ec9a20ff75c9191b6915df64255fb8be)
|
| | |
|
| |
|
|
| |
during boot
|
| |
|
|
|
|
|
|
|
|
|
| |
If you use the the webGUI to reset to factory defaults, then while the
existing system is shutting down you navigate off to the dashboard, the
initial setup wizard will start. The trigger_initial_wizard flag file is
deleted, and so after the reboot the initial setup wizard will not be
triggered.
This change fixes that sequence of events by using a different flag file
across the reboot, and switching it back to the usual flag file name
during the subsequent boot up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on factory default boot.
This allows the system to switch interfaces from the newer ones in the
default config (e.g. em0 em1) back to the interfaces used by:
Alix - vr1 vr0
APU - re1 re2
that match the WAN and LAN labels printed on many existing devices.
It means these devices can boot the default config and this will
automatically detect that there is no em0/em1 and will instead select
whatever exists out of vr1/vr0 or re1/re2. This avoids the user having
to use the serial cable to do interface assignment when starting a brand
new image, or when resetting to factory defaults. It could easily be
extended to other common interface combinations.
For me, this (or similar) would be very beneficial. At remote sites it
is really good if it is possible to do reset to factory defaults, or put
a fresh CF/SD card in, and the system boots without needing to connect a
serial cable and do interface assignment.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Use a different flag file to indicate that a package reinstall is
required after a reboot is done first. This avoids the possibility that
the user navigates in the webGUI during the time while the shutdown is
in progress and is accidentally presented with the reinstall all
packages GUI button.
Early in rc.bootup switch the flag file to use its ordinary name, so
that all subsequent code in boot scripts and webGUI will work as it
already does to handle the package reinstall and notifying the user that
a package reinstall is about to be done or in progress...
|
| | |
|
| | |
|
| | |
|
| |
|
