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

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

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

התקנה ממקור לא ידוע של חבילת OTA מלאה במכשיר A/B וירטואלי מחיצה שגודלה קטן מ- *2 * amount(size of update groups)* עלולה להיכשל עם הפרטים הבאים ביומן השחזור /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, בנייה מחדש ו-Flash מחיצת האתחול או מחיצת השחזור אם המכשיר לא משתמש בשחזור בתור לאתחל.

תיקון שגיאת פילוח במהלך המיזוג

לאחר החלת עדכון OTA, במהלך מיזוג ה-VAB, מתבצעת קריאה אל update_engine_client --cancel גורם לקריסה של CleanupPreviousUpdateAction. א' שגיאה פוטנציאלית של המצביע הכללי קיימת גם כאשר markSlotSuccessful מגיע באיחור.

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

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

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

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

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

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

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

מוודאים שהתצורה הנכונה של dm-verity

ב-Android מגרסה 11 ואילך, אפשר להגדיר בטעות מכשירים עם אפשרויות dm-ver הבאות:

• CONFIG_DM_VERITY_AVB=y בליבה (kernel)
• תוכנת האתחול שהוגדרה לשימוש בכל מצב אימות (למשל 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 בליבה (kernel).
2. מגדירים את המכשירים לשימוש במקום זאת, מצב AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

מידע נוסף זמין במסמכי התיעוד בנושא verity: טיפול ב-dm-verity שגיאות.

מוודאים שהקובץ שמוזג מוגדר כראוי

אם אתם בונים תמונות מערכת ותמונות ספקים בנפרד, צריך להשתמש merge_target_files כדי למזג אותם, הגדרות של Virtual A/B עשויות להיות ירד באופן שגוי בתהליך המיזוג. כדי לאמת שמערכת ה-A/B הווירטואלית ההגדרות האישיות של קובץ היעד שמוזגו נכונות, צריך להחיל את תיקונים: CL 2084183 (מיזוג צמדי מפתח/ערך זהים בפרטי מחיצות דינמיות)

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

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