ভার্চুয়াল A/B - প্যাচ প্রয়োগ করুন

চেরি-নিম্নলিখিত জ্ঞাত সমস্যা সমাধানের জন্য নিম্নলিখিত প্যাচগুলি বেছে নিন।

সাইডলোড করার সময় বরাদ্দযোগ্য স্থান সঠিকভাবে পরীক্ষা করুন

একটি ভার্চুয়াল A/B ডিভাইসে একটি সম্পূর্ণ OTA প্যাকেজ সাইডলোড করা যাতে *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.

আপনি যদি এই সমস্যার সম্মুখীন হন, চেরি পিক CL 1399393 , পুনঃনির্মাণ করুন এবং বুট পার্টিশন বা রিকভারি পার্টিশন ফ্ল্যাশ করুন যদি ডিভাইসটি বুট হিসাবে পুনরুদ্ধার ব্যবহার না করে।

মার্জ করার সময় সেগমেন্টেশন ফল্ট ঠিক করুন

একটি OTA আপডেট প্রয়োগ করার পরে, VAB মার্জ প্রক্রিয়া চলাকালীন, update_engine_client --cancel এ একটি কল CleanupPreviousUpdateAction ক্র্যাশ করে। markSlotSuccessful দেরিতে আসলে একটি সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটিও বিদ্যমান।

StopActionInternal ফাংশন যোগ করে এটি সমাধান করা হয়েছে। CleanupPreviousUpdateAction ধ্বংসের মুলতুবি কাজগুলি বাতিল করে। এটি একটি ভেরিয়েবল বজায় রাখে যা বার্তা লুপে মুলতুবি থাকা টাস্কের টাস্ক আইডি ট্র্যাক করে। ধ্বংস করার সময়, সেগফল্ট এড়াতে মুলতুবি কাজটি বাতিল করা হয়।

মার্জ করার সময় update_engineSIGSEGV ক্র্যাশগুলি ঠিক করতে আপনার Android 11 সোর্স ট্রিতে নিম্নলিখিত পরিবর্তনগুলি রয়েছে তা নিশ্চিত করুন:

  • CL 1439792 (CL 1439372 এর পূর্বশর্ত)
  • CL 1439372 ( CleanupPreviousUpdateAction : ধ্বংসের মুলতুবি কাজগুলি বাতিল করুন)
  • CL 1663460 ( markSlotSuccessful দেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটি ঠিক করুন)

VAB ভুল স্লট-সুইচিং ঠিক করুন, OTA আপডেট পোস্ট করুন

অ্যান্ড্রয়েড 11 এবং উচ্চতর সংস্করণে, একটি OTA আপডেটের পরে একটি ডিভাইসে একটি স্লট-সুইচ সিঙ্ক্রোনাইজ করতে ব্যর্থ হলে একটি ডিভাইস একটি অব্যবহারযোগ্য অবস্থায় ফেলে দিতে পারে। যদি আপনার IBootControl HAL-এর স্লট-সুইচিং ইমপ্লিমেন্টেশন রাইটগুলি সম্পাদন করে, তাহলে আপনাকে অবশ্যই সেই লেখাগুলিকে অবিলম্বে ফ্লাশ করতে হবে। যদি রাইটগুলি ফ্লাশ না করা হয়, এবং মার্জ শুরু হওয়ার পরে ডিভাইসটি রিবুট হয়, কিন্তু হার্ডওয়্যার স্লট-সুইচ লেখাটি ফ্লাশ করার আগে, ডিভাইসটি আগের স্লটে ফিরে যেতে পারে এবং বুট করতে ব্যর্থ হতে পারে৷

একটি উদাহরণ কোড সমাধানের জন্য, এই CL দেখুন: CL 1535570

আপডেট_ইঞ্জিন অকাল মার্জ প্রতিরোধ করুন

যখন একটি ডিভাইস বুট হয় (Android 11 এবং উচ্চতর), এবং বুট সম্পূর্ণ হয়, update_engine কল করে ScheduleWaitMarkBootSuccessful() , এবং WaitForMergeOrSchedule() । এটি মার্জ প্রক্রিয়া শুরু করে। যাইহোক, ডিভাইসটি পুরানো স্লটে রিবুট হয়। যেহেতু মার্জ ইতিমধ্যেই শুরু হয়েছে, ডিভাইসটি বুট করতে ব্যর্থ হয় এবং অকার্যকর হয়ে যায়।

আপনার উৎস গাছে নিম্নলিখিত পরিবর্তন যোগ করুন। মনে রাখবেন যে CL 1664859 ঐচ্ছিক।

  • CL 1439792 (CL 1439372 এর পূর্বশর্ত)
  • CL 1439372 ( CleanupPreviousUpdateAction : ধ্বংসের মুলতুবি কাজগুলি বাতিল করুন)
  • CL 1663460 ( markSlotSuccessful দেরিতে এলে সম্ভাব্য ওয়াইল্ড পয়েন্টার ত্রুটি ঠিক করুন)
  • CL 1664859 (ঐচ্ছিক - CleanupPreviousUpdateAction এর জন্য unittest যোগ করুন)

এড়িয়ে যাওয়া মেটাডেটার কারণে ডেটা ক্ষতি বা দুর্নীতি প্রতিরোধ করুন

অ্যান্ড্রয়েড 11 এবং উচ্চতর সংস্করণে, যদি একটি স্টোরেজ ডিভাইসে একটি উদ্বায়ী রাইট-ব্যাক ক্যাশে থাকে, তবে নির্দিষ্ট শর্তে, একটি সম্পূর্ণ মার্জের মেটাডেটা এড়িয়ে যায়, যার ফলে ডেটা ক্ষতি বা দুর্নীতি হয়।

শর্তাবলী:

  1. ব্যতিক্রমগুলির একটি সেটের একটি মার্জ অপারেশন শেষ করার পরে, merge_callback() আহ্বান করা হয়েছিল।
  2. মেটাডেটা COW ডিভাইসে আপডেট করা হয়েছে যা মার্জ সমাপ্তি ট্র্যাক করে। (কাউ ডিভাইসের এই আপডেটটি পরিষ্কারভাবে ফ্লাশ করা হয়েছে।)

ফলাফল: সাম্প্রতিক একত্রীকরণের স্টোরেজ ডিভাইসের ক্যাশে ফ্লাশ না হওয়ার কারণে সিস্টেমটি ক্র্যাশ হয়েছে৷

একটি রেজোলিউশন বাস্তবায়ন করতে নিম্নলিখিত দেখুন:

সঠিক dm-verity কনফিগারেশন নিশ্চিত করুন

অ্যান্ড্রয়েড 11 এবং উচ্চতর, ডিভাইসগুলি অসাবধানতাবশত নিম্নলিখিত dm-verity বিকল্পগুলির সাথে কনফিগার করা যেতে পারে:

  • কার্নেলে CONFIG_DM_VERITY_AVB=y
  • বুটলোডার AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO ছাড়া যেকোন সত্যতা মোড, (যেমন AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ) ব্যবহার করার জন্য কনফিগার করা হয়েছে।

এই ডিভাইস কনফিগারেশনের সাথে, যেকোন সত্যতা ত্রুটির কারণে vbmeta পার্টিশনটি নষ্ট হয়ে যায় এবং নন-A/B ডিভাইসগুলিকে অকার্যকর করে তোলে। একইভাবে, যদি একটি মার্জ শুরু হয়, তাহলে A/B ডিভাইসগুলিও অকার্যকর হয়ে যেতে পারে। শুধুমাত্র AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO সত্যতা মোড ব্যবহার করুন৷

  1. কার্নেলে CONFIG_DM_VERITY_AVB=n সেট করুন
  2. পরিবর্তে AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO মোড ব্যবহার করতে ডিভাইসগুলি কনফিগার করুন৷

আরও তথ্যের জন্য, এবং অনুশীলনের বিষয় হিসাবে, যাচাই ডকুমেন্টেশন উল্লেখ করুন: dm-verity Errors হ্যান্ডলিং

জরুরী সিস্টেম শাটডাউনের সময় একটি I/O ত্রুটির প্রতিক্রিয়া হিসাবে সত্যতা কাজ এড়িয়ে যান

অ্যান্ড্রয়েড 11 এবং উচ্চতর ক্ষেত্রে, যদি একটি জরুরী সিস্টেম শাটডাউন বলা হয় (থার্মাল শাটডাউনের ক্ষেত্রে), একটি dm ডিভাইস জীবিত থাকতে পারে যখন ব্লক ডিভাইসটি আর I/O অনুরোধগুলি প্রক্রিয়া করতে পারে না। এই অবস্থায়, নতুন dm I/O অনুরোধ দ্বারা পরিচালিত I/O ত্রুটিগুলি, অথবা ইতিমধ্যেই ফ্লাইটে থাকা ব্যক্তিদের দ্বারা, একটি সত্য দুর্নীতির অবস্থার দিকে নিয়ে যেতে পারে, যা একটি ভুল বিচার।

সিস্টেমটি বন্ধ হওয়ার সময় একটি I/O ত্রুটির প্রতিক্রিয়া হিসাবে সত্যতা কাজ এড়িয়ে যেতে, নিম্নলিখিতগুলি ব্যবহার করুন:

CL 1847875 (শাটডাউনের সময় I/O ত্রুটির প্রতিক্রিয়া হিসাবে সত্যতা কাজ এড়িয়ে যায়)

DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED বন্ধ আছে তা নিশ্চিত করুন

4.19 কার্নেল বা তার আগের Android Go ডিভাইসগুলির কার্নেল কনফিগারেশনে DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y থাকতে পারে৷ এই সেটিংটি ভার্চুয়াল A/B এর সাথে সামঞ্জস্যপূর্ণ নয়, এবং উভয়ই একসাথে সক্ষম হলে বিরল পৃষ্ঠা দুর্নীতির সমস্যা সৃষ্টি করে বলে পরিচিত৷

কার্নেল 4.19 এবং তার আগের জন্য, কার্নেল কনফিগারেশনে CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n সেট করে এটি নিষ্ক্রিয় করুন।

কার্নেল 5.4 এবং পরবর্তীতে, কোডটি সরানো হয়েছে এবং কনফিগারেশন বিকল্পটি উপলব্ধ নেই।

মার্জ করা ফাইলটি সঠিকভাবে কনফিগার করা হয়েছে তা নিশ্চিত করুন

আপনি যদি আলাদাভাবে সিস্টেম ইমেজ এবং ভেন্ডর ইমেজ তৈরি করেন, তাহলে merge_target_files ব্যবহার করে সেগুলিকে একত্রিত করার জন্য, ভার্চুয়াল A/B কনফিগারেশনগুলি মার্জ প্রক্রিয়া চলাকালীন ভুলভাবে বাদ দেওয়া হতে পারে। মার্জ করা টার্গেট ফাইলে ভার্চুয়াল A/B কনফিগারেশন সঠিক কিনা তা যাচাই করতে, নিম্নলিখিত প্যাচগুলি প্রয়োগ করুন: CL 2084183 (ডাইনামিক পার্টিশন তথ্যে অভিন্ন কী/ভাল জোড়া মার্জ করুন)

প্রয়োজনীয় উপাদান আপডেট করুন

অ্যান্ড্রয়েড 13 অনুযায়ী, snapuserd ভেন্ডর রামডিস্ক থেকে জেনেরিক রামডিস্কে সরানো হয়েছে। যদি আপনার ডিভাইসটি Android 13-এ আপগ্রেড করা হয়, তাহলে এটা সম্ভব যে বিক্রেতা র‌্যামডিস্ক এবং জেনেরিক র‌্যামডিস্ক উভয়েই snapuserd একটি কপি রয়েছে। এই পরিস্থিতিতে, ভার্চুয়াল A/B-এর জন্য snapuserd এর সিস্টেম কপি প্রয়োজন। snapuserd এর সঠিক কপি জায়গায় আছে তা নিশ্চিত করতে, CL 2031243 ( snapuserd কপি first_stage_ramdisk) প্রয়োগ করুন।