base-files: make sure tools are present in sysupgrade ramdisk
authorDaniel Golle <daniel@makrotopia.org>
Tue, 22 Feb 2022 18:04:34 +0000 (18:04 +0000)
committerDaniel Golle <daniel@makrotopia.org>
Tue, 22 Feb 2022 19:16:03 +0000 (19:16 +0000)
commit2baded9ecc3434abadec43bbcc0aca95a12deddd
treec3f8ca4cb347ea556e40c08500c9d937b2a11e5c
parentc0849c1d9c17ba96a37b67363b5551c065e9f50d
base-files: make sure tools are present in sysupgrade ramdisk

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>
package/base-files/files/lib/upgrade/stage2