إن ظهور الخطأ apt: command not found في ZimaOS لا يعني أن sudo معطّل، بل يعني أن ZimaOS ليس Ubuntu أو Debian ولا يتضمن أسلوب إدارة الحزم عبر APT الذي تستخدمه تلك التوزيعات. كان المستخدم في المصدر من أكتوبر 2024 مسجّلًا بصلاحيات root ومتصلًا عبر ttydBridge، لكنه ظل غير قادر على تحديث حزم النظام المضيف أو تثبيتها، لأن هذه ليست الطريقة التي صُمّم بها ZimaOS.
توضح وثائق IceWhale الحالية البنية بشكل أكبر: يعتمد ZimaOS على Buildroot، ومعظم مجلدات النظام للقراءة فقط حتى عند تسجيل الدخول بصلاحيات root، ومن المفترض تشغيل التطبيقات عبر الحاويات بدلًا من تثبيتها داخل نظام التشغيل المضيف باستخدام apt أو yum أو أدوات مشابهة.
لم تكن المشكلة في sudo
اعتقد المستخدم الأصلي أن «أوامر sudo» تفشل لأن أوامر مثل sudo apt ... كانت تُرجع أخطاء تفيد بعدم العثور على الأمر.
يغيّر sudo سياق الصلاحيات فقط، ولا يمكنه إنشاء مدير حزم غير مثبّت في نظام التشغيل.
يعتمد ZimaOS على Buildroot
تصف أدلة IceWhale الحالية ZimaOS بأنه نظام Buildroot مخصص للأجهزة. ينشئ Buildroot صورة Linux مضمّنة ومضغوطة، وليس توزيعة عامة الغرض تتضمن قاعدة بيانات حزم قابلة للتعديل ومستودعات APT عادية.
لذلك تفشل غالبًا محاولات تطبيق أدلة إدارة الحزم الخاصة بـ Debian أو Ubuntu على مضيف ZimaOS، رغم توفر العديد من أوامر Linux المألوفة.
معظم مجلدات النظام للقراءة فقط عمدًا
توضح إرشادات سطر أوامر ZimaOS الحالية أن معظم مجلدات النظام تظل للقراءة فقط حتى عند تسجيل الدخول بصلاحيات root. ويجب وضع بيانات المستخدم والتطبيقات القابلة للكتابة ضمن /DATA.
استخدم نموذج نظام الملفات الحالي لسطر أوامر ZimaOS قبل محاولة تعديل نظام التشغيل الأساسي.
استخدم Docker لتطبيقات الخادم
إذا ذكر أحد الأدلة «ثبّت هذه الخدمة باستخدام apt»، فتحقق أولًا مما إذا كان للتطبيق نفسه صورة Docker مُصانة أو حزمة Compose. فهذا هو نموذج التطبيقات الأصلي في ZimaOS، كما أنه يفصل التبعيات عن المضيف غير القابل للتغيير.
وينطبق ذلك على خوادم الوسائط، وأدوات المراقبة، وقواعد البيانات، وعملاء VPN، ومنصات الأتمتة، وخدمات المستندات، والعديد من تطبيقات المختبرات المنزلية الأخرى.
استخدم ZVM عندما يتطلب البرنامج مضيف Debian أو Ubuntu كاملًا
تتوقع بعض التطبيقات وجود systemd أو مدير حزم أو وحدات نواة أو عدة خدمات على مستوى نظام التشغيل. في هذه الحالة، تكون آلة افتراضية تعمل بنظام Debian أو Ubuntu أنسب من محاولة إجبار مضيف ZimaOS على التصرف كأحدهما.
داخل الآلة الافتراضية، تعمل إدارة الحزم المعتادة عبر apt لأن نظام التشغيل الضيف هو فعليًا Debian أو Ubuntu.
لا يزال لـ SSH وttydBridge استخدام مهم
عدم دعم تثبيت الحزم لا يجعل سطر الأوامر عديم الفائدة. يظل SSH والطرفية عبر الويب مفيدين للفحص، وعرض السجلات، وتنفيذ أوامر Docker، وإدارة الملفات ضمن مساحة التخزين القابلة للكتابة، وإجراء عمليات استكشاف الأخطاء المتقدمة.
وتدعم إرشادات IceWhale الحالية كلاً من SSH والطرفية عبر المتصفح من خلال وضع المطوّر.
كانت مشكلة Jellyfin لدى المستخدم في المصدر غير مرتبطة بـ apt
ذكر صاحب المنشور الأصلي لاحقًا أن بعض مقاطع الفيديو تعمل في تطبيق الملفات لكنها لا تعمل في Jellyfin. وقد وجّهته ردود IceWhale والمجتمع إلى إعداد مسارات الوسائط في Docker.
وهذا هو الفصل الصحيح بين المشكلتين: يجب استكشاف مشكلة التشغيل أو المكتبة داخل Jellyfin من خلال تعيينات وحدات التخزين في التطبيق، وبرامج الترميز، والتحويل، والسجلات، وليس عبر تثبيت حزم عشوائية على المضيف باستخدام APT.
الأسئلة الشائعة حول apt في ZimaOS
هل يمكنني تثبيت apt على مضيف ZimaOS؟
لم يُصمَّم ZimaOS لإدارة الحزم عبر APT؛ لذا استخدم الحاويات أو آلة افتراضية بدلًا من التعامل مع المضيف على أنه Debian.
هل تجعل صلاحيات root مجلدات النظام قابلة للكتابة؟
لا. يتعمد ZimaOS الحالي إبقاء معظم مجلدات النظام للقراءة فقط حتى بالنسبة إلى root.
أين ينبغي أن أضع البرامج النصية المخصصة والملفات القابلة للكتابة؟
استخدم موقعًا قابلًا للكتابة ضمن /DATA أو مسار تخزين بيانات مُدارًا آخر.
