It attempts to use /data/local/tmp instead, which results in the
following error message:
[ 154.293873] /tmp/addon.d/50-lineage.sh[43]: can't create temporary file : No such file or directory
Change-Id: I34be32ef41c92a6b543c75e4beaa3f326615e888
Extracted file /tmp/install/bin/backuptool.functions
Extracted file /tmp/install/bin/backuptool.sh
Extracted 2 file(s)
about to run program [/tmp/install/bin/backuptool.sh] with 5 args
[libfs_mgr]Unmapped logical partition system
DM_DEV_REMOVE failed for [vendor]: Device or resource busy
Cannot unmap vendor before removing group qti_dynamic_partitions.
script aborted: assert failed: update_dynamic_partitions(package_extract_file(dynamic_partitions_op_list))
assert failed: update_dynamic_partitions(package_extract_file(dynamic_partitions_op_list))error: 25
Updater process ended with ERROR: 1
Failed to mount '/system_root' (No such file or directory)
I:Actual block device: '/dev/block/dm-0', current file system: 'ext4'
We can clearly see that after version 3 script is executed with
its specific functions. It cannot or don't unmount partitions for
successful OTA upgrade. Resulting broken installation, this also
affects ROM inbuilt OTA updater app.
Signed-off-by: TheHitMan7 <krtik.vrma@gmail.com>
Change-Id: Ic2d4e7809e8abd402c2a49188c73c83ea3b4e8df
* Ignore the block devices in case their mount points are symlinks.
This is common on devices where maintainers have chosen not to use
real partitions because of their size being too small to be useful
Also `continue` instead of `break`. Oops.
Change-Id: I3e27abe510219066ecacd81d099220ac8e119f9f
There are addon.d scripts that rely on the value of ADDOND_VERSION
to determine if they're being called from a-only vs a/b backuptool.
If they declare ADDOND_VERSION=3, they shall stop doing that;
otherwise offer them the same environment, that is unset ADDOND_VERSION
for a-only backuptool.
Change-Id: I1be21eda2e6ec9837b3080bb5e7fbe5241318eaa
For scripts declaring ADDOND_VERSION=3 automatically mount
vendor, product, system_ext and others (when they're dedicated partitions).
Also expose the get_output_path() function to get the path to where
a file is mounted in case it lives in a dedicated partition.
ab exapmles:
get_output_path "system/product/priv-app/MyApp.apk" = "/postinstall/product/priv-app/MyApk.apk"
get_output_path "system/app/MySystemApp.apk" = "/postinstall/system/app/MySystemApp.apk"
a-only examples:
get_output_path "/mnt/system/system/product/priv-app/MyApp.apk" = "/mnt/system/system/product/priv-app/MyApp.apk"
******************************************************************
Instead of cycling all scripts for each stage, run
pre-backup -> backup -> post-backup in quick succession
(and likewise for restore), to ensure backwards compatibility
with scripts that wrongly assumed their environment not to
change between steps.
This is needed because we want to undo any mounting done for V3
scripts when executing V2 scripts. If a V2 script did mounting in
pre-restore and expected things to still be mounted in restore,
we would break their (yes incorrect) assumption.
Change-Id: I73fbad6f45824fed99e4482128769435348588f5
Backup/restore functionality was broken in the
Ia1f4ae95c9e4dae4df844853e81c264bc838f177 change
because of incorrect check of the function's result.
check_prereq() function refactored to return 0 if
backuping/restoration is possible. Any work should be
performed only if check_prereq() succeeds.
Change-Id: Ic977dba675df58a228ef4b882b25beb66cc9d2c6
For non AB devices system partition should be unmounted
if check_prereq function fails.
This patch also refactors backuptool a bit for AB devices
in order to look same as backuptool for non AB devices.
Change-Id: Ia1f4ae95c9e4dae4df844853e81c264bc838f177
* This check was supposed to check whether the script
addon.d version was lower than backuptool's
* Given that the backuptool addon.d version is 1, this
isn't going to happen ever making this check completely
unuseful
Change-Id: I2464749b52bf4e8825e0b4ef42500ee7d3bbfa61
* For some odd reasons executing `cd /system/addon.d` makes the system
hang and unmount error:
umount: /system_root: Device or resource busy
* Don't change directory to not allow the system partition hang
Change-Id: I3d30bdc59c2f05d16823e99046c1dce2e1e6eb73
* If any of these two function gets run on a recovery mounting system
to /system, /system/addon.d won't exist while /system/system/addon.d will.
* Run the functions with $S as argument to make this work correctly
Change-Id: I02e7b91429a9e74d28bdb77e56955dad97ca75ac
* The path /postinstall exists only for A/B, causing:
grep: /postinstall/tmp/addon.d/*sh: No such file or directory
Change-Id: Ia07b3029e949c3e08302457cd08798a4dde00ef6
* Dynamically mount system to the path chosen by the recovery through backuptool
* This can be helpful because of the fragmentation that will happen with system mount in recovery after Q
Change-Id: I2d1e775efcf87e33319bc7790d1e54bca72116d3
* The grep errorlevel output was not properly used by the if,
therefore allowing a device to upgrade with old addons
instead of aborting the backuptool steps
* The LineageOS versions properties were removed from the build.prop,
which is resolved properly in commit:
"lineage: Keep LineageOS versions properties in build.prop"
Change-Id: I0060141c097b3d14c3710eee1e0caf7110634967
* Introduced in the following commit:
"backuptool: Take into account new location for system default props"
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
This reverts commit 1022cc7c50.
Change-Id: I7f5a3510f64f0ecabfe9d15b5dbc1a667b210eb8
Signed-off-by: Adrian DC <radian.dc@gmail.com>
* Since A/B addon.d scripts are going to need to do things in a
specific way or things could go horribly wrong for a user, let's
introduce versioning so that scripts can claim to be compatible.
* A script can denote it is compatible with addon.d version 2 by
adding: "# ADDOND_VERSION=2" somewhere in its script.
* Only A/B will require version 2 scripts for now, and version 2
scripts will still run on non-A/B. Additionally if a script does
not explicitly denote its version, assume its version 1.
* Version 1: The same old scripts we've always used. We cannot assume
these will all work with A/B backuptools.
* Version 2: Scripts that denote they are compatible with version 2
must be aware of the fact that A/B devices will run this
script for a rom, during a seamless update, mounted at
/postinstall. The best way to ensure compatibility would
be to use the pre-designated functions found in the
backuptool[,_ab].functions scripts.
Change-Id: I5573018dabd21bb64c7c964e2081806072a75243
* Due to both following commits, backuptool went permissive
and lineage properties got lost from the system on devices
that do not have BOARD_PROPERTY_OVERRIDES_SPLIT_ENABLED
"backuptool: Take into account new location for system default props"
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
"lineage: Move to Google's method of defining system default props"
Change-Id: I6cb0e28a7599b010b389cc541015a37010a00f4b
* Once the properties issue is properly resolved in the sources,
a period of time is required for "most" of the users to upgrade
their system with fixed lineage properties before we break addons
by repairing the backuptool script globally
Change-Id: Iea8865ea9bb05eed56a8a0a7b95e3f04b01c4bae
* System default props defined using PRODUCT_SYSTEM_DEFAULT_PROPERTIES
are stored into /system/etc/prop.default, so that's the location where
ro.lineage.version prop needs to be checked now. Although, fallback
to the old location to allow sucessful upgrades.
Change-Id: I62046447876c2198a0c4f88a4f36f4723d417617
If /system is empty, /tmp/addon.d/ will not exist, "*sh" won't be
expanded, md5sum will not generate any output and the variable $s
will be empty. Therefore grep, which will receive only one arg, will
start to read the standard input and never exit, causing the
installation to never end. Fix this checking whether we have files
to read or not.
Change-Id: I656eab42e54b3f81da8c5ac81374b9deddcf8484
* Add the addon.d folder creation to preserve_addon_d
before copying the files back to /system/addon.d
* On CM based ROMs, the path exists for built elements,
but on other AOSP-based ROMs where this script might
be used, the folder might not be created on build and
copy fails, breaking backuptool on second ROM update
Change-Id: I7438823b8d7ad0972649d2bf491d0f6fe423bc99
