Add a function 'ipcalc' to /lib/functions.sh that sets variables more
safely using export.
With this new function, dnsmasq also handles the return value of ipcalc
correctly.
Fixes: e4bd3de1be ("dnsmasq: refuse to add empty DHCP range")
Co-Authored-By: Philip Prindeville <philipp@redfish-solutions.com>
Signed-off-by: Leon M. Busch-George <leon@georgemail.eu>
Add 2 seconds sleep after each forcibly killed/tried-to-kill process
in the final process termination loop in sysupgrade stage2.
This is needed especially for qualcommax/ipq807x, where ath11k
wireless driver may have a long 10-20 seconds delay after termination
before actually getting killed. This often breaks sysupgrade.
The current KILL loop in kill_remaining does all 10 kill attempts
consecutively without any delay, as evidenced here in a failing sysupgrade.
It does not allow any time for the process to finalize its internal
termination.
Sat Sep 2 19:05:56 EEST 2023 upgrade: Sending TERM to remaining processes ...
Sat Sep 2 19:05:56 EEST 2023 upgrade: Sending signal TERM to hostapd (2122)
Sat Sep 2 19:05:56 EEST 2023 upgrade: Sending signal TERM to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending KILL to remaining processes ...
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2122)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Sending signal KILL to hostapd (2138)
Sat Sep 2 19:06:00 EEST 2023 upgrade: Failed to kill all processes.
sysupgrade aborted with return code: 256
The change in this commit adds a 2 seconds delay after each kill attempt
in order to allow some processes to more gracefully handle their
internal termination.
The result is like this:
Sun Sep 3 11:15:10 EEST 2023 upgrade: Sending TERM to remaining processes ...
Sun Sep 3 11:15:10 EEST 2023 upgrade: Sending signal TERM to hostapd (2309)
Sun Sep 3 11:15:10 EEST 2023 upgrade: Sending signal TERM to hostapd (2324)
Sun Sep 3 11:15:14 EEST 2023 upgrade: Sending KILL to remaining processes ...
Sun Sep 3 11:15:14 EEST 2023 upgrade: Sending signal KILL to hostapd (2309)
[ 699.827521] br-lan: port 7(hn5wpa2r) entered disabled state
[ 699.908673] device hn5wpa2r left promiscuous mode
[ 699.908721] br-lan: port 7(hn5wpa2r) entered disabled state
[ 701.038029] br-lan: port 6(hn5wpa3) entered disabled state
Sun Sep 3 11:15:16 EEST 2023 upgrade: Sending signal KILL to hostapd (2324)
[ 702.058256] br-lan: port 5(hn2wlan) entered disabled state
[ 709.250063] stage2 (8237): drop_caches: 3
Sun Sep 3 11:15:25 EEST 2023 upgrade: Switching to ramdisk...
The delay introduced here only kicks in if there is some process that
does not get terminated by the first TERM call. Then there is at least
one 2 sec wait after the first KILL loop round.
This commit is related to discussion in PRs #12235 and #12632
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Reviewed-by: Robert Marko <robimarko@gmail.com>
Some Broadcom MIPS devices require JFFS2 cleanmarkers to be present on the
kernel partition or the bootloader will identify the partition as corrupt and
won't boot the kernel.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
When using OpenWRT with DSA and 'lan' ports, we could get an empty
`next_eth`. This is of course not desirable, as this causes `sh: out of
range` errors when trying to determine which one would be greater.
It turns out, that we don't even need this check at all because, when
looking for all existin eth*s on a system, and take the highest index
and then iterate a set of devices and rename to eth${highest_index+n},
it is guaranteed that there will be no conflict.
Fixes: b688bf83f9 ("base-files: rename ethernet devs on known boards")
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
When using "ubiformat" with stdin it requires passing image size using
the -S argument. Provide it just like we do for "ubiupdatevol".
This fixes:
ubiformat: error!: must use '-S' with non-zero value when reading from stdin
This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices
possibly some other targets too.
Cc: Rodrigo Balerdi <lanchon@gmail.com>
Cc: Daniel Golle <daniel@makrotopia.org>
Fixes: 9710712120 ("base-files: accept gzipped nand sysupgrade images")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Daniel Golle <daniel@makrotopia.org>
Tested-by: Koen Vandeputte <koen.vandeputte@citymesh.com>
In DHCPv6-PD enabled environments, addresses are assigned to interfaces.
These new functions retrieve the IPv6 assigned prefix(es).
Signed-off-by: Mark Baker <mark@vpost.net>
Starting from Linux Kernel version 6.3 UBI devices will no longer be
considered virtual, but rather have an MTD device parent. Hence they
will no longer be listed under /sys/devices/virtual/ubi which is
used in multiple places in OpenWrt. Prepare for future kernels by
using /sys/class/ubi instead of /sys/devuces/virtual/ubi.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
$BOOTDEV_MAJOR may be empty for many of the uevents parsed in this
function. This condition thus tends to fail benignly (we just skip to
the next device), but it can really clutter the stage2 sysupgrade
stderr, since it looks like the "=" operand doesn't have an appropriate
left-hand argument.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
This change ensures compatibility with both types of sysupgrade-tar files.
1. For some boards like xiaomi,redmi-router-ax6s, sysupgrade-tar
is pack in directory `vendor,name/`
2. For some boards like xiaomi,mi-router-3g, sysupgrade-tar is pack
in directory `vendor_name/`
Signed-off-by: Chen Minqiang <ptpt52@gmail.com>
emmc_do_upgrade() relies on identify() from the nand.sh upgrade helper.
This only works because FEATURES=emmc targets also tend to include
FEATURES=nand.
Rename identify_magic() to identify_magic_long() to match the common.sh
style and make it clear it pairs with other *_long() variants (and not,
say *_word()).
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
It's necessary to be able to specify the length
for MAC addresses that are stored in flash, for example,
in a case where it is stored without any delimiter.
Let both offset and length have default values.
Add a sanity check related to partition size.
Also, clean up syntax and unnecessary lines.
Signed-off-by: Michael Pratt <mcpratt@pm.me>
This is a MT7621-based device with 128MB NAND flash, 256MB RAM, and a USB port.
The board has headers to attach console. In order for them to work two solder
bridges near those pads need to be made.
The defice has the following partition table:
```
0x000000000000-0x000000080000 : "u-boot"
0x000000080000-0x000000100000 : "u-boot-env"
0x000000100000-0x000000140000 : "factory"
0x000000140000-0x000007e00000 : "firmware"
0x000007e00000-0x000008000000 : "panic-ops"
```
`firmware` partition contains UBI volumes. Unfortunately I accidentally wiped
partition and I no longer have access to it.
`firmware` partition contains 'secondary' U-Boot which is run by 'first' u-boot.
It also contains various configuration partitions that include device info and
MAC address. There also seems to be 'primary' and 'backup' set of 'main' volumes.
U-boot has `mtkupgrade` command that just overrides data on firmware partitions.
Firmware file provided by TP-Link cannot be used with that command.
U-boot also has 'recovery' http server. Unfortunately I was not able to make it
work with manufacturer's firmware.
Manufacturer's firmware essentially contains multiple UBI volumes along with
'partition table'. Unfortunately I no longer can properly run manufacturer's
firmware so I cannot at the moment try to a support for building 'factory' images.
This patch adds support for initramfs image as well as sysupgrade image.
This seems to be pretty standard MT7621 board otherwise.
Things that work:
* network
* leds
* usb
* factory MAC detection
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
This is used to access footer data in firmare files, and is simpler and
less error-prone than using 'dd' with calculated offsets.
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
Ensure the MAC address for all NanoPi R1 boards is assigned uniquely for
each board.
The vendor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500d ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer <mail@david-bauer.net>
Signed-off-by: Jan-Niklas Burfeind <git@aiyionpri.me>
There are some devices putting kernel and rootfs on separated
ubi volumes. To make OpenWrt compatible with their bootloader,
we need to put kernel and rootfs into separated ubi volumes.
Add support for CI_KERN_UBIPART and CI_ROOT_UBIPART for this
situation.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
split ubi reformat/attach into nand_attach_ubi in preparation
for reusing this code in other functions.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Several Broadcom targets were using the nand_do_upgrade_success
shell function which has been removed by commit e25e6d8e54
("base-files: fix and clean up nand sysupgrade code"). Refactor the
new nand_do_upgrade to bring back nand_do_upgrade_success with the
behavior expected by those users.
Fixes: e25e6d8e54 ("base-files: fix and clean up nand sysupgrade code")
Reported-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
When firmware images only contained compressed kernels and squashfs roots,
uncompressed tar files were a good option. We are now using UBIFS images,
both raw and tarred, as well as ubinized (full UBI partition) images, all
of which benefit greatly from compression.
For example, a raw ubinized backup taken from a running Askey RT4230W REV6
(such full backups can be restored via the LUCI's sysupgrade UI) is over
400 MB, but compresses to less than 10 MB.
This commit adds support for gzipped versions of all file types already
accepted by the nand sysupgrade mechanism, be them raw or tarred.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
It has been reported that ubinized nand sysupgrade fails under certain
circumstances, being unable to detach the existing ubi partition due to
volumes within the partition being mounted.
This is an attempt to solve such issues by unmounting and removing
ubiblock devices and unmounting ubi volumes within the target partition
prior to detaching and formatting it.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
- Never return from 'nand_do_upgrade', not even in case of errors, as that
would cause execution of sysupgrade code not intended for NAND devices.
- Unify handling of sysupgrade success and failure.
- Detect and report more error conditions.
- Fix outdated/incorrect/unclear comments.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
These will be used to give WLAN PHYs a specific name based on path specified
in board.json. The platform board.d script can assign a specific order based
on available slots (PCIe slots, WMAC device) and device tree configuration.
This helps with maintaining config compatibility in case the device path
changes due to kernel upgrades.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The currently used shell expansion doesn't seem to exist [0] and also
does not work. This surely was not intended, so lets allow default
naming to actually work.
[0]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html
Fixes: be09c5a3cd ("base-files: add board.d support for bridge device")
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
Add support for TP-Link Deco S4 wifi router
The label refers to the device as S4R and the TP-Link firmware
site calls it the Deco S4 v2. (There does not appear to be a v1)
Hardware (and FCC id) are identical to the Deco M4R v2 but the
flash layout is ordered differently and the OEM firmware encrypts
some config parameters (including the label mac address) in flash
In order to set the encrypted mac address, the wlan's caldata
node is removed from the DTS so the mac can be decrypted with
the help of the uencrypt tool and patched into the wlan fw
via hotplug
Specifications:
SoC: QCA9563-AL3A
RAM: Zentel A3R1GE40JBF
Wireless 2.4GHz: QCA9563-AL3A (main SoC)
Wireless 5GHz: QCA9886
Ethernet Switch: QCA8337N-AL3C
Flash: 16 MB SPI NOR
UART serial access (115200N1) on board via solder pads:
RX = TP1 pad
TX = TP2 pad
GND = C201 (pad nearest board edge)
The device's bootloader and web gui will only accept images that
were signed using TP-Link's RSA key, however a memory safety bug
in the bootloader can be leveraged to install openwrt without
accessing the serial console. See developer forum S4 support page
for link to a "firmware" file that starts a tftp client, or you
may generate one on your own like this:
```
python - > deco_s4_faux_fw_tftp.bin <<EOF
import sys
from struct import pack
b = pack('>I', 0x00008000) + b'X'*16 + b"fw-type:" \
+ b'x'*256 + b"S000S001S002" + pack('>I', 0x80060200) \
b += b"\x00"*(0x200-len(b)) \
+ pack(">33I", *[0x3c0887fc, 0x35083ddc, 0xad000000, 0x24050000,
0x3c048006, 0x348402a0, 0x3c1987f9, 0x373947f4,
0x0320f809, 0x00000000, 0x24050000, 0x3c048006,
0x348402d0, 0x3c1987f9, 0x373947f4, 0x0320f809,
0x00000000, 0x24050000, 0x3c048006, 0x34840300,
0x3c1987f9, 0x373947f4, 0x0320f809, 0x00000000,
0x24050000, 0x3c048006, 0x34840400, 0x3c1987f9,
0x373947f4, 0x0320f809, 0x00000000, 0x1000fff1,
0x00000000])
b += b"\xff"*(0x2A0-len(b)) + b"setenv serverip 192.168.0.2\x00"
b += b"\xff"*(0x2D0-len(b)) + b"setenv ipaddr 192.168.0.1\x00"
b += b"\xff"*(0x300-len(b)) + b"tftpboot 0x81000000 initramfs-kernel.bin\x00"
b += b"\xff"*(0x400-len(b)) + b"bootm 0x81000000\x00"
b += b"\xff"*(0x8000-len(b))
sys.stdout.buffer.write(b)
EOF
```
Installation:
1. Run tftp server on pc with static ip 192.168.0.2
2. Place openwrt "initramfs-kernel.bin" image in tftp root dir
3. Connect pc to router ethernet port1
4. While holding in reset button on bottom of router, power on router
5. From pc access router webgui at http://192.168.0.1
6. Upload deco_s4_faux_fw_tftp.bin
7. Router will load and execture in-memory openwrt
8. Switch pc back to dhcp or static 192.168.1.x
9. Flash openwrt sysupgrade image via luci/ssh at 192.168.1.1
Revert to stock:
Press and hold reset button while powering device to start the
bootloader's recovery mode, where stock firmware can be uploaded
via web gui at 192.168.0.1
Please note that one additional non-github commits is also needed:
firmware-utils: add tplink-safeloader support for Deco S4
Signed-off-by: Nick French <nickfrench@gmail.com>
Some platforms lack an established way to name netdevs; for example,
on x86, PCIe-based ethernet interfaces will be named starting from
eth0 in the order they are probed. This is a problem for many devices
supported explicitly by OpenWrt which have hard-wired, standalone or
on-CPU NICs not supported by DSA (which is usually used to rename the
ports based on their ostensible function).
To fix this, add a mapping between ethernet device name and sysfs
device path to board.json; this allows us to configure ethernet device
names we know about for a given board so that they correspond to
external labeling.
Signed-off-by: Martin Kennedy <hurricos@gmail.com>
Some Arcadyan devices (e.g. MTS WG430223) keep their config in encrypted
mtd. This adds mtd_get_mac_encrypted_arcadyan() function to get the MAC
address from the encrypted partition. Function uses uencrypt utility for
decryption (and openssl if the uencrypt wasn't found).
Signed-off-by: Mikhail Zhilkin <csharper2005@gmail.com>
On x86, when both CONFIG_GRUB_CONSOLE and CONFIG_GRUB_SERIAL are set (as
they are by default), the kernel command line will have two console=
entries, such as
console=tty0 console=ttyS0,115200n8
Failsafe was only running a shell on the first defined console, the VGA
console. This is a problem for devices like apu2, where there is only a
serial console and it appears on ttyS0.
Moreover, the console prompt to enter failsafe during boot was delivered
to, and its input read from, the last console= on the kernel command
line. So while the failsafe shell was on the first defined console, only
the last defined console could be used to enter failsafe during boot.
In contrast, the x86 bootloader (GRUB) operates on both the serial
console and the VGA console by virtue of "terminal_{input,output}
console serial". GRUB also provided an alternate means to enter failsafe
from either console. The presence of two console= kernel command line
parameters causes kernel messages to be delivered to both. Under normal
operation (not failsafe), procd runs login in accordance with inittab,
which on x86 specifies ttyS0, hvc0, and tty1, allowing login through any
of serial, hypervisor, or VGA console. Thus, serial access was
consistently available on x86 devices with serial consoles under normal
operation, except for shell access in failsafe mode (without editing the
kernel command line).
By presenting the failsafe prompt, reading failsafe prompt input, and
running failsafe shells on all consoles listed in /proc/cmdline,
failsafe mode will work correctly on devices with a serial console (like
apu2), and the same image without any need for reconfiguration can be
shared by devices with the more traditional (for x86) VGA console. This
improvement should benefit any system with multiple console= arguments,
including x86 and bcm27xx (Raspberry Pi).
Signed-off-by: Mark Mentovai <mark at moxienet.com>
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: David Bauer <mail@david-bauer.net>
Remove forgotten redundant selinuxenabled call and skip the whole
thing in case $IPKG_INSTROOT is set as labels are anyway applied only
later on in fakeroot when squashfs is created.
Fixes: 6d7272852e ("base-files: add missing $IPKG_INSTROOT to restorecon call")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Update to overlooked v2 version of Dominick Grift's patch.
Fixes: 5109bd164c ("base-files: address sed in-place without SELinux awareness")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
sed(1) in busybox does not support this functionality:
https://git.savannah.gnu.org/cgit/sed.git/tree/sed/execute.c#n598
This causes /etc/group to become mislabeled when a package requests
that a uid/gid be added on OpenWrt with SELinux
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
[move restorecon inside lock]
Signed-off-by: Dominick Grift <dominick.grift@defensec.nl>
Commit ecbcc0b595 bricks devices on which the raw kernel and UBI mtd
partitions overlap.
This is the case of the ZyXEL NR7101 for example. Its OEM bootloader has
no UBI support. OpenWrt splits the stock kernel mtd partition into a raw
kernel part used by the bootloader and a UBI part used to store rootfs
and rootfs_data. Running mtd erase on the complete partition during
sysupgrade erases the UBI part and results in a soft brick.
Arguably the best solution would be to fix the partition layouts so that
kernel and UBI partitions do not overlap, also including a stock_kernel
partition to help reverting to stock firmware. This would have the added
benefit of protecting UBI from kernel images that are excessively large.
Fixes: ecbcc0b595 ("base-files: safer sysupgrade.tar for kernel-out-of-UBI")
Reported-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Attempt to minimize the time during which an interrupted nand sysupgrade
can lead to a non-functional device by flushing caches before starting
the upgrade procedure.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Fix issues while retaining configuration during nand sysupgrade:
- abort configuration saving if data partition is not found
- generate diagnostics if saving fails (eg, because of lack of space)
- do not output "sysupgrade successful" in case of errors
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Remove redundant check from nand ubinized sysupgrade code. This check
has already been done in the only caller of the affected function:
nand_do_upgrade.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Prepares code for ubirename-based safe sysupgrade implementation.
Fixes several issues:
- the special CI_KERNPART value "none" is ignored if an MTD partition
named "none" exists
- misleading variable names (such as has_kernel to mean "tar has kernel
and it should not be written to an MTD partition but a UBI volume")
- inconsistent treatment of zero-length tar member files
- inconsistent meaning of "0" and "" variable values
- redundant operations (unneeded untaring, repeated untaring, unneeded
partition lookups)
- inconsistent variable quoting
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Ensure that the kernel CRC is invalidated while rootfs is being updated.
This allows the bootloader to detect an interrupted sysupgrade and fall
back to an alternate booting method, such as TFTP, instead of just going
ahead with normal boot and effectively bricking the device.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Ensure that the kernel CRC is invalidated while rootfs is being updated.
This allows the bootloader to detect an interrupted sysupgrade and fall
back to an alternate booting method, instead of just going ahead with
normal boot and effectively bricking the device.
Possible fallbacks include a recovery initramfs partition or UBI volume
and TFTP. See here for an example U-Boot configuration with fallbacks:
https://shorturl.at/befsA (https://github.com/Lanchon/openwrt-tr4400-v2/
blob/e7d707d6bd7839fbd0b8d0bd180fce451df77e47/install-recovery.sh#L52-L63)
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Emit diagnostics if nand sysupgrade is aborted because UBI partition
cannot be attached. Also avoid redudndant checks.
Signed-off-by: Rodrigo Balerdi <lanchon@gmail.com>
Make sure sysupgrade on NAND also works in case of UBI volumes having
index >9. While at it, also make sure UBI device is detected and abort
in case it isn't. Use Shell built-in shorthand ':' instead of 'true'.
Fixes#9708
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
See firmware-utils.git commits [1], which implemented the cros-vbutil
verified-boot payload-packing tool, and extended ptgen for the CrOS
kernel partition type. With these, it's now possible to package kernel +
rootfs to make disk images that can boot a Chrome OS-based system (e.g.,
Chromebooks, or even a few AP models).
Regarding PARTUUID= changes: Chromium bootloaders work well with a
partition number offset (i.e., relative to the kernel partition), so
we'll be using a slightly different root UUID line.
NB: I've made this support specific to ip40xx for now, because I only
plan to support an IPQ4019-based AP that uses a Chromium-based
bootloader, but this image format can be used for essentially any
Chromebook, as well as the Google OnHub, a prior Chromium-based AP using
an IPQ8064 chipset.
[1]
ptgen: add Chromium OS kernel partition support
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=6c95945b5de973026dc6f52eb088d0943efa96bb
cros-vbutil: add Chrome OS vboot kernel-signing utility
https://git.openwrt.org/?p=project/firmware-utils.git;a=commit;h=8e7274e02fdc6f2cb61b415d6e5b2e1c7e977aa1
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Rootfs overlays get created at a ROOTDEV_OVERLAY_ALIGN (64KiB)
alignment after the rootfs, but emmc_do_upgrade() is assuming
it comes at the very next 512-byte sector.
Suggested-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
(move spaces around, mention fstools' libtoolfs)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
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: Daniel Golle <daniel@makrotopia.org>
This patch adds support for creation heartbeat led trigger with,
for example, this command:
ucidef_set_led_heartbeat "..." "..." "..."
from /etc/board.d/01_leds.
Signed-off-by: Alexey Smirnov <s.alexey@gmail.com>
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: Daniel Golle <daniel@makrotopia.org>
We were missing (not using) the last sector of each partition,
compared with the output of gparted.
Signed-off-by: Javier Marcet <javier@marcet.info>
[moved the dot]
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
