Skip to content

O
openwrt

mirrors / openwrt / openwrt
大约 1 年 前同步成功

通知 7
Star 2
Fork 0
O
openwrt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 10月, 2022 1 次提交
  3. 10 10月, 2022 2 次提交
  5. 04 9月, 2022 2 次提交
  7. 19 8月, 2022 1 次提交
  9. 01 8月, 2022 2 次提交
  11. 07 7月, 2022 2 次提交
  13. 23 6月, 2022 1 次提交
    • D
      base-files: allow ignoring minor compat-version check · 618ab576
      由 David Bauer 提交于 
      Downstream projects might re-generate device-specific configuration
based on OpenWrt's defaults on each upgrade, thus being unaffected by
forward- as well as backwards-breaking configuration.

Add a new sysupgrade parameter, which allows sysupgrades between minor
compat-versions. Upgrades will still fail upon mismatching major compat
versions.
Signed-off-by: NDavid Bauer <mail@david-bauer.net>
(cherry picked from commit 34437af8)
      618ab576
  15. 11 6月, 2022 2 次提交
  17. 27 5月, 2022 2 次提交
  19. 04 5月, 2022 3 次提交
  21. 21 4月, 2022 2 次提交
  23. 15 4月, 2022 1 次提交
  25. 20 3月, 2022 1 次提交
  27. 19 3月, 2022 2 次提交
    • F
      base-files: add wrapper for procd service list command · 09c41ea6
      由 Florian Eckert 提交于 
      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: NFlorian Eckert <fe@dev.tdt.de>
      09c41ea6
    • F
      procd: move service command to procd · b9017384
      由 Florian Eckert 提交于 
      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: NFlorian Eckert <fe@dev.tdt.de>
      b9017384
  29. 17 3月, 2022 1 次提交
  31. 12 3月, 2022 1 次提交
    • R
      base-files: call "sync" after initial setup · 9851d4b6
      由 Rafał Miłecki 提交于 
      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: NRafał Miłecki <rafal@milecki.pl>
Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
Acked-by: NSergey Ryazanov <ryazanov.s.a@gmail.com>
      9851d4b6
  33. 25 2月, 2022 1 次提交
    • R
      base-file: remove password aging feature form /etc/shadow · e040d311
      由 Rucke Teg 提交于 
      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: NRucke Teg <rucketeg@protonmail.com>
      e040d311
  35. 23 2月, 2022 1 次提交
    • D
      base-files: make sure tools are present in sysupgrade ramdisk · 2baded9e
      由 Daniel Golle 提交于 
      Not all targets create /var/lock or touch /var/lock/fw_printenv.lock in
their platform.sh. This is problematic as fw_printenv then fails in
case /var/lock/fw_printenv.lock has not been created by previous calls
to fw_printenv/fw_setenv before sysupgrade is run.

Targets using fw_printenv/fw_setenv during sysupgrade:
 * ath79/*
 * ipq40xx/*
 * ipq806x/*
 * kirkwood/*
 * layerscape/*
 * mediatek/mt7622
 * mvebu/*
 * ramips/*
 * realtek/*

Targets currently using additional steps in /lib/upgrade/platform.sh
to make sure /var/lock/fw_printenv.lock (or at least /var/lock)
actually exists:
 * ath79/* (openmesh devices)
 * ipq40xx/* (linksys devices)
 * ipq806x/* (linksys devices)
 * kirkwood/* (linksys devices)
 * layerscape/*
 * mvebu/cortexa9 (linksys devices)

Given that accessing the U-Boot environment during sysupgrade is not
uncommon and the situation across targets is currently quite diverse,
just make sure both tools as well fw_env.config are always copied to
the ramdisk used for sysupgrade. Also make sure /var/lock always
exists.

This now allows to remove copying of fw_printenv/fw_setenv as well as
fw_env.config, creation of /var/lock or even /var/lock/fw_printenv.lock
from lib/upgrade/platform.sh or files included there.

As the same applies also to 'fwtool' which is used by generic eMMC
sysupgrade, also always copy that to ramdisk.
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
      2baded9e
  37. 19 2月, 2022 1 次提交
  39. 17 2月, 2022 1 次提交
    • D
      base-files: Make sure rootfs_data_max is considered · 397de500
      由 Daniel Golle 提交于 
      For sysupgrade on NAND/UBI devices there is the U-Boot environment
variable rootfs_data_max which can be used to limit the size of the
rootfs_data volume created on sysupgrade.
This stopped working reliable with recent kernels, probably due to a
race condition when reading the number of free erase blocks from sysfs
just after removing a volume.
Change the script to just try creating rootfs_data with the desired
size and retry with maximum size in case that fails. Hence calculating
the available size in the script can be dropped which works around the
problem.
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
      397de500
  41. 07 2月, 2022 1 次提交
  43. 27 12月, 2021 1 次提交
  45. 04 12月, 2021 1 次提交
    • F
      base-files: fix service_running check · dd681838
      由 Florian Eckert 提交于 
      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: NFlorian Eckert <fe@dev.tdt.de>
Reviewed-by: NSungbo Eo <mans0n@gorani.run>
      dd681838
  47. 03 12月, 2021 1 次提交
    • E
      base-files: add eMMC sysupgrade support · 57c1f3f9
      由 Enrico Mioso 提交于 
      Adds generic support for sysupgrading on eMMC-based devices.

Provide function emmc_do_upgrade and emmc_copy_config to be used in
/lib/upgrade/platform.sh instead of redundantly implementing the same
logic over and over again.
Similar to generic sysupgrade on NAND, use environment variables
CI_KERNPART, CI_ROOTPART and newly introduce CI_DATAPART to indicate
GPT partition names to be used. On devices with more than one MMC
block device, CI_ROOTDEV can be used to specify the MMC device for
partition name lookups.

Also allow to select block devices directly using EMMC_KERN_DEV,
EMMC_ROOT_DEV and EMMC_DATA_DEV, as using GPT partition names is not
always an option (e.g. when forced to use MBR).

To easily handle writing kernel and rootfs make use of sysupgrade.tar
format convention which is also already used for generic NAND support.
Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
CC: Li Zhang <li.zhang@gl-inet.com>
CC: TruongSinh Tran-Nguyen <i@truongsinh.pro>
      57c1f3f9
  49. 29 11月, 2021 1 次提交
    • R
      base-files: dont always create kernel UBI volume · f2c4064e
      由 Robert Marko 提交于 
      Currently nand_upgrade_tar() will pass the kernel length
to nand_upgrade_prepare_ubi() in all cases except for when
the kernel is to be installed in a separate partition as a
binary with the MTD tool.

While this is fine for almost all cases newer MikroTik NAND
devices like hAP ac3 require the kernel to be installed as a
UBIFS packed UBI volume in its own partition.

So, since we have a custom recipe to use ubiformat to flash
the kernel in its partition it makes no sense for sysupgrade
to also install the kernel as a UBI volume in the "ubi"
partition as it only wastes space and will never be used.

So, simply check whether CI_KERNPART is set to "none" and
if so unset the "has_kernel" variable which will in turn
prevent the kernel length from being passed on and then
the kernel UBI volume wont be created for no usefull purpose.

The ath79 MikroTik NAND target has been setting CI_KERNPART
to "none" for a while now altough that was not preventing
the kernel to be installed as UBI volume as well.
Signed-off-by: NRobert Marko <robimarko@gmail.com>
      f2c4064e
  51. 14 11月, 2021 1 次提交
    • D
      base-files: stage2: improve /proc/*/stat parser · 4d3303b1
      由 Daniel Golle 提交于 
      Simply reading /proc/*/stat as a space-separated string will not work
as the process name may itself contain spaces. Hence we must match on
the '(' and ')' characters around the process name and can then handle
the remaining string as space-separated values.
This fixes shell error messages which have been popping up the console
due to spaces in process names being interpreted as field separators.
Signed-off-by: NDaniel Golle <daniel@makrotopia.org>
      4d3303b1
  53. 02 11月, 2021 2 次提交
  55. 01 11月, 2021 1 次提交
  57. 28 10月, 2021 1 次提交