It's a variable set by procd that should replace hardcoded
/tmp/sysupgrade.tgz.
This change requires the most recent procd with the commit 0f3c136
("sysupgrade: set UPGRADE_BACKUP env variable").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 641f6b6c26cb9ab5e1198810015e5f4b2b5b34ad)
$CONF_TAR shouldn't be assumed to always point to the sysupgrade.tgz.
This change makes code more generic and allows refactoring $CONF_TAR.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit 62dbe361a1b1ed1506bc0387bff55eddcb619e49)
This explicitly lets stage2 know if partitions should be preserved. No
more "touch /tmp/sysupgrade.always.overwrite.bootdisk.partmap" hack.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
(cherry picked from commit b6f4cd57e19a8cfcd9ff52582b65164ce6213c3d)
Recently, upgrade device autodetection has been added to the mvebu target.
This exposes some shortcomings of the generic export_bootdevice function,
e.g. on the Turris Omnia: export_bootdevice silently reports the root
partition to be the boot device. This makes the sysupgrade process fail at
several places.
Fix this by clearly distinguishing between /proc/cmdline arguments which
specify the boot disk, and those which specify the root partition. Only in
the latter case, strip off the partition, and do it consistently.
root=PARTUUID=<pseudo PARTUUID for MBR> (any partition) and root=/dev/*
(any partition) are accepted.
The root of the problem is that the *existing* export_bootdevice in
/lib/upgrade/common.sh behaves differently, if the kernel is booted with
root=/dev/..., or if it is booted with root=PARTUUID=...
In the former case, it reports back major/minor of the root partition,
in the latter case it reports back major/minor of the complete boot disk.
Targets, which boot with root=/dev/... *and* use export_bootdevice /
export_partdevice, have added workarounds to this behaviour, by specifying
*negative* increments to the export_partdevice function.
Consequently, those targets have to be adapted to use positive increments,
otherwise they are broken by the change to export_bootdevice.
Fixes: 4e8345ff68 ("mvebu: base-files: autodetect upgrade device")
Signed-off-by: Klaus Kudielka <klaus.kudielka@gmail.com>
Tested-by: Tomasz Maciej Nowak <tomek_n@o2.pl>
Restoring the bootloader config before rebooting fails:
tar: invalid tar magic
Add the -z option to the tar command to fix this.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
BusyBox's `tar` command does not support the `--directory` directive, which
is essentially `-C` in short-form option.
BusyBox's `tar` command supports `-C`.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Advantages:
- preserves existing partition layout on the sd-card.
Only the boot and rootfs partition will be overwritten.
Please note that sysupgrade will refuse to upgrade, if the existing
installation has an incompatible partition layout. Future changes
to the bootfs and/or rootfs partition size will likely cause breakage
to the sysupgrade procedure. In these cases, the ext4-sdcard.img.gz
will have to be written to the sdcard manually.
Please don't forget to backup your configuration in this case.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This patch converts all the raspberrypi images to utilize
the common metadata-based image verification.
Note: the CM1 and CM3 currently use the same "rpi-cm"
boardname.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
The Raspberry Pi bootloader reads configuration values from config.txt
in the boot partition. This file allows to specify the amount of memory
to assign to the GPU, the license keys for hardware MPEG-2 and VC-1
decoding, Device Tree parameters and overlays, and lots of other things.
Since sysupgrade only restores the configuration after booting the newly
flashed image, these values will not be active, even if sysupgrade would
save /boot/config.txt. To solve this, add the file to the files to be
backed up, and restore it in platform_copy_config, before reboot.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Implement a crude but functioning sysupgrade image check for the
Raspberry Pi. The code only checks if the master boot record boot
signature (0x55aa) is present in the first 512-bytes at the correct
location. This can prevent the odd bricking of a system when flashing
the wrong file.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
This way it's easier to configure device tree overlays, customize other
parameters...
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
SVN-Revision: 47126
Implement sysupgrade for Raspberry Pi, similar to the way it is done on x86:
The config files are saved in the boot partition and moved to where they are
normally expected in preinit.
Also add optional gzip compression for the SD card image, since this can save
a lot of space (76M vs 6M), also similar to x86.
Signed-off-by: Bruno Randolf <br1@einfach.org>
SVN-Revision: 46347
Rafał Miłecki