يمكن حزم Automatic Ripping Machine (ARM) وتشغيلها كتطبيق Docker، لكن هذا لا يعني أن نسخ الأقراص الضوئية سيعمل بصورة صحيحة على ZimaOS. وقد وصلت سلسلة مجتمع IceWhale في يناير 2026 إلى هذا التمييز بالضبط: فـ ARM نفسها تعمل داخل حاوية، لكن نسخ الأقراص المضغوطة وأقراص DVD وأقراص Blu-ray بشكل موثوق يتطلب وصولًا عميقًا على نحو غير معتاد إلى محرك الأقراص الضوئية وطبقة أجهزة Linux على المضيف.
لم تُنتج السلسلة إعدادًا مؤكدًا يعمل بالكامل لـ ARM على ZimaOS. وأفاد أحد المشاركين بأن ARM لم تكن تعمل بصورة صحيحة، وأن تطبيق نسخ آخر عبر Docker أنتج أخطاء تفيد بأن القرص غير قابل للقراءة. وكانت التوصية العملية من المجتمع هي إجراء النسخ على جهاز Linux ثانٍ وحفظ الملفات المكتملة على ZimaOS عبر SMB أو NFS. وتدعم وثائق ARM الحالية التشخيص التقني: إذ يتوقع إعدادها عبر Docker تمرير الأجهزة الضوئية، وأجهزة SCSI العامة، وتطابق UID/GID للمضيف، وفي بعض الإعدادات الوضع ذا الامتيازات والتكامل مع udev على المضيف.
لماذا لا يكفي تطبيق Docker عادي لنسخ الأقراص
تحتاج معظم تطبيقات NAS إلى منافذ الشبكة ووحدات تخزين البيانات فقط. أما النسخ من الأقراص الضوئية فمختلف، لأن برامج مثل MakeMKV وARM تحتاج إلى التواصل مباشرةً مع أجهزة محرك الأقراص.
تشمل الأجهزة الضوئية النموذجية في Linux ما يلي:
/dev/sr0
/dev/sg1الـ /dev/sr* يكشف الجهاز محرك الأقراص الضوئية، بينما الجهاز المطابق /dev/sg* قد يكون جهاز SCSI العام مطلوبًا لتنفيذ الأوامر منخفضة المستوى. وإذا لم تتلقَّ الحاوية سوى تركيب مجلد عادي، فلن تتمكن من تنفيذ تلك العمليات.
الأعراض المُبلّغ عنها في سلسلة ZimaOS
أفاد مستخدم من المجتمع بما يلي:
- ولم تعمل ARM بنجاح؛
- وكان تطبيق نسخ آخر يعمل عبر Docker لا يبدأ إلا ضمن إعدادات مقيّدة؛
- واجه syslog-ng مشكلات في المقبس/الأذونات؛
- ما أدى إلى ظهور أخطاء تفيد بأن القرص غير قابل للقراءة، حتى عندما كان يُعتقد أن القرص الفعلي سليم.
وأوضح رد آخر أن هذه الأعراض تتوافق مع وصول غير مكتمل إلى جهاز النسخ /dev/sr0، وتمرير SCSI، وأحداث udev، أو أذونات أخرى على مستوى المضيف.
تؤكد وثائق ARM الحالية متطلبات الأجهزة
تطلب وثائق ARM الحالية من المستخدمين فحص الأجهزة الضوئية باستخدام:
lsscsi -gقد يظهر محرك الأقراص على نحو مشابه لما يلي:
الأقراص المضغوطة/أقراص DVD ... /dev/sr0 /dev/sg1ثم توصي ARM بتمرير الجهازين إلى داخل الحاوية:
--device="/dev/sr0:/dev/sr0"
--device="/dev/sg1:/dev/sg1"راجع وثائق ARM الحالية لـ Docker.
قد تحتاج ARM أيضًا إلى الوصول إلى الحاوية ذات الامتيازات
يتضمن الدليل الحالي لـ ARM لبنائه من المصدر باستخدام Docker ما يلي:
--privilegedوتذكر وثائق استكشاف الأخطاء وإصلاحها أن بعض المستخدمين يحتاجون إلى الوضع ذي الامتيازات لكي يعمل إدخال الأقراص والنسخ باستخدام udev بشكل كامل.
وهذا اختلاف رئيسي عن حاويات خوادم الوسائط العادية. يمنح الوضع المميّز الحاوية إمكانات واسعة للوصول إلى أجهزة المضيف، ولذلك لا ينبغي تفعيله بلا تفكير على صورة غير موثوقة.
تعتمد أتمتة إدخال الأقراص على المضيف
صُمّم ARM للاستجابة تلقائيًا عند إدخال قرص. وتتوقع وثائق Docker الخاصة به إعداد محرك الأقراص على جانب المضيف وسلوك udev بحيث يؤدي الإدخال إلى تشغيل سير عمل النسخ.
يقترح دليل استكشاف أخطاء ARM وإصلاحها التحقق من سجلات المضيف بحثًا عن حدث إدخال القرص، ويؤكد أن الحاوية قد تكون سليمة بينما لا يزال النسخ التلقائي يفشل إذا لم يكن تكامل udev مع المضيف يعمل.
المرجع الحالي: استكشاف أخطاء ARM في Docker وإصلاحها.
لماذا قد يفشل MakeMKV حتى عندما يرى ARM محرك الأقراص
تحذّر وثائق ARM تحديدًا من أن MakeMKV قد يفشل في اكتشاف محرك أقراص أو قراءته إذا تم تمرير /dev/sr0 تم تمريره، وتم إغفال جهاز SCSI العام المطابق.
وهذا يجعل عَرَض «القرص غير قابل للقراءة» من نقاش ZimaOS مهمًا بصفة خاصة. فكون محرك الأقراص البصري قابلًا للقراءة على المضيف لا يثبت أن الحاوية تملك جميع واجهات الأجهزة التي يحتاج إليها MakeMKV.
يتطلب ARM أيضًا تطابق أذونات المضيف
توصي وثائق ARM الحالية بإنشاء arm المستخدم/المجموعة على المضيف ومواءمة:
معرّف مستخدم ARM
معرّف مجموعة ARMمع حساب المضيف ذلك. يجب أن تكون أدلة الوسائط والإعدادات والموسيقى والسجلات قابلة للكتابة بواسطة تلك الهوية.
إذا لم تتطابق المعرّفات، فقد يفشل ARM قبل أن تصل عملية النسخ أصلًا إلى محرك الأقراص البصري.
ما يؤكده موضوع المصدر فعليًا عن ZimaOS
لا يؤكد نقاش المصدر أن ARM مستحيل على ZimaOS إلى الأبد. بل يؤكد أن المشاركين في يناير 2026 لم تكن لديهم تهيئة مُتحقَّق منها تُتيح بنجاح جميع امتيازات محرك الأقراص البصري المطلوبة.
رأى أحد الردود أن القيد الرئيسي يتمثل في مستوى الوصول إلى العتاد/الأجهزة المتاح للحاوية. وقد وافق المؤلف الأصلي على الحل العملي المتمثل في استخدام جهاز ثانٍ للنسخ.
لا تحوّل هذه النتيجة إلى ادعاء شامل بأن Docker لا يستطيع نسخ الأقراص أو أن ZimaOS لن يدعم ARM أبدًا.
الحل العملي للمجتمع
كانت الخطة النهائية التي وافق عليها المؤلف الأصلي هي:
- ثبّت ARM على جهاز Linux آخر لديه وصول مباشر إلى محرك الأقراص البصري.
- انسخ القرص وحوّله هناك.
- احفظ الملفات المكتملة أو انقلها إلى مساحة تخزين ZimaOS.
يمكن أن تكون الوجهة مشاركة SMB أو NFS مُثبّتة، أو يمكن نقل الملفات بعد النسخ.
يُبقي هذا ZimaOS مُركّزًا على التخزين وتقديم الوسائط، بينما يتولى الجهاز الثاني التعامل مع العتاد البصري منخفض المستوى.
يدعم ARM رسميًا سير عمل الإخراج المعتمد على الشبكة
تشير وثائق Docker الخاصة بـ ARM إلى إمكانية توجيه وحدات تخزين الإخراج إلى مشاركات الشبكة، مع اعتماد الأداء على الشبكة وسلوك نقاط التحميل.
من البنى الشائعة:
محرك أقراص ضوئية
↓
جهاز ARM يعمل بنظام Linux
↓
مساحة تخزين محلية مؤقتة للعمل
↓
استخراج مكتمل
↓
مكتبة وسائط ZimaOS عبر SMB/NFSيمكن أن يؤدي استخدام مساحة تخزين محلية سريعة ومؤقتة لمرحلة الاستخراج/تحويل الترميز ونقل الناتج المكتمل فقط إلى وحدة NAS إلى تقليل مشكلات الشبكة والقفل.
إذا كنت لا تزال تريد اختبار ARM مباشرةً على ZimaOS
قبل محاولة إنشاء تطبيق مخصّص، اجمع معلومات أجهزة المضيف:
lsscsi -g
ls -l /dev/sr*
ls -l /dev/sg*ثم تحقّق مما إذا كان تكوين Docker المخصّص في ZimaOS يستطيع تمثيل جميع المتطلبات التي توثقها ARM:
- الضوئي
/dev/sr*جهاز. - المطابق
/dev/sg*جهاز. - الصلاحيات المطلوبة للمضيف/الحاوية؛
- وحدات تخزين دائمة للإعدادات والسجلات والموسيقى والوسائط؛
- الوضع المميّز أو إمكانات مكافئة إذا لزم الأمر؛
- سير عمل الأحداث/udev على جانب المضيف المستخدم للاستخراج التلقائي.
إذا لم يتمكن ZimaOS من إتاحة أحد هذه المتطلبات من خلال نموذج التطبيقات الحالي، فلن يؤدي تغيير مسارات وحدات تخزين Docker العادية إلى حل فشل الاستخراج.
ملاحظات حول الأمان والموثوقية
- تحصل الحاويات ذات الوضع المميّز على وصول واسع إلى المضيف. استخدم صوراً موثوقة فقط وافهم نطاق التعرض.
- لا تمرّر أجهزة مضيف غير مرتبطة إلى ARM.
- امنح ARM صلاحية الكتابة إلى الأدلة التي يحتاج إليها فقط.
- استخدم دليلاً مخصّصاً للعمل تتوفر فيه مساحة حرة كافية؛ فقد يتطلب استخراج الوسائط الضوئية وتحويل الترميز مساحة تخزين كبيرة مؤقتاً.
- انسخ الوسائط المكتملة احتياطياً بشكل مستقل عن سير عمل الاستخراج.
قائمة التحقق لتشغيل ARM على ZimaOS
- تأكد من ظهور محرك الأقراص الضوئية على مضيف ZimaOS.
- شغّل
lsscsi -gوحدّد كليهما/dev/sr*و/dev/sg*. - قارن إمكانات التطبيقات المخصّصة في ZimaOS بمتطلبات Docker الحالية لـ ARM.
- طابق ARM_UID/ARM_GID مع الأدلة القابلة للكتابة على المضيف.
- تحقق مما إذا كان الوضع المميّز وتكامل أحداث المضيف متاحين.
- لا تفترض أن ظهور واجهة ARM على الويب يعني أن MakeMKV لديه وصول صحيح إلى محرك الأقراص.
- إذا ظل تمرير الجهاز غير موثوق، فاستخدم جهاز استخراج منفصلاً وخزّن الناتج المكتمل على ZimaOS.
الأسئلة الشائعة حول Automatic Ripping Machine على ZimaOS
هل يمكن تثبيت ARM على ZimaOS؟
يمكن تشغيله داخل حاوية، لكن سلسلة النقاش الأصلية لم تؤكد إعداد استخراج يعمل بالكامل على ZimaOS، لأن تمرير محرك الأقراص الضوئية والصلاحيات كانا العائقين.
لماذا يقول برنامج الاستخراج إن القرص غير قابل للقراءة؟
قد يكون أحد الأسباب هو عدم اكتمال تمرير الجهاز. وتنص وثائق ARM الحالية على أن MakeMKV قد يتطلب كلاً من محرك الأقراص الضوئية /dev/sr* الجهاز وواجهة SCSI العامة المطابقة /dev/sg* جهاز.
هل يتطلب ARM الوضع المميّز؟
تتضمن وثائق Docker الحالية لـ ARM الوضع المميّز ضمن إرشادات الإعداد واستكشاف الأخطاء وإصلاحها لبعض التكوينات. ويعتمد احتياج كل عملية تثبيت إليه على المضيف وسير عمل الجهاز.
ما الحل المقبول في سلسلة النقاش الأصلية؟
اختار المؤلف الأصلي تثبيت ARM على جهاز ثانٍ ونقل الملفات المستخرجة إلى وحدة تخزين على خادم ZimaOS.
