mkosi(1)

الاسم
mkosi — بناء صور أنظمة تشغيل مخصصة

موجز
mkosi [خيارات...] init

mkosi [خيارات...] summary

mkosi [خيارات...] cat-config

mkosi [خيارات...] build [-- سطر الأوامر...]

mkosi [خيارات...] shell [-- سطر الأوامر...]

mkosi [خيارات...] boot [-- إعدادات nspawn...]

mkosi [خيارات...] vm [-- معاملات vmm...]

mkosi [خيارات...] ssh [-- سطر الأوامر...]

mkosi [خيارات...] journalctl [-- سطر الأوامر...]

mkosi [خيارات...] coredumpctl [-- سطر الأوامر...]

mkosi [خيارات...] sysupdate [-- إعدادات sysupdate...]

mkosi [خيارات...] box [-- سطر الأوامر...]

mkosi [خيارات...] dependencies [-- خيارات...]

mkosi [خيارات...] clean

mkosi [خيارات...] serve

mkosi [خيارات...] burn <الجهاز>

mkosi [خيارات...] bump

mkosi [خيارات...] genkey

mkosi [خيارات...] documentation [دليل]

mkosi [خيارات...] completion [صدفة]

mkosi [خيارات...] latest-snapshot

mkosi [خيارات...] help

الوصف
mkosi أداة لبناء صور أنظمة تشغيل مخصصة بسهولة. إنها غلاف متطور حول dnf و apt و pacman و zypper يمكنها توليد صور أقراص مع مجموعة من الميزات الإضافية.

  أفعال سطر الأوامر
تُعرف أفعال سطر الأوامر التالية:

init
    بدء صنو mkosi. هذه عملية تُنفذ لمرة واحدة تضبط ملفات تكوين مختلفة مطلوبة لتجربة مثالية. حاليًا، لا تُبدأ سوى إضافة tmpfiles.d لدليل خبيئة حزم mkosi للتأكد من تنظيف الملفات القديمة وغير المستخدمة آليًا.

summary
    يُظهر ملخصًا مقروءًا لجميع الخيارات المستخدمة لبناء الصور. سيحلل سطر الأوامر وملفات الضبط، لكنه سيكتفي بطباعة ما ضُبط ولن يبني أو يشغل أي شيء فعليًا.

cat-config
    يُخرج أسماء ومحتويات جميع ملفات الضبط المُحمّلة. يُحمّل mkosi مجموعة من الملفات من مواقع مختلفة وهذا الأمر يسهل معرفة ما ضُبط وأين ضُبط.

build
    بناء الصورة بناءً على الإعدادات الممرة في سطر الأوامر وفي ملفات التكوين. هذا الأمر هو المبدئي إذا لم يُحدد فعل. يمكن تمرير معطيات إلى سكريبتات البناء، إذا كانت معرفة. لتمرير خيارات إلى سكريبتات البناء، افصلها عن خيارات mkosi العادية باستخدام --.

shell
    هذا يبني الصورة إذا لم تُبنَ بعد، ثم يستدعي systemd-nspawn لتشغيل صدفة تفاعلية في الصورة. لا يتطلب هذا إقلاع النظام، فهو يشبه chroot محسنًا. يمكن تحديد سطر أوامر اختياري بعد الفعل shell، ليُستدعى بدلًا من الصدفة في الحاوية. لتمرير خيارات إضافية إلى nspawn، افصلها عن الخيارات العادية باستخدام --.

boot
    مشابه للفعل shell، ولكن بدلًا من إطلاق صدفة، فإنه يقلع systemd في الصورة باستخدام systemd-nspawn. يمكن تحديد معطيات إضافية بعد الفعل boot، والتي تُممر كـ سطر أوامر النواة إلى نظام البدء في الصورة. لتمرير خيارات إضافية إلى nspawn، افصلها عن الخيارات العادية باستخدام --.

vm  مشابه للفعل boot، ولكنه يستخدم مراقب الآلة الافتراضية المضبوط (المبدئي هو qemu) لإقلاع الصورة، أي بدلًا من افتراضية الحاويات، تُستخدم افتراضية الآلات الافتراضية. تعتمد كيفية تفسير معطيات سطر الأوامر الإضافية على مراقب الآلة الافتراضية المضبوط. انظر VirtualMachineMonitor= لمزيد من المعلومات. لتمرير خيارات إضافية إلى مراقب الآلة الافتراضية المضبوط، افصلها عن الخيارات العادية باستخدام --.

ssh عند بناء الصورة مع خيار Ssh=always أو إذا كانت خدمة sshd-vsock الخاصة بـ systemd تعمل في الآلة الافتراضية (systemd الإصدار 256 فأحدث)، يتصل هذا الأمر بآلة افتراضية مقلعة عبر SSH. تأكد من تشغيل mkosi ssh بنفس التكوين المستخدم في mkosi build بحيث تتوفر لديه المعلومات اللازمة للاتصال بالآلة الافتراضية التي تعمل عبر SSH. تحديدًا، يُستخدم مفتاح SSH الخاص من إعداد SshKey= للاتصال بالآلة الافتراضية. استخدم mkosi genkey لتوليد مفتاح وشهادة آليًا ليلتقطهما mkosi. أي معطيات ممرة بعد الفعل ssh تُممر كمعطيات لاستدعاء ssh. لتمرير خيارات إضافية، افصلها عن الخيارات العادية باستخدام --. للاتصال بحاوية، استخدم machinectl login أو machinectl shell.
    يمكن استخدام الخيار Machine= لإعطاء الآلة اسم مضيف مخصص عند إقلاعها، والذي يمكن استخدامه لاحقًا لولوج الصورة عبر ssh (مثال: mkosi --machine=mymachine vm يتبعه mkosi --machine=mymachine ssh).

journalctl
    يستخدم journalctl لمعاينة السجل (journal) داخل الصورة. تُلحق جميع المعطيات المحددة بعد الفعل journalctl والمفصولة بـ -- عن الخيارات العادية باستدعاء journalctl.

coredumpctl
    يستخدم coredumpctl للبحث عن ملفات إفراغ الذاكرة (coredumps) داخل الصورة. تُلحق جميع المعطيات المحددة بعد الفعل coredumpctl والمفصولة بـ -- عن الخيارات العادية باستدعاء coredumpctl.

sysupdate
    يستدعي systemd-sysupdate مع ضبط الخيار --transfer-source= على دليل المخرجات والخيار --definitions= على الدليل المضبوط بـ SysupdateDirectory=. تُمرر جميع المعطيات المحددة بعد الفعل sysupdate والمفصولة عن الخيارات العادية بـ -- مباشرة إلى systemd-sysupdate.

box تشغيل أوامر اعتباطية داخل نفس البيئة المستخدمة لتنفيذ أفعال أخرى مثل boot و shell و vm وغيرها. هذا يعني أن /usr سيُستبدل بـ /usr من شجرة الأدوات إذا كانت مستخدمة بينما يظل كل شيء آخر في مكانه. إذا لم يُوفر أمر، سيُنفذ $SHELL أو bash إذا لم يكن $SHELL مضبوطًا. لتمرير خيارات إضافية للأمر المعطى، افصلها عن الخيارات العادية بـ --.

clean
    إزالة نواتج البناء المولدة في بناء سابق. إذا دُمج مع -f، فإنه يزيل أيضًا صور خبيئة البناء المتزايد وشجرة الأدوات. إذا حُدد -f مرتين، فإنه يزيل أيضًا أي خبيئة حزم.

serve
    هذا يبني الصورة إذا لم تُبنَ بعد، ثم يقدم دليل المخرجات (أي عادةً mkosi.output/، انظر أدناه) عبر خادم HTTP صغير مدمج، ينصت على المنفذ 8081. ادمجه مع -f لإعادة بناء الصورة دون شروط قبل تقديمها. هذا الأمر مفيد لاختبار الحصول على صور أنظمة التشغيل عبر الشبكة، على سبيل المثال عبر machinectl pull-raw ... و machinectl pull-tar ....

burn <الجهاز>
    يبني هذا الصورة إذا لم تُبنَ بعد، ثم يكتبها في الجهاز الكتلي المحدد. تُكتب محتويات القسم كما هي، ولكن يٌصحح جدول أقسام GPT ليطابق حجم القطاع والقرص للوسيط المحدد.

bump
    يرفع إصدار الصورة من mkosi.version ويكتب سلسلة الإصدار الناتجة في mkosi.version. هذا مفيد لتنفيذ مخطط ترقيم إصدارات بسيط: في كل مرة يُستدعى فيها هذا الفعل، يُرفع الإصدار استعدادًا للبناء اللاحق. لاحظ أنه يمكن استخدام --auto-bump/-B لرفع الإصدار آليًا كجزء من عملية البناء. لا يُكتب الإصدار الجديد في mkosi.version إلا إذا نجح البناء في تلك الحالة.
    إذا كان mkosi.bump موجودًا، فسيُستدعى لتوليد الإصدار الجديد الذي سيُستخدم بدلًا من استخدام منطق mkosi الخاص.

genkey
    توليد زوج من مفاتيح الإقلاع الآمن (SecureBoot) للاستخدام مع خيارات SecureBootKey=/--secure-boot-key= و SecureBootCertificate=/--secure-boot-certificate=.

documentation
    عرض توثيق mkosi. إذا لم يُعطَ معطى، تُعرض صفحة دليل (man) mkosi، ولكن المعطيات mkosi و mkosi-initrd و initrd و mkosi-sandbox و sandbox و mkosi.news و news مدعومة وتعرض على التوالي صفحات الدليل لـ mkosi و mkosi-initrd و mkosi-sandbox وملف NEWS الخاص بـ mkosi.
    افتراضيًا سيحاول هذا الفعل عدة طرق لإخراج التوثيق، ولكن يمكن اختيار خيار محدد باستخدام خيار --doc-format. يُشجع حازمو التوزيعات على إضافة ملف mkosi.1 في دليل mkosi/resources لحزمة بايثون، إذا كان مفقودًا، بالإضافة إلى تثبيته في مسار البحث المناسب لصفحات الدليل. يمكن توليد صفحة الدليل من ملف ماركداون (markdown) mkosi/resources/man/mkosi.1.md مثلًا عبر pandoc -t man -s -o mkosi.1 mkosi.1.md.

completion
    توليد إكمال الصدفة للصدفة المعطاة كمعطى وطباعتها على المخرج القياسي. المعطيات bash و fish و zsh مفهومة.

dependencies
    يُخرج قائمة الحزم المطلوبة من قبل mkosi لبناء وإقلاع الصور.
    يمكن تمرير هذه القائمة مباشرة إلى مدير حزم لتثبيت الحزم. على سبيل المثال، إذا كان النظام المضيف يستخدم مدير الحزم dnf، فيمكن تثبيت الحزم كما يلي:

            mkosi dependencies | xargs -d '\n' dnf install
        افتراضيًا، لا تُعرض سوى الاعتماديات المطلوبة لبناء الصور باستخدام mkosi. يمكن تمكين تشكيلات شجرة أدوات إضافية لإخراج الحزم التي تنتمي لتلك التشكيلات أيضًا. على سبيل المثال، تشغيل mkosi dependencies -- --profile runtime سيخرج أيضًا الحزم في تشكيلة وقت التشغيل (runtime) بالإضافة إلى الحزم العادية. انظر توثيق ToolsTreeProfiles= للحصول على قائمة بالتشكيلات المتاحة.

latest-snapshot
    يُخرج أحدث لقطة متاحة في المرآة المضبوطة.
    هذا الفعل مفيد لرفع اللقطات آليًا من حين لآخر. لاحظ أن هذا الفعل يخرج فقط أحدث لقطة. الأمر متروك للمستدعِي للتأكد من كتابة اللقطة في ملف التكوين المقصود.

help
    هذا الفعل يكافئ مفتاح التبديل --help الموثق أدناه: فهو يعرض شرحًا موجزًا للاستخدام.

  خيارات سطر الأوامر فقط
لا يمكن ضبط هذه الإعدادات في ملفات الضبط.

--force, -f
    استبدال ملف المخرجات إذا كان موجودًا بالفعل عند بناء صورة. افتراضيًا، عند بناء صورة ووجود ناتج بناء بالفعل، سيرفض mkosi العملية. حدد هذا الخيار مرة واحدة لحذف جميع نواتج البناء من تشغيل سابق قبل إعادة بناء الصورة. إذا كانت عمليات البناء المتزايدة مُمكّنة، فإن تحديد هذا الخيار مرتين سيضمن إزالة ملفات الخبيئة الوسيطة أيضًا قبل بدء إعادة البناء. إذا كانت خبيئة الحزم مستخدمة (انظر أيضًا قسم FILES أدناه)، فإن تحديد هذا الخيار ثلاث مرات سيضمن إزالة خبيئة الحزم أيضًا قبل بدء إعادة البناء. بالنسبة لعملية clean، يكون لهذا الخيار تأثير مختلف قليلًا: افتراضيًا سيزيل الفعل نواتج البناء من تشغيل سابق فقط، وعند تحديده مرة واحدة تُحذف ملفات الخبيئة المتزايدة وشجرة الأدوات أيضًا، وعند تحديده مرتين تُزال خبيئة الحزم أيضًا.

--directory=, -C
    يأخذ مسارًا لمجلد. ينتقل mkosi إلى هذا المجلد قبل القيام بأي شيء. لاحظ أنه يُبحث عن ملفات الضبط المتنوعة في هذا المجلد، لذا فإن استخدام هذا الخيار طريقة فعالة لبناء مشروع يقع في مجلد معين. القيمة المبدئية هي مجلد العمل الحالي. إذا حُددت سلسلة فارغة، سيُتجاهل كل الضبط في مجلد العمل الحالي.

--debug
    فعل خرج تنقيب إضافي.

--debug-shell
    عند فشل تنفيذ أمر في الصورة، سيبدأ mkosi صدفة تفاعلية في الصورة للسماح بمزيد من التنقيح.

--debug-workspace
    عند تحديده، لن يُحذف مجلد مساحة العمل وسيتم تسجيل موقعه عند خروج mkosi.

--debug-sandbox
    شغّل mkosi-sandbox باستخدام strace.

--version
    أظهر إصدار الحزمة.

--help, -h
    أظهر معلومات استخدام موجزة.

--genkey-common-name=
    الاسم العام (Common name) الذي سيُستخدم عند توليد المفاتيح عبر أمر genkey الخاص بـ mkosi. القيمة المبدئية هي mkosi of %u، حيث تُوسع %u إلى اسم المستخدم الذي يستدعي mkosi.

--genkey-valid-days=
    عدد الأيام التي يجب أن تظل فيها المفاتيح صالحة عند توليدها عبر أمر genkey الخاص بـ mkosi. المبدئي هو عامان (730 يومًا).

--auto-bump=, -B
    إذا حُدد، سيُرفع الإصدار وإذا نجح البناء، سيُكتب الإصدار في mkosi.version بطريقة مكافئة للفعل bump. هذا مفيد لإدارة الإصدارات البسيطة والخطية: كل بناء في سلسلة سيكون له رقم إصدار أعلى بواحد من الإصدار السابق.
    إذا كان mkosi.bump موجودًا، فسيُستدعى لتوليد الإصدار الجديد الذي سيُستخدم بدلًا من استخدام منطق mkosi الخاص.

--doc-format
    التنسيق الذي سيُعرض به التوثيق. يدعم القيم markdown و man و pandoc و system و auto. في حالة markdown يُعرض التوثيق بتنسيق Markdown الأصلي. تعرض man التوثيق بتنسيق صفحة الدليل، إذا كان متاحًا. ستقوم pandoc بتوليد تنسيق صفحة الدليل فورًا، إذا كانت pandoc متاحة. ستعرض system صفحة الدليل على مستوى النظام لـ mkosi، والتي قد تتوافق أو لا تتوافق مع الإصدار الذي تستخدمه، اعتمادًا على كيفية تثبيتك لـ mkosi. القيمة المبدئية auto ستحاول جميع الطرق بالترتيب man ثم pandoc ثم markdown ثم system.

--json
    أظهر خرج الملخص كـ JSON-SEQ.

--wipe-build-dir, -w
    امسح مجلد البناء إذا ضُبط واحد قبل بناء الصورة.

--rerun-build-scripts, -R
    إعادة تشغيل سكريبتات البناء. يتطلب تمكين الخيار Incremental= وأن تكون الصورة قد بُنيت بالفعل مرة واحدة. إذا كان History= مُمكّنًا، فسيُعاد استخدام السجل من البناء السابق ولن يُكتب سجل جديد.

  تنسيقات المخرجات المدعومة
تنسيقات المخرجات التالية مدعومة:

•   صورة قرص GPT خام، أنشئت باستخدام systemd-repart (disk)

•   مجلد عادي، يحتوي على شجرة نظام التشغيل (directory)

•   أرشيف Tar (tar)

•   أرشيف CPIO (cpio)

•   صورة نواة موحدة (UKI)

•   ... وأكثر من ذلك بكثير. انظر توثيق Format= أدناه.

يمكن أيضًا ضبط تنسيق المخرجات على none لكي لا ينتج mkosi أي صورة على الإطلاق. يمكن أن يكون هذا مفيدًا إذا كنت تريد فقط استخدام الصورة لإنتاج مخرج آخر في سكريبتات البناء (مثل بناء حزمة RPM).

عند إنشاء صورة قرص GPT، يمكن وضع ملفات تعريف أقسام repart في mkosi.repart/ لضبط صورة القرص المولدة.

يوصى بشدة بتشغيل mkosi على نظام ملفات يدعم reflinks مثل XFS و btrfs وإبقاء جميع المجلدات ذات الصلة على نفس نظام الملفات. يسمح هذا لـ mkosi بإنشاء الصور بسرعة كبيرة عن طريق استخدام reflinks لإجراء النسخ عبر عمليات النسخ عند الكتابة (copy-on-write).

  إعدادات الضبط
يمكن ضبط الإعدادات التالية عبر ملفات التكوين (الصيغة بـ SomeSetting=value) وعلى سطر الأوامر (الصيغة بـ --some-setting=value). بالنسبة لبعض معلمات سطر الأوامر، يُسمح أيضًا باختصار من حرف واحد. في ملفات التكوين، يجب أن يكون الإعداد في القسم المناسب، لذا جُمعت الإعدادات حسب الأقسام أدناه.

يُحلل الضبط بالترتيب التالي:

•   تُحلل معطيات سطر الأوامر.

•   يُحلل mkosi.local.conf و mkosi.local/ إذا كانا موجودين (بهذا الترتيب). يجب أن يكون هذا الملف وهذا الدليل في .gitignore (أو ما يعادله) وهما مخصصان للتكوين المحلي.

•   إذا كان لخيار ما مسار مبدئي مقابل، فسيتم تحليله إذا وجد المسار المبدئي المقابل.

•   يُحلل mkosi.conf إذا كان موجودًا في الدليل المضبوط بـ --directory= أو دليل العمل الحالي إذا لم يُستخدم --directory=. إذا كان الدليل المحدد لا يحتوي على mkosi.conf أو mkosi.tools.conf ولكن يوجد mkosi/mkosi.conf أو mkosi/mkosi.tools.conf، فسيُحلل التكوين من الدليل الفرعي mkosi/ للدليل المحدد بدلًا من ذلك.

•   يُحلل mkosi.conf.d/ في نفس دليل mkosi.conf إذا كان موجودًا. يُحلل كل دليل وكل ملف بالامتداد .conf في mkosi.conf.d/. يُحلل أي دليل في mkosi.conf.d كما لو كان دليلًا عاديًا من المستوى الأعلى، باستثناء mkosi.images/ و mkosi.tools.conf اللذين لا يُلتقطان إلا في دليل المستوى الأعلى.

•   إذا ضُبطت أي تشكيلات، فسيُحلل تكوينها من دليل mkosi.profiles/.

•   تُحلل الصور الفرعية من دليل mkosi.images/ إذا كان موجودًا.

لاحظ أن الإعدادات المضبوطة عبر سطر الأوامر تتجاوز دائمًا الإعدادات المضبوطة عبر ملفات التكوين. إذا ضُبط نفس الإعداد أكثر من مرة عبر ملفات التكوين، فإن التعيينات اللاحقة تتجاوز التعيينات السابقة باستثناء الإعدادات التي تأخذ مجموعة من القيم. أيضًا، الإعدادات المقروءة من mkosi.local.conf أو mkosi.local/ ستتجاوز الإعدادات من ملفات التكوين التي تُحلل لاحقًا، ولكن ليس الإعدادات المحددة على سطر الأوامر.

بالنسبة للإعدادات التي تأخذ قيمة واحدة، يمكن استخدام التعيين الفارغ (SomeSetting= أو --some-setting=) لتجاوز إعداد سابق وإعادة الضبط إلى المبدئي.

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

لتضمين ملفات التكوين بشرط، يمكن استخدام قسم [Match]. يتكون قسم [Match] من شروط فردية. يمكن للشروط استخدام رمز الأنبوب (|) بعد علامة التساوي (...=|...)، مما يجعل الشرط شرطًا محفزًا. سيُضمن ملف التكوين إذا تحقق الـ AND المنطقي لجميع الشروط غير المحفزة والـ OR المنطقي لجميع الشروط المحفزة. لنفي نتيجة شرط، ألحق المعطى بعلامة تعجب. إذا أُلحق معطى برمز الأنبوب وعلامة تعجب، فيجب تمرير رمز الأنبوب أولًا، ثم علامة التعجب ثانيًا.

لاحظ أن شروط [Match] تُقارن بالقيم الحالية لإعدادات محددة، ولا تأخذ في الاعتبار التغييرات التي أُجريت على الإعداد في ملفات التكوين التي لم تُحلل بعد (تُؤخذ الإعدادات المحددة على سطر الأوامر في الاعتبار). لاحظ أيضًا أن المطابقة مع إعداد ثم تغيير قيمته لاحقًا في ملف تكوين مختلف قد يؤدي إلى نتائج غير متوقعة.

ينطبق قسم [Match] لملف mkosi.conf في دليل ما على الدليل بأكمله. إذا لم تتحقق الشروط، سيُتخطى الدليل بأكمله. تنطبق أقسام [Match] للملفات في mkosi.conf.d/ و mkosi.local.conf على الملف نفسه فقط.

إذا كان هناك عدة أقسام [Match] في نفس ملف التكوين، يجب أن يتحقق كل منها ليُضمن ملف التكوين. تحديدًا، تنطبق الشروط المحفزة فقط على قسم [Match] الحالي وتُصفر بين أقسام [Match] المتعددة. كمثال، لن تتحقق المطابقة التالية إلا إذا كان تنسيق المخرجات أحد disk أو directory والبنية أحد x86-64 أو arm64:

        [Match]
        Format=|disk
        Format=|directory

        [Match]
        Architecture=|x86-64
        Architecture=|arm64

يمكن استخدام قسم [TriggerMatch] للإشارة إلى مطابقات محفزة. هذه مطابقة للشروط المحفزة في وحدات systemd باستثناء أنها تنطبق على قسم المطابقة بأكمله بدلًا من شرط واحد فقط. كمثال، ستحقق المطابقة التالية إذا كانت التوزيعة debian والإصدارة bookworm أو إذا كانت التوزيعة ubuntu والإصدارة noble.

        [TriggerMatch]
        Distribution=debian
        Release=bookworm

        [TriggerMatch]
        Distribution=ubuntu
        Release=noble

دلالات الشروط في أقسام [TriggerMatch] هي نفسها كما في [Match]، أي أن جميع الشروط العادية تُربط بـ AND منطقي وجميع الشروط المحفزة تُربط بـ OR منطقي. عند خلط أقسام [Match] و [TriggerMatch]، تتحقق المطابقة عندما تطابق جميع أقسام [Match] ويطابق قسم واحد على الأقل من أقسام [TriggerMatch]. يُعتبر غياب أقسام المطابقة قيمة صحيحة (true). منطقيًا هذا يعني:

        (⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ)

هناك أيضًا دعم لأقسام [Assert] و [TriggerAssert] التي تتصرف بشكل مطابق لأقسام المطابقة باستثناء أن تحليل التكوين سيفشل إذا لم تتحقق أقسام التأكيد (assert)، أي يجب تحقق جميع أقسام [Assert] في ملف بالإضافة إلى قسم [TriggerAssert] واحد على الأقل وإلا سيفشل تحليل التكوين.

تُعرض خيارات سطر الأوامر التي لا تأخذ معطيات بدون = في نسختها الطويلة. في ملفات التكوين، يجب تحديدها بمعطى منطقي (boolean): إما 1 أو yes أو true للتمكين، أو 0 أو no أو false للتعطيل.

  قسم [Distribution]

Distribution=, --distribution=, -d
    التوزيعة المراد تثبيتها في الصورة. تأخذ أحد المعطيات التالية: fedora، debian، kali، ubuntu، arch، opensuse، mageia، centos، rhel، rhel-ubi، openmandriva، rocky، alma، azure أو custom. إذا لم تُحدد، فالمبدئي هو توزيعة المضيف أو custom إذا كانت توزيعة المضيف غير مدعومة.

Release=, --release=, -r
    إصدار التوزيعة المراد تثبيتها في الصورة. تعتمد الصيغة الدقيقة للمعطى الذي تأخذه على التوزيعة المستخدمة، وهو إما سلسلة رقمية (في حالة فيدورا لينكس، CentOS، إلخ، مثل 29)، أو اسم إصدار التوزيعة (في حالة ديبيان، كالي، أوبونتو، إلخ، مثل artful). المبدئي هو إصدار حديث من التوزيعة المختارة، أو إصدار التوزيعة التي تعمل على المضيف إذا كانت تطابق التوزيعة المضبوطة.

Architecture=, --architecture=
    البنية المراد بناء الصورة لها. تعتمد البنيات المدعومة فعليًا على التوزيعة المستخدمة وما إذا كانت الصورة المطلوبة قابلة للإقلاع أم لا. عند البناء لبنية أجنبية، ستحتاج أيضًا إلى تثبيت وتسجيل محاكي وضع المستخدم لتلك البنية.
    يمكن تحديد واحدة من البنيات التالية لكل صورة تُبنى: alpha، arc، arm، arm64، ia64، loongarch64، mips64-le، mips-le، parisc، ppc، ppc64، ppc64-le، riscv32، riscv64، s390، s390x، tilegx، x86، x86-64.

Mirror=, --mirror=, -m
    المرآة المستخدمة لتنزيل حزم التوزيعة. تتوقع رابط URL للمرآة كمعطى. إذا لم تُوفر، تُستخدم المرآة المبدئية للتوزيعة.
    المرايا المبدئية لكل توزيعة هي كما يلي (ما لم يُحدد خلاف ذلك، تُستخدم المرآة نفسها لجميع المعماريات):

     | x86-64 | aarch64
    debian | http://deb.debian.org |
    arch | https://fastly.mirror.pkgbuild.com | http://mirror.archlinuxarm.org
    opensuse | http://download.opensuse.org |
    kali | http://http.kali.org/kali |
    ubuntu | http://archive.ubuntu.com | http://ports.ubuntu.com
    centos | https://mirrors.centos.org |
    rocky | https://mirrors.rockylinux.org |
    alma | https://mirrors.almalinux.org |
    fedora | https://mirrors.fedoraproject.org |
    rhel-ubi | https://cdn-ubi.redhat.com |
    mageia | https://www.mageia.org |
    openmandriva | http://mirrors.openmandriva.org |
    azure | https://packages.microsoft.com/ |

Snapshot=
    تنزيل الحزم من اللقطة (snapshot) المعطاة بدلًا من تنزيل أحدث حزم التوزيعة من المرآة المعطاة. تأخذ معرف لقطة (تختلف صيغة معرف اللقطة باختلاف التوزيعة)، استخدم الفعل latest-snapshot لمعرفة أحدث لقطة متاحة.
    إذا ضُبط هذا الإعداد ولم يُضبط Mirror= صراحةً، تُستخدم مرايا مبدئية مختلفة:

     | x86-64 | aarch64
    debian | https://snapshot.debian.org |
    arch | https://archive.archlinux.org | http://mirror.archlinuxarm.org
    opensuse | http://download.opensuse.org |
    ubuntu | http://archive.ubuntu.com | http://ports.ubuntu.com
    centos | https://composes.stream.centos.org |
    fedora | https://kojipkgs.fedoraproject.org |
    لأي توزيعة غير مدرجة أعلاه، اللقطات غير مدعومة.

LocalMirror=, --local-mirror=
    ستُستخدم المرآة كمرآة محلية ومباشرة وبسيطة بدلًا من استخدامها كبادئة للمجموعة الكاملة من المستودعات المدعومة عادةً من التوزيعات. مفيد لعمليات البناء غير المتصلة بالإنترنت تمامًا مع مستودع واحد. مدعوم في التوزيعات القائمة على deb و rpm و pacman. يتجاوز --mirror= ولكن فقط لبناء mkosi المحلي، ولن يُضبط داخل الصورة النهائية، بل سيُضبط --mirror= (أو المستودع المبدئي) داخل الصورة النهائية بدلًا من ذلك.

RepositoryKeyCheck=, --repository-key-check=
    يتحكم في فحوصات التوقيع/المفتاح عند استخدام المستودعات، وهو مُمكّن افتراضيًا. مفيد لتعطيل الفحوصات عند دمجه مع --local-mirror= واستخدام مستودع من نظام ملفات محلي فقط.

RepositoryKeyFetch=, --repository-key-fetch=
    يتحكم فيما إذا كان mkosi سيجلب مفاتيح GPG الخاصة بالتوزيعة عن بُعد. مفعل مبدئيًا على Ubuntu عند عدم استخدام شجرة أدوات أو عند استخدام أشجار أدوات Ubuntu لبناء Arch Linux أو التوزيعات المعتمدة على RPM. معطل مبدئيًا في جميع التوزيعات الأخرى. عند تعطيله، يجب تثبيت مفاتيح GPG الخاصة بالتوزيعة المستهدفة محليًا على نظام المضيف إلى جانب مدير الحزم لتلك التوزيعة.
    نُفذ هذا الإعداد فقط للتوزيعات التي تستخدم dnf أو pacman أو zypper كمدير حزم لها. بالنسبة للتوزيعات الأخرى، يُبحث دائمًا عن مفاتيح GPG للتوزيعة محليًا بغض النظر عن قيمة هذا الإعداد. لجعل مفاتيح GPG الخاصة بالتوزيعات متاحة دون تمكين هذا الإعداد، يجب تثبيت الحزمة المقابلة على المضيف. عادةً ما تكون هذه إحدى archlinux-keyring أو debian-keyring أو kali-archive-keyring أو ubuntu-keyring أو distribution-gpg-keys (للتوزيعات القائمة على RPM).

Repositories=, --repositories=
    تفعيل مستودعات الحزم المعطلة مبدئيًا. يمكن استخدام هذا لتفعيل مستودعات EPEL لـ CentOS أو مكونات مختلفة من مستودعات Debian/Kali/Ubuntu.

  قسم [Output]

Format=, --format=, -t
    نوع تنسيق الصورة المراد توليدها. أحد الخيارات: directory (لتوليد صورة نظام تشغيل مباشرة في دليل محلي)، tar (مشابه، ولكن تُولد أرشيف tar لصورة نظام التشغيل)، cpio (مشابه، ولكن يُولد أرشيف cpio)، disk (صورة نظام تشغيل لجهاز كتلي مع جدول أقسام GPT)، uki (صورة نواة موحدة مع صورة نظام التشغيل في قسم PE من نوع .initrd)، esp (صورة قرص مع قسم ESP فقط، ومحمل إقلاع وربما UKI)، oci (دليل متوافق مع مواصفات صورة OCI)، أو sysext، أو confext، أو portable، أو addon، أو none (صورة نظام التشغيل مخصصة فقط كصورة بناء لإنتاج ناتج آخر).
    إذا استُخدم تنسيق المخرجات disk، تُولد صورة القرص باستخدام systemd-repart. يمكن ضبط ملفات تعريف أقسام repart المراد استخدامها باستخدام إعداد RepartDirectories= أو عبر mkosi.repart/. عندما تُضبط أقسام verity باستخدام إعداد Verity= الخاص بـ systemd-repart، سيقوم mkosi آليًا بتحليل الـ roothash لقسم hash الخاص بـ verity من مخرجات JSON الخاصة بـ systemd-repart وتضمينه في سطر أوامر النواة لكل صورة نواة موحدة يبنيها mkosi. إذا استُخدم تنسيق المخرجات none، فلن تُزال مخرجات بناء سابق، ولكن تظل سكريبتات التنظيف (انظر CleanScripts=) تُنفذ. يسمح هذا بإعادة تشغيل سكريبت بناء (انظر BuildScripts=) دون إزالة نتائج بناء سابق.

ManifestFormat=, --manifest-format=
    نوع تنسيق البيان (manifest) أو التنسيقات المراد توليدها. قائمة مفصولة بفاصلة تتكون من json (تنسيق مخرجات JSON القياسي الذي يصف الحزم المثبتة)، و changelog (تنسيق نصي قابل للقراءة البشرية مصمم للمقارنة بالفروقات). افتراضيًا لا يُولد أي بيان.

Output=, --output=, -o
    الاسم المراد استخدامه لملف صورة المخرجات المولد أو الدليل. المبدئي هو image أو، إذا حُدد ImageId=، فإنه يُستخدم كاسم مخرجات مبدئي، ملحقًا اختياريًا بالإصدار المضبوط بـ ImageVersion= أو إذا بُنيت صورة محددة من mkosi.images، فيُفضل اسم الصورة على ImageId. لاحظ أن هذا الخيار لا يسمح بضبط دليل المخرجات، استخدم OutputDirectory= لذلك.
    لاحظ أن هذا يحدد بادئة المخرجات فقط، وبناءً على تنسيق المخرجات المحدد والضغط وإصدار الصورة المستخدم، قد يكون اسم المخرجات الكامل image_7.8.raw.xz.

OutputExtension=, --output-extension=
    استخدم الامتداد المحدد لملف الإخراج. المبدئي هو الامتداد المناسب بناءً على تنسيق الإخراج. يتضمن امتداد الملف فقط، وليس أي امتداد ضغط سيُلحق بهذا الامتداد إذا فُعل الضغط.

CompressOutput=, --compress-output=
    اضبط الضغط للصورة الناتجة أو الأرشيف. يمكن أن يكون المعطى إما قيمة منطقية أو خوارزمية ضغط (xz، zstd). يُستخدم ضغط zstd افتراضيًا، باستثناء CentOS ومشتقاته حتى الإصدار 8، التي تستخدم xz افتراضيًا، وصور OCI، التي تستخدم gzip افتراضيًا. لاحظ أنه عند تطبيقه على أنواع صور الأجهزة الكتلية، فإن الضغط يعني أن الصورة لا يمكن بدؤها مباشرة ولكن يجب فك ضغطها أولًا. هذا يعني أيضًا أن الأفعال shell و boot و vm لا تتوفر عند استخدام هذا الخيار. يُعتبر مضمنًا لـ tar و cpio و uki و esp و oci و addon.

CompressLevel=, --compress-level=
    اضبط مستوى الضغط المستخدم. يأخذ رقمًا صحيحًا. تعتمد القيم الممكنة على نوع الضغط المستخدم.

OutputDirectory=, --output-directory=, -O
    المسار إلى دليل لوضع جميع النواتج المولدة فيه. إذا لم يُحدد هذا وكان الدليل mkosi.output/ موجودًا في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض.

OutputMode=, --output-mode=
    وضع الوصول لنظام الملفات المستخدم عند إنشاء ملف صورة المخرجات. يأخذ وضع وصول بالترميز الثماني. إذا لم يُضبط، تُستخدم القيم المبدئية للنظام الحالي.

ImageVersion=, --image-version=
    اضبط إصدار الصورة. يقبل هذا أي سلسلة نصية، ولكن يُوصى بتحديد سلسلة من المكونات المفصولة بنقاط. يمكن أيضًا ضبط الإصدار بقراءة ملف mkosi.version (وفي هذه الحالة يمكن إدارته بسهولة عبر الفعل bump أو الخيار --auto-bump) أو بقراءة المخرج القياسي (stdout) إذا كان ملفًا تنفيذيًا (راجع قسم Scripts أدناه). عند تحديده، يُدرج إصدار الصورة في اسم ملف المخرج المبدئي، أي بدلاً من image.raw سيكون المبدئي هو image_0.1.raw للإصدار 0.1 من الصورة، وما شابه ذلك. يُمرر الإصدار أيضًا عبر المتغير $IMAGE_VERSION إلى أي سكريبتات بناء مستدعاة (والذي قد يكون مفيدًا لترقيعه داخل /usr/lib/os-release أو ما شابه، لا سيما حقل IMAGE_VERSION= فيه).

ImageId=, --image-id=
    اضبط معرف الصورة. يقبل هذا سلسلة نصية حرة تُستخدم لتعريف الصورة. إذا ضُبط، سيُسمى ملف المخرج المبدئي باسمه (مع احتمال إلحاقه بالإصدار). يُمرر المعرف أيضًا عبر المتغير $IMAGE_ID إلى أي سكريبتات بناء مستدعاة. يُضاف معرف الصورة آليًا إلى /usr/lib/os-release.

SplitArtifacts=, --split-artifacts=
    أنواع المصنوعات (artifacts) المراد فصلها عن الصورة النهائية. وهي قائمة مفصولة بفاصلة تتكون من uki، وkernel، وinitrd، وos-release، وprcs، وpartitions، وroothash، وkernel-modules-initrd، وrepart-definitions وtar. عند بناء صورة قابلة للإقلاع، يتوافق kernel وinitrd مع مصنوعاتهما الموجودة في الصورة (أو في UKI)، بينما ينسخ uki صورة UKI بالكامل. إذا حُدد pcrs، يُكتب ملف JSON يحتوي على خلاصات TPM2 المحسوبة مسبقًا، وفقًا لمواصفات UKI في https://uapi-group.org/specifications/specs/unified_kernel_image/#json-format-for-pcrsig ، وهو أمر مفيد للتوقيع دون اتصال بالشبكة.
    عند بناء صورة قرص وتحديد partitions، مرر --split=yes إلى systemd-repart ليقوم بكتابة ملفات أقسام منفصلة لكل قسم ضُبط. اقرأ صفحة الدليل https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--split=BOOL لمزيد من المعلومات. هذا مفيد في سيناريوهات التحديث A/B حيث تُعزز صورة قرص موجودة بإصدار جديد من قسم الجذر أو قسم /usr مع قسم Verity الخاص به ونواة موحدة. عند تحديد tar، تُؤرشف ملفات الجذر (rootfs) إضافيًا كأرشيف tar (مضغوط وفقًا لـ CompressOutput=). عند تحديد roothash وبناء صورة قرص dm-verity، تُكتب خلاصة الجذر (roothash) الخاصة بـ dm-verity كملف منفصل، وهو أمر مفيد للتوقيع دون اتصال بالشبكة. يتوافق kernel-modules-initrd مع initrd لوحدات النواة المنفصلة التي يلحقها mkosi بـ initrd الرئيس. صُمم هذا أساسًا لأغراض التنقيح لأن العديد من أدوات فحص initrd لا تتعامل بشكل صحيح مع ملفات initrd المتعددة الملحقة ببعضها البعض. عند تحديد repart-definitions، يُكتب دليل يحتوي على ملفات تعريف repart المستخدمة في دليل المخرج. إذا ضُبطت أدلة متعددة عبر RepartDirectories=، فستُدمج، مع إعطاء الأولوية للأدلة اللاحقة على السابقة عند وجود ملفات بأسماء متطابقة. بشكل مبدئي، تُفصل ملفات uki وkernel وinitrd.

RepartDirectories=, --repart-directory=
    مسارات الأدلة التي تحتوي على ملفات تعريف أقسام systemd-repart التي تُستخدم عندما يستدعي mkosi الأداة systemd-repart عند بناء صورة قرص. إذا كان mkosi.repart/ موجودًا في الدليل المحلي، فسيُستخدم لهذا الغرض أيضًا. لاحظ أن mkosi يستدعي repart مع ضبط --root= على جذر صورة الجذر، لذا فإن أي مسارات مصدر في CopyFiles= داخل ملفات تعريف الأقسام ستكون نسبية لدليل جذر الصورة.

SectorSize=, --sector-size=
    تجاوز حجم القطاع المبدئي الذي تستخدمه systemd-repart عند بناء صورة قرص.

Overlay=, --overlay=
    عند استخدامه مع BaseTrees=، سيتكون المخرج فقط من التغييرات التي طرأت على الأشجار الأساسية المحددة. تُوصل كل شجرة أساسية كطبقة سفلى في بنية overlayfs، ويصبح المخرج هو الطبقة العليا، وتكون فارغة في البداية. وبالتالي فإن الملفات التي لم تُعدل مقارنة بالأشجار الأساسية لن تكون موجودة في المخرج النهائي.
    يمكن استخدام هذا الخيار لإنشاء امتدادات نظام systemd (https://uapi-group.org/specifications/specs/extension_image) .

Seed=, --seed=
    يأخذ UUID كمعطى أو القيمة الخاصة random. يتجاوز البذرة (seed) التي يستخدمها systemd-repart عند بناء صورة قرص. هذا مفيد لتحقيق عمليات بناء قابلة لإعادة الإنتاج، حيث ينبغي اشتقاق معرفات UUID حتمية وبيانات أقسام وصفية أخرى في كل عملية بناء. إذا لم يُحدد صراحةً وكان ملف mkosi.seed موجودًا في الدليل المحلي، فسيُقرأ معرف UUID المستخدم منه. خلاف ذلك، يُستخدم UUID عشوائي.

CleanScripts=, --clean-script=
    يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي تُستخدم كسكربتات تنظيف لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

  قسم [Content]

Packages=, --package=, -p
    ثبّت حزم التوزيعة المحددة (أي RPM و deb و...) في الصورة. يأخذ قائمة مفصولة بفاصلة من مواصفات الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم الحزم المحددة. استخدم BuildPackages= لتحديد الحزم التي يجب تثبيتها فقط في طبقة تراكب تُوصل عند تنفيذ سكريبتات التحضير مع معطى build وعند تنفيذ سكريبتات البناء.
    تعتمد أنواع وصيغ مواصفات الحزم المسموح بها على مثبت الحزم (مثل dnf للتوزيعات المعتمدة على RPM أو apt للتوزيعات المعتمدة على deb)، ولكنها قد تشمل أسماء الحزم، وأسماء الحزم مع الإصدار و/أو المعمارية، وأنماط أسماء الحزم (globs)، ومجموعات الحزم، والمزودات الافتراضية، بما في ذلك مسارات الملفات. راجع PackageDirectories= للحصول على معلومات حول كيفية جعل الحزم المحلية متاحة للتثبيت باستخدام Packages=. مثال: عند استخدام توزيعة تستخدم dnf، فإن الإعداد التالي سيقوم بتثبيت حزمة meson (بأحدث إصدار)، وإصدار 32 بت من حزمة libfdisk-devel، وجميع الحزم المتاحة التي تبدأ ببادئة git-، وحزمة RPM لـ systemd من نظام الملفات المحلي، وإحدى الحزم التي توفر /usr/bin/ld، والحزم الموجودة في مجموعة أدوات التطوير، والحزمة التي تحتوي على وحدة بايثون mypy.

            Packages=meson
                     libfdisk-devel.i686
                     git-*
                     /usr/bin/ld
                     @development-tools
                     python3dist(mypy)

BuildPackages=, --build-package=
    مشابه لـ Packages=، ولكنه يضبط الحزم لتُثبت فقط في طبقة تراكب تُتاح فوق الصورة لسكريبتات التحضير عند تنفيذها مع معطى build وسكريبتات البناء. يجب استخدام هذا الخيار لإدراج الحزم التي تحتوي على ملفات الترويسة، والمصرفات، وأنظمة البناء، والروابط وأدوات البناء الأخرى التي تتطلبها سكريبتات mkosi.build للعمل. لاحظ أن الحزم المدرجة هنا ستكون غائبة عن الصورة النهائية.

VolatilePackages=, --volatile-package=
    مشابه لـ Packages=، ولكن الحزم المضبوطة بهذا الإعداد لا تُخزن في الخبيئة عند تفعيل Incremental= وتُثبت بعد تنفيذ أي سكريبتات بناء.
    تحديدًا، يمكن استخدام هذا الإعداد لتثبيت الحزم التي تتغير كثيرًا أو التي يُبني بواسطة سكريبت بناء.

PackageDirectories=, --package-directory=
    حدد الأدلة التي تحتوي على حزم إضافية لتكون متاحة أثناء البناء. سيقوم mkosi بإنشاء مستودع محلي يحتوي على جميع الحزم الموجودة في هذه الأدلة وجعلها متاحة عند تثبيت الحزم أو تشغيل السكريبتات. إذا وُجد دليل mkosi.packages/ في الدليل المحلي، فسيُستخدم لهذا الغرض أيضًا.

VolatilePackageDirectories=, --volatile-package-directory=
    مثل PackageDirectories=، ولكن أي تغييرات تطرأ على الحزم في هذه الأدلة لن تبطل الصور المخزنة في الخبيئة إذا فُعل Incremental=.
    بالإضافة إلى ذلك، يمكن لسكريبتات البناء إضافة المزيد من الحزم إلى المستودع المحلي بوضع الحزم المبنية في $PACKAGEDIR. تُشارك الحزم الموضوعة في $PACKAGEDIR بين جميع عمليات بناء الصور وبالتالي تكون متاحة للتثبيت في جميع الصور باستخدام VolatilePackages=.

WithRecommends=, --with-recommends=
    يضبط ما إذا كان سيُثبت التبعات الموصى بها أو الضعيفة، اعتمادًا على تسميتها بواسطة مدير الحزم المستخدم، أم لا. مبدئيًا، لا تُثبت الحزم الموصى بها. يُستخدم هذا فقط لمديري الحزم الذين يدعمون هذا المفهوم، وهم حاليًا apt و dnf و zypper.

WithDocs=, --with-docs=
    ضمّن التوثيق في الصورة. مفعّل مبدئيًا. عند تعطيله، وإذا كان مدير حزم التوزيعة الأساسي يدعم ذلك، فلن يُضمن التوثيق في الصورة. يُضبط متغير البيئة $WITH_DOCS الممرر إلى سكريبتات mkosi.build على 0 أو 1 اعتمادًا على ما إذا كان هذا الخيار مفعلًا أو معطلاً.

BaseTrees=, --base-tree=
    يأخذ قائمة مفصولة بفاصلة من المسارات لاستخدامها كأشجار أساسية. عند استخدامها، تُنسخ كل شجرة من هذه الأشجار الأساسية إلى شجرة نظام التشغيل وتشكل التوزيعة الأساسية بدلاً من تثبيت التوزيعة من الصفر. تُثبت الحزم الإضافية فقط فوق الحزم المثبتة بالفعل في الأشجار الأساسية. لاحظ أنه لكي يعمل هذا بشكل صحيح، لا تزال الصورة الأساسية بحاجة إلى احتواء البيانات الوصفية لمدير الحزم عن طريق ضبط CleanPackageMetadata=no (راجع CleanPackageMetadata=).
    بدلاً من الدليل، يمكن توفير ملف tar أو صورة قرص. في هذه الحالة تُفك في شجرة نظام التشغيل. يسمح نمط التشغيل هذا بضبط الأذونات وملكية الملفات صراحةً، لا سيما للمشاريع المخزنة في نظام تحكم في الإصدارات مثل git والتي تحتفظ ببيانات ملكية الملفات الكاملة ووضع الوصول للملفات المودعة.

SkeletonTrees=, --skeleton-tree=
    يأخذ قائمة مفصولة بفاصلة من أزواج المسارات المفصولة بنقطتين رأسيتين. يشير المسار الأول من كل زوج إلى دليل ليُنسخ إلى شجرة نظام التشغيل قبل استدعاء مدير الحزم. يشير المسار الثاني من كل زوج إلى الدليل المستهدف داخل الصورة. إذا لم يُوفر المسار الثاني، فسيُنسخ الدليل فوق دليل الجذر للصورة. يُفسر المسار الثاني دائمًا كمسار مطلق. استخدم هذا لإدراج ملفات وأدلة في شجرة نظام التشغيل قبل أن يثبت مدير الحزم أي حزم. إذا وُجد دليل mkosi.skeleton/ في الدليل المحلي، فسيُستخدم أيضًا لهذا الغرض مع دليل الجذر كهدف (راجع أيضًا قسم FILES أدناه).
    لاحظ أن الأشجار الهيكلية (skeleton trees) تُخزن في الخبيئة وأي تغييرات تطرأ عليها بعد بناء صورة مخبأة (عند استخدام Incremental=) لا تُطبق إلا عند إعادة بناء الصورة المخبأة (باستخدام -ff أو تشغيل mkosi -f clean). وكما هو الحال مع منطق الشجرة الأساسية أعلاه، يمكن توفير ملف tar بدلاً من الدليل أيضًا. سيُستخدم mkosi.skeleton.tar آليًا إذا وُجد في الدليل المحلي. لإضافة ملفات إعدادات إضافية لمدير الحزم مثل المستودعات الإضافية، استخدم SandboxTrees= لأن mkosi يستدعي مديري الحزم من خارج الصورة وليس من داخلها، لذا فإن أي ملفات إعدادات لمدير الحزم تُوفر عبر SkeletonTrees= لن يسري مفعولها عندما يستدعي mkosi مدير حزم لتثبيت الحزم.

ExtraTrees=, --extra-tree=
    يأخذ قائمة مفصولة بفاصلة من أزواج المسارات المفصولة بنقطتين رأسيتين. يشير المسار الأول من كل زوج إلى دليل ليُنسخ من المضيف إلى الصورة. يشير المسار الثاني من كل زوج إلى الدليل المستهدف داخل الصورة. إذا لم يُوفر المسار الثاني، فسيُنسخ الدليل فوق دليل الجذر للصورة. يُفسر المسار الثاني دائمًا كمسار مطلق. استخدم هذا لتجاوز أي ملفات إعدادات مبدئية مشحونة مع التوزيعة. إذا وُجد دليل mkosi.extra/ في الدليل المحلي، فسيُستخدم أيضًا لهذا الغرض مع دليل الجذر كهدف (راجع أيضًا قسم FILES أدناه).
    كما هو الحال مع منطق الشجرة الأساسية أعلاه، يمكن توفير ملف tar بدلاً من الدليل أيضًا. سيُستخدم mkosi.extra.tar آليًا إذا وُجد في الدليل المحلي.

RemovePackages=, --remove-package=
    يأخذ قائمة مفصولة بفاصلة من مواصفات الحزم لإزالتها، بنفس صيغة Packages=. ستُنفذ الإزالة كواحدة من الخطوات الأخيرة. تُتخطى هذه الخطوة إذا استُخدم CleanPackageMetadata=no.

RemoveFiles=, --remove-files=
    يأخذ قائمة مفصولة بفاصلة من الأنماط (globs). ستُحذف الملفات في الصورة التي تطابق الأنماط في النهاية.

CleanPackageMetadata=, --clean-package-metadata=
    فعل/عطل إزالة قواعد بيانات مدير الحزم والبيانات الوصفية للمستودعات في نهاية التثبيت. يمكن تحديده كـ true أو false أو auto (المبدئي). مع auto، ستُزال قواعد بيانات مدير الحزم والبيانات الوصفية للمستودعات إذا كان الملف التنفيذي لمدير الحزم المعني غير موجود في نهاية التثبيت.

SourceDateEpoch=, --source-date-epoch=
    يأخذ طابعًا زمنيًا بالثواني منذ حقبة يونكس (UNIX epoch) كمعطى. ستُثبت أوقات تعديل جميع الملفات على هذه القيمة. يُنشر المتغير أيضًا إلى systemd-repart والسكريبتات التي ينفذها mkosi. إذا لم يُضبط صراحةً، فسيُحاول استخدام SOURCE_DATE_EPOCH من --environment= ثم من بيئة المضيف بهذا الترتيب. هذا مفيد لجعل عمليات البناء قابلة لإعادة الإنتاج. راجع SOURCE_DATE_EPOCH (https://reproducible-builds.org/specs/source-date-epoch/) لمزيد من المعلومات.

SyncScripts=, --sync-script=
    يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي تُستخدم كسكربتات مزامنة لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

PrepareScripts=, --prepare-script=
    يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي تُستخدم كسكربتات تحضير لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

BuildScripts=, --build-script=
    يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج بناء نصية لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

PostInstallationScripts=, --postinst-script=
    يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج ما بعد التثبيت النصية لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

FinalizeScripts=, --finalize-script=
    يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج الإنهاء النصية لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

PostOutputScripts=, --postoutput-script=
    يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج ما بعد الإخراج النصية لهذه الصورة. انظر قسم SCRIPTS لمزيد من المعلومات.

Bootable=, --bootable=
    يأخذ قيمة منطقية (boolean) أو auto. يفعل أو يعطل توليد صورة قابلة للإقلاع. إذا فُعل، فسيقوم mkosi بتثبيت محمل إقلاع EFI، وإضافة قسم ESP عند استخدام مخرج صورة القرص. إذا لم يُثبّت محمل إقلاع EFI المحدد (راجع Bootloader=) أو لم يُعثر على صور نواة، فستفشل عملية البناء. يسلك auto سلوك تفعيل الخيار، ولكن لن تفشل عملية البناء إذا لم يُعثر على صور نواة أو لم يُعثر على محمل إقلاع EFI المحدد. إذا عُطل، فلن يُثبت أي محمل إقلاع حتى لو وُجد داخل الصورة، ولن تُولد صور نواة موحدة ولن يُضاف قسم ESP إلى الصورة إذا استُخدمت صيغة مخرج القرص.
    إذا استُخدمت صيغة المخرج esp، فسيُضاف دائمًا قسم ESP ومحمل إقلاع، ويتحكم خيار Bootable= فقط فيما إذا كانت ستُضاف UKI إلى قسم ESP أم لا.

Bootloader=, --bootloader=
    يأخذ واحدًا من none، أو systemd-boot، أو uki، أو grub، أو systemd-boot-signed، أو uki-signed أو grub-signed. القيمة المبدئية هي systemd-boot. إذا ضُبط على none، فلن يُثبّت أي محمل إقلاع EFI في الصورة. إذا ضُبط على systemd-boot، فسيُثبّت systemd-boot وسيتم توليد UKI لكل نواة مثبتة وتخزينها في EFI/Linux داخل قسم ESP. إذا ضُبط على uki، فسيتم توليد UKI واحدة لأحدث نواة مثبتة (التي تحمل أعلى إصدار) وتُثبت في EFI/BOOT/BOOTX64.EFI داخل قسم ESP. إذا ضُبط على grub، فسيتم توليد UKI لكل نواة مثبتة وتخزينها في EFI/Linux داخل قسم ESP. ولكل UKI مولدة، يُلحق مدخل قائمة بإعدادات grub في grub/grub.cfg داخل قسم ESP والذي يقوم بالتحميل المتسلسل (chainloads) إلى UKI. يُكتب أيضًا ملف grub.cfg وسيط (shim) إلى EFI/<distribution>/grub.cfg داخل قسم ESP والذي يحمل grub/grub.cfg في قسم ESP للتوافق مع الإصدارات الموقعة من grub التي تحمل إعدادات grub من هذا الموقع.
    ستقوم المتغيرات الموقعة (signed) فقط بتثبيت ثنائيات EFI الموقعة مسبقًا والمشحونة مع التوزيعة. يجب وضع النوى في نظام الملفات الجذر (على سبيل المثال باستخدام ExtraTrees=) تحت /usr/lib/modules/$version، وتسميتها vmlinux أو vmlinuz. الإصدار $version هو ما ينتجه هدف البناء kernelversion الخاص بـ Kbuild. ملاحظة: عند استخدام systemd-boot أو systemd-boot-signed، يتوقع mkosi أن تكون ثنائيات EFI الخاصة بـ systemd-boot موجودة في الصورة. اعتمادًا على توزيعتك، قد تكون هذه محزمة بشكل منفصل. على سبيل المثال، ستحتاج الصور المعتمدة على دبيان إلى systemd-boot-efi.

BiosBootloader=, --bios-bootloader=
    يأخذ واحدًا من none أو grub. القيمة المبدئية هي none. إذا ضُبط على none، فلن يُثبت أي محمل إقلاع BIOS. إذا ضُبط على grub، فسيُثبت grub كمحمل إقلاع BIOS إذا طُلبت صورة قابلة للإقلاع باستخدام خيار Bootable=. إذا لم تُضبط أي ملفات تعريف أقسام repart، فسيقوم mkosi بإضافة قسم إقلاع grub BIOS وقسم نظام EFI إلى ملفات تعريف الأقسام المبدئية.
    لاحظ أن هذا الخيار لا يتعارض مع Bootloader=. من الممكن الحصول على صورة قابلة للإقلاع على كل من UEFI و BIOS من خلال ضبط كل من Bootloader= و BiosBootloader=. يجب أن يكون لقسم إقلاع grub BIOS المعرف UUID 21686148-6449-6e6f-744e-656564454649 ويجب أن يكون بمساحة 1 ميجابايت على الأقل. حتى لو لم يُثبت محمل إقلاع EFI، فنحن لا نزال بحاجة إلى ESP لإقلاع BIOS لأن هذا هو المكان الذي نخزن فيه النواة و initrd ووحدات grub.

ShimBootloader=, --shim-bootloader=
    يأخذ واحدًا من none، أو unsigned، أو signed. القيمة المبدئية هي none. إذا ضُبط على none، فلن يُثبت shim و MokManager في قسم ESP. إذا ضُبط على unsigned، فسيقوم mkosi بالبحث عن ثنائيات EFI لـ shim و MokManager غير الموقعة وتثبيتها. إذا فُعل SecureBoot=، فسيقوم mkosi بتوقيع ثنائيات EFI غير الموقعة قبل تثبيتها. إذا ضُبط على signed، فسيقوم mkosi بالبحث عن ثنائيات EFI الموقعة وتثبيتها. حتى لو فُعل SecureBoot=، فلن يعيد mkosi توقيع هذه الثنائيات.
    لاحظ أن هذا الخيار لا يسري مفعوله إلا عند طلب صورة قابلة للإقلاع على برمجيات UEFI الثابتة باستخدام خيارات أخرى (Bootable= و Bootloader=). لاحظ أنه عند تفعيل هذا الخيار، سيقوم mkosi فقط بتثبيت ثنائيات محمل الإقلاع الموقعة بالفعل، وملفات صور النواة وصور النواة الموحدة، لأن الثنائيات الموقعة ذاتيًا لن تقبلها النسخة الموقعة من shim.

UnifiedKernelImages=, --unified-kernel-images=
    يحدد ما إذا كان ستُستخدم صور نواة موحدة أم لا عندما يكون Bootloader= مضبوطًا على systemd-boot أو grub. يأخذ واحدًا من none، أو unsigned، أو signed أو auto. القيمة المبدئية هي auto. إذا ضُبط على unsigned أو signed، تُستخدم صور النواة الموحدة دائمًا وستفشل عملية البناء إذا كانت أي من المكونات المطلوبة لبناء صور النواة الموحدة مفقودة. إذا ضُبط على auto، فستُستخدم صور النواة الموحدة إذا كانت جميع المكونات الضرورية متاحة. خلاف ذلك، ستُستخدم مداخل النوع 1 (Type 1) كما هو محدد في مواصفات محمل الإقلاع (Boot Loader Specification). إذا عُطل، فستُستخدم مداخل النوع 1 دائمًا. إذا ضُبط Bootloader= على أحد المتغيرات الموقعة، فسيبحث عن UKI مبنية مسبقًا وستفشل عملية البناء إذا تعذر العثور عليها، ما لم يُضبط UnifiedKernelImages= على unsigned، وفي هذه الحالة سيتم بناء UKI محليًا. هذا مفيد عند دمجه مع خيار وقت التشغيل Firmware= المضبوط على custom بحيث يُدرج مفتاح التوقيع المحلي في قاعدة بيانات UEFI (UEFI db).

UnifiedKernelImageFormat=, --unified-kernel-image-format=
    يأخذ اسم ملف دون أي مكونات مسار لتحديد الصيغة التي يجب تثبيت صور النواة الموحدة بها. قد يتضمن ذلك كلاً من المحددات العادية (راجع Specifiers) والمحددات المؤجلة الخاصة التي تُوسع أثناء تثبيت الملفات، والموضحة أدناه. الصيغة المبدئية لهذا المعامل هي &e-&k مع إلحاق -&h إذا وُجدت القيمة roothash= أو usrhash= في سطر أوامر النواة، وإلحاق +&c إذا وُجد /etc/kernel/tries في الصورة.
    يمكن استخدام المحددات التالية:

    المحدد | القيمة
    && | محرف &
    &e | رمز المدخل
    &k | إصدار النواة
    &h | قيمة roothash= أو usrhash= في معطى النواة

UnifiedKernelImageProfiles=, --uki-profile=
    ابنِ تشكيلات (profiles) نواة موحدة (UKI) إضافية. يأخذ قائمة مفصولة بفاصلة من المسارات إلى ملفات إعداد تشكيلات UKI. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُبنى كل إعدادات في تشكيلة UKI المقابلة. تُلتقط ملفات الإعداد في دليل mkosi.uki-profiles/ آليًا. تُضاف جميع تشكيلات UKI المضبوطة كتشكيلات إضافية لكل UKI يبنيها mkosi.
    راجع توثيق قسم UKIProfile للحصول على معلومات حول الإعدادات التي يمكن ضبطها في ملفات إعداد تشكيلات UKI.

Initrds=, --initrd=
    استخدام ملفات initrd التي يوفرها المستخدم. يأخذ قائمة مفصولة بفواصل من المسارات لملفات initrd. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم initrd. إذا لم تُحدد أي ملفات initrd وطُلبت صورة قابلة للإقلاع، سيقوم mkosi آليًا ببناء initrd مبدئي.
    سيبحث mkosi أيضًا عن initrds في دليل فرعي io.mkosi.initrd من دليل المصنوعات (انظر $ARTIFACTDIR في قسم ENVIRONMENT VARIABLES). تُلحق أي initrds توجد هناك بملفات initrd المقدمة من المستخدم وأي initrd مبدئي يبنيه mkosi.

InitrdProfiles=, --initrd-profile=
    ضبط التشكيلات لتفعيلها في initrd المبدئي. يأخذ قائمة تشكيلات مفصولة بفواصل. تكون كافة التشكيلات معطلة مبدئيًا.
    تُمكّن تشكيلة lvm دعم LVM. وتُمكّن تشكيلة network دعم الشبكة عبر systemd-networkd. وتُمكّن تشكيلة nfs دعم NFS. وتتطلب وجود شبكة في initrd، باستخدام تشكيلة network، أو طريقة مخصصة أخرى. وتُمكّن تشكيلة pkcs11 دعم PKCS#11. وتوفر تشكيلة plymouth واجهة رسومية عند الإقلاع (رسوم متحركة ومحث كلمة مرور). وتُمكّن تشكيلة raid دعم مصفوفات RAID.

InitrdPackages=, --initrd-package=
    حزم إضافية لتثبيتها في initrd المبدئي. يأخذ قائمة مفصولة بفواصل لمواصفات الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم الحزم المحددة.

InitrdVolatilePackages=, --initrd-volatile-package=
    مشابه لـ VolatilePackages=، إلا أنه ينطبق على initrd المبدئي.

Devicetrees=, --devicetrees=
    قائمة بأنماط شجرة الأجهزة (devicetree) مفصولة بفواصل للاختيار الآلي المبني على الأجهزة. الأنماط هي تعابير مطابقة (glob). يبحث mkosi عن ملفات شجرة الأجهزة في المواقع القياسية بالنسبة لـ /usr/lib/modules/<kver>/dtb/، و /usr/lib/firmware/<kver>/device-tree/، و /usr/lib/linux-image-<kver>/.
    لبناء UKI، تفعّل التطابقات المتعددة الاختيار الآلي المبني على الأجهزة باستخدام أقسام .dtbauto. تتطلب مدخلات إقلاع النوع 1 تطابقًا واحدًا بالضبط. مثال: Devicetrees=rockchip/*,imx.* سيضمن كل أشجار أجهزة Rockchip وأي أشجار أجهزة IMX.

Splash=, --splash=
    عند ضبطه، سيُجلب شاشة البداية (boot splash) لأي صورة نواة موحدة يبنيها mkosi من المسار المعطى داخل الصورة.

MicrocodeHost=, --microcode-host=
    عند ضبطه إلى true، يضمن فقط الرمز الدقيق (microcode) لوحدة المعالجة المركزية للمضيف في الصورة.

KernelCommandLine=, --kernel-command-line=
    استخدام سطر أوامر النواة المحدد عند بناء الصور.
    إذا أُنشئ قسم الجذر أو usr مع تفعيل verity، فسيُضاف roothash= أو usrhash= بالترتيب آليًا إلى سطر أوامر النواة ويجب ألا يُضاف root= أو mount.usr=. خلاف ذلك، إذا احتوت قيمة هذا الضبط على النصوص root=PARTUUID أو mount.usr=PARTUUID، فستُستبدل بـ UUID الخاص بقسم الجذر أو قسم usr بالترتيب. على سبيل المثال، root=PARTUUID ستُستبدل بـ root=PARTUUID=58c7d0b2-d224-4834-a16f-e036322e88f7 حيث 58c7d0b2-d224-4834-a16f-e036322e88f7 هو UUID لقسم الجذر.

KernelModules=, --kernel-modules=
    يأخذ قائمة من أنماط المظاهرة (glob) التي تحدد وحدات النواة التي يجب تضمينها في الصورة. يمكن بادئة كل وسيط بشرطة (-)، لـ استثناء الوحدات المطابقة. تُقيم الوسائط بالترتيب، ويحدد آخر نمط مطابق (إيجابي أو سلبي) النتيجة. تُضمن الوحدات التي طابقت آخر نمط إيجابي في الصورة، بالإضافة إلى تبعات الوحدات والبرمجيات الثابتة الخاصة بها.
    يُتجاهل اللاحقة .ko ولاحقة الضغط أثناء المطابقة. تُطابق الأنماط مع مسارات الوحدات بالنسبة لـ /usr/lib/module/<kver>، مثلاً الوحدة في /usr/lib/module/<kver>/kernel/foo/bar.ko.xz تصبح kernel/foo/bar لأغراض المطابقة. الأنماط التي تبدأ بـ “/” تُعامل معاملة خاصة. يُطابق النمط أولاً مع مسار بالنسبة لـ /usr/lib/module/<kver>/kernel، ثم بعد ذلك فقط مع /usr/lib/module/<kver>/. هذا للتسهيل، حيث إن الوحدات داخل الشجرة تحت kernel/ هي ما يهم عادةً. على سبيل المثال، الوحدة في /usr/lib/module/<kver>/kernel/foo/bar.ko.xz يمكن مطابقتها بـ /foo/bar أو /kernel/foo/bar. قد تتضمن أنماط المطابقة الاسم الأساسي فقط (مثل loop)، الذي يجب أن يطابق الاسم الأساسي للوحدة، أو المسار النسبي (مثل block/loop)، أو مسارًا مطلقًا (مثل /drivers/block/loop). عند انتهاء النمط بـ /، فسيطابق كل الوحدات تحت ذلك الدليل. قد تتضمن الأنماط رموز مطابقة الصدفة (*، ?). إذا استُخدمت القيمة الخاصة default، ستُضمن وحدات النواة المبدئية المعرفة في ضبط mkosi-initrd. وإذا استُخدمت القيمة الخاصة host، ستُضمن الوحدات المحملة حاليًا على نظام المضيف.

KernelModulesInitrd=, --kernel-modules-initrd=
    قيمة منطقية، مفعلة (true) مبدئيًا. إذا فُعلت، سيقوم mkosi عند بناء صورة قابلة للإقلاع بتوليد initrd إضافي لكل صورة نواة موحدة يجمعها. يحتوي هذا الـ initrd فقط على الوحدات وربما البرمجيات الثابتة، ثم يُلحق بـ initrd الأساسي لتشكيل ملف initrd النهائي. يحافظ هذا على استقلالية initrd الأساسي عن النواة، ويقوم فقط بتعزيزه بالوحدات اللازمة والخاصة بإصدار النواة عند تجميع صورة النواة الموحدة (UKI).
    إذا عُطّل، لن يُولد أي initrd إضافي. لاحظ أن وحدات النواة ستظل غير مضمنة في initrd الأساسي، الذي يظل مستقلاً عن النواة. بدلاً من ذلك، يُفترض أن المستخدم يوفر الوحدات اللازمة عبر initrd مخصص إضافي.

KernelInitrdModules=, --kernel-modules-initrd-include=
    مثل KernelModules=، لكنه يحدد وحدات النواة لتضمينها في initrd.

FirmwareFiles=, --firmware-files=
    يأخذ قائمة بأنماط المطابقة التي تحدد ملفات البرمجيات الثابتة (firmware) لتضمينها في الصورة. تُفسر الأنماط بنفس الطريقة المستخدمة في إعدادات KernelModules=، باستثناء أن المسارات تكون نسبية لـ /usr/lib/firmware/<subdir>. تُتجاهل لاحقة الضغط ويجب عدم تضمينها في النمط.
    تُضمن تبعات البرمجيات الثابتة لوحدات النواة المثبتة في الصورة آليًا. مثال: FirmwareFiles=cxgb4/bcm8483.bin أو FirmwareFiles=bcm8483.* كلاهما سيؤدي إلى تضمين /usr/lib/firmware/cxgb4/bcm8483.bin.xz، حتى لو لم تُدرج بواسطة وحدة.

Locale=, --locale=, LocaleMessages=, --locale-messages=, Keymap=, --keymap=, Timezone=, --timezone=, Hostname=, --hostname=, RootShell=, --root-shell=
    الإعدادات Locale=، --locale=، LocaleMessages=، --locale-messages=، Keymap=، --keymap=، Timezone=، --timezone=، Hostname=، --hostname=، RootShell=، --root-shell= تقابل خيارات systemd-firstboot التي تحمل نفس الاسم. انظر systemd-firstboot(1) لمزيد من المعلومات. بالإضافة إلى ذلك، حيثما أمكن، تُكتب اعتمادات systemd المقابلة لهذه الإعدادات في /usr/lib/credstore، لكي تنطبق حتى لو شُحن /usr فقط في الصورة.

RootPassword=, --root-password=,
    اضبط كلمة سر جذر النظام. إذا لم يُستخدم هذا الخيار، ووُجد ملف mkosi.rootpw في الدليل المحلي، فستُقرأ كلمة السر منه آليًا أو إذا كان الملف قابلاً للتنفيذ فسيُشغل ككراسة ويُقرأ الخرج القياسي بدلاً من ذلك (انظر قسم SCRIPTS أدناه). إذا بدأت كلمة السر بـ hashed:، فستُعامل ككلمة سر جذر معمّاة مسبقًا. تُخزن كلمة سر الجذر أيضًا في /usr/lib/credstore تحت اعتماد systemd المناسب لكي تنطبق حتى لو شُحن /usr فقط في الصورة. لإنشاء حساب غير مقفل بدون أي كلمة سر استخدم hashed: بدون تعمية.

Autologin=, --autologin=, -a
    فعل الولوج الآلي للمستخدم root على /dev/pts/0 (nspawn)، و /dev/tty1 و /dev/hvc0.

MakeInitrd=, --make-initrd=
    أضف /etc/initrd-release و /init إلى الصورة لكي يمكن استخدامها كـ initramfs.

Ssh=, --ssh=
    يحدد ما إذا كان يجب تثبيت وحدة مقبس sshd والخدمة المطابقة لها في الصورة النهائية. يأخذ أحد القيم always أو never أو auto أو runtime. القيمة المبدئية هي auto.
    إذا ضُبط إلى auto وكان sshd موجودًا في الصورة وثنائية المولد systemd-ssh-generator غير موجودة، أو إذا ضُبط إلى always، سيثبت mkosi وحدات sshd في الصورة النهائية التي تعرض SSH عبر VSock. إذا ضُبط إلى never، لن يثبت mkosi هذه الوحدات. إذا استُخدمت القيمة runtime، لن يثبت mkosi أي وحدات أيضًا ولكنه سيجهض بدء mkosi vm إذا لم تُضبط أي اعتمادات SSH. عند البناء بهذا الخيار وتشغيل الصورة باستخدام mkosi vm، يمكن استخدام أمر mkosi ssh للاتصال بالحاوية/الآلة الافتراضية عبر SSH. لاحظ أنه لا يزال يتعين عليك التأكد من تثبيت openssh في الصورة ليعمل mkosi ssh بشكل صحيح. شغّل mkosi genkey لتوليد شهادة X.509 ومفتاح خاص آليًا ليستخدمهما mkosi لتفعيل وصول SSH إلى أي آلات افتراضية عبر mkosi ssh. للوصول إلى الصور المقُلعة باستخدام mkosi boot، استخدم machinectl. بدءًا من systemd v256، سيقوم systemd-ssh-generator(8) آليًا بتوفير sshd عبر VSock عند التشغيل داخل آلة افتراضية. لذا إذا كنت تستخدم إصدارًا حديثًا من systemd، فلن يُستخدم هذا الخيار عمومًا. لا تزال بحاجة إلى تثبيت openssh في الصورة، والضبط المبدئي لـ --vsock=auto كافٍ لضمان توفر VSock داخل الآلة الافتراضية. ملاحظة: إذا كانت توزيعة الصورة تستخدم SELinux، فستُرفض خدمة sshd الخاصة بـ mkosi من الوصول إلى VSock، مما يؤدي لفشل الاتصال. ستحتاج إما لتعطيل فرض SELinux أو إنشاء وحدة سياسة مخصصة (مثلاً باستخدام audit2allow).

SELinuxRelabel=, --selinux-relabel=
    يحدد ما إذا كان يجب إعادة وسم الملفات لتطابق سياسة SELinux الخاصة بالصورة. يأخذ قيمة منطقية أو auto. القيمة المبدئية هي auto. إذا عُطّل، لن تُعاد وسم الملفات. إذا فُعّل، يجب تثبيت سياسة SELinux في الصورة ويجب أن يكون setfiles متاحًا لإعادة وسم الملفات. إذا حدثت أي أخطاء أثناء setfiles، سيفشل البناء. إذا ضُبط إلى auto، ستُعاد وسم الملفات إذا كان mkosi لا يبني صورة دليل، وكانت سياسة SELinux مثبتة في الصورة و setfiles متاحًا. ستُتجاهل أي أخطاء تحدث أثناء setfiles.
    لاحظ أنه عند التشغيل بدون امتيازات، سيفشل setfiles في ضبط أي لصائق ليست في سياسة SELinux للمضيف. لضمان نجاح setfiles بدون أخطاء، تأكد من تشغيل mkosi كجذر أو البناء من نظام مضيف له نفس سياسة SELinux للصورة التي تبنيها.

MachineId=, --machine-id=
    يأخذ UUID أو القيمة الخاصة random. يضبط معرف الآلة (machine ID) للصورة إلى UUID المحدد. إذا ضُبط إلى random، فسيُكتب UUID عشوائي إلى /etc/machine-id. إذا لم يُحدد صراحةً ووُجد الملف mkosi.machine-id في الدليل المحلي، فسيُقرأ UUID المستخدم منه. خلاف ذلك، ستُكتب القيمة uninitialized إلى /etc/machine-id.

  قسم [التحقق]

SecureBoot=, --secure-boot=
    توقيع systemd-boot (إذا لم يكن موقعًا بعد) وأي صور نواة موحدة مولدة لـ UEFI SecureBoot (الإقلاع الآمن).

SecureBootAutoEnroll=, --secure-boot-auto-enroll=
    قم بإعداد التسجيل الآلي لمفاتيح الإقلاع الآمن في الآلات الافتراضية كما هو موثق في systemd-boot(7) إذا استُخدم SecureBoot=. لاحظ أن systemd-boot سيقوم بالتسجيل الآلي فقط في الآلات الافتراضية بدءًا من systemd v253. للقيام بالتسجيل الآلي في إصدار systemd v252 أو على الأجهزة الحقيقية، اكتب ملف ضبط systemd-boot إلى /efi/loader/loader.conf باستخدام شجرة إضافية تحتوي على secure-boot-enroll force أو secure-boot-enroll manual. التسجيل الآلي غير مدعوم في إصدارات systemd أقدم من v252. القيمة المبدئية هي yes.

SecureBootKey=, --secure-boot-key=
    مسار ملف PEM الذي يحتوي على المفتاح السري لتوقيع صورة نواة UEFI إذا استُخدم SecureBoot= وتوقيعات PCR عند استخدام SignExpectedPcr= أيضًا. عند تحديد SecureBootKeySource=، يعتمد نوع الإدخال على المصدر.

SecureBootCertificate=, --secure-boot-certificate=
    مسار ملف X.509 الذي يحتوي على شهادة صورة نواة UEFI الموقعة، إذا استُخدم SecureBoot=.

SecureBootSignTool=, --secure-boot-sign-tool=
    الأداة المستخدمة لتوقيع ثنائيات PE للإقلاع الآمن. تأخذ أحد القيم systemd-sbsign أو sbsign أو auto. القيمة المبدئية هي auto. إذا ضُبطت إلى auto، ستُستخدم إما systemd-sbsign أو sbsign إذا توفرتا، مع تفضيل systemd-sbsign.

Verity=, --verity=
    ما إذا كان يجب فرض أو تعطيل verity لصور الامتدادات. يأخذ أحد القيم signed أو hash أو defer أو auto أو قيمة منطقية. إذا ضُبط إلى signed، فيجب توفر مفتاح وشهادة verity وسيفشل البناء إذا لم نكتشف أي أقسام verity في صورة القرص الناتجة عن systemd-repart. إذا عُطّل، ستُستبعد أقسام verity من صور الامتدادات. إذا ضُبط إلى hash، سيضبط mkosi أداة systemd-repart لإنشاء قسم بصمة verity، ولكن بدون قسم توقيع. إذا ضُبط إلى defer، فسيُخصص مسار لقسم توقيع verity ولكنه لن يُملأ بعد. إذا ضُبط إلى auto ووُجد مفتاح وشهادة verity، سيمررهما mkosi إلى systemd-repart ويتوقع احتواء الصورة على أقسام verity، لكن البناء لن يفشل إذا لم توجد.
    لاحظ أن التعطيل الصريح لتوقيع و/أو بصمة verity لم يُنفذ بعد لمخرجات disk ويعمل فقط لصور الامتدادات في الوقت الحالي.

VerityKey=, --verity-key=
    مسار ملف PEM الذي يحتوي على المفتاح السري لتوقيع توقيع verity، إذا أُضيف قسم توقيع verity باستخدام systemd-repart. عند تحديد VerityKeySource=، يعتمد نوع الإدخال على المصدر.

VerityCertificate=, --verity-certificate=
    المسار إلى ملف X.509 الذي يحتوي على الشهادة لتوقيع توقيع verity، إذا أُضيف قسم توقيع verity باستخدام systemd-repart.

SignExpectedPcr=, --sign-expected-pcr=
    قياس مكونات صورة النواة الموحدة (UKI) باستخدام systemd-measure ودمج توقيع PCR داخل صورة النواة الموحدة. يأخذ هذا الخيار قيمة منطقية أو القيمة الخاصة auto، وهي المبدئية، وتساوي القيمة true إذا كانت ثنائية systemd-measure موجودة في PATH. يعتمد على تفعيل SecureBoot= والمفتاح من SecureBootKey=.

SignExpectedPcrKey=, --sign-expected-pcr-key=
    مسار ملف PEM الذي يحتوي على المفتاح السري لتوقيع توقيعات PCR المتوقعة. عند تحديد SignExpectedPcrKeySource=، يعتمد نوع الإدخال على المصدر.

SignExpectedPcrCertificate=, --sign-expected-pcr-certificate=
    المسار إلى ملف X.509 الذي يحتوي على الشهادة لتوقيع توقيعات PCR المتوقعة.

SecureBootKeySource=, --secure-boot-key-source=, VerityKeySource=, --verity-key-source=, SignExpectedPcrKeySource=, --sign-expected-key-source=
    مصدر المفتاح الخاص المقابل، لدعم محركات ومزودي OpenSSL، مثلاً --secure-boot-key-source=engine:pkcs11 أو --secure-boot-key-source=provider:pkcs11.

SecureBootCertificateSource=, --secure-boot-certificate-source=, VerityCertificateSource=, --verity-certificate-source=, SignExpectedPcrCertificateSource=, --sign-expected-certificate-source=
    مصدر الشهادة المقابلة، لدعم مزودي OpenSSL، مثلاً --secure-boot-certificate-source=provider:pkcs11. لاحظ أن المحركات غير مدعومة.

Passphrase=, --passphrase=
    حدد المسار إلى ملف يحتوي على عبارة المرور لاستخدامها في تعمية LUKS. يجب أن يحتوي على عبارة المرور حرفيًا، وألا ينتهي بحرف سطر جديد (أي بنفس التنسيق الذي يتوقعه cryptsetup و /etc/crypttab). يجب أن يكون للملف وضع وصول 0600 أو أقل.
    لاحظ أن هذا الإعداد بمفرده لا يفعل أي تعمية. يجب عليك أيضًا إضافة ملف تعريف قسم واحد أو أكثر إلى mkosi.repart/ مع Encrypt=key-file لإضافة أقسام معماة إلى الصورة.

Checksum=, --checksum=
    ولد ملف <output>.SHA256SUMS لكل المصنوعات المولدة بعد اكتمال البناء.

Sign=، --sign=
    وقّع ملف SHA256SUMS المولد باستخدام gpg بعد الانتهاء.

OpenPGPTool=، --openpgp-tool=
    تطبيق OpenPGP المراد استخدامه للتوقيع. يُعد gpg هو المبدئي. سيؤدي اختيار قيمة تختلف عن القيمة المبدئية إلى استخدام أداة OpenPGP عديمة الحالة (SOP) المعطاة لتوقيع ملف SHA256SUMS.
    الخيارات النموذجية هي sqop و rsop، ولكن أي تطبيق من https://www.openpgp.org/about/sop/ يمكن تثبيته محليًا سيعمل.

Key=، --key=
    اختر مفتاح gpg لاستخدامه في توقيع SHA256SUMS. يجب أن يكون هذا المفتاح موجودًا بالفعل في حلقة مفاتيح gpg.

  قسم [البناء]

ToolsTree=، --tools-tree=
    إذا حدد، فسيُبحث عن البرامج التي ينفذها mkosi لبناء الصورة وإقلاعها داخل الشجرة المعطاة بدلاً من النظام المضيف. استخدم هذا الخيار لجعل عمليات بناء الصور أكثر قابلية للتكرار عبر استخدام نفس إصدارات البرامج دائمًا لبناء الصورة النهائية بدلاً من أي إصدار مثبت على النظام المضيف. إذا لم يُستخدم هذا الخيار، ولكن وُجد دليل mkosi.tools/ في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض مع اعتبار الدليل الجذر هدفًا.
    يُحتفظ بدليل شجرة الأدوات بين عمليات بناء الصور المتكررة ما لم يُنظف باستدعاء mkosi clean -f. لاحظ أن الملفات الثنائية الموجودة في أي من المسارات المضبطة عبر ExtraSearchPaths= ستُنفذ باستخدام /usr/ من شجرة الأدوات بدلاً من المضيف. إذا لم تتطابق توزيعة المضيف أو إصداره مع توزيعة أو إصدار شجرة الأدوات على التوالي، فقد يؤدي ذلك إلى إخفاقات عند محاولة تنفيذ الملفات الثنائية من أي من مسارات البحث الإضافية. إذا ضُبط على yes، سيضيف mkosi آليًا صورة شجرة أدوات إضافية ويستخدمها كشجرة أدوات. يمكن ضبط هذه الصورة بشكل أكبر باستخدام الإعدادات أدناه أو باستخدام mkosi.tools.conf الذي يمكن أن يكون إما ملفًا أو دليلاً يحتوي على إعدادات إضافية لشجرة الأدوات المبدئية. انظر قسم TOOLS TREE لمزيد من التفاصيل.

ToolsTreeDistribution=، --tools-tree-distribution=
    اضبط التوزيعة المراد استخدامها لشجرة الأدوات المبدئية. القيمة المبدئية هي توزيعة المضيف باستثناء Ubuntu التي تعود مبدئيًا إلى Debian، و RHEL و CentOS و Alma و Rocky التي تعود مبدئيًا إلى Fedora، أو custom إذا لم تكن توزيعة المضيف مدعومة.

ToolsTreeRelease=، --tools-tree-release=
    اضبط إصدارة التوزيعة لاستخدامها في شجرة الأدوات المبدئية. مبدئيًا، تُستخدم الإصدارة المبدئية المضمنة في mkosi للتوزيعة.

ToolsTreeProfiles=، --tools-tree-profile=
    اضبط التشكيلات المراد تفعيلها لشجرة الأدوات المبدئية. يأخذ قائمة مفصولة بفواصل تتكون من devel و misc و package-manager و runtime. مبدئيًا، تُفعل كل التشكيلات باستثناء devel.
    تحتوي تشكيلة devel على الأدوات المطلوبة لبناء مشاريع (C/C++). وتحتوي تشكيلة misc على أدوات مفيدة متنوعة يسهل توفرها في السكربتات. تحتوي تشكيلة مدير الحزم على مديري الحزم والأدوات ذات الصلة بخلاف تلك الأصلية لتوزيعة شجرة الأدوات. تحتوي تشكيلة runtime على الأدوات المطلوبة لإقلاع الصور في حاوية systemd-nspawn أو في آلة افتراضية.

ToolsTreeMirror=، --tools-tree-mirror=
    اضبط المرآة لاستخدامها في شجرة الأدوات المبدئية. مبدئيًا، تُستخدم المرآة المبدئية لتوزيعة شجرة الأدوات.

ToolsTreeRepositories=، --tools-tree-repository=
    مثل Repositories= ولكن لشجرة الأدوات المبدئية.

ToolsTreeSandboxTrees=، --tools-tree-sandbox-tree=
    مثل SandboxTrees= ولكن لشجرة الأدوات المبدئية.

ToolsTreePackages=، --tools-tree-package=
    حزم إضافية لتثبيتها في شجرة الأدوات المبدئية. تأخذ قائمة مفصولة بفاصلة من مواصفات الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم الحزم المحددة.

ToolsTreePackageDirectories=، --tools-tree-package-directory=
    مثل PackageDirectories=، ولكن لشجرة الأدوات المبدئية.

ToolsTreeCertificates=، --tools-tree-certificates=
    حدد ما إذا كان سيُستخدم الشهادات والمفاتيح من شجرة الأدوات. مُفعل مبدئيًا. إذا فُعل، فستُستخدم المسارات /etc/pki/ca-trust و /etc/pki/tls و /etc/ssl و /etc/ca-certificates و /var/lib/ca-certificates من شجرة الأدوات. بخلاف ذلك، تُجلب هذه الأدلة من المضيف.

ExtraSearchPaths=، --extra-search-path=
    قائمة مسارات مفصولة بنقطتين للبحث عن الأدوات فيها قبل استخدام مسار البحث $PATH العادي.

Incremental=، --incremental=، -i
    يأخذ إما strict أو قيمة منطقية كمعامل له. يُفعل وضع البناء التزايدي. في هذا الوضع، تُنشأ نسخة من صورة نظام التشغيل فور تثبيت جميع حزم النظام وتنفيذ سكربتات التحضير ولكن قبل استدعاء سكربتات mkosi.build (أو أي شيء يحدث بعدها). في الاستدعاءات اللاحقة لـ mkosi مع مفتاح -i، قد تُستخدم هذه الصورة المخبأة لتخطي تثبيت حزم النظام، مما يسرع أوقات البناء المتكررة بشكل كبير. لاحظ أنه على الرغم من وجود بعض الآليات البدائية لإبطال الخبيئة، إلا أنها ليست مثالية بالتأكيد. لإجبار إعادة بناء الصورة المخبأة، ادمج -i مع -ff لضمان إزالة الصورة المخبأة أولاً ثم إعادة إنشائها.
    إذا ضُبط على strict، فسيخفق البناء إذا لم تكن الصورة المخبأة المبنية سابقًا موجودة.

CacheOnly=، --cache-only=
    يأخذ أحد القيم auto، أو metadata، أو always، أو never. القيمة المبدئية هي auto. إذا ضُبط على always، يُوجّه مدير الحزم بعدم التراسل مع الشبكة. يوفر هذا مستوى أدنى من قابلية التكرار، طالما أن خبيئة الحزم مملوءة بالكامل بالفعل. إذا ضُبط على metadata، يمكن لمدير الحزم تنزيل الحزم، لكننا لن نمامن بيانات المستودع الوصفية. إذا ضُبط على auto، فستُزامن بيانات المستودع الوصفية ما لم يكن لدينا صورة مخبأة (انظر Incremental=) ويمكن تنزيل الحزم أثناء البناء. إذا ضُبط على never، فستُزامن بيانات المستودع الوصفية دائمًا ويمكن تنزيل الحزم أثناء البناء.

SandboxTrees=، --sandbox-tree=
    يأخذ قائمة مفصولة بفواصل من أزواج مسارات مفصولة بنقطتين. يشير المسار الأول من كل زوج إلى دليل لنسخه إلى معزل (sandbox) mkosi قبل تنفيذ أي أداة. يشير المسار الثاني من كل زوج إلى الدليل الهدف داخل المعزل. إذا لم يُوفر المسار الثاني، فسيُنسخ الدليل فوق الدليل الجذر للمعزل. يُفسر المسار الثاني دائمًا كمسار مطلق. إذا وُجد دليل mkosi.sandbox/ في الدليل المحلي، فسيُستخدم لهذا الغرض مع اعتبار الدليل الجذر هدفًا (انظر أيضًا قسم FILES أدناه).
    سيبحث mkosi عن ضبط مدير الحزم والملفات ذات الصلة في أشجار المعزل المضبطة. ما لم يُحدد خلاف ذلك، سيستخدم ملفات الضبط من مواقعها الأصلية في /usr أو /etc في أشجار المعزل. على سبيل المثال، سيبحث عن /etc/dnf/dnf.conf في أشجار المعزل إذا استُخدم dnf لتثبيت الحزم.

WorkspaceDirectory=، --workspace-directory=
    مسار إلى دليل لتخزين البيانات المطلوبة مؤقتًا أثناء بناء الصورة. يجب أن يتوفر في هذا الدليل مساحة كافية لتخزين صورة نظام التشغيل الكاملة، رغم أن مساحة القرص المستخدمة فعليًا في معظم الأوضاع تكون أصغر. إذا لم يُحدد، فسيُستخدم دليل فرعي من $XDG_CACHE_HOME (إذا ضُبط)، أو $CACHE_DIRECTORY (إذا ضُبط)، أو $HOME/.cache (إذا ضُبط)، أو /var/tmp.
    تُزال البيانات الموجودة في هذا الدليل آليًا بعد كل عملية بناء. من الآمن إزالة محتويات هذا الدليل يدويًا في حال أُحبط استدعاء mkosi بشكل غير طبيعي (على سبيل المثال، بسبب إعادة التشغيل أو انقطاع الطاقة).

CacheDirectory=، --cache-directory=
    يأخذ مسارًا لدليل لاستخدامه كدليل خبيئة تزايدي للصور التزايدية الناتجة عند تفعيل خيار Incremental=. إذا لم يُستخدم هذا الخيار، ولكن وُجد دليل mkosi.cache/ في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض.

CacheKey=، --cache-key=
    يحدد الدليل الفرعي داخل دليل الخبيئة حيث تُخزن الصورة المخبأة. قد يشمل ذلك كلاً من المحددات العادية (انظر Specifiers) والمحددات المؤجلة الخاصة، التي تُوسع بعد انتهاء تحليل الضبط بدلاً من أثنائه، والموصوفة أدناه. التنسيق المبدئي لهذا المعامل هو &d~&r~&a~&I.
    يمكن استخدام المحددات التالية:

    المحدد | القيمة
    && | محرف &
    &d | Distribution=
    &r | Release=
    &a | Architecture=
    &i | ImageId=
    &v | ImageVersion=
    &I | اسم الصورة الفرعية داخل mkosi.images/ أو main
    لاحظ أن جميع الصور داخل عملية بناء واحدة يجب أن تمتلك مفتاح خبيئة فريد.

PackageCacheDirectory=، --package-cache-dir=
    يأخذ مسارًا لدليل لاستخدامه كدليل خبيئة للحزم لمدير حزم التوزيعة المستخدم. إذا لم يُضبط، ولكن وُجد دليل mkosi.pkgcache/ في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض، وإلا فسيُستخدم دليل مناسب في دليل المنزل للمستخدم أو في النظام.

BuildDirectory=، --build-directory=
    يأخذ مسارًا لدليل لاستخدامه كدليل بناء لأنظمة البناء التي تدعم البناء خارج الشجرة (مثل Meson). الدليل المستخدم بهذه الطريقة يُشارك بين عمليات البناء المتكررة، ويسمح لنظام البناء بإعادة استخدام النواتج (مثل ملفات الكائنات، والملفات التنفيذية، ...) المولدة في الاستدعاءات السابقة. يمكن لسكربتات البناء العثور على مسار هذا الدليل في متغير البيئة $BUILDDIR. يُوصل هذا الدليل في الدليل الجذر للصورة عند استدعاء mkosi-chroot أثناء تنفيذ سكربتات البناء. إذا لم يُحدد هذا الخيار، ولكن وُجد دليل mkosi.builddir/ في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض (انظر أيضًا قسم FILES أدناه).

BuildKey=، --build-key=
    يحدد الدليل الفرعي داخل دليل البناء حيث تُخزن نواتج البناء التزايدية. قد يشمل ذلك كلاً من المحددات العادية (انظر Specifiers) والمحددات المؤجلة الخاصة، التي تُوسع بعد انتهاء تحليل الضبط بدلاً من أثنائه، وهي نفس المحددات المؤجلة التي يدعمها CacheKey=. التنسيق المبدئي لهذا المعامل هو &d~&r~&a.
    لتعطيل استخدام دليل بناء فرعي تمامًا، خصص الرمز - لهذا الإعداد.

UseSubvolumes=، --use-subvolumes=
    يأخذ قيمة منطقية أو auto. يُفعل أو يُعطل استخدام مجلدات btrfs الفرعية لمخرجات شجرة الأدلة. إذا فُعل، فسيقوم mkosi بإنشاء الدليل الجذر كمجلد فرعي لـ btrfs ويستخدم لقطات مجلدات btrfs الفرعية حيثما أمكن لنسخ الأشجار الأساسية أو المخبأة، وهو ما يعد أسرع بكثير من إجراء نسخ تكراري. إذا فُعل صراحةً وكان btrfs غير مثبت أو تعذر إنشاء مجلدات فرعية، فسيُرفع خطأ. إذا ضُبط على auto، فسيُتجاهل غياب btrfs أو الإخفاق في إنشاء المجلدات الفرعية.

RepartOffline=، --repart-offline=
    يحدد ما إذا كان سيُبنى صور القرص باستخدام أجهزة الحلقة (loopback). مُفعل مبدئيًا. عند التفعيل، لن يستخدم systemd-repart أجهزة الحلقة لبناء صور القرص. عند التعطيل، سيستخدم systemd-repart دائمًا أجهزة الحلقة لبناء صور القرص.
    لاحظ أنه عند استخدام RepartOffline=no، لا يمكن لـ mkosi العمل بدون امتيازات، ويجب أن تُبنى الصورة كمستخدم جذر خارج أي حاويات ومع توفر أجهزة الحلقة (loopback devices) على النظام المضيف. هناك حالتان معروفان يجب فيهما استخدام RepartOffline=no. الأولى هي عند استخدام Subvolumes= في ملف تعريف قسم repart، حيث لا يمكن إنشاء مجلدات فرعية دون استخدام أجهزة الحلقة. الثانية هي عند إنشاء نظام بـ SELinux وقسم جذر XFS. لأن mkfs.xfs لا يدعم ملء نظام ملفات XFS بسمات ممتدة، يجب استخدام أجهزة الحلقة لضمان وصول سمات SELinux الممتدة إلى نظام ملفات XFS المولد.

History=، --history=
    يأخذ قيمة منطقية. إذا فُعل، فسيقوم mkosi بكتابة الضبط المقدم عبر واجهة سطر الأوامر لآخر عملية بناء في الدليل الفرعي .mkosi-private في الدليل الذي استُدعي منه. تُعاد استخدام هذه المعاملات طالما لم تُعد بناء الصورة لتجنب الاضطرار إلى تحديدها مرارًا وتكرارًا.
    لإعطاء مثال على فائدة ذلك، إذا نفذت mkosi -O my-custom-output-dir -f متبوعًا بـ mkosi vm، فسيخفق mkosi قائلاً إن الصورة لم تُبنَ بعد. أما إذا نفذت mkosi -O my-custom-output-dir --history=yes -f متبوعًا بـ mkosi vm، فسيقلع الصورة التي بُنيت في الخطوة السابقة كما هو متوقع.

BuildSources=، --build-sources=
    يأخذ قائمة مفصولة بفواصل من أزواج مسارات مفصولة بنقطتين. يشير المسار الأول من كل زوج إلى دليل لوصله من المضيف. يشير المسار الثاني من كل زوج إلى الدليل الذي يجب وصل دليل المصدر فيه عند تشغيل السكربتات. يسبق كل مسار هدف بالبادئة /work/src وتُفرز جميع مصادر البناء معجميًا حسب هدفها قبل الوصل، بحيث تُوصل مسارات المستوى الأعلى أولاً. إذا لم تُضبط صراحة، يُوصل دليل العمل الحالي إلى /work/src.

BuildSourcesEphemeral=، --build-sources-ephemeral=
    يأخذ قيمة منطقية أو القيمة الخاصة buildcache. معطل مبدئيًا. يضبط ما إذا كان سيُبقى على التغييرات في أدلة المصدر ودليل العمل المضبط باستخدام BuildSources=. إذا فُعل، فستُصفر جميع أدلة المصدر إلى حالتها الأصلية في كل مرة بعد تشغيل جميع السكربتات من نوع معين (باستثناء سكربتات المزامنة).
    💥💣💥 إذا ضُبط إلى buildcache فلن تُهمش الطبقة الفوقية عند تشغيل كراسات البناء، بل تُحفظ في دليل البناء، المضبط عبر BuildDirectory=، وستُستخدم مجددًا في التشغيلات اللاحقة. تظل الطبقة الفوقية مُهمشة لكل الكراسات الأخرى. يمكن استخدام هذا الخيار لتنفيذ خبأ متقدم للبناء، لكنه قد يؤدي إلى حالات غير متوقعة لدليل المصدر. عند استخدام هذا الخيار، يجب ضبط دليل بناء. 💥💣💥

Environment=، --environment=
    يضيف متغيرات إلى البيئة التي يُنفذ مديري الحزم وبرامج الإعداد/البناء/ما بعد التثبيت/الإنهاء النصية بها. يأخذ قائمة مفصولة بمسافات من تعيينات المتغيرات أو مجرد أسماء المتغيرات. في الحالة الأخيرة، ستُمرر قيم تلك المتغيرات من البيئة التي استُدعي فيها mkosi. قد يُحدد هذا الخيار أكثر من مرة، وفي هذه الحالة ستُضبط جميع المتغيرات المدرجة. إذا ضُبط نفس المتغير مرتين، فإن الضبط الأخير يتجاوز السابق.

EnvironmentFiles=، --env-file=
    يأخذ قائمة مفصولة بفواصل من مسارات الملفات التي تحتوي على تعريفات متغيرات البيئة لإضافتها إلى بيئة السكربتات. يستخدم mkosi.env إذا وُجد في الدليل المحلي. تُقرأ المتغيرات أولاً من mkosi.env إن وجد، ثم من قائمة الملفات المعطاة ثم من إعدادات Environment=.

WithTests=، --with-tests=، -T
    إذا ضُبط على خطأ (أو عند استخدام خيار سطر الأوامر)، يُضبط متغير البيئة $WITH_TESTS على 0 عند استدعاء سكربتات mkosi.build. يُفترض أن يُستخدم هذا من قِبل سكربتات البناء لتجاوز أي اختبارات وحدة أو تكامل تُجرى عادةً أثناء عملية بناء المصدر. لاحظ أن هذا الخيار ليس له أي تأثير ما لم تحترمه سكربتات بناء mkosi.build.

WithNetwork=، --with-network=
    عندما تكون القيمة صواب، يُفعل الاتصال بالشبكة أثناء استدعاء سكربتات البناء mkosi.build. مبدئيًا، تعمل سكربتات البناء مع إيقاف الشبكة. يُمرر متغير البيئة $WITH_NETWORK إلى سكربتات بناء mkosi.build للإشارة إلى ما إذا كان البناء يتم بوجود شبكة أو بدونها.

ProxyUrl=، --proxy-url=
    اضبط وكيلاً لاستخدامه لجميع اتصالات الشبكة الصادرة. تُضبط الأدوات المتنوعة التي يستدعيها mkosi والتي يمكن ضبط الوكيل لها لاستخدام هذا الوكيل. يضبط mkosi أيضًا متغيرات بيئة معروفة متنوعة لتحديد الوكيل المراد استخدامه لأي برامج يستدعيها قد تحتاج إلى وصول للإنترنت.

ProxyExclude=، --proxy-exclude=
    اضبط أسماء المضيفين التي يجب ألا تمر طلباتها عبر الوكيل. يأخذ قائمة مفصولة بفاصلة من أسماء المضيفين.

ProxyPeerCertificate=، --proxy-peer-certificate=
    اضبط ملفًا يحتوي على شهادات تُستخدم للتحقق من الوكيل. القيمة المبدئية هي مخزن الشهادات على مستوى النظام.
    حاليًا، دعم ضبط شهادة نظير الوكيل متاح فقط عند استخدام dnf أو dnf5 لبناء الصورة.

ProxyClientCertificate=، --proxy-client-certificate=
    اضبط ملفًا يحتوي على الشهادة المستخدمة لاستيثاق العميل مع الوكيل.
    حاليًا، دعم ضبط شهادة عميل الوكيل متاح فقط عند استخدام dnf أو dnf5 لبناء الصورة.

ProxyClientKey=، --proxy-client-key=
    اضبط ملفًا يحتوي على المفتاح الخاص المستخدم لاستيثاق العميل مع الوكيل. المبدئي هو شهادة عميل الوكيل إن وُفرت.
    حاليًا، دعم ضبط مفتاح عميل الوكيل متاح فقط عند استخدام dnf أو dnf5 لبناء الصورة.

  قسم [Runtime] (المعروف سابقًا بقسم [Host])

NSpawnSettings=، --settings=
    يحدد ملف إعدادات .nspawn ليستخدمه systemd-nspawn في الفعلين boot و shell، ولوضعه بجانب ملف الصورة المولد. هذا مفيد لضبط بيئة systemd-nspawn عند تشغيل الصورة. إذا لم يُستخدم هذا الإعداد ولكن وُجد ملف mkosi.nspawn في الدليل المحلي، فسيُستخدم آليًا لهذا الغرض.

VirtualMachineMonitor=، --vmm=
    يضبط مراقب الآلة الافتراضية المراد استخدامه. يأخذ أحد القيمتين qemu أو vmspawn. القيمة المبدئية هي qemu.
    عند الضبط على qemu، تُقلع الصورة باستخدام qemu. يمكن إقلاع معظم تنسيقات المخرجات في qemu. أي معاملات تُحدد بعد الفعل تُلحق باستدعاء qemu وتُفسر كمعاملات سطر أوامر إضافية لـ qemu. عند الضبط على vmspawn، يُستخدم systemd-vmspawn لإقلاع الصورة، ويدعم vmspawn فقط الصور من نوع القرص والدليل. أي معاملات تُحدد بعد الفعل تُلحق باستدعاء systemd-vmspawn وتُفسر كخيارات إضافية لـ vmspawn ومعاملات إضافية لسطر أوامر النواة.

Console=، --console=
    يضبط كيفية إعداد الطرفية للآلة الافتراضية. يأخذ أحد القيم interactive، أو read-only، أو native، أو gui. القيمة المبدئية هي interactive. توفر interactive واجهة طرفية تفاعلية للآلة الافتراضية. أما read-only فهي مشابهة لكنها للقراءة فقط تمامًا، أي أنها لا تقبل أي مدخلات من المستخدم. توفر native أيضًا واجهة تعتمد على TTY، لكنها تستخدم التطبيق الأصلي لـ qemu (مما يعني توفر مراقب qemu). وتظهر gui واجهة المستخدم الرسومية لـ qemu.

CPUs=، --cpus=
    يضبط عدد نوى المعالج لتخصيصها للضيف عند إقلاع آلة افتراضية. القيمة المبدئية هي 2.
    عند الضبط على 0، سيُستخدم عدد المعالجات المتاحة لعملية mkosi.

RAM=، --ram=
    يضبط مقدار ذاكرة الوصول العشوائي المخصصة للضيف عند إقلاع آلة افتراضية. القيمة المبدئية هي 2G.

MaxMem=، --maxmem=
    يضبط أقصى مقدار من الذاكرة يمكن للضيف نشره إجمالاً (ذاكرة الوصول العشوائي + أجهزة الذاكرة القابلة للتوصيل السريع). المبدئي هو مقدار ذاكرة الوصول العشوائي المضبوطة.

KVM=، --kvm=
    يضبط ما إذا كان يجب استخدام تسريع KVM عند إقلاع آلة افتراضية. يأخذ قيمة منطقية أو auto. القيمة المبدئية هي auto.

CXL=، --cxl=
    يضبط ما إذا كانت أجهزة CXL مفعلة لآلة معينة. صالح فقط إذا كانت البنية تدعم cxl. يأخذ قيمة منطقية. القيمة المبدئية هي false.

VSock=، --vsock=
    يضبط ما إذا كان سيُوفر vsock عند إقلاع آلة افتراضية. يأخذ قيمة منطقية أو auto. القيمة المبدئية هي auto.

VSockCID=، --vsock-cid=
    يضبط معرف اتصال vsock لاستخدامه عند إقلاع آلة افتراضية. يأخذ رقمًا في المدى [3, 0xFFFFFFFF) أو hash أو auto. القيمة المبدئية هي auto. عند الضبط على hash، سيُشتق معرف الاتصال من المسار الكامل للصورة. وعند الضبط على auto، سيحاول mkosi العثور على معرف اتصال حر آليًا. وبخلاف ذلك، سيُستخدم الرقم المقدم كما هو.

TPM=، --tpm=
    اضبط ما إذا كان سيُستخدم وحدة نظام أمان افتراضية (TPM) عند إقلاع آلة افتراضية. يأخذ قيمة منطقية أو auto. القيمة المبدئية هي auto.

Removable=، --removable=
    يضبط ما إذا كان سيُرفق الصورة كجهاز قابل للفصل عند إقلاع آلة افتراضية. يأخذ قيمة منطقية. القيمة المبدئية هي no.

Firmware=، --firmware=
    يضبط البرمجيات الثابتة (firmware) للآلة الافتراضية. يأخذ أحد القيم uefi، أو uefi-secure-boot، أو bios، أو linux، أو linux-noinitrd، أو auto. القيمة المبدئية هي auto. عند الضبط على uefi، تُستخدم برمجية OVMF بدون دعم الإقلاع الآمن. وعند الضبط على uefi-secure-boot، تُستخدم برمجية OVMF مع دعم الإقلاع الآمن. وعند الضبط على bios، تُستخدم برمجية SeaBIOS المبدئية. وعند الضبط على linux، يُستخدم إقلاع النواة المباشر. انظر خيار Linux= لمزيد من التفاصيل حول أي صورة نواة تُستخدم مع إقلاع النواة المباشر. linux-noinitrd مماثل لـ linux باستثناء عدم استخدام initrd. وعند الضبط على auto، يُستخدم uefi-secure-boot إن أمكن، وإلا فـ linux.

FirmwareVariables=، --firmware-variables=
    يضبط المسار إلى ملف متغيرات البرمجيات الثابتة للآلة الافتراضية. حاليًا، يُؤخذ هذا الخيار في الاعتبار فقط عند استخدام البرمجيات الثابتة uefi أو uefi-secure-boot. إذا لم يُحدد، سيبحث mkosi عن ملف المتغيرات المبدئي ويستخدمه بدلاً من ذلك.
    عند الضبط على microsoft، سيُستخدم ملف متغيرات برمجيات ثابتة مسجل فيه بالفعل شهادات الإقلاع الآمن من Microsoft. وعند الضبط على microsoft-mok، سيُوسع ملف متغيرات البرمجيات الثابتة المسجل فيه شهادات Microsoft بمتغير MokList يحتوي على شهادة الإقلاع الآمن من SecureBootCertificate=. هذا مخصص للاستخدام مع ثنائيات shim الموقعة من التوزيعة وثنائيات EFI الموقعة محليًا. وعند الضبط على custom، ستُسجل شهادة الإقلاع الآمن من SecureBootCertificate= في ملف متغيرات البرمجيات الثابتة المبدئي. يمكن استخدام virt-fw-vars من مشروع virt-firmware (https://gitlab.com/kraxel/virt-firmware) لتخصيص ملفات متغيرات OVMF.

Linux=، --linux=
    اضبط صورة النواة لاستخدامها في إقلاع النواة المباشر لـ qemu. إذا لم تُحدد، فسيستخدم mkosi النواة المقدمة عبر سطر الأوامر (خيار -kernel) أو أحدث نواة ثُبتت في الصورة (أو سيخفق إذا لم تُثبت أي نواة في الصورة).
    لاحظ أنه عند استخدام تنسيق المخرجات cpio، يُستخدم إقلاع النواة المباشر بغض النظر عن البرمجيات الثابتة المضبطة. اعتمادًا على البرمجيات الثابتة، قد يقوم qemu بإقلاع النواة بنفسه أو باستخدام البرمجيات الثابتة المضبطة. قد يشمل هذا الإعداد كلاً من المحددات العادية (انظر Specifiers) والمحددات المؤجلة الخاصة، التي تُوسع بعد انتهاء تحليل الضبط بدلاً من أثنائه، والموصوفة أدناه. يمكن استخدام المحددات التالية:

    المحدد | القيمة
    && | محرف &
    &b | دليل البناء النهائي (بما في ذلك الدليل الفرعي)

Drives=، --drive=
    أضف قرصًا. يأخذ سلسلة نصية مفصولة بنقطتين بالتنسيق <المعرف>:<الحجم>[:<الدليل>[:<الخيارات>[:<معرف-الملف>[:<الأعلام>]]]]. يحدد id المعرف المخصص للقرص. يمكن استخدام هذا كخاصية drive= في أجهزة qemu المختلفة. يحدد size حجم القرص، ويأخذ الحجم بالبايت. بالإضافة إلى ذلك، يمكن استخدام اللاحقات K و M و G لتحديد الحجم بالكيلوبايت والميجابايت والجيجابايت على التوالي. يحدد directory اختياريًا الدليل الذي سيُنشأ فيه الملف الساند للقرص؛ إذا لم يُضبط، سيُنشأ الملف تحت /var/tmp. تحدد options اختياريًا خصائص إضافية مفصولة بفواصل تُمرر كما هي إلى خيار -blockdev في qemu. يحدد file-id معرف الملف الساند للقرص؛ وإذا لم يُضبط، فإنه يعود مبدئيًا إلى معرف القرص. ستتشارك الأقراص التي لها نفس معرف الملف في الملف الساند نفسه. سيُحدد دليل الملف وحجمه من أول قرص يحمل معرف ملف معين. تأخذ flags قائمة مفصولة بفواصل من أعلام القرص التي تدعم حاليًا persist فقط. يحدد persist ما إذا كان القرص سيستمر عبر استدعاءات qemu. ستُنشأ الملفات الساندة للأقراص وفق النمط /<الدليل>/mkosi-drive-<اسم-الآلة-أو-الصورة>-<معرف-الملف>. يمكنك تخطي القيم بضبطها على سلسلة فارغة، فمثلاً تحديد myfs:1G::::persist سيُنشئ قرصًا مستمرًا تحت /var/tmp/mkosi-drive-main-myfs.
    مثال على الاستخدام:

            [Runtime]
            Drives=btrfs:10G
                   ext4:20G
            QemuArgs=-device nvme,serial=btrfs,drive=btrfs
                     -device nvme,serial=ext4,drive=ext4

QemuArgs=
    قائمة مفصولة بمسافات من المعاملات الإضافية لتمريرها عند استدعاء qemu.

Ephemeral=، --ephemeral=
    عند الاستخدام مع الأفعال shell أو boot أو vm، يقوم هذا الخيار بتشغيل الفعل المحدد على لقطة مؤقتة لصورة المخرجات تُزال فور انتهاء الحاوية. أخذ لقطة مؤقتة يكون أكثر كفاءة في أنظمة الملفات التي تدعم الروابط المرجعية (reflinks) بشكل أصيل (btrfs أو xfs) مقارنة بأنظمة الملفات التقليدية التي لا تدعمها (ext4).

Credentials=، --credential=
    اضبط الاعتمادات المراد تمريرها إلى systemd-nspawn أو الآلة الافتراضية على التوالي عند استخدام mkosi shell/boot أو mkosi vm. يأخذ هذا الخيار قائمة قيم مفصولة بمسافات يمكن أن تكون إما أزواج مفتاح=قيمة أو مسارات. إذا قُدم مسار وكان ملفًا، فسيكون اسم الاعتماد هو اسم الملف. وإذا كان الملف تنفيذيًا، فستكون قيمة الاعتماد هي مخرجات تنفيذ الملف. وبخلاف ذلك، ستكون قيمة الاعتماد هي محتويات الملف. وإذا كان المسار دليلاً، فسيُطبق نفس المنطق على كل ملف في الدليل.
    لاحظ أن القيم ستُعامل كمسارات فقط إذا لم تكن تحتوي على الفاصل (=).

KernelCommandLineExtra=، --kernel-command-line-extra=
    اضبط مدخلات سطر أوامر نواة إضافية تُلحق بسطر أوامر النواة في وقت التشغيل عند إقلاع الصورة. عند الإقلاع في حاوية، تُمرر كمعاملات إضافية إلى systemd. عند الإقلاع في آلة افتراضية، تُلحق بسطر أوامر النواة عبر سلسلة SMBIOS OEM المسماة io.systemd.stub.kernel-cmdline-extra. لن تُلتقط هذه إلا بواسطة إصدارات systemd-boot وsystemd-stub الأحدث من أو المساوية لـ v254.

RuntimeTrees=، --runtime-tree=
    يأخذ زوجًا من المسارات مفصولاً بنقطتين. يشير المسار الأول إلى دليل لوصله في أي آلة (حاوية أو آلة افتراضية) يبدؤها mkosi. ويشير المسار الثاني إلى الدليل الهدف داخل الآلة. إذا لم يُوفر المسار الثاني، فسيُوصل الدليل عند /root/src في الآلة. وإذا كان المسار الثاني نسبيًا، فسيُفسر بالنسبة إلى /root/src في الآلة.
    لكل دليل موصول، تُطابق uid و gid للمستخدم الذي يشغل mkosi مع المستخدم الجذر في الآلة. هذا يعني أن كل الملفات والأدلة ستظهر كما لو كانت مملوكة للجذر في الآلة، وكل الملفات والأدلة الجديدة التي ينشئها الجذر في الآلة في هذه الأدلة سيمتلكها المستخدم الذي يشغل mkosi على المضيف. لاحظ أنه عند استخدام mkosi vm مع هذه الميزة، يجب تثبيت systemd v254 أو أحدث في الصورة.

RuntimeSize=، --runtime-size=
    إذا حُدد، ستُوسع صور الأقراص إلى الحجم المحدد عند إقلاعها باستخدام mkosi boot أو mkosi vm. يأخذ الحجم بالبايت. بالإضافة إلى ذلك، يمكن استخدام اللاحقات K و M و G لتحديد الحجم بالكيلوبايت والميجابايت والجيجابايت على التوالي.

RuntimeNetwork=، --runtime-network=
    يأخذ أحد القيم user أو interface أو none. القيمة المبدئية هي user. يحدد الشبكة المراد إعدادها عند إقلاع الصورة. user يقوم بإعداد شبكة وضع المستخدم. interface يقوم بإعداد اتصال شبكة افتراضي بين المضيف والصورة، ويترجم هذا إلى واجهة veth لـ mkosi shell و mkosi boot، وواجهة tap لـ mkosi vm و mkosi vmspawn.
    لاحظ أنه عند استخدام interface، لا يقوم mkosi بضبط واجهة المضيف آليًا. يُتوقع أن يكون إصدار حديث من systemd-networkd يعمل على المضيف ليقوم بضبط واجهة المضيف للرابط آليًا.

RuntimeBuildSources=، --runtime-build-sources=
    صِل مصادر البناء المضبطة عبر BuildSources= ودليل البناء (إذا ضُبط) في نفس المواقع في /work التي وُصلت فيها عند تشغيل سكربت البناء، وذلك عند استخدام mkosi boot أو mkosi vm.

BindUser=، --bind-user=
    ربط دليل المنزل للمستخدم الحالي داخل الحاوية أو الآلة الافتراضية. تقبل قيمة منطقية. معطلة مبدئياً.

UnitProperties=، --unit-property=
    اضبط خصائص وحدات systemd لإضافتها إلى نطاقات systemd المخصصة عند استخدام mkosi boot أو mkosi vm. تُمرر هذه الخصائص مباشرة إلى خيارات --property= الخاصة بـ systemd-nspawn و systemd-run على التوالي.

SshKey=، --ssh-key=
    المسار إلى المفتاح الخاص X.509 بتنسيق PEM لاستخدامه للاتصال بآلة افتراضية بُدئت باستخدام mkosi vm وبُنيت مع تفعيل خيار Ssh= (أو مع تثبيت systemd-ssh-generator) عبر أمر mkosi ssh. إذا لم يُضبط ووجد ملف mkosi.key في دليل العمل، فسيُستخدم آليًا لهذا الغرض. نفذ mkosi genkey لتوليد مفتاح آليًا في mkosi.key.

SshCertificate=، --ssh-certificate=
    المسار إلى شهادة X.509 بتنسيق PEM لتوفيرها كمفتاح SSH عام في الآلات الافتراضية التي تُبدأ باستخدام mkosi vm. إذا لم تُضبط ووجد ملف mkosi.crt في دليل العمل، فسيُستخدم آليًا لهذا الغرض. نفذ mkosi genkey لتوليد شهادة آليًا في mkosi.crt.

Machine=، --machine=
    حدد اسم الآلة المراد استخدامه عند إقلاع الصورة. يمكن استخدامه أيضًا للإشارة إلى صورة محددة عند الدخول عبر SSH إلى صورة (مثلاً mkosi --image=myimage ssh).
    لاحظ أنه يجب تفعيل Ephemeral= لبدء عدة نسخ من نفس الصورة.

Register=, --register=
    تقبل قيمة منطقية (boolean) أو auto (آلي). تحدد ما إذا كان سيُسجل الحاسوب الافتراضي/الحاوية لدى systemd-machined. في حال تفعيلها، ستفشل أداة mkosi إذا لم تستطع تسجيل الحاسوب الافتراضي/الحاوية لدى systemd-machined. وإذا عُطلت، فلن تسجل mkosi الحاسوب الافتراضي/الحاوية. أما إذا كانت القيمة auto، فستسجل mkosi الحاسوب الافتراضي/الحاوية لدى systemd-machined إن كان متاحًا. القيمة المبدئية هي auto.

ForwardJournal=, --forward-journal=
    تحدد المسار الذي يجب تحويل سجلات اليومية (journal logs) من الحاويات والحواسيب الافتراضية إليه. إذا كان للمسار الامتداد .journal، فسيُفسر على أنه ملف يجب كتابة السجل فيه. وخلاف ذلك، يُفسر المسار على أنه دليل يجب كتابة السجل فيه.
    لاحظ أن نظام systemd بالإصدار v256 أو أحدث مطلوب في الحاسوب الافتراضي ليعمل تحويل السجلات. لاحظ أيضًا أنه في حال إعطاء مسار بامتداد .journal، فسيكون حجم السجل محدودًا بـ 4G. اضبط دليل مخرجات بدلاً من ملف إذا كان حجم بيانات السجل التي ينتجها عملك يتجاوز 4G.

StorageTargetMode=, --storage-target-mode=
    تحدد ما إذا كان يجب على الأمر serve تشغيل systemd-storagetm لتقديم صور الأقراص عبر NVME-TCP. تقبل قيمة منطقية أو auto. في حال التفعيل، يُشغل systemd-storagetm دائمًا وستفشل mkosi إذا لم تتمكن من تشغيله. وفي حال التعطيل، لا يُشغل systemd-storagetm أبدًا. أما في حالة auto، فسيُشغل systemd-storagetm إذا كانت صورة القرص قيد البناء، وكان ملف systemd-storagetm التنفيذي موجودًا، واستُدعي mkosi serve بصلاحيات المستخدم الجذر.

SysupdateDirectory=, --sysupdate-directory=
    المسار إلى دليل يحتوي على ملفات تعريف النقل لـ systemd-sysupdate والتي تستخدمها mkosi sysupdate. إذا وُجد mkosi.sysupdate/ في الدليل المحلي، فسيُستخدم لهذا الغرض أيضًا.
    لاحظ أن mkosi sysupdate يستدعي systemd-sysupdate مع ضبط --transfer-source= على دليل مخرجات mkosi. للاستفادة من هذا في ملف تعريف النقل، اضبط PathRelativeTo=explicit ليُفسر إعداد Path= لمصدر النقل نسبةً إلى دليل مخرجات mkosi. بشكل عام، يعد ضبط PathRelativeTo=explicit و Path=/ لمصدر النقل كافيًا لتفسير نمط المطابقة نسبةً إلى دليل مخرجات mkosi.

  قسم [Match]

Profiles=
    يطابق التشكيلات المضبوطة.

Distribution=
    يطابق التوزيعة المضبوطة.

Release=
    يطابق إصدارة التوزيعة المضبوطة. إذا استُخدم هذا الشرط ولم تُضبط أي توزيعة صراحة بعد، فتُستخدم توزيعة المضيف وإصدارته.

Architecture=
    تطابق المعمارية المضبوطة. إذا استُخدم هذا الشرط ولم تكن هناك معمارية قد ضُبطت صراحة بعد، فستُستخدم معمارية المضيف. يمكن استخدام Architecture=uefi للمطابقة مع أي معمارية تدعم UEFI.

Repositories=
    تطابق المستودعات المفعلة عبر إعداد Repositories=. تقبل اسم مستودع واحد.

PathExists=
    يتحقق هذا الشرط إذا كان المسار المعطى موجوداً. تُفسر المسارات النسبية نسبةً إلى الدليل الأب لملف الضبط الذي قُرئ منه الشرط.

ImageId=
    يطابق معرف الصورة المضبوط، ويدعم أنماط المطابقة (globs). إذا استُخدم هذا الشرط ولم يُضبط معرف الصورة صراحة بعد، فسيفشل هذا الشرط.

ImageVersion=
    تطابق إصدار الصورة المضبوط. يمكن أن تُسبق إصدارات الصور بالمعاملات ==، أو !=، أو >=، أو <=، أو <، أو > لإجراء مقارنات إصدارات غنية وفقًا لمواصفة تنسيق إصدار مجموعة UAPI. إذا لم يُسبق بمعامل، يُفترض معامل المساواة مبدئيًا. إذا استُخدم هذا الشرط ولم يكن قد ضُبط إصدار للصورة صراحة بعد، فسيفشل هذا الشرط.

Bootable=
    تطابق القيمة المضبوطة لميزة Bootable=. تقبل قيمة منطقية أو auto.

Format=
    تطابق القيمة المضبوطة لخيار Format=. تقبل تنسيق مخرجات (انظر خيار Format=).

SystemdVersion=
    تطابق إصدار systemd على المضيف (كما يوردها أمر systemctl --version). يمكن أن تُسبق القيم بالمعاملات ==، أو !=، أو >=، أو <=، أو <، أو > لمقارنات الإصدارات وفقًا لمواصفة تنسيق إصدار مجموعة UAPI. إذا لم يُسبق بمعامل، يُفترض معامل المساواة مبدئيًا.

BuildSources=
    تقبل مسار هدف لمصدر بناء (انظر BuildSources=). يتحقق هذا التطابق إذا كان أي من مصادر البناء المضبوطة يستخدم مسار الهدف هذا. على سبيل المثال، إذا كان لدينا ملف mkosi.conf يحتوي على:

            [Build]
            BuildSources=../abc/qed:kernel
        وملف تكميلي (drop-in) يحتوي على:

            [Match]
            BuildSources=kernel
        سيُضمن الملف التكميلي. تُفسر أي مسارات مطلقة تُمرر لهذا الإعداد نسبةً إلى دليل العمل الحالي.

HostArchitecture=
    تطابق المعمارية الأصلية للمضيف. انظر إعداد Architecture= للاطلاع على قائمة بالقيم الممكنة.

ToolsTreeDistribution=
    يطابق توزيعة شجرة الأدوات المضبوطة.

ToolsTreeRelease=
    يطابق إصدارة شجرة الأدوات المضبوطة.

Environment=
    تطابق زوج مفتاح/قيمة محدد ضُبط باستخدام Environment=. إذا لم تُوفر قيمة، فسيُتحقق مما إذا كان المفتاح المعطى موجودًا في البيئة بغض النظر عن قيمته.

Image=
    تطابق اسم الصورة (أو الصورة الفرعية) الحالية. اسم الصورة الفرعية هو اسمها في mkosi.images/ (بدون لاحقة .conf). اسم الصورة في المستوى الأعلى هو main. حالة الاستخدام الرئيسة هي السماح بوجود تكوين مشترك يمكن تضمينه من قِبل كل من الصورة في المستوى الأعلى والصور الفرعية عبر حجب الإعدادات الشاملة خلف مطابقة Image=main.

يوضح هذا الجدول أي أدوات المطابقة تدعم أنماط المطابقة (globs)، والمقارنات الثرية، والقيمة المبدئية التي يُطابق معها إذا لم يُضبط أي قيمة وقت قراءة ملف الضبط:

أداة المطابقة | أنماط المطابقة (Globs) | المقارنات الثرية | المبدئي
Profiles= | لا | لا | تفشل المطابقة
Distribution= | لا | لا | يطابق توزيعة المضيف
Release= | لا | لا | يطابق إصدارة المضيف
Architecture= | لا | لا | يطابق معمارية المضيف
PathExists= | لا | لا | غير متاح
ImageId= | نعم | لا | تفشل المطابقة
ImageVersion= | لا | نعم | تفشل المطابقة
Bootable= | لا | لا | يطابق الميزة الآلية
Format= | لا | لا | يطابق التنسيق المبدئي
SystemdVersion= | لا | نعم | غير متاح
BuildSources= | لا | لا | تفشل المطابقة
HostArchitecture= | لا | لا | غير متاح
ToolsTreeDistribution= | لا | لا | تطابق توزيعة شجرة الأدوات الاحتياطية (انظر ToolsTreeDistribution= في قسم [Build])
ToolsTreeRelease= | لا | لا | يطابق إصدارة شجرة الأدوات المبدئية
Environment= | لا | لا | غير متاح
Image= | لا | لا | غير متاح

  [Include]

Include=, --include=, -I
    تضمين إعدادات إضافية من الملف أو الدليل المعطى. تُضمن الإعدادات الإضافية مباشرة بعد تحليل الإعداد، إلا عند استخدامها في سطر الأوامر، ففي تلك الحالة تُضمن الإعدادات الإضافية بعد تحليل جميع وسائط سطر الأوامر.
    لاحظ أن كل مسار يحتوي على تكوين إضافي يُحلل مرة واحدة فقط، حتى لو ضُمّن أكثر من مرة باستخدام Include=. يمكن تضمين التكوينات المبيتة لـ mkosi الخاصة بـ initrd المبدئي، وشجرة الأدوات المبدئية، وصورة الحاسوب الافتراضي المبدئية، وملحق UKI المبدئي عبر تضمين القيم الحرفية mkosi-initrd، أو mkosi-tools، أو mkosi-vm أو mkosi-addon على التوالي. ملاحظة: أسماء التضمين التي تبدأ بأي من الحروف mkosi- أو contrib- محجوزة لاستخدام mkosi نفسها.

  قسم [Config]

Profiles=, --profile=
    تحدد التشكيلات المعطاة. التشكيلة هي ملف تكوين أو دليل في دليل mkosi.profiles/. تُضمن ملفات التكوين وأدلة كل تشكيلة بعد تحليل التكوينات التكميلية في mkosi.conf.d/*.conf.

Dependencies=, --dependency=
    الصور التي تعتمد عليها هذه الصورة، وتُحدد كقائمة مفصولة بفاصلة. جميع الصور المضبوطة في هذا الخيار ستُبنى قبل هذه الصورة.
    عند تحديد هذا الإعداد للصورة "الرئيسة"، فإنه يحدد الصور الفرعية التي يجب بناؤها. انظر قسم BUILDING MULTIPLE IMAGES لمزيد من المعلومات.

MinimumVersion=, --minimum-version=
    أدنى إصدارة من mkosi مطلوبة لبناء هذا الضبط. إذا حُددت عدة مرات، تُستخدم أعلى إصدارة محددة.
    يمكن أيضًا تحديد الإصدار الأدنى كبصمة إيداع git عندما تُسبق بـ commit:، وفي هذه الحالة يجب تنفيذ mkosi من نسخة مستخرجة من git (checkout) ويجب أن تكون بصمة إيداع git المحددة سلفًا للإيداع المستخرج حاليًا في المستودع الذي تُنفذ منه mkosi.

ConfigureScripts=, --configure-script=
    يقبل قائمة مفصولة بفاصلة من المسارات للملفات التنفيذية التي تُستخدم كنصوص ضبط برمجية لهذه الصورة. راجع قسم SCRIPTS لمزيد من المعلومات.

PassEnvironment=, --pass-environment=
    تقبل قائمة بأسماء متغيرات البيئة مفصولة بمسافات. عند بناء صور متعددة، تُمرر متغيرات البيئة المدرجة إلى كل صورة فرعية على حدة كما لو كانت إعدادات "شاملة". انظر قسم BUILDING MULTIPLE IMAGES لمزيد من المعلومات.

  قسم [UKIProfile]
يمكن استخدام قسم UKIProfile في ملفات تكوين تشكيلة UKI التي تُمرر لإعداد UnifiedKernelImageProfiles=. يمكن تحديد الإعدادات التالية في قسم UKIProfile:

Profile=
    محتويات قسم .profile في تشكيلة UKI. تقبل قائمة من أزواج مفتاح/قيمة مفصولة بـ =. يجب تحديد المفتاح ID=. انظر مواصفة UKI https://uapi-group.org/specifications/specs/unified_kernel_image/#multi-profile-ukis للاطلاع على قائمة كاملة بالمفاتيح الممكنة.

Cmdline=
    خيارات إضافية لسطر أوامر النواة لتشكيلة UKI. تقبل قائمة مفصولة بمسافات من وسائط سطر أوامر النواة الإضافية. لاحظ أن قسم .cmdline النهائي سيكون مزيجًا من قسم .cmdline الأساسي ووسائط سطر أوامر النواة الإضافية المحددة بهذا الإعداد.

SignExpectedPcr=
    توقيع قياسات PCR المتوقعة لتشكيلة UKI هذه. يقبل قيمة منطقية. مفعّل مبدئياً.

  المحددات
يمكن الوصول إلى القيمة الحالية لمختلف الإعدادات عند تحليل ملفات التكوين باستخدام المحددات (specifiers). لكتابة حرف % حرفيًا في ملف تكوين دون معاملته كمحدد، استخدم %%. المحددات التالية مدعومة:

الإعداد | المحدد
Distribution= | %d
Release= | %r
Architecture= | %a
Format= | %t
Output= | %o
OutputDirectory= | %O
ImageId= | %i
ImageVersion= | %v

توجد أيضًا محددات مستقلة عن الإعدادات:

المحدد | القيمة
%C | الدليل الأب لملف الضبط الحالي
%P | دليل العمل الحالي
%D | الدليل الذي استُدعي فيه mkosi
%I | اسم الصورة الفرعية الحالية في mkosi.images

أخيراً، هناك محددات مشتقة من أحد الإعدادات:

المحدد | القيمة
%F | نظام الملفات المبدئي للتوزيعة المضبوطة

لاحظ أن دليل العمل الحالي يتغير أثناء قيام mkosi بتحليل تكوينها. تحديدًا، في كل مرة تحلل فيها mkosi دليلاً يحتوي على ملف mkosi.conf، تغير mkosi دليل عملها إلى ذلك الدليل.

لاحظ أن الدليل الذي استُدعيت منه mkosi يتأثر بوسيط سطر الأوامر --directory=.

يوضح الجدول التالي أمثلة لقيم محددات الأدلة المدرجة أعلاه:

 | $D/mkosi.conf | $D/mkosi.conf.d/abc/abc.conf | $D/mkosi.conf.d/abc/mkosi.conf
%C | $D | $D/mkosi.conf.d | $D/mkosi.conf.d/abc
%P | $D | $D | $D/mkosi.conf.d/abc
%D | $D | $D | $D

  التوزيعات المدعومة
يمكن إنشاء صور تحتوي على تثبيتات للتوزيعات التالية:

•   فيدورا لينكس

•   دبيان

•   كالي لينكس

•   أوبونتو

•   آرتش لينكس

•   أوبن سوزي

•   ماجيا

•   سنت أو إس

•   RHEL

•   RHEL UBI

•   OpenMandriva

•   Rocky Linux

•   Alma Linux

•   Azure Linux

•   postmarketOS

•   بلا (يتطلب من المستخدم توفير نظام ملفات جذر (rootfs) مبني مسبقًا)

نظريًا، يمكن استخدام أي توزيعة على المضيف لبناء صور تحتوي على أي توزيعة أخرى، طالما أن الأدوات اللازمة متاحة. تحديدًا، أي توزيعة توفر حزمة apt يمكن استخدامها لبناء صور Debian أو Kali أو Ubuntu. وأي توزيعة توفر حزمة dnf يمكن استخدامها لبناء صور لأي من التوزيعات القائمة على RPM. وأي توزيعة توفر حزمة pacman يمكن استخدامها لبناء صور Arch Linux. وأي توزيعة توفر حزمة zypper يمكن استخدامها لبناء صور openSUSE. التوزيعات الأخرى وأدوات أتمتة البناء لأنظمة لينكس المضمنة مثل Buildroot وOpenEmbedded وYocto Project يمكن استخدامها باختيار التوزيعة custom (مخصصة)، وملء نظام الملفات الجذر (rootfs) عبر مزيج من الأشجار الأساسية، والأشجار الهيكلية، وسكربتات التحضير.

حاليًا، تحزم Fedora Linux جميع الأدوات ذات الصلة بدءًا من إصدارة Fedora 28.

لاحظ أنه عند عدم استخدام مرآة مخصصة، لا يمكن بناء صور RHEL إلا من نظام مضيف لديه اشتراك RHEL (يُنشأ باستخدام subscription-manager على سبيل المثال).

تدفق التنفيذ
تدفق التنفيذ لـ mkosi build. القيم/الاستدعاءات المبدئية موضحة بين قوسين. عند البناء مع خيار --incremental=yes، تُنشئ mkosi خبيئة لتثبيت التوزيعة إذا لم تكن موجودة بالفعل، وتستبدل تثبيت التوزيعة في التشغيلات اللاحقة ببيانات من تلك المخبوءة.

1.  حلل خيارات واجهة سطر الأوامر

2.  حلل ملفات الضبط

3.  تشغيل سكربتات الضبط (mkosi.configure)

4.  إذا لم يكن التشغيل بصلاحيات الجذر، تُفصل مساحة أسماء المستخدمين (unshare) ويُسند نطاق subuid المضبوط في /etc/subuid و /etc/subgid إليها.

5.  افصل مساحة أسماء الوصل

6.  أعد وصل المجلدات التالية للقراءة فقط إذا كانت موجودة:

    •   /usr

    •   /etc

    •   /opt

    •   /srv

    •   /boot

    •   /efi

    •   /media

    •   /mnt

ثم، لكل صورة، ننفذ الخطوات التالية:

1.  انسخ أشجار المعزل (sandbox) إلى مساحة العمل

2.  زامن البيانات الوصفية لمستودع مدير الحزم

3.  تشغيل سكربتات المزامنة (mkosi.sync)

4.  نسخ الأشجار الأساسية (--base-tree=) إلى الصورة

5.  أعد استخدام صورة مخبوءة إذا توفرت

6.  انسخ لقطة من البيانات الوصفية لمستودع مدير الحزم إلى الصورة

7.  نسخ الأشجار الهيكلية (mkosi.skeleton) إلى الصورة

8.  ثبّت التوزيعة والحزم داخل الصورة

9.  تشغيل سكربتات التحضير على الصورة مع وسيط final (mkosi.prepare)

10. ثبّت حزم البناء في الطبقة الفوقية (overlay) إذا ضُبطت أي سكربتات بناء

11. تشغيل سكربتات التحضير على الغطاء (overlay) مع وسيط build إذا كانت هناك سكربتات بناء مضبوطة (mkosi.prepare)

12. خزن الصورة في الخبيئة إذا كان ذلك مضبوطًا (--incremental=yes)

13. تشغيل سكربتات البناء على الصورة + الغطاء إذا كانت هناك سكربتات بناء مضبوطة (mkosi.build)

14. إنهاء البناء إذا كان تنسيق المخرجات none مضبوطًا

15. انسخ مخرجات سكربتات البناء إلى داخل الصورة

16. نسخ الأشجار الإضافية إلى الصورة (mkosi.extra)

17. تشغيل سكربتات ما بعد التثبيت (mkosi.postinst)

18. كتابة ملفات التكوين المطلوبة لـ Ssh= و Autologin= و MakeInitrd=

19. تثبيت systemd-boot وضبط الإقلاع الآمن إذا كان ذلك مضبوطًا (--secure-boot=yes)

20. شغّل systemd-sysusers

21. شغّل systemd-tmpfiles

22. تشغيل systemctl preset-all

23. شغّل depmod

24. شغّل systemd-firstboot

25. شغّل systemd-hwdb

26. إزالة الحزم والملفات (RemovePackages=، RemoveFiles=)

27. شغّل إعادة وسم SELinux إذا كانت سياسة SELinux مثبتة

28. تشغيل سكربتات الإنهاء (mkosi.finalize)

29. ولّد صورة نواة موحدة إذا ضُبط ذلك

30. ولّد صيغة المخرجات النهائية

31. تشغيل سكربتات ما بعد المخرجات (mkosi.postoutput)

سكربتات
للسماح بتخصيص الصورة الذي لا يمكن تنفيذه باستخدام ميزات mkosi المبيتة، تدعم mkosi تشغيل سكربتات في نقاط مختلفة أثناء عملية بناء الصورة لتخصيصها حسب الحاجة. تُنفذ السكربتات على نظام المضيف كجذر (إما الجذر الحقيقي أو الجذر داخل مساحة أسماء المستخدمين التي أنشأتها mkosi عند التشغيل بدون امتيازات) مع بيئة مخصصة لتبسيط تعديل الصورة. لكل سكربت، تُوصل مصادر البناء المضبوطة (BuildSources=) في دليل العمل الحالي قبل تشغيل السكربت فيه. يُضبط $SRCDIR ليشير إلى دليل العمل الحالي. السكربتات التالية مدعومة:

•   إذا وُجد mkosi.configure (ConfigureScripts=)، فإنه يُنفذ قبل بناء الصورة. يمكن استخدام هذا السكربت لتعديل التكوين ديناميكيًا. يتلقى التكوين متسلسلاً بتنسيق JSON عبر stdin ويجب أن يخرج التكوين المعدل بتنسيق JSON عبر stdout. لاحظ أن هذا السكربت يعمل فقط عند بناء أو إقلاع الصورة (أوامر build و vm و boot و shell). إذا ضُبطت شجرة أدوات مبدئية، فستُبنى قبل تشغيل سكربتات الضبط، وستعمل سكربتات الضبط مع توفر شجرة الأدوات. وهذا يعني أيضًا أن التعديلات التي تجريها سكربتات الضبط لن تكون مرئية في مخرجات الملخص (summary).

•   إذا وُجد mkosi.sync (SyncScripts=)، فإنه يُنفذ قبل بناء الصورة. يمكن استخدام هذا السكربت لتحديث مختلف المصادر المستخدمة في بناء الصورة. إحدى حالات الاستخدام هي تشغيل git pull على مستودعات المصادر المختلفة قبل بناء الصورة. تحديدًا، لا ينطبق إعداد BuildSourcesEphemeral= على سكربتات المزامنة، مما يعني إمكانية استخدامها لتحديث مصادر البناء حتى لو كان هذا الإعداد مفعلًا.

•   إذا وُجد mkosi.prepare (PrepareScripts=)، فإنه يُستدعى أولاً مع وسيط final، فور تثبيت حزم البرمجيات. ثم يُستدعى مرة ثانية مع معامل سطر الأوامر build، فور تثبيت حزم البناء ووصل غطاء البناء فوق الدليل الجذر للصورة. يمتلك هذا السكربت صلاحية الوصول للشبكة ويمكن استخدامه لتثبيت حزم من مصادر أخرى غير مدير حزم التوزيعة (مثل pip، و npm، إلخ)، بعد تثبيت جميع الحزم ولكن قبل وضع الصورة في الخبيئة (إذا كان الوضع التزايدي مفعلًا). وبخلاف التثبيت العام، من الآمن تثبيت الحزم في النظام (pip install، npm install -g) بدلاً من $SRCDIR نفسه لأن صورة البناء تُستخدم لمشروع واحد فقط ويمكن التخلص منها وإعادة بنائها بسهولة، فلا يوجد خطر تضارب الاعتماديات أو تلويث نظام المضيف.

•   إذا وُجد mkosi.build (BuildScripts=)، فإنه يُنفذ مع وصل غطاء البناء فوق الدليل الجذر للصورة. عند تشغيل سكربت البناء، يشير $DESTDIR إلى دليل يجب على السكربت وضع أي ملفات مولدة فيه لكي تنتهي في الصورة. لاحظ أن أنظمة البناء القائمة على make و automake و meson تحترم عمومًا $DESTDIR، مما يجعل بناء أشجار المصادر من سكربت البناء أمرًا طبيعيًا جدًا. بعد تشغيل سكربت البناء، تُنسخ محتويات $DESTDIR إلى الصورة.

•   إذا وُجد mkosi.postinst (PostInstallationScripts=)، فإنه يُنفذ بعد تثبيت شجرة البناء (الاختيارية) والأشجار الإضافية. يمكن استخدام هذا السكربت لتعديل الصور دون أي قيود، بعد تثبيت جميع حزم البرمجيات والمصادر المبنية.

•   إذا وُجد mkosi.finalize (FinalizeScripts=)، فإنه يُنفذ كآخر خطوة في تحضير الصورة.

•   إذا وُجد mkosi.postoutput (PostOutputScripts=)، فإنه يُنفذ فور توليد جميع ملفات المخرجات، وقبل نقلها نهائيًا إلى دليل المخرجات. يمكن استخدام هذا لتوليد مخرجات إضافية أو بديلة، مثل SHA256FILES أو بيانات SBOM.

•   إذا وُجد mkosi.clean (CleanScripts=)، فإنه يُنفذ فور تنظيف مخرجات بناء سابق. يمكن لسكربت التنظيف تنظيف أي مخرجات لا تعرفها mkosi (مثل الآثار الناتجة عن SplitArtifacts=partitions أو حزم RPM التي بُنيت في سكربت بناء). لاحظ أن هذا السكربت لا يستخدم شجرة الأدوات حتى لو كانت مضبوطة.

•   إذا وُجد mkosi.version وكان قابلاً للتنفيذ، فإنه يُشغل أثناء تحليل التكوين ويملأ ImageVersion= بالمخرجات من stdout. يمكن استخدام هذا لتتبع الإصدارات خارجيًا، مثل استخدام git describe أو date '+%Y-%m-%d'. لاحظ أن هذا السكربت يُنفذ على نظام المضيف دون أي عزل (sandboxing).

•   إذا وُجد mkosi.rootpw وكان قابلاً للتنفيذ، فإنه يُشغل أثناء تحليل التكوين ويملأ RootPassword= بالمخرجات من stdout. يمكن استخدام هذا لتوليد كلمة سر عشوائيًا، ويمكن تذكرها عبر إخراجها إلى stderr أو بقراءة $MKOSI_CONFIG في سكربت آخر (مثل mkosi.postoutput). لاحظ أن هذا السكربت يُنفذ على نظام المضيف دون أي عزل.

إذا استخدم سكربت الامتداد .chroot، فستقوم mkosi بتغيير الجذر (chroot) إلى داخل الصورة باستخدام mkosi-chroot (انظر أدناه) قبل تنفيذ السكربت. على سبيل المثال، إذا وُجد mkosi.postinst.chroot، فستقوم mkosi بتغيير الجذر إلى داخل الصورة وتنفيذه كسكربت ما بعد التثبيت.

بدلاً من سكربت في ملف واحد، ستقرأ mkosi أيضًا جميع الملفات بترتيب معجمي من الأدلة التي تنتهي بـ .d وتحمل اسمًا مناسبًا، مثلاً ستُستخدم جميع الملفات في mkosi.build.d كسكربتات بناء. هذا مدعوم في:

•   mkosi.sync.d,

•   mkosi.prepare.d,

•   mkosi.build.d,

•   mkosi.postinst.d,

•   mkosi.finalize.d,

•   mkosi.postoutput.d، و

•   mkosi.clean.d.

يمكن دمج هذا مع امتداد .chroot، مثلاً mkosi.build.d/01-foo.sh سيُشغل دون تغيير الجذر إلى الصورة، بينما mkosi.build.d/02-bar.sh.chroot سيُشغل بعد تغيير الجذر إلى الصورة أولاً.

تتلقى السكربتات التي ينفذها mkosi متغيرات البيئة التالية:

•   $ARCHITECTURE يحتوي على المعمارية من إعداد Architecture=. إذا لم يُضبط الإعداد، فسيحتوي على المعمارية الأصلية لجهاز المضيف. انظر توثيق Architecture= للاطلاع على القيم الممكنة لهذا المتغير.

•   $QEMU_ARCHITECTURE يحتوي على المعمارية من $ARCHITECTURE بالتنسيق الذي يستخدمه qemu. مفيد للعثور على ملف qemu التنفيذي ( qemu-system-$QEMU_ARCHITECTURE).

•   $EFI_ARCHITECTURE يحتوي على المعمارية من $ARCHITECTURE بالتنسيق الذي يستخدمه UEFI. يكون غير معين في المعماريات التي لا تدعم UEFI.

•   $DISTRIBUTION يحتوي على التوزيعة من إعداد Distribution=.

•   $RELEASE يحتوي على الإصدارة (release) من إعداد Release=.

•   $DISTRIBUTION_ARCHITECTURE يحتوي على المعمارية من $ARCHITECTURE بالتنسيق الذي تستخدمه التوزيعة المضبوطة.

•   $PROFILES يحتوي على التشكيلات من إعداد Profiles= كسلسلة نصية مفصولة بفاصلات.

•   يُضبط $CACHED على 1 إذا كانت هناك صورة مخبوءة متاحة، وعلى 0 بخلاف ذلك.

•   $CHROOT_SCRIPT يحتوي على مسار السكربت الجاري تشغيله نسبةً إلى الدليل الجذر للصورة. حالة الاستخدام الرئيسة لهذا المتغير هي بالاشتراك مع سكربت mkosi-chroot. انظر وصف mkosi-chroot أدناه لمزيد من المعلومات.

•   $SRCDIR يحتوي على المسار إلى الدليل الذي استُدعيت منه mkosi، مع وصل أي مصادر بناء مضبوطة فوقه. $CHROOT_SRCDIR يحتوي على القيمة التي ستؤول إليها $SRCDIR بعد استدعاء mkosi-chroot.

•   لا يُعرف $BUILDDIR إلا إذا وُجد mkosi.builddir وكان يشير إلى دليل البناء المراد استخدامه. هذا مفيد لجميع أنظمة البناء التي تدعم البناء خارج الشجرة لإعادة استخدام الآثار المبنية بالفعل من تشغيلات سابقة. $CHROOT_BUILDDIR يحتوي على القيمة التي ستؤول إليها $BUILDDIR بعد استدعاء mkosi-chroot.

•   $DESTDIR هو دليل يمكن وضع أي برمجيات مثبتة مولدة بواسطة سكربت البناء فيه. لا يُضبط هذا المتغير إلا عند تنفيذ سكربت بناء. $CHROOT_DESTDIR يحتوي على القيمة التي ستؤول إليها $DESTDIR بعد استدعاء mkosi-chroot.

•   يشير $OUTPUTDIR إلى دليل التحضير المستخدم لتخزين آثار البناء المولدة أثناء العملية. $CHROOT_OUTPUTDIR يحتوي على القيمة التي ستؤول إليها $OUTPUTDIR بعد استدعاء mkosi-chroot.

•   يشير $PACKAGEDIR إلى الدليل الذي يحتوي على مستودع الحزم المحلي. يمكن لسكربتات البناء إضافة مزيد من الحزم إلى المستودع المحلي عبر كتابة الحزم في $PACKAGEDIR.

•   يشير $ARTIFACTDIR إلى الدليل المستخدم لتناقل آثار البناء المولدة أثناء العملية وجعلها متاحة لاستخدام mkosi. هذا يشبه PACKAGEDIR، ولكنه مخصص للآثار التي قد لا تكون حزمًا يفهمها مدير الحزم، مثل initrds المنشأة بواسطة مولدات أخرى غير mkosi. يمكن لسكربتات البناء إضافة مزيد من الآثار إلى الدليل بوضعها في $ARTIFACTDIR. الملفات في هذا الدليل متاحة فقط للبناء الحالي ولا تُنسخ للخارج مثل محتويات $OUTPUTDIR.

    سيستخدم mkosi أيضًا مجلدات فرعية معينة من مجلد النواتج لاستخدام محتوياتها آليًا في خطوات معينة. حاليًا، يُستخدم المجلدان الفرعيان التاليان في مجلد النواتج بواسطة mkosi:

    •   io.mkosi.microcode: تُستخدم جميع الملفات في هذا الدليل كملفات كود دقيق (microcode)، أي أنها تُسبق إلى initrds بترتيب معجمي.

    •   io.mkosi.initrd: تُستخدم جميع الملفات في هذا الدليل كـ initrds وتُدمج بترتيب معجمي.

    يُوصى بأن يضع مستخدمو $ARTIFACTDIR الأشياء الخاصة بهم في دليل يحمل مساحة أسماء مماثلة، مثلاً local.my.namespace.

•   $BUILDROOT هو الدليل الجذر للصورة الجاري بناؤها، مع وصل غطاء البناء فوقه اختياريًا اعتمادًا على السكربت الذي يُنفذ.

•   تكون قيمة $WITH_DOCS إما 0 أو 1 اعتمادًا على ما إذا كان قد طُلب البناء مع أو بدون الوثائق المثبتة (WithDocs=yes). يجب أن يمنع سكربت البناء تثبيت أي وثائق للحزم في $DESTDIR في حال كانت قيمة $WITH_DOCS هي 0.

•   تكون قيمة $WITH_TESTS إما 0 أو 1 اعتمادًا على ما إذا كان قد طُلب البناء مع أو بدون تشغيل مجموعة الاختبارات (WithTests=no). يجب أن يتجنب سكربت البناء تشغيل أي اختبارات وحدة أو اختبارات تكامل في حال كانت قيمة $WITH_TESTS هي 0.

•   تكون قيمة $WITH_NETWORK إما 0 أو 1 اعتمادًا على ما إذا كان البناء يُنفذ مع أو بدون شبكة (WithNetwork=no). يجب أن يتجنب سكربت البناء أي اتصال بالشبكة في حال كانت قيمة $WITH_NETWORK هي 0.

•   يُعرف $SOURCE_DATE_EPOCH إذا طُلب ذلك (عبر SourceDateEpoch=TIMESTAMP، أو Environment=SOURCE_DATE_EPOCH=TIMESTAMP أو متغير بيئة المضيف $SOURCE_DATE_EPOCH). هذا مفيد لجعل عمليات البناء قابلة للتكرار (reproducible). انظر SOURCE_DATE_EPOCH (https://reproducible-builds.org/specs/source-date-epoch/) لمزيد من المعلومات.

•   $MKOSI_UID و $MKOSI_GID هما على التوالي مُعرف المستخدم (uid) ومُعرف المجموعة (gid) للمستخدم الذي استدعى mkosi.

•   $MKOSI_CONFIG هو ملف يحتوي على ملخص بتنسيق json لإعدادات الصورة الحالية. يمكن تحليل هذا الملف برمجياً داخل السكربتات للوصول إلى كافة إعدادات الصورة الحالية.

•   $IMAGE_ID يحتوي على المعرّف من إعداد ImageId= أو خيار --image-id=.

•   $IMAGE_VERSION يحتوي على الإصدارة من إعداد ImageVersion= أو خيار --image-version=.

•   $MKOSI_DEBUG هي إما 0 أو 1 اعتماداً على ما إذا كانت مخرجات التنقِيح مفعلة أم لا.

راجع هذا الجدول لمعرفة أي السكربتات تتلقى أي متغيرات بيئة:

المتغير | configure | sync | prepare | build | postinst | finalize | postoutput | clean
ARCHITECTURE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
ARTIFACTDIR |  |  | ✓ | ✓ | ✓ | ✓ |  |
BUILDDIR |  |  |  | ✓ | ✓ | ✓ |  |
BUILDROOT |  |  | ✓ | ✓ | ✓ | ✓ |  |
CACHED |  | ✓ |  |  |  |  |  |
CHROOT_BUILDDIR |  |  |  | ✓ |  |  |  |
CHROOT_DESTDIR |  |  |  | ✓ |  |  |  |
CHROOT_OUTPUTDIR |  |  |  |  | ✓ | ✓ |  |
CHROOT_SCRIPT |  |  | ✓ | ✓ | ✓ | ✓ |  |
CHROOT_SRCDIR |  |  | ✓ | ✓ | ✓ | ✓ |  |
MKOSI_DEBUG | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
DESTDIR |  |  |  | ✓ |  |  |  |
DISTRIBUTION | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
DISTRIBUTION_ARCHITECTURE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
EFI_ARCHITECTURE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
IMAGE_ID | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
IMAGE_VERSION | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
MKOSI_CONFIG |  | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
MKOSI_GID | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
MKOSI_UID | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
OUTPUTDIR |  |  |  |  | ✓ | ✓ | ✓ | ✓
PACKAGEDIR |  |  | ✓ | ✓ | ✓ | ✓ |  |
PROFILES | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  | ✓
QEMU_ARCHITECTURE | ✓ |  |  |  |  |  |  |
RELEASE | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
SOURCE_DATE_EPOCH |  |  | ✓ | ✓ | ✓ | ✓ |  | ✓
SRCDIR | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
WITH_DOCS |  |  | ✓ | ✓ |  |  |  |
WITH_NETWORK |  |  | ✓ | ✓ | ✓ | ✓ |  |
WITH_TESTS |  |  | ✓ | ✓ |  |  |  |

بالإضافة إلى ذلك، عند تنفيذ سكربت ما، تُجعل بضعة سكربتات متاحة عبر $PATH لتبسيط حالات الاستخدام الشائعة.

•   mkosi-chroot: سيقوم هذا السكربت بتغيير الجذر (chroot) إلى داخل الصورة وتنفيذ الأمر المعطى. بالإضافة إلى تغيير الجذر، سيقوم أيضًا بوصل ملفات وأدلة متنوعة ($SRCDIR, $DESTDIR, $BUILDDIR, $OUTPUTDIR, $CHROOT_SCRIPT) داخل الصورة وتعديل متغيرات البيئة المقابلة لتشير إلى المواقع داخل الصورة. كما سيقوم بوصل أنظمة ملفات APIVFS (/proc, /dev, ...) لضمان عمل السكربتات والأدوات المنفذة داخل بيئة الجذر المغيرة بشكل سليم. كما ينقل /etc/resolv.conf من المضيف إلى بيئة الجذر المغيرة إذا طُلب ذلك ليعمل حل أسماء النطاقات (DNS) داخلها. بعد خروج أمر mkosi-chroot، تُنظف نقاط الوصل المتنوعة.

    على سبيل المثال، لاستدعاء ls داخل الصورة، استخدم ما يلي:

            mkosi-chroot ls ...

    لتنفيذ السكربت بالكامل داخل الصورة، أضف اللاحقة .chroot إلى الاسم (mkosi.build.chroot بدلاً من mkosi.build، إلخ).

•   لكافة مديري الحزم المدعومين (dnf, rpm, apt, dpkg, pacman, zypper)، توضع سكربتات بنفس الأسماء في $PATH تضمن عمل هذه الأوامر على الدليل الجذري للصورة بالإعدادات المقدمة من المستخدم بدلاً من العمل على نظام المضيف. هذا يعني أنه يمكنك من داخل السكربت القيام بـ dnf install vim مثلاً لتثبيت vim داخل الصورة.

    بالإضافة إلى ذلك، ستقوم أوامر mkosi-install و mkosi-reinstall و mkosi-upgrade و mkosi-remove باستدعاء العملية المقابلة لمدير الحزم المستخدم لبناء الصورة.

•   يُستدعى git آلياً مع الخيار safe.directory=* لتجنب أخطاء الصلاحيات عند التشغيل كمستخدم جذر (root) في فضاء أسماء مستخدم.

•   يُستدعى useradd و groupadd آلياً مع الخيار --root=$BUILDROOT عند تنفيذهما خارج الصورة.

عند تنفيذ السكربتات، تُجعل أيضًا أي أدلة لا تزال قابلة للكتابة للقراءة فقط (/home, /var, /root, ...) وتبقى فقط المجموعة الدنيا من الأدلة التي تحتاج للكتابة قابلة لذلك. هذا لضمان عدم عبث السكربتات بنظام المضيف عندما يعمل mkosi بصلاحيات الجذر.

لاحظ أنه عند تنفيذ السكريبتات، تُجعل جميع أدلة المصدر زائلة، مما يعني أن جميع التغييرات التي أُجريت على أدلة المصدر أثناء تشغيل السكريبتات تُهمل بعد انتهاء تنفيذها. استخدم أدلة المخرجات أو البناء أو الخبيئة إذا كنت بحاجة لاستمرار البيانات بين عمليات البناء.

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

•   يمكن استخدام دليل mkosi.skeleton/ أو أرشيف mkosi.skeleton.tar لإدراج ملفات داخل الصورة. تُنسخ الملفات قبل تثبيت حزم التوزيعة في الصورة. يسمح هذا بإنشاء ملفات يجب توفيرها مبكراً، على سبيل المثال لضبط مدير الحزم أو تعيين إعدادات systemd المسبقة.

    عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.

•   يمكن استخدام دليل mkosi.extra/ أو أرشيف mkosi.extra.tar لإدراج ملفات إضافية في الصورة، زيادة على ما تتضمنه التوزيعة في حزمها. هي مشابهة لـ mkosi.skeleton/ و mkosi.skeleton.tar، لكن الملفات تُنسخ إلى شجرة أدلة الصورة بعد تثبيت نظام التشغيل.

    عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.

•   يمكن استخدام دليل mkosi.sandbox/ أو أرشيف mkosi.sandbox.tar لضبط مدير الحزم دون إدراج الملفات داخل الصورة. إذا كان يجب تضمين الملفات في الصورة، فينبغي استخدام mkosi.skeleton/ و mkosi.skeleton.tar بدلاً من ذلك.

    عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.

•   سيُنسخ ملف إعدادات nspawn المسمى mkosi.nspawn إلى نفس مكان ملف صورة المخرجات، في حال وجوده. هذا مفيد لأن nspawn يبحث عن ملفات الإعدادات بجانب ملفات الصور التي يقلع منها، للحصول على إعدادات تشغيل حاوية إضافية.

•   يُستخدم دليل mkosi.cache/ آلياً، في حال وجوده، كخبيئة لتنزيل الحزم، وذلك لتسريع عمليات تشغيل الأداة المتكررة.

•   يُستخدم دليل mkosi.builddir/ آلياً، في حال وجوده، كدليل بناء خارج الشجرة، إذا كانت أوامر البناء في سكربتات mkosi.build تدعم ذلك. تحديداً، سيُوصل هذا الدليل داخل حاوية البناء، وسيُضبط متغير البيئة $BUILDDIR ليشير إليه عند استدعاء سكربتات البناء. يمكن لسكربت البناء حينها استخدام هذا الدليل كدليل بناء، لعمليات البناء خارج الشجرة بأسلوب automake أو ninja. يسرع هذا عمليات البناء بشكل ملحوظ، خاصة عند استخدام mkosi في الوضع التزايدي (-i): حيث لا تقتصر إعادة الاستخدام على الصورة وطبقة البناء فحسب، بل تشمل أيضًا شجرة البناء بين الاستدعاءات المتلاحقة. لاحظ أنه إذا لم يكن هذا الدليل موجوداً، فلن يُضبط متغير البيئة $BUILDDIR، ويُترك لسكربتات البناء قرار القيام ببناء داخل الشجرة أو خارجها، وتحديد دليل البناء المستخدم.

•   يمكن استخدام ملف mkosi.rootpw لتوفير كلمة سر المستخدم الجذر (root) للصورة. إذا كانت كلمة السر مسبوقة بـ hashed: فستُعامل ككلمة سر جذر معمّاة (hashed) مسبقاً. يمكن أن تتبع كلمة السر اختيارياً بحرف سطر جديد يُحذف ضمناً. يجب أن تكون صلاحيات الوصول للملف 0600 أو أقل. إذا لم يكن هذا الملف موجوداً، تُعين كلمة سر الجذر المبدئية للتوزيعة (مما يعني عادةً حظر الوصول للمستخدم الجذر).

•   يوفر ملف mkosi.passphrase عبارة المرور لاستخدامها عند اختيار تعمية LUKS. يجب أن يحتوي على عبارة المرور حرفياً، وألا ينتهي بحرف سطر جديد (أي بنفس التنسيق الذي تتوقعه ملفات عبارة المرور في cryptsetup و /etc/crypttab). يجب أن تكون صلاحيات الوصول للملف 0600 أو أقل.

•   يحتوي الملفان mkosi.crt و mkosi.key على شهادة X.509 ومفتاح PEM خاص لاستخدامهما عندما يتطلب الأمر توقيعاً (الإقلاع الآمن UEFI، verity، ...).

•   يُستخدم دليل mkosi.output/ لتخزين كافة مخلفات البناء.

•   يُستخدم دليل mkosi.credentials/ كمصدر للاعتمادات الإضافية بشكل مشابه لخيار Credentials=. لكل ملف في الدليل، سيُستخدم اسم الملف كاسم للاعتماد وتصبح محتويات الملف هي قيمة الاعتماد، أو إذا كان الملف قابلاً للتنفيذ، سيقوم mkosi بتنفيذ الملف واستخدام مخرجات الأمر إلى stdout كقيمة للاعتماد. سيُتجاهل الإخراج إلى stderr. الاعتمادات المصبوطة عبر Credentials= لها الأولوية على الملفات الموجودة في mkosi.credentials.

•   يُستخدم دليل mkosi.repart/ كمصدر لملفات تعريف الأقسام الخاصة بـ systemd-repart والتي تُمرر إلى systemd-repart عند بناء صورة قرص. إذا لم يكن موجوداً ولم يُضبط إعداد RepartDirectories=، سيعتمد mkosi مبدئياً على ملفات تعريف الأقسام التالية:

    00-esp.conf (إذا كنا نبني صورة قابلة للإقلاع):

            [Partition]
            Type=esp
            Format=vfat
            CopyFiles=/boot:/
            CopyFiles=/efi:/
            SizeMinBytes=512M
            SizeMaxBytes=512M

    05-bios.conf (إذا كنا نبني صورة قابلة للإقلاع عبر BIOS):

            [Partition]
            # UUID لقسم إقلاع BIOS الخاص بـ grub والذي يحتاجه grub على GPT
            # ليغرس نفسه بداخله.
            Type=21686148-6449-6e6f-744e-656564454649
            SizeMinBytes=1M
            SizeMaxBytes=1M

    10-root.conf

            [Partition]
            Type=root
            Format=<distribution-default-filesystem>
            CopyFiles=/
            Minimize=guess

    لاحظ أنه في حال العثور على mkosi.repart/ أو استخدام RepartDirectories=، فلن نستخدم أياً من تعريفات الأقسام المبدئية.

جميع هذه الملفات اختيارية.

لاحظ أن مواقع كل هذه الملفات يمكن أيضًا ضبطها أثناء الاستدعاء عبر مبدلات سطر الأوامر، وكإعدادات في mkosi.conf، في حال كانت الإعدادات المبدئية غير مقبولة للمشروع.

الخزن في الخبيئة
يدعم mkosi ثلاث خبيئات مختلفة لتسريع عمليات إعادة بناء الصور المتكررة. وتحديداً:

1.  يمكن تخزين خبيئة الحزم لمدير حزم التوزيعة بين عمليات البناء. يُضبط هذا عبر خيار --cache-directory= أو دليل mkosi.cache/. يعتمد هذا النوع من التخبئة على مدير حزم التوزيعة، ويقوم بتخبئة حزم التوزيعة (RPM, deb, ...) بعد تنزيلها وقبل فك حزمها.

2.  إذا فُعل وضع البناء التزايدي عبر --incremental=yes، تُنشأ نسخ مخبوءة من الصورة النهائية وطبقة البناء فوراً قبل نسخ مصادر البناء (لطبقة البناء) أو قبل نسخ المخلفات الناتجة عن mkosi.build (في حالة الصورة النهائية). يسمح هذا النوع من التخبئة بتجاوز خطوة فك الحزم المستهلكة للوقت في مديري حزم التوزيعات، ولكنه فعال فقط إذا بقيت قائمة الحزم المستخدمة مستقرة مع تغير مصادر البناء وسكربتاته بانتظام. لاحظ أن هذه الخبيئة تتطلب إفراغاً يدوياً: كلما عُدلت قائمة الحزم، يجب إزالة الصور المخبوءة صراحة قبل إعادة البناء التالية، باستخدام مبدل -f.

3.  أخيراً، يمكن مشاركة دليل مخلفات البناء بين عمليات بناء متعددة باستخدام دليل mkosi.builddir/. يسمح هذا الدليل لأنظمة البناء مثل Meson بإعادة استخدام المصادر المجمعة مسبقاً من بناء سابق، مما يسرع عملية بناء سكربت البناء mkosi.build.

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

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

يمكن توفير أشجار الأدوات عبر خيار ToolsTree=، أو دليل mkosi.tools أو بناؤها آلياً بواسطة mkosi إذا ضُبط الخيار على ToolsTree=yes. لمعظم حالات الاستخدام، يكفي ضبطه لاستخدام أشجار الأدوات المبدئية ويُوصى باستخدام شجرة أدوات.

يمكن بناء أشجار أدوات مخصصة بالكامل كأي صورة mkosi أخرى، ولكن يوفر mkosi تضميناً مدمجاً يقدم حزم شجرة الأدوات المبدئية:

        mkosi --include=mkosi-tools --format=directory

يمكن تخصيص أشجار الأدوات أكثر، بما في ذلك الأشجار المبدئية، عبر متغيرات ToolsTree*= المختلفة بالإضافة إلى ملف أو دليل إعداد mkosi.tools.conf. لا يمكن حالياً تغيير تنسيق مخرجات أشجار الأدوات عبر ملفات الإعداد.

يوضح الجدول التالي التوزيعات التي عُرّفت لها حزم أشجار أدوات مبدئية والحزم المضمنة في تلك الأشجار المبدئية:

 | فيدورا | سنت أو إس | دبيان | كالي | أوبونتو | بنية | أوبن سوزا | بوسط ماركت أو إس
acl | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
apt | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  |
archlinux-keyring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  |
attr | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
bash | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
btrfs-progs | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
ca-certificates | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
coreutils | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
cpio | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
createrepo_c | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
curl | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
debian-keyring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  | ✓
diffutils | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
distribution-gpg-keys | ✓ | ✓ | ✓ | ✓ |  | ✓ | ✓ | ✓
dnf | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
dosfstools | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
e2fsprogs | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
edk2-ovmf | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
erofs-utils | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
findutils | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
git | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
grep | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
grub-tools | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  |
jq | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
kali-archive-keyring |  |  |  | ✓ |  |  |  |
kmod | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
less | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
mtools | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
nano | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
opensc | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
openssh | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
openssl | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
pkcs11-provider | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
perf | ✓ | ✓ | ✓ | ✓ |  | ✓ | ✓ | ✓
sed | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
pacman | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  | ✓
p11-kit | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
policycoreutils | ✓ | ✓ | ✓ | ✓ | ✓ |  | ✓ | ✓
qemu | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
sbsigntools | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
socat | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
squashfs-tools | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
strace | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
swtpm | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
systemd | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
ukify | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
tar | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
ubuntu-keyring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |  |
util-linux | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
virtiofsd | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
virt-firmware | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
xfsprogs | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
xz | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
zstd | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓
zypper | ✓ |  | ✓ | ✓ | ✓ | ✓ | ✓ |

بناء صور متعددة
إذا كان دليل mkosi.images/ موجوداً، سيقوم mkosi بتحميل إعدادات الصور الفرعية الفردية منه وبناء كل منها. يمكن أن تكون إعدادات الصور إما أدلة تحتوي على ملفات إعداد mkosi أو ملفات عادية بالامتداد .conf.

عند العثور على إعدادات صور في mkosi.images/، سيقوم mkosi ببناء الصور المحددة في إعداد Dependencies= للصورة الرئيسة وكافة تبعاتها (أو جميعها إذا لم تُضبط أي صور صراحة باستخدام Dependencies= في إعداد الصورة الرئيس). لإضافة تبعيات بين الصور الفرعية، يمكن استخدام إعداد Dependencies= أيضًا. تُبنى الصور الفرعية دائماً قبل الصورة الرئيس.

عند تعريف الصور، سيقوم mkosi أولاً بقراءة إعداد الصورة الرئيس (الإعداد خارج دليل mkosi.images/)، يليه الإعداد الخاص بالصورة.

تنطبق عدة إعدادات "جامعة" على شجرة الأدوات المبدئية وعلى الصورة الرئيس ولا يمكن ضبطها بشكل منفصل خارج الصورة الرئيس:

•   RepositoryKeyCheck=

•   RepositoryKeyFetch=

•   SourceDateEpoch=

•   CacheOnly=

•   WorkspaceDirectory=

•   PackageCacheDirectory=

•   BuildSources=

•   BuildSourcesEphemeral=

•   ProxyClientCertificate=

•   ProxyClientKey=

•   ProxyExclude=

•   ProxyPeerCertificate=

•   ProxyUrl=

تنطبق عدة إعدادات "شاملة" على الصورة الرئيس وكافة صورها الفرعية ولا يمكن ضبطها بشكل منفصل في الصور الفرعية. الإعدادات التالية شاملة ولا يمكن ضبطها في الصور الفرعية:

•   Architecture=

•   BuildDirectory=

•   CacheDirectory=

•   Distribution=

•   ExtraSearchPaths=

•   Incremental=

•   LocalMirror=

•   Mirror=

•   OutputDirectory=

•   OutputMode=

•   PackageDirectories=

•   Release=

•   RepartOffline=

•   Repositories=

•   SandboxTrees=

•   ToolsTree=

•   ToolsTreeCertificates=

•   UseSubvolumes=

•   SecureBootCertificate=

•   SecureBootCertificateSource=

•   SecureBootKey=

•   SecureBootKeySource=

•   VerityCertificate=

•   VerityCertificateSource=

•   VerityKey=

•   VerityKeySource=

•   VolatilePackageDirectories=

•   WithNetwork=

•   WithTests

توجد أيضًا إعدادات تُمرر إلى الصور الفرعية ولكن يمكن تخطيها. بالنسبة لهذه الإعدادات، القيم المضبوطة صراحةً في الصورة الفرعية ستأخذ الأولوية على القيم المضبوطة في سطر الأوامر أو في إعداد الصورة الرئيسة. حاليًا تُمرر الإعدادات التالية إلى الصور الفرعية ولكن يمكن تخطيها:

•   Profiles=

•   ImageId=

•   ImageVersion=

•   SectorSize=

•   CacheKey=

•   BuildKey=

•   CompressLevel=

•   SignExpectedPcrKey=

•   SignExpectedPcrKeySource=

•   SignExpectedPcrCertificate=

•   SignExpectedPcrCertificateSource=

بالإضافة إلى ذلك، هناك إعدادات متنوعة لا يمكن ضبطها إلا في الصورة الرئيسة ولا تُمرر إلى الصور الفرعية:

•   MinimumVersion=

•   PassEnvironment=

•   ToolsTreeDistribution=

•   ToolsTreeRelease=

•   ToolsTreeProfiles=

•   ToolsTreeMirror=

•   ToolsTreeRepositories=

•   ToolsTreeSandboxTrees=

•   ToolsTreePackages=

•   ToolsTreePackageDirectories=

•   History=

•   كل إعداد في قسم [Runtime]

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

•   BaseTrees=

•   ExtraTrees=

•   Initrds=

للإشارة إلى مخرجات تبعيات الصورة، اضبط ببساطة أيًا من هذه الخيارات بمسار نسبي للمخرجات المطلوب استخدامها في دليل مخرجات التبعية. أو استخدم الوسم %O للإشارة إلى دليل المخرجات.

يمكن العثور على مثال جيد حول كيفية بناء صور متعددة في مستودع systemd على https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images

متغيرات البيئة

•   يتخطى $MKOSI_LESS خيارات less عندما يستدعيه mkosi لتقسيم المخرجات إلى صفحات.

•   يمكن استخدام $MKOSI_DNF لتخطي الملف التنفيذي المستخدم بصفة dnf. يفيد هذا تحديداً للمفاضلة بين dnf و dnf5.

•   يمكن استخدام $EPEL_MIRROR لتخطي موقع المرآة المبدئي المستخدم لمستودعات epel عند استخدام Mirror=. يبحث mkosi مبدئياً عن مستودعات epel في الدليل الفرعي fedora التابع للدليل الأب للمرآة المحددة في Mirror=. على سبيل المثال، إذا ضُبطت المرآة لتكون https://mirror.net/centos-stream سيبحث mkosi عن مستودعات epel في https://mirror.net/fedora/epel.

•   يمكن استخدام SYSEXT_SCOPE و CONFEXT_SCOPE لتخطي القيمة المبدئية لملف extension-release المقابل عند بناء sysext أو confext. تُضبط القيمة مبدئياً لتكون initrd system portable.

أمثلة
أنشئ وشغل صورة GPT خام بنظام ملفات ext4، باسم image.raw:

        # mkosi -p systemd -i boot

أنشئ وشغل صورة GPT قابلة للإقلاع، باسم foobar.raw:

        $ mkosi -d fedora -p kernel-core -p systemd -p systemd-boot -p udev -o foobar.raw
        # mkosi --output foobar.raw boot
        $ mkosi --output foobar.raw vm

أنشئ وشغل صورة Fedora Linux في دليل عادي:

        # mkosi --distribution fedora --format directory boot

أنشئ صورة مضغوطة image.raw.xz مع تثبيت SSH وأضف ملف فحص المجموع:

        $ mkosi --distribution fedora --format disk --checksum=yes --compress-output=yes --package=openssh-clients

داخل دليل المصدر لمشروع يعتمد على automake، اضبط mkosi بحيث يؤدي استدعاء mkosi ببساطة دون أي معاملات إلى بناء صورة نظام تشغيل تحتوي على نسخة مبنية من المشروع في حالته الحالية:

        $ cat >mkosi.conf <<EOF
        [Distribution]
        Distribution=fedora

        [Output]
        Format=disk

        [Content]
        Packages=kernel,systemd,systemd-udev,openssh-clients,httpd
        BuildPackages=make,gcc,libcurl-devel
        EOF
        $ cat >mkosi.build <<EOF
        #!/bin/sh

        if [ "$container" != "mkosi" ]; then
            exec mkosi-chroot "$CHROOT_SCRIPT" "$@"
        fi

        cd $SRCDIR
        ./autogen.sh
        ./configure --prefix=/usr
        make -j `nproc`
        make install
        EOF
        $ chmod +x mkosi.build
        # mkosi -i boot
        # systemd-nspawn -bi image.raw

  طرق مختلفة للإقلاع باستخدام vm
أسهل طريقة لإقلاع آلة افتراضية هي بناء صورة بالمكونات المطلوبة وترك mkosi يستدعي qemu بجميع الخيارات الصحيحة:

        $ mkosi -d fedora -p systemd-udev,systemd-boot,kernel-core build
        $ mkosi -d fedora vm
        ...
        fedora login: root (ولوج آلي)
        [root@fedora ~]#

يتمثل السلوك المبدئي في الإقلاع باستخدام معراض نصي فقط. في هذا النمط، تستخدم رسائل محمل الإقلاع، والنواة، وsystemd، ولاحقًا محث ولوج getty والصدفة نفس الطرفية. يمكن التبديل بين معراض qemu والمراقب بالضغط على Ctrl-a c. يمكن استخدام مراقب qemu على سبيل المثال لحقن مفاتيح خاصة أو إغلاق الحاسوب بسرعة. وبدلاً من ذلك، يمكن إغلاق الحاسوب باستخدام Ctrl-a x.

للإقلاع بنوافذ رسومية، أضف --console=gui:

        $ mkosi -d fedora --console=gui qemu

يمكن إقلاع النواة مباشرة باستخدام mkosi vm -kernel ... -initrd ... -append '...'. يعد هذا أسرع قليلاً لعدم استخدام محمل إقلاع، كما يسهل تجربة نوى مختلفة وأسطر أوامر النواة. لاحظ أنه رغم الاسم، فإن خيار -append في qemu يستبدل سطر أوامر النواة المبدئي المضمن في النواة وأي مواصفات -append سابقة.

يُنسخ UKI أيضًا إلى دليل المخرجات ويمكن إقلاعه مباشرة:

        $ mkosi vm -- -kernel mkosi.output/fedora~38/image.efi

عند الإقلاع باستخدام نواة خارجية، لا نحتاج لوجود النواة داخل الصورة، ولكننا لا نزال نريد تثبيت وحدات النواة.

من الممكن أيضًا إجراء إقلاع نواة مباشر إلى محمل إقلاع، بالاستفادة من حقيقة أن systemd-boot(7) هو ملف UEFI ثنائي صالح:

        $ mkosi vm -- -kernel /usr/lib/systemd/boot/efi/systemd-bootx64.efi

في هذا السيناريو، تُحمل النواة من ESP في الصورة بواسطة systemd-boot.

المتطلبات
تتوفر حزم mkosi لمختلف التوزيعات: Debian، و Kali، و Ubuntu، و Arch Linux، و Fedora Linux، و OpenMandriva، و Gentoo، و postmarketOS. لاحظ أنه قد مضى وقت طويل منذ آخر إصدار والحزم التي تشحنها التوزيعات قديمة جدًا. نوصي حاليا بتشغيل mkosi من git حتى يصدر إصدار جديد.

يتطلب mkosi نواة لينكس توفر mount_setattr() والتي قُدمت في الإصدار 5.12.

يتطلب mkosi حاليًا systemd 254 لبناء صور أقراص قابلة للإقلاع.

عند عدم استخدام حزم التوزيعات، تأكد من تثبيت التبعات اللازمة. على سبيل المثال، في Fedora Linux تحتاج إلى:

        # dnf install btrfs-progs apt dosfstools mtools edk2-ovmf e2fsprogs squashfs-tools gnupg python3 tar xfsprogs xz zypper sbsigntools

في ديبيان/كالي/أوبونتو، قد يلزم تثبيت حزم ubuntu-keyring و/أو ubuntu-archive-keyring و/أو kali-archive-keyring و/أو debian-archive-keyring صراحةً، بالإضافة إلى apt، بناءً على نوع صور التوزيعات المطلوب بناؤها.

لاحظ أن الحد الأدنى المطلوب من نسخة Python هو 3.9.

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

لمعلومات عن أوبونتو، التي تفرض هذه القيود باستخدام AppArmor، راجع الموقع https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces. للأنظمة الأخرى، ابحث في معاملات sysctl من نوع kernel.unprivileged_userns_clone أو user.max.user_namespace.

لأنظمة أوبونتو، يمكن إزالة القيود عن mkosi بتعديل هذه القصاصة لتشير إلى ملف mkosi التنفيذي لديك، ونسخها إلى /etc/apparmor.d/resolved.path.to.mkosi، ثم تشغيل systemctl reload apparmor:

        abi <abi/4.0>,

        include <tunables/global>

        /resolved/path/to/mkosi flags=(default_allow) {
          userns,
        }

الأسئلة الشائعة (FAQ)

•   لماذا لا يعمل mkosi vm مع KVM في ديبيان/كالي/أوبونتو؟

    بينما تسمح التوزيعات الأخرى بالوصول إلى /dev/kvm، لا يُسمح بذلك في ديبيان/كالي/أوبونتو إلا للمستخدمين في مجموعة kvm. ولأن mkosi يلغي مشاركة فضاء أسماء المستخدمين (unshares) عند العمل دون صلاحيات، فإنه يفقد الوصول إلى مجموعة kvm حتى لو كان المستدعِي عضواً فيها، وبحلول وقت بدء qemu لا نكون نملك حق الوصول إلى /dev/kvm بعد الآن. كحل بديل، يمكن تغيير أذونات عقد الجهاز إلى 0666 وهو ما يكفي لجعل KVM يعمل دون صلاحيات. وللحفاظ على هذه الإعدادات عبر عمليات إعادة التشغيل، انسخ /usr/lib/tmpfiles.d/static-nodes-permissions.conf إلى /etc/tmpfiles.d/static-nodes-permissions.conf وغير نمط /dev/kvm من 0660 إلى 0666.

•   كيف يمكنني إضافة مستخدم عادي إلى صورة؟

    يمكنك استخدام القصاصة التالية في سكربت ما بعد التثبيت:

            useradd --create-home --user-group $USER --password "$(openssl passwd -stdin -6 <$USER_PASSWORD_FILE)"

    لاحظ أنه من الإصدار v256 من systemd فصاعدًا، إذا فُعلت، فستطلب systemd-homed-firstboot.service إنشاء مستخدم عادي عند أول إقلاع إذا لم يكن هناك مستخدمون عاديون.

•   لماذا أرى إخفاقات في chown للملفات عند بناء الصور؟

    عندما لا تعمل كجذر (root)، لا يستطيع مستخدمك تغيير ملكية الملفات إلى ملاك اعتباطيين. لا تزال توزيعات مختلفة تشحن ملفات في حزمها لا يملكها المستخدم الجذر. عندما لا يعمل mkosi كجذر، فإنه يربط المستخدم الحالي بالجذر عند استدعاء مديري الحزم، مما يعني أن تغيير الملكية إلى الجذر سيعمل ولكن تغيير الملكية إلى أي مستخدم أو مجموعة أخرى سيخفق.

    لاحظ أن استدعاءات chown تُكبت فقط عند تشغيل مديري الحزم، وليس عند تشغيل السكربتات. إذا كان ذلك مطلوباً، مثلاً لسكربت بناء، يمكن ضبط المتغير MKOSI_CHROOT_SUPPRESS_CHOWN على قيمة صحيحة (1، أو yes، أو true) لكبت استدعاءات chown في سكربتات mkosi-chroot و .chroot.

    إذا تسبب هذا السلوك في سوء أداء التطبيقات التي تعمل في صورتك، يمكنك التفكير في تشغيل mkosi كجذر (root) لتجنب هذه المشكلة. وبدلاً من ذلك، إذا كان تشغيل mkosi كجذر غير مرغوب فيه، يمكنك استخدام unshare --map-auto --map-current-user --setuid 0 --setgid 0 لتصبح جذراً في فضاء أسماء مستخدمين يضم أكثر من مستخدم واحد، بفرض أن تخطيطات UID/GID في /etc/subuid و /etc/subgid مضبوطة بشكل صحيح. لاحظ أن تشغيل mkosi كجذر أو باستخدام unshare يعني أن جميع ملفات المخرجات التي ينتجها mkosi لن تعود مملوكة لمستخدمك الحالي.

    لاحظ أنه بالنسبة لخدمات systemd التي تحتاج أدلة في /var مملوكة لمستخدم ومجموعة الخدمة، فإن البديل لشحن هذه الأدلة في الحزم أو إنشائها عبر systemd-tmpfiles هو استخدام StateDirectory= أو CacheDirectory= أو LogsDirectory= في ملف الخدمة، مما يوجه systemd لإنشاء الدليل عند بدء الخدمة لأول مرة.

    وبدلاً من ذلك، يمكن استخدام توجيهات z أو Z لـ systemd-tmpfiles لتغيير ملكية (chown) مختلف الأدلة والملفات لمستخدمها المالك عند إقلاع النظام لأول مرة.

•   لماذا يذكر portablectl inspect <image>/systemd-dissect <image> أن خدمتي المحمولة ليست كذلك؟

    يتحقق كل من systemd-dissect و portablectl inspect من وجود PORTABLE_PREFIXES= في os-release، وإذا كان المفتاح مفقوداً، سيفشلان في التعرف على الخدمة المحمولة بكونها كذلك، حيث يظهر ✗ تحت Use as في حالة systemd-dissect أو n/a تحت Portable Service لـ portablectl.

    بما أنه لا توجد قيمة مبدئية جيدة لضبطها لهذا المفتاح، ولأن صور الخدمات المحمولة المولدة ستظل ترفق بشكل صحيح حتى لو لم يُضبط المفتاح، فإن mkosi لا يضبط أي قيمة له.

    يمكنك ضبط PORTABLE_PREFIXES= في ملف os-release بنفسك في سكربت ما بعد التثبيت (postinst).

المراجع

•

    مستودع mkosi git الرئيس على GitHub https://github.com/systemd/mkosi/

•

    mkosi — أداة لتوليد صور أنظمة التشغيل (https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html) تدوينة تعريفية بقلم لينارت بوتيرينج

•

    أداة إنشاء أنظمة التشغيل mkosi (https://lwn.net/Articles/726655/) قصة على LWN

انظر أيضًا
systemd-nspawn(1), systemd-repart(8), dnf(8)

ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>

هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 (https://www.gnu.org/licenses/gpl-3.0.html) أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.

إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.