.\" -*- coding: UTF-8 -*-
'\" t
.\" Automatically generated by Pandoc 3.5
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH mkosi 1 "" "" 
.SH الاسم
mkosi \[em] ابْنِ صور أنظمة تشغيل مخصصة
.SH موجز
\f[CR]mkosi [الخيارات\&...] init\fR
.PP
\f[CR]mkosi [الخيارات\&...] summary\fR
.PP
\f[CR]mkosi [الخيارات\&...] cat\-config\fR
.PP
\f[CR]mkosi [الخيارات\&...] build [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] shell [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] boot [\-\- إعدادات nspawn\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] vm [\-\- معاملات vmm\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] ssh [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] journalctl [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] coredumpctl [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] sysupdate [\-\- إعدادات sysupdate\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] box [\-\- سطر الأوامر\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] dependencies [\-\- الخيارات\&...]\fR
.PP
\f[CR]mkosi [الخيارات\&...] clean\fR
.PP
\f[CR]mkosi [الخيارات\&...] serve\fR
.PP
\f[CR]mkosi [الخيارات\&...] burn <الجهاز>\fR
.PP
\f[CR]mkosi [الخيارات\&...] bump\fR
.PP
\f[CR]mkosi [الخيارات\&...] genkey\fR
.PP
\f[CR]mkosi [الخيارات\&...] documentation [manual]\fR
.PP
\f[CR]mkosi [الخيارات\&...] completion [صدفة]\fR
.PP
\f[CR]mkosi [الخيارات\&...] latest\-snapshot\fR
.PP
\f[CR]mkosi [الخيارات\&...] help\fR
.SH الوصف
\f[B]mkosi\f[R] هو أداة لبناء صور أنظمة تشغيل مخصصة بسهولة. إنه غلاف متطور
حول \f[B]dnf\f[R] و \f[B]apt\f[R] و \f[B]pacman\f[R] و \f[B]zypper\f[R]
يمكنه توليد صور أقراص بمزايا وإضافات عديدة.\fR
.SS "أفعال سطر الأوامر"
تُعرف أفعال سطر الأوامر التالية:
.TP 
\f[CR]init\fR
يُهيّئ \f[B]mkosi\f[R]. هذه عملية تُنفذ لمرة واحدة تضبط ملفات ضبط متنوعة
مطلوبة لتجربة مثلى. حاليًا لا يهيئ هذا سوى ملف \f[CR]tmpfiles.d\f[R] لمجلد
خبيئة حزم mkosi للتأكد من تنظيف الملفات القديمة وغير المستخدمة آليًا.\fR
.TP 
\f[CR]summary\fR
يُظهر ملخصًا مقروءًا لجميع الخيارات المستخدمة لبناء الصور. سيحلل سطر الأوامر
وملفات الضبط، لكنه سيكتفي بطباعة ما ضُبط ولن يبني أو يشغل أي شيء فعليًا.
.TP 
\f[CR]cat\-config\fR
يُخرج أسماء ومحتويات جميع ملفات الضبط المُحمّلة. يُحمّل \f[B]mkosi\f[R]
مجموعة من الملفات من مواقع مختلفة وهذا الأمر يسهل معرفة ما ضُبط وأين
ضُبط.\fR
.TP 
\f[CR]build\fR
يبني الصورة بناءً على الإعدادات الممررة في سطر الأوامر وفي ملفات الضبط. هذا
الأمر هو المبدئي إذا لم يُحدد أي فعل. يمكن تمرير المعطيات إلى سكريبتات
البناء، إذا وُجدت. لتمرير خيارات لسكريبتات البناء، افصلها عن خيارات mkosi
العادية باستخدام \f[CR]\-\-\f[R].\fR
.TP 
\f[CR]shell\fR
يبني هذا الصورة إن لم تُبنَ بعد، ثم يستدعي \f[B]systemd\-nspawn\f[R] لتشغيل
صدفة تفاعلية في الصورة. لا يتطلب هذا إقلاع النظام، بل هو أشبه بـ chroot
أفضل. يمكن تحديد سطر أوامر اختياري بعد فعل \f[CR]shell\f[R]، ليُستدعى بدلاً
من الصدفة في الحاوية. لتمرير خيارات إضافية لـ nspawn، افصلها عن الخيارات
العادية باستخدام \f[CR]\-\-\f[R].\fR
.TP 
\f[CR]boot\fR
مشابه لـ \f[CR]shell\f[R]، ولكن بدلاً من إطلاق صدفة، فإنه يُقلع systemd في
الصورة باستخدام \f[B]systemd\-nspawn\f[R]. يمكن تحديد معطيات إضافية بعد فعل
\f[CR]boot\f[R]، والتي تُمرر كـ \f[I]سطر أوامر النواة\f[I] لنظام التهيئة في
الصورة. لتمرير خيارات إضافية لـ nspawn، افصلها عن الخيارات العادية باستخدام
\f[CR]\-\-\f[R].\fR
.TP 
\f[CR]vm\fR
مشابه لـ \f[CR]boot\f[R]، ولكنه يستخدم مراقب الآلة الافتراضية المضبوط
(مبدئيًا \f[CR]qemu\f[R]) لإقلاع الصورة، أي بدلاً من الاستنراض بالحاويات،
يُستخدم الاستنراض بالآلة الافتراضية. تعتمد كيفية تفسير معطيات سطر الأوامر
الإضافية على مراقب الآلة الافتراضية المضبوط. انظر
\f[CR]VirtualMachineMonitor=\f[R] لمزيد من المعلومات. لتمرير خيارات إضافية
لمراقب الآلة الافتراضية، افصلها عن الخيارات العادية باستخدام
\f[CR]\-\-\f[R].\fR
.TP 
\f[CR]ssh\fR
عند بناء الصورة بخيار \f[CR]Ssh=always\f[R] أو إذا كانت خدمة
\f[CR]sshd\-vsock\f[R] الخاصة بـ systemd تعمل في الآلة الافتراضية (الإصدار
256+)، يتصل هذا الأمر بآلة افتراضية مُقلعة عبر SSH. تأكد من تشغيل
\f[CR]mkosi ssh\f[R] بنفس الضبط المستخدم في \f[CR]mkosi build\f[R] ليتوفر
لديه المعلومات اللازمة للاتصال بالآلة الافتراضية عبر SSH. تحديدًا، يُستخدم
مفتاح SSH الخاص من إعداد \f[CR]SshKey=\f[R] للاتصال بالآلة
الافتراضية. استخدم \f[CR]mkosi genkey\f[R] لتوليد مفتاح وشهادة آليًا
ليلتقطهما \f[B]mkosi\f[R]. أي معطيات تُمرر بعد فعل \f[CR]ssh\f[R] تُمرر
كمعطيات لاستدعاء \f[B]ssh\f[R]. لتمرير خيارات إضافية، افصلها عن الخيارات
العادية باستخدام \f[CR]\-\-\f[R]. للاتصال بحاوية، استخدم \f[CR]machinectl
login\f[R] أو \f[CR]machinectl shell\f[R].\fR
.RS
.PP
يمكن استخدام خيار \f[CR]Machine=\f[R] لإعطاء الآلة اسم مضيف مخصص عند
إقلاعها، والذي يمكن استخدامه لاحقًا لـ \f[B]ssh\f[R] إلى الصورة (مثلاً:
\f[CR]mkosi \-\-machine=mymachine vm\f[R] يتبعه \f[CR]mkosi
\-\-machine=mymachine ssh\f[R]).\fR
.RE
.TP 
\f[CR]journalctl\fR
يستخدم \f[B]journalctl\f[R] لمعاينة السجل داخل الصورة. جميع المعطيات المحددة
بعد فعل \f[CR]journalctl\f[R] والمفصولة بـ \f[CR]\-\-\f[R] عن الخيارات العادية
تُلحق باستدعاء \f[B]journalctl\f[R].\fR
.TP 
\f[CR]coredumpctl\fR
يستخدم \f[B]coredumpctl\f[R] للبحث عن ملفات تفريغ الذاكرة (coredumps) داخل
الصورة. جميع المعطيات المحددة بعد فعل \f[CR]coredumpctl\f[R] والمفصولة بـ
\f[CR]\-\-\f[R] عن الخيارات العادية تُلحق باستدعاء \f[B]coredumpctl\f[R].\fR
.TP 
\f[CR]sysupdate\fR
يستدعي \f[B]systemd\-sysupdate\f[R] مع ضبط خيار \f[CR]\-\-transfer\-source=\f[R]
على مجلد المخرجات وضبط خيار \f[CR]\-\-definitions=\f[R] على المجلد المضبوط بـ
\f[CR]SysupdateDirectory=\f[R]. جميع المعطيات المحددة بعد فعل
\f[CR]sysupdate\f[R] والمفصولة عن الخيارات العادية بـ \f[CR]\-\-\f[R] تُمرر
مباشرة إلى \f[B]systemd\-sysupdate\f[R].\fR
.TP 
\f[CR]box\fR
يُشغل أوامر عشوائية داخل نفس البيئة المستخدمة لتنفيذ أفعال أخرى مثل
\f[CR]boot\f[R] و \f[CR]shell\f[R] و \f[CR]vm\f[R] وغيرها. هذا يعني أن
\f[CR]/usr\f[R] سيُستبدل بـ \f[CR]/usr\f[R] من شجرة الأدوات إذا استخدمت
واحدة، بينما يظل كل شيء آخر في مكانه. إذا لم يُوفر أي أمر، فسيُنفذ
\f[CR]$SHELL\f[R] أو \f[B]bash\f[R] إذا لم يكن \f[CR]$SHELL\f[R]
مضبوطًا. لتمرير خيارات إضافية للأمر المعطى، افصلها عن الخيارات العادية بـ
\f[CR]\-\-\f[R].\fR
.TP 
\f[CR]clean\fR
يُزيل مخلفات البناء الناتجة عن بناء سابق. إذا دُمج مع \f[CR]\-f\f[R]، فإنه
يزيل أيضًا صور خبيئة البناء التزايدي وشجرة الأدوات. إذا حُدد \f[CR]\-f\f[R]
مرتين، فإنه يزيل أيضًا أي خبيئة حزم.\fR
.TP 
\f[CR]serve\fR
يبني هذا الصورة إذا لم تُبنَ بعد، ثم يخدم مجلد المخرجات (أي عادةً
\f[CR]mkosi.output/\f[R]، انظر أدناه) عبر خادم HTTP مدمج صغير، يستمع على
المنفذ 8081. ادمجه مع \f[CR]\-f\f[R] لإعادة بناء الصورة دون قيد أو شرط قبل
خدمتها. هذا الأمر مفيد لاختبار جلب صور أنظمة التشغيل عبر الشبكة، مثلاً عبر
\f[CR]machinectl pull\-raw \&...\f[R] و \f[CR]machinectl pull\-tar
\&...\f[R].\fR
.TP 
\f[CR]burn <الجهاز>\fR
يبني هذا الصورة إذا لم تُبنَ بعد، ثم يكتبها في الجهاز الكتلي المحدد. تُكتب
محتويات القسم كما هي، ولكن يتم تصحيح جدول أقسام GPT ليطابق حجم القطاع والقرص
للوسيط المحدد.
.TP 
\f[CR]bump\fR
يرفع إصدار الصورة من \f[CR]mkosi.version\f[R] ويكتب سلسلة الإصدار الناتجة في
\f[CR]mkosi.version\f[R]. هذا مفيد لتنفيذ مخطط إصدارات بسيط: في كل مرة
يُستدعى فيها هذا الفعل يُرفع الإصدار استعدادًا للبناء اللاحق. لاحظ أن
\f[CR]\-\-auto\-bump\f[R]/\f[CR]\-B\f[R] يمكن استخدامه لرفع الإصدار آليًا كجزء
من عملية البناء. لا يُكتب الإصدار الجديد في \f[CR]mkosi.version\f[R] إلا إذا
نجح البناء في تلك الحالة.\fR
.RS
.PP
إذا وجد \f[CR]mkosi.bump\f[R]، فسيُستدعى لتوليد الإصدار الجديد بدلاً من
استخدام منطق mkosi الخاص.\fR
.RE
.TP 
\f[CR]genkey\fR
يولّد زوجًا من مفاتيح الإقلاع الآمن (SecureBoot) للاستخدام مع خياري
\f[CR]SecureBootKey=\f[R]/\f[CR]\-\-secure\-boot\-key=\f[R] و
\f[CR]SecureBootCertificate=\f[R]/\f[CR]\-\-secure\-boot\-certificate=\f[R].\fR
.TP 
\f[CR]documentation\fR
يُظهر توثيق \f[B]mkosi\f[R]. إذا لم يُعطَ أي معطى، تُعرض صفحة دليل
\f[B]mkosi\f[R]، ولكن المعطيات \f[CR]mkosi\f[R] و \f[CR]mkosi\-initrd\f[R] و
\f[CR]initrd\f[R] و \f[CR]mkosi\-sandbox\f[R] و \f[CR]sandbox\f[R] و
\f[CR]mkosi.news\f[R] و \f[CR]news\f[R] مدعومة وتُظهر على التوالي صفحات
الدليل لـ \f[B]mkosi\f[R] و \f[B]mkosi\-initrd\f[R] و \f[B]mkosi\-sandbox\f[R]
وملف الأخبار (NEWS) لـ \f[B]mkosi\f[R].\fR
.RS
.PP
مبدئيًا سيحاول هذا الفعل عدة طرق لإخراج التوثيق، ولكن يمكن اختيار خيار محدد
باستخدام خيار \f[CR]\-\-doc\-format\f[R]. يُشجع محزمو التوزيعات على إضافة ملف
\f[CR]mkosi.1\f[R] في مجلد \f[CR]mkosi/resources\f[R] لحزمة بايثون، إذا كان
مفقودًا، وكذلك تثبيته في مسار البحث المناسب لصفحات الدليل. يمكن توليد صفحة
الدليل من ملف markdown \f[CR]mkosi/resources/man/mkosi.1.md\f[R] مثلاً عبر
\f[CR]pandoc \-t man \-s \-o mkosi.1 mkosi.1.md\f[R].\fR
.RE
.TP 
\f[CR]completion\fR
يولّد إكمال الصدفة للصدفة المعطاة كمعطى ويطبعها في الخرج القياسي. تُفهم
المعطيات \f[CR]bash\f[R] و \f[CR]fish\f[R] و \f[CR]zsh\f[R].\fR
.TP 
\f[CR]dependencies\fR
يُخرج قائمة الحزم المطلوبة من قبل \f[B]mkosi\f[R] لبناء وإقلاع الصور.\fR
.RS
.PP
يمكن تمرير هذه القائمة مباشرة إلى مدير حزم لتثبيت الحزم. مثلاً، إذا كان
النظام المضيف يستخدم مدير الحزم \f[B]dnf\f[R]، يمكن تثبيت الحزم كما يلي:\fR
.IP
.EX
mkosi dependencies \f[B]|\f[R] xargs \-d \[aq]\[rs]n\[aq] dnf install\fR
.EE
.PP
مبدئيًا، تُعرض التبعيات المطلوبة لبناء الصور بـ mkosi فقط. يمكن تفعيل
تشكيلات شجرة أدوات إضافية لإخراج الحزم التابعة لتلك التشكيلات أيضًا. مثلاً،
تشغيل \f[CR]mkosi dependencies \-\- \-\-profile runtime\f[R] سيخرج أيضًا الحزم
في تشكيلة runtime بالإضافة إلى الحزم العادية. انظر توثيق
\f[CR]ToolsTreeProfiles=\f[R] لقائمة بالتشكيلات المتاحة.\fR
.RE
.TP 
\f[CR]latest\-snapshot\fR
يُخرج أحدث لقطة متاحة في المرآة المضبوطة.
.RS
.PP
هذا الفعل مفيد لرفع اللقطات آليًا بين الحين والآخر. لاحظ أن هذا الفعل يخرج
أحدث لقطة فقط. يقع على عاتق المستدعي (caller) التأكد من كتابة اللقطة في ملف
الضبط المقصود.
.RE
.TP 
\f[CR]help\fR
هذا الفعل يكافئ خيار \f[CR]\-\-help\f[R] الموثق أدناه: يظهر شرحًا موجزًا
للاستخدام.\fR
.SS "خيارات سطر الأوامر فقط"
لا يمكن ضبط هذه الإعدادات في ملفات الضبط.
.TP 
\f[CR]\-\-force\f[R], \f[CR]\-f\fR
استبدل ملف المخرجات إذا كان موجودًا بالفعل عند بناء صورة. مبدئيًا عند بناء
صورة ووجود مخرجات سابقة سيرفض \f[B]mkosi\f[R] العملية. حدد هذا الخيار مرة
واحدة لحذف جميع مخلفات البناء من تشغيل سابق قبل إعادة بناء الصورة. إذا فُعلت
عمليات البناء التزايدي، فإن تحديد هذا الخيار مرتين سيضمن إزالة ملفات الخبيئة
الوسيطة أيضًا قبل بدء إعادة البناء. إذا استُخدمت خبيئة حزم (انظر أيضًا قسم
\f[B]FILES\f[R] أدناه)، فإن تحديد هذا الخيار ثلاث مرات سيضمن إزالة خبيئة
الحزم أيضًا قبل بدء إعادة البناء. بالنسبة لعملية \f[CR]clean\f[R]، يكون لهذا
الخيار تأثير مختلف قليلاً: مبدئيًا سيقوم الفعل بإزالة مخلفات البناء من تشغيل
سابق فقط، وعند تحديده مرة واحدة تُحذف ملفات الخبيئة التزايدية وشجرة الأدوات
أيضًا، وعند تحديده مرتين تُزال خبيئة الحزم أيضًا.\fR
.TP 
\f[CR]\-\-directory=\f[R], \f[CR]\-C\fR
يأخذ مسارًا لمجلد. ينتقل \f[B]mkosi\f[R] إلى هذا المجلد قبل القيام بأي
شيء. لاحظ أنه يتم البحث عن ملفات الضبط المتنوعة في هذا المجلد، لذا فإن
استخدام هذا الخيار طريقة فعالة لبناء مشروع يقع في مجلد معين. القيمة المبدئية
هي مجلد العمل الحالي. إذا حُددت سلسلة فارغة، سيتم تجاهل كل الضبط في مجلد
العمل الحالي.\fR
.TP 
\f[CR]\-\-debug\fR
فعل خرج تنقيب إضافي.
.TP 
\f[CR]\-\-debug\-shell\fR
عند فشل تنفيذ أمر في الصورة، سيبدأ \f[B]mkosi\f[R] صدفة تفاعلية في الصورة
للسماح بمزيد من التنقيح.\fR
.TP 
\f[CR]\-\-debug\-workspace\fR
عند تحديده، لن يُحذف مجلد مساحة العمل وسيتم تسجيل موقعه عند خروج
\f[B]mkosi\f[R].\fR
.TP 
\f[CR]\-\-debug\-sandbox\fR
شغّل \f[B]mkosi\-sandbox\f[R] باستخدام \f[B]strace\f[R].\fR
.TP 
\f[CR]\-\-version\fR
أظهر إصدار الحزمة.
.TP 
\f[CR]\-\-help\f[R], \f[CR]\-h\fR
أظهر معلومات استخدام موجزة.
.TP 
\f[CR]\-\-genkey\-common\-name=\fR
الاسم الشائع المستخدم عند توليد المفاتيح عبر أمر \f[CR]genkey\f[R] الخاص بـ
\f[B]mkosi\f[R]. القيمة المبدئية هي \f[CR]mkosi of %u\f[R]، حيث
\f[CR]%u\f[R] تتمدد لتصبح اسم المستخدم الذي استدعى \f[B]mkosi\f[R].\fR
.TP 
\f[CR]\-\-genkey\-valid\-days=\fR
عدد الأيام التي يجب أن تظل فيها المفاتيح صالحة عند توليدها عبر أمر
\f[CR]genkey\f[R] لـ \f[B]mkosi\f[R]. القيمة المبدئية هي سنتان (730
يومًا).\fR
.TP 
\f[CR]\-\-auto\-bump=\f[R], \f[CR]\-B\fR
إذا حُدد، سيُرفع الإصدار وإذا نجح البناء، يُكتب الإصدار في
\f[CR]mkosi.version\f[R] بطريقة مكافئة لفعل \f[CR]bump\f[R]. هذا مفيد لإدارة
إصدارات خطية بسيطة: سيكون لكل بناء في سلسلة رقم إصدار أعلى بواحد من البناء
السابق.\fR
.RS
.PP
إذا وجد \f[CR]mkosi.bump\f[R]، فسيُستدعى لتوليد الإصدار الجديد بدلاً من
استخدام منطق mkosi الخاص.\fR
.RE
.TP 
\f[CR]\-\-doc\-format\fR
التنسيق الذي يُعرض به التوثيق. يدعم القيم \f[CR]markdown\f[R] و
\f[CR]man\f[R] و \f[CR]pandoc\f[R] و \f[CR]system\f[R] و \f[CR]auto\f[R]. في
حالة \f[CR]markdown\f[R]، يُعرض التوثيق بتنسيق Markdown الأصلي. تعرض
\f[CR]man\f[R] التوثيق بتنسيق صفحة الدليل، إذا كان متاحًا. ستقوم
\f[B]pandoc\f[R] بتوليد تنسيق صفحة الدليل أثناء التشغيل، إذا كانت
\f[B]pandoc\f[R] متاحة. ستعرض \f[CR]system\f[R] صفحة الدليل الخاصة بـ
\f[B]mkosi\f[R] على مستوى النظام، والتي قد تتطابق أو لا تتطابق مع الإصدار
الذي تستخدمه، اعتمادًا على كيفية تثبيت \f[B]mkosi\f[R]. أما \f[CR]auto\f[R]،
وهي المبدئية، ستحاول جميع الطرق بالترتيب: \f[CR]man\f[R]، ثم
\f[CR]pandoc\f[R]، ثم \f[CR]markdown\f[R]، ثم \f[CR]system\f[R].\fR
.TP 
\f[CR]\-\-json\fR
أظهر خرج الملخص كـ JSON\-SEQ.
.TP 
\f[CR]\-\-wipe\-build\-dir\f[R], \f[CR]\-w\fR
امسح مجلد البناء إذا ضُبط واحد قبل بناء الصورة.
.TP 
\f[CR]\-\-rerun\-build\-scripts\f[R], \f[CR]\-R\fR
أعد تشغيل سكريبتات البناء. يتطلب تفعيل خيار \f[CR]Incremental=\f[R] وأن تكون
الصورة قد بُنيت بالفعل مرة واحدة. إذا فُعل خيار \f[CR]History=\f[R]، سيتم
إعادة استخدام السجل من البناء السابق ولن يُكتب سجل جديد.\fR
.SS "تنسيقات المخرجات المدعومة"
تنسيقات المخرجات التالية مدعومة:
.IP \[bu] 2
صورة قرص \f[I]GPT\f[R] خام، أنشئت باستخدام \f[B]systemd\-repart\f[R]
(\f[I]disk\f[R])\fR
.IP \f[R]\[bu]\fR 2
مجلد عادي، يحتوي على شجرة نظام التشغيل (\f[I]directory\f[R])\fR
.IP \f[R]\[bu]\fR 2
أرشيف Tar (\f[I]tar\f[R])\fR
.IP \f[R]\[bu]\fR 2
أرشيف CPIO (\f[I]cpio\f[R])\fR
.IP \f[R]\[bu]\fR 2
صورة نواة موحدة (\f[I]UKI\f[R])\fR
.IP \f[R]\[bu]\fR 2
\&... وأكثر من ذلك بكثير. انظر توثيق \f[CR]Format=\f[R] أدناه.\fR
.PP
يمكن أيضًا ضبط تنسيق المخرجات على \f[I]none\f[R] لكي لا ينتج \f[B]mkosi\f[R]
أي صورة على الإطلاق. يمكن أن يكون هذا مفيدًا إذا كنت تريد فقط استخدام الصورة
لإنتاج مخرج آخر في سكريبتات البناء (مثل بناء حزمة RPM).\fR
.PP
عند إنشاء صورة قرص \f[I]GPT\f[R]، يمكن وضع ملفات تعريف أقسام repart في
\f[CR]mkosi.repart/\f[R] لضبط صورة القرص المولدة.\fR
.PP
يوصى بشدة بتشغيل \f[B]mkosi\f[R] على نظام ملفات يدعم reflinks مثل XFS و
btrfs وإبقاء جميع المجلدات ذات الصلة على نفس نظام الملفات. يسمح هذا لـ
\f[B]mkosi\f[R] بإنشاء الصور بسرعة كبيرة عن طريق استخدام reflinks لإجراء
النسخ عبر عمليات النسخ عند الكتابة (copy\-on\-write).\fR
.SS "إعدادات الضبط"
يمكن ضبط الإعدادات التالية عبر ملفات الضبط (بناء الجملة
\f[CR]SomeSetting=value\f[R]) وعلى سطر الأوامر (بناء الجملة
\f[CR]\-\-some\-setting=value\f[R]). بالنسبة لبعض معاملات سطر الأوامر، يُسمح
أيضًا باختصار من حرف واحد. في ملفات الضبط، يجب أن يكون الإعداد في القسم
المناسب، لذا يتم تجميع الإعدادات حسب القسم أدناه.\fR
.PP
يُحلل الضبط بالترتيب التالي:
.IP \[bu] 2
تُحلل معطيات سطر الأوامر.
.IP \[bu] 2
يُحلل \f[CR]mkosi.local.conf\f[R] و \f[CR]mkosi.local/\f[R] إذا وُجدا (بهذا
الترتيب). يجب أن يكون هذا الملف والمجلد في \f[CR].gitignore\f[R] (أو ما
يكافئه) وهما مخصصان للضبط المحلي.\fR
.IP \f[R]\[bu]\fR 2
إذا كان لخيار ما مسار مبدئي مقابل، فسيتم تحليله إذا وجد المسار المبدئي
المقابل.
.IP \[bu] 2
يُحلل \f[CR]mkosi.conf\f[R] إذا وجد في المجلد المضبوط بـ
\f[CR]\-\-directory=\f[R] أو مجلد العمل الحالي إذا لم يُستخدم
\f[CR]\-\-directory=\f[R]. إذا لم يحتوي المجلد المحدد على
\f[CR]mkosi.conf\f[R] أو \f[CR]mkosi.tools.conf\f[R] ولكن وجد
\f[CR]mkosi/mkosi.conf\f[R] أو \f[CR]mkosi/mkosi.tools.conf\f[R]، فسيتم
تحليل الضبط من المجلد الفرعي \f[CR]mkosi/\f[R] للمجلد المحدد بدلاً من
ذلك.\fR
.IP \f[R]\[bu]\fR 2
يُحلل \f[CR]mkosi.conf.d/\f[R] في نفس المجلد مثل \f[CR]mkosi.conf\f[R] إذا
وجد. يتم تحليل كل مجلد وكل ملف بامتداد \f[CR].conf\f[R] في
\f[CR]mkosi.conf.d/\f[R]. يُحلل أي مجلد في \f[CR]mkosi.conf.d\f[R] كما لو
كان مجلد مستوى أعلى عادي، باستثناء \f[CR]mkosi.images/\f[R] و
\f[CR]mkosi.tools.conf\f[R]، اللذين يتم التقاطهما في مجلد المستوى الأعلى
فقط.\fR
.IP \f[R]\[bu]\fR 2
إذا ضُبطت أي تشكيلات (profiles)، فسيتم تحليل ضبطها من مجلد
\f[CR]mkosi.profiles/\f[R].\fR
.IP \f[R]\[bu]\fR 2
يتم تحليل الصور الفرعية من مجلد \f[CR]mkosi.images/\f[R] إذا وجد.\fR
.PP
لاحظ أن الإعدادات المضبوطة عبر سطر الأوامر تسود دائمًا على الإعدادات
المضبوطة عبر ملفات الضبط. إذا ضُبط نفس الإعداد أكثر من مرة عبر ملفات الضبط،
فإن التعيينات اللاحقة تسود على التعيينات السابقة باستثناء الإعدادات التي
تأخذ مجموعة من القيم. أيضًا، الإعدادات المقروءة من
\f[CR]mkosi.local.conf\f[R] أو \f[CR]mkosi.local/\f[R] ستسود على الإعدادات
من ملفات الضبط التي تُحلل لاحقًا، ولكن ليس على الإعدادات المحددة في سطر
الأوامر.\fR
.PP
بالنسبة للإعدادات التي تأخذ قيمة واحدة، يمكن استخدام التعيين الفارغ
(\f[CR]SomeSetting=\f[R] أو \f[CR]\-\-some\-setting=\f[R]) لتجاوز إعداد سابق
وإعادة الضبط إلى القيمة المبدئية.\fR
.PP
تُدمج الإعدادات التي تأخذ مجموعة من القيم عن طريق إلحاق القيم الجديدة بالقيم
المضبوطة سابقًا. يؤدي تعيين سلسلة فارغة لمثل هذا الإعداد إلى إزالة جميع
القيم المعينة سابقًا، ويتجاوز أي قيم مبدئية مضبوطة أيضًا. تُلحق القيم
المحددة في سطر الأوامر بعد جميع القيم من ملفات الضبط.
.PP
لتضمين ملفات الضبط بشكل مشروط، يمكن استخدام قسم \f[CR][Match]\f[R]. يتكون
قسم \f[CR][Match]\f[R] من شروط فردية. يمكن أن تستخدم الشروط رمز الأنبوب
(\f[CR]|\f[R]) بعد علامة التساوي (\f[CR]\&...=|\&...\f[R])، مما يجعل الشرط
شرطًا مُطلقًا (triggering). سيتم تضمين ملف الضبط إذا تحقق الـ AND المنطقي
لجميع الشروط غير المطلقة والـ OR المنطقي لجميع الشروط المطلقة. لنفي نتيجة
شرط ما، ضع علامة تعجب قبل المعطى. إذا سُبق المعطى برمز الأنبوب وعلامة
التعجب، يجب تمرير رمز الأنبوب أولاً ثم علامة التعجب ثانيًا.\fR
.PP
لاحظ أن شروط \f[CR][Match]\f[R] تقارن بالقيم الحالية لإعدادات معينة، ولا
تأخذ في الاعتبار التغييرات التي أُجريت على الإعداد في ملفات الضبط التي لم
تُحلل بعد (تُؤخذ الإعدادات المحددة في سطر الأوامر في الاعتبار). لاحظ أيضًا
أن المطابقة مع إعداد ما ثم تغيير قيمته لاحقًا في ملف ضبط مختلف قد يؤدي إلى
نتائج غير متوقعة.\fR
.PP
ينطبق قسم \f[CR][Match]\f[R] لملف \f[CR]mkosi.conf\f[R] في مجلد ما على
المجلد بأكمله. إذا لم تتحقق الشروط، يتم تجاوز المجلد بأكمله. تنطبق أقسام
\f[CR][Match]\f[R] للملفات في \f[CR]mkosi.conf.d/\f[R] و
\f[CR]mkosi.local.conf\f[R] على الملف نفسه فقط.\fR
.PP
إذا كان هناك عدة أقسام \f[CR][Match]\f[R] في نفس ملف الضبط، يجب أن يتحقق كل
منها حتى يتم تضمين ملف الضبط. تحديدًا، تنطبق الشروط المطلقة فقط على قسم
\f[CR][Match]\f[R] الحالي ويتم تصفيرها بين أقسام \f[CR][Match]\f[R]
المتعددة. كمثال، سيطابق ما يلي فقط إذا كان تنسيق المخرجات واحدًا من
\f[CR]disk\f[R] أو \f[CR]directory\f[R] والمعمارية واحدة من
\f[CR]x86\-64\f[R] أو \f[CR]arm64\f[R]:\fR
.IP
.EX
\f[B][Match]\f[R]
Format=|disk
Format=|directory\fR

\f[B][Match]\f[R]
Architecture=|x86\-64
Architecture=|arm64\fR
.EE
.PP
يمكن استخدام قسم \f[CR][TriggerMatch]\f[R] للإشارة إلى المطابقات
المُطلقة. هذه مطابقة للشروط المطلقة في وحدات systemd إلا أنها تنطبق على قسم
المطابقة بالكامل بدلاً من شرط واحد فقط. كمثال، سيطابق ما يلي إذا كانت
التوزيعة \f[CR]debian\f[R] والإصدار \f[CR]bookworm\f[R] أو إذا كانت التوزيعة
\f[CR]ubuntu\f[R] والإصدار \f[CR]noble\f[R].\fR
.IP
.EX
\f[B][TriggerMatch]\f[R]
Distribution=debian
Release=bookworm\fR

\f[B][TriggerMatch]\f[R]
Distribution=ubuntu
Release=noble\fR
.EE
.PP
دلالات الشروط في أقسام \f[CR][TriggerMatch]\f[R] هي نفسها في
\f[CR][Match]\f[R]، أي يتم ربط جميع الشروط العادية بـ AND منطقي وجميع الشروط
المطلقة بـ OR منطقي. عند خلط أقسام \f[CR][Match]\f[R] و
\f[CR][TriggerMatch]\f[R]، تتحقق المطابقة عندما تطابق جميع أقسام
\f[CR][Match]\f[R] ويطابق قسم \f[CR][TriggerMatch]\f[R] واحد على الأقل. غياب
أقسام المطابقة يُعتبر صحيحًا. منطقيًا يعني هذا:\fR
.IP
.EX
(⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ)
.EE
.PP
يتوفر أيضًا دعم لأقسام \f[CR][Assert]\f[R] و \f[CR][TriggerAssert]\f[R] التي
تعمل بشكل مطابق لأقسام المطابقة، باستثناء أن تحليل الضبط سيفشل إذا لم تُلبَّ
أقسام التأكيد، أي يجب تلبية جميع أقسام \f[CR][Assert]\f[R] في الملف بالإضافة
إلى قسم \f[CR][TriggertAssert]\f[R] واحد على الأقل، وإلا سيفشل تحليل
الضبط.\fR
.PP
تظهر خيارات سطر الأوامر التي لا تأخذ معطيات بدون \f[CR]=\f[R] في إصدارها
الطويل. في ملفات الضبط، يجب تحديدها بمعطى منطقي: إما \f[CR]1\f[R]، أو
\f[CR]yes\f[R]، أو \f[CR]true\f[R] للتفعيل، أو \f[CR]0\f[R]، أو
\f[CR]no\f[R]، أو \f[CR]false\f[R] للتعطيل.\fR
.SS "قسم [Distribution]"
.TP 
\f[CR]Distribution=\f[R]، \f[CR]\-\-distribution=\f[R]، \f[CR]\-d\fR
التوزيعة المراد تثبيتها في الصورة. تأخذ أحد المعطيات التالية:
\f[CR]fedora\f[R]، أو \f[CR]debian\f[R]، أو \f[CR]kali\f[R]، أو
\f[CR]ubuntu\f[R]، أو \f[CR]arch\f[R]، أو \f[CR]opensuse\f[R]، أو
\f[CR]mageia\f[R]، أو \f[CR]centos\f[R]، أو \f[CR]rhel\f[R]، أو
\f[CR]rhel\-ubi\f[R]، أو \f[CR]openmandriva\f[R]، أو \f[CR]rocky\f[R]، أو
\f[CR]alma\f[R]، أو \f[CR]azure\f[R] أو \f[CR]custom\f[R]. إذا لم تُحدد،
فستكون المبدئية هي توزيعة المضيف أو \f[CR]custom\f[R] إذا كانت توزيعة المضيف
غير مدعومة.\fR
.TP 
\f[CR]Release=\f[R]، \f[CR]\-\-release=\f[R]، \f[CR]\-r\fR
إصدار التوزيعة المراد تثبيتها في الصورة. يعتمد الصيغة الدقيقة للمعطى الذي
تأخذه على التوزيعة المستخدمة، وهو إما سلسلة رقمية (في حالة Fedora Linux و
CentOS وغيرها، مثلاً \f[CR]29\f[R])، أو اسم إصدار التوزيعة (في حالة Debian و
Kali و Ubuntu وغيرها، مثلاً \f[CR]artful\f[R]). القيمة المبدئية هي إصدار
حديث من التوزيعة المختارة، أو إصدار التوزيعة التي تعمل على المضيف إذا كانت
تطابق التوزيعة المضبوطة.\fR
.TP 
\f[CR]Architecture=\f[R]، \f[CR]\-\-architecture=\fR
المعمارية المراد بناء الصورة لها. تعتمد المعماريات المدعومة فعليًا على
التوزيعة المستخدمة وما إذا كانت الصورة المطلوبة قابلة للإقلاع أم لا. عند
البناء لمعمارية أجنبية، ستحتاج أيضًا إلى تثبيت وتسجيل محاكي وضع المستخدم
لتلك المعمارية.
.RS
.PP
يمكن تحديد إحدى المعماريات التالية لكل صورة تُبنى: \f[CR]alpha\f[R]، أو
\f[CR]arc\f[R]، أو \f[CR]arm\f[R]، أو \f[CR]arm64\f[R]، أو \f[CR]ia64\f[R]،
أو \f[CR]loongarch64\f[R]، أو \f[CR]mips64\-le\f[R]، أو \f[CR]mips\-le\f[R]،
أو \f[CR]parisc\f[R]، أو \f[CR]ppc\f[R]، أو \f[CR]ppc64\f[R]، أو
\f[CR]ppc64\-le\f[R]، أو \f[CR]riscv32\f[R]، أو \f[CR]riscv64\f[R]، أو
\f[CR]s390\f[R]، أو \f[CR]s390x\f[R]، أو \f[CR]tilegx\f[R]، أو
\f[CR]x86\f[R]، أو \f[CR]x86\-64\f[R].\fR
.RE
.TP 
\f[CR]Mirror=\f[R]، \f[CR]\-\-mirror=\f[R]، \f[CR]\-m\fR
المرآة المستخدمة لتنزيل حزم التوزيعة. تتوقع رابط URL للمرآة كمعطى. إذا لم
تُوفر، تُستخدم المرآة المبدئية للتوزيعة.
.RS
.PP
المرايا المبدئية لكل توزيعة هي كما يلي (ما لم يُحدد خلاف ذلك، تُستخدم المرآة
نفسها لجميع المعماريات):
.PP
.TS
tab(@);
lw(13.3n) lw(30.0n) lw(26.7n).
T{
T}@T{
x86\-64
T}@T{
aarch64
T}
_
T{
\f[CR]debian\fR
T}@T{
\f[R]http://deb.debian.org\fR
T}@T{
T}
T{
\f[CR]arch\fR
T}@T{
\f[R]https://fastly.mirror.pkgbuild.com\fR
T}@T{
\f[R]http://mirror.archlinuxarm.org\fR
T}
T{
\f[CR]opensuse\fR
T}@T{
\f[R]http://download.opensuse.org\fR
T}@T{
T}
T{
\f[CR]kali\fR
T}@T{
\f[R]http://http.kali.org/kali\fR
T}@T{
T}
T{
\f[CR]ubuntu\fR
T}@T{
\f[R]http://archive.ubuntu.com\fR
T}@T{
\f[R]http://ports.ubuntu.com\fR
T}
T{
\f[CR]centos\fR
T}@T{
\f[R]https://mirrors.centos.org\fR
T}@T{
T}
T{
\f[CR]rocky\fR
T}@T{
\f[R]https://mirrors.rockylinux.org\fR
T}@T{
T}
T{
\f[CR]alma\fR
T}@T{
\f[R]https://mirrors.almalinux.org\fR
T}@T{
T}
T{
\f[CR]fedora\fR
T}@T{
\f[R]https://mirrors.fedoraproject.org\fR
T}@T{
T}
T{
\f[CR]rhel\-ubi\fR
T}@T{
\f[R]https://cdn\-ubi.redhat.com\fR
T}@T{
T}
T{
\f[CR]mageia\fR
T}@T{
\f[R]https://www.mageia.org\fR
T}@T{
T}
T{
\f[CR]openmandriva\fR
T}@T{
\f[R]http://mirrors.openmandriva.org\fR
T}@T{
T}
T{
\f[CR]azure\fR
T}@T{
\f[R]https://packages.microsoft.com/\fR
T}@T{
T}
.TE
.RE
.TP 
\f[CR]Snapshot=\fR
تنزيل الحزم من اللقطة المعطاة بدلاً من تنزيل أحدث حزم التوزيعة من المرآة
المعطاة. تأخذ معرف لقطة (يختلف تنسيق معرف اللقطة باختلاف التوزيعة)، استخدم
الفعل \f[CR]latest\-snapshot\f[R] لمعرفة أحدث لقطة متاحة.\fR
.RS
.PP
إذا ضُبط هذا الإعداد ولم يُضبط \f[CR]Mirror=\f[R] صراحةً، فستُستخدم مرايا
مبدئية مختلفة:\fR
.PP
.TS
tab(@);
lw(13.3n) lw(30.0n) lw(26.7n).
T{
T}@T{
x86\-64
T}@T{
aarch64
T}
_
T{
\f[CR]debian\fR
T}@T{
\f[R]https://snapshot.debian.org\fR
T}@T{
T}
T{
\f[CR]arch\fR
T}@T{
\f[R]https://archive.archlinux.org\fR
T}@T{
\f[R]http://mirror.archlinuxarm.org\fR
T}
T{
\f[CR]opensuse\fR
T}@T{
\f[R]http://download.opensuse.org\fR
T}@T{
T}
T{
\f[CR]ubuntu\fR
T}@T{
\f[R]http://archive.ubuntu.com\fR
T}@T{
\f[R]http://ports.ubuntu.com\fR
T}
T{
\f[CR]centos\fR
T}@T{
\f[R]https://composes.stream.centos.org\fR
T}@T{
T}
T{
\f[CR]fedora\fR
T}@T{
\f[R]https://kojipkgs.fedoraproject.org\fR
T}@T{
T}
.TE
.PP
بالنسبة لأي توزيعة غير مدرجة أعلاه، اللقطات غير مدعومة.
.RE
.TP 
\f[CR]LocalMirror=\f[R]، \f[CR]\-\-local\-mirror=\fR
ستُستخدم المرآة كمرآة محلية ومباشرة بدلاً من استخدامها كبادئة للمجموعة
الكاملة من المستودعات التي تدعمها التوزيعات عادةً. مفيد للبناء دون اتصال
بالشبكة تمامًا باستخدام مستودع واحد. مدعوم في التوزيعات المعتمدة على
\f[B]deb\f[R] و \f[B]rpm\f[R] و \f[B]pacman\f[R]. يتجاوز
\f[CR]\-\-mirror=\f[R] ولكن فقط لبناء \f[B]mkosi\f[R] المحلي، ولن يُضبط داخل
الصورة النهائية، بل سيُضبط \f[CR]\-\-mirror=\f[R] (أو المستودع المبدئي) داخل
الصورة النهائية بدلاً من ذلك.\fR
.TP 
\f[CR]RepositoryKeyCheck=\f[R]، \f[CR]\-\-repository\-key\-check=\fR
يتحكم في فحص التوقيع/المفتاح عند استخدام المستودعات، وهو مفعل مبدئيًا. مفيد
لتعطيل الفحوصات عند استخدامه مع \f[CR]\-\-local\-mirror=\f[R] واستخدام مستودع
من نظام ملفات محلي فقط.\fR
.TP 
\f[CR]RepositoryKeyFetch=\f[R]، \f[CR]\-\-repository\-key\-fetch=\fR
يتحكم فيما إذا كان \f[B]mkosi\f[R] سيجلب مفاتيح GPG الخاصة بالتوزيعة عن
بُعد. مفعل مبدئيًا على Ubuntu عند عدم استخدام شجرة أدوات أو عند استخدام
أشجار أدوات Ubuntu لبناء Arch Linux أو التوزيعات المعتمدة على RPM. معطل
مبدئيًا في جميع التوزيعات الأخرى. عند تعطيله، يجب تثبيت مفاتيح GPG الخاصة
بالتوزيعة المستهدفة محليًا على نظام المضيف إلى جانب مدير الحزم لتلك
التوزيعة.\fR
.RS
.PP
نُفذ هذا الإعداد فقط للتوزيعات التي تستخدم \f[B]dnf\f[R]، أو
\f[B]pacman\f[R] أو \f[B]zypper\f[R] كمدير للحزم. بالنسبة للتوزيعات الأخرى،
يُبحث دائمًا عن مفاتيح GPG للتوزيعة محليًا بغض النظر عن قيمة هذا
الإعداد. لجعل مفاتيح GPG الخاصة بالتوزيعات متاحة دون تفعيل هذا الإعداد، يجب
تثبيت الحزمة المقابلة على المضيف. عادة ما تكون هذه إحدى الحزم التالية:
\f[CR]archlinux\-keyring\f[R]، أو \f[CR]debian\-keyring\f[R]، أو
\f[CR]kali\-archive\-keyring\f[R]، أو \f[CR]ubuntu\-keyring\f[R] أو
\f[CR]distribution\-gpg\-keys\f[R] (للتوزيعات المعتمدة على RPM).\fR
.RE
.TP 
\f[CR]Repositories=\f[R]، \f[CR]\-\-repositories=\fR
تفعيل مستودعات الحزم المعطلة مبدئيًا. يمكن استخدام هذا لتفعيل مستودعات EPEL
لـ CentOS أو مكونات مختلفة من مستودعات Debian/Kali/Ubuntu.
.SS "قسم [Output]"
.TP 
\f[CR]Format=\f[R]، \f[CR]\-\-format=\f[R]، \f[CR]\-t\fR
نوع تنسيق الصورة المراد توليدها. أحد الخيارات: \f[CR]directory\f[R] (لتوليد
صورة نظام تشغيل مباشرة في دليل محلي)، أو \f[CR]tar\f[R] (مماثل، ولكن تُولد
أرشفة tar لصورة نظام التشغيل)، أو \f[CR]cpio\f[R] (مماثل، ولكن تُولد أرشفة
cpio)، أو \f[CR]disk\f[R] (صورة نظام تشغيل لجهاز كتلي مع جدول أقسام GPT)، أو
\f[CR]uki\f[R] (صورة نواة موحدة مع صورة نظام التشغيل في قسم PE باسم
\&\f[CR].initrd\f[R])، أو \f[CR]esp\f[R] (صورة قرص مع قسم ESP فقط، ومحمل إقلاع
وربما UKI)، أو \f[CR]oci\f[R] (دليل متوافق مع مواصفات صورة OCI)، أو
\f[CR]sysext\f[R]، أو \f[CR]confext\f[R]، أو \f[CR]portable\f[R]، أو
\f[CR]addon\f[R] أو \f[CR]none\f[R] (صورة نظام التشغيل مخصصة فقط كصورة بناء
لإنتاج منتج آخر).\fR
.RS
.PP
إذا استخدم تنسيق الإخراج \f[CR]disk\f[R]، فستُولد صورة القرص باستخدام
\f[B]systemd\-repart\f[R]. يمكن ضبط ملفات تعريف أقسام repart المستخدمة
باستخدام إعداد \f[CR]RepartDirectories=\f[R] أو عبر
\f[CR]mkosi.repart/\f[R]. عندما تُضبط أقسام verity باستخدام إعداد
\f[CR]Verity=\f[R] الخاص بـ \f[B]systemd\-repart\f[R]، سيحلل \f[B]mkosi\f[R]
آليًا roothash الخاص بقسم هاش verity من مخرجات JSON الخاصة بـ
\f[B]systemd\-repart\f[R] ويضمنه في سطر أوامر النواة لكل صورة نواة موحدة
يبنيها \f[B]mkosi\f[R].\fR
.PP
إذا استخدم تنسيق الإخراج \f[CR]none\f[R]، فلن تُزال مخرجات البناء السابق،
ولكن ستُنفذ سكربتات التنظيف (انظر \f[CR]CleanScripts=\f[R]). يسمح هذا بإعادة
تشغيل سكربت بناء (انظر \f[CR]BuildScripts=\f[R]) دون إزالة نتائج بناء
سابق.\fR
.RE
.TP 
\f[CR]ManifestFormat=\f[R]، \f[CR]\-\-manifest\-format=\fR
نوع أو أنواع تنسيق البيان المراد توليدها. قائمة مفصولة بفاصلة تتكون من
\f[CR]json\f[R] (تنسيق مخرجات JSON القياسي الذي يصف الحزم المثبتة)، و
\f[CR]changelog\f[R] (تنسيق نصي قابل للقراءة من البشر مصمم
للمقارنة). مبدئيًا لا يُولد أي بيان.\fR
.TP 
\f[CR]Output=\f[R]، \f[CR]\-\-output=\f[R]، \f[CR]\-o\fR
الاسم المستخدم لملف صورة المخرجات المولدة أو الدليل. المبدئي هو
\f[CR]image\f[R] أو، إذا حُدد \f[CR]ImageId=\f[R]، فسيُستخدم كاسم الإخراج
المبدئي، متبوعًا اختياريًا بالإصدار المحدد بـ \f[CR]ImageVersion=\f[R] أو
إذا بُنيت صورة محددة من \f[CR]mkosi.images\f[R]، يُفضل اسم الصورة على
\f[CR]ImageId\f[R]. لاحظ أن هذا الخيار لا يسمح بضبط دليل الإخراج، استخدم
\f[CR]OutputDirectory=\f[R] لذلك.\fR
.RS
.PP
لاحظ أن هذا يحدد بادئة الإخراج فقط، اعتمادًا على تنسيق الإخراج المحدد،
والضغط وإصدار الصورة المستخدم، قد يكون اسم الإخراج الكامل هو
\f[CR]image_7.8.raw.xz\f[R].\fR
.RE
.TP 
\f[CR]OutputExtension=\f[R]، \f[CR]\-\-output\-extension=\fR
استخدم الامتداد المحدد لملف الإخراج. المبدئي هو الامتداد المناسب بناءً على
تنسيق الإخراج. يتضمن امتداد الملف فقط، وليس أي امتداد ضغط سيُلحق بهذا
الامتداد إذا فُعل الضغط.
.TP 
\f[CR]CompressOutput=\f[R]، \f[CR]\-\-compress\-output=\fR
اضبط الضغط للصورة أو الأرشفة الناتجة. يمكن أن يكون المعطى إما قيمة منطقية أو
خوارزمية ضغط (\f[B]xz\f[R]، أو \f[B]zstd\f[R]). يُستخدم ضغط \f[B]zstd\f[R]
مبدئيًا، باستثناء CentOS ومشتقاته حتى الإصدار 8، والتي تستخدم \f[B]xz\f[R]
مبدئيًا، وصور OCI التي تستخدم \f[B]gzip\f[R] مبدئيًا. لاحظ أنه عند تطبيقه
على أنواع صور الأجهزة الكتلية، فإن الضغط يعني أنه لا يمكن بدء الصورة مباشرة
ولكن يجب فك ضغطها أولاً. وهذا يعني أيضًا أن أفعال \f[CR]shell\f[R] و
\f[CR]boot\f[R] و \f[CR]vm\f[R] غير متاحة عند استخدام هذا الخيار. هذا الخيار
ضمني لكل من \f[CR]tar\f[R] و \f[CR]cpio\f[R] و \f[CR]uki\f[R] و
\f[CR]esp\f[R] و \f[CR]oci\f[R] و \f[CR]addon\f[R].\fR
.TP 
\f[CR]CompressLevel=\f[R]، \f[CR]\-\-compress\-level=\fR
اضبط مستوى الضغط المستخدم. يأخذ رقمًا صحيحًا. تعتمد القيم الممكنة على نوع
الضغط المستخدم.
.TP 
\f[CR]OutputDirectory=\f[R]، \f[CR]\-\-output\-directory=\f[R]، \f[CR]\-O\fR
المسار إلى دليل لوضع جميع المنتجات المولدة فيه. إذا لم يُحدد هذا وكان الدليل
\f[CR]mkosi.output/\f[R] موجودًا في الدليل المحلي، فسيُستخدم آليًا لهذا
الغرض.\fR
.TP 
\f[CR]OutputMode=\f[R]، \f[CR]\-\-output\-mode=\fR
وضع الوصول لنظام الملفات المستخدم عند إنشاء ملف صورة المخرجات. يأخذ وضع وصول
بالترميز الثماني. إذا لم يُضبط، تُستخدم القيم المبدئية للنظام الحالي.
.TP 
\f[CR]ImageVersion=\f[R]، \f[CR]\-\-image\-version=\fR
اضبط إصدار الصورة. يقبل هذا أي سلسلة نصية، ولكن يُوصى بتحديد سلسلة من
المكونات المفصولة بنقاط. يمكن أيضًا ضبط الإصدار عن طريق قراءة ملف
\f[CR]mkosi.version\f[R] (وفي هذه الحالة يمكن إدارته بسهولة عبر الفعل
\f[CR]bump\f[R] أو خيار \f[CR]\-\-auto\-bump\f[R]) أو عن طريق قراءة المخرجات
القياسية إذا كان قابلاً للتنفيذ (انظر قسم \f[B]السكربتات\f[R] أدناه). عند
تحديده، يُضمن إصدار الصورة في اسم ملف الإخراج المبدئي، أي بدلاً من
\f[CR]image.raw\f[R] سيكون المبدئي هو \f[CR]image_0.1.raw\f[R] للإصدار
\f[CR]0.1\f[R] من الصورة، وهكذا. يُمرر الإصدار أيضًا عبر
\f[CR]$IMAGE_VERSION\f[R] إلى أي سكربتات بناء تُستدعى (والذي قد يكون مفيدًا
لترقيعه في \f[CR]/usr/lib/os\-release\f[R] أو ما شابه، لاسيما حقل
\f[CR]IMAGE_VERSION=\f[R] فيه).\fR
.TP 
\f[CR]ImageId=\f[R]، \f[CR]\-\-image\-id=\fR
اضبط معرف الصورة. يقبل هذا سلسلة نصية حرة تُستخدم لتعريف الصورة. إذا ضُبط،
فسيُسمى ملف الإخراج المبدئي باسمه (ربما متبوعًا بالإصدار). يُمرر المعرف
أيضًا عبر \f[CR]$IMAGE_ID\f[R] إلى أي سكربتات بناء تُستدعى. يُضاف معرف
الصورة آليًا إلى \f[CR]/usr/lib/os\-release\f[R].\fR
.TP 
\f[CR]SplitArtifacts=\f[R]، \f[CR]\-\-split\-artifacts=\fR
أنواع المنتجات المراد فصلها عن الصورة النهائية. قائمة مفصولة بفاصلة تتكون من
\f[CR]uki\f[R]، و \f[CR]kernel\f[R]، و \f[CR]initrd\f[R]، و
\f[CR]os\-release\f[R]، و \f[CR]prcs\f[R]، و \f[CR]partitions\f[R]، و
\f[CR]roothash\f[R]، و \f[CR]kernel\-modules\-initrd\f[R]، و
\f[CR]repart\-definitions\f[R] و \f[CR]tar\f[R]. عند بناء صورة قابلة للإقلاع،
يوافق \f[CR]kernel\f[R] و \f[CR]initrd\f[R] منتجهما الموجود في الصورة (أو في
UKI)، بينما ينسخ \f[CR]uki\f[R] كامل UKI. إذا حُدد \f[CR]pcrs\f[R]، فيُكتب
ملف JSON يحتوي على خلاصات TPM2 المحسوبة مسبقًا، وفقًا لمواصفات
.UR https://uapi\-group.org/specifications/specs/unified_kernel_image/#json\-format\-for\-pcrsig
UKI
.UE
، وهو مفيد للتوقيع دون اتصال بالشبكة.\fR
.RS
.PP
عند بناء صورة قرص وتحديد \f[CR]partitions\f[R]، مرر \f[CR]\-\-split=yes\f[R]
إلى \f[B]systemd\-repart\f[R] ليقوم بكتابة ملفات أقسام منفصلة لكل قسم
مضبوط. اقرأ صفحة الدليل
.UR https://www.freedesktop.org/software/systemd/man/systemd\-repart.html#\-\-split=BOOL
.UE
لمزيد من المعلومات. هذا مفيد في سيناريوهات تحديث A/B حيث يجب تعزيز
صورة قرص موجودة بإصدار جديد من قسم الجذر أو قسم \f[CR]/usr\f[R] إلى جانب قسم
Verity الخاص به والنواة الموحدة.\fR
.PP
عند تحديد \f[CR]tar\f[R]، يُؤرشف نظام ملفات الجذر (rootfs) إضافيًا كأرشفة
tar (مضغوطة وفقًا لـ \f[CR]CompressOutput=\f[R]).\fR
.PP
عند تحديد \f[CR]roothash\f[R] وبناء صورة قرص dm\-verity، يُكتب dm\-verity
roothash كملف منفصل، وهو مفيد للتوقيع دون اتصال بالشبكة.\fR
.PP
\f[CR]kernel\-modules\-initrd\f[R] يوافق ملف initrd لوحدات النواة المنفصل الذي
يلحقه mkosi بملف initrd الرئيس. هذا مخصص في المقام الرئيس للتنقيح لأن العديد
من أدوات فحص initrd لا تتعامل بشكل صحيح مع عدة ملفات initrd ملحقة ببعضها
البعض.\fR
.PP
عند تحديد \f[CR]repart\-definitions\f[R]، يُكتب دليل يحتوي على ملفات تعريف
repart المستخدمة في دليل الإخراج. إذا ضُبطت أدلة متعددة عبر
\f[CR]RepartDirectories=\f[R]، فستُدمج، مع إعطاء الأولوية للأدلة اللاحقة على
السابقة عند وجود ملفات بأسماء متطابقة.\fR
.PP
مبدئيًا، تُفصل كل من \f[CR]uki\f[R] و \f[CR]kernel\f[R] و
\f[CR]initrd\f[R].\fR
.RE
.TP 
\f[CR]RepartDirectories=\f[R]، \f[CR]\-\-repart\-directory=\fR
المسارات إلى الأدلة التي تحتوي على ملفات تعريف أقسام
\f[B]systemd\-repart\f[R] التي تُستخدم عندما يستدعي \f[B]mkosi\f[R] الأداة
\f[B]systemd\-repart\f[R] عند بناء صورة قرص. إذا كان الدليل
\f[CR]mkosi.repart/\f[R] موجودًا في الدليل المحلي، فسيُستخدم لهذا الغرض
أيضًا. لاحظ أن \f[B]mkosi\f[R] يستدعي repart مع ضبط \f[CR]\-\-root=\f[R] على
جذر صورة الجذر، لذا فإن أي مسارات مصدر لـ \f[CR]CopyFiles=\f[R] في ملفات
تعريف الأقسام ستكون نسبية لدليل جذر الصورة.\fR
.TP 
\f[CR]SectorSize=\f[R]، \f[CR]\-\-sector\-size=\fR
تجاوز حجم القطاع المبدئي الذي تستخدمه \f[B]systemd\-repart\f[R] عند بناء صورة
قرص.\fR
.TP 
\f[CR]Overlay=\f[R]، \f[CR]\-\-overlay=\fR
عند استخدامه مع \f[CR]BaseTrees=\f[R]، سيتألف الإخراج فقط من التغييرات على
أشجار الأساس المحددة. تُوصل كل شجرة أساس كطبقة سفلية في بنية overlayfs،
ويصبح الإخراج هو الطبقة العلوية، والتي تكون فارغة في البداية. وبالتالي فإن
الملفات التي لم تُعدل مقارنة بأشجار الأساس لن تكون موجودة في الإخراج
النهائي.\fR
.RS
.PP
يمكن استخدام هذا الخيار لإنشاء \f[I]امتدادات نظام\f[R] systemd
.UR https://uapi\-group.org/specifications/specs/extension_image
.UE
.\fR
.RE
.TP 
\f[CR]Seed=\f[R]، \f[CR]\-\-seed=\fR
يأخذ UUID كمعطى أو القيمة الخاصة \f[CR]random\f[R]. يتجاوز البذرة التي
تستخدمها \f[B]systemd\-repart\f[R] عند بناء صورة قرص. هذا مفيد لتحقيق بناءات
قابلة لإعادة الإنتاج، حيث يجب اشتقاق معرفات UUID حتمية وبيانات أقسام وصفية
أخرى في كل عملية بناء. إذا لم يُحدد صراحة وكان الملف \f[CR]mkosi.seed\f[R]
موجودًا في الدليل المحلي، يُقرأ معرف UUID منه. خلاف ذلك، يُستخدم UUID
عشوائي.\fR
.TP 
\f[CR]CleanScripts=\f[R]، \f[CR]\-\-clean\-script=\fR
يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي
تُستخدم كسكربتات تنظيف لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.SS "قسم [Content]"
.TP 
\f[CR]Packages=\f[R]، \f[CR]\-\-package=\f[R]، \f[CR]\-p\fR
تثبيت حزم التوزيعة المحددة (مثل RPM و deb وغيرها) في الصورة. يأخذ قائمة
مفصولة بفاصلة من مواصفات الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه
الحالة تُدمج قوائم الحزم المحددة. استخدم \f[CR]BuildPackages=\f[R] لتحديد
الحزم التي يجب تثبيتها فقط في طبقة تغطية (overlay) تُوصل عندما تُنفذ سكربتات
التحضير بمعطى \f[CR]build\f[R] وعند تنفيذ سكربتات البناء.\fR
.RS
.PP
تعتمد أنواع وصيغ \f[I]مواصفات الحزم\f[R] المسموح بها على مثبت الحزم (مثلاً
\f[B]dnf\f[R] للتوزيعات المعتمدة على RPM أو \f[B]apt\f[R] للتوزيعات المعتمدة
على deb)، ولكنها قد تشمل أسماء الحزم، وأسماء الحزم مع الإصدار و/أو
المعمارية، وأنماط أسماء الحزم (globs)، ومجموعات الحزم، والموفرات الافتراضية،
بما في ذلك مسارات الملفات.\fR
.PP
انظر \f[CR]PackageDirectories=\f[R] للحصول على معلومات حول كيفية جعل الحزم
المحلية متاحة للتثبيت باستخدام \f[CR]Packages=\f[R].\fR
.PP
\f[B]مثال\f[R]: عند استخدام توزيعة تستخدم \f[B]dnf\f[R]، فإن الضبط التالي
سيثبت حزمة \f[B]meson\f[R] (بأحدث إصدار)، وإصدار 32 بت من حزمة
\f[CR]libfdisk\-devel\f[R]، وجميع الحزم المتاحة التي تبدأ بالبادئة
\f[CR]git\-\f[R]، وحزمة RPM لـ \f[B]systemd\f[R] من نظام الملفات المحلي،
وإحدى الحزم التي توفر \f[CR]/usr/bin/ld\f[R]، والحزم في مجموعة
\f[I]Development Tools\f[R]، والحزمة التي تحتوي على وحدة python باسم
\f[CR]mypy\f[R].\fR
.IP
.EX
Packages=meson
         libfdisk\-devel.i686
         git\-*
         /usr/bin/ld
         \[at]development\-tools
         python3dist(mypy)
.EE
.RE
.TP 
\f[CR]BuildPackages=\f[R]، \f[CR]\-\-build\-package=\fR
مشابه لـ \f[CR]Packages=\f[R]، ولكنه يضبط الحزم لتثبيتها فقط في طبقة تغطية
(overlay) تُتاح فوق الصورة لسكربتات التحضير عند تنفيذها بمعطى
\f[CR]build\f[R] وسكربتات البناء. يجب استخدام هذا الخيار لسرد الحزم التي
تحتوي على ملفات الترويسة، والمصرفات، وأنظمة البناء، والموصلات وأدوات البناء
الأخرى التي تتطلبها سكربتات \f[CR]mkosi.build\f[R] للعمل. لاحظ أن الحزم
المدرجة هنا ستكون غائبة في الصورة النهائية.\fR
.TP 
\f[CR]VolatilePackages=\f[R]، \f[CR]\-\-volatile\-package=\fR
مشابه لـ \f[CR]Packages=\f[R]، ولكن الحزم المضبوطة بهذا الإعداد لا تُخزن في
الخبيئة عند تفعيل \f[CR]Incremental=\f[R] وتُثبت بعد تنفيذ أي سكربتات
بناء.\fR
.RS
.PP
تحديدًا، يمكن استخدام هذا الإعداد لتثبيت الحزم التي تتغير كثيرًا أو التي
تُبنى بواسطة سكربت بناء.
.RE
.TP 
\f[CR]PackageDirectories=\f[R]، \f[CR]\-\-package\-directory=\fR
حدد الأدلة التي تحتوي على حزم إضافية لتكون متاحة أثناء البناء. سيقوم
\f[B]mkosi\f[R] بإنشاء مستودع محلي يحتوي على جميع الحزم في هذه الأدلة ويجعله
متاحًا عند تثبيت الحزم أو تشغيل السكربتات. إذا وُجد دليل
\f[CR]mkosi.packages/\f[R] في الدليل المحلي، فسيُستخدم أيضًا لهذا الغرض.\fR
.TP 
\f[CR]VolatilePackageDirectories=\f[R]، \f[CR]\-\-volatile\-package\-directory=\fR
مثل \f[CR]PackageDirectories=\f[R]، ولكن أي تغييرات على الحزم في هذه الأدلة
لن تبطل الصور المخزنة في الخبيئة إذا فُعل \f[CR]Incremental=\f[R].\fR
.RS
.PP
بالإضافة إلى ذلك، يمكن لسكربتات البناء إضافة المزيد من الحزم إلى المستودع
المحلي بوضع الحزم المبنية في \f[CR]$PACKAGEDIR\f[R]. تُشارك الحزم الموضوعة
في \f[CR]$PACKAGEDIR\f[R] بين جميع عمليات بناء الصور وبالتالي تكون متاحة
للتثبيت في جميع الصور باستخدام \f[CR]VolatilePackages=\f[R].\fR
.RE
.TP 
\f[CR]WithRecommends=\f[R]، \f[CR]\-\-with\-recommends=\fR
يضبط ما إذا كان سيُثبت التبعات الموصى بها أو الضعيفة، اعتمادًا على تسميتها
بواسطة مدير الحزم المستخدم، أم لا. مبدئيًا، لا تُثبت الحزم الموصى
بها. يُستخدم هذا فقط لمديري الحزم الذين يدعمون هذا المفهوم، وهم حاليًا
\f[B]apt\f[R] و \f[B]dnf\f[R] و \f[B]zypper\f[R].\fR
.TP 
\f[CR]WithDocs=\f[R]، \f[CR]\-\-with\-docs=\fR
تضمين التوثيق في الصورة. مفعل مبدئيًا. عند تعطيله، وإذا كان مدير حزم
التوزيعة الأساسية يدعم ذلك، فلن يُضمن التوثيق في الصورة. يُضبط متغير البيئة
\f[CR]$WITH_DOCS\f[R] الممرر لسكربتات \f[CR]mkosi.build\f[R] على
\f[CR]0\f[R] أو \f[CR]1\f[R] بناءً على ما إذا كان هذا الخيار مفعلاً أم
معطلاً.\fR
.TP 
\f[CR]BaseTrees=\f[R]، \f[CR]\-\-base\-tree=\fR
يأخذ قائمة مفصولة بفاصلة من المسارات لاستخدامها كأشجار أساس. عند استخدامها،
تُنسخ كل من أشجار الأساس هذه إلى شجرة نظام التشغيل وتشكل التوزيعة الأساسية
بدلاً من تثبيت التوزيعة من الصفر. تُثبت الحزم الإضافية فقط فوق الحزم المثبتة
بالفعل في أشجار الأساس. لاحظ أنه لكي يعمل هذا بشكل صحيح، لا تزال صورة الأساس
بحاجة إلى احتواء البيانات الوصفية لمدير الحزم عن طريق ضبط
\f[CR]CleanPackageMetadata=no\f[R] (انظر
\f[CR]CleanPackageMetadata=\f[R]).\fR
.RS
.PP
بدلاً من الدليل، يمكن توفير ملف tar أو صورة قرص. في هذه الحالة تُفك في شجرة
نظام التشغيل. يسمح وضع التشغيل هذا بضبط الأذونات وملكية الملفات صراحةً،
لاسيما للمشاريع المخزنة في نظام تحكم في الإصدارات مثل \f[B]git\f[R] والتي
تحتفظ بملكية الملفات الكاملة وبيانات وضع الوصول الوصفية للملفات المودعة.\fR
.RE
.TP 
\f[CR]SkeletonTrees=\f[R]، \f[CR]\-\-skeleton\-tree=\fR
يأخذ قائمة مفصولة بفاصلة من أزواج مسارات مفصولة بنقطتين رأسيتين. يشير المسار
الأول من كل زوج إلى دليل لنسخه إلى شجرة نظام التشغيل قبل استدعاء مدير
الحزم. يشير المسار الثاني من كل زوج إلى الدليل المستهدف داخل الصورة. إذا لم
يُوفر المسار الثاني، يُنسخ الدليل فوق دليل الجذر للصورة. يُفسر المسار الثاني
دائمًا كمسار مطلق. استخدم هذا لإدراج الملفات والأدلة في شجرة نظام التشغيل
قبل أن يثبت مدير الحزم أي حزم. إذا وُجد دليل \f[CR]mkosi.skeleton/\f[R] في
الدليل المحلي، فسيُستخدم أيضًا لهذا الغرض مع دليل الجذر كهدف (انظر أيضًا قسم
\f[B]FILES\f[R] أدناه).\fR
.RS
.PP
لاحظ أن أشجار الهيكل (skeleton) تُخزن في الخبيئة، وأي تغييرات عليها بعد بناء
صورة مخزنة (عند استخدام \f[CR]Incremental=\f[R]) لا تُطبق إلا عند إعادة بناء
الصورة المخزنة (باستخدام \f[CR]\-ff\f[R] أو تشغيل \f[CR]mkosi \-f
clean\f[R]).\fR
.PP
كما هو الحال مع منطق شجرة الأساس أعلاه، يمكن توفير ملف tar بدلاً من الدليل
أيضًا. سيُستخدم \f[CR]mkosi.skeleton.tar\f[R] آليًا إذا وُجد في الدليل
المحلي.\fR
.PP
لإضافة ملفات ضبط إضافية لمدير الحزم مثل المستودعات الإضافية، استخدم
\f[CR]SandboxTrees=\f[R] لأن \f[B]mkosi\f[R] يستدعي مديري الحزم من خارج
الصورة وليس داخلها، لذا فإن أي ملفات ضبط لمدير الحزم تُوفر عبر
\f[CR]SkeletonTrees=\f[R] لن يسري مفعولها عندما يستدعي \f[B]mkosi\f[R] مدير
الحزم لتثبيت الحزم.\fR
.RE
.TP 
\f[CR]ExtraTrees=\f[R]، \f[CR]\-\-extra\-tree=\fR
يأخذ قائمة مفصولة بفاصلة من أزواج مسارات مفصولة بنقطتين رأسيتين. يشير المسار
الأول من كل زوج إلى دليل لنسخه من المضيف إلى الصورة. يشير المسار الثاني من
كل زوج إلى الدليل المستهدف داخل الصورة. إذا لم يُوفر المسار الثاني، يُنسخ
الدليل فوق دليل الجذر للصورة. يُفسر المسار الثاني دائمًا كمسار مطلق. استخدم
هذا لتجاوز أي ملفات ضبط مبدئية مشحونة مع التوزيعة. إذا وُجد دليل
\f[CR]mkosi.extra/\f[R] في الدليل المحلي، فسيُستخدم أيضًا لهذا الغرض مع دليل
الجذر كهدف (انظر أيضًا قسم \f[B]FILES\f[R] أدناه).\fR
.RS
.PP
كما هو الحال مع منطق شجرة الأساس أعلاه، يمكن توفير ملف tar بدلاً من الدليل
أيضًا. سيُستخدم \f[CR]mkosi.extra.tar\f[R] آليًا إذا وُجد في الدليل
المحلي.\fR
.RE
.TP 
\f[CR]RemovePackages=\f[R]، \f[CR]\-\-remove\-package=\fR
يأخذ قائمة مفصولة بفاصلة من مواصفات الحزم للإزالة، بنفس تنسيق
\f[CR]Packages=\f[R]. ستُنفذ الإزالة كواحدة من الخطوات الأخيرة. تُتخطى هذه
الخطوة إذا استُخدم \f[CR]CleanPackageMetadata=no\f[R].\fR
.TP 
\f[CR]RemoveFiles=\f[R]، \f[CR]\-\-remove\-files=\fR
يأخذ قائمة مفصولة بفاصلة من الأنماط (globs). ستُحذف الملفات في الصورة التي
تطابق الأنماط في النهاية.
.TP 
\f[CR]CleanPackageMetadata=\f[R]، \f[CR]\-\-clean\-package\-metadata=\fR
تفعيل/تعطيل إزالة قواعد بيانات مدير الحزم والبيانات الوصفية للمستودع عند
نهاية التثبيت. يمكن تحديده كـ \f[CR]true\f[R]، أو \f[CR]false\f[R]، أو
\f[CR]auto\f[R] (المبدئي). مع \f[CR]auto\f[R]، ستُزال قواعد بيانات مدير
الحزم والبيانات الوصفية للمستودع إذا كان ملف مدير الحزم القابل للتنفيذ
المعني \f[I]غير\f[R] موجود عند نهاية التثبيت.\fR
.TP 
\f[CR]SourceDateEpoch=\f[R]، \f[CR]\-\-source\-date\-epoch=\fR
يأخذ طابعًا زمنيًا بالثواني منذ حقبة UNIX كمعطى. ستُحصر أوقات تعديل الملفات
لجميع الملفات في هذه القيمة. يُمرر المتغير أيضًا إلى
\f[B]systemd\-repart\f[R] والسكربتات التي ينفذها \f[B]mkosi\f[R]. إذا لم
يُضبط صراحةً، تُجرب قيمة \f[CR]SOURCE_DATE_EPOCH\f[R] من
\f[CR]\-\-environment=\f[R] ومن بيئة المضيف بهذا الترتيب. هذا مفيد لجعل
البناءات قابلة لإعادة الإنتاج. انظر
.UR https://reproducible\-builds.org/specs/source\-date\-epoch/
SOURCE_DATE_EPOCH
.UE
لمزيد من المعلومات.\fR
.TP 
\f[CR]SyncScripts=\f[R]، \f[CR]\-\-sync\-script=\fR
يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي
تُستخدم كسكربتات مزامنة لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.TP 
\f[CR]PrepareScripts=\f[R]، \f[CR]\-\-prepare\-script=\fR
يأخذ قائمة مفصولة بفاصلة من المسارات إلى الملفات القابلة للتنفيذ التي
تُستخدم كسكربتات تحضير لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.TP 
\f[CR]BuildScripts=\f[R]، \f[CR]\-\-build\-script=\fR
يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج
بناء نصية لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من المعلومات.\fR
.TP 
\f[CR]PostInstallationScripts=\f[R], \f[CR]\-\-postinst\-script=\fR
يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج
ما بعد التثبيت النصية لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.TP 
\f[CR]FinalizeScripts=\f[R], \f[CR]\-\-finalize\-script=\fR
يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج
الإنهاء النصية لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.TP 
\f[CR]PostOutputScripts=\f[R], \f[CR]\-\-postoutput\-script=\fR
يأخذ قائمة مفصولة بفواصل من المسارات للملفات التنفيذية التي تُستخدم كبرامج
ما بعد الإخراج النصية لهذه الصورة. انظر قسم \f[B]SCRIPTS\f[R] لمزيد من
المعلومات.\fR
.TP 
\f[CR]Bootable=\f[R], \f[CR]\-\-bootable=\fR
يأخذ قيمة منطقية أو \f[CR]auto\f[R]. يُفعّل أو يُعطّل توليد صورة قابلة
للإقلاع. في حال التفعيل، سيثبّت \f[B]mkosi\f[R] محمّل إقلاع EFI، ويضيف قسم
ESP عند استخدام مخرج صورة القرص. إذا كان محمّل إقلاع EFI المختار (انظر
\f[CR]Bootloader=\f[R]) غير مثبت أو لم يُعثر على صور نواة، سيفشل
البناء. يسلك الخيار \f[CR]auto\f[R] سلوك التفعيل، لكن البناء لن يفشل إذا لم
يُعثر على صور نواة أو لم يُعثر على محمّل إقلاع EFI المختار. في حال التعطيل،
لن يُثبّت أي محمّل إقلاع حتى لو وُجد داخل الصورة، ولن تُولد صور نواة موحدة
ولن يُضاف قسم ESP إلى الصورة إذا استُخدم تنسيق مخرج القرص.\fR
.RS
.PP
إذا استُخدم تنسيق المخرج \f[CR]esp\f[R]، يضاف قسم ESP ومحمّل الإقلاع دائمًا،
ويتحكم الخيار \f[CR]Bootable=\f[R] فقط فيما إذا كانت ستضاف صورة نواة موحدة
(UKI) إلى قسم ESP أم لا.\fR
.RE
.TP 
\f[CR]Bootloader=\f[R], \f[CR]\-\-bootloader=\fR
يأخذ أحد القيم: \f[CR]none\f[R]، أو \f[CR]systemd\-boot\f[R]، أو
\f[CR]uki\f[R]، أو \f[CR]grub\f[R]، أو \f[CR]systemd\-boot\-signed\f[R]، أو
\f[CR]uki\-signed\f[R]، أو \f[CR]grub\-signed\f[R]. القيمة المبدئية هي
\f[CR]systemd\-boot\f[R]. إذا ضُبط على \f[CR]none\f[R]، لن يُثبّت أي محمّل
إقلاع EFI في الصورة. إذا ضُبط على \f[CR]systemd\-boot\f[R]، سيُثبّت
\f[B]systemd\-boot\f[R] وستُولد صورة نواة موحدة (UKI) لكل نواة مثبتة وتُخزن
في \f[CR]EFI/Linux\f[R] في ESP. إذا ضُبط على \f[CR]uki\f[R]، ستُولد صورة
نواة موحدة واحدة لأحدث نواة مثبتة (ذات الإصدار الأعلى) وتُثبّت في
\f[CR]EFI/BOOT/BOOTX64.EFI\f[R] في ESP. إذا ضُبط على \f[CR]grub\f[R]، ستُولد
صورة نواة موحدة لكل نواة مثبتة وتُخزن في \f[CR]EFI/Linux\f[R] في ESP. ولكل
صورة موحدة مولدة، يُلحق مدخل قائمة إلى تهيئة grub في
\f[CR]grub/grub.cfg\f[R] في ESP والذي يقوم بتحميل الصورة الموحدة
تسلسليًا. ويُكتب أيضًا ملف grub.cfg وسيط إلى
\f[CR]EFI/<distribution>/grub.cfg\f[R] في ESP والذي يقوم بتحميل
\f[CR]grub/grub.cfg\f[R] في ESP للتوافق مع إصدارات grub الموقعة التي تحمل
تهيئة grub من هذا الموقع.\fR
.RS
.PP
ستقوم المتغيرات الموقعة (\f[CR]signed\f[R]) فقط بتثبيت ثنائيات EFI الموقعة
مسبقًا والتي تشحنها التوزيعة.\fR
.PP
يجب وضع النوى في نظام الملفات الجذر (على سبيل المثال باستخدام
\f[CR]ExtraTrees=\f[R]) تحت \f[CR]/usr/lib/modules/$version\f[R]، باسم
\f[CR]vmlinux\f[R] أو \f[CR]vmlinuz\f[R]. الإصدار \f[CR]$version\f[R] هو ما
ينتجه هدف make المسمى \f[CR]kernelversion\f[R] الخاص بـ Kbuild.\fR
.PP
ملاحظة: عند استخدام \f[CR]systemd\-boot\f[R] أو
\f[CR]systemd\-boot\-signed\f[R]، يتوقع \f[B]mkosi\f[R] وجود ثنائيات EFI
الخاصة بـ \f[CR]systemd\-boot\f[R] في الصورة. اعتمادًا على توزيعتك، قد تكون
هذه محزمة بشكل منفصل. على سبيل المثال، ستحتاج الصور المبنية على دبيان إلى
\f[CR]systemd\-boot\-efi\f[R].\fR
.RE
.TP 
\f[CR]BiosBootloader=\f[R], \f[CR]\-\-bios\-bootloader=\fR
يأخذ أحد القيم \f[CR]none\f[R] أو \f[CR]grub\f[R]. القيمة المبدئية هي
\f[CR]none\f[R]. إذا ضُبط على \f[CR]none\f[R]، لن يُثبّت محمّل إقلاع
BIOS. إذا ضُبط على \f[CR]grub\f[R]، سيُثبّت grub كمحمّل إقلاع BIOS إذا طُلبت
صورة قابلة للإقلاع باستخدام خيار \f[CR]Bootable=\f[R]. إذا لم تُضبط أي ملفات
تعريف أقسام repart، سيضيف \f[B]mkosi\f[R] قسم إقلاع grub BIOS وقسم نظام EFI
إلى ملفات تعريف الأقسام المبدئية.\fR
.RS
.PP
لاحظ أن هذا الخيار لا يتعارض مع \f[CR]Bootloader=\f[R]. من الممكن الحصول على
صورة قابلة للإقلاع على كل من UEFI و BIOS عن طريق ضبط كل من
\f[CR]Bootloader=\f[R] و \f[CR]BiosBootloader=\f[R].\fR
.PP
يجب أن يكون لقسم إقلاع grub BIOS المعرف UUID التالي:
\f[CR]21686148\-6449\-6e6f\-744e\-656564454649\f[R] وأن لا تقل مساحته عن 1
ميجابايت.\fR
.PP
حتى لو لم يُثبّت محمّل إقلاع EFI، سنظل بحاجة إلى قسم ESP لإقلاع BIOS حيث
أننا هناك سنخزن النواة، و initrd ووحدات grub.
.RE
.TP 
\f[CR]ShimBootloader=\f[R], \f[CR]\-\-shim\-bootloader=\fR
يأخذ أحد القيم: \f[CR]none\f[R]، أو \f[CR]unsigned\f[R]، أو
\f[CR]signed\f[R]. القيمة المبدئية هي \f[CR]none\f[R]. إذا ضُبط على
\f[CR]none\f[R]، لن يُثبّت shim و MokManager في ESP. إذا ضُبط على
\f[CR]unsigned\f[R]، سيبحث \f[B]mkosi\f[R] عن ثنائيات EFI لـ shim و
MokManager غير الموقعة ويقوم بتثبيتها. وإذا كان \f[CR]SecureBoot=\f[R]
مفعلًا، سيقوم \f[B]mkosi\f[R] بتوقيع الثنائيات غير الموقعة قبل تثبيتها. أما
إذا ضُبط على \f[CR]signed\f[R]، سيبحث \f[B]mkosi\f[R] عن الثنائيات الموقعة
ويثبتها. وحتى لو كان الإقلاع الآمن مفعلًا، لن يقوم \f[B]mkosi\f[R] بتوقيع
هذه الثنائيات مرة أخرى.\fR
.RS
.PP
لاحظ أن هذا الخيار لا يسري مفعوله إلا عند طلب صورة قابلة للإقلاع على برمجيات
UEFI الثابتة باستخدام خيارات أخرى (\f[CR]Bootable=\f[R]،
\f[CR]Bootloader=\f[R]).\fR
.PP
لاحظ أنه عند تفعيل هذا الخيار، سيقوم \f[B]mkosi\f[R] فقط بتثبيت ثنائيات محمل
الإقلاع الموقعة مسبقًا، وملفات صور النواة، وصور النواة الموحدة لأن الثنائيات
ذاتية التوقيع لن تُقبل من قِبل نسخة shim الموقعة.
.RE
.TP 
\f[CR]UnifiedKernelImages=\f[R], \f[CR]\-\-unified\-kernel\-images=\fR
يحدد ما إذا كان سيتم استخدام صور النواة الموحدة (UKI) أم لا عندما يكون
\f[CR]Bootloader=\f[R] مضبوطًا على \f[CR]systemd\-boot\f[R] أو
\f[CR]grub\f[R]. يأخذ أحد القيم: \f[CR]none\f[R]، أو \f[CR]unsigned\f[R]، أو
\f[CR]signed\f[R]، أو \f[CR]auto\f[R]. القيمة المبدئية هي
\f[CR]auto\f[R]. إذا كان \f[CR]unsigned\f[R] أو \f[CR]signed\f[R]، تُستخدم
الصور الموحدة دائمًا وسيفشل البناء في حال فقدان أي مكون مطلوب لبنائها. إذا
ضُبط على \f[CR]auto\f[R]، ستُستخدم الصور الموحدة إذا توفرت كافة المكونات
اللازمة؛ وإلا ستُستخدم مداخل النوع 1 (Type 1) كما هي محددة في مواصفات محمل
الإقلاع (Boot Loader Specification). في حال التعطيل، ستُستخدم مداخل النوع 1
دائمًا. وإذا ضُبط \f[CR]Bootloader=\f[R] على أحد المتغيرات الموقعة، سيُبحث
عن صورة موحدة مبنية مسبقًا وسيفشل البناء إذا لم يُعثر عليها، ما لم يُضبط
\f[CR]UnifiedKernelImages=\f[R] على \f[CR]unsigned\f[R]، وفي هذه الحالة
ستُبنى الصورة الموحدة محليًا. هذا مفيد عند الجمع بين خيار وقت التشغيل
\f[CR]Firmware=\f[R] المضبوط على \f[CR]custom\f[R] بحيث يُدرج مفتاح التوقيع
المحلي في قاعدة بيانات UEFI db.\fR
.TP 
\f[CR]UnifiedKernelImageFormat=\f[R], \f[CR]\-\-unified\-kernel\-image\-format=\fR
يأخذ اسم ملف دون أي مكونات مسار لتحديد التنسيق الذي يجب تثبيت صور النواة
الموحدة به. قد يشمل ذلك كلاً من المحددات العادية (انظر \f[B]المحددات\f[R])
والمحددات المؤجلة الخاصة، التي يتم توسيعها أثناء تثبيت الملفات، والموصوفة
أدناه. التنسيق المبدئي لهذا المعامل هو \f[CR]&e\-&k\f[R] مع إلحاق
\f[CR]\-&h\f[R] إذا وُجد \f[CR]roothash=\f[R] أو \f[CR]usrhash=\f[R] في سطر
أوامر النواة و \f[CR]+&c\f[R] إذا وُجد \f[CR]/etc/kernel/tries\f[R] في
الصورة.\fR
.RS
.PP
يمكن استخدام المحددات التالية:
.PP
.TS
tab(@);
l l.
T{
المحدد
T}@T{
القيمة
T}
_
T{
\f[CR]&&\fR
T}@T{
محرف \f[CR]&\f[R]
T}
T{
\f[CR]&e\fR
T}@T{
\f[R]رمز المدخل\fR
T}
T{
\f[CR]&k\fR
T}@T{
\f[R]إصدار النواة\fR
T}
T{
\f[CR]&h\fR
T}@T{
قيمة وسيط النواة \f[CR]roothash=\f[R] أو \f[CR]usrhash=\f[R]
T}
.TE
.RE
.TP 
\f[CR]UnifiedKernelImageProfiles=\f[R], \f[CR]\-\-uki\-profile=\fR
بناء تشكيلات UKI إضافية. يأخذ قائمة مفصولة بفواصل من المسارات لملفات تهيئة
تشكيلات UKI. يمكن استخدام هذا الخيار عدة مرات حيث تُبنى كل تهيئة في تشكيلة
UKI مقابلة. يتم جلب ملفات التهيئة في دليل \f[CR]mkosi.uki\-profiles/\f[R]
آليًا. وتُضاف كافة تشكيلات UKI المهيأة كتشكيلات UKI إضافية لكل UKI يبنيه
\f[B]mkosi\f[R].\fR
.RS
.PP
انظر توثيق قسم \f[CR]UKIProfile\f[R] لمعلومات حول الإعدادات التي يمكن ضبطها
في ملفات تهيئة تشكيلات UKI.\fR
.RE
.TP 
\f[CR]Initrds=\f[R], \f[CR]\-\-initrd=\fR
استخدام ملفات initrd التي يوفرها المستخدم. يأخذ قائمة مفصولة بفواصل من
المسارات لملفات initrd. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة
تُدمج قوائم initrd. إذا لم تُحدد أي ملفات initrd وطُلبت صورة قابلة للإقلاع،
سيقوم \f[B]mkosi\f[R] آليًا ببناء initrd مبدئي.\fR
.RS
.PP
سيبحث \f[B]mkosi\f[R] أيضًا عن ملفات initrd في الدليل الفرعي
\f[CR]io.mkosi.initrd\f[R] التابع لدليل النتائج (انظر
\f[CR]$ARTIFACTDIR\f[R] في قسم \f[B]ENVIRONMENT VARIABLES\f[R]). تُلحق أي
ملفات initrd توجد هناك بملفات initrd التي وفرها المستخدم وأي initrd مبدئي
بناه mkosi.\fR
.RE
.TP 
\f[CR]InitrdProfiles=\f[R], \f[CR]\-\-initrd\-profile=\fR
ضبط التشكيلات لتفعيلها في initrd المبدئي. يأخذ قائمة تشكيلات مفصولة
بفواصل. تكون كافة التشكيلات معطلة مبدئيًا.
.RS
.PP
تُمكّن تشكيلة \f[CR]lvm\f[R] دعم LVM. وتُمكّن تشكيلة \f[CR]network\f[R] دعم
الشبكة عبر \f[B]systemd\-networkd\f[R]. وتُمكّن تشكيلة \f[CR]nfs\f[R] دعم
NFS. وتتطلب وجود شبكة في initrd، باستخدام تشكيلة \f[CR]network\f[R]، أو
طريقة مخصصة أخرى. وتُمكّن تشكيلة \f[CR]pkcs11\f[R] دعم PKCS#11. وتوفر تشكيلة
\f[CR]plymouth\f[R] واجهة رسومية عند الإقلاع (رسوم متحركة ومحث كلمة
مرور). وتُمكّن تشكيلة \f[CR]raid\f[R] دعم مصفوفات RAID.\fR
.RE
.TP 
\f[CR]InitrdPackages=\f[R], \f[CR]\-\-initrd\-package=\fR
حزم إضافية لتثبيتها في initrd المبدئي. يأخذ قائمة مفصولة بفواصل لمواصفات
الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم الحزم
المحددة.
.TP 
\f[CR]InitrdVolatilePackages=\f[R], \f[CR]\-\-initrd\-volatile\-package=\fR
مشابه لـ \f[CR]VolatilePackages=\f[R]، فيما عدا أنه ينطبق على initrd
المبدئي.\fR
.TP 
\f[CR]Devicetrees=\f[R], \f[CR]\-\-devicetrees=\fR
قائمة مفصولة بفواصل لأنماط شجرة الأجهزة (devicetree) للاختيار الآلي بناءً
على العتاد. الأنماط هي تعبيرات نمطية (glob). يبحث \f[B]mkosi\f[R] عن ملفات
شجرة الأجهزة في المواقع القياسية بالنسبة إلى
\f[CR]/usr/lib/modules/<kver>/dtb/\f[R]، و
\f[CR]/usr/lib/firmware/<kver>/device\-tree/\f[R]، و
\f[CR]/usr/lib/linux\-image\-<kver>/\f[R].\fR
.RS
.PP
بالنسبة لبناء UKI، تُفعّل التطابقات المتعددة الاختيار الآلي بناءً على العتاد
باستخدام أقسام \f[CR].dtbauto\f[R]. تتطلب مداخل إقلاع النوع 1 تطابقًا واحدًا
بالضبط.\fR
.PP
مثال: \f[CR]Devicetrees=rockchip/*,imx.*\f[R] سيشمل جميع أشجار أجهزة
Rockchip وأي أشجار أجهزة IMX.\fR
.RE
.TP 
\f[CR]Splash=\f[R], \f[CR]\-\-splash=\fR
عند ضبطه، سيتم جلب شاشة البداية (boot splash) لأي صورة نواة موحدة يبنيها
\f[B]mkosi\f[R] من المسار المعطى داخل الصورة.\fR
.TP 
\f[CR]MicrocodeHost=\f[R], \f[CR]\-\-microcode\-host=\fR
عند ضبطه على صواب (true) يتم فقط تضمين الكود الدقيق (microcode) لوحدة
المعالجة المركزية للمضيف في الصورة.
.TP 
\f[CR]KernelCommandLine=\f[R], \f[CR]\-\-kernel\-command\-line=\fR
استخدام سطر أوامر النواة المحدد عند بناء الصور.
.RS
.PP
إذا أُنشئ قسم الجذر (root) أو قسم /usr مع تفعيل verity، يُضاف
\f[CR]roothash=\f[R] أو \f[CR]usrhash=\f[R] على التوالي آليًا إلى سطر أوامر
النواة ويجب عدم إضافة \f[CR]root=\f[R] أو \f[CR]mount.usr=\f[R]. بخلاف ذلك،
إذا احتوت قيمة هذا الإعداد على الثوابت الحرفية \f[CR]root=PARTUUID\f[R] أو
\f[CR]mount.usr=PARTUUID\f[R]، تُستبدل هذه بالمعرف الفريد العالمي (UUID)
للقسم الخاص بالجذر أو /usr على التوالي. على سبيل المثال، سيُستبدل
\f[CR]root=PARTUUID\f[R] بـ
\f[CR]root=PARTUUID=58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] حيث أن
\f[CR]58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] هو UUID لقسم الجذر.\fR
.RE
.TP 
\f[CR]KernelModules=\f[R], \f[CR]\-\-kernel\-modules=\fR
يأخذ قائمة من أنماط glob التي تحدد أي وحدات النواة يجب تضمينها في
الصورة. يمكن بادئة كل وسيط بشرطة (\f[CR]\-\f[R]) لـ \f[I]استبعاد\f[R] الوحدات
المطابقة. تُقيّم الوسائط بالترتيب، ويحدد آخر نمط مطابق (سواء كان إيجابيًا أو
سلبيًا) النتيجة. تُضمن الوحدات التي تطابقت آخِرًا مع نمط إيجابي في الصورة،
بالإضافة إلى تبعيات الوحدة والبرمجيات الثابتة الخاصة بها.\fR
.RS
.PP
يتم تجاهل اللاحقة \f[CR].ko\f[R] ولاحقة الضغط أثناء المطابقة.\fR
.PP
تُطابق الأنماط مع مسارات الوحدات بالنسبة إلى
\f[CR]/usr/lib/module/<kver>\f[R]، على سبيل المثال، الوحدة الموجودة
في \f[CR]/usr/lib/module/<kver>/kernel/foo/bar.ko.xz\f[R] تصبح
\f[CR]kernel/foo/bar\f[R] لأغراض المطابقة.\fR
.PP
تُعامل الأنماط التي تبدأ بـ "/" معاملة خاصة. يُطابق النمط \f[I]أولاً\f[R] مع
مسار بالنسبة لـ \f[CR]/usr/lib/module/<kver>/kernel\f[R]، وبعد ذلك
فقط مع \f[CR]/usr/lib/module/<kver>/\f[R]. هذا لتسهيل الأمر، حيث أن
الاهتمام ينصب عادةً على الوحدات المدمجة تحت \f[CR]kernel/\f[R].\fR
.PP
على سبيل المثال، الوحدة الموجودة في
\f[CR]/usr/lib/module/<kver>/kernel/foo/bar.ko.xz\f[R] يمكن مطابقتها
بـ \f[CR]/foo/bar\f[R] أو \f[CR]/kernel/foo/bar\f[R].\fR
.PP
قد تتضمن أنماط glob الاسم الأساسي فقط (مثل \f[CR]loop\f[R])، والذي يجب أن
يطابق الاسم الأساسي للوحدة، أو المسار النسبي (مثل \f[CR]block/loop\f[R])،
والذي يجب أن يطابق المكونات النهائية لمسار الوحدة حتى الاسم الأساسي، أو
مسارًا مطلقًا (مثل \f[CR]/drivers/block/loop\f[R])، والذي يجب أن يطابق
المسار الكامل للوحدة.\fR
.PP
عند إلحاق \f[CR]/\f[R]، سيطابق النمط جميع الوحدات الموجودة تحت ذلك
الدليل.\fR
.PP
قد تتضمن الأنماط تعبيرات glob بنمط الصدفة (\f[CR]*\f[R]، \f[CR]?\f[R]،
\f[CR][\&...\-\&...]\f[R]).\fR
.PP
إذا استُخدمت القيمة الخاصة \f[CR]default\f[R]، تُضمن وحدات النواة المبدئية
المحددة في تهيئة \f[B]mkosi\-initrd\f[R] أيضًا.\fR
.PP
إذا استُخدمت القيمة الخاصة \f[CR]host\f[R]، تُضمن الوحدات المحملة حاليًا على
نظام المضيف أيضًا.\fR
.RE
.TP 
\f[CR]KernelModulesInitrd=\f[R], \f[CR]\-\-kernel\-modules\-initrd=\fR
قيمة منطقية، مفعلة (true) مبدئيًا. إذا فُعلت، سيقوم \f[B]mkosi\f[R] عند بناء
صورة قابلة للإقلاع بتوليد initrd إضافي لكل صورة نواة موحدة يجمعها. يحتوي هذا
الـ initrd فقط على الوحدات وربما البرمجيات الثابتة، ثم يُلحق بـ initrd
الأساسي لتشكيل ملف initrd النهائي. يحافظ هذا على استقلالية initrd الأساسي عن
النواة، ويقوم فقط بتعزيزه بالوحدات اللازمة والخاصة بإصدار النواة عند تجميع
صورة النواة الموحدة (UKI).\fR
.RS
.PP
في حال التعطيل، لا يُولد initrd إضافي. لاحظ أن وحدات النواة ستظل
\f[B]غير\f[R] مضمنة في initrd الأساسي، الذي يظل مستقلاً عن النواة. وبدلاً من
ذلك، يُفترض أن المستخدم سيوفر الوحدات اللازمة، إن وجدت، عبر initrd مخصص
إضافي.\fR
.RE
.TP 
\f[CR]KernelInitrdModules=\f[R], \f[CR]\-\-kernel\-modules\-initrd\-include=\fR
مثل \f[CR]KernelModules=\f[R]، ولكنه يحدد وحدات النواة التي سيتم تضمينها في
initrd.\fR
.TP 
\f[CR]FirmwareFiles=\f[R], \f[CR]\-\-firmware\-files=\fR
يأخذ قائمة من أنماط glob التي تحدد ملفات البرمجيات الثابتة التي يجب تضمينها
في الصورة. تُفسر الأنماط بنفس طريقة إعدادات \f[CR]KernelModules=\f[R]، إلا
أن المسارات تكون نسبية لـ \f[CR]/usr/lib/firmware/<subdir>\f[R]. يتم
تجاهل لاحقة الضغط ويجب عدم تضمينها في النمط.\fR
.RS
.PP
يتم تضمين تبعيات البرمجيات الثابتة لوحدات النواة المثبتة في الصورة آليًا.
.PP
مثال: \f[CR]FirmwareFiles=cxgb4/bcm8483.bin\f[R] أو
\f[CR]FirmwareFiles=bcm8483.*\f[R] سيؤدي كلاهما إلى تضمين
\f[CR]/usr/lib/firmware/cxgb4/bcm8483.bin.xz\f[R]، حتى لو لم تدرجها وحدة.\fR
.RE
.TP 
\f[CR]Locale=\f[R], \f[CR]\-\-locale=\f[R], \f[CR]LocaleMessages=\f[R], \f[CR]\-\-locale\-messages=\f[R], \f[CR]Keymap=\f[R], \f[CR]\-\-keymap=\f[R], \f[CR]Timezone=\f[R], \f[CR]\-\-timezone=\f[R], \f[CR]Hostname=\f[R], \f[CR]\-\-hostname=\f[R], \f[CR]RootShell=\f[R], \f[CR]\-\-root\-shell=\fR
الإعدادات \f[CR]Locale=\f[R]، و \f[CR]\-\-locale=\f[R]، و
\f[CR]LocaleMessages=\f[R]، و \f[CR]\-\-locale\-messages=\f[R]، و
\f[CR]Keymap=\f[R]، و \f[CR]\-\-keymap=\f[R]، و \f[CR]Timezone=\f[R]، و
\f[CR]\-\-timezone=\f[R]، و \f[CR]Hostname=\f[R]، و \f[CR]\-\-hostname=\f[R]، و
\f[CR]RootShell=\f[R]، و \f[CR]\-\-root\-shell=\f[R] تقابل خيارات
systemd\-firstboot التي تحمل نفس الاسم. انظر \f[B]systemd\-firstboot\f[R](1)
لمزيد من المعلومات. بالإضافة إلى ذلك، وحيثما أمكن، تُكتب وثائق استيثاق
systemd المقابلة لهذه الإعدادات في \f[CR]/usr/lib/credstore\f[R]، لكي تنطبق
حتى لو تم شحن \f[CR]/usr\f[R] فقط في الصورة.\fR
.TP 
\f[CR]RootPassword=\f[R], \f[CR]\-\-root\-password=\f[R],\fR
تعيين كلمة مرور الجذر للنظام. إذا لم يُستخدم هذا الخيار، ولكن وُجد ملف
\f[CR]mkosi.rootpw\f[R] في الدليل المحلي، تُقرأ كلمة المرور منه آليًا أو إذا
كان الملف قابلاً للتنفيذ يُشغل كبرنامج نصي ويُقرأ خرجه القياسي بدلاً من ذلك
(انظر قسم \f[B]SCRIPTS\f[R] أدناه). إذا بدأت كلمة المرور بـ
\f[CR]hashed:\f[R]، تُعامل ككلمة مرور جذر مُموهة (hashed) بالفعل. تُخزن كلمة
مرور الجذر أيضًا في \f[CR]/usr/lib/credstore\f[R] تحت وثيقة استيثاق systemd
المناسبة لكي تنطبق حتى لو تم شحن \f[CR]/usr\f[R] فقط في الصورة. لإنشاء حساب
مفتوح بدون أي كلمة مرور استخدم \f[CR]hashed:\f[R] بدون أي قيمة مموهة.\fR
.TP 
\f[CR]Autologin=\f[R], \f[CR]\-\-autologin=\f[R], \f[CR]\-a\fR
تفعيل الولوج الآلي لمستخدم الجذر (\f[CR]root\f[R]) على \f[CR]/dev/pts/0\f[R]
(nspawn)، و \f[CR]/dev/tty1\f[R] و \f[CR]/dev/hvc0\f[R].\fR
.TP 
\f[CR]MakeInitrd=\f[R], \f[CR]\-\-make\-initrd=\fR
إضافة \f[CR]/etc/initrd\-release\f[R] و \f[CR]/init\f[R] إلى الصورة لكي يمكن
استخدامها كـ initramfs.\fR
.TP 
\f[CR]Ssh=\f[R], \f[CR]\-\-ssh=\fR
يحدد ما إذا كان سيتم تثبيت وحدة مقبس \f[B]sshd\f[R] والخدمة المقابلة لها في
الصورة النهائية. يأخذ أحد القيم: \f[CR]always\f[R]، أو \f[CR]never\f[R]، أو
\f[CR]auto\f[R]، أو \f[CR]runtime\f[R]. القيمة المبدئية هي
\f[CR]auto\f[R].\fR
.RS
.PP
إذا ضُبط على \f[CR]auto\f[R] وكان \f[CR]sshd\f[R] موجودًا في الصورة وثنائي
المولد \f[CR]systemd\-ssh\-generator\f[R] غير موجود، أو إذا ضُبط على
\f[CR]always\f[R]، سيقوم mkosi بتثبيت وحدات \f[B]sshd\f[R] في الصورة
النهائية التي تعرض SSH عبر VSock. إذا ضُبط على \f[CR]never\f[R]، لن يثبت
mkosi هذه الوحدات. إذا استُخدمت القيمة \f[CR]runtime\f[R]، فلن يثبت mkosi أي
وحدات أيضًا ولكنه سيجهض بدء \f[CR]mkosi vm\f[R] إذا لم تكن وثائق استيثاق SSH
مهيأة. عند البناء بهذا الخيار وتشغيل الصورة باستخدام \f[CR]mkosi vm\f[R]،
يمكن استخدام أمر \f[CR]mkosi ssh\f[R] للاتصال بالحاوية/الآلة الافتراضية عبر
SSH. لاحظ أنه لا يزال يتعين عليك التأكد من تثبيت openssh في الصورة لكي يعمل
\f[CR]mkosi ssh\f[R] بشكل صحيح. شغّل \f[CR]mkosi genkey\f[R] لتوليد شهادة
X.509 ومفتاح خاص آليًا ليستخدمهما \f[B]mkosi\f[R] لتمكين وصول SSH إلى أي
آلات افتراضية عبر \f[CR]mkosi ssh\f[R]. للوصول إلى الصور التي تم إقلاعها
باستخدام \f[CR]mkosi boot\f[R]، استخدم \f[B]machinectl\f[R].\fR
.PP
بدءًا من الإصدار v256 لـ systemd، سيقوم systemd\-ssh\-generator(8) بتوفير
\f[CR]sshd\f[R] عبر VSock آليًا عند التشغيل داخل آلة افتراضية. لذا إذا كنت
تستخدم إصدارًا حديثًا من systemd داخل آلة افتراضية، فإن هذا الخيار لا
يُستخدم عمومًا. لا تزال بحاجة إلى تثبيت openssh في الصورة، والإعداد المبدئي
لـ \f[CR]\-\-vsock=auto\f[R] كافٍ لضمان توفر VSock داخل الآلة الافتراضية.\fR
.PP
ملاحظة: إذا كانت توزيعة الصورة تستخدم SELinux، سيُمنع وصول خدمة sshd الخاصة
بـ mkosi إلى VSock، مما يؤدي إلى فشل الاتصال بها من المضيف. ستحتاج إما إلى
تعطيل فرض SELinux، أو إنشاء وحدة سياسة مخصصة (على سبيل المثال باستخدام
\f[CR]audit2allow\f[R]).\fR
.RE
.TP 
\f[CR]SELinuxRelabel=\f[R], \f[CR]\-\-selinux\-relabel=\fR
يحدد ما إذا كان سيتم إعادة وسم الملفات لتطابق سياسة SELinux الخاصة
بالصورة. يأخذ قيمة منطقية أو \f[CR]auto\f[R]. القيمة المبدئية هي
\f[CR]auto\f[R]. في حال التعطيل، لن تُعاد وسم الملفات. وفي حال التفعيل، يجب
تثبيت سياسة SELinux في الصورة ويجب أن يكون \f[B]setfiles\f[R] متاحًا لإعادة
وسم الملفات. إذا حدثت أي أخطاء أثناء \f[B]setfiles\f[R]، سيفشل البناء. إذا
ضُبط على \f[CR]auto\f[R]، ستُعاد وسم الملفات إذا لم يكن mkosi يبني صورة
دليل، وكانت سياسة SELinux مثبتة في الصورة وكان \f[B]setfiles\f[R]
متاحًا. سيتم تجاهل أي أخطاء تحدث أثناء \f[B]setfiles\f[R].\fR
.RS
.PP
لاحظ أنه عند التشغيل بدون امتيازات، سيفشل \f[B]setfiles\f[R] في تعيين أي
لصائق ليست في سياسة SELinux الخاصة بالمضيف. لضمان نجاح \f[B]setfiles\f[R]
بدون أخطاء، تأكد من تشغيل \f[B]mkosi\f[R] كجذر (root) أو البناء من نظام مضيف
له نفس سياسة SELinux كالصورة التي تبنيها.\fR
.RE
.TP 
\f[CR]MachineId=\f[R], \f[CR]\-\-machine\-id=\fR
يأخذ UUID أو القيمة الخاصة \f[CR]random\f[R]. يضبط معرف الآلة (machine ID)
للصورة إلى الـ UUID المحدد. إذا ضُبط على \f[CR]random\f[R]، سيُكتب UUID
عشوائي في \f[CR]/etc/machine\-id\f[R]. إذا لم يُحدد صراحةً ووُجد الملف
\f[CR]mkosi.machine\-id\f[R] في الدليل المحلي، يُقرأ الـ UUID المراد استخدامه
منه؛ وإلا سيُكتب \f[CR]uninitialized\f[R] في \f[CR]/etc/machine\-id\f[R].\fR
.SS "قسم [التحقق]"
.TP 
\f[CR]SecureBoot=\f[R], \f[CR]\-\-secure\-boot=\fR
توقيع \f[B]systemd\-boot\f[R] (إذا لم يكن موقعًا بعد) وأي صور نواة موحدة
مولدة لـ UEFI SecureBoot (الإقلاع الآمن).\fR
.TP 
\f[CR]SecureBootAutoEnroll=\f[R], \f[CR]\-\-secure\-boot\-auto\-enroll=\fR
إعداد الإدراج الآلي لمفاتيح الإقلاع الآمن في الآلات الافتراضية كما هو موثق
في \f[B]systemd\-boot\f[R](7) إذا استُخدم \f[CR]SecureBoot=\f[R]. لاحظ أن
\f[B]systemd\-boot\f[R] سيقوم فقط بالإدراج الآلي لمفاتيح الإقلاع الآمن في
الآلات الافتراضية بدءًا من systemd v253. للقيام بالإدراج الآلي على systemd
v252 أو على الأجهزة الحقيقية، اكتب ملف تهيئة \f[B]systemd\-boot\f[R] إلى
\f[CR]/efi/loader/loader.conf\f[R] باستخدام شجرة إضافية تحتوي على
\f[CR]secure\-boot\-enroll force\f[R] أو \f[CR]secure\-boot\-enroll
manual\f[R]. الإدراج الآلي غير مدعوم في إصدارات systemd الأقدم من
v252. القيمة المبدئية هي \f[CR]yes\f[R].\fR
.TP 
\f[CR]SecureBootKey=\f[R], \f[CR]\-\-secure\-boot\-key=\fR
المسار إلى ملف PEM الذي يحتوي على المفتاح السري لتوقيع صورة نواة UEFI إذا
استُخدم \f[CR]SecureBoot=\f[R] وتوقيعات PCR عندما يُستخدم
\f[CR]SignExpectedPcr=\f[R] أيضًا. عندما يُحدد
\f[CR]SecureBootKeySource=\f[R]، يعتمد نوع المدخل على المصدر.\fR
.TP 
\f[CR]SecureBootCertificate=\f[R], \f[CR]\-\-secure\-boot\-certificate=\fR
المسار إلى ملف X.509 الذي يحتوي على الشهادة لصورة نواة UEFI الموقعة، في حال
استخدام \f[CR]SecureBoot=\f[R].\fR
.TP 
\f[CR]SecureBootSignTool=\f[R], \f[CR]\-\-secure\-boot\-sign\-tool=\fR
الأداة المراد استخدامها لتوقيع ثنائيات PE الخاصة بالإقلاع الآمن. يأخذ أحد
القيم: \f[CR]systemd\-sbsign\f[R]، أو \f[CR]sbsign\f[R]، أو
\f[CR]auto\f[R]. القيمة المبدئية هي \f[CR]auto\f[R]. إذا ضُبط على
\f[CR]auto\f[R]، تُستخدم إما \f[B]systemd\-sbsign\f[R] أو \f[B]sbsign\f[R]
إذا توفرتا، مع تفضيل \f[B]systemd\-sbsign\f[R].\fR
.TP 
\f[CR]Verity=\f[R], \f[CR]\-\-verity=\fR
ما إذا كان سيتم فرض أو تعطيل verity لصور الامتداد. يأخذ أحد القيم:
\f[CR]signed\f[R]، أو \f[CR]hash\f[R]، أو \f[CR]defer\f[R]، أو
\f[CR]auto\f[R] أو قيمة منطقية. إذا ضُبط على \f[CR]signed\f[R]، يجب وجود
مفتاح وشهادة verity وسيفشل البناء إذا لم نكتشف أي أقسام verity في صورة القرص
التي أنتجها \f[B]systemd\-repart\f[R]. في حال التعطيل، ستُستبعد أقسام verity
من صور الامتداد التي أنتجها \f[B]systemd\-repart\f[R]. إذا ضُبط على
\f[CR]hash\f[R]، يهيئ \f[B]mkosi\f[R] أداة \f[B]systemd\-repart\f[R] لإنشاء
قسم hash لـ verity، ولكن بدون قسم توقيع. إذا ضُبط على \f[CR]defer\f[R]،
سيُخصص مساحة لقسم توقيع verity ولكن لن يتم ملؤه بعد. إذا ضُبط على
\f[CR]auto\f[R] ووُجد مفتاح وشهادة verity، سيمررهما \f[B]mkosi\f[R] إلى
\f[B]systemd\-repart\f[R] ويتوقع أن تحتوي صورة القرص المولدة على أقسام
verity، لكن البناء لن يفشل إذا لم يُعثر على أقسام verity في صورة القرص التي
أنتجها \f[B]systemd\-repart\f[R].\fR
.RS
.PP
لاحظ أن التعطيل الصريح لتوقيع و/أو hash الخاص بـ verity لم يُنفذ بعد لـ مخرج
القرص (\f[CR]disk\f[R]) ويعمل فقط لصور الامتداد في الوقت الحالي.\fR
.RE
.TP 
\f[CR]VerityKey=\f[R], \f[CR]\-\-verity\-key=\fR
المسار إلى ملف PEM الذي يحتوي على المفتاح السري لتوقيع توقيع verity، إذا
أُضيف قسم توقيع verity باستخدام \f[B]systemd\-repart\f[R]. عندما يُحدد
\f[CR]VerityKeySource=\f[R]، يعتمد نوع المدخل على المصدر.\fR
.TP 
\f[CR]VerityCertificate=\f[R], \f[CR]\-\-verity\-certificate=\fR
المسار إلى ملف X.509 الذي يحتوي على الشهادة لتوقيع توقيع verity، إذا أُضيف
قسم توقيع verity باستخدام \f[B]systemd\-repart\f[R].\fR
.TP 
\f[CR]SignExpectedPcr=\f[R], \f[CR]\-\-sign\-expected\-pcr=\fR
قياس مكونات صورة النواة الموحدة (UKI) باستخدام \f[B]systemd\-measure\f[R]
وتضمين توقيع PCR في صورة النواة الموحدة. يأخذ هذا الخيار قيمة منطقية أو
القيمة الخاصة \f[CR]auto\f[R]، وهي القيمة المبدئية، والتي تعادل قيمة صواب
إذا كان ثنائي \f[B]systemd\-measure\f[R] موجودًا في المسار
\f[CR]PATH\f[R]. يعتمد هذا على تفعيل \f[CR]SecureBoot=\f[R] والمفتاح من
\f[CR]SecureBootKey=\f[R].\fR
.TP 
\f[CR]SignExpectedPcrKey=\f[R], \f[CR]\-\-sign\-expected\-pcr\-key=\fR
المسار إلى ملف PEM الذي يحتوي على المفتاح السري لتوقيع توقيعات PCR
المتوقعة. عندما يُحدد \f[CR]SignExpectedPcrKeySource=\f[R]، يعتمد نوع المدخل
على المصدر.\fR
.TP 
\f[CR]SignExpectedPcrCertificate=\f[R], \f[CR]\-\-sign\-expected\-pcr\-certificate=\fR
المسار إلى ملف X.509 الذي يحتوي على الشهادة لتوقيع توقيعات PCR المتوقعة.
.TP 
\f[CR]SecureBootKeySource=\f[R], \f[CR]\-\-secure\-boot\-key\-source=\f[R], \f[CR]VerityKeySource=\f[R], \f[CR]\-\-verity\-key\-source=\f[R], \f[CR]SignExpectedPcrKeySource=\f[R], \f[CR]\-\-sign\-expected\-key\-source=\fR
مصدر المفتاح الخاص المقابل، لدعم محركات ومزودات OpenSSL، على سبيل المثال
\f[CR]\-\-secure\-boot\-key\-source=engine:pkcs11\f[R] أو
\f[CR]\-\-secure\-boot\-key\-source=provider:pkcs11\f[R].\fR
.TP 
\f[CR]SecureBootCertificateSource=\f[R], \f[CR]\-\-secure\-boot\-certificate\-source=\f[R], \f[CR]VerityCertificateSource=\f[R], \f[CR]\-\-verity\-certificate\-source=\f[R], \f[CR]SignExpectedPcrCertificateSource=\f[R], \f[CR]\-\-sign\-expected\-certificate\-source=\fR
مصدر الشهادة المقابلة، لدعم مزودي OpenSSL، على سبيل المثال
\f[CR]\-\-secure\-boot\-certificate\-source=provider:pkcs11\f[R]. لاحظ أن
المحركات غير مدعومة.\fR
.TP 
\f[CR]Passphrase=\f[R], \f[CR]\-\-passphrase=\fR
تحديد المسار إلى ملف يحتوي على عبارة المرور لاستخدامها في تعمية LUKS. يجب أن
يحتوي الملف على عبارة المرور حرفيًا، وألا ينتهي بمحرف سطر جديد (أي بنفس
التنسيق الذي تتوقعه أدوات \f[B]cryptsetup\f[R] و \f[CR]/etc/crypttab\f[R]
لملفات عبارة المرور). يجب أن يكون للملف وضع وصول 0600 أو أقل.\fR
.RS
.PP
لاحظ أن هذا الإعداد بمفرده لا يفعل أي تعمية. يجب عليك أيضًا إضافة ملف تعريف
قسم واحد أو أكثر إلى \f[CR]mkosi.repart/\f[R] مع \f[CR]Encrypt=key\-file\f[R]
لإضافة أقسام معماة إلى الصورة.\fR
.RE
.TP 
\f[CR]Checksum=\f[R], \f[CR]\-\-checksum=\fR
توليد ملف \f[CR]<output>.SHA256SUMS\f[R] لكافة النتائج المولدة بعد
اكتمال البناء.\fR
.TP 
\f[CR]Sign=\f[R], \f[CR]\-\-sign=\fR
توقيع ملف \f[CR]SHA256SUMS\f[R] المولد باستخدام \f[B]gpg\f[R] بعد
الاكتمال.\fR
.TP 
\f[CR]OpenPGPTool=\f[R], \f[CR]\-\-openpgp\-tool=\fR
تطبيق OpenPGP المراد استخدامه للتوقيع. الأداة \f[CR]gpg\f[R] هي
المبدئية. سيؤدي اختيار قيمة مختلفة عن القيمة المبدئية إلى استخدام أداة
Stateless OpenPGP (SOP) المعطاة لتوقيع ملف \f[CR]SHA256SUMS\f[R].\fR
.RS
.PP
من الأمثلة على الخيارات \f[CR]sqop\f[R] و \f[CR]rsop\f[R]، ولكن أي تطبيق من
https://www.openpgp.org/about/sop/ يمكن تثبيته محليًا سيعمل.\fR
.RE
.TP 
\f[CR]Key=\f[R], \f[CR]\-\-key=\fR
اختر مفتاح \f[B]gpg\f[R] لاستخدامه في توقيع \f[CR]SHA256SUMS\f[R]. يجب أن
يكون هذا المفتاح موجودًا بالفعل في حلقة مفاتيح \f[B]gpg\f[R].\fR
.SS "قسم [البناء]"
.TP 
\f[CR]ToolsTree=\f[R], \f[CR]\-\-tools\-tree=\fR
إذا حُدد، سيُبحث عن البرامج التي يشغلها \f[B]mkosi\f[R] لبناء وإقلاع صورة
داخل الشجرة المعطاة بدلاً من نظام المضيف. استخدم هذا الخيار لجعل عمليات بناء
الصور أكثر قابلية للتكرار عن طريق استخدام نفس إصدارات البرامج دائمًا لبناء
الصورة النهائية بدلاً من أي إصدار مثبت على نظام المضيف. إذا لم يُستخدم هذا
الخيار، ووُجد الدليل \f[CR]mkosi.tools/\f[R] في الدليل المحلي، سيُستخدم
آليًا لهذا الغرض مع اعتبار الدليل الجذر كهدف.\fR
.RS
.PP
يُحتفظ بدليل شجرة الأدوات بين عمليات بناء الصور المتكررة ما لم يُنظف عن طريق
استدعاء \f[CR]mkosi clean \-f\f[R].\fR
.PP
لاحظ أن الثنائيات الموجودة في أي من المسارات المهيأة باستخدام
\f[CR]ExtraSearchPaths=\f[R] ستُنفذ باستخدام \f[CR]/usr/\f[R] من شجرة
الأدوات بدلاً من المضيف. إذا كانت توزيعة أو إصدار المضيف لا يطابق توزيعة أو
إصدار شجرة الأدوات على التوالي، فقد يؤدي ذلك إلى حالات فشل عند محاولة تنفيذ
الثنائيات من أي من مسارات البحث الإضافية.\fR
.PP
إذا ضُبط على \f[CR]yes\f[R]، سيقوم \f[B]mkosi\f[R] آليًا بإضافة صورة شجرة
أدوات إضافية واستخدامها كشجرة أدوات. يمكن تهيئة هذه الصورة بشكل أكبر
باستخدام الإعدادات أدناه أو باستخدام \f[CR]mkosi.tools.conf\f[R] الذي يمكن
أن يكون ملفًا أو دليلاً يحتوي على تهيئة إضافية لشجرة الأدوات المبدئية.\fR
.PP
انظر قسم \f[B]TOOLS TREE\f[R] لمزيد من التفاصيل.\fR
.RE
.TP 
\f[CR]ToolsTreeDistribution=\f[R], \f[CR]\-\-tools\-tree\-distribution=\fR
ضبط التوزيعة المراد استخدامها لشجرة الأدوات المبدئية. القيمة المبدئية هي
توزيعة المضيف باستثناء أوبونتو (Ubuntu)، التي يكون مبدؤها دبيان (Debian)، و
RHEL و CentOS و Alma و Rocky، التي يكون مبدؤها فيدورا (Fedora)، أو
\f[CR]custom\f[R] إذا لم تكن توزيعة المضيف توزيعة مدعومة.\fR
.TP 
\f[CR]ToolsTreeRelease=\f[R], \f[CR]\-\-tools\-tree\-release=\fR
اضبط إصدارة التوزيعة لاستخدامها في شجرة الأدوات المبدئية. مبدئيًا، تُستخدم
الإصدارة المبدئية المضمنة في \f[B]mkosi\f[R] للتوزيعة.\fR
.TP 
\f[CR]ToolsTreeProfiles=\f[R], \f[CR]\-\-tools\-tree\-profile=\fR
اضبط التشكيلات المراد تفعيلها لشجرة الأدوات المبدئية. تأخذ قائمة مفصولة
بفاصلة تتكون من \f[CR]devel\f[R]، و\f[CR]misc\f[R]،
و\f[CR]package\-manager\f[R] و\f[CR]runtime\f[R]. مبدئيًا، تُفعل كل التشكيلات
عدا \f[CR]devel\f[R].\fR
.RS
.PP
تحتوي تشكيلة \f[CR]devel\f[R] على الأدوات المطلوبة لبناء مشاريع
(C/C++). وتحتوي تشكيلة \f[CR]misc\f[R] على أدوات مفيدة متنوعة يسهل توفرها في
البرامج النصية. تحتوي تشكيلة مدير الحزم على مديري الحزم والأدوات المتعلقة
بها بخلاف تلك الأصيلة في توزيعة شجرة الأدوات. تحتوي تشكيلة
\f[CR]runtime\f[R] على الأدوات المطلوبة لإقلاع الصور في حاوية systemd\-nspawn
أو في آلة افتراضية.\fR
.RE
.TP 
\f[CR]ToolsTreeMirror=\f[R], \f[CR]\-\-tools\-tree\-mirror=\fR
اضبط المرآة لاستخدامها في شجرة الأدوات المبدئية. مبدئيًا، تُستخدم المرآة
المبدئية لتوزيعة شجرة الأدوات.
.TP 
\f[CR]ToolsTreeRepositories=\f[R], \f[CR]\-\-tools\-tree\-repository=\fR
نفس \f[CR]Repositories=\f[R] ولكن لشجرة الأدوات المبدئية.\fR
.TP 
\f[CR]ToolsTreeSandboxTrees=\f[R], \f[CR]\-\-tools\-tree\-sandbox\-tree=\fR
نفس \f[CR]SandboxTrees=\f[R] ولكن لشجرة الأدوات المبدئية.\fR
.TP 
\f[CR]ToolsTreePackages=\f[R], \f[CR]\-\-tools\-tree\-package=\fR
حزم إضافية لتثبيتها في شجرة الأدوات المبدئية. تأخذ قائمة مفصولة بفاصلة من
مواصفات الحزم. يمكن استخدام هذا الخيار عدة مرات وفي هذه الحالة تُدمج قوائم
الحزم المحددة.
.TP 
\f[CR]ToolsTreePackageDirectories=\f[R], \f[CR]\-\-tools\-tree\-package\-directory=\fR
نفس \f[CR]PackageDirectories=\f[R]، ولكن لشجرة الأدوات المبدئية.\fR
.TP 
\f[CR]ToolsTreeCertificates=\f[R], \f[CR]\-\-tools\-tree\-certificates=\fR
حدد ما إذا كنت تريد استخدام الشهادات والمفاتيح من شجرة الأدوات. مُفعل
مبدئيًا. في حالة التفعيل، تُستخدم \f[CR]/etc/pki/ca\-trust\f[R]،
و\f[CR]/etc/pki/tls\f[R]، و\f[CR]/etc/ssl\f[R]،
و\f[CR]/etc/ca\-certificates\f[R]، و\f[CR]/var/lib/ca\-certificates\f[R] من
شجرة الأدوات. بخلاف ذلك، تُؤخذ هذه الأدلة من المضيف.\fR
.TP 
\f[CR]ExtraSearchPaths=\f[R], \f[CR]\-\-extra\-search\-path=\fR
قائمة بالمسارات المفصولة بنقطتين للبحث عن الأدوات فيها، قبل استخدام مسار
البحث \f[CR]$PATH\f[R] العادي.\fR
.TP 
\f[CR]Incremental=\f[R], \f[CR]\-\-incremental=\f[R], \f[CR]\-i\fR
يأخذ إما \f[CR]strict\f[R] أو قيمة منطقية كمعامل له. يُفعل وضع البناء
المتزايد. في هذا الوضع، تُنشأ نسخة من صورة نظام التشغيل فور تثبيت جميع حزم
نظام التشغيل وتنفيذ برامج الإعداد النصية ولكن قبل استدعاء برامج
\f[CR]mkosi.build\f[R] النصية (أو أي شيء يحدث بعدها). في الاستدعاءات اللاحقة
لـ \f[B]mkosi\f[R] مع مفتاح \f[CR]\-i\f[R]، قد تُستخدم هذه الصورة المخبوءة في
الخبيئة لتخطي تثبيت حزم نظام التشغيل، مما يسرع أوقات البناء المتكررة بشكل
كبير. لاحظ أنه على الرغم من وجود إبطال بدائي للخبيئة، إلا أنه ليس مثاليًا
بالتأكيد. لإجبار إعادة بناء الصورة المخبوءة، ادمج \f[CR]\-i\f[R] مع
\f[CR]\-ff\f[R] لضمان إزالة الصورة المخبوءة أولاً ثم إعادة إنشائها.\fR
.RS
.PP
إذا ضُبط على \f[CR]strict\f[R]، سيفشل البناء إذا لم تكن الصورة المخبوءة
المبنية مسبقًا موجودة.\fR
.RE
.TP 
\f[CR]CacheOnly=\f[R], \f[CR]\-\-cache\-only=\fR
يأخذ أحد القيم \f[CR]auto\f[R] أو \f[CR]metadata\f[R] أو \f[CR]always\f[R]
أو \f[CR]never\f[R]. القيمة المبدئية هي \f[CR]auto\f[R]. إذا ضُبط على
\f[CR]always\f[R]، يُوجه مدير الحزم بعدم التراسل مع الشبكة. يوفر هذا مستوى
أدنى من قابلية إعادة الإنتاج، طالما أن خبيئة الحزم ممتلئة بالكامل
بالفعل. إذا ضُبط على \f[CR]metadata\f[R]، لا يزال بإمكان مدير الحزم تنزيل
الحزم، لكننا لن نمزامن البيانات الوصفية للمستودع. إذا ضُبط على
\f[CR]auto\f[R]، تُزامن البيانات الوصفية للمستودع ما لم تكن لدينا صورة
مخبوءة (انظر \f[CR]Incremental=\f[R]) ويمكن تنزيل الحزم أثناء البناء. إذا
ضُبط على \f[CR]never\f[R]، تُزامن البيانات الوصفية للمستودع دائمًا ويمكن
تنزيل الحزم أثناء البناء.\fR
.TP 
\f[CR]SandboxTrees=\f[R], \f[CR]\-\-sandbox\-tree=\fR
يأخذ قائمة مفصولة بفاصلة من أزواج مسارات مفصولة بنقطتين. يشير المسار الأول
لكل زوج إلى دليل لنسخه إلى معزل (sandbox) mkosi قبل تنفيذ أداة ما. يشير
المسار الثاني لكل زوج إلى الدليل المستهدف داخل المعزل. إذا لم يُوفر المسار
الثاني، يُنسخ الدليل فوق الدليل الرئيس للمعزل. يُفسر المسار الثاني دائمًا
كمسار مطلق. إذا وُجد دليل \f[CR]mkosi.sandbox/\f[R] في الدليل المحلي،
فسيُستخدم لهذا الغرض مع اعتبار الدليل الرئيس هو الهدف (انظر أيضًا قسم
\f[B]FILES\f[R] أدناه).\fR
.RS
.PP
سيبحث \f[B]mkosi\f[R] عن ضبط مدير الحزم والملفات المتعلقة به في أشجار المعزل
المضبوطة. ما لم يُحدد خلاف ذلك، سيستخدم ملفات الضبط من مواقعها المتعارف
عليها في \f[CR]/usr\f[R] أو \f[CR]/etc\f[R] في أشجار المعزل. على سبيل
المثال، سيبحث عن \f[CR]/etc/dnf/dnf.conf\f[R] في أشجار المعزل إذا وُظف
\f[B]dnf\f[R] لتثبيت الحزم.\fR
.RE
.TP 
\f[CR]WorkspaceDirectory=\f[R], \f[CR]\-\-workspace\-directory=\fR
مسار الدليل المخصص لتخزين البيانات المطلوبة مؤقتًا أثناء بناء الصورة. يجب أن
يتوفر في هذا الدليل مساحة كافية لتخزين صورة نظام التشغيل كاملة، رغم أن
المساحة المستخدمة فعليًا في معظم الأوضاع تكون أصغر. إذا لم يُحدد، يُستخدم
دليل فرعي من \f[CR]$XDG_CACHE_HOME\f[R] (إن وُجد)، أو
\f[CR]$CACHE_DIRECTORY\f[R] (إن وُجد)، أو \f[CR]$HOME/.cache\f[R] (إن وُجد)
أو \f[CR]/var/tmp\f[R].\fR
.RS
.PP
تُزال البيانات الموجودة في هذا الدليل آليًا بعد كل عملية بناء. من الآمن
إزالة محتويات هذا الدليل يدويًا في حالة إيقاف استدعاء \f[B]mkosi\f[R] بشكل
غير طبيعي (على سبيل المثال، بسبب إعادة التشغيل/انقطاع الطاقة).\fR
.RE
.TP 
\f[CR]CacheDirectory=\f[R], \f[CR]\-\-cache\-directory=\fR
يأخذ مسارًا لدليل يُستخدم كدليل خبيئة متزايد للصور المتزايدة المنتجة عند
تفعيل خيار \f[CR]Incremental=\f[R]. إذا لم يُستخدم هذا الخيار، ولكن وُجد
دليل \f[CR]mkosi.cache/\f[R] في الدليل المحلي، فسيُستخدم آليًا لهذا
الغرض.\fR
.TP 
\f[CR]CacheKey=\f[R], \f[CR]\-\-cache\-key=\fR
يحدد الدليل الفرعي داخل دليل الخبيئة حيث تُخزن الصورة المخبوءة. قد يشمل ذلك
كلاً من المحددات العادية (انظر \f[B]Specifiers\f[R]) والمحددات المؤجلة
الخاصة، التي تُوسع بعد انتهاء تحليل الضبط، بدلاً من أثنائه، والموصوفة
أدناه. التنسيق المبدئي لهذا المعامل هو
\f[CR]&d\[ti]&r\[ti]&a\[ti]&I\f[R].\fR
.RS
.PP
يمكن استخدام المحددات التالية:
.PP
.TS
tab(@);
l l.
T{
المحدد
T}@T{
القيمة
T}
_
T{
\f[CR]&&\fR
T}@T{
محرف \f[CR]&\f[R]
T}
T{
\f[CR]&d\fR
T}@T{
\f[CR]Distribution=\fR
T}
T{
\f[CR]&r\fR
T}@T{
\f[CR]Release=\fR
T}
T{
\f[CR]&a\fR
T}@T{
\f[CR]Architecture=\fR
T}
T{
\f[CR]&i\fR
T}@T{
\f[CR]ImageId=\fR
T}
T{
\f[CR]&v\fR
T}@T{
\f[CR]ImageVersion=\fR
T}
T{
\f[CR]&I\fR
T}@T{
\f[R]اسم الصورة الفرعية داخل mkosi.images/ أو \f[CR]main\fR
T}
.TE
.PP
لاحظ أن جميع الصور ضمن البناء يجب أن تمتلك مفتاح خبيئة فريد.
.RE
.TP 
\f[CR]PackageCacheDirectory=\f[R], \f[CR]\-\-package\-cache\-dir=\fR
يأخذ مسارًا لدليل يُستخدم كدليل خبيئة للحزم لمدير حزم التوزيعة المستخدم. إذا
لم يُضبط، ولكن وُجد دليل \f[CR]mkosi.pkgcache/\f[R] في الدليل المحلي،
فسيُستخدم آليًا لهذا الغرض، وإلا سيُستخدم دليل مناسب في دليل المنزل للمستخدم
أو النظام.\fR
.TP 
\f[CR]BuildDirectory=\f[R], \f[CR]\-\-build\-directory=\fR
يأخذ مسارًا لدليل يُستخدم كدليل بناء لأنظمة البناء التي تدعم البناء خارج
الشجرة (مثل Meson). الدليل المستخدم بهذه الطريقة يُشارك بين عمليات البناء
المتكررة، ويسمح لنظام البناء بإعادة استخدام النواتج (مثل ملفات الكائنات،
والملفات التنفيذية، ...) المولدة في الاستدعاءات السابقة. يمكن لبرامج البناء
النصية العثور على مسار هذا الدليل في متغير البيئة
\f[CR]$BUILDDIR\f[R]. يُوصل هذا الدليل في الدليل الرئيس للصورة عند استدعاء
\f[B]mkosi\-chroot\f[R] أثناء تنفيذ برامج البناء النصية. إذا لم يُحدد هذا
الخيار، ولكن وُجد دليل \f[CR]mkosi.builddir/\f[R] في الدليل المحلي،
فسيُستخدم آليًا لهذا الغرض (انظر أيضًا قسم \f[B]FILES\f[R] أدناه).\fR
.TP 
\f[CR]BuildKey=\f[R], \f[CR]\-\-build\-key=\fR
يحدد الدليل الفرعي داخل دليل البناء حيث تُخزن نواتج البناء المتزايد. قد يشمل
ذلك كلاً من المحددات العادية (انظر \f[B]Specifiers\f[R]) والمحددات المؤجلة
الخاصة، التي تُوسع بعد انتهاء تحليل الضبط، بدلاً من أثنائه، وهي نفس المحددات
المؤجلة التي يدعمها \f[CR]CacheKey=\f[R]. التنسيق المبدئي لهذا المعامل هو
\f[CR]&d\[ti]&r\[ti]&a\f[R].\fR
.RS
.PP
لتعطيل استخدام دليل بناء فرعي تمامًا، خصص العلامة \f[CR]\-\f[R] حرفيًا لهذا
الضبط.\fR
.RE
.TP 
\f[CR]UseSubvolumes=\f[R], \f[CR]\-\-use\-subvolumes=\fR
يأخذ قيمة منطقية أو \f[CR]auto\f[R]. يُفعل أو يُعطل استخدام أحجام btrfs
الفرعية لمخرجات شجرة الدليل. في حالة التفعيل، سيُنشئ \f[B]mkosi\f[R] الدليل
الرئيس كحجم btrfs فرعي ويستخدم لقطات حجم btrfs الفرعي حيثما أمكن لنسخ
الأشجار الأساسية أو المخبوءة وهو أسرع بكثير من إجراء نسخ تكراري. إذا فُعل
صراحةً وكان \f[CR]btrfs\f[R] غير مثبت أو تعذر إنشاء أحجام فرعية، يُرفع
خطأ. إذا ضُبط على \f[CR]auto\f[R]، يُتجاهل غياب \f[B]btrfs\f[R] أو الفشل في
إنشاء أحجام فرعية.\fR
.TP 
\f[CR]RepartOffline=\f[R], \f[CR]\-\-repart\-offline=\fR
يحدد ما إذا كان سيتم بناء صور القرص باستخدام أجهزة الحلقة (loopback). مُفعل
مبدئيًا. عند التفعيل، لن يستخدم \f[B]systemd\-repart\f[R] أجهزة الحلقة لبناء
صور القرص. عند التعطيل، سيستخدم \f[B]systemd\-repart\f[R] دائمًا أجهزة الحلقة
لبناء صور القرص.\fR
.RS
.PP
لاحظ أنه عند استخدام \f[CR]RepartOffline=no\f[R]، لا يمكن لـ \f[B]mkosi\f[R]
العمل بدون صلاحيات ويجب إجراء بناء الصورة كمستخدم جذر (root) خارج أي حاويات
ومع توفر أجهزة الحلقة على نظام المضيف.\fR
.PP
يوجد حاليًا سيناريوهان معروفان حيث يجب استخدام
\f[CR]RepartOffline=no\f[R]. الأول هو عند استخدام \f[CR]Subvolumes=\f[R] في
ملف تعريف قسم repart، حيث لا يمكن إنشاء أحجام فرعية بدون استخدام أجهزة
الحلقة. الثاني هو عند إنشاء نظام باستخدام SELinux وقسم رئيس بتنسيق
XFS. نظرًا لأن \f[B]mkfs.xfs\f[R] لا يدعم ملء نظام ملفات XFS بسمات ممتدة،
يجب استخدام أجهزة الحلقة لضمان وصول سمات SELinux الممتدة إلى نظام ملفات XFS
المولد.\fR
.RE
.TP 
\f[CR]History=\f[R], \f[CR]\-\-history=\fR
يأخذ قيمة منطقية. في حالة التفعيل، سيكتب \f[B]mkosi\f[R] الضبط المقدم عبر
واجهة سطر الأوامر لآخر بناء في الدليل الفرعي \f[CR].mkosi\-private\f[R] في
الدليل الذي استُدعي منه. تُعاد استخدام هذه المعاملات طالما لم تُعد بناء
الصورة لتجنب الاضطرار إلى تحديدها مرارًا وتكرارًا.\fR
.RS
.PP
لإعطاء مثال على سبب فائدة ذلك، إذا نفذت \f[CR]mkosi \-O my\-custom\-output\-dir
\-f\f[R] متبوعًا بـ \f[CR]mkosi vm\f[R]، سيفشل \f[B]mkosi\f[R] قائلاً إن
الصورة لم تُبنَ بعد. إذا نفذت \f[CR]mkosi \-O my\-custom\-output\-dir
\-\-history=yes \-f\f[R] متبوعًا بـ \f[CR]mkosi vm\f[R]، فسيقوم بإقلاع الصورة
المبنية في الخطوة السابقة كما هو متوقع.\fR
.RE
.TP 
\f[CR]BuildSources=\f[R], \f[CR]\-\-build\-sources=\fR
يأخذ قائمة مفصولة بفاصلة من أزواج مسارات مفصولة بنقطتين. يشير المسار الأول
لكل زوج إلى دليل لوصله من المضيف. يشير المسار الثاني لكل زوج إلى الدليل حيث
يجب وصل دليل المصدر عند تشغيل البرامج النصية. كل مسار مستهدف يُسبق بـ
\f[CR]/work/src\f[R] وتُرتب جميع مصادر البناء أبجديًا حسب أهدافها قبل الوصل،
بحيث تُوصل مسارات المستوى الأعلى أولاً. إذا لم تُضبط صراحةً، يُوصل دليل
العمل الحالي في \f[CR]/work/src\f[R].\fR
.TP 
\f[CR]BuildSourcesEphemeral=\f[R], \f[CR]\-\-build\-sources\-ephemeral=\fR
يأخذ قيمة منطقية أو القيمة الخاصة \f[CR]buildcache\f[R]. مُعطل مبدئيًا. يضبط
ما إذا كانت التغييرات على أدلة المصدر، ودليل العمل والمضبوطة باستخدام
\f[CR]BuildSources=\f[R]، ستستمر. في حالة التفعيل، ستُصفر جميع أدلة المصدر
إلى حالتها الأصلية في كل مرة بعد تشغيل جميع البرامج النصية من نوع معين
(باستثناء برامج المزامنة النصية).\fR
.RS
.PP
💥💣💥 إذا ضُبط إلى \f[CR]buildcache\f[R] فلن تُهمش الطبقة الفوقية (overlay)
عند تشغيل كراسات البناء، بل تُحفظ في دليل البناء، المضبط عبر
\f[CR]BuildDirectory=\f[R]، وستُستخدم مجددًا في التشغيلات اللاحقة. تظل
الطبقة الفوقية مُهمشة لكل الكراسات الأخرى. يمكن استخدام هذا الخيار لتنفيذ
خبأ متقدم للبناء، لكنه قد يؤدي إلى حالات غير متوقعة لدليل المصدر. عند
استخدام هذا الخيار، يجب ضبط دليل بناء. 💥💣💥\fR
.RE
.TP 
\f[CR]Environment=\f[R], \f[CR]\-\-environment=\fR
يضيف متغيرات إلى البيئة التي يتم تنفيذ مديري الحزم وبرامج الإعداد/البناء/ما
بعد التثبيت/الإنهاء النصية بها. يأخذ قائمة مفصولة بمسافات من تعيينات
المتغيرات أو مجرد أسماء المتغيرات. في الحالة الأخيرة، ستُمرر قيم تلك
المتغيرات من البيئة التي استُدعي فيها \f[B]mkosi\f[R]. قد يُحدد هذا الخيار
أكثر من مرة، وفي هذه الحالة ستُضبط جميع المتغيرات المدرجة. إذا ضُبط نفس
المتغير مرتين، فإن الضبط الأخير يتجاوز السابق.\fR
.TP 
\f[CR]EnvironmentFiles=\f[R], \f[CR]\-\-env\-file=\fR
يأخذ قائمة مفصولة بفاصلة من المسارات إلى ملفات تحتوي على تعريفات متغيرات
البيئة لإضافتها إلى بيئة البرمجة النصية. يستخدم \f[CR]mkosi.env\f[R] إذا
وُجد في الدليل المحلي. تُقرأ المتغيرات أولاً من \f[CR]mkosi.env\f[R] إن
وُجد، ثم من قائمة الملفات المعطاة ثم من ضبط \f[CR]Environment=\f[R].\fR
.TP 
\f[CR]WithTests=\f[R], \f[CR]\-\-with\-tests=\f[R], \f[CR]\-T\fR
إذا ضُبط على خطأ (أو عند استخدام خيار سطر الأوامر)، يُضبط متغير البيئة
\f[CR]$WITH_TESTS\f[R] على \f[CR]0\f[R] عند استدعاء برامج
\f[CR]mkosi.build\f[R] النصية. يُفترض أن يُستخدم هذا بواسطة برامج البناء
النصية لتجاوز أي اختبارات وحدات أو اختبارات تكامل تُشغل عادةً أثناء عملية
بناء المصدر. لاحظ أن هذا الخيار ليس له أي تأثير ما لم تلتزم به برامج بناء
\f[CR]mkosi.build\f[R].\fR
.TP 
\f[CR]WithNetwork=\f[R], \f[CR]\-\-with\-network=\fR
عندما تكون القيمة صوابًا، يُمكّن الاتصال بالشبكة أثناء استدعاء برامج البناء
النصية \f[CR]mkosi.build\f[R]. مبدئيًا، تعمل برامج البناء النصية مع إيقاف
الشبكة. يُمرر متغير البيئة \f[CR]$WITH_NETWORK\f[R] إلى برامج بناء
\f[CR]mkosi.build\f[R] موضحًا ما إذا كان البناء يتم بشبكة أو بدونها.\fR
.TP 
\f[CR]ProxyUrl=\f[R], \f[CR]\-\-proxy\-url=\fR
اضبط وكيلاً لاستخدامه لجميع اتصالات الشبكة الصادرة. تُضبط الأدوات المتنوعة
التي يستدعيها \f[B]mkosi\f[R] والتي يمكن ضبط الوكيل لها لاستخدام هذا
الوكيل. يضبط \f[B]mkosi\f[R] أيضًا متغيرات بيئة معروفة متنوعة لتحديد الوكيل
المراد استخدامه لأي برامج يستدعيها قد تحتاج إلى وصول للإنترنت.\fR
.TP 
\f[CR]ProxyExclude=\f[R], \f[CR]\-\-proxy\-exclude=\fR
اضبط أسماء المضيفين التي يجب ألا تمر طلباتها عبر الوكيل. يأخذ قائمة مفصولة
بفاصلة من أسماء المضيفين.
.TP 
\f[CR]ProxyPeerCertificate=\f[R], \f[CR]\-\-proxy\-peer\-certificate=\fR
اضبط ملفًا يحتوي على شهادات تُستخدم للتحقق من الوكيل. القيمة المبدئية هي
مخزن الشهادات على مستوى النظام.
.RS
.PP
حاليًا، دعم ضبط شهادة نظير الوكيل متاح فقط عند استخدام \f[B]dnf\f[R] أو
\f[B]dnf5\f[R] لبناء الصورة.\fR
.RE
.TP 
\f[CR]ProxyClientCertificate=\f[R], \f[CR]\-\-proxy\-client\-certificate=\fR
اضبط ملفًا يحتوي على الشهادة المستخدمة لاستيثاق العميل مع الوكيل.
.RS
.PP
حاليًا، دعم ضبط شهادة عميل الوكيل متاح فقط عند استخدام \f[B]dnf\f[R] أو
\f[B]dnf5\f[R] لبناء الصورة.\fR
.RE
.TP 
\f[CR]ProxyClientKey=\f[R], \f[CR]\-\-proxy\-client\-key=\fR
اضبط ملفًا يحتوي على المفتاح الخاص المستخدم لاستيثاق العميل مع
الوكيل. المبدئي هو شهادة عميل الوكيل إن وُفرت.
.RS
.PP
حاليًا، دعم ضبط مفتاح عميل الوكيل متاح فقط عند استخدام \f[B]dnf\f[R] أو
\f[B]dnf5\f[R] لبناء الصورة.\fR
.RE
.SS "قسم [Runtime] (المعروف سابقًا بقسم [Host])"
.TP 
\f[CR]NSpawnSettings=\f[R], \f[CR]\-\-settings=\fR
يحدد ملف إعدادات \f[CR].nspawn\f[R] ليستخدمه \f[B]systemd\-nspawn\f[R] في
أفعال \f[CR]boot\f[R] و\f[CR]shell\f[R]، ووضعه بجانب ملف الصورة المولد. هذا
مفيد لضبط بيئة \f[B]systemd\-nspawn\f[R] عند تشغيل الصورة. إذا لم يُستخدم هذا
الضبط ولكن وُجد ملف \f[CR]mkosi.nspawn\f[R] في الدليل المحلي، فسيُستخدم
آليًا لهذا الغرض.\fR
.TP 
\f[CR]VirtualMachineMonitor=\f[R], \f[CR]\-\-vmm=\fR
يضبط مراقب الآلة الافتراضية المراد استخدامه. يأخذ واحدًا من \f[CR]qemu\f[R]
أو \f[CR]vmspawn\f[R]. القيمة المبدئية هي \f[CR]qemu\f[R].\fR
.RS
.PP
عند ضبطه على \f[CR]qemu\f[R]، تُقلع الصورة باستخدام \f[B]qemu\f[R]. يمكن
إقلاع معظم تنسيقات المخرجات في \f[B]qemu\f[R]. أي معاملات تُحدد بعد الفعل
تُلحق باستدعاء \f[B]qemu\f[R] وتُفسر كمعاملات سطر أوامر \f[B]qemu\f[R]
إضافية.\fR
.PP
عند ضبطه على \f[CR]vmspawn\f[R]، يُستخدم \f[B]systemd\-vmspawn\f[R] لإقلاع
الصورة، ويدعم \f[CR]vmspawn\f[R] فقط الصور من نوع القرص والدليل. أي معاملات
تُحدد بعد الفعل تُلحق باستدعاء \f[B]systemd\-vmspawn\f[R] وتُفسر كخيار
vmspawn إضافية ومعاملات سطر أوامر نواة إضافية.\fR
.RE
.TP 
\f[CR]Console=\f[R], \f[CR]\-\-console=\fR
يضبط كيفية إعداد وحدة تحكم الآلة الافتراضية. يأخذ واحدًا من
\f[CR]interactive\f[R] أو \f[CR]read\-only\f[R] أو \f[CR]native\f[R] أو
\f[CR]gui\f[R]. المبدئي هو \f[CR]interactive\f[R]. يوفر
\f[CR]interactive\f[R] واجهة طرفية تفاعلية للآلة
الافتراضية. و\f[CR]read\-only\f[R] مشابه، ولكنه للقراءة فقط بصرامة، أي لا
يقبل أي إدخال من المستخدم. كما يوفر \f[CR]native\f[R] واجهة قائمة على TTY،
ولكنه يستخدم تنفيذ \f[B]qemu\f[R] الأصيل (ما يعني توفر مراقب
\f[B]qemu\f[R]). يُظهر \f[CR]gui\f[R] واجهة المستخدم الرسومية لـ
\f[B]qemu\f[R].\fR
.TP 
\f[CR]CPUs=\f[R], \f[CR]\-\-cpus=\fR
يضبط عدد نوى المعالج لتخصيصها للضيف عند إقلاع آلة افتراضية. المبدئي هو
\f[CR]2\f[R].\fR
.RS
.PP
عند ضبطه على \f[CR]0\f[R]، سيُستخدم عدد المعالجات المتاحة لعملية
\f[B]mkosi\f[R].\fR
.RE
.TP 
\f[CR]RAM=\f[R], \f[CR]\-\-ram=\fR
يضبط مقدار ذاكرة الوصول العشوائي المخصصة للضيف عند إقلاع آلة
افتراضية. المبدئي هو \f[CR]2G\f[R].\fR
.TP 
\f[CR]MaxMem=\f[R], \f[CR]\-\-maxmem=\fR
يضبط أقصى مقدار من الذاكرة يمكن للضيف نشره إجمالاً (ذاكرة الوصول العشوائي +
أجهزة الذاكرة القابلة للتوصيل السريع). المبدئي هو مقدار ذاكرة الوصول
العشوائي المضبوطة.
.TP 
\f[CR]KVM=\f[R], \f[CR]\-\-kvm=\fR
يضبط ما إذا كان يجب استخدام تسريع KVM عند إقلاع آلة افتراضية. يأخذ قيمة
منطقية أو \f[CR]auto\f[R]. المبدئي هو \f[CR]auto\f[R].\fR
.TP 
\f[CR]CXL=\f[R], \f[CR]\-\-cxl=\fR
يضبط ما إذا كانت أجهزة CXL مفعلة لآلة معينة. صالح فقط إذا كانت المعمارية
تدعم cxl. يأخذ قيمة منطقية. المبدئي هو \f[CR]false\f[R].\fR
.TP 
\f[CR]VSock=\f[R], \f[CR]\-\-vsock=\fR
يضبط ما إذا كان سيتم توفير vsock عند إقلاع آلة افتراضية. يأخذ قيمة منطقية أو
\f[CR]auto\f[R]. المبدئي هو \f[CR]auto\f[R].\fR
.TP 
\f[CR]VSockCID=\f[R], \f[CR]\-\-vsock\-cid=\fR
يضبط معرف اتصال vsock لاستخدامه عند إقلاع آلة افتراضية. يأخذ رقمًا في المدى
\f[CR][3, 0xFFFFFFFF)\f[R] أو \f[CR]hash\f[R] أو \f[CR]auto\f[R]. المبدئي هو
\f[CR]auto\f[R]. عند ضبطه على \f[CR]hash\f[R]، سيُشتق معرف الاتصال من المسار
الكامل للصورة. عند ضبطه على \f[CR]auto\f[R]، سيحاول \f[B]mkosi\f[R] العثور
على معرف اتصال حر آليًا. بخلاف ذلك، سيُستخدم الرقم المقدم كما هو.\fR
.TP 
\f[CR]TPM=\f[R], \f[CR]\-\-tpm=\fR
اضبط ما إذا كان سيتم استخدام وحدة نظام منصة موثوقة (TPM) افتراضية عند إقلاع
آلة افتراضية. يأخذ قيمة منطقية أو \f[CR]auto\f[R]. المبدئي هو
\f[CR]auto\f[R].\fR
.TP 
\f[CR]Removable=\f[R], \f[CR]\-\-removable=\fR
يضبط ما إذا كان سيتم إرفاق الصورة كجهاز قابل للإزالة عند إقلاع آلة
افتراضية. يأخذ قيمة منطقية. المبدئي هو \f[CR]no\f[R].\fR
.TP 
\f[CR]Firmware=\f[R], \f[CR]\-\-firmware=\fR
يضبط البرنامج الثابت للآلة الافتراضية المراد استخدامه. يأخذ واحدًا من
\f[CR]uefi\f[R] أو \f[CR]uefi\-secure\-boot\f[R] أو \f[CR]bios\f[R] أو
\f[CR]linux\f[R] أو \f[CR]linux\-noinitrd\f[R] أو \f[CR]auto\f[R]. المبدئي هو
\f[CR]auto\f[R]. عند ضبطه على \f[CR]uefi\f[R]، يُستخدم البرنامج الثابت OVMF
بدون دعم الإقلاع الآمن. عند ضبطه على \f[CR]uefi\-secure\-boot\f[R]، يُستخدم
البرنامج الثابت OVMF مع دعم الإقلاع الآمن. عند ضبطه على \f[CR]bios\f[R]،
يُستخدم برنامج SeaBIOS الثابت المبدئي. عند ضبطه على \f[CR]linux\f[R]،
يُستخدم إقلاع النواة المباشر. انظر خيار \f[CR]Linux=\f[R] لمزيد من التفاصيل
حول أي صورة نواة تُستخدم مع إقلاع النواة المباشر. \f[CR]linux\-noinitrd\f[R]
مطابق لـ \f[CR]linux\f[R] باستثناء عدم استخدام initrd. عند ضبطه على
\f[CR]auto\f[R]، يُستخدم \f[CR]uefi\-secure\-boot\f[R] إن أمكن
و\f[CR]linux\f[R] بخلاف ذلك.\fR
.TP 
\f[CR]FirmwareVariables=\f[R], \f[CR]\-\-firmware\-variables=\fR
يضبط المسار إلى ملف متغيرات البرنامج الثابت للآلة الافتراضية المراد
استخدامه. حاليًا، يُؤخذ هذا الخيار في الاعتبار فقط عند استخدام البرنامج
الثابت \f[CR]uefi\f[R] أو \f[CR]uefi\-secure\-boot\f[R]. إذا لم يُحدد، سيبحث
\f[B]mkosi\f[R] عن ملف المتغيرات المبدئي ويستخدمه بدلاً من ذلك.\fR
.RS
.PP
عند ضبطه على \f[CR]microsoft\f[R]، سيُستخدم ملف متغيرات برنامج ثابت بداخلة
شهادات الإقلاع الآمن من Microsoft مسجلة بالفعل.\fR
.PP
عند ضبطه على \f[CR]microsoft\-mok\f[R]، سيُوسع ملف متغيرات البرنامج الثابت
الذي يحتوي بالفعل على شهادات الإقلاع الآمن من Microsoft بمتغير
\f[CR]MokList\f[R] يحتوي على شهادة الإقلاع الآمن من
\f[CR]SecureBootCertificate=\f[R]. هذا مخصص للاستخدام مع ثنائيات shim
الموقعة من التوزيعة وثنائيات EFI الموقعة محليًا.\fR
.PP
عند ضبطه على \f[CR]custom\f[R]، ستُسجل شهادة الإقلاع الآمن من
\f[CR]SecureBootCertificate=\f[R] في ملف متغيرات البرنامج الثابت المبدئي.\fR
.PP
يمكن استخدام \f[CR]virt\-fw\-vars\f[R] من مشروع
.UR https://gitlab.com/kraxel/virt\-firmware
virt\-firmware
.UE
لتخصيص ملفات
متغيرات OVMF.\fR
.RE
.TP 
\f[CR]Linux=\f[R], \f[CR]\-\-linux=\fR
اضبط صورة النواة لاستخدامها في إقلاع النواة المباشر لـ \f[B]qemu\f[R]. إذا
لم تُحدد، سيستخدم \f[B]mkosi\f[R] النواة المقدمة عبر سطر الأوامر (خيار
\f[CR]\-kernel\f[R]) أو أحدث نواة وُجدت مثبتة في الصورة (أو سيفشل إذا لم
تُثبت أي نواة في الصورة).\fR
.RS
.PP
لاحظ أنه عند استخدام تنسيق المخرجات \f[CR]cpio\f[R]، يُستخدم إقلاع النواة
المباشر بغض النظر عن البرنامج الثابت المضبوط. اعتمادًا على البرنامج الثابت
المضبوط، قد يقوم \f[B]qemu\f[R] بإقلاع النواة بنفسه أو باستخدام البرنامج
الثابت المضبوط.\fR
.PP
قد يشمل هذا الضبط كلاً من المحددات العادية (انظر \f[B]Specifiers\f[R])
والمحددات المؤجلة الخاصة، التي تُوسع بعد انتهاء تحليل الضبط، بدلاً من
أثنائه، والموصوفة أدناه.\fR
.PP
يمكن استخدام المحددات التالية:
.PP
.TS
tab(@);
l l.
T{
المحدد
T}@T{
القيمة
T}
_
T{
\f[CR]&&\fR
T}@T{
محرف \f[CR]&\f[R]
T}
T{
\f[CR]&b\fR
T}@T{
\f[R]دليل البناء النهائي (بما في ذلك الدليل الفرعي)\fR
T}
.TE
.RE
.TP 
\f[CR]Drives=\f[R], \f[CR]\-\-drive=\fR
أضف محرك أقراص. يأخذ سلسلة مفصولة بنقطتين بتنسيق
\f[CR]<id>:<size>[:<directory>[:<options>[:<file\-id>[:<flags>]]]]\f[R].
يحدد \f[CR]id\f[R] المعرف المخصص للمحرك. يمكن استخدام هذا كخاصية
\f[CR]drive=\f[R] في أجهزة \f[B]qemu\f[R] المتنوعة. يحدد \f[CR]size\f[R] حجم
المحرك. يأخذ هذا الحجم بالبايت. بالإضافة إلى ذلك، يمكن استخدام اللواحق
\f[CR]K\f[R] و\f[CR]M\f[R] و\f[CR]G\f[R] لتحديد الحجم بالكيلوبايت
والميجابايت والجيجابايت على التوالي. يحدد \f[CR]directory\f[R] اختياريًا
الدليل الذي سيتم إنشاء الملف الذي يدعم المحرك فيه. إذا لم يُضبط، فسيتم إنشاء
الملف تحت \f[CR]/var/tmp\f[R]. تحدد \f[CR]options\f[R] اختياريًا خصائص
إضافية مفصولة بفاصلة تُمرر حرفيًا إلى خيار \f[CR]\-blockdev\f[R] الخاص بـ
\f[B]qemu\f[R]. يحدد \f[CR]file\-id\f[R] معرف الملف الذي يدعم المحرك. إذا لم
يُضبط، فسيأخذ معرف المحرك مبدئيًا. ستتشارك المحركات التي لها نفس معرف الملف
في الملف الداعم. سيتم تحديد دليل الملف وحجمه من المحرك الأول الذي يحمل معرف
ملف معينًا. تأخذ \f[CR]flags\f[R] قائمة مفصولة بفاصلة من أعلام المحرك التي
تدعم حاليًا \f[CR]persist\f[R] فقط. يحدد \f[CR]persist\f[R] ما إذا كان
المحرك سيستمر عبر استدعاءات \f[B]qemu\f[R]. سيتم إنشاء الملفات التي تدعم
المحركات وفقًا للمخطط
\f[CR]/<directory>/mkosi\-drive\-<machine\-or\-image\-name>\-<file\-id>\f[R].
يمكنك تخطي القيم بضبطها على سلسلة فارغة، فتحديد
\f[CR]myfs:1G::::persist\f[R] مثلاً سينشئ محرك أقراص مستمرًا تحت
\f[CR]/var/tmp/mkosi\-drive\-main\-myfs\f[R].\fR
.RS
.PP
\f[B]مثال على الاستخدام:\fR
.IP
.EX
\f[B][Runtime]\f[R]
Drives=btrfs:10G
       ext4:20G
QemuArgs=\-device nvme,serial=btrfs,drive=btrfs
         \-device nvme,serial=ext4,drive=ext4\fR
.EE
.RE
.TP 
\f[CR]QemuArgs=\fR
قائمة مفصولة بمسافات من المعاملات الإضافية لتمريرها عند استدعاء
\f[B]qemu\f[R].\fR
.TP 
\f[CR]Ephemeral=\f[R], \f[CR]\-\-ephemeral=\fR
عند استخدامه مع أفعال \f[CR]shell\f[R] أو \f[CR]boot\f[R] أو \f[CR]vm\f[R]،
يشغل هذا الخيار الفعل المحدد على لقطة مؤقتة لصورة المخرجات تُزال فور إنهاء
الحاوية. أخذ اللقطة المؤقتة أكثر كفاءة في نظم الملفات التي تدعم الروابط
المرجعية (reflinks) أصلاً (\f[B]btrfs\f[R] أو \f[B]xfs\f[R]) منها في نظم
الملفات التقليدية التي لا تدعمها (ext4).\fR
.TP 
\f[CR]Credentials=\f[R], \f[CR]\-\-credential=\fR
اضبط بيانات الاستيثاق التي سيتم تمريرها إلى \f[B]systemd\-nspawn\f[R] أو
الآلة الافتراضية على التوالي عند استخدام \f[CR]mkosi shell/boot\f[R] أو
\f[CR]mkosi vm\f[R]. يأخذ هذا الخيار قائمة قيم مفصولة بمسافات يمكن أن تكون
إما أزواج مفتاح=قيمة أو مسارات. إذا وُفر مسار، وكان ملفًا، فسيكون اسم بيانات
الاستيثاق هو اسم الملف. إذا كان الملف قابلاً للتنفيذ، فستكون قيمة بيانات
الاستيثاق هي ناتج تنفيذ الملف. بخلاف ذلك، ستكون قيمة بيانات الاستيثاق هي
محتويات الملف. إذا كان المسار دليلاً، يُطبق نفس المنطق على كل ملف في
الدليل.\fR
.RS
.PP
لاحظ أن القيم ستُعامل كمسارات فقط إذا لم تكن تحتوي على الفاصل
(\f[CR]=\f[R]).\fR
.RE
.TP 
\f[CR]KernelCommandLineExtra=\f[R], \f[CR]\-\-kernel\-command\-line\-extra=\fR
اضبط مدخلات سطر أوامر نواة إضافية تُلحق بسطر أوامر النواة في وقت التشغيل عند
إقلاع الصورة. عند الإقلاع في حاوية، تُمرر كمعاملات إضافية إلى systemd. عند
الإقلاع في آلة افتراضية، تُلحق بسطر أوامر النواة عبر سلسلة SMBIOS OEM
المسماة io.systemd.stub.kernel\-cmdline\-extra. لن تُلتقط هذه إلا بواسطة
إصدارات \f[B]systemd\-boot\f[R] و\f[B]systemd\-stub\f[R] الأحدث من أو المساوية
لـ v254.\fR
.TP 
\f[CR]RuntimeTrees=\f[R], \f[CR]\-\-runtime\-tree=\fR
يأخذ زوجًا من المسارات مفصولاً بنقطتين. يشير المسار الأول إلى دليل لوصله في
أي آلة (حاوية أو آلة افتراضية) يبدأها mkosi. يشير المسار الثاني إلى الدليل
المستهدف داخل الآلة. إذا لم يُوفر المسار الثاني، يُوصل الدليل في
\f[CR]/root/src\f[R] في الآلة. إذا كان المسار الثاني نسبيًا، فسيُفسر بالنسبة
إلى \f[CR]/root/src\f[R] في الآلة.\fR
.RS
.PP
لكل دليل موصول، تُطابق معرفات المستخدم (uid) والمجموعة (gid) للمستخدم الذي
يشغل mkosi مع مستخدم الجذر (root) في الآلة. هذا يعني أن جميع الملفات والأدلة
ستظهر كما لو كانت مملوكة للجذر في الآلة، وجميع الملفات والأدلة الجديدة التي
ينشئها الجذر في الآلة في هذه الأدلة سيمتلكها المستخدم الذي يشغل mkosi على
المضيف.
.PP
لاحظ أنه عند استخدام \f[CR]mkosi vm\f[R] مع هذه الميزة، يجب تثبيت إصدارة
systemd v254 أو أحدث في الصورة.\fR
.RE
.TP 
\f[CR]RuntimeSize=\f[R], \f[CR]\-\-runtime\-size=\fR
إذا حُدد، ستُكبر صور القرص إلى الحجم المحدد عند إقلاعها باستخدام \f[CR]mkosi
boot\f[R] أو \f[CR]mkosi vm\f[R]. يأخذ الحجم بالبايت. بالإضافة إلى ذلك، يمكن
استخدام اللواحق \f[CR]K\f[R] و\f[CR]M\f[R] و\f[CR]G\f[R] لتحديد الحجم
بالكيلوبايت والميجابايت والجيجابايت على التوالي.\fR
.TP 
\f[CR]RuntimeNetwork=\f[R]، \f[CR]\-\-runtime\-network=\fR
تقبل إحدى القيم \f[CR]user\f[R]، أو \f[CR]interface\f[R] أو
\f[CR]none\f[R]. القيمة المبدئية هي \f[CR]user\f[R]. تحدد إعدادات الشبكة
التي تُضبط عند إقلاع الصورة. تضبط القيمة \f[CR]user\f[R] شبكة بوضع
المستخدم. أما القيمة \f[CR]interface\f[R] فتضبط اتصال شبكة افتراضي بين
المضيف والصورة. يترجم هذا إلى واجهة veth للأمرين \f[CR]mkosi shell\f[R] و
\f[CR]mkosi boot\f[R]، وواجهة tap للأمرين \f[CR]mkosi vm\f[R] و \f[CR]mkosi
vmspawn\f[R].\fR
.RS
.PP
لاحظ أنه عند استخدام \f[CR]interface\f[R]، فإن \f[B]mkosi\f[R] لا يضبط واجهة
المضيف آلياً. ويُتوقع وجود نسخة حديثة من \f[B]systemd\-networkd\f[R] تعمل على
المضيف لتضبط واجهة المضيف للرابط آلياً.\fR
.RE
.TP 
\f[CR]RuntimeBuildSources=\f[R]، \f[CR]\-\-runtime\-build\-sources=\fR
تُوصَل مصادر البناء المضبوطة عبر \f[CR]BuildSources=\f[R] ودليل البناء (إن
وُجد) في المواقع نفسها داخل \f[CR]/work\f[R] التي وُصلت فيها عند تشغيل نص
البناء البرمجي أثناء استخدام \f[CR]mkosi boot\f[R] أو \f[CR]mkosi
vm\f[R].\fR
.TP 
\f[CR]BindUser=\f[R]، \f[CR]\-\-bind\-user=\fR
ربط دليل المنزل للمستخدم الحالي داخل الحاوية أو الآلة الافتراضية. تقبل قيمة
منطقية. معطلة مبدئياً.
.TP 
\f[CR]UnitProperties=\f[R]، \f[CR]\-\-unit\-property=\fR
اضبط خصائص وحدة systemd لإضافتها إلى نطاقات systemd المخصصة عند استخدام
\f[CR]mkosi boot\f[R] أو \f[CR]mkosi vm\f[R]. تُمرر هذه الخصائص مباشرة إلى
خيارات \f[CR]\-\-property=\f[R] الخاصة بكل من \f[B]systemd\-nspawn\f[R] و
\f[B]systemd\-run\f[R] على التوالي.\fR
.TP 
\f[CR]SshKey=\f[R]، \f[CR]\-\-ssh\-key=\fR
مسار مفتاح X.509 الخاص بتنسيق PEM للاستخدام عند الاتصال بآلة افتراضية شُغلت
باستخدام \f[CR]mkosi vm\f[R] وبُنيت مع تفعيل خيار \f[CR]Ssh=\f[R] (أو مع
تثبيت \f[B]systemd\-ssh\-generator\f[R]) عبر أمر \f[CR]mkosi ssh\f[R]. إذا لم
يُضبط ووجد الملف \f[CR]mkosi.key\f[R] في دليل العمل، فسيُستخدم آلياً لهذا
الغرض. شغل \f[CR]mkosi genkey\f[R] لتوليد مفتاح آلياً في
\f[CR]mkosi.key\f[R].\fR
.TP 
\f[CR]SshCertificate=\f[R], \f[CR]\-\-ssh\-certificate=\fR
مسار شهادة X.509 بتنسيق PEM لتوفيرها بصفتها مفتاح SSH عام في الآلات
الافتراضية المبدؤة بـ \f[CR]mkosi vm\f[R]. إذا لم تُضبط ووُجد الملف
\f[CR]mkosi.crt\f[R] في دليل العمل، فسيُستخدم آليًا لهذا الغرض. شغّل
\f[CR]mkosi genkey\f[R] لتوليد شهادة آليًا في \f[CR]mkosi.crt\f[R].\fR
.TP 
\f[CR]Machine=\f[R], \f[CR]\-\-machine=\fR
حدد اسم الآلة لاستخدامه عند إقلاع الصورة. يمكن استخدامه أيضًا للإشارة إلى
صورة محددة عند الدخول عبر SSH إلى صورة (مثل: \f[CR]mkosi \-\-image=myimage
ssh\f[R]).\fR
.RS
.PP
لاحظ أنه يجب تفعيل \f[CR]Ephemeral=\f[R] لبدء جلسات متعددة من نفس الصورة.\fR
.RE
.TP 
\f[CR]Register=\f[R], \f[CR]\-\-register=\fR
يأخذ قيمة منطقية أو \f[CR]auto\f[R]. يحدد ما إذا كان يجب تسجيل الآلة
الافتراضية/الحاوية مع systemd\-machined. إذا فُعّل، سيفشل mkosi إذا تعذر
تسجيل الآلة الافتراضية/الحاوية مع systemd\-machined. إذا عُطّل، لن يسجل mkosi
الآلة الافتراضية/الحاوية. إذا ضُبط إلى \f[CR]auto\f[R]، سيسجل mkosi الآلة
الافتراضية/الحاوية مع systemd\-machined إذا كان متاحًا. القيمة المبدئية هي
\f[CR]auto\f[R].\fR
.TP 
\f[CR]ForwardJournal=\f[R], \f[CR]\-\-forward\-journal=\fR
حدد المسار الذي يجب توجيه سجلات اليومية (journal) من الحاويات والآلات
الافتراضية إليه. إذا كان للمسار الامتداد \f[CR].journal\f[R]، فسيُفسر على
أنه ملف يجب كتابة اليومية فيه. خلاف ذلك، يُفسر المسار على أنه دليل يجب كتابة
اليومية فيه.\fR
.RS
.PP
لاحظ أن الإصدار v256 من systemd أو أحدث مطلوب في الآلة الافتراضية ليعمل
توجيه السجلات.
.PP
لاحظ أنه إذا أُعطي مسار بامتداد \f[CR].journal\f[R]، فإن حجم اليومية سيكون
محدودًا بـ \f[CR]4G\f[R]. اضبط دليل مخرجات بدلاً من ملف إذا كان عبء العمل
ينتج أكثر من \f[CR]4G\f[R] من بيانات اليومية.\fR
.RE
.TP 
\f[CR]StorageTargetMode=\f[R], \f[CR]\-\-storage\-target\-mode=\fR
يحدد ما إذا كان فعل \f[CR]serve\f[R] سيشغل \f[B]systemd\-storagetm\f[R] لخدمة
صور الأقراص عبر NVME\-TCP. يأخذ قيمة منطقية أو \f[CR]auto\f[R]. إذا فُعّل،
سيُشغل systemd\-storagetm دائمًا وسيفشل mkosi إذا تعذر تشغيله. إذا عُطّل، لن
يُشغل systemd\-storagetm أبدًا. إذا ضُبط إلى \f[CR]auto\f[R]، سيُشغل
systemd\-storagetm إذا كانت صورة القرص قيد البناء، ووُجدت ثنائية
systemd\-storagetm واستُدعي \f[CR]mkosi serve\f[R] بصفة المستخدم الجذر.\fR
.TP 
\f[CR]SysupdateDirectory=\f[R]، \f[CR]\-\-sysupdate\-directory=\fR
مسار لدليل يحتوي على ملفات تعريف النقل لـ systemd\-sysupdate التي تُستخدم
بواسطة \f[CR]mkosi sysupdate\f[R]. إذا وجد الدليل
\f[CR]mkosi.sysupdate/\f[R] في الدليل المحلي، فسيُستخدم لهذا الغرض أيضاً.\fR
.RS
.PP
لاحظ أن \f[CR]mkosi sysupdate\f[R] يستدعي \f[CR]systemd\-sysupdate\f[R] مع
ضبط \f[CR]\-\-transfer\-source=\f[R] على دليل مخرجات \f[B]mkosi\f[R]. للاستفادة
من هذا في ملف تعريف نقل، اضبط \f[CR]PathRelativeTo=explicit\f[R] ليُفسر
إعداد \f[CR]Path=\f[R] لمصدر النقل بالنسبة لدليل مخرجات
\f[B]mkosi\f[R]. عموماً، يكفي ضبط \f[CR]PathRelativeTo=explicit\f[R] و
\f[CR]Path=/\f[R] لمصدر النقل ليُفسر نمط المطابقة بالنسبة لدليل مخرجات
\f[B]mkosi\f[R].\fR
.RE
.SS "قسم [Match]"
.TP 
\f[CR]Profiles=\fR
يطابق التشكيلات المضبوطة.
.TP 
\f[CR]Distribution=\fR
يطابق التوزيعة المضبوطة.
.TP 
\f[CR]Release=\fR
يطابق إصدارة التوزيعة المضبوطة. إذا استُخدم هذا الشرط ولم تُضبط أي توزيعة
صراحة بعد، فتُستخدم توزيعة المضيف وإصدارته.
.TP 
\f[CR]Architecture=\fR
يطابق المعمارية المضبوطة. إذا استُخدم هذا الشرط ولم تُضبط أي معمارية صراحة
بعد، فتُستخدم معمارية المضيف. يمكن استخدام \f[CR]Architecture=uefi\f[R]
لمطابقة أي معمارية تدعم UEFI.\fR
.TP 
\f[CR]Repositories=\fR
يطابق المستودعات المفعّلة باستخدام إعداد \f[CR]Repositories=\f[R]. يقبل اسم
مستودع واحد.\fR
.TP 
\f[CR]PathExists=\fR
يتحقق هذا الشرط إذا كان المسار المعطى موجوداً. تُفسر المسارات النسبية نسبةً
إلى الدليل الأب لملف الضبط الذي قُرئ منه الشرط.
.TP 
\f[CR]ImageId=\fR
يطابق معرف الصورة المضبوط، ويدعم أنماط المطابقة (globs). إذا استُخدم هذا
الشرط ولم يُضبط معرف الصورة صراحة بعد، فسيفشل هذا الشرط.
.TP 
\f[CR]ImageVersion=\fR
يطابق نسخة الصورة المضبوطة. يمكن أن تُسبق نسخ الصور بالعوامل \f[CR]==\f[R]،
أو \f[CR]!=\f[R]، أو \f[CR]>=\f[R]، أو \f[CR]<=\f[R]، أو
\f[CR]<\f[R]، أو \f[CR]>\f[R] لإجراء مقارنات نسخ ثرية وفقاً لمواصفات
تنسيق النسخ لمجموعة UAPI. إذا لم يُسبق بأي عامل، فيُفترض عامل التساوي
مبدئياً. إذا استُخدم هذا الشرط ولم تُضبط نسخة الصورة صراحة بعد، فسيفشل هذا
الشرط.\fR
.TP 
\f[CR]Bootable=\fR
يطابق القيمة المضبوطة لميزة \f[CR]Bootable=\f[R]. يقبل قيمة منطقية أو
\f[CR]auto\f[R].\fR
.TP 
\f[CR]Format=\fR
يطابق القيمة المضبوطة لخيار \f[CR]Format=\f[R]. يقبل تنسيق مخرجات (راجع خيار
\f[CR]Format=\f[R]).\fR
.TP 
\f[CR]SystemdVersion=\fR
يطابق نسخة systemd على المضيف (كما يوردها الأمر \f[CR]systemctl
\-\-version\f[R]). يمكن أن تُسبق القيم بالعوامل \f[CR]==\f[R]، أو
\f[CR]!=\f[R]، أو \f[CR]>=\f[R]، أو \f[CR]<=\f[R]، أو
\f[CR]<\f[R]، أو \f[CR]>\f[R] لإجراء مقارنات نسخ ثرية وفقاً لمواصفات
تنسيق النسخ لمجموعة UAPI. إذا لم يُسبق بأي عامل، فيُفترض عامل التساوي
مبدئياً.\fR
.TP 
\f[CR]BuildSources=\fR
يقبل مساراً لوجهة مصدر البناء (راجع \f[CR]BuildSources=\f[R]). يتحقق هذا
التطابق إذا كان أي من مصادر البناء المضبوطة يستخدم مسار الوجهة هذا. على سبيل
المثال، إذا كان لدينا ملف \f[CR]mkosi.conf\f[R] يحتوي على:\fR
.RS
.IP
.EX
\f[B][Build]\f[R]
BuildSources=../abc/qed:kernel\fR
.EE
.PP
وملف تكميلي (drop\-in) يحتوي على:
.IP
.EX
\f[B][Match]\f[R]
BuildSources=kernel\fR
.EE
.PP
سيُضمن الملف التكميلي.
.PP
تُفسر أي مسارات مطلقة تُمرر لهذا الإعداد نسبةً إلى دليل العمل الحالي.
.RE
.TP 
\f[CR]HostArchitecture=\fR
يطابق المعمارية الأصلية للمضيف. راجع إعداد \f[CR]Architecture=\f[R] للاطلاع
على قائمة بالقيم الممكنة.\fR
.TP 
\f[CR]ToolsTreeDistribution=\fR
يطابق توزيعة شجرة الأدوات المضبوطة.
.TP 
\f[CR]ToolsTreeRelease=\fR
يطابق إصدارة شجرة الأدوات المضبوطة.
.TP 
\f[CR]Environment=\fR
يطابق زوج مفتاح/قيمة معيناً مضبوطاً عبر \f[CR]Environment=\f[R]. إذا لم
تُوفر قيمة، فسيُتحقق مما إذا كان المفتاح المعطى موجوداً في البيئة بغض النظر
عن قيمته.\fR
.TP 
\f[CR]Image=\fR
يطابق اسم الصورة (الفرعية) الحالية. اسم الصورة الفرعية هو اسمها في
\f[CR]mkosi.images/\f[R] (بدون لاحقة \f[CR].conf\f[R]). اسم الصورة من
المستوى الأعلى هو \f[CR]main\f[R]. حالة الاستخدام الرئيسة هي السماح بوجود
إعدادات مشتركة يمكن تضمينها في كل من الصورة الرئيسة والصور الفرعية عبر حصر
الإعدادات العامة خلف مطابقة \f[CR]Image=main\f[R].\fR
.PP
يوضح هذا الجدول أي أدوات المطابقة تدعم أنماط المطابقة (globs)، والمقارنات
الثرية، والقيمة المبدئية التي يُطابق معها إذا لم يُضبط أي قيمة وقت قراءة ملف
الضبط:
.PP
.TS
tab(@);
lw(13.1n) lw(3.5n) lw(9.1n) lw(44.3n).
T{
أداة المطابقة
T}@T{
أنماط المطابقة (Globs)
T}@T{
المقارنات الثرية
T}@T{
المبدئي
T}
_
T{
\f[CR]Profiles=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]تفشل المطابقة\fR
T}
T{
\f[CR]Distribution=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق توزيعة المضيف\fR
T}
T{
\f[CR]Release=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق إصدارة المضيف\fR
T}
T{
\f[CR]Architecture=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق معمارية المضيف\fR
T}
T{
\f[CR]PathExists=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]غير متاح\fR
T}
T{
\f[CR]ImageId=\fR
T}@T{
\f[R]نعم\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]تفشل المطابقة\fR
T}
T{
\f[CR]ImageVersion=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]نعم\fR
T}@T{
\f[R]تفشل المطابقة\fR
T}
T{
\f[CR]Bootable=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق الميزة الآلية\fR
T}
T{
\f[CR]Format=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق التنسيق المبدئي\fR
T}
T{
\f[CR]SystemdVersion=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]نعم\fR
T}@T{
\f[R]غير متاح\fR
T}
T{
\f[CR]BuildSources=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]تفشل المطابقة\fR
T}
T{
\f[CR]HostArchitecture=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]غير متاح\fR
T}
T{
\f[CR]ToolsTreeDistribution=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق توزيعة شجرة أدوات الاحتياط (راجع
\f[CR]ToolsTreeDistribution=\f[R] في \f[CR][Build]\f[R])\fR
T}
T{
\f[CR]ToolsTreeRelease=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]يطابق إصدارة شجرة الأدوات المبدئية\fR
T}
T{
\f[CR]Environment=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]غير متاح\fR
T}
T{
\f[CR]Image=\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]لا\fR
T}@T{
\f[R]غير متاح\fR
T}
.TE
.SS [Include]
.TP 
\f[CR]Include=\f[R]، \f[CR]\-\-include=\f[R]، \f[CR]\-I\fR
تضمين إعدادات إضافية من الملف أو الدليل المعطى. تُضمن الإعدادات الإضافية
مباشرة بعد تحليل الإعداد، إلا عند استخدامها في سطر الأوامر، ففي تلك الحالة
تُضمن الإعدادات الإضافية بعد تحليل جميع وسائط سطر الأوامر.
.RS
.PP
لاحظ أن كل مسار يحتوي على إعدادات إضافية يُحلل مرة واحدة فقط، حتى لو ضُمّن
أكثر من مرة عبر \f[CR]Include=\f[R].\fR
.PP
يمكن تضمين الإعدادات المدمجة لـ initrd المبدئي الخاص بـ \f[B]mkosi\f[R]،
وشجرة الأدوات المبدئية، وصورة الآلة الافتراضية المبدئية، وملحق UKI المبدئي
عبر تضمين القيمة الحرفية \f[CR]mkosi\-initrd\f[R]، أو \f[CR]mkosi\-tools\f[R]،
أو \f[CR]mkosi\-vm\f[R]، أو \f[CR]mkosi\-addon\f[R] على التوالي.\fR
.PP
ملاحظة: أسماء التضمين التي تبدأ بالقيمتين الحرفيتين \f[CR]mkosi\-\f[R] أو
\f[CR]contrib\-\f[R] محجوزة لاستخدام \f[B]mkosi\f[R] نفسه.\fR
.RE
.SS "قسم [Config]"
.TP 
\f[CR]Profiles=\f[R]، \f[CR]\-\-profile=\fR
اختر التشكيلات المعطاة. التشكيلة هي ملف ضبط أو دليل في الدليل
\f[CR]mkosi.profiles/\f[R]. تُضمن ملفات الضبط وأدلة كل تشكيلة بعد تحليل
الضبط التكميلي في \f[CR]mkosi.conf.d/*.conf\f[R].\fR
.TP 
\f[CR]Dependencies=\f[R]، \f[CR]\-\-dependency=\fR
الصور التي تعتمد عليها هذه الصورة، وتُحدد كقائمة مفصولة بفاصلة. جميع الصور
المضبوطة في هذا الخيار ستُبنى قبل هذه الصورة.
.RS
.PP
عند تحديد هذا الإعداد للصورة \[lq]الرئيسة\[rq]، فإنه يحدد الصور الفرعية التي
ينبغي بناؤها. راجع قسم \f[B]BUILDING MULTIPLE IMAGES\f[R] لمزيد من
المعلومات.\fR
.RE
.TP 
\f[CR]MinimumVersion=\f[R]، \f[CR]\-\-minimum\-version=\fR
أدنى إصدارة من \f[B]mkosi\f[R] مطلوبة لبناء هذا الضبط. إذا حُددت عدة مرات،
تُستخدم أعلى إصدارة محددة.\fR
.RS
.PP
يمكن أيضاً تحديد أدنى إصدارة كبصمة إيداع git (hash) عندما تُسبق بـ
\f[CR]commit:\f[R]، وفي هذه الحالة يجب تشغيل mkosi من مستودع git مستخرج،
ويجب أن تكون بصمة إيداع git المحددة سلفاً للإيداع الحالي المستخرج في
المستودع الذي يُشغل mkosi منه.\fR
.RE
.TP 
\f[CR]ConfigureScripts=\f[R]، \f[CR]\-\-configure\-script=\fR
يقبل قائمة مفصولة بفاصلة من المسارات للملفات التنفيذية التي تُستخدم كنصوص
ضبط برمجية لهذه الصورة. راجع قسم \f[B]SCRIPTS\f[R] لمزيد من المعلومات.\fR
.TP 
\f[CR]PassEnvironment=\f[R]، \f[CR]\-\-pass\-environment=\fR
يقبل قائمة بأسماء متغيرات البيئة مفصولة بمسافات. عند بناء صور متعددة، تُمرر
متغيرات البيئة المدرجة إلى كل صورة فرعية على حدة كما لو كانت إعدادات
\[lq]عامة\[rq]. راجع قسم \f[B]BUILDING MULTIPLE IMAGES\f[R] لمزيد من
المعلومات.\fR
.SS "قسم [UKIProfile]"
يمكن استخدام قسم \f[CR]UKIProfile\f[R] في ملفات ضبط تشكيلة UKI التي تُمرر
لإعداد \f[CR]UnifiedKernelImageProfiles=\f[R]. يمكن تحديد الإعدادات التالية
في قسم \f[CR]UKIProfile\f[R]:\fR
.TP 
\f[CR]Profile=\fR
محتويات قسم \f[CR].profile\f[R] لتشكيلة UKI. يقبل قائمة من أزواج المفاتيح
والقيم مفصولة بـ \f[CR]=\f[R]. يجب تحديد المفتاح \f[CR]ID=\f[R]. راجع
مواصفات UKI في
.UR https://uapi\-group.org/specifications/specs/unified_kernel_image/#multi\-profile\-ukis
.UE
\ للحصول على قائمة كاملة بالمفاتيح الممكنة.\fR
.TP 
\f[CR]Cmdline=\fR
خيارات سطر أوامر النواة الإضافية لتشكيلة UKI. يقبل قائمة من وسائط سطر أوامر
النواة الإضافية مفصولة بمسافات. لاحظ أن قسم \f[CR].cmdline\f[R] النهائي
سيكون عبارة عن دمج بين قسم \f[CR].cmdline\f[R] الأساسي ووسائط سطر أوامر
النواة الإضافية المحددة بهذا الإعداد.\fR
.TP 
\f[CR]SignExpectedPcr=\fR
توقيع قياسات PCR المتوقعة لتشكيلة UKI هذه. يقبل قيمة منطقية. مفعّل مبدئياً.
.SS المحددات
يمكن الوصول إلى القيمة الحالية لمختلف الإعدادات عند تحليل ملفات الضبط
باستخدام المحددات. لكتابة حرف \f[CR]%\f[R] حرفياً في ملف الضبط دون معاملته
كمحدد، استخدم \f[CR]%%\f[R]. المحددات التالية مفهومة:\fR
.PP
.TS
tab(@);
l l.
T{
الإعداد
T}@T{
المحدد
T}
_
T{
\f[CR]Distribution=\fR
T}@T{
\f[CR]%d\fR
T}
T{
\f[CR]Release=\fR
T}@T{
\f[CR]%r\fR
T}
T{
\f[CR]Architecture=\fR
T}@T{
\f[CR]%a\fR
T}
T{
\f[CR]Format=\fR
T}@T{
\f[CR]%t\fR
T}
T{
\f[CR]Output=\fR
T}@T{
\f[CR]%o\fR
T}
T{
\f[CR]OutputDirectory=\fR
T}@T{
\f[CR]%O\fR
T}
T{
\f[CR]ImageId=\fR
T}@T{
\f[CR]%i\fR
T}
T{
\f[CR]ImageVersion=\fR
T}@T{
\f[CR]%v\fR
T}
.TE
.PP
توجد أيضاً محددات مستقلة عن الإعدادات:
.PP
.TS
tab(@);
l l.
T{
المحدد
T}@T{
القيمة
T}
_
T{
\f[CR]%C\fR
T}@T{
\f[R]الدليل الأب لملف الضبط الحالي\fR
T}
T{
\f[CR]%P\fR
T}@T{
\f[R]دليل العمل الحالي\fR
T}
T{
\f[CR]%D\fR
T}@T{
\f[R]الدليل الذي استُدعي فيه \f[B]mkosi\f[R]\fR
T}
T{
\f[CR]%I\fR
T}@T{
\f[R]اسم الصورة الفرعية الحالية في \f[CR]mkosi.images\fR
T}
.TE
.PP
أخيراً، هناك محددات مشتقة من أحد الإعدادات:
.PP
.TS
tab(@);
l l.
T{
المحدد
T}@T{
القيمة
T}
_
T{
\f[CR]%F\fR
T}@T{
\f[R]نظام الملفات المبدئي للتوزيعة المضبوطة\fR
T}
.TE
.PP
لاحظ أن دليل العمل الحالي يتغير بينما يحلل \f[B]mkosi\f[R]
إعداداته. تحديداً، في كل مرة يحلل فيها \f[B]mkosi\f[R] دليلاً يحتوي على ملف
\f[CR]mkosi.conf\f[R]، فإنه يغير دليل عمله إلى ذلك الدليل.\fR
.PP
لاحظ أن الدليل الذي استُدعي فيه \f[B]mkosi\f[R] يتأثر بوسيط سطر الأوامر
\f[CR]\-\-directory=\f[R].\fR
.PP
يوضح الجدول التالي أمثلة لقيم محددات الأدلة المدرجة أعلاه:
.PP
.TS
tab(@);
lw(4.7n) lw(13.4n) lw(25.2n) lw(26.7n).
T{
T}@T{
\f[CR]$D/mkosi.conf\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc/abc.conf\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc/mkosi.conf\fR
T}
\f[R]_\fR
T{
\f[CR]%C\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D/mkosi.conf.d\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc\fR
T}
T{
\f[CR]%P\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D/mkosi.conf.d/abc\fR
T}
T{
\f[CR]%D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}@T{
\f[CR]$D\fR
T}
.TE
.SS "التوزيعات المدعومة"
يمكن إنشاء صور تحتوي على تثبيتات للتوزيعات التالية:
.IP \[bu] 2
\f[I]فيدورا لينكس\fR
.IP \f[R]\[bu]\fR 2
\f[I]دبيان\fR
.IP \f[R]\[bu]\fR 2
\f[I]كالي لينكس\fR
.IP \f[R]\[bu]\fR 2
\f[I]أوبونتو\fR
.IP \f[R]\[bu]\fR 2
\f[I]آرتش لينكس\fR
.IP \f[R]\[bu]\fR 2
\f[I]أوبن سوزي\fR
.IP \f[R]\[bu]\fR 2
\f[I]ماجيا\fR
.IP \f[R]\[bu]\fR 2
\f[I]سنت أو إس\fR
.IP \f[R]\[bu]\fR 2
\f[I]RHEL\fR
.IP \f[R]\[bu]\fR 2
\f[I]RHEL UBI\fR
.IP \f[R]\[bu]\fR 2
\f[I]OpenMandriva\fR
.IP \f[R]\[bu]\fR 2
\f[I]Rocky Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Alma Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]Azure Linux\fR
.IP \f[R]\[bu]\fR 2
\f[I]postmarketOS\fR
.IP \f[R]\[bu]\fR 2
\f[I]بلا\f[R] (\f[B]يتطلب من المستخدم توفير نظام ملفات جذر (rootfs) مبني
مسبقًا\f[R])\fR
.PP
نظريًا، يمكن استخدام أي توزيعة على المضيف لبناء صور تحتوي على أي توزيعة
أخرى، طالما أن الأدوات اللازمة متوفرة. تحديدًا، يمكن استخدام أي توزيعة تحزم
\f[B]apt\f[R] لبناء صور \f[I]Debian\f[R] أو \f[I]Kali\f[R] أو
\f[I]Ubuntu\f[R]. ويمكن استخدام أي توزيعة تحزم \f[B]dnf\f[R] لبناء صور لأي
من التوزيعات المعتمدة على RPM. ويمكن لأي توزيعة تحزم \f[B]pacman\f[R] أن
تُستخدم لبناء صور \f[I]Arch Linux\f[R]. وأي توزيعة تحزم \f[B]zypper\f[R]
يمكن استخدامها لبناء صور \f[I]openSUSE\f[R]. أما التوزيعات الأخرى وأدوات
أتمتة البناء للأنظمة المضمنة مثل Buildroot و OpenEmbedded و Yocto Project،
فيمكن استخدامها عبر اختيار التوزيعة \f[CR]custom\f[R]، وملء نظام ملفات الجذر
عبر مزيج من أشجار الأساس، وأشجار الهيكل (skeleton trees)، وسكربتات
التحضير.\fR
.PP
حاليًا، تحزم \f[I]Fedora Linux\f[R] جميع الأدوات ذات الصلة بدءًا من إصدارة
Fedora 28.\fR
.PP
لاحظ أنه عند عدم استخدام مرآة مخصصة، لا يمكن بناء صور \f[CR]RHEL\f[R] إلا من
نظام مضيف يمتلك اشتراك \f[CR]RHEL\f[R] (يُنشأ باستخدام
\f[CR]subscription\-manager\f[R] على سبيل المثال).\fR
.SH "تدفق التنفيذ"
تدفق التنفيذ لـ \f[CR]mkosi build\f[R]. تظهر القيم/الاستدعاءات المبدئية بين
قوسين. عند البناء باستخدام \f[CR]\-\-incremental=yes\f[R]، يُنشئ
\f[B]mkosi\f[R] خبيئة لتثبيت التوزيعة إذا لم تكن موجودة بالفعل، ويستبدل
تثبيت التوزيعة في التشغيلات المتتالية ببيانات من تلك المخبوءة.\fR
.IP \f[R]1.\fR 3
حلل خيارات واجهة سطر الأوامر
.IP 2. 3
حلل ملفات الضبط
.IP 3. 3
شغّل سكربتات الضبط (\f[CR]mkosi.configure\f[R])\fR
.IP \f[R]4.\fR 3
إذا لم نكن نعمل كجذر (root)، فافصل مساحة أسماء المستخدم وارسم نطاق subuid
المضبوط في \f[CR]/etc/subuid\f[R] و \f[CR]/etc/subgid\f[R] داخلها.\fR
.IP \f[R]5.\fR 3
افصل مساحة أسماء الوصل
.IP 6. 3
أعد وصل المجلدات التالية للقراءة فقط إذا كانت موجودة:
.RS 4
.IP \[bu] 2
\f[CR]/usr\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/etc\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/opt\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/srv\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/boot\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/efi\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/media\fR
.IP \f[R]\[bu]\fR 2
\f[CR]/mnt\fR
.RE
.PP
ثم، لكل صورة، ننفذ الخطوات التالية:
.IP " 1." 4
انسخ أشجار المعزل (sandbox) إلى مساحة العمل
.IP " 2." 4
زامن البيانات الوصفية لمستودع مدير الحزم
.IP " 3." 4
شغّل سكربتات المزامنة (\f[CR]mkosi.sync\f[R])\fR
.IP "\f[R] 4.\fR" 4
انسخ أشجار الأساس (\f[CR]\-\-base\-tree=\f[R]) إلى الصورة\fR
.IP "\f[R] 5.\fR" 4
أعد استخدام صورة مخبوءة إذا توفرت
.IP " 6." 4
انسخ لقطة من البيانات الوصفية لمستودع مدير الحزم إلى الصورة
.IP " 7." 4
انسخ أشجار الهيكل (\f[CR]mkosi.skeleton\f[R]) إلى الصورة\fR
.IP "\f[R] 8.\fR" 4
ثبّت التوزيعة والحزم داخل الصورة
.IP " 9." 4
شغّل سكربتات التحضير على الصورة مع المعطى \f[CR]final\f[R]
(\f[CR]mkosi.prepare\f[R])\fR
.IP \f[R]10.\fR 4
ثبّت حزم البناء في الطبقة الفوقية (overlay) إذا ضُبطت أي سكربتات بناء
.IP 11. 4
شغّل سكربتات التحضير على الطبقة الفوقية مع المعطى \f[CR]build\f[R] إذا ضُبطت
أي سكربتات بناء (\f[CR]mkosi.prepare\f[R])\fR
.IP \f[R]12.\fR 4
اخزن الصورة في الخبيئة إذا ضُبط ذلك (\f[CR]\-\-incremental=yes\f[R])\fR
.IP \f[R]13.\fR 4
شغّل سكربتات البناء على الصورة + الطبقة الفوقية إذا ضُبطت أي سكربتات بناء
(\f[CR]mkosi.build\f[R])\fR
.IP \f[R]14.\fR 4
أنهِ البناء إذا ضُبطت صيغة المخرجات على \f[CR]none\f[R]\fR
.IP \f[R]15.\fR 4
انسخ مخرجات سكربتات البناء إلى داخل الصورة
.IP 16. 4
انسخ الأشجار الإضافية إلى داخل الصورة (\f[CR]mkosi.extra\f[R])\fR
.IP \f[R]17.\fR 4
شغّل سكربتات ما بعد التثبيت (\f[CR]mkosi.postinst\f[R])\fR
.IP \f[R]18.\fR 4
اكتب ملفات الضبط المطلوبة لكل من \f[CR]Ssh=\f[R] و \f[CR]Autologin=\f[R] و
\f[CR]MakeInitrd=\fR
.IP \f[R]19.\fR 4
ثبّت systemd\-boot واضبط الإقلاع الآمن إذا ضُبط ذلك
(\f[CR]\-\-secure\-boot=yes\f[R])\fR
.IP \f[R]20.\fR 4
شغّل \f[B]systemd\-sysusers\fR
.IP \f[R]21.\fR 4
شغّل \f[B]systemd\-tmpfiles\fR
.IP \f[R]22.\fR 4
شغّل \f[CR]systemctl preset\-all\fR
.IP \f[R]23.\fR 4
شغّل \f[B]depmod\fR
.IP \f[R]24.\fR 4
شغّل \f[B]systemd\-firstboot\fR
.IP \f[R]25.\fR 4
شغّل \f[B]systemd\-hwdb\fR
.IP \f[R]26.\fR 4
أزل الحزم والملفات (\f[CR]RemovePackages=\f[R]، \f[CR]RemoveFiles=\f[R])\fR
.IP \f[R]27.\fR 4
شغّل إعادة وسم SELinux إذا كانت سياسة SELinux مثبتة
.IP 28. 4
شغّل سكربتات الإنهاء (\f[CR]mkosi.finalize\f[R])\fR
.IP \f[R]29.\fR 4
ولّد صورة نواة موحدة إذا ضُبط ذلك
.IP 30. 4
ولّد صيغة المخرجات النهائية
.IP 31. 4
شغّل سكربتات ما بعد المخرجات (\f[CR]mkosi.postoutput\f[R])\fR
.SH سكربتات
للسماح بتخصيص الصور الذي لا يمكن تنفيذه باستخدام ميزات \f[B]mkosi\f[R]
المدمجة، يدعم \f[B]mkosi\f[R] تشغيل سكربتات في نقاط مختلفة أثناء عملية بناء
الصورة لتخصيصها حسب الحاجة. تُنفذ السكربتات على نظام المضيف كجذر (إما الجذر
الحقيقي أو الجذر داخل مساحة أسماء المستخدم التي أنشأها \f[B]mkosi\f[R] عند
التشغيل بدون امتيازات) مع بيئة مخصصة لتبسيط تعديل الصورة. لكل سكربت، تُوصل
مصادر البناء المضبوطة (\f[CR]BuildSources=\f[R]) داخل مجلد العمل الحالي قبل
تشغيل السكربت فيه. يُضبط \f[CR]$SRCDIR\f[R] ليشير إلى مجلد العمل
الحالي. السكربتات التالية مدعومة:\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.configure\f[R] (\f[CR]ConfigureScripts=\f[R])، فيُنفذ
قبل بناء الصورة. يمكن استخدام هذا السكربت لتعديل الضبط ديناميكيًا. يتلقى
الضبط متسلسلاً بصيغة JSON عبر المدخل القياسي (stdin) ويجب أن يُخرج الضبط
المعدل بصيغة JSON عبر المخرج القياسي (stdout). لاحظ أن هذا السكربت يعمل فقط
عند بناء أو إقلاع الصورة (أفعال \f[CR]build\f[R] و \f[CR]vm\f[R] و
\f[CR]boot\f[R] و \f[CR]shell\f[R]). إذا ضُبطت شجرة أدوات مبدئية، فستُبنى
قبل تشغيل سكربتات الضبط، وستعمل سكربتات الضبط مع توفر شجرة الأدوات. هذا يعني
أيضًا أن التعديلات التي تجريها سكربتات الضبط لن تكون مرئية في مخرجات الملخص
\f[CR]summary\f[R].\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.sync\f[R] (\f[CR]SyncScripts=\f[R])، فيُنفذ قبل بناء
الصورة. يمكن استخدام هذا السكربت لتحديث المصادر المختلفة المستخدمة لبناء
الصورة. إحدى حالات الاستخدام هي تشغيل \f[CR]git pull\f[R] على مستودعات
المصادر المختلفة قبل بناء الصورة. تحديدًا، لا ينطبق إعداد
\f[CR]BuildSourcesEphemeral=\f[R] على سكربتات المزامنة، مما يعني إمكانية
استخدامها لتحديث مصادر البناء حتى لو كان هذا الإعداد مفعلاً.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.prepare\f[R] (\f[CR]PrepareScripts=\f[R])، فيُستدعى
أولاً مع المعطى \f[CR]final\f[R] فور تثبيت حزم البرمجيات. ثم يُستدعى مرة
ثانية مع بارامتر سطر الأوامر \f[CR]build\f[R] فور تثبيت حزم البناء ووصل طبقة
البناء الفوقية أعلى مجلد جذر الصورة. يمتلك هذا السكربت صلاحية الوصول إلى
الشبكة ويمكن استخدامه لتثبيت حزم من مصادر أخرى غير مدير حزم التوزيعة (مثل
\f[B]pip\f[R]، \f[B]npm\f[R]، ...)، بعد تثبيت جميع حزم البرمجيات وقبل وضع
الصورة في الخبيئة (إذا كان الوضع التزايدي مفعلاً). وعلى عكس التثبيت عام
الأغراض، من الآمن تثبيت الحزم على النظام (\f[CR]pip install\f[R]، \f[CR]npm
install \-g\f[R]) بدلاً من \f[CR]$SRCDIR\f[R] نفسه لأن صورة البناء تُستخدم
لمشروع واحد فقط ويمكن التخلص منها وإعادة بنائها بسهولة، فلا خطر من تعارض
الاعتماديات ولا خطر من تلويث نظام المضيف.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.build\f[R] (\f[CR]BuildScripts=\f[R])، فيُنفذ بينما
طبقة البناء الفوقية موصولة أعلى مجلد جذر الصورة. عند تشغيل سكربت البناء،
يشير \f[CR]$DESTDIR\f[R] إلى مجلد يجب على السكربت أن يضع فيه أي ملفات مولدة
يرغب في أن تنتهي داخل الصورة. لاحظ أن أنظمة البناء المعتمدة على
\f[B]make\f[R] و \f[B]automake\f[R] و \f[B]meson\f[R] تحترم عادةً
\f[CR]$DESTDIR\f[R]، مما يجعل بناء أشجار \f[I]المصدر\f[R] من سكربت البناء
أمرًا طبيعيًا جدًا. بعد تشغيل سكربت البناء، تُنسخ محتويات
\f[CR]$DESTDIR\f[R] إلى الصورة.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.postinst\f[R] (\f[CR]PostInstallationScripts=\f[R])،
فيُنفذ بعد تثبيت شجرة البناء (الاختيارية) والأشجار الإضافية. يمكن استخدام
هذا السكربت لتغيير الصور دون أي قيود، بعد تثبيت جميع حزم البرمجيات والمصادر
المبنية.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.finalize\f[R] (\f[CR]FinalizeScripts=\f[R])، فيُنفذ
كآخر خطوة في تحضير الصورة.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.postoutput\f[R] (\f[CR]PostOutputScripts=\f[R])، فيُنفذ
فور توليد جميع ملفات المخرجات، وقبل نقلها نهائيًا إلى مجلد المخرجات. يمكن
استخدامه لتوليد مخرجات إضافية أو بديلة، مثل \f[CR]SHA256FILES\f[R] أو بيان
SBOM.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.clean\f[R] (\f[CR]CleanScripts=\f[R])، فيُنفذ فور تنظيف
مخرجات عملية بناء سابقة. يمكن لسكربت التنظيف تنظيف أي مخرجات لا يعرفها
\f[B]mkosi\f[R] (مثل النواتج من \f[CR]SplitArtifacts=partitions\f[R] أو حزم
RPM المبنية في سكربت بناء). لاحظ أن هذا السكربت لا يستخدم شجرة الأدوات حتى
لو كانت مضبوطة.\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.version\f[R] وكان قابلاً للتنفيذ، فيُشغل أثناء تحليل
الضبط ويملأ \f[CR]ImageVersion=\f[R] بالمخرجات الظاهرة على المخرج
القياسي. يمكن استخدامه لتتبع الإصدارات خارجيًا، مثلاً عبر \f[CR]git
describe\f[R] أو \f[CR]date \[aq]+%Y\-%m\-%d\[aq]\f[R]. لاحظ أن هذا السكربت
يُنفذ على نظام المضيف دون أي عزل (sandboxing).\fR
.IP \f[R]\[bu]\fR 2
إذا وُجد \f[CB]mkosi.rootpw\f[R] وكان قابلاً للتنفيذ، فيُشغل أثناء تحليل
الضبط ويملأ \f[CR]RootPassword=\f[R] بالمخرجات الظاهرة على المخرج
القياسي. يمكن استخدامه لتوليد كلمة سر عشوائية ويمكن تذكرها عبر إخراجها إلى
الخطأ القياسي (stderr) أو عبر قراءة \f[CR]$MKOSI_CONFIG\f[R] في سكربت آخر
(مثلاً \f[CR]mkosi.postoutput\f[R]). لاحظ أن هذا السكربت يُنفذ على نظام
المضيف دون أي عزل.\fR
.PP
إذا استخدم السكربت الملحق \f[CR].chroot\f[R]، فسيقوم \f[B]mkosi\f[R] بتغيير
الجذر (chroot) إلى داخل الصورة باستخدام \f[B]mkosi\-chroot\f[R] (انظر أدناه)
قبل تنفيذ السكربت. على سبيل المثال، إذا وُجد
\f[CR]mkosi.postinst.chroot\f[R]، فسيغير \f[B]mkosi\f[R] الجذر إلى الصورة
وينفذه كسكربت ما بعد التثبيت.\fR
.PP
بدلاً من سكربت بملف واحد، سيقرأ \f[B]mkosi\f[R] أيضًا جميع الملفات بترتيب
معجمي من مجلدات تنتهي بـ \f[CR].d\f[R] ذات أسماء مناسبة، فمثلاً تُستخدم جميع
الملفات في \f[CR]mkosi.build.d\f[R] كسكربتات بناء. هذا مدعوم في:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.sync.d\f[R]،\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.prepare.d\f[R]،\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.build.d\f[R]،\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.postinst.d\f[R]،\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.finalize.d\f[R]،\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.postoutput.d\f[R]، و\fR
.IP \f[R]\[bu]\fR 2
\f[CR]mkosi.clean.d\f[R].\fR
.PP
يمكن دمج ذلك مع ملحق \f[CR].chroot\f[R]، فمثلاً سيعمل
\f[CR]mkosi.build.d/01\-foo.sh\f[R] دون تغيير الجذر إلى داخل الصورة، وسيعمل
\f[CR]mkosi.build.d/02\-bar.sh.chroot\f[R] بعد تغيير الجذر إلى داخلها
أولاً.\fR
.PP
تتلقى السكربتات التي ينفذها \f[B]mkosi\f[R] متغيرات البيئة التالية:\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$ARCHITECTURE\f[R] على المعمارية من إعداد
\f[CR]Architecture=\f[R]. إذا لم يُضبط، فسيحتوي على المعمارية الأصلية لجهاز
المضيف. راجع وثائق \f[CR]Architecture=\f[R] للقيم الممكنة لهذا المتغير.\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$QEMU_ARCHITECTURE\f[R] على المعمارية من
\f[CR]$ARCHITECTURE\f[R] بالصيغة التي يستخدمها \f[B]qemu\f[R]. يفيد ذلك في
العثور على ملف qemu الثنائي (\f[CR]qemu\-system\-$QEMU_ARCHITECTURE\f[R]).\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$EFI_ARCHITECTURE\f[R] على المعمارية من \f[CR]$ARCHITECTURE\f[R]
بالصيغة التي يستخدمها \f[B]UEFI\f[R]. يكون غير مضبوط في المعماريات التي لا
تدعم \f[B]UEFI\f[R].\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$DISTRIBUTION\f[R] على التوزيعة من إعداد
\f[CR]Distribution=\f[R].\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$RELEASE\f[R] على الإصدارة من إعداد \f[CR]Release=\f[R].\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$DISTRIBUTION_ARCHITECTURE\f[R] على المعمارية من
\f[CR]$ARCHITECTURE\f[R] بالصيغة التي تستخدمها التوزيعة المضبوطة.\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$PROFILES\f[R] على التشكيلات من إعداد \f[CR]Profiles=\f[R]
كسلسلة نصية مفصولة بفاصلات.\fR
.IP \f[R]\[bu]\fR 2
يُضبط \f[CR]$CACHED\f[R] على \f[CR]1\f[R] إذا توفرت صورة مخبوءة، وإلا فيُضبط
على \f[CR]0\f[R].\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$CHROOT_SCRIPT\f[R] على المسار إلى السكربت الذي يعمل حاليًا
نسبةً إلى مجلد جذر الصورة. حالة الاستخدام الرئيسة لهذا المتغير هي بالاقتران
مع سكربت \f[B]mkosi\-chroot\f[R]. انظر وصف \f[B]mkosi\-chroot\f[R] أدناه لمزيد
من المعلومات.\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$SRCDIR\f[R] على المسار إلى المجلد الذي استُدعي منه
\f[B]mkosi\f[R]، مع وصل أي مصادر بناء مضبوطة أعلاه. يحتوي
\f[CR]$CHROOT_SRCDIR\f[R] على القيمة التي سيمتلكها \f[CR]$SRCDIR\f[R] بعد
استدعاء \f[B]mkosi\-chroot\f[R].\fR
.IP \f[R]\[bu]\fR 2
يُعرف \f[CR]$BUILDDIR\f[R] فقط إذا وُجد \f[CR]mkosi.builddir\f[R] وكان يشير
إلى مجلد البناء المراد استخدامه. يفيد ذلك جميع أنظمة البناء التي تدعم البناء
خارج شجرة المصدر لإعادة استخدام النواتج المبنية بالفعل من تشغيلات
سابقة. يحتوي \f[CR]$CHROOT_BUILDDIR\f[R] على القيمة التي سيمتلكها
\f[CR]$BUILDDIR\f[R] بعد استدعاء \f[B]mkosi\-chroot\f[R].\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$DESTDIR\f[R] هو مجلد يمكن وضع أي برمجيات مثبتة ومولدة بواسطة سكربت
بناء فيه. يُضبط هذا المتغير فقط عند تنفيذ سكربت بناء. يحتوي
\f[CR]$CHROOT_DESTDIR\f[R] على القيمة التي سيمتلكها \f[CR]$DESTDIR\f[R] بعد
استدعاء \f[B]mkosi\-chroot\f[R].\fR
.IP \f[R]\[bu]\fR 2
يشير \f[CR]$OUTPUTDIR\f[R] إلى مجلد التحضير المستخدم لتخزين نواتج البناء
المولدة أثناء العملية. يحتوي \f[CR]$CHROOT_OUTPUTDIR\f[R] على القيمة التي
سيمتلكها \f[CR]$OUTPUTDIR\f[R] بعد استدعاء \f[B]mkosi\-chroot\f[R].\fR
.IP \f[R]\[bu]\fR 2
يشير \f[CR]$PACKAGEDIR\f[R] إلى المجلد الذي يحتوي على مستودع الحزم
المحلي. يمكن لسكربتات البناء إضافة مزيد من الحزم للمستودع المحلي عبر كتابة
الحزم في \f[CR]$PACKAGEDIR\f[R].\fR
.IP \f[R]\[bu]\fR 2
يشير \f[CR]$ARTIFACTDIR\f[R] إلى المجلد المستخدم لتداول نواتج البناء المولدة
أثناء العملية وجعلها متاحة لاستخدام mkosi. هذا يشبه \f[CR]PACKAGEDIR\f[R]،
ولكنه مخصص للنواتج التي قد لا تكون حزمًا يفهمها مدير الحزم، مثل ملفات initrd
المنشأة بمولدات أخرى غير mkosi. يمكن لسكربتات البناء إضافة مزيد من النواتج
إلى المجلد بوضعها في \f[CR]$ARTIFACTDIR\f[R]. الملفات في هذا المجلد متاحة
فقط للبناء الحالي ولا تُنسخ للخارج مثل محتويات \f[CR]$OUTPUTDIR\f[R].\fR
.RS 2
.PP
سيستخدم \f[B]mkosi\f[R] أيضًا مجلدات فرعية معينة من مجلد النواتج لاستخدام
محتوياتها آليًا في خطوات معينة. حاليًا، يُستخدم المجلدان الفرعيان التاليان
في مجلد النواتج بواسطة mkosi:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]io.mkosi.microcode\f[R]: تُستخدم جميع الملفات في هذا المجلد كملفات كود
دقيق (microcode)، أي أنها تُلحق ببدابة ملفات initrd بترتيب معجمي.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]io.mkosi.initrd\f[R]: تُستخدم جميع الملفات في هذا المجلد كملفات initrd
وتُضم معًا بترتيب معجمي.\fR
.PP
يُنصح مستخدمو \f[CR]$ARTIFACTDIR\f[R] بوضع الأشياء الخاصة بهم في مجلد ذو
مساحة أسماء مشابهة، مثلاً \f[CR]local.my.namespace\f[R].\fR
.RE
.IP \f[R]\[bu]\fR 2
\f[CR]$BUILDROOT\f[R] هو المجلد الجذر للصورة التي تُبنى، مع إمكانية وصل طبقة
البناء الفوقية أعلاه حسب السكربت الذي يُنفذ.\fR
.IP \f[R]\[bu]\fR 2
يكون \f[CR]$WITH_DOCS\f[R] إما \f[CR]0\f[R] أو \f[CR]1\f[R] اعتمادًا على ما
إذا كان قد طُلب البناء مع تثبيت الوثائق أو بدونها
(\f[CR]WithDocs=yes\f[R]). يجب على سكربت البناء كبت تثبيت أي وثائق للحزم في
\f[CR]$DESTDIR\f[R] في حال ضُبط \f[CR]$WITH_DOCS\f[R] على \f[CR]0\f[R].\fR
.IP \f[R]\[bu]\fR 2
يكون \f[CR]$WITH_TESTS\f[R] إما \f[CR]0\f[R] أو \f[CR]1\f[R] اعتمادًا على ما
إذا كان قد طُلب البناء مع تشغيل طقم الاختبارات أو بدونه
(\f[CR]WithTests=no\f[R]). يجب على سكربت البناء تجنب تشغيل أي اختبارات وحدة
أو تكامل في حال ضُبط \f[CR]$WITH_TESTS\f[R] على \f[CR]0\f[R].\fR
.IP \f[R]\[bu]\fR 2
يكون \f[CR]$WITH_NETWORK\f[R] إما \f[CR]0\f[R] أو \f[CR]1\f[R] اعتمادًا على
ما إذا كان البناء يُنفذ مع شبكة أو بدونها (\f[CR]WithNetwork=no\f[R]). يجب
على سكربت البناء تجنب أي اتصال بالشبكة في حال ضُبط \f[CR]$WITH_NETWORK\f[R]
على \f[CR]0\f[R].\fR
.IP \f[R]\[bu]\fR 2
يُعرف \f[CR]$SOURCE_DATE_EPOCH\f[R] إذا طُلب ذلك
(\f[CR]SourceDateEpoch=TIMESTAMP\f[R] أو
\f[CR]Environment=SOURCE_DATE_EPOCH=TIMESTAMP\f[R] أو متغير بيئة المضيف
\f[CR]$SOURCE_DATE_EPOCH\f[R]). يفيد هذا في جعل عمليات البناء قابلة لإعادة
الإنتاج. انظر
.UR https://reproducible\-builds.org/specs/source\-date\-epoch/
SOURCE_DATE_EPOCH
.UE
لمزيد من المعلومات.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$MKOSI_UID\f[R] و \f[CR]$MKOSI_GID\f[R] هما على التوالي معرف المستخدم
ومعرف المجموعة للمستخدم الذي استدعى mkosi.\fR
.IP \f[R]\[bu]\fR 2
\f[CR]$MKOSI_CONFIG\f[R] هو ملف يحتوي على ملخص بصيغة json لإعدادات الصورة
الحالية. يمكن تحليل هذا الملف داخل السكربتات للوصول إلى جميع إعدادات الصورة
الحالية.\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$IMAGE_ID\f[R] على المعرف من إعداد \f[CR]ImageId=\f[R] أو خيار
\f[CR]\-\-image\-id=\f[R].\fR
.IP \f[R]\[bu]\fR 2
يحتوي \f[CR]$IMAGE_VERSION\f[R] على الإصدارة من إعداد
\f[CR]ImageVersion=\f[R] أو خيار \f[CR]\-\-image\-version=\f[R].\fR
.IP \f[R]\[bu]\fR 2
يكون \f[CR]$MKOSI_DEBUG\f[R] إما \f[CR]0\f[R] أو \f[CR]1\f[R] اعتمادًا على
ما إذا كانت مخرجات التنقيح مفعلة.\fR
.PP
راجع هذا الجدول لمعرفة أي السكربتات تتلقى أي متغيرات بيئة:
.PP
.TS
tab(@);
lw(17.4n) cw(7.8n) cw(4.8n) cw(6.6n) cw(5.4n) cw(7.2n) cw(7.2n) cw(8.4n) cw(5.4n).
T{
المتغير
T}@T{
\f[CR]اضبط\fR
T}@T{
\f[CR]مزامنة\fR
T}@T{
\f[CR]تحضير\fR
T}@T{
\f[CR]build\fR
T}@T{
\f[CR]postinst\fR
T}@T{
\f[CR]إنهاء\fR
T}@T{
\f[CR]postoutput\fR
T}@T{
\f[CR]clean\fR
T}
\f[R]_\fR
T{
\f[CR]البنية\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ARTIFACTDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]BUILDDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]BUILDROOT\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]مخبوء\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_BUILDDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_DESTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_OUTPUTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_SCRIPT\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]CHROOT_SRCDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]MKOSI_DEBUG\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]DESTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]التوزيعة\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]بنية_التوزيعة\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]بنية_EFI\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]معرف_الصورة\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]إصدار_الصورة\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_CONFIG\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_GID\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]MKOSI_UID\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]OUTPUTDIR\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]PACKAGEDIR\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]تشكيلات\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]بنية_QEMU\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]الإصدارة\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]SOURCE_DATE_EPOCH\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]SRCDIR\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]مع_التوثيقات\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]مع_الشبكة\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]مع_الاختبارات\fR
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
.TE
.PP
بالإضافة إلى ذلك، عند تنفيذ أي سكايب، تُوفر بضعة سكريبتات عبر
\f[CR]$PATH\f[R] لتبسيط حالات الاستخدام الشائعة.\fR
.IP \f[R]\[bu]\fR 2
\f[B]mkosi\-chroot\f[R]: سيقوم هذا السكريبت بتغيير الجذر (chroot) إلى داخل
الصورة وتنفيذ الأمر المعطى. وبالإضافة إلى تغيير الجذر، سيقوم أيضاً بوصل
(mount) ملفات وأدلة متنوعة (\f[CR]$SRCDIR\f[R]، و\f[CR]$DESTDIR\f[R]،
و\f[CR]$BUILDDIR\f[R]، و\f[CR]$OUTPUTDIR\f[R]، و\f[CR]$CHROOT_SCRIPT\f[R])
داخل الصورة وتعديل متغيرات البيئة المقابلة لتشير إلى المواقع داخل
الصورة. كما سيقوم بوصل أنظمة ملفات APIVFS (\f[CR]/proc\f[R]،
و\f[CR]/dev\f[R]، و\&...) للتأكد من أن السكريبتات والأدوات المنفذة داخل بيئة
chroot تعمل بشكل سليم. كما ينقل \f[CR]/etc/resolv.conf\f[R] من المضيف إلى
داخل بيئة chroot إذا طُلب ذلك لضمان عمل دقة أسماء النطاقات (DNS). بعد خروج
أمر mkosi\-chroot، تُنظف نقاط الوصل المختلفة.\fR
.RS 2
.PP
على سبيل المثال، لاستدعاء \f[B]ls\f[R] داخل الصورة، استخدم ما يلي:\fR
.IP
.EX
mkosi\-chroot ls ...
.EE
.PP
لتنفيذ السكريبت بالكامل داخل الصورة، أضف اللاحقة \f[CR].chroot\f[R] إلى
الاسم (\f[CR]mkosi.build.chroot\f[R] بدلاً من \f[CR]mkosi.build\f[R]، وما
إلى ذلك).\fR
.RE
.IP \f[R]\[bu]\fR 2
بالنسبة لجميع مديري الحزم المدعومين (\f[B]dnf\f[R]، و\f[B]rpm\f[R]،
و\f[B]apt\f[R]، و\f[B]dpkg\f[R]، و\f[B]pacman\f[R]، و\f[B]zypper\f[R])، توضع
سكريبتات بنفس الاسم في \f[CR]$PATH\f[R] تضمن عمل هذه الأوامر على الدليل
الجذر للصورة مع الإعدادات التي قدمها المستخدم بدلاً من العمل على نظام
المضيف. هذا يعني أنه من داخل سكريبت، يمكنك تنفيذ \f[CR]dnf install vim\f[R]
مثلاً لتثبيت vim داخل الصورة.\fR
.RS 2
.PP
بالإضافة إلى ذلك، ستقوم أوامر \f[CR]mkosi\-install\f[R]،
و\f[CR]mkosi\-reinstall\f[R]، و\f[CR]mkosi\-upgrade\f[R]،
و\f[CR]mkosi\-remove\f[R] باستدعاء العملية المقابلة لمدير الحزم المستخدم
لبناء الصورة.\fR
.RE
.IP \f[R]\[bu]\fR 2
يُستدعى \f[B]git\f[R] آلياً مع الخيار \f[CR]safe.directory=*\f[R] لتجنب
أخطاء الأذونات عند التشغيل كالمستخدم الجذر (root) في فضاء أسماء مستخدم.\fR
.IP \f[R]\[bu]\fR 2
يُستدعى \f[B]useradd\f[R] و\f[B]groupadd\f[R] آلياً مع الخيار
\f[CR]\-\-root=$BUILDROOT\f[R] عند التنفيذ خارج الصورة.\fR
.PP
عند تنفيذ السكريبتات، تُجعل أي أدلة لا تزال قابلة للكتابة للقراءة فقط
(\f[CR]/home\f[R]، و\f[CR]/var\f[R]، و\f[CR]/root\f[R]، و\&...) وتبقى فقط
المجموعة الدنيا من الأدلة التي تحتاج للكتابة قابلة للكتابة. يتم ذلك لضمان
عدم عبث السكريبتات بنظام المضيف عندما يعمل \f[B]mkosi\f[R] بصلاحيات
الجذر.\fR
.PP
لاحظ أنه عند تنفيذ السكريبتات، تُجعل جميع أدلة المصدر زائلة، مما يعني أن
جميع التغييرات التي أُجريت على أدلة المصدر أثناء تشغيل السكريبتات تُهمل بعد
انتهاء تنفيذها. استخدم أدلة المخرجات أو البناء أو الخبيئة إذا كنت بحاجة
لاستمرار البيانات بين عمليات البناء.
.SH الملفات
لتسهيل بناء الصور لنسخ التطوير الخاصة بمشاريعك، يمكن لـ \f[B]mkosi\f[R]
قراءة بيانات الإعدادات من الدليل المحلي، على افتراض أنه استُدعي من شجرة
\f[I]المصدر\f[R]. تحديداً، تُستخدم الملفات التالية إذا وُجدت في الدليل
المحلي:\fR
.IP \f[R]\[bu]\fR 2
يمكن استخدام الدليل \f[CB]mkosi.skeleton/\f[R] أو أرشيف
\f[CB]mkosi.skeleton.tar\f[R] لإدراج ملفات داخل الصورة. تُنسخ الملفات
\f[I]قبل\f[R] تثبيت حزم التوزيعة في الصورة. يسمح هذا بإنشاء الملفات التي يجب
توفيرها مبكراً، على سبيل المثال لضبط مدير الحزم أو ضبط مسبقات (presets) نظام
systemd.\fR
.RS 2
.PP
عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون
مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.
.RE
.IP \[bu] 2
يمكن استخدام الدليل \f[CB]mkosi.extra/\f[R] أو أرشيف
\f[CB]mkosi.extra.tar\f[R] لإدراج ملفات إضافية في الصورة، بالإضافة إلى ما
تتضمنه التوزيعة في حزمها. وهي تشبه \f[CR]mkosi.skeleton/\f[R]
و\f[CR]mkosi.skeleton.tar\f[R]، لكن الملفات تُنسخ إلى شجرة أدلة الصورة
\f[I]بعد\f[R] تثبيت نظام التشغيل.\fR
.RS 2
.PP
عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون
مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.
.RE
.IP \[bu] 2
يمكن استخدام الدليل \f[CB]mkosi.sandbox/\f[R] أو أرشيف
\f[CB]mkosi.sandbox.tar\f[R] لضبط مدير الحزم دون إدراج هذه الملفات داخل
الصورة. إذا كان يجب تضمين الملفات في الصورة، يجب استخدام
\f[CR]mkosi.skeleton/\f[R] و\f[CR]mkosi.skeleton.tar\f[R] بدلاً من ذلك.\fR
.RS 2
.PP
عند استخدام الدليل، لا تُحفظ ملكية الملفات: جميع الملفات المنسوخة ستكون
مملوكة للمستخدم الجذر. للحفاظ على الملكية، استخدم أرشيف tar.
.RE
.IP \[bu] 2
سيُنسخ ملف إعدادات nspawn المسمى \f[CB]mkosi.nspawn\f[R] إلى نفس مكان ملف
صورة المخرجات، إذا وُجد. وهذا مفيد لأن nspawn يبحث عن ملفات الإعدادات بجانب
ملفات الصور التي يقلع منها، للحصول على إعدادات تشغيل حاويات إضافية.\fR
.IP \f[R]\[bu]\fR 2
الدليل \f[CB]mkosi.cache/\f[R]، إذا وُجد، يُستخدم آلياً كخبيئة لتنزيل الحزم،
من أجل تسريع عمليات التشغيل المتكررة للأداة.\fR
.IP \f[R]\[bu]\fR 2
الدليل \f[CB]mkosi.builddir/\f[R]، إذا وُجد، يُستخدم آلياً كدليل بناء خارج
الشجرة (out\-of\-tree)، إذا كانت أوامر البناء في سكريبتات
\f[CR]mkosi.build\f[R] تدعم ذلك. تحديداً، سيُوصل هذا الدليل داخل حاوية
البناء، وسيُضبط متغير البيئة \f[CR]$BUILDDIR\f[R] ليشير إليه عند استدعاء
سكريبتات البناء. يمكن لسكريبت البناء حينها استخدام هذا الدليل كدليل بناء،
لعمليات البناء خارج الشجرة بنمط \f[B]automake\f[R] أو \f[B]ninja\f[R]. يسرع
هذا عمليات البناء بشكل ملحوظ، خاصة عند استخدام \f[B]mkosi\f[R] في الوضع
المتزايد (\f[CR]\-i\f[R]): حيث لا تقتصر إعادة الاستخدام على الصورة وطبقة
البناء فحسب، بل تشمل شجرة البناء أيضاً بين الاستدعاءات المتتالية. لاحظ أنه
إذا لم يكن هذا الدليل موجوداً، فلن يُضبط متغير البيئة \f[CR]$BUILDDIR\f[R]،
ويُترك لسكريبتات البناء قرار إجراء بناء داخل الشجرة أو خارجها، وأي دليل بناء
ستستخدم.\fR
.IP \f[R]\[bu]\fR 2
يمكن استخدام ملف \f[CB]mkosi.rootpw\f[R] لتوفير كلمة مرور للمستخدم الجذر
(root) في الصورة. إذا سُبقت كلمة المرور بـ \f[CR]hashed:\f[R] تُعامل ككلمة
مرور جذر مجزأة (hashed) بالفعل. يمكن اختيارياً إتباع كلمة المرور بمحرف سطر
جديد يُزال ضمناً. يجب أن يكون نمط الوصول للملف 0600 أو أقل. إذا لم يكن هذا
الملف موجوداً، تُضبط كلمة مرور الجذر المبدئية للتوزيعة (وهو ما يعني عادةً أن
الوصول للمستخدم الجذر محظور).\fR
.IP \f[R]\[bu]\fR 2
يوفر ملف \f[CB]mkosi.passphrase\f[R] عبارة المرور لاستخدامها عند اختيار
تعمية LUKS. يجب أن يحتوي على عبارة المرور حرفياً، وألا ينتهي بمحرف سطر جديد
(أي بنفس التنسيق الذي تتوقعه \f[B]cryptsetup\f[R] و\f[CR]/etc/crypttab\f[R]
لملفات عبارة المرور). يجب أن يكون نمط الوصول للملف 0600 أو أقل.\fR
.IP \f[R]\[bu]\fR 2
يحتوي الملفان \f[CB]mkosi.crt\f[R] و\f[CB]mkosi.key\f[R] على شهادة X.509
ومفتاح PEM خاص لاستخدامهما عندما يكون التوقيع مطلوباً (إقلاع UEFI الآمن،
verity، \&...).\fR
.IP \f[R]\[bu]\fR 2
يُستخدم الدليل \f[CB]mkosi.output/\f[R] لتخزين جميع نواتج البناء.\fR
.IP \f[R]\[bu]\fR 2
يُستخدم الدليل \f[CB]mkosi.credentials/\f[R] كمصدر لبيانات اعتماد إضافية
مشابه لخيار \f[CR]Credentials=\f[R]. لكل ملف في الدليل، سيُستخدم اسم الملف
كاسم لبيانات الاعتماد وتصبح محتويات الملف هي قيمة بيانات الاعتماد، أو إذا
كان الملف قابلاً للتنفيذ، سيقوم \f[B]mkosi\f[R] بتنفيذ الملف ويُستخدم خرج
الأمر إلى stdout كقيمة لبيانات الاعتماد. سيُتجاهل الخرج إلى stderr. بيانات
الاعتماد التي ضُبطت باستخدام \f[CR]Credentials=\f[R] لها الأولوية على
الملفات الموجودة في \f[CR]mkosi.credentials\f[R].\fR
.IP \f[R]\[bu]\fR 2
يُستخدم الدليل \f[CB]mkosi.repart/\f[R] كمصدر لملفات تعريف أقسام
\f[B]systemd\-repart\f[R] التي تُمرر إلى \f[B]systemd\-repart\f[R] عند بناء
صورة قرص. إذا لم يكن موجوداً ولم يُضبط إعداد \f[CR]RepartDirectories=\f[R]،
سيلجأ \f[B]mkosi\f[R] مبدئياً إلى ملفات تعريف الأقسام التالية:\fR
.RS 2
.PP
\f[CR]00\-esp.conf\f[R] (إذا كنا نبني صورة قابلة للإقلاع):\fR
.IP
.EX
\f[B][Partition]\f[R]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M\fR
.EE
.PP
\f[CR]05\-bios.conf\f[R] (إذا كنا نبني صورة قابلة للإقلاع بنظام BIOS):\fR
.IP
.EX
\f[B][Partition]\f[R]
\f[I]# UUID لقسم إقلاع BIOS الخاص بـ grub والذي يحتاجه grub على GPT\f[R]
\f[I]# ليغرس نفسه بداخله.\f[R]
Type=21686148\-6449\-6e6f\-744e\-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M\fR
.EE
.PP
\f[CR]10\-root.conf\fR
.IP
.EX
\f[B][Partition]\f[R]
Type=root
Format=<distribution\-default\-filesystem>
CopyFiles=/
Minimize=guess\fR
.EE
.PP
لاحظ أنه إذا وُجد \f[CR]mkosi.repart/\f[R] أو استُخدم
\f[CR]RepartDirectories=\f[R]، فلن نستخدم أي من تعريفات الأقسام المبدئية.\fR
.RE
.PP
جميع هذه الملفات اختيارية.
.PP
لاحظ أن موقع كل هذه الملفات يمكن ضبطه أيضاً أثناء الاستدعاء عبر مفاتيح سطر
الأوامر، وكإعدادات في \f[CR]mkosi.conf\f[R]، في حال كانت الإعدادات المبدئية
غير مقبولة لمشروع ما.\fR
.SH "الخزن في الخبيئة"
يدعم \f[B]mkosi\f[R] ثلاث خبيئات مختلفة لتسريع عمليات إعادة بناء الصور
المتكررة. وتحديداً:\fR
.IP \f[R]1.\fR 3
يمكن خزن خبيئة الحزم الخاصة بمدير حزم التوزيعة بين عمليات البناء. يُضبط هذا
عبر الخيار \f[CR]\-\-cache\-directory=\f[R] أو دليل
\f[CR]mkosi.cache/\f[R]. يعتمد هذا النوع من الخزن على مدير حزم التوزيعة،
ويخزن حزم التوزيعة (RPM، وdeb، و\&...) بعد تنزيلها، ولكن قبل فكها.\fR
.IP \f[R]2.\fR 3
إذا فُعل وضع البناء المتزايد عبر \f[CR]\-\-incremental=yes\f[R]، تُنشأ نسخ
مخبوءة من الصورة النهائية وطبقة البناء (build overlay) مباشرةً قبل نسخ مصادر
البناء إليها (بالنسبة لطبقة البناء) أو نسخ النواتج المولدة بواسطة
\f[CR]mkosi.build\f[R] (في حالة الصورة النهائية). يسمح هذا النوع من الخزن
بتجاوز خطوة فك الحزم التي تستهلك وقتاً طويلاً في مديري حزم التوزيعات، ولكنه
فعال فقط إذا بقيت قائمة الحزم المراد استخدامها مستقرة، بينما تتغير مصادر
البناء وسكريبتاتها بانتظام. لاحظ أن هذه الخبيئة تتطلب إفراغاً يدوياً: كلما
عُدلت قائمة الحزم، يجب إزالة الصور المخبوءة صراحةً قبل إعادة البناء التالية،
باستخدام المفتاح \f[CR]\-f\f[R].\fR
.IP \f[R]3.\fR 3
أخيراً، يمكن مشاركة دليل نواتج البناء بين عمليات بناء متعددة، باستخدام دليل
\f[CR]mkosi.builddir/\f[R]. يسمح هذا الدليل لأنظمة البناء مثل Meson بإعادة
استخدام المصادر المجمعة مسبقاً من بناء سابق، مما يسرع عملية البناء لسكريبت
\f[CR]mkosi.build\f[R].\fR
.PP
خبيئة الحزم والوضع المتزايد مفيدان دائماً. أما الخبيئة الأخيرة فتنطبق فقط
على استخدامات \f[B]mkosi\f[R] مع شجرة مصدر وسكريبت بناء. عند تفعيل الثلاثة
معاً، تصبح أوقات دورة بناء الصورة الكاملة في حدها الأدنى، حيث يلزم فقط إعادة
تجميع ملفات المصدر التي تغيرت.\fR
.SH "أشجار الأدوات"
أشجار الأدوات هي صورة ثانوية يمكن لـ mkosi استخدامها لبناء الصور
الفعلية. وهذا مفيد لجعل عمليات بناء الصور أكثر قابلية لإعادة الإنتاج، كما
يسمح باستخدام أدوات أحدث قد لا تكون متوفرة بعد في توزيعة المضيف التي تشغل
mkosi.
.PP
يمكن توفير أشجار الأدوات عبر خيار \f[CR]ToolsTree=\f[R]، أو دليل
\f[CR]mkosi.tools\f[R] أو بناؤها آلياً بواسطة mkosi إذا ضُبط على
\f[CR]ToolsTree=yes\f[R]. في معظم حالات الاستخدام، يكفي استخدام أشجار
الأدوات المبدئية، ويُنصح باستخدام شجرة أدوات.\fR
.PP
يمكن بناء أشجار أدوات مخصصة بالكامل كأي صورة mkosi أخرى، ولكن يوفر mkosi
تضميناً مدمجاً يقدم حزم شجرة الأدوات المبدئية:
.IP
.EX
mkosi \-\-include=mkosi\-tools \-\-format=directory
.EE
.PP
يمكن تخصيص أشجار الأدوات، بما في ذلك الأشجار المبدئية، بشكل أكبر عبر متغيرات
\f[CR]ToolsTree*=\f[R] المختلفة بالإضافة إلى ملف أو دليل إعدادات
\f[CR]mkosi.tools.conf\f[R]. لا يمكن حالياً تغيير تنسيق المخرجات لأشجار
الأدوات عبر ملفات الإعدادات.\fR
.PP
يوضح الجدول التالي التوزيعات التي عُرّفت لها حزم أشجار أدوات مبدئية والحزم
المضمنة في تلك الأشجار المبدئية:
.PP
.TS
tab(@);
lw(18.8n) cw(6.0n) cw(6.0n) cw(6.0n) cw(4.5n) cw(6.0n) cw(4.5n) cw(7.5n) cw(10.5n).
T{
T}@T{
فيدورا
T}@T{
سنت أو إس
T}@T{
ديبايان
T}@T{
كالي
T}@T{
أوبونتو
T}@T{
بنية
T}@T{
أوبن سوزا
T}@T{
بوسط ماركت أو إس
T}
_
T{
\f[CR]acl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]apt\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]archlinux\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]attr\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]bash\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]btrfs\-progs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ca\-certificates\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]coreutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]cpio\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]createrepo_c\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]curl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]debian\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]diffutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]distribution\-gpg\-keys\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]dnf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]dosfstools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]e2fsprogs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]edk2\-ovmf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]erofs\-utils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]findutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]git\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]grep\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]grub\-tools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]jq\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]kali\-archive\-keyring\fR
T}@T{
T}@T{
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[CR]kmod\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]less\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]mtools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]نانو\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]opensc\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]openssh\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]openssl\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]pkcs11\-provider\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]perf\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]sed\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]pacman\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]p11\-kit\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]policycoreutils\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]qemu\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]sbsigntools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]socat\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]squashfs\-tools\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]strace\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]swtpm\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]systemd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ukify\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]tar\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]ubuntu\-keyring\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
T}
T{
\f[CR]util\-linux\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]virtiofsd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]virt\-firmware\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]xfsprogs\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]xz\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]zstd\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}
T{
\f[CR]zypper\fR
T}@T{
\f[R]✓\fR
T}@T{
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
\f[R]✓\fR
T}@T{
T}
.TE
.SH "بناء صور متعددة"
إذا وُجد دليل \f[CR]mkosi.images/\f[R]، فسيقوم \f[B]mkosi\f[R] بتحميل
إعدادات الصور الفرعية الفردية منه وبناء كل منها. يمكن أن تكون إعدادات الصور
إما أدلة تحتوي على ملفات إعداد \f[B]mkosi\f[R] أو ملفات عادية بامتداد
\&\f[CR].conf\f[R].\fR
.PP
عند العثور على إعدادات الصور في \f[CR]mkosi.images/\f[R]، سيقوم
\f[B]mkosi\f[R] ببناء الصور المحددة في إعداد \f[CR]Dependencies=\f[R] للصورة
الرئيسة وكافة تبعاتها (أو جميعها إذا لم تُضبط أي صور صراحةً باستخدام
\f[CR]Dependencies=\f[R] في إعداد الصورة الرئيسة). لإضافة تبعات بين الصور
الفرعية، يمكن استخدام إعداد \f[CR]Dependencies=\f[R] أيضًا. تُبنى الصور
الفرعية دومًا قبل الصورة الرئيسة.\fR
.PP
عند تعريف الصور، سيقرأ \f[B]mkosi\f[R] أولًا إعداد الصورة الرئيسة (الإعداد
خارج دليل \f[CR]mkosi.images/\f[R])، يليه الإعداد الخاص بالصورة.\fR
.PP
تنطبق عدة إعدادات "عالمية شاملة" على شجرة الأدوات المبدئية وعلى الصورة
الرئيسة ولا يمكن ضبطها بشكل منفصل خارج الصورة الرئيسة:
.IP \[bu] 2
\f[CR]RepositoryKeyCheck=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]RepositoryKeyFetch=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SourceDateEpoch=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CacheOnly=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WorkspaceDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]PackageCacheDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildSources=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildSourcesEphemeral=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyClientCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyClientKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyExclude=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyPeerCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ProxyUrl=\fR
.PP
تنطبق عدة إعدادات "شاملة" على الصورة الرئيسة وكافة صورها الفرعية ولا يمكن
ضبطها بشكل منفصل في الصور الفرعية. الإعدادات التالية شاملة ولا يمكن ضبطها في
الصور الفرعية:
.IP \[bu] 2
\f[CR]Architecture=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CacheDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Distribution=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ExtraSearchPaths=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Incremental=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]LocalMirror=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Mirror=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]OutputDirectory=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]OutputMode=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]PackageDirectories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Release=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]RepartOffline=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Repositories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SandboxTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTree=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeCertificates=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]UseSubvolumes=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootCertificateSource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SecureBootKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityCertificateSource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VerityKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]VolatilePackageDirectories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WithNetwork=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]WithTests\fR
.PP
توجد أيضًا إعدادات تُمرر إلى الصور الفرعية ولكن يمكن تخطيها. بالنسبة لهذه
الإعدادات، القيم المضبوطة صراحةً في الصورة الفرعية ستأخذ الأولوية على القيم
المضبوطة في سطر الأوامر أو في إعداد الصورة الرئيسة. حاليًا تُمرر الإعدادات
التالية إلى الصور الفرعية ولكن يمكن تخطيها:
.IP \[bu] 2
\f[CR]Profiles=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ImageId=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ImageVersion=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SectorSize=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CacheKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BuildKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]CompressLevel=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrKey=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrKeySource=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrCertificate=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]SignExpectedPcrCertificateSource=\fR
.PP
بالإضافة إلى ذلك، هناك إعدادات متنوعة لا يمكن ضبطها إلا في الصورة الرئيسة
ولا تُمرر إلى الصور الفرعية:
.IP \[bu] 2
\f[CR]MinimumVersion=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]PassEnvironment=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeDistribution=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeRelease=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeProfiles=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeMirror=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeRepositories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreeSandboxTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreePackages=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ToolsTreePackageDirectories=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]History=\fR
.IP \f[R]\[bu]\fR 2
كل إعداد في قسم \f[CR][Runtime]\f[R]\fR
.PP
يمكن للصور أن تشير إلى مخرجات الصور التي تعتمد عليها. تحديدًا، للخيارات
التالية، سيتحقق \f[B]mkosi\f[R] فقط مما إذا كانت المدخلات موجودة قبيل بناء
الصورة مباشرةً:\fR
.IP \f[R]\[bu]\fR 2
\f[CR]BaseTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]ExtraTrees=\fR
.IP \f[R]\[bu]\fR 2
\f[CR]Initrds=\fR
.PP
للإشارة إلى مخرجات تبعات الصورة، ما عليك سوى ضبط أي من هذه الخيارات بمسار
نسبي للمخرج المراد استخدامه في دليل مخرجات التبعية. أو استخدم محدد
\f[CR]%O\f[R] للإشارة إلى دليل المخرجات.\fR
.PP
يمكن العثور على مثال جيد حول كيفية بناء صور متعددة في مستودع systemd على
.UR https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images
.UE
.
.SH "متغيرات البيئة"
.IP \[bu] 2
يتخطى \f[CR]$MKOSI_LESS\f[R] خيارات \f[B]less\f[R] عندما يستدعيه
\f[B]mkosi\f[R] لتقسيم المخرجات إلى صفحات.\fR
.IP \f[R]\[bu]\fR 2
يمكن استخدام \f[CR]$MKOSI_DNF\f[R] لتخطي الملف التنفيذي المستخدم كـ
\f[B]dnf\f[R]. هذا مفيد بشكل خاص للاختيار بين \f[B]dnf\f[R] و
\f[B]dnf5\f[R].\fR
.IP \f[R]\[bu]\fR 2
يمكن استخدام \f[CR]$EPEL_MIRROR\f[R] لتخطي موقع المرآة المبدئي المستخدم
لمستودعات epel عند استخدام \f[CR]Mirror=\f[R]. يبحث \f[B]mkosi\f[R] مبدئيًا
عن مستودعات epel في الدليل الفرعي \f[CR]fedora\f[R] من الدليل الأب للمرآة
المحددة في \f[CR]Mirror=\f[R]. على سبيل المثال، إذا ضُبطت المرآة على
\f[CR]https://mirror.net/centos\-stream\f[R] فسيقوم \f[B]mkosi\f[R] بالبحث عن
مستودعات epel في \f[CR]https://mirror.net/fedora/epel\f[R].\fR
.IP \f[R]\[bu]\fR 2
يمكن استخدام \f[CR]SYSEXT_SCOPE\f[R] و \f[CR]CONFEXT_SCOPE\f[R] لتخطي القيمة
المبدئية لملف \f[CR]extension\-release\f[R] المقابل عند بناء sysext أو
confext. تُضبط القيمة مبدئيًا على \f[CR]initrd system portable\f[R].\fR
.SH أمثلة
أنشئ وشغل صورة \f[I]GPT\f[R] خام مع \f[I]ext4\f[R]، باسم
\f[CR]image.raw\f[R]:\fR
.IP
.EX
# mkosi \-p systemd \-i boot
.EE
.PP
أنشئ وشغل صورة \f[I]GPT\f[R] قابلة للإقلاع، باسم \f[CR]foobar.raw\f[R]:\fR
.IP
.EX
$ 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
.EE
.PP
أنشئ وشغل صورة \f[I]Fedora Linux\f[R] في دليل عادي:\fR
.IP
.EX
# mkosi \-\-distribution fedora \-\-format directory boot
.EE
.PP
أنشئ صورة مضغوطة \f[CR]image.raw.xz\f[R] مع تثبيت SSH وأضف ملف تدقيق
مجموع:\fR
.IP
.EX
$ mkosi \-\-distribution fedora \-\-format disk \-\-checksum=yes \-\-compress\-output=yes \-\-package=openssh\-clients
.EE
.PP
داخل دليل المصدر لمشروع يعتمد على \f[B]automake\f[R]، اضبط \f[B]mkosi\f[R]
بحيث يؤدي استدعاء \f[B]mkosi\f[R] ببساطة دون أي معاملات إلى بناء صورة نظام
تشغيل تحتوي على نسخة مبنية من المشروع في حالته الحالية:\fR
.IP
.EX
$ 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 [ \[dq]$container\[dq] != \[dq]mkosi\[dq] ]; then
    exec mkosi\-chroot \[dq]$CHROOT_SCRIPT\[dq] \[dq]$\[at]\[dq]
fi

cd $SRCDIR
\&./autogen.sh
\&./configure \-\-prefix=/usr
make \-j \[ga]nproc\[ga]
make install
EOF
$ chmod +x mkosi.build
# mkosi \-i boot
# systemd\-nspawn \-bi image.raw
.EE
.SS "طرق مختلفة للإقلاع باستخدام \f[CR]vm\fB"
أسهل طريقة لإقلاع آلة افتراضية هي بناء صورة بالمكونات المطلوبة وترك
\f[B]mkosi\f[R] يستدعي \f[B]qemu\f[R] بجميع الخيارات الصحيحة:\fR
.IP
.EX
$ mkosi \-d fedora \-p systemd\-udev,systemd\-boot,kernel\-core build
$ mkosi \-d fedora vm
\&...
fedora login: root (تسجيل دخول آلي)
[root\[at]fedora \[ti]]#
.EE
.PP
المبدئي هو الإقلاع بكونسول نصي فقط. في هذا النمط، تستخدم الرسائل الواردة من
محمل الإقلاع، والنواة، و systemd، ولاحقًا محث تسجيل دخول \f[B]getty\f[R]
والصدفة جميعها نفس الطرفية. يمكن التبديل بين كونسول \f[B]qemu\f[R] والمراقب
بالضغط على \f[CR]Ctrl\-a c\f[R]. يمكن استخدام مراقب \f[B]qemu\f[R] مثلًا لحقن
مفاتيح خاصة أو إيقاف تشغيل الآلة بسرعة. بدلاً من ذلك، يمكن إيقاف تشغيل الآلة
باستخدام \f[CR]Ctrl\-a x\f[R].\fR
.PP
للإقلاع بنوافذ رسومية، أضف \f[CR]\-\-console=gui\f[R]:\fR
.IP
.EX
$ mkosi \-d fedora \-\-console=gui qemu
.EE
.PP
يمكن إقلاع النواة مباشرة باستخدام \f[CR]mkosi vm \-kernel ... \-initrd
\&... \-append \[aq]...\[aq]\f[R]. هذا أسرع قليلاً لأنه لا يُستخدم محمل إقلاع،
كما أنه أسهل لتجربة نويات وأسطر أوامر نواة مختلفة. لاحظ أنه على الرغم من
الاسم، فإن خيار \f[CR]\-append\f[R] الخاص بـ \f[B]qemu\f[R] يستبدل سطر أوامر
النواة المبدئي المدمج في النواة وأي مواصفات \f[CR]\-append\f[R] سابقة.\fR
.PP
يُنسخ UKI أيضًا إلى دليل المخرجات ويمكن إقلاعه مباشرة:
.IP
.EX
$ mkosi vm \-\- \-kernel mkosi.output/fedora\[ti]38/image.efi
.EE
.PP
عند الإقلاع باستخدام نواة خارجية، لا نحتاج إلى وجود النواة \f[I]داخل\f[R]
الصورة، ولكننا سنظل نرغب في تثبيت وحدات النواة.\fR
.PP
من الممكن أيضًا إجراء \f[I]إقلاع نواة مباشر\f[R] إلى محمل إقلاع، بالاستفادة
من حقيقة أن \f[B]systemd\-boot\f[R](7) هو ملف UEFI ثنائي صالح:\fR
.IP
.EX
$ mkosi vm \-\- \-kernel /usr/lib/systemd/boot/efi/systemd\-bootx64.efi
.EE
.PP
في هذا السيناريو، تُحمل النواة من ESP في الصورة بواسطة
\f[B]systemd\-boot\f[R].\fR
.SH المتطلبات
تتوفر حزم mkosi لمختلف التوزيعات: Debian، و Kali، و Ubuntu، و Arch Linux، و
Fedora Linux، و OpenMandriva، و Gentoo، و postmarketOS. لاحظ أنه قد مضى وقت
طويل منذ آخر إصدار والحزم التي تشحنها التوزيعات قديمة جدًا. نوصي حاليا
بتشغيل \f[B]mkosi\f[R] من git حتى يصدر إصدار جديد.\fR
.PP
يتطلب mkosi نواة Linux توفر \f[CR]mount_setattr()\f[R] التي قُدمت في
5.12.\fR
.PP
يتطلب mkosi حاليًا systemd 254 لبناء صور أقراص قابلة للإقلاع.
.PP
عند عدم استخدام حزم التوزيعات، تأكد من تثبيت التبعات اللازمة. على سبيل
المثال، في \f[I]Fedora Linux\f[R] تحتاج إلى:\fR
.IP
.EX
\f[I]# dnf install btrfs\-progs apt dosfstools mtools edk2\-ovmf e2fsprogs squashfs\-tools gnupg python3 tar xfsprogs xz zypper sbsigntools\fR
.EE
.PP
في Debian/Kali/Ubuntu قد يكون من الضروري تثبيت حزم
\f[CR]ubuntu\-keyring\f[R]، و \f[CR]ubuntu\-archive\-keyring\f[R]، و
\f[CR]kali\-archive\-keyring\f[R] و/أو \f[CR]debian\-archive\-keyring\f[R]
صراحةً، بالإضافة إلى \f[B]apt\f[R]، اعتمادًا على نوع صور التوزيعات التي تريد
بناءها.\fR
.PP
لاحظ أن الحد الأدنى المطلوب من نسخة Python هو 3.9.
.PP
يحتاج mkosi إلى قدرات غير مقيدة للإنشاء والعمل داخل فضاءات الأسماء. تقيد بعض
التوزيعات إنشاء فضاءات أسماء المستخدمين أو القدرات داخلها، مما يعطل mkosi.
.PP
للحصول على معلومات حول Ubuntu، التي تنفذ مثل هذه القيود باستخدام AppArmor،
راجع
https://ubuntu.com/blog/ubuntu\-23\-10\-restricted\-unprivileged\-user\-namespaces.
للأنظمة الأخرى، حاول البحث في sysctls لـ
\f[CR]kernel.unprivileged_userns_clone\f[R] أو
\f[CR]user.max.user_namespace\f[R].\fR
.PP
لأنظمة Ubuntu، يمكنك إزالة القيود المفروضة على \f[B]mkosi\f[R] عن طريق تكييف
هذه القصاصة لتشير إلى ملف \f[B]mkosi\f[R] الثنائي الخاص بك، ونسخها إلى
\f[CR]/etc/apparmor.d/resolved.path.to.mkosi\f[R]، ثم تشغيل \f[CR]systemctl
reload apparmor\f[R]:\fR
.IP
.EX
abi <abi/4.0>,

include <tunables/global>

/resolved/path/to/mkosi flags=(default_allow) {
  userns,
}
.EE
.SH "الأسئلة الشائعة (FAQ)"
.IP \[bu] 2
لماذا لا يعمل \f[CR]mkosi vm\f[R] مع KVM على Debian/Kali/Ubuntu؟\fR
.RS 2
.PP
بينما لا تمانع التوزيعات الأخرى في السماح بالوصول إلى \f[CR]/dev/kvm\f[R]،
فإن هذا مسموح به في Debian/Kali/Ubuntu فقط للمستخدمين في مجموعة
\f[CR]kvm\f[R]. نظرًا لأن \f[B]mkosi\f[R] يفصل فضاء أسماء مستخدم عند التشغيل
دون امتيازات، فحتى لو كان المستخدم المستدعِي في مجموعة kvm، فعندما يفصل
\f[B]mkosi\f[R] فضاء أسماء المستخدم للتشغيل دون امتيازات، فإنه يفقد الوصول
إلى مجموعة \f[CR]kvm\f[R] وبحلول الوقت الذي نبدأ فيه \f[B]qemu\f[R] لا نملك
وصولاً إلى \f[CR]/dev/kvm\f[R] بعد الآن. كحل بديل، يمكنك تغيير أذونات عُقد
الجهاز إلى \f[CR]0666\f[R] وهو ما يكفي لجعل KVM يعمل دون امتيازات. لتثبيت
هذه الإعدادات عبر عمليات إعادة التشغيل، انسخ
\f[CR]/usr/lib/tmpfiles.d/static\-nodes\-permissions.conf\f[R] إلى
\f[CR]/etc/tmpfiles.d/static\-nodes\-permissions.conf\f[R] وغير نمط
\f[CR]/dev/kvm\f[R] من \f[CR]0660\f[R] إلى \f[CR]0666\f[R].\fR
.RE
.IP \f[R]\[bu]\fR 2
كيف يمكنني إضافة مستخدم عادي إلى صورة؟
.RS 2
.PP
يمكنك استخدام القصاصة التالية في سكربت ما بعد التثبيت:
.IP
.EX
useradd \-\-create\-home \-\-user\-group $USER \-\-password \[dq]$(openssl passwd \-stdin \-6 <$USER_PASSWORD_FILE)\[dq]
.EE
.PP
لاحظ أنه من الإصدار v256 من systemd فصاعدًا، إذا فُعلت، فستطلب
\f[B]systemd\-homed\-firstboot.service\f[R] إنشاء مستخدم عادي عند أول إقلاع
إذا لم يكن هناك مستخدمون عاديون.\fR
.RE
.IP \f[R]\[bu]\fR 2
لماذا أرى إخفاقات في chown للملفات عند بناء الصور؟
.RS 2
.PP
عندما لا تعمل كجذر (root)، لا يستطيع مستخدمك تغيير ملكية الملفات إلى ملاك
اعتباطيين. لا تزال توزيعات مختلفة تشحن ملفات في حزمها لا يملكها المستخدم
الجذر. عندما لا يعمل mkosi كجذر، فإنه يربط المستخدم الحالي بالجذر عند
استدعاء مديري الحزم، مما يعني أن تغيير الملكية إلى الجذر سيعمل ولكن تغيير
الملكية إلى أي مستخدم أو مجموعة أخرى سيخفق.
.PP
لاحظ أن استدعاءات chown تُكبت فقط عند تشغيل مديري الحزم، وليس عند تشغيل
السكربتات. إذا كان هذا مطلوبًا، على سبيل المثال لسكربت بناء، يمكنك ضبط
المتغير \f[CR]MKOSI_CHROOT_SUPPRESS_CHOWN\f[R] على قيمة حقيقية
(\f[CR]1\f[R]، \f[CR]yes\f[R]، \f[CR]true\f[R]) لكبت استدعاءات chown في
سكربتات \f[B]mkosi\-chroot\f[R] و \f[CR].chroot\f[R].\fR
.PP
إذا كان هذا السلوك يتسبب في سوء تصرف التطبيقات التي تعمل في صورتك، يمكنك
التفكير في تشغيل \f[B]mkosi\f[R] كجذر لتجنب هذه المشكلة. بدلاً من ذلك، إذا
كان تشغيل \f[B]mkosi\f[R] كجذر غير مرغوب فيه، يمكنك استخدام \f[CR]unshare
\-\-map\-auto \-\-map\-current\-user \-\-setuid 0 \-\-setgid 0\f[R] لتصبح جذرًا في فضاء
أسماء مستخدم مع أكثر من مستخدم واحد بافتراض أن خرائط UID/GID في
\f[CR]/etc/subuid\f[R] و \f[CR]/etc/subgid\f[R] قد ضُبطت بشكل صحيح. لاحظ أن
تشغيل mkosi كجذر أو باستخدام \f[CR]unshare\f[R] يعني أن جميع ملفات المخرجات
التي ينتجها \f[B]mkosi\f[R] لن يملكها مستخدمك الحالي بعد الآن.\fR
.PP
لاحظ أنه بالنسبة لخدمات systemd التي تحتاج إلى أدلة في \f[CR]/var\f[R]
يملكها مستخدم الخدمة ومجموعتها، فإن البديل لشحن هذه الأدلة في حزم أو إنشائها
عبر systemd\-tmpfiles هو استخدام \f[CR]StateDirectory=\f[R] أو
\f[CR]CacheDirectory=\f[R] أو \f[CR]LogsDirectory=\f[R] في ملف الخدمة مما
يوجه systemd لإنشاء الدليل عند بدء تشغيل الخدمة لأول مرة.\fR
.PP
بدلاً من ذلك، يمكن استخدام توجيهات \f[CR]z\f[R] أو \f[CR]Z\f[R] لـ
\f[CR]systemd\-tmpfiles\f[R] لعمل chown لمختلف الأدلة والملفات لمستخدمها
المالك عند إقلاع النظام لأول مرة.\fR
.RE
.IP \f[R]\[bu]\fR 2
لماذا يقول \f[CR]portablectl inspect
<image>\f[R]/\f[CR]systemd\-dissect <image>\f[R] أن خدمتي
المحمولة ليست كذلك؟\fR
.RS 2
.PP
يتحقق \f[CR]systemd\-dissect\f[R] و \f[CR]portablectl inspect\f[R] من
\f[CR]PORTABLE_PREFIXES=\f[R] في \f[CR]os\-release\f[R] وإذا كان المفتاح
مفقودًا، فسيخفقان في التعرف على الخدمة المحمولة كواحدة، ويظهران ✗ تحت
\f[I]Use as\f[R] في حالة \f[CR]systemd\-dissect\f[R] أو \f[CR]n/a\f[R] تحت
\f[I]Portable Service\f[R] لـ \f[CR]portablectl\f[R].\fR
.PP
بما أنه لا توجد قيمة مبدئية جيدة لضبط هذا المفتاح وصور الخدمة المحمولة
المنشأة ستظل ترفق بشكل صحيح حتى في حالة عدم ضبط المفتاح، فإن \f[B]mkosi\f[R]
لا يضبط أيًا منها.\fR
.PP
يمكنك ضبط \f[CR]PORTABLE_PREFIXES=\f[R] في ملف \f[CR]os\-release\f[R] بنفسك
في سكربت ما بعد التثبيت (postinst).\fR
.RE
.SH المراجع
.IP \[bu] 2

مستودع mkosi git الرئيس على GitHub
.UR https://github.com/systemd/mkosi/
.UE
.IP \[bu] 2

.UR https://0pointer.net/blog/mkosi\-a\-tool\-for\-generating\-os\-images.html
mkosi \[em] أداة لإنشاء صور أنظمة التشغيل
.UE
\ تدوينة مقدمة بقلم
Lennart Poettering
.IP \[bu] 2

.UR https://lwn.net/Articles/726655/
أداة إنشاء أنظمة التشغيل mkosi
.UE
\ قصة على LWN
.SH "انظر أيضًا"
\f[B]systemd\-nspawn\f[R](1), \f[B]systemd\-repart\f[R](8),
\f[B]dnf\f[R](8)\fR
.PP
.SH ترجمة
تُرجمت هذه الصفحة من الدليل بواسطة
زايد السعيدي <zayed.alsaidi@gmail.com>
.
.PP
هذه الترجمة هي وثيقة مجانية؛ راجع
.UR https://www.gnu.org/licenses/gpl-3.0.html 
رخصة جنو العامة الإصدار 3
.UE
أو ما بعده للاطلاع على شروط حقوق النشر.
لا توجد أي ضمانات.
.PP
إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه،
يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين:
.MT kde-l10n-ar@kde.org
.ME .