चेरी-निम्नलिखित ज्ञात समस्याओं के समाधान के लिए निम्नलिखित पैच चुनें।
साइडलोड करते समय आवंटन योग्य स्थान को सही ढंग से जांचें
वर्चुअल ए/बी डिवाइस पर एक पूर्ण ओटीए पैकेज को साइडलोड करना जिसमें *2 * योग (अद्यतन समूहों का आकार)* से छोटे आकार वाला एक सुपर विभाजन है, पुनर्प्राप्ति लॉग /tmp/recovery.log
में निम्नलिखित के साथ विफल हो सकता है:
The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...
यहाँ लॉग का एक उदाहरण है:
[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.
यदि आप इस समस्या का सामना करते हैं, तो चेरी सीएल 1399393 चुनें, बूट पार्टीशन या रिकवरी पार्टीशन को फिर से बनाएं और फ्लैश करें, यदि डिवाइस बूट के रूप में रिकवरी का उपयोग नहीं करता है।
मर्ज के दौरान विभाजन दोष को ठीक करें
OTA अपडेट लागू करने के बाद, VAB मर्ज प्रक्रिया के दौरान, update_engine_client --cancel
पर कॉल करने से CleanupPreviousUpdateAction
क्रैश हो जाता है। जब markSlotSuccessful
देर से आता है तो एक संभावित वाइल्ड पॉइंटर त्रुटि भी मौजूद होती है।
इसे StopActionInternal
फ़ंक्शन जोड़कर हल किया गया था। CleanupPreviousUpdateAction
नष्ट होने पर लंबित कार्यों को रद्द कर देता है। यह एक वेरिएबल बनाए रखता है जो संदेश लूप में लंबित कार्य की कार्य आईडी को ट्रैक करता है। नष्ट होने पर, सेगफॉल्ट से बचने के लिए लंबित कार्य रद्द कर दिया जाता है।
सुनिश्चित करें कि मर्ज के दौरान update_engine
में SIGSEGV
क्रैश को ठीक करने के लिए आपके Android 11 स्रोत ट्री में निम्नलिखित परिवर्तन हैं:
- सीएल 1439792 (सीएल 1439372 के लिए एक शर्त)
- सीएल 1439372 (
CleanupPreviousUpdateAction
: नष्ट होने पर लंबित कार्यों को रद्द करें) - सीएल 1663460 (
markSlotSuccessful
देर से आने पर संभावित वाइल्ड पॉइंटर त्रुटि को ठीक करें)
VAB गलत स्लॉट-स्विचिंग को ठीक करें, OTA अपडेट पोस्ट करें
एंड्रॉइड 11 और उच्चतर में, ओटीए अपडेट के बाद डिवाइस में स्लॉट-स्विच को सिंक्रोनाइज़ करने में विफलता डिवाइस को अनुपयोगी स्थिति में डाल सकती है। यदि आपका IBootControl
HAL का स्लॉट-स्विचिंग कार्यान्वयन राइट्स निष्पादित करता है, तो आपको उन राइट्स को तुरंत फ्लश करना होगा। यदि राइट्स को फ्लश नहीं किया जाता है, और मर्ज शुरू होने के बाद डिवाइस रीबूट होता है, लेकिन इससे पहले कि हार्डवेयर स्लॉट-स्विच राइट को फ्लश कर सके, डिवाइस पिछले स्लॉट पर वापस आ सकता है और बूट करने में विफल हो सकता है।
उदाहरण कोड समाधान के लिए, यह सीएल देखें: सीएल 1535570 ।
update_engine समयपूर्व विलय को रोकें
जब कोई डिवाइस बूट होता है (एंड्रॉइड 11 और उच्चतर), और बूट पूरा हो जाता है, तो update_engine
ScheduleWaitMarkBootSuccessful()
और WaitForMergeOrSchedule()
को कॉल करता है। इससे मर्ज प्रक्रिया प्रारंभ हो जाती है. हालाँकि, डिवाइस पुराने स्लॉट पर रीबूट हो जाता है। क्योंकि मर्ज पहले ही शुरू हो चुका है, डिवाइस बूट होने में विफल रहता है और निष्क्रिय हो जाता है।
अपने स्रोत ट्री में निम्नलिखित परिवर्तन जोड़ें। ध्यान दें कि सीएल 1664859 वैकल्पिक है।
- सीएल 1439792 (सीएल 1439372 के लिए एक शर्त)
- सीएल 1439372 (
CleanupPreviousUpdateAction
: नष्ट होने पर लंबित कार्यों को रद्द करें) - सीएल 1663460 (
markSlotSuccessful
देर से आने पर संभावित वाइल्ड पॉइंटर त्रुटि को ठीक करें) - सीएल 1664859 (वैकल्पिक -
CleanupPreviousUpdateAction
के लिएunittest
जोड़ें)
छोड़े गए मेटाडेटा के कारण डेटा हानि या भ्रष्टाचार को रोकें
एंड्रॉइड 11 और उच्चतर में, यदि किसी स्टोरेज डिवाइस में अस्थिर राइट-बैक कैश है, तो कुछ शर्तों के तहत, पूर्ण मर्ज का मेटाडेटा छोड़ दिया जाता है, जिसके परिणामस्वरूप डेटा हानि या भ्रष्टाचार होता है।
स्थितियाँ:
- अपवादों के एक सेट का मर्ज ऑपरेशन पूरा करने के बाद,
merge_callback()
लागू किया गया था। - मेटाडेटा को COW डिवाइस में अपडेट किया गया था जो मर्ज पूरा होने को ट्रैक करता है। (COW डिवाइस के लिए यह अपडेट साफ़-साफ़ फ्लश किया गया है।)
परिणाम: हालिया मर्ज के स्टोरेज डिवाइस का कैश फ्लश नहीं होने के कारण सिस्टम क्रैश हो गया।
किसी संकल्प को लागू करने के लिए निम्नलिखित देखें:
सही डीएम-वेरिटी कॉन्फ़िगरेशन सुनिश्चित करें
Android 11 और उच्चतर में, डिवाइस को अनजाने में निम्नलिखित dm-verity विकल्पों के साथ कॉन्फ़िगर किया जा सकता है:
- कर्नेल में
CONFIG_DM_VERITY_AVB=y
- बूटलोडर को
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
के बिना, किसी भी सत्यता मोड (जैसेAVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE
) का उपयोग करने के लिए कॉन्फ़िगर किया गया है।
इस डिवाइस कॉन्फ़िगरेशन के साथ, किसी भी सत्यता त्रुटि के कारण vbmeta विभाजन दूषित हो जाता है, और गैर-ए/बी डिवाइस निष्क्रिय हो जाता है। इसी तरह, यदि कोई मर्ज शुरू हो गया है, तो ए/बी डिवाइस भी निष्क्रिय हो सकते हैं। केवल AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
सत्यता मोड का उपयोग करें।
- कर्नेल में
CONFIG_DM_VERITY_AVB=n
सेट करें - इसके बजाय
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO
मोड का उपयोग करने के लिए डिवाइस कॉन्फ़िगर करें।
अधिक जानकारी के लिए, और अभ्यास के तौर पर, सत्यता दस्तावेज़ का संदर्भ लें: Handling dm-verity Errors ।
आपातकालीन सिस्टम शटडाउन के दौरान I/O त्रुटि के जवाब में सत्यता कार्य छोड़ें
एंड्रॉइड 11 और उच्चतर में, यदि एक आपातकालीन सिस्टम शटडाउन कहा जाता है (जैसा कि थर्मल शटडाउन के मामले में), एक डीएम डिवाइस सक्रिय हो सकता है जबकि ब्लॉक डिवाइस अब I/O अनुरोधों को संसाधित नहीं कर सकता है। इस स्थिति में, नए dm I/O अनुरोधों द्वारा, या पहले से ही उड़ान में मौजूद I/O त्रुटियों को संभाले जाने से वास्तविक भ्रष्टाचार की स्थिति पैदा हो सकती है, जो एक गलत निर्णय है।
जब सिस्टम बंद हो रहा हो तो I/O त्रुटि के जवाब में सत्यता कार्य को छोड़ने के लिए, निम्नलिखित का उपयोग करें:
सीएल 1847875 (शटडाउन के दौरान I/O त्रुटि के जवाब में सत्यता कार्य को छोड़ देता है)
सुनिश्चित करें कि DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED बंद है
4.19 कर्नेल या इससे पहले के संस्करण पर चलने वाले एंड्रॉइड गो डिवाइस में उनके कर्नेल कॉन्फ़िगरेशन में DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y
हो सकता है। यह सेटिंग वर्चुअल ए/बी के साथ संगत नहीं है, और जब दोनों को एक साथ सक्षम किया जाता है तो दुर्लभ पृष्ठ भ्रष्टाचार समस्याओं का कारण माना जाता है।
कर्नेल 4.19 और इससे पहले के संस्करण के लिए, कर्नेल कॉन्फ़िगरेशन में CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n
सेट करके इसे अक्षम करें।
कर्नेल 5.4 और बाद के संस्करण के लिए, कोड हटा दिया गया है और कॉन्फ़िगरेशन विकल्प उपलब्ध नहीं है।
पुष्टि करें कि मर्ज की गई फ़ाइल सही ढंग से कॉन्फ़िगर की गई है
यदि आप सिस्टम छवियां और विक्रेता छवियां अलग-अलग बना रहे हैं, तो उन्हें मर्ज करने के लिए merge_target_files
उपयोग कर रहे हैं, मर्ज प्रक्रिया के दौरान वर्चुअल ए/बी कॉन्फ़िगरेशन गलत तरीके से छोड़ा जा सकता है। यह सत्यापित करने के लिए कि मर्ज किए गए लक्ष्य फ़ाइल में वर्चुअल ए/बी कॉन्फ़िगरेशन सही हैं, निम्नलिखित पैच लागू करें: सीएल 2084183 (डायनामिक विभाजन जानकारी में समान कुंजी/वैल जोड़े को मर्ज करें)
आवश्यक घटकों को अद्यतन करें
एंड्रॉइड 13 के अनुसार, snapuserd
विक्रेता रैमडिस्क से जेनेरिक रैमडिस्क में स्थानांतरित कर दिया गया है। यदि आपका डिवाइस एंड्रॉइड 13 में अपग्रेड हो रहा है, तो यह संभव है कि विक्रेता रैमडिस्क और जेनेरिक रैमडिस्क दोनों में snapuserd
की एक प्रति हो। इस स्थिति में, वर्चुअल A/B को snapuserd
की सिस्टम कॉपी की आवश्यकता होती है। यह सुनिश्चित करने के लिए कि snapuserd
की सही प्रतिलिपि मौजूद है, सीएल 2031243 लागू करें ( snapuserd
को फर्स्ट_स्टेज_रामडिस्क पर कॉपी करें)।