Commit Graph

7 Commits

Author SHA1 Message Date
Rafał Miłecki
a717428828 treewide: use new procd sysupgrade $UPGRADE_BACKUP variable
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 641f6b6c26)
2019-09-12 13:27:29 +02:00
Rafał Miłecki
1b9a4f0cb4 treewide: when copying a backup file always specify dest name
$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 62dbe361a1)
2019-09-12 13:26:39 +02:00
Rafał Miłecki
2c77562af8 treewide: sysupgrade: pass "save_partitions" option to the "sysupgrade" method
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 b6f4cd57e1)
2019-09-04 13:43:05 +02:00
Klaus Kudielka
ad62247800 base-files: improve lib/upgrade/common.sh
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>
2019-05-11 16:37:11 +02:00
Matthias Schiffer
ce06d2bd01
sunxi: sysupgrade: sync with x86
sunxi sysupgrade was based on the x86 implementation; sync fixes and other
changes from the current x86 version:

x86: fix sysupgrades on disks with 4k block size
x86: sysupgrade: move partition table change check to platform_check_image
x86: sysupgrade: refactor platform_do_upgrade
x86: sysupgrade: explicitly rescan disk after writing partition table

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
2017-05-29 23:50:35 +02:00
Matthias Schiffer
6bb7b87315
sunxi: sysupgrade: don't write partitions twice
When existing partitions are retained, the dd call writing the uboot image
in the space before the first partition was accidentally writing the whole
image, making the code for individual partitions redundant. Limit the copy
to 1016KiB (the first 8KiB are skipped, and the first partition starts at
1024KiB).

In addition, conv=notrunc is replaced with conv=fsync. It seems this was an
oversight, as notrunc doesn't make sense for block devices and all other dd
commands use conv=fsync.

Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
2017-05-29 23:50:34 +02:00
Yousong Zhou
5ece16fd23 sunxi: add sysupgrade support
Enalbe builtin support for FAT filesystem as we need to mount boot
partition to store sysupgrade.tgz there

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
2017-01-05 11:09:15 +01:00