فشل Magisk flash: شخّص boot image قبل مسح البيانات

الجهاز الذي لا يقلع بعد فلاش Magisk مشكلة تشخيص، وليس مشكلة إعادة ضبط. هناك ستة أمور شائعة تسببه، والعَرَض الذي رأيته يحصرها غالباً في سبب أو اثنين، ولا يُصلح مسح بياناتك أياً منها. اتبع جدول الاستبعاد أدناه قبل أن تفكر في أي إجراء مدمّر.

الأسباب الستة المحتملة

هذه أسباب محتملة وليست أحكاماً نهائية. قد ينطبق أكثر من سبب في آن واحد، ويعتمد السبب الفعلي على جهازك وبناء الـ firmware وما قمت بفلاشه.

1. صورة إقلاع من بناء خاطئ. جاءت الصورة من firmware لا يطابق المثبّت على الجهاز، ولو بمستوى تصحيح أمني واحد.
2. رقّعت القسم الخطأ. في بعض الأجهزة يوجد الـ ramdisk في boot وفي أخرى في init_boot. ترقيع القسم الخطأ ينتج جهازاً لا يقلع.
3. لم يُستوفَ شرط الإقلاع الموثّق أو vbmeta. رفضت سلسلة التحقق في الجهاز الصورة المعدّلة، أو أن حالة vbmeta لا تطابق ما جرى فلاشه.
4. البوتلودر مقفل أو أُعيد قفله. لا يحمّل البوتلودر المقفل صورة إقلاع معدّلة، والفلاش عليه ينتج أخطاءً خاصة به.
5. الـ slot الخطأ. في أجهزة A/B ذهبت الصورة إلى الـ slot غير النشط، أو تغيّر الـ slot النشط بين العمليات.
6. تعارض وحدة أو تعارض بعد الإقلاع. نجح الترقيع وأقلع الجهاز، ثم أسقطه شيء يعمل بعد الإقلاع.

لاحظ ما ليس في هذه القائمة: بيانات المستخدم. لا ينشأ أي من هذه الأسباب الستة في قسم البيانات، ولا يعالجه مسحه.

جدول استبعاد الأسباب

ابحث عن الصف الذي يطابق ما لاحظته فعلاً.

هذا الجدول يؤدي ما لا تستطيع قائمة حلول مرقّمة أداءه. فالعَرَض يضيّق الاحتمالات قبل أن تقضي ساعة مع السبب الخطأ.

مطابقة البناء بدقة

هذا هو السبب الأجدر بأكبر وقت، لأنه أسهل ما يمكن الخطأ فيه وأنت تظن أنك أصبت.

تُشتق صورة الإقلاع المرقّعة من بناء firmware محدد. المصدر الصحيح هو الـ firmware لرقم طرازك بالضبط ورقم البناء بالضبط، وهو يتضمن مستوى التصحيح الأمني. لا الطراز نفسه من منطقة أخرى، ولا رقم الإصدار نفسه من قبل شهر. بل البناء المثبّت حالياً على الجهاز بدقة.

أين يخطئ الناس:

• متغيرات الطراز. كثيراً ما يغطي الاسم التسويقي الواحد عدة متغيرات عتادية مختلفة بـ firmware مختلف. نسختا Snapdragon وExynos من الهاتف نفسه جهازان مختلفان لهذا الغرض. ومتغيرات شركات الاتصالات تختلف أيضاً.
• المنطقة. يختلف الـ firmware للطراز نفسه بحسب المنطقة، والصور غير قابلة للتبادل.
• انحراف البناء. تلقى الجهاز تحديثاً بعد تنزيل الـ firmware أو قبله. المهم هو رقم البناء على الجهاز.
• الملفات المعاد تغليفها. الصورة من موقع استضافة ملفات مجهولة المصدر. استخدم توزيع الشركة المصنّعة نفسها وتحقق من المجاميع الاختبارية حيث تُنشر.

افحص البناء المثبّت في Settings ضمن About phone قبل أن تنزّل أي شيء. وإذا كان الجهاز لا يقلع، فقد يظهر رقم البناء في شاشة البوتلودر أو وضع التنزيل. صوّرها.

يغطي دليل الأجهزة القابلة للروت لدينا أي متغيرات من أي طرازات لها مسارات روت تعمل، وأين تقع فخاخ المتغيرات.

boot.img وinit_boot.img غير قابلين للتبادل

هذه النقطة توقع حتى من نجح في الروت سابقاً، لأن القاعدة تغيّرت خلال تطور Android.

تصف وثائق Android Open Source Project التغيير مباشرة: الأجهزة التي أُطلقت بـ Android 13 لديها صورة init_boot جديدة تحتوي على الـ ramdisk العام، أما الأجهزة التي رُقّيت من Android 12 إلى Android 13 فتستخدم البنية نفسها التي كانت لديها في Android 12.

القاعدة العملية الناتجة:

الفخ أن جهازاً يعمل بـ Android 14 اليوم قد يكون في أي من الصفين بحسب ما شُحن به. إصدار Android المثبّت حالياً لا يخبرك أيهما ينطبق. المهم هو الإصدار الذي أُطلق به الجهاز.

تشرح وثائق تثبيت Magisk نفسها كيف تعرف ما ينطبق على جهازك، وتنبّه إلى وجود استثناءات في بعض العتاد. اقرأها لجهازك تحديداً بدلاً من الافتراض من إصدار Android المكتوب على العلبة.

الخطأ هنا ينتج فلاشاً يبدو سليماً وجهازاً لا يقلع، ولهذا بالذات يقع في أعلى قائمة الاستبعاد.

مسألة vbmeta

يفحص Android Verified Boot سلامة ما سيحمّله البوتلودر. لن تطابق صورة الإقلاع المعدّلة قيم التجزئة المتوقعة، ويعتمد رد فعل الجهاز على تنفيذ الشركة المصنّعة.

تتطلب بعض الأجهزة تعديل حالة التحقق لكي تقلع صورة معدّلة، وبعضها لا يتطلب. وفي بعض الأجهزة يفرض تغيير هذه الحالة مسح البيانات عند الإقلاع التالي كإجراء أمني. هذه السلوكيات خاصة بكل جهاز ولا تتسق بين الشركات، بل ولا بين طرازات الشركة الواحدة.

هذا التباين هو سبب أن هذا المقال لا يعطيك أمر vbmeta لتشغّله. فتشغيل علامات تحقق خاطئة على جهاز لا يحتاجها قد يكلفك بياناتك، وعدم تشغيل أي منها على جهاز يحتاجها ينتج حلقة الإقلاع التي تحاول إصلاحها. اعثر على المتطلب لطرازك بالضبط من وثائق الشركة المصنّعة أو من مصدر خاص بالجهاز قبل أن تلمسه.

تحذير من إجراء مدمّر: في بعض الأجهزة يؤدي فلاش vbmeta مع تعطيل التحقق إلى مسح كامل لبيانات المستخدم عند الإقلاع التالي. ولا رجعة فيه. تأكد من سلوك جهازك قبل تنفيذه.

العودة إلى حالة قابلة للإقلاع

إذا كان الجهاز في fastboot ولديك صورة الإقلاع الأصلية الصحيحة للبناء المثبّت، فإن استعادتها تعكس التغيير. هذه العملية تكتب في قسم boot فقط ولا تمس بيانات المستخدم.

المتطلبات بالترتيب:

1. يدخل الجهاز إلى fastboot ويكتشفه الحاسوب. وإلا فـابدأ من هنا.
2. لديك الصورة الأصلية غير المرقّعة للبناء المثبّت بدقة، من توزيع الشركة المصنّعة نفسها.
3. تعرف القسم الذي تنتمي إليه، وفق الجدول أعلاه.
4. تعرف أي slot نشط، إذا كان الجهاز يستخدم A/B.

إذا نقص أي منها، فتوقف واحصل على الجزء الناقص بدلاً من الارتجال. فلاش صورة صحيحة تقريباً على قسم صحيح تقريباً هو ما يحوّل حالة قابلة للإصلاح إلى حالة أسوأ.

عندما تكون المشكلة في الوحدة

إذا نجح الروت وعمل الجهاز بشكل طبيعي ولم يبدأ الدوران في حلقة إلا بعد تثبيت وحدة، فالتشخيص مباشر والحل لا يمس صورة الإقلاع إطلاقاً.

توفر أطر الروت طرقاً للإقلاع مع تعطيل الوحدات لتتمكن من إزالة الوحدة المسببة. تصف وثائق Magisk تسلسل ضغط مفاتيح أثناء الإقلاع يشغّل النظام مع تعطيل الوحدات. ويوثّق KernelSU مسار إنقاذ خاصاً به، يشمل تشغيل أداة سطر الأوامر الخاصة به من shell الاسترداد لعرض الوحدات أو تعطيلها أو إلغاء تثبيتها.

يستهدف كلا النهجين مجلد الوحدات ويتركان بيانات المستخدم دون مساس. استخدم الوثائق الحالية لحل الروت الذي ثبّتّه فعلاً، لأن هذا السلوك تغيّر عبر الإصدارات وقد تصف تعليمات المنتديات القديمة آلية لم تعد موجودة.

الوحدات التي تتدخل مبكراً في عملية الإقلاع، أو تستبدل مكونات النظام، أو تعدّل خصائص الجهاز، أخطر من غيرها. يغطي دليل وحدات Magisk لدينا الفئات التي لها سجل في مشاكل الإقلاع وما تفحصه قبل التثبيت.

ليست كل حالات الفشل قابلة للإصلاح

سأكون مباشراً بشأن الحدود، لأن بقية المقال متفائلة والحدود حقيقية:

• إذا قُفل البوتلودر وكانت صورة إقلاع معدّلة مفلوشة بالفعل، فقد يرفض الجهاز تحميل أي شيء وقد لا يقبل فلاشات جديدة أيضاً. قد يصعب حل هذه الحالة أو يستحيل دون أدوات الشركة المصنّعة.
• إذا انقطع الفلاش قبل اكتمال كتابة قسم، فالنتيجة تعتمد على أي قسم وإلى أي مدى وصلت الكتابة.
• إذا لم يعد الجهاز يدخل fastboot ولا يُكتشف في أي وضع، فأنت خارج نطاق هذا المقال. اقرأ soft brick مقابل hard brick لتحديد حالتك.
• إذا لم تعد الشركة المصنّعة توزّع الـ firmware الأصلي لبنائك بالضبط، فقد يتعذّر استعادة الصورة نفسها، وتشمل البدائل عادةً مسح البيانات.

لا ندّعي أن كل فلاش Magisk فاشل قابل للإصلاح. بعضها ليس كذلك، والأمانة أن نقول أيها قبل أن تنفق مالاً لتعرف.

الأسئلة الشائعة

هل يحذف فلاش صورة boot الأصلية بياناتي؟ فلاش قسم boot لا يمس قسم بيانات المستخدم. ما يحذف البيانات هو إعادة الضبط أو التهيئة أو علامة المسح أو تغيير حالة التحقق في الأجهزة التي تفرض فيها مسحاً. اقرأ العملية نفسها ولا تكتفِ بالتطمين.

هل أعيد فلاش الصورة المرقّعة وأحاول مجدداً؟ إعادة فلاش الصورة نفسها تعطي النتيجة نفسها. إذا كانت الصورة هي المشكلة فلا يفيد التكرار. غيّر شيئاً محدداً بناءً على جدول الاستبعاد ثم أعد المحاولة.

يقلع جهازي لكن Magisk يقول إنه غير مثبّت. يعني هذا عادةً أن الفلاش ذهب إلى الـ slot غير النشط، أو أن الجهاز أقلع من الـ slot الآخر. افحص أي slot نشط. وقد يعني أيضاً أن الترقيع طُبّق على القسم الخطأ، وهو ما يغطيه قسم boot مقابل init_boot.

هل أحتاج TWRP أو recovery مخصصاً لإصلاح هذا؟ ليس لاستعادة صورة الإقلاع، فهي عملية fastboot. يفيد الـ recovery المخصص في بعض سيناريوهات إزالة الوحدات، ويثير أسئلة توافق خاصة به على تخطيطات الأقسام الحديثة. يغطي دليل تثبيت TWRP لدينا أين يناسب وأين لا يناسب.

هل هذا خاص بـ Magisk؟ لا. صور البناء الخاطئ والالتباس في الأقسام ومتطلبات التحقق وعدم تطابق الـ slot تنطبق على أي تعديل لصورة الإقلاع. تواجه تثبيتات KernelSU وAPatch الفئات نفسها من الفشل بالمنطق التشخيصي نفسه، وتختلف الطرق الثلاث بما يستحق الفهم قبل أن تختار.

هل أعيد ضبط المصنع وأبدأ من جديد؟ ليس كخطوة أولى. لا ينشأ أي من الأسباب الستة في قسم البيانات، فمن غير المرجح أن تعالج إعادة الضبط أياً منها. وهي لا رجعة فيها، وعلى الأجهزة التي تستخدم التشفير على مستوى الملفات تدمّر المادة التشفيرية للمفاتيح مع البيانات. ابدأ بالجدول أولاً.

---

قراءة ذات صلة: إصلاح حلقة الإقلاع دون فقدان البيانات · ماذا يعني كل عَرَض في شاشة الإقلاع · soft brick مقابل hard brick · جهاز fastboot غير مكتشف · وحدات Magisk الأساسية

المصادر: Android Open Source Project، وثائق قسم الإقلاع العام. وثائق تثبيت Magisk الرسمية. وثائق إنقاذ KernelSU الرسمية.

آخر تحقق: 24 أغسطس 2026. تختلف تخطيطات الأقسام ومتطلبات الإقلاع الموثّق وإجراءات الفلاش بحسب الشركة المصنّعة والطراز والبناء. تأكد من الوثائق الرسمية لجهازك قبل تنفيذ أي أمر.