নিম্নলিখিত পরিচিত সমস্যাগুলি সমাধান করতে নিম্নলিখিত প্যাচগুলি বেছে নিন।
সাইডলোড করার সময় বরাদ্দ করা যায় এমন স্পেস সঠিকভাবে চেক করুন
ভার্চুয়াল A/B ডিভাইসে সম্পূর্ণ OTA প্যাকেজ সাইডলোড করার সময় সুপার পার্টিশনের সাইজ *২ * যোগফল(আপডেট গ্রুপের সাইজ)*-এর থেকে ছোট হলে,
রিকভারি লগ /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.
আপনি এই সমস্যার সম্মুখীন হলে, CL 1399393 বেছে নিন, আবার তৈরি করুন এবং বুট পার্টিশন বা রিকভারি পার্টিশন ফ্ল্যাশ করুন যদি ডিভাইসটি বুট হিসেবে রিকভারি ব্যবহার না করে।
মার্জ করার সময় সেগমেন্টেশন ফল্ট সংক্রান্ত সমস্যার সমাধান করা
OTA আপডেট প্রয়োগ করার পরে, VAB মার্জ করার প্রসেস চলাকালীন, update_engine_client --cancel-এ কল করলে CleanupPreviousUpdateAction ক্র্যাশ করে। markSlotSuccessful দেরিতে এলে, সম্ভাব্য ওয়াইল্ড পয়েন্টার সংক্রান্ত সমস্যাও দেখা দেয়।
StopActionInternal ফাংশন যোগ করে এই সমস্যার সমাধান করা হয়েছে।
CleanupPreviousUpdateAction ডেস্ট্রয় করার সময় বাকি থাকা টাস্ক বাতিল করে। এটি একটি
ভেরিয়েবল বজায় রাখে যা মেসেজ লুপে থাকা বাকি টাস্কের টাস্ক আইডি ট্র্যাক করে। সেগফল্ট এড়াতে, ডেস্ট্রয় করার সময় বাকি থাকা টাস্ক বাতিল করা হয়।
মার্জ করার সময় update_engine-এ SIGSEGV ক্র্যাশ সংক্রান্ত সমস্যার সমাধান করতে,
আপনার Android 11 সোর্স ট্রিতে নিম্নলিখিত পরিবর্তনগুলি করা হয়েছে কিনা তা নিশ্চিত করুন:
- CL 1439792 (a CL 1439372-এর পূর্বশর্ত)
- CL 1439372
(
CleanupPreviousUpdateAction: destroy করার সময় বাকি থাকা টাস্ক বাতিল করুন) - CL 1663460 (
markSlotSuccessfulদেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার সংক্রান্ত সমস্যা সমাধান করুন)
update_engine-এর অকাল মার্জ আটকান
কোনও ডিভাইস বুট করার সময় (Android 11 এবং তার পরবর্তী যেকোনও ভার্সন) এবং বুট করা সম্পূর্ণ হলে,
update_engine ScheduleWaitMarkBootSuccessful()-কে কল করে এবং
WaitForMergeOrSchedule()। এটি মার্জ করার প্রসেস শুরু করে। তবে, ডিভাইসটি
পুরনো স্লটে রিবুট হয়। মার্জ করার প্রসেস আগেই শুরু হয়ে যাওয়ায়, ডিভাইস বুট করতে
পারেনি এবং কাজ করা বন্ধ করে দিয়েছে।
আপনার সোর্স ট্রিতে নিম্নলিখিত পরিবর্তনগুলি যোগ করুন। মনে রাখবেন, CL 1664859 হল ঐচ্ছিক।
- CL 1439792 (a CL 1439372-এর পূর্বশর্ত)
- CL 1439372
(
CleanupPreviousUpdateAction: destroy করার সময় বাকি থাকা টাস্ক বাতিল করুন) - CL 1663460 (
markSlotSuccessfulদেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার সংক্রান্ত সমস্যার সমাধান করুন) - CL 1664859 (ঐচ্ছিক -
CleanupPreviousUpdateAction-এর জন্যunittestযোগ করুন)
সঠিক dm-verity কনফিগারেশন নিশ্চিত করুন
Android 11 ও এর পরের যেকোনও ভার্সনে, ডিভাইসগুলি ভুলবশত নিম্নলিখিত dm-verity বিকল্পের সাথে কনফিগার করা হতে পারে:
- কার্নেলে
CONFIG_DM_VERITY_AVB=y - যেকোনও ভেরিটি মোড ব্যবহার করার জন্য কনফিগার করা বুটলোডার, (যেমন
AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE), withoutAVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.
এই ডিভাইস কনফিগারেশনের সাথে, কোনও ভেরিটি সংক্রান্ত সমস্যা হলে vbmeta পার্টিশন
খারাপ হয়ে যায় এবং A/B নয় এমন ডিভাইস কাজ করে না। একইভাবে, মার্জ করার প্রসেস শুরু হয়ে গেলে, A/B ডিভাইসও কাজ করা বন্ধ করে দিতে পারে। শুধুমাত্র
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO ভেরিটি মোড ব্যবহার করুন।
- কার্নেলে
CONFIG_DM_VERITY_AVB=nসেট করুন। - পরিবর্তে
AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIOমোড ব্যবহার করার জন্য ডিভাইস কনফিগার করুন।
আরও তথ্যের জন্য, ভেরিটি ডকুমেন্টেশন দেখুন: dm-verity সমস্যা ম্যানেজ করা।
মার্জ করা ফাইলটি সঠিকভাবে কনফিগার করা হয়েছে কিনা তা কনফার্ম করুন
আপনি যদি সিস্টেম ইমেজ এবং ভেন্ডর ইমেজ আলাদাভাবে তৈরি করেন, তাহলে সেগুলিকে মার্জ করার জন্য
merge_target_files ব্যবহার করলে, মার্জ করার প্রসেস চলাকালীন ভার্চুয়াল A/B কনফিগারেশন
ভুলভাবে বাদ দেওয়া হতে পারে। মার্জ করা টার্গেট ফাইলে ভার্চুয়াল A/B
কনফিগারেশন সঠিক কিনা তা যাচাই করতে, নিম্নলিখিত
প্যাচ প্রয়োগ করুন: CL
2084183
(ডায়নামিক পার্টিশন তথ্যে অভিন্ন কী/ভ্যালু পেয়ার মার্জ করুন)
প্রয়োজনীয় কম্পোনেন্ট আপডেট করা
Android 13 ভার্সন অনুযায়ী, snapuserd ভেন্ডর র্যামডিস্ক থেকে জেনেরিক
র্যামডিস্কে সরানো হয়েছে। আপনার ডিভাইস Android 13-এ আপগ্রেড করা হলে, এটি সম্ভব যে ভেন্ডর র্যামডিস্ক এবং জেনেরিক র্যামডিস্ক,
উভয়তেই snapuserd-এর একটি কপি আছে। এই পরিস্থিতিতে, ভার্চুয়াল A/B-এর জন্য snapuserd-এর সিস্টেম কপি প্রয়োজন। snapuserd-এর সঠিক কপি
যথাযথ জায়গায় আছে কিনা তা নিশ্চিত করতে, CL
2031243
(first_stage_ramdisk-এ snapuserd কপি করুন) প্রয়োগ করুন।