הטמעת A/B וירטואלית - תיקונים

בחר את התיקונים הבאים כדי לטפל בבעיות הידועות הבאות.

בדוק את השטח הניתן להקצאה כראוי בעת העמסת צד

טעינת צד של חבילת OTA מלאה במכשיר וירטואלי A/B שיש לו מחיצת סופר בגודל הקטן מ-*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 מבטל משימות ממתינות בהשמדה. הוא שומר על משתנה שעוקב אחר מזהה המשימה של המשימה הממתינה בלולאת ההודעות. בהשמדה, המשימה הממתינה מבוטלת כדי למנוע תקלות בחלוקה.

ודא שהשינויים הבאים נמצאים בעץ המקור של Android 11 שלך כדי לתקן קריסות SIGSEGV ב- update_engine במהלך המיזוג:

  • CL 1439792 (תנאי מוקדם ל-CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : בטל משימות ממתינות בהשמדה)
  • CL 1663460 (תקן את שגיאת המצביע הפרוע הפוטנציאלית כאשר markSlotSuccessful מגיע באיחור)

תקן החלפת חריצים שגויה של VAB, פרסם עדכון OTA

באנדרואיד 11 ומעלה, אי סנכרון של מתג חריץ במכשיר לאחר עדכון OTA יכול להכניס את המכשיר למצב בלתי שמיש. אם יישום החלפת החריצים של IBootControl HAL שלך מבצע כתיבה, עליך לשטוף את הכתיבה הללו באופן מיידי. אם הכתיבה לא נשטפה, וההתקן יופעל מחדש לאחר תחילת המיזוג, אך לפני שהחומרה תוכל לשטוף את הכתיבה של מתג החריץ, ההתקן עלול לחזור לחריץ הקודם ולא לאתחל.

לדוגמא לפתרון קוד, הצג את CL זה: CL 1535570 .

מנע מיזוג מוקדם של update_engine

כאשר מכשיר מאתחל (אנדרואיד 11 ומעלה), והאתחול מסתיים, ה- update_engine קורא ל- ScheduleWaitMarkBootSuccessful() ול- WaitForMergeOrSchedule() . זה מתחיל את תהליך המיזוג. עם זאת, המכשיר מאתחל לחריץ הישן. מכיוון שהמיזוג כבר התחיל, המכשיר לא מצליח לאתחל והופך לבלתי ניתן להפעלה.

הוסף את השינויים הבאים לעץ המקור שלך. שים לב ש-CL 1664859 הוא אופציונלי.

  • CL 1439792 (תנאי מוקדם ל-CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : בטל משימות ממתינות בהשמדה)
  • CL 1663460 (תקן את שגיאת המצביע הפרוע הפוטנציאלית כאשר markSlotSuccessful מגיע באיחור)
  • CL 1664859 (אופציונלי - הוסף unittest עבור CleanupPreviousUpdateAction )

מנע אובדן או השחתה של נתונים עקב מטא נתונים שדילג

באנדרואיד 11 ומעלה, אם למכשיר אחסון יש מטמון כתיבה לאחור נדיף, בתנאים מסוימים, מדלגים על המטא נתונים של מיזוג שהושלם, וכתוצאה מכך לאובדן נתונים או השחתה.

תנאים:

  1. לאחר סיום פעולת מיזוג של קבוצה אחת של חריגים, merge_callback() הופעל.
  2. המטא נתונים עודכנו במכשיר COW שעוקב אחר השלמת המיזוג. (עדכון זה למכשיר COW נשטף בצורה נקייה.)

תוצאה: המערכת קרסה בגלל שהמטמון של התקן האחסון של המיזוג האחרון לא נשטף.

ראה את הדברים הבאים כדי ליישם החלטה:

ודא את תצורת dm-verity הנכונה

באנדרואיד 11 ומעלה, ניתן להגדיר מכשירים בטעות עם אפשרויות dm-verity הבאות:

  • CONFIG_DM_VERITY_AVB=y בליבה
  • טוען האתחול מוגדר להשתמש בכל מצב אמת, (כגון AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE ), ללא AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

עם תצורת התקן זו, כל שגיאת אמת גורמת למחיצת 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 .

דלג על עבודת אמת בתגובה לשגיאת קלט/פלט במהלך כיבוי מערכת חירום

באנדרואיד 11 ומעלה, אם נקראת כיבוי חירום של מערכת (כמו במקרה של כיבוי תרמי), מכשיר dm יכול להיות חי בזמן שהמכשיר החסום לא יכול יותר לעבד בקשות קלט/פלט. במצב זה, שגיאות קלט/פלט המטופלות על ידי בקשות קלט/פלט dm חדשות, או על ידי אלה שכבר נמצאות בטיסה, יכולות להוביל למצב של שחיתות אמיתית, שהיא שיקול דעת מוטעה.

כדי לדלג על עבודת אמת בתגובה לשגיאת קלט/פלט כאשר המערכת נכבית, השתמש בפעולות הבאות:

CL 1847875 (דילג על עבודת אמת בתגובה לשגיאת קלט/פלט במהלך כיבוי)

ודא ש-DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED כבוי

מכשירי Android Go המריצים את ליבת 4.19 או קודמים יותר עשויים להיות בעלי DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y בתצורת הליבה שלהם. הגדרה זו אינה תואמת ל-Virtual 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 (מזג זוגות מפתח/ערך זהים בפרטי מחיצה דינמית)

עדכן את הרכיבים הדרושים

החל מ-Android 13, snapuserd הועבר מ-ramdisk של הספק ל-ramdisk גנרי. אם המכשיר שלך משדרג ל-Android 13, ייתכן שה-ramdisk של הספק וה-ramdisk הגנרי מכילים עותק של snapuserd . במצב זה, Virtual A/B דורש את עותק המערכת של snapuserd . כדי להבטיח שהעותק הנכון של snapuserd נמצא במקום, החל את CL 2031243 (העתק snapuserd ל-first_stage_ramdisk).