Issue #2229
open/data/system/applications.xml corruption at boot ?
0%
Updated by Denis 'GNUtoo' Carikli about 3 years ago
- Subject changed from /data/system/applications.xml corruption at boot to /data/system/applications.xml corruption at boot ?
I was running Replicant 6.0 0004 RC3 on a Galaxy SIII (GT-I9300). The exact image version was retrieved with getprop.
I was doing some experiments to write some clean reboot and power off scripts as my power button got damaged. I may also have removed the battery at early boot (I've a tendency to do that).
But at some point it stopped booting.
I then reinstalled Replicant 6.0 0004 RC3 and it still didn't boot.
I then started removing some applications I installed lately with rm -rf in /data (find -iname "*com.application.something" + rm -rf the resulting directories), and nothing changed.
I then looked at /data/system/ and I had that:
root@m0:/data/system # ls appops.xml inputmethod packages.xml batterystats-checkin.bin install_sessions packages.xmlNIfHGG batterystats-daily.xml job procstats batterystats.bin last-fstrim profiles.xml cache locksettings.db recent_images called_pre_boots.dat locksettings.db-shm recent_tasks code_cache locksettings.db-wal seapp_hash device_policies.xml ndebugsocket shared_prefs dockbatterystats.bin netpolicy.xml storage.xml dropbox netstats sync entropy.dat notification_log.db theme framework_atlas.config notification_log.db-journal uiderrors.txt hdcp2 notification_policy.xml usagestats heapdump package-usage.list users ifw packages.list
Bot packages.xmlNIfHGG and packages.xml were empty (in my previous test while developing the migration feature only one would be empty if something went wrong).
- sed didn't write if nothing needed to be changed
- It wound't change anything when reinstalling the same image.
If the corruption happened, something of my assumptions are wrong.
Updated by Denis 'GNUtoo' Carikli about 3 years ago
It seems that getting the keys for previous Replicant 6.0 releases is not an option.
So we need to make sure that it at least runs only once and covers all the situations.
If it could delete itself once it ran it would probably be good enough.
Updated by Denis 'GNUtoo' Carikli about 3 years ago
We also need to verify the key formats.
The short one might need == at the end.
Updated by Denis 'GNUtoo' Carikli about 3 years ago
I've some difficulties finding a very robust way to do the migration.
The idea would be to only run the script only once at the first boot right after the installation.
Unfortunately that might not be easy:- The script cannot be run in the recovery because if the user partition is encrypted, the installer or recovery cannot access /data/system/applications.xml
- init configuration files (like the /*.rc) have to be system files, and if I use some include for non existing paths it doesn't fail but:
- /etc/init.d/ scripts cannot delete system files (it ends up with selinux compilation issues due to neverallow)
- init (with *.rc files) cannot delete system files either (it also ends up with neverallow)
I'd really prefer to have something simple (like delete the file) than write some code to write the version in a file and only run if it differs as it would be more fragile (we have -dev images too and I keep loosing my data on those) and continue to run at each boot.
Updated by Denis 'GNUtoo' Carikli almost 3 years ago
It seems that using init .rc files would also be complicated.
In vendor/replicant with the following addition in prebuilt/common/etc/init.local.rc:
on post-fs
import /system/key-migration.rc
And the following prebuilt/common/key-migration.rc:
service gnutoo-test /system/bin/log -p i -t Replicant "Test GNUtoo"
oneshot
seclabel u:r:sudaemon:s0
disabled
on post-fs-data
start gnutoo-test
And the following (pseudo) patch:
diff --git a/config/common.mk b/config/common.mk
index 411a7567..3e56cb3c 100644
--- a/config/common.mk
+++ b/config/common.mk
@@ -236,6 +236,8 @@ endif
# test-keys migration script
PRODUCT_PACKAGES += \
key-migration.sh
+PRODUCT_COPY_FILES += \
+ vendor/replicant/prebuilt/common/key-migration.rc:system/key-migration.rc
DEVICE_PACKAGE_OVERLAYS += vendor/replicant/overlay/common
diff --git a/sepolicy/file_contexts b/sepolicy/file_contexts
index bcc9217c..f3a320d3 100644
--- a/sepolicy/file_contexts
+++ b/sepolicy/file_contexts
@@ -55,3 +55,6 @@
# bash
/system/xbin/bash u:object_r:shell_exec:s0
+
+#
+/system/key-migration.rc u:object_r:rootfs:s0
It doesn't boot anymore and init seems to kill process on its own.
So it's probably way easier to record the version data somehow but I really don't like that idea as it's way more error prone...
Updated by Denis 'GNUtoo' Carikli almost 3 years ago
I think we could use another approach: keep the code as-is and do 2 releases.
The installation procedure would be as follow:- Users would backup their contacts and install the first release which will do the key migration at boot.
- Then once done they can restore their contact and install the second release which will not do any automatic key migration anymore. The script will still be kept in case of issues.
Denis.