'\" t
.\" Automatically generated by Pandoc 3.10.2
.\"
.TH "mkosi" "1" "" ""
.SH "نام (NAME)"
mkosi \- ساخت ایمیج‌های سفارشی سیستم‌عامل
.SH "خلاصه دستور (SYNOPSIS)"
\f[B]mkosi [options\&...]
init\f[R]
.PP
\f[B]mkosi [options\&...]
summary\f[R]
.PP
\f[B]mkosi [options\&...]
cat\-config\f[R]
.PP
\f[B]mkosi [options\&...]
build [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
shell [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
boot [\-\- nspawn settings\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
vm [\-\- vmm parameters\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
ssh [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
journalctl [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
coredumpctl [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
sysupdate [\-\- sysupdate settings\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
box [\-\- command line\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
dependencies [\-\- options\&...]\f[R]
.PP
\f[B]mkosi [options\&...]
clean\f[R]
.PP
\f[B]mkosi [options\&...]
serve\f[R]
.PP
\f[B]mkosi [options\&...]
burn <device>\f[R]
.PP
\f[B]mkosi [options\&...]
bump\f[R]
.PP
\f[B]mkosi [options\&...]
genkey\f[R]
.PP
\f[B]mkosi [options\&...]
documentation [manual]\f[R]
.PP
\f[B]mkosi [options\&...]
completion [shell]\f[R]
.PP
\f[B]mkosi [options\&...]
latest\-snapshot\f[R]
.PP
\f[B]mkosi [options\&...]
help\f[R]
.SH "توضیحات (DESCRIPTION)"
دستور \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] است که می‌تواند ایمیج‌های دیسک را
همراه با امکانات و قابلیت‌های متعددی ایجاد کند.
.SS "زیردستورهای خط فرمان (Command Line Verbs)"
زیردستورهای خط فرمان زیر پشتیبانی می‌شوند:
.TP
\f[B]init\f[R]
مقداردهی اولیه \f[B]mkosi\f[R].
این یک عملیات یک‌باره است که فایل‌های پیکربندی مختلف مورد نیاز برای یک تجربه بهینه را راه‌اندازی می‌کند.
در حال حاضر این دستور تنها یک دراپ‌این \f[B]tmpfiles.d\f[R] برای دایرکتوری حافظه موقت (cache) بسته‌های mkosi راه‌اندازی می‌کند تا اطمینان حاصل شود که فایل‌های قدیمی و بدون استفاده به‌طور خودکار پاک‌سازی می‌شوند.
.TP
\f[B]summary\f[R]
نمایش خلاصه‌ای خوانا برای انسان از تمامی گزینه‌های استفاده‌شده برای ساخت ایمیج‌ها.
این دستور خط فرمان و فایل‌های پیکربندی را تجزیه می‌کند، اما تنها تنظیمات اعمال‌شده را چاپ کرده و عملاً چیزی را نمی‌سازد یا اجرا نمی‌کند.
.TP
\f[B]cat\-config\f[R]
نمایش نام‌ها و محتوای تمام فایل‌های پیکربندی بارگذاری‌شده در خروجی.
دستور \f[B]mkosi\f[R] مجموعه‌ای از فایل‌ها را از مکان‌های مختلف بارگذاری می‌کند و این دستور بررسی این‌که چه چیزی در کجا پیکربندی شده است را آسان‌تر می‌سازد.
.TP
\f[B]build\f[R]
ساخت ایمیج بر اساس تنظیمات ارائه‌شده در خط فرمان و فایل‌های پیکربندی.
در صورتی که هیچ زیردستوری مشخص نشود، این دستور حالت پیش‌فرض است.
در صورت تعریف شدن اسکریپت‌های ساخت، می‌توان آرگومان‌هایی را به آن‌ها ارسال کرد.
برای ارسال گزینه‌ها به اسکریپت‌های ساخت، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی mkosi جدا کنید.
.TP
\f[B]shell\f[R]
این دستور در صورتی که ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس \f[B]systemd\-nspawn\f[R] را برای اجرای یک پوسته تعاملی درون ایمیج فراخوانی می‌کند.
این کار نیازی به راه‌اندازی (بوت) سیستم ندارد و مانند نسخه‌ای پیشرفته‌تر از chroot عمل می‌کند.
می‌توان یک خط فرمان اختیاری را پس از زیردستور \f[B]shell\f[R] مشخص کرد تا به جای پوسته درون کانتینر اجرا شود.
برای ارسال گزینه‌های اضافی به nspawn، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا کنید.
.RS
جهت استفاده از ایمیج‌های \f[B]directory\f[R] با \f[B]shell\f[R]، گزینه \f[B]ForeignUIDRange=\f[R] باید هنگام ساخت ایمیج فعال شده باشد.
.RE
.TP
\f[B]boot\f[R]
مشابه \f[B]shell\f[R]، اما به جای اجرای یک پوسته، systemd را با استفاده از \f[B]systemd\-nspawn\f[R] درون ایمیج بوت می‌کند.
می‌توان آرگومان‌های اضافی را پس از زیردستور \f[B]boot\f[R] مشخص کرد که به عنوان \f[I]خط فرمان کرنل (kernel command line)\f[R] به سیستم init درون ایمیج ارسال می‌شوند.
برای ارسال گزینه‌های اضافی به nspawn، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا کنید.
.RS
جهت استفاده از ایمیج‌های \f[B]directory\f[R] با \f[B]boot\f[R]، گزینه \f[B]ForeignUIDRange=\f[R] باید هنگام ساخت ایمیج فعال شده باشد.
برای استفاده از ایمیج‌های \f[B]disk\f[R] با \f[B]boot\f[R]، به systemd\-nsresourced و systemd\-mountfsd نسخه v260 یا جدیدتر روی سیستم میزبان نیاز است.
.RE
.TP
\f[B]vm\f[R]
مشابه \f[B]boot\f[R]، اما از ناظر ماشین مجازی پیکربندی‌شده (به‌طور پیش‌فرض \f[B]qemu\f[R]) برای بوت کردن ایمیج استفاده می‌کند؛ یعنی به جای مجازی‌سازی کانتینری، از مجازی‌سازی ماشین مجازی استفاده می‌شود.
نحوه تفسیر آرگومان‌های خط فرمان اضافی به ناظر ماشین مجازی پیکربندی‌شده بستگی دارد.
برای اطلاعات بیشتر \f[B]VirtualMachineMonitor=\f[R] را ببینید.
برای ارسال گزینه‌های اضافی به ناظر ماشین مجازی پیکربندی‌شده، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا کنید.
.RS
جهت استفاده از ایمیج‌های \f[B]directory\f[R] با \f[B]vm\f[R]، گزینه \f[B]ForeignUIDRange=\f[R] باید هنگام ساخت ایمیج فعال شده باشد.
.RE
.TP
\f[B]ssh\f[R]
هنگامی که ایمیج با گزینه \f[B]Ssh=always\f[R] ساخته شده باشد یا سرویس \f[B]sshd\-vsock\f[R] مربوط به systemd در ماشین مجازی در حال اجرا باشد (systemd نسخه v256 به بالا)، این دستور از طریق SSH به یک ماشین مجازی بوت‌شده متصل می‌شود.
اطمینان حاصل کنید که \f[B]mkosi ssh\f[R] را با همان پیکربندی \f[B]mkosi build\f[R] اجرا می‌کنید تا اطلاعات لازم برای اتصال به ماشین مجازی در حال اجرا از طریق SSH در دسترس باشد.
به‌ویژه، کلید خصوصی SSH از تنظیم \f[B]SshKey=\f[R] برای اتصال به ماشین مجازی استفاده می‌شود.
از \f[B]mkosi genkey\f[R] برای تولید خودکار کلید و گواهی‌نامه‌ای که توسط \f[B]mkosi\f[R] شناسایی می‌شود استفاده کنید.
هر آرگومانی که بعد از زیردستور \f[B]ssh\f[R] مشخص شود، به عنوان آرگومان به فراخوانی \f[B]ssh\f[R] ارسال می‌شود.
برای ارسال گزینه‌های اضافی، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا کنید. برای اتصال به یک کانتینر، از \f[B]machinectl login\f[R] یا \f[B]machinectl shell\f[R] استفاده کنید.
.RS
گزینه \f[B]Machine=\f[R] می‌تواند برای اختصاص یک نام میزبان (hostname) سفارشی به ماشین در زمان بوت استفاده شود که بعداً می‌توان از آن برای \f[B]ssh\f[R] به ایمیج استفاده کرد (به‌عنوان مثال، \f[B]mkosi \-\-machine=mymachine vm\f[R] و به دنبال آن \f[B]mkosi \-\-machine=mymachine ssh\f[R]).
.RE
.TP
\f[B]journalctl\f[R]
از \f[B]journalctl\f[R] برای بررسی ژورنال درون ایمیج استفاده می‌کند.
تمام آرگومان‌هایی که بعد از زیردستور \f[B]journalctl\f[R] مشخص شده و با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا شوند، به فراخوانی \f[B]journalctl\f[R] پیوست می‌گردند.
.TP
\f[B]coredumpctl\f[R]
از \f[B]coredumpctl\f[R] برای جستجوی coredumpها درون ایمیج استفاده می‌کند.
تمام آرگومان‌هایی که بعد از زیردستور \f[B]coredumpctl\f[R] مشخص شده و با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا شوند، به فراخوانی \f[B]coredumpctl\f[R] پیوست می‌گردند.
.TP
\f[B]sysupdate\f[R]
دستور \f[B]systemd\-sysupdate\f[R] را با تنظیم گزینه \f[B]\-\-transfer\-source=\f[R] بر روی دایرکتوری خروجی و گزینه \f[B]\-\-definitions=\f[R] بر روی دایرکتوری پیکربندی‌شده با \f[B]SysupdateDirectory=\f[R] فراخوانی می‌کند.
تمام آرگومان‌هایی که بعد از زیردستور \f[B]sysupdate\f[R] مشخص شده و با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا شوند، مستقیماً به \f[B]systemd\-sysupdate\f[R] ارسال می‌شوند.
.TP
\f[B]box\f[R]
اجرای دستورات دلخواه درون همان محیطی که برای اجرای سایر زیردستورها مانند \f[B]boot\f[R]، \f[B]shell\f[R]، \f[B]vm\f[R] و غیره استفاده می‌شود.
این بدان معناست که در صورت استفاده از درخت ابزارها (tools tree)، دایرکتوری \f[B]/usr\f[R] با \f[B]/usr\f[R] درخت ابزارها جایگزین خواهد شد، در حالی که همه چیز دیگر در جای خود باقی می‌ماند.
اگر دستوری مشخص نشود، \f[B]$SHELL\f[R] یا در صورت تنظیم نبودن آن، \f[B]bash\f[R] اجرا خواهد شد.
برای ارسال گزینه‌های اضافی به دستور داده‌شده، آن‌ها را با \f[B]\-\-\f[R] از گزینه‌های معمولی جدا کنید..TP
\f[B]clean\f[R]
مصنوعات ساخت تولیدشده در یک ساخت قبلی را حذف می‌کند.
اگر با \f[B]\-f\f[R] ترکیب شود، ایمیج‌های حافظهٔ پنهان ساخت افزایشی و درخت ابزارها (tools tree) را نیز حذف می‌کند.
اگر \f[B]\-f\f[R] دو بار مشخص شود، هرگونه حافظهٔ پنهان بسته‌ها را نیز حذف می‌کند.
.TP
\f[B]serve\f[R]
این دستور اگر ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس دایرکتوری خروجی (یعنی معمولاً \f[B]mkosi.output/\f[R]، پایین‌تر را ببینید) را از طریق یک سرور HTTP توکار کوچک که روی درگاه ۸۰۸۱ شنود می‌کند، ارائه می‌دهد.
برای بازسازی بدون قید و شرط ایمیج پیش از ارائهٔ آن، این دستور را با \f[B]\-f\f[R] ترکیب کنید.
این دستور برای آزمایش دریافت تحت شبکهٔ ایمیج‌های سیستم‌عامل، به عنوان مثال از طریق \f[B]machinectl pull\-raw \&...\f[R] و \f[B]machinectl pull\-tar \&...\f[R] مفید است.
.TP
\f[B]burn <device>\f[R]
این دستور اگر ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس آن را در دستگاه بلوکی مشخص‌شده می‌نویسد.
محتویات پارتیشن‌ها همان‌گونه که هستند نوشته می‌شوند، اما جدول پارتیشن GPT اصلاح می‌شود تا با اندازهٔ دیسک و سکتورهای رسانهٔ مشخص‌شده مطابقت یابد.
.TP
\f[B]bump\f[R]
نسخهٔ ایمیج را از \f[B]mkosi.version\f[R] افزایش می‌دهد و رشتهٔ نسخهٔ حاصل را در \f[B]mkosi.version\f[R] می‌نویسد.
این دستور برای پیاده‌سازی یک طرح نسخه‌بندی ساده مفید است: هر بار که این فعل فراخوانی می‌شود، نسخه در آمادگی برای ساخت بعدی افزایش می‌یابد.
توجه داشته باشید که می‌توان از \f[B]\-\-auto\-bump\f[R]/\f[B]\-B\f[R] برای افزایش خودکار نسخه به عنوان بخشی از فرایند ساخت استفاده کرد.
در این حالت، نسخهٔ جدید تنها در صورتی در \f[B]mkosi.version\f[R] نوشته می‌شود که ساخت موفقیت‌آمیز باشد.
.RS
اگر \f[B]mkosi.bump\f[R] وجود داشته باشد، به جای استفاده از منطق درونی mkosi، برای تولید نسخهٔ جدید فراخوانی می‌شود.
.RE
.TP
\f[B]genkey\f[R]
یک جفت کلید SecureBoot برای استفاده با گزینه‌های \f[B]SecureBootKey=\f[R]/\f[B]\-\-secure\-boot\-key=\f[R] و \f[B]SecureBootCertificate=\f[R]/\f[B]\-\-secure\-boot\-certificate=\f[R] تولید می‌کند.
.TP
\f[B]documentation\f[R]
مستندات \f[B]mkosi\f[R] را نمایش می‌دهد.
اگر هیچ آرگومانی داده نشود، صفحهٔ man مربوط به \f[B]mkosi\f[R] نمایش داده می‌شود، اما آرگومان‌های \f[B]mkosi\f[R]، \f[B]mkosi\-initrd\f[R]، \f[B]initrd\f[R]، \f[B]mkosi\-sandbox\f[R]، \f[B]sandbox\f[R]، \f[B]mkosi.news\f[R] و \f[B]news\f[R] نیز پشتیبانی می‌شوند و به ترتیب صفحات man مربوط به \f[B]mkosi\f[R]، \f[B]mkosi\-initrd\f[R]، \f[B]mkosi\-sandbox\f[R] و فایل NEWS مربوط به \f[B]mkosi\f[R] را نمایش می‌دهند.
.RS
به‌طور پیش‌فرض این فعل چندین روش را برای خروجی دادن مستندات امتحان می‌کند، اما می‌توان با گزینهٔ \f[B]\-\-doc\-format\f[R] گزینهٔ خاصی را انتخاب کرد.
به بسته‌بندهای توزیع‌ها توصیه می‌شود در صورت موجود نبودن فایل \f[B]mkosi.1\f[R]، آن را به دایرکتوری \f[B]mkosi/resources\f[R] بستهٔ Python اضافه کنند و همچنین آن را در مسیر جستجوی مناسب برای صفحات man نصب نمایند.
صفحهٔ man را می‌توان از فایل Markdown در \f[B]mkosi/resources/man/mkosi.1.md\f[R] تولید کرد، مثلاً از طریق \f[B]pandoc \-t man \-s \-o mkosi.1 mkosi.1.md\f[R].
.RE
.TP
\f[B]completion\f[R]
تکمیل خودکار شل را برای پوسته‌ای که به عنوان آرگومان داده شده تولید کرده و در stdout چاپ می‌کند.
آرگومان‌های \f[B]bash\f[R]، \f[B]fish\f[R] و \f[B]zsh\f[R] پشتیبانی می‌شوند.
.TP
\f[B]dependencies\f[R]
فهرست بسته‌های مورد نیاز \f[B]mkosi\f[R] را برای ساخت و بوت کردن ایمیج‌ها خروجی می‌دهد.
.RS
این فهرست را می‌توان مستقیماً با لوله‌کشی (pipe) به یک مدیر بسته هدایت کرد تا بسته‌ها را نصب کند.
برای مثال، اگر سیستم میزبان از مدیر بستهٔ \f[B]dnf\f[R] استفاده می‌کند، بسته‌ها را می‌توان به روش زیر نصب کرد:
.IP
.EX
mkosi dependencies \f[B]|\f[R] xargs \-d \(aq\(rsn\(aq dnf install
.EE
به‌طور پیش‌فرض، تنها وابستگی‌های مورد نیاز برای ساخت ایمیج‌ها با mkosi نمایش داده می‌شوند.
پروفایل‌های درخت ابزارهای اضافی را می‌توان فعال کرد تا بسته‌های متعلق به آن پروفایل‌ها را نیز خروجی دهد.
به عنوان مثال، اجرای \f[B]mkosi dependencies \-\- \-\-profile runtime\f[R] علاوه بر بسته‌های معمولی، بسته‌های موجود در پروفایل runtime را نیز نمایش می‌دهد.
برای مشاهدهٔ فهرستی از پروفایل‌های موجود، مستندات مربوط به \f[B]ToolsTreeProfiles=\f[R] را ببینید.
.RE
.TP
\f[B]latest\-snapshot\f[R]
جدیدترین اسنپ‌شات موجود در آینهٔ (mirror) پیکربندی‌شده را نمایش می‌دهد.
.RS
این فعل برای افزایش خودکار اسنپ‌شات‌ها در فواصل زمانی منظم مفید است.
توجه داشته باشید که این فعل فقط جدیدترین اسنپ‌شات را در خروجی می‌آورد.
اطمینان از نوشته شدن اسنپ‌شات در فایل پیکربندی مورد نظر بر عهدهٔ فراخواننده است.
.RE
.TP
\f[B]help\f[R]
این فعل معادل سوئیچ \f[B]\-\-help\f[R] است که در ادامه توضیح داده شده است: توضیح مختصری از نحوهٔ استفاده را نشان می‌دهد.
.SS "گزینه‌های فقط خط فرمان (Command-Line-Only Options)"
این تنظیمات را نمی‌توان در فایل‌های پیکربندی تعیین کرد.
.TP
\f[B]\-\-force\f[R], \f[B]\-f\f[R]
هنگام ساخت یک ایمیج، در صورتی که فایل خروجی از قبل وجود داشته باشد، آن را جایگزین می‌کند.
به‌طور پیش‌فرض هنگام ساخت یک ایمیج، اگر یک مصنوع خروجی از قبل موجود باشد، \f[B]mkosi\f[R] از انجام عملیات خودداری خواهد کرد.
این گزینه را یک بار مشخص کنید تا تمام مصنوعات ساخت یک اجرای قبلی، پیش از ساخت مجدد ایمیج حذف شوند.
اگر ساخت‌های افزایشی فعال باشند، مشخص کردن دو بارهٔ این گزینه تضمین می‌کند که فایل‌های حافظهٔ پنهان میانی نیز قبل از شروع ساخت مجدد حذف شوند.
اگر از حافظهٔ پنهان بسته استفاده می‌شود (همچنین بخش \f[B]فایل‌ها (FILES)\f[R] را در زیر ببینید)، مشخص کردن سه بارهٔ این گزینه تضمین می‌کند که حافظهٔ پنهان بسته‌ها نیز قبل از آغاز ساخت مجدد حذف شود.
برای عملیات \f[B]clean\f[R] این گزینه تأثیر اندکی متفاوت دارد: به‌طور پیش‌فرض این فعل فقط مصنوعات ساخت اجرای قبلی را حذف می‌کند، هنگامی که یک بار مشخص شود فایل‌های حافظهٔ پنهان افزایشی و درخت ابزارها نیز حذف می‌شوند، و هنگامی که دو بار مشخص شود حافظهٔ پنهان بسته‌ها نیز حذف خواهد شد.
.TP
\f[B]\-\-directory=\f[R], \f[B]\-C\f[R]
مسیری به یک دایرکتوری را می‌گیرد.
\f[B]mkosi\f[R] پیش از انجام هر کاری به این دایرکتوری تغییر مکان می‌دهد.
توجه داشته باشید که فایل‌های پیکربندی مختلف در این دایرکتوری جستجو می‌شوند، بنابراین استفاده از این گزینه روشی مؤثر برای ساخت پروژه‌ای است که در یک دایرکتوری خاص قرار دارد.
پیش‌فرض آن دایرکتوری کاری فعلی است.
اگر یک رشتهٔ خالی مشخص شود، تمام پیکربندی‌های موجود در دایرکتوری کاری فعلی نادیده گرفته می‌شوند.
.TP
\f[B]\-\-debug\f[R]
خروجی اشکال‌زدایی اضافی را فعال می‌کند.
.TP
\f[B]\-\-debug\-shell\f[R]
هنگامی که اجرای یک دستور در ایمیج با شکست مواجه می‌شود، \f[B]mkosi\f[R] یک پوستهٔ تعاملی را درون ایمیج اجرا می‌کند تا امکان اشکال‌زدایی بیشتر فراهم شود.
.TP
\f[B]\-\-debug\-workspace\f[R]
در صورت تعیین، دایرکتوری فضای کاری (workspace) حذف نخواهد شد و مکان آن هنگام خروج \f[B]mkosi\f[R] در لاگ ثبت می‌شود.
.TP
\f[B]\-\-debug\-sandbox\f[R]
\f[B]mkosi\-sandbox\f[R] را با \f[B]strace\f[R] اجرا می‌کند.
.TP
\f[B]\-\-debug\-timing\f[R]
مدت‌زمان هر مرحله از ساخت را ثبت می‌کند.
.TP
\f[B]\-\-version\f[R]
نسخهٔ بسته را نشان می‌دهد.
.TP
\f[B]\-\-help\f[R], \f[B]\-h\f[R]
اطلاعات مختصری دربارهٔ نحوهٔ استفاده را نمایش می‌دهد.
.TP
\f[B]\-\-genkey\-common\-name=\f[R]
نام مشترک (Common Name) که هنگام تولید کلیدها از طریق دستور \f[B]genkey\f[R] در \f[B]mkosi\f[R] استفاده می‌شود.
پیش‌فرض \f[B]mkosi of %u\f[R] است، که در آن \f[B]%u\f[R] به نام کاربری کاربری که \f[B]mkosi\f[R] را فراخوانی می‌کند گسترش می‌یابد.
.TP
\f[B]\-\-genkey\-valid\-days=\f[R]
تعداد روزهایی که کلیدها هنگام تولید از طریق دستور \f[B]genkey\f[R] در \f[B]mkosi\f[R] باید معتبر بمانند.
پیش‌فرض دو سال (۷۳۰ روز) است.
.TP
\f[B]\-\-auto\-bump=\f[R], \f[B]\-B\f[R]
در صورت مشخص شدن، نسخه افزایش می‌یابد و در صورت موفقیت‌آمیز بودن ساخت، نسخه به روشی معادل فعل \f[B]bump\f[R] در \f[B]mkosi.version\f[R] نوشته می‌شود.
این گزینه برای مدیریت نسخهٔ خطی و ساده مفید است: هر ساخت در یک توالی، شماره نسخه‌ای یک واحد بالاتر از نسخهٔ قبلی خواهد داشت.
.RS
اگر \f[B]mkosi.bump\f[R] وجود داشته باشد، به جای استفاده از منطق درونی mkosi، برای تولید نسخهٔ جدید فراخوانی می‌شود.
.RE
.TP
\f[B]\-\-doc\-format\f[R]
قالبی که مستندات در آن نمایش داده می‌شوند.
از مقادیر \f[B]markdown\f[R]، \f[B]man\f[R]، \f[B]pandoc\f[R]، \f[B]system\f[R] و \f[B]auto\f[R] پشتیبانی می‌کند.
در صورت استفاده از \f[B]markdown\f[R]، مستندات در قالب اصلی Markdown نشان داده می‌شوند.
\f[B]man\f[R] در صورت موجود بودن، مستندات را در قالب صفحهٔ man نمایش می‌دهد.
\f[B]pandoc\f[R] در صورت در دسترس بودن، قالب صفحهٔ man را بلافاصله تولید خواهد کرد.
\f[B]system\f[R] صفحهٔ man سراسری سیستم را برای \f[B]mkosi\f[R] نشان می‌دهد، که بسته به نحوهٔ نصب \f[B]mkosi\f[R]، ممکن است با نسخه‌ای که استفاده می‌کنید مطابقت داشته باشد یا خیر.
\f[B]auto\f[R] که حالت پیش‌فرض است، تمام روش‌ها را به ترتیب \f[B]man\f[R]، \f[B]pandoc\f[R]، \f[B]markdown\f[R] و \f[B]system\f[R] امتحان خواهد کرد.
.TP
\f[B]\-\-json\f[R]
خروجی خلاصه را به صورت JSON\-SEQ نمایش می‌دهد..TP
\f[B]\-\-wipe\-build\-dir\f[R], \f[B]\-w\f[R]
پاک کردن دایرکتوری ساخت پیش از ساخت ایمیج، در صورتی که دایرکتوری‌ای پیکربندی شده باشد.
.TP
\f[B]\-\-rerun\-build\-scripts\f[R], \f[B]\-R\f[R]
اجرای دوبارهٔ اسکریپت‌های ساخت.
نیازمند این است که گزینهٔ \f[B]Incremental=\f[R] فعال باشد و ایمیج پیش‌تر یک‌بار ساخته شده باشد.
اگر \f[B]History=\f[R] فعال باشد، تاریخچهٔ ساخت قبلی مجدداً استفاده خواهد شد و تاریخچهٔ جدیدی نوشته نمی‌شود.
.SS قالب‌های خروجی پشتیبانی‌شده (Supported output formats)
قالب‌های خروجی زیر پشتیبانی می‌شوند:
.IP \(bu 2
ایمیج دیسک خام \f[I]GPT\f[R]، ایجادشده با استفاده از \f[B]systemd\-repart\f[R]
(\f[I]disk\f[R])
.IP \(bu 2
دایرکتوری ساده، شامل درخت سیستم‌عامل (\f[I]directory\f[R])
.IP \(bu 2
بایگانی Tar (\f[I]tar\f[R])
.IP \(bu 2
بایگانی CPIO (\f[I]cpio\f[R])
.IP \(bu 2
ایمیج یکپارچهٔ هسته یا Unified Kernel Image (\f[I]UKI\f[R])
.IP \(bu 2
\&...
و موارد بسیار بیشتر.
مستندات \f[B]Format=\f[R] در ادامه را ببینید.
.PP
قالب خروجی می‌تواند روی \f[I]none\f[R] نیز تنظیم شود تا \f[B]mkosi\f[R] هیچ ایمیجی تولید نکند.
این حالت در صورتی مفید است که تنها بخواهید از ایمیج برای تولید یک خروجی دیگر در اسکریپت‌های ساخت استفاده کنید (برای نمونه، ساخت یک RPM).
.PP
هنگامی که یک ایمیج دیسک \f[I]GPT\f[R] ایجاد می‌شود، می‌توان فایل‌های تعریف پارتیشن repart را در \f[B]mkosi.repart/\f[R] قرار داد تا ایمیج دیسک تولیدشده را پیکربندی کرد.
.PP
اکیداً توصیه می‌شود \f[B]mkosi\f[R] را روی یک سیستم‌فایل اجرا کنید که از reflinkها پشتیبانی می‌کند (مانند XFS و btrfs) و همهٔ دایرکتوری‌های مرتبط را روی همان سیستم‌فایل نگه دارید.
این کار به \f[B]mkosi\f[R] اجازه می‌دهد با استفاده از reflinkها برای انجام کپی از طریق عملیات‌های رونوشت هنگام نوشتن (copy\-on\-write)، ایمیج‌ها را بسیار سریع ایجاد کند.
.SS تنظیمات پیکربندی (Configuration Settings)
تنظیمات زیر را می‌توان از طریق فایل‌های پیکربندی (نحو با \f[B]SomeSetting=value\f[R]) و در خط فرمان (نحو با \f[B]\-\-some\-setting=value\f[R]) مشخص کرد.
برای برخی از پارامترهای خط فرمان، میانبر تک‌حرفی نیز مجاز است.
در فایل‌های پیکربندی، تنظیم باید در بخش مناسب قرار گیرد، از این رو تنظیمات زیر بر اساس بخش گروه‌بندی شده‌اند.
.PP
پیکربندی به ترتیب زیر تجزیه می‌شود:
.IP \(bu 2
آرگومان‌های خط فرمان تجزیه می‌شوند.
.IP \(bu 2
\f[B]mkosi.local.conf\f[R] و \f[B]mkosi.local/\f[R] در صورت وجود تجزیه می‌شوند (به همین ترتیب).
این فایل و دایرکتوری باید در \f[B].gitignore\f[R] (یا معادل آن) قرار گیرند و برای پیکربندی محلی در نظر گرفته شده‌اند.
.IP \(bu 2
اگر گزینه‌ای دارای یک مسیر پیش‌فرض متناظر باشد، در صورت وجود آن مسیر پیش‌فرض، تجزیه می‌شود.
.IP \(bu 2
\f[B]mkosi.conf\f[R] در صورت وجود در دایرکتوریِ پیکربندی‌شده با \f[B]\-\-directory=\f[R] تجزیه می‌شود؛ یا اگر از \f[B]\-\-directory=\f[R] استفاده نشود، در دایرکتوری کاری جاری.
اگر دایرکتوری مشخص‌شده شامل \f[B]mkosi.conf\f[R] یا \f[B]mkosi.tools.conf\f[R] نباشد و \f[B]mkosi/mkosi.conf\f[R] یا \f[B]mkosi/mkosi.tools.conf\f[R] وجود داشته باشد، پیکربندی به‌جای آن از زیردایرکتوری \f[B]mkosi/\f[R] در دایرکتوری مشخص‌شده تجزیه خواهد شد.
.IP \(bu 2
\f[B]mkosi.conf.d/\f[R] در صورت وجود، در همان دایرکتوریِ \f[B]mkosi.conf\f[R] تجزیه می‌شود.
هر دایرکتوری و هر فایل با پسوند \f[B].conf\f[R] در \f[B]mkosi.conf.d/\f[R] تجزیه می‌شود.
هر دایرکتوری درون \f[B]mkosi.conf.d\f[R] به گونه‌ای تجزیه می‌شود که گویی یک دایرکتوری سطح بالای عادی است، به‌جز \f[B]mkosi.images/\f[R]، \f[B]mkosi.tools.conf\f[R] و \f[B]mkosi.initrd.conf\f[R] که تنها در دایرکتوری سطح بالا دریافت می‌شوند.
.IP \(bu 2
اگر هر پروفایلی پیکربندی شده باشد، پیکربندی آن‌ها از دایرکتوری \f[B]mkosi.profiles/\f[R] تجزیه می‌شود.
.IP \(bu 2
زیرایمیج‌ها در صورت وجود، از دایرکتوری \f[B]mkosi.images/\f[R] تجزیه می‌شوند.
.PP
توجه داشته باشید که تنظیمات پیکربندی‌شده از طریق خط فرمان همواره تنظیمات مشخص‌شده از طریق فایل‌های پیکربندی را بازنویسی می‌کنند.
اگر یک تنظیم، بیش از یک‌بار از طریق فایل‌های پیکربندی تعیین شده باشد، انتساب‌های بعدی انتساب‌های قبلی را بازنویسی می‌کنند، مگر برای تنظیماتی که مجموعه‌ای از مقادیر را می‌پذیرند.
همچنین، تنظیمات خوانده‌شده از \f[B]mkosi.local.conf\f[R] یا \f[B]mkosi.local/\f[R]، تنظیمات فایل‌های پیکربندی که بعداً تجزیه می‌شوند را بازنویسی خواهند کرد، اما تنظیمات مشخص‌شده در خط فرمان را بازنویسی نمی‌کنند.
.PP
برای تنظیماتی که یک مقدار واحد را می‌پذیرند، انتساب خالی (\f[B]SomeSetting=\f[R] یا \f[B]\-\-some\-setting=\f[R]) می‌تواند برای بازنویسی تنظیم قبلی و بازنشانی آن به مقدار پیش‌فرض استفاده شود.
.PP
تنظیماتی که مجموعه‌ای از مقادیر را می‌پذیرند، با افزودن مقادیر جدید به انتهای مقادیر قبلاً پیکربندی‌شده، ادغام می‌شوند.
انتساب یک رشتهٔ خالی به چنین تنظیمی، همهٔ مقادیر قبلاً انتساب‌داده‌شده را حذف کرده و هر مقدار پیش‌فرض پیکربندی‌شده را نیز بازنویسی می‌کند.
مقادیر مشخص‌شده در خط فرمان، پس از همهٔ مقادیر فایل‌های پیکربندی به انتها افزوده می‌شوند.
.PP
برای گنجاندن شرطیِ فایل‌های پیکربندی، بخش \f[B][Match]\f[R] می‌تواند استفاده شود.
یک بخش \f[B][Match]\f[R] از شرایط منفرد تشکیل شده است.
شرایط می‌توانند از یک نویسهٔ پایپ (\f[B]|\f[R]) پس از علامت مساوی (\f[B]\&...=|\&...\f[R]) استفاده کنند که باعث می‌شود آن شرط به یک شرط راه‌انداز تبدیل شود.
فایل پیکربندی در صورتی گنجانده می‌شود که «و»ی منطقی (AND) تمام شرایط غیرراه‌انداز و «یا»ی منطقی (OR) تمام شرایط راه‌انداز برقرار باشد.
برای نقیض کردن نتیجهٔ یک شرط، قبل از آرگومان یک علامت تعجب قرار دهید.
اگر آرگومانی با نویسهٔ پایپ و علامت تعجب شروع شود، ابتدا باید پایپ و سپس علامت تعجب درج گردد.
.PP
توجه داشته باشید که شرایط \f[B][Match]\f[R] با مقادیر جاریِ تنظیمات خاص مقایسه می‌شوند و تغییرات اعمال‌شده بر آن تنظیم در فایل‌های پیکربندی که هنوز تجزیه نشده‌اند را در نظر نمی‌گیرند (تنظیمات مشخص‌شده در خط فرمان لحاظ می‌شوند).
همچنین دقت کنید که تطبیق دادن با یک تنظیم و سپس تغییر مقدار آن در یک فایل پیکربندی دیگر ممکن است به نتایج غیرمنتظره منجر شود.
.PP
بخش \f[B][Match]\f[R] یک فایل \f[B]mkosi.conf\f[R] درون یک دایرکتوری به کل آن دایرکتوری اعمال می‌شود.
اگر شرایط برآورده نشوند، کل دایرکتوری نادیده گرفته می‌شود.
بخش‌های \f[B][Match]\f[R] فایل‌های موجود در \f[B]mkosi.conf.d/\f[R] و \f[B]mkosi.local.conf\f[R] تنها برای خود آن فایل اعمال می‌شوند.
.PP
اگر چندین بخش \f[B][Match]\f[R] در یک فایل پیکربندی یکسان وجود داشته باشد، تک‌تک آن‌ها باید برقرار باشند تا فایل پیکربندی گنجانده شود.
به‌ویژه، شرایط راه‌انداز تنها برای بخش \f[B][Match]\f[R] جاری اعمال شده و بین بخش‌های مختلف \f[B][Match]\f[R] بازنشانی می‌شوند.
به عنوان مثال، قطعه‌کد زیر تنها در صورتی مطابقت دارد که قالب خروجی یکی از \f[B]disk\f[R] یا \f[B]directory\f[R] بوده و معماری نیز یکی از \f[B]x86\-64\f[R] یا \f[B]arm64\f[R] باشد:
.IP
.EX
\f[B][Match]\f[R]
Format=|disk
Format=|directory

\f[B][Match]\f[R]
Architecture=|x86\-64
Architecture=|arm64
.EE
.PP
بخش \f[B][TriggerMatch]\f[R] می‌تواند برای نشان دادن مطابقت‌های راه‌انداز استفاده شود.
این بخش‌ها مشابه شرایط راه‌انداز در واحدهای systemd هستند، با این تفاوت که به جای یک شرط منفرد، به کل بخش تطبیق اعمال می‌شوند.
به عنوان مثال، قطعه‌کد زیر در صورتی تطبیق می‌یابد که توزیع \f[B]debian\f[R] و انتشار \f[B]bookworm\f[R] باشد، یا توزیع \f[B]ubuntu\f[R] و انتشار \f[B]noble\f[R] باشد:
.IP
.EX
\f[B][TriggerMatch]\f[R]
Distribution=debian
Release=bookworm

\f[B][TriggerMatch]\f[R]
Distribution=ubuntu
Release=noble
.EE
.PP
معناشناسی شرایط در بخش‌های \f[B][TriggerMatch]\f[R] مشابه با \f[B][Match]\f[R] است؛ بدین معنی که تمام شرایط عادی با یک «و»ی منطقی و تمام شرایط راه‌انداز با یک «یا»ی منطقی به یکدیگر متصل می‌شوند.
هنگام ترکیب بخش‌های \f[B][Match]\f[R] و \f[B][TriggerMatch]\f[R]، تطبیق در صورتی حاصل می‌شود که تمام بخش‌های \f[B][Match]\f[R] برقرار باشند و دست‌کم یکی از بخش‌های \f[B][TriggerMatch]\f[R] تطبیق یابد.
نبود بخش‌های تطبیق، برابر با درست (true) در نظر گرفته می‌شود.
از نظر منطقی این یعنی:
.IP
.EX
(⋀ᵢ Matchᵢ) ∧ (⋁ᵢ TriggerMatchᵢ)
.EE
.PP
همچنین پشتیبانی از بخش‌های \f[B][Assert]\f[R] و \f[B][TriggerAssert]\f[R] وجود دارد که رفتاری مشابه بخش‌های تطبیق دارند، با این تفاوت که در صورت برقرار نبودن بخش‌های assert، تجزیهٔ پیکربندی شکست خواهد خورد؛ یعنی تمام بخش‌های \f[B][Assert]\f[R] در یک فایل و همچنین دست‌کم یک بخش \f[B][TriggertAssert]\f[R] باید برآورده شوند، وگرنه تجزیهٔ پیکربندی با شکست مواجه می‌شود.
.PP
گزینه‌های خط فرمان که هیچ آرگومانی نمی‌پذیرند، در نسخهٔ بلند خود بدون \f[B]=\f[R] نشان داده شده‌اند.
در فایل‌های پیکربندی، این گزینه‌ها باید با یک آرگومان بولی مشخص شوند:
یا \f[B]1\f[R]، \f[B]yes\f[R]، یا \f[B]true\f[R] برای فعال‌سازی، یا \f[B]0\f[R]، \f[B]no\f[R]، \f[B]false\f[R] برای غیرفعال‌سازی..SS بخش [Distribution]
.TP
\f[B]Distribution=\f[R], \f[B]\-\-distribution=\f[R], \f[B]\-d\f[R]
توزیعی که باید در ایمیج نصب شود.
یکی از این آرگومان‌ها را می‌پذیرد: \f[B]fedora\f[R]،
\f[B]debian\f[R]، \f[B]kali\f[R]، \f[B]ubuntu\f[R]، \f[B]arch\f[R]،
\f[B]opensuse\f[R]، \f[B]mageia\f[R]، \f[B]centos\f[R]، \f[B]rhel\f[R]،
\f[B]rhel\-ubi\f[R]، \f[B]openmandriva\f[R]، \f[B]rocky\f[R]،
\f[B]alma\f[R]، \f[B]azure\f[R] یا \f[B]custom\f[R].
در صورت مشخص نشدن، به توزیع میزبان پیش‌فرض می‌شود، یا به \f[B]custom\f[R] اگر توزیع میزبان توزیع پشتیبانی‌شده‌ای نباشد.
.TP
\f[B]Release=\f[R], \f[B]\-\-release=\f[R], \f[B]\-r\f[R]
انتشار توزیع برای نصب در ایمیج.
نحو دقیق آرگومانی که این گزینه می‌پذیرد به توزیع مورد استفاده بستگی دارد، و یا یک رشته عددی است (در مورد Fedora
Linux، CentOS و غیره، برای مثال \f[B]29\f[R])، یا یک نام نسخهٔ توزیع (در مورد Debian، Kali، Ubuntu و غیره، برای مثال \f[B]artful\f[R]).
پیش‌فرض آن نسخهٔ جدیدی از توزیع انتخاب‌شده است، یا نسخهٔ توزیع در حال اجرا روی میزبان در صورتی که با توزیع پیکربندی‌شده مطابقت داشته باشد.
.TP
\f[B]Architecture=\f[R], \f[B]\-\-architecture=\f[R]
معماری‌ای که ایمیج برای آن ساخته می‌شود.
معماری‌هایی که عملاً پشتیبانی می‌شوند به توزیع مورد استفاده و اینکه آیا ایمیج قابل بوت درخواست شده است یا خیر بستگی دارد.
هنگام ساخت برای یک معماری بیگانه (foreign architecture)، لازم است یک شبیه‌ساز حالت کاربر (user mode emulator) را نیز برای آن معماری نصب و ثبت کنید.
.RS
به‌ازای هر ایمیج ساخته‌شده می‌توان یکی از معماری‌های زیر را مشخص کرد:
\f[B]alpha\f[R]، \f[B]arc\f[R]، \f[B]arm\f[R]، \f[B]arm64\f[R]،
\f[B]ia64\f[R]، \f[B]loongarch64\f[R]، \f[B]mips64\-le\f[R]،
\f[B]mips\-le\f[R]، \f[B]parisc\f[R]، \f[B]ppc\f[R]، \f[B]ppc64\f[R]،
\f[B]ppc64\-le\f[R]، \f[B]riscv32\f[R]، \f[B]riscv64\f[R]،
\f[B]s390\f[R]، \f[B]s390x\f[R]، \f[B]tilegx\f[R]، \f[B]x86\f[R]،
\f[B]x86\-64\f[R].
.RE
.TP
\f[B]Mirror=\f[R], \f[B]\-\-mirror=\f[R], \f[B]\-m\f[R]
مخزن آینه‌ای (mirror) مورد استفاده برای بارگیری بسته‌های توزیع.
یک URL آینه را به عنوان آرگومان می‌پذیرد.
در صورت ارائه نشدن، آینهٔ پیش‌فرض برای آن توزیع استفاده می‌شود.
.RS
آینه‌های پیش‌فرض برای هر توزیع به شرح زیر است (مگر اینکه مشخص شده باشد، همان آینه برای همه معماری‌ها استفاده می‌شود):
.PP
.TS
tab(@);
lw(13.3n) lw(30.0n) lw(26.7n).
T{
T}@T{
x86\-64
T}@T{
aarch64
T}
_
T{
\f[B]debian\f[R]
T}@T{
http://deb.debian.org
T}@T{
T}
T{
\f[B]arch\f[R]
T}@T{
https://fastly.mirror.pkgbuild.com
T}@T{
http://mirror.archlinuxarm.org
T}
T{
\f[B]opensuse\f[R]
T}@T{
http://download.opensuse.org
T}@T{
T}
T{
\f[B]kali\f[R]
T}@T{
http://http.kali.org/kali
T}@T{
T}
T{
\f[B]ubuntu\f[R]
T}@T{
http://archive.ubuntu.com
T}@T{
http://ports.ubuntu.com
T}
T{
\f[B]centos\f[R]
T}@T{
https://mirrors.centos.org
T}@T{
T}
T{
\f[B]rocky\f[R]
T}@T{
https://mirrors.rockylinux.org
T}@T{
T}
T{
\f[B]alma\f[R]
T}@T{
https://mirrors.almalinux.org
T}@T{
T}
T{
\f[B]fedora\f[R]
T}@T{
https://mirrors.fedoraproject.org
T}@T{
T}
T{
\f[B]rhel\-ubi\f[R]
T}@T{
https://cdn\-ubi.redhat.com
T}@T{
T}
T{
\f[B]mageia\f[R]
T}@T{
https://www.mageia.org
T}@T{
T}
T{
\f[B]openmandriva\f[R]
T}@T{
http://mirrors.openmandriva.org
T}@T{
T}
T{
\f[B]azure\f[R]
T}@T{
https://packages.microsoft.com
T}@T{
T}
.TE
.RE
.TP
\f[B]Snapshot=\f[R]
بارگیری بسته‌ها از تصویر لحظه‌ای (snapshot) مشخص‌شده به‌جای بارگیری جدیدترین بسته‌های توزیع از آینهٔ داده‌شده.
یک شناسهٔ snapshot را می‌پذیرد (قالب شناسهٔ snapshot در هر توزیع متفاوت است)، از فعل \f[B]latest\-snapshot\f[R] برای یافتن آخرین snapshot موجود استفاده کنید.
.RS
اگر این تنظیم پیکربندی شده باشد و \f[B]Mirror=\f[R] صریحاً تعیین نشده باشد، آینه‌های پیش‌فرض متفاوتی استفاده می‌شوند:
.PP
.TS
tab(@);
lw(13.3n) lw(30.0n) lw(26.7n).
T{
T}@T{
x86\-64
T}@T{
aarch64
T}
_
T{
\f[B]debian\f[R]
T}@T{
https://snapshot.debian.org
T}@T{
T}
T{
\f[B]arch\f[R]
T}@T{
https://archive.archlinux.org
T}@T{
http://mirror.archlinuxarm.org
T}
T{
\f[B]opensuse\f[R]
T}@T{
http://download.opensuse.org
T}@T{
T}
T{
\f[B]ubuntu\f[R]
T}@T{
http://archive.ubuntu.com
T}@T{
http://ports.ubuntu.com
T}
T{
\f[B]centos\f[R]
T}@T{
https://composes.stream.centos.org
T}@T{
T}
T{
\f[B]fedora\f[R]
T}@T{
https://kojipkgs.fedoraproject.org
T}@T{
T}
.TE
برای هر توزیعی که در بالا فهرست نشده باشد، snapshotها پشتیبانی نمی‌شوند.
توجه داشته باشید که این تنظیم بر درخت ابزارهای پیش‌فرض اعمال نمی‌شود؛ برای آن از \f[B]ToolsTreeSnapshot=\f[R] استفاده کنید.
.RE.TP
\f[B]LocalMirror=\f[R], \f[B]\-\-local\-mirror=\f[R]
این آینه به عنوان یک آینه محلی، ساده و مستقیم استفاده خواهد شد، به جای آنکه
به عنوان پیشوندی برای مجموعه کامل مخازنی که معمولاً توسط توزیع‌ها پشتیبانی
می‌شوند به کار رود.
برای ساخت‌های کاملاً آفلاین با یک مخزن واحد مفید است.
در توزیع‌های مبتنی بر \f[B]deb\f[R]، \f[B]rpm\f[R] و \f[B]pacman\f[R]
پشتیبانی می‌شود.
این گزینه مقدار \f[B]\-\-mirror=\f[R] را بازنویسی می‌کند، اما فقط برای ساخت
محلی \f[B]mkosi\f[R]؛ این گزینه درون تصویر نهایی پیکربندی نخواهد شد و به جای
آن، \f[B]\-\-mirror=\f[R] (یا مخزن پیش‌فرض) در تصویر نهایی پیکربندی می‌شود.
.TP
\f[B]RepositoryKeyCheck=\f[R], \f[B]\-\-repository\-key\-check=\f[R]
بررسی‌های امضا/کلید را هنگام استفاده از مخازن کنترل می‌کند؛ به صورت پیش‌فرض
فعال است.
برای غیرفعال کردن بررسی‌ها در صورت ترکیب با \f[B]\-\-local\-mirror=\f[R]
و استفادهٔ صرف از یک مخزن از سیستم‌فایل محلی مفید است.
.TP
\f[B]RepositoryKeyFetch=\f[R], \f[B]\-\-repository\-key\-fetch=\f[R]
کنترل می‌کند که آیا \f[B]mkosi\f[R] کلیدهای GPG توزیع را از راه دور دریافت کند یا خیر.
به صورت پیش‌فرض در Ubuntu هنگام عدم استفاده از درخت ابزارها یا هنگام استفاده از
درخت‌های ابزار Ubuntu برای ساخت Arch Linux یا توزیع‌های مبتنی بر RPM فعال است.
به صورت پیش‌فرض در تمام توزیع‌های دیگر غیرفعال است.
هنگام غیرفعال بودن، کلیدهای GPG توزیع برای توزیع مقصد باید به صورت محلی در سیستم
میزبان در کنار مدیر بستهٔ آن توزیع نصب شده باشند.
.RS
این تنظیم تنها برای توزیع‌هایی پیاده‌سازی شده است که از \f[B]dnf\f[R]،
\f[B]pacman\f[R] یا \f[B]zypper\f[R] به عنوان مدیر بستهٔ خود استفاده می‌کنند.
برای سایر توزیع‌ها، کلیدهای GPG توزیع صرف‌نظر از مقدار این تنظیم همیشه
به صورت محلی جستجو می‌شوند.
برای دردسترس قرار دادن کلیدهای GPG توزیع‌ها بدون فعال‌سازی این تنظیم،
بستهٔ مربوطه باید روی سیستم میزبان نصب شود.
این بسته معمولاً یکی از بسته‌های \f[B]archlinux\-keyring\f[R]،
\f[B]debian\-keyring\f[R]، \f[B]kali\-archive\-keyring\f[R]،
\f[B]ubuntu\-keyring\f[R] یا \f[B]distribution\-gpg\-keys\f[R] (برای
توزیع‌های مبتنی بر RPM) است.
.RE
.TP
\f[B]Repositories=\f[R], \f[B]\-\-repositories=\f[R]
مخازن بسته‌ای را که به صورت پیش‌فرض غیرفعال هستند، فعال می‌کند.
از این گزینه می‌توان برای فعال‌سازی مخازن EPEL برای CentOS یا مؤلفه‌های
مختلف مخازن Debian/Kali/Ubuntu استفاده کرد.
.SS بخش [Output] ([Output] Section)
.TP
\f[B]Format=\f[R], \f[B]\-\-format=\f[R], \f[B]\-t\f[R]
نوع قالب تصویر برای تولید.
یکی از مقادیر \f[B]directory\f[R] (برای تولید مستقیم تصویر سیستم‌عامل در یک
پوشهٔ محلی)، \f[B]tar\f[R] (مشابه، اما یک بایگانی tarball از تصویر سیستم‌عامل
تولید می‌شود)، \f[B]cpio\f[R] (مشابه، اما یک بایگانی cpio تولید می‌شود)،
\f[B]disk\f[R] (یک تصویر سیستم‌عامل از نوع دستگاه بلوکی با جدول افراز GPT)،
\f[B]uki\f[R] (یک تصویر هستهٔ یکپارچه با تصویر سیستم‌عامل در بخش PE با نام
\f[B].initrd\f[R])، \f[B]esp\f[R] (یک تصویر دیسک تنها با یک افراز ESP،
بوت‌لودر و به صورت اختیاری یک UKI)، \f[B]oci\f[R] (یک دایرکتوری سازگار با
مشخصات تصویر OCI)، \f[B]sysext\f[R]، \f[B]confext\f[R]، \f[B]portable\f[R]،
\f[B]addon\f[R] یا \f[B]none\f[R] (تصویر سیستم‌عامل صرفاً به عنوان یک تصویر ساخت
برای تولید یک دست‌ساختهٔ دیگر در نظر گرفته شده است).
.RS
اگر از قالب خروجی \f[B]disk\f[R] استفاده شود، تصویر دیسک با استفاده از
\f[B]systemd\-repart\f[R] تولید می‌شود.
فایل‌های تعریف افراز repart که باید استفاده شوند را می‌توان با استفاده از تنظیم
\f[B]RepartDirectories=\f[R] یا از طریق \f[B]mkosi.repart/\f[R] پیکربندی کرد.
هنگامی که افرازهای verity با استفاده از تنظیم \f[B]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] قرار می‌دهد.
اگر از قالب خروجی \f[B]none\f[R] استفاده شود، خروجی‌های ساخت قبلی حذف نمی‌شوند،
اما اسکریپت‌های پاک‌سازی (نگاه کنید به \f[B]CleanScripts=\f[R]) همچنان اجرا می‌شوند.
این امکان اجرای مجدد یک اسکریپت ساخت (نگاه کنید به \f[B]BuildScripts=\f[R]) را
بدون حذف نتایج ساخت قبلی فراهم می‌کند.
.RE
.TP
\f[B]ManifestFormat=\f[R], \f[B]\-\-manifest\-format=\f[R]
نوع یا انواع قالب مانیفست برای تولید.
یک فهرست جداشده با کاما شامل \f[B]json\f[R] (قالب خروجی استاندارد JSON که
بسته‌های نصب‌شده را توصیف می‌کند) و \f[B]changelog\f[R] (یک قالب متنی خوانا
برای انسان که برای مقایسهٔ تفاوت‌ها طراحی شده است).
به صورت پیش‌فرض هیچ مانیفستی تولید نمی‌شود.
.TP
\f[B]Output=\f[R], \f[B]\-\-output=\f[R], \f[B]\-o\f[R]
نام مورد استفاده برای فایل یا پوشهٔ تصویر خروجی تولیدشده.
پیش‌فرض آن \f[B]image\f[R] است یا اگر \f[B]ImageId=\f[R] مشخص شده باشد،
به عنوان نام خروجی پیش‌فرض استفاده می‌شود که به صورت اختیاری با نسخهٔ تعیین‌شده
توسط \f[B]ImageVersion=\f[R] پسوند می‌گیرد، یا اگر تصویر خاصی از
\f[B]mkosi.images\f[R] ساخته شود، نام تصویر بر \f[B]ImageId\f[R] ارجحیت دارد.
توجه داشته باشید که این گزینه اجازهٔ پیکربندی دایرکتوری خروجی را نمی‌دهد؛
برای این منظور از \f[B]OutputDirectory=\f[R] استفاده کنید.
.RS
توجه داشته باشید که این گزینه فقط پیشوند خروجی را مشخص می‌کند؛ بسته به قالب
خروجی خاص، فشرده‌سازی و نسخهٔ تصویر مورد استفاده، نام کامل خروجی ممکن است
\f[B]image_7.8.raw.xz\f[R] باشد.
.RE
.TP
\f[B]OutputExtension=\f[R], \f[B]\-\-output\-extension=\f[R]
استفاده از پسوند مشخص‌شده برای فایل خروجی.
به صورت پیش‌فرض به پسوند مناسب بر پایهٔ قالب خروجی تنظیم می‌شود.
فقط شامل پسوند فایل است، نه پسوندهای فشرده‌سازی که در صورت فعال بودن فشرده‌سازی
به این پسوند الصاق می‌شوند.
.TP
\f[B]OutputSize=\f[R], \f[B]\-\-output\-size=\f[R]
در صورت تنظیم، اندازهٔ تصویر دیسک خروجی به اندازهٔ داده‌شده تغییر می‌یابد.
یک اندازه بر حسب بایت می‌گیرد.
از پسوندهای \f[B]K\f[R]، \f[B]M\f[R] و \f[B]G\f[R] می‌توان برای تعیین اندازه
به کیلوبایت، مگابایت و گیگابایت استفاده کرد.
این تنظیم فقط اندازهٔ دیسک را افزایش می‌دهد و محدود به تصاویر کامل دیسک است
و برای هیچ قالب خروجی دیگری کاربرد ندارد.
.TP
\f[B]CompressOutput=\f[R], \f[B]\-\-compress\-output=\f[R]
پیکربندی فشرده‌سازی برای تصویر یا بایگانی حاصل.
آرگومان می‌تواند یک مقدار بولی (boolean) یا یک الگوریتم فشرده‌سازی
(\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[B]shell\f[R]،
\f[B]boot\f[R] و \f[B]vm\f[R] در دسترس نخواهند بود.
برای مقادیر \f[B]tar\f[R]، \f[B]cpio\f[R]، \f[B]uki\f[R]، \f[B]esp\f[R]،
\f[B]oci\f[R] و \f[B]addon\f[R] به طور ضمنی فعال است.
.TP
\f[B]CompressLevel=\f[R], \f[B]\-\-compress\-level=\f[R]
سطح فشرده‌سازی مورد استفاده را پیکربندی می‌کند.
یک عدد صحیح می‌پذیرد.
مقادیر ممکن به نوع فشرده‌سازی مورد استفاده بستگی دارد.
.TP
\f[B]OutputDirectory=\f[R], \f[B]\-\-output\-directory=\f[R], \f[B]\-O\f[R]
مسیر پوشه‌ای که تمام دست‌ساخته‌های تولیدشده در آن قرار می‌گیرند.
اگر این گزینه مشخص نشده باشد و دایرکتوری \f[B]mkosi.output/\f[R] در پوشهٔ
محلی وجود داشته باشد، به‌طور خودکار برای این منظور استفاده می‌شود.
.TP
\f[B]OutputMode=\f[R], \f[B]\-\-output\-mode=\f[R]
حالت دسترسی سیستم‌فایل که هنگام ایجاد فایل تصویر خروجی استفاده می‌شود.
یک حالت دسترسی در نمادگذاری هشت‌هشتی (octal) می‌گیرد.
در صورت تنظیم نشدن، از مقادیر پیش‌فرض فعلی سیستم استفاده می‌کند.
.TP
\f[B]ImageVersion=\f[R], \f[B]\-\-image\-version=\f[R]
نسخهٔ تصویر را پیکربندی می‌کند.
این گزینه هر رشته‌ای را می‌پذیرد، اما توصیه می‌شود مجموعه‌ای از مؤلفه‌های
جداشده با نقطه مشخص شود.
نسخه همچنین می‌تواند با خواندن یک فایل \f[B]mkosi.version\f[R] (که در این صورت
می‌توان آن را به راحتی از طریق فعل \f[B]bump\f[R] یا گزینهٔ \f[B]\-\-auto\-bump\f[R]
مدیریت کرد) یا در صورت قابل اجرا بودن با خواندن stdout پیکربندی شود (بخش
\f[B]Scripts\f[R] در زیر را ببینید).
هنگام مشخص شدن، نسخهٔ تصویر در نام پیش‌فرض فایل خروجی گنجانده می‌شود، یعنی
به جای \f[B]image.raw\f[R] نام پیش‌فرض برای نسخهٔ \f[B]0.1\f[R] تصویر،
\f[B]image_0.1.raw\f[R] خواهد بود و موارد مشابه.
این نسخه همچنین از طریق \f[B]$IMAGE_VERSION\f[R] به تمام اسکریپت‌های ساخت
فراخوانی‌شده ارسال می‌شود (که ممکن است برای اعمال آن در
\f[B]/usr/lib/os\-release\f[R] یا موارد مشابه، به ویژه در فیلد
\f[B]IMAGE_VERSION=\f[R] آن، مفید باشد).
.TP
\f[B]ImageId=\f[R], \f[B]\-\-image\-id=\f[R]
شناسهٔ تصویر را پیکربندی می‌کند.
یک رشته آزاد را می‌پذیرد که برای شناسایی تصویر به کار خواهد رفت.
در صورت تنظیم، نام فایل خروجی پیش‌فرض بر اساس آن نام‌گذاری می‌شود (احتمالاً همراه
با پسوند نسخه).
این شناسه همچنین از طریق \f[B]$IMAGE_ID\f[R] به تمام اسکریپت‌های ساخت
فراخوانی‌شده ارسال می‌شود.
شناسه تصویر به‌طور خودکار به \f[B]/usr/lib/os\-release\f[R] افزوده می‌شود.
هنگام استفاده از \f[B]Format=oci\f[R]، شناسه تصویر همچنین به عنوان حاشیه‌نویسی
\f[B]org.opencontainers.image.ref.name\f[R] روی توصیف‌گر نمایهٔ OCI تنظیم می‌شود.
.TP
\f[B]OciLabels=\f[R], \f[B]\-\-oci\-labels=\f[R]
برچسب‌های پیکربندی OCI را روی تصاویر تولیدشده با \f[B]Format=oci\f[R] تنظیم می‌کند.
فهرستی از انتساب‌های \f[B]KEY=VALUE\f[R] جداشده با فاصله را می‌گیرد.
این برچسب‌ها در حباب پیکربندی تصویر OCI ذخیره می‌شوند و از طریق
\f[B]podman inspect\f[R] یا \f[B]docker inspect\f[R] قابل مشاهده هستند (معادل
\f[B]LABEL\f[R] در یک Containerfile).
این گزینه می‌تواند بیش از یک بار مشخص شود که در این حالت تمام برچسب‌های
فهرست‌شده تنظیم خواهند شد.
اگر یک برچسب دو بار تنظیم شود، تنظیم پسین مقدار پیشین را بازنویسی می‌کند.
.TP
\f[B]OciAnnotations=\f[R], \f[B]\-\-oci\-annotations=\f[R]
حاشیه‌نویسی‌های مانیفست OCI را روی تصاویر تولیدشده با
\f[B]Format=oci\f[R] تنظیم می‌کند.
فهرستی از انتساب‌های \f[B]KEY=VALUE\f[R] جداشده با فاصله را می‌پذیرد.
این حاشیه‌نویسی‌ها در مانیفست تصویر OCI ذخیره می‌شوند.
ابزار mkosi به‌طور خودکار \f[B]io.systemd.mkosi.version\f[R] و در صورت
تنظیم \f[B]ImageVersion=\f[R]، مقدار \f[B]org.opencontainers.image.version\f[R]
را تنظیم می‌کند.
حاشیه‌نویسی‌های مشخص‌شده توسط کاربر این مقادیر پیش‌فرض را بازنویسی می‌کنند.
این گزینه می‌تواند بیش از یک بار مشخص شود که در این حالت تمام حاشیه‌نویسی‌های
فهرست‌شده اعمال خواهند شد.
.TP
\f[B]SplitArtifacts=\f[R], \f[B]\-\-split\-artifacts=\f[R]
انواع دست‌ساخته‌هایی که باید از تصویر نهایی تفکیک شوند.
یک فهرست جداشده با کاما شامل \f[B]uki\f[R]، \f[B]kernel\f[R]،
\f[B]initrd\f[R]، \f[B]os\-release\f[R]، \f[B]pcrs\f[R]،
\f[B]partitions\f[R]، \f[B]roothash\f[R]،
\f[B]kernel\-modules\-initrd\f[R]، \f[B]repart\-definitions\f[R] و
\f[B]tar\f[R].
هنگام ساخت یک تصویر قابل بوت، \f[B]kernel\f[R] و \f[B]initrd\f[R]
متناظر با دست‌ساختهٔ آن‌ها در تصویر (یا در UKI) هستند، در حالی که
\f[B]uki\f[R] کل UKI را به بیرون کپی می‌کند.
اگر \f[B]pcrs\f[R] مشخص شود، یک فایل JSON حاوی خلاصه‌های از‌پیش‌محاسبه‌شدهٔ
TPM2 مطابق با \c
.UR https://uapi-group.org/specifications/specs/unified_kernel_image/#json-format-for-pcrsig
مشخصات UKI
.UE \c
\ نوشته می‌شود که برای امضای آفلاین مفید است.
.RS
هنگام ساخت یک تصویر دیسک و در صورت تعیین \f[B]partitions\f[R]، گزینهٔ
\f[B]\-\-split=yes\f[R] به \f[B]systemd\-repart\f[R] داده می‌شود تا فایل‌های
افراز تفکیک‌شده را برای هر افراز پیکربندی‌شده بنویسد.
برای اطلاعات بیشتر \c
.UR https://www.freedesktop.org/software/systemd/man/systemd-repart.html#--split=BOOL
صفحهٔ راهنما (man page)
.UE \c
\ را مطالعه کنید.
این قابلیت در سناریوهای به‌روزرسانی A/B که در آن یک تصویر دیسک موجود باید
با نسخهٔ جدیدی از یک افراز root یا \f[B]/usr\f[R] همراه با افراز Verity و هستهٔ
یکپارچهٔ آن ارتقا یابد، مفید است.
هنگامی که \f[B]tar\f[R] مشخص شود، rootfs علاوه بر این به عنوان یک بایگانی tar
(فشرده‌شده طبق \f[B]CompressOutput=\f[R]) بایگانی می‌شود.
هنگامی که \f[B]roothash\f[R] مشخص شده و یک تصویر دیسک dm\-verity ساخته شود،
مقدار dm\-verity roothash به عنوان یک فایل مجزا نوشته می‌شود که برای امضای
آفلاین مفید است.
مقدار \f[B]kernel\-modules\-initrd\f[R] متناظر با initrd مجزای ماژول‌های هسته
است که mkosi آن را به انتهای initrd اصلی الصاق می‌کند.
این مورد اصولاً برای اشکال‌زدایی در نظر گرفته شده است زیرا بسیاری از ابزارهای
بررسی initrd الصاق چند initrd به یکدیگر را به درستی پشتیبانی نمی‌کنند.
هنگامی که \f[B]repart\-definitions\f[R] مشخص شود، پوشه‌ای حاوی فایل‌های تعاریف
repart استفاده‌شده در پوشه خروجی نوشته می‌شود.
اگر چندین پوشه از طریق \f[B]RepartDirectories=\f[R] پیکربندی شده باشد،
آن‌ها ادغام می‌شوند و در صورت وجود فایل‌هایی با نام‌های یکسان، پوشه‌های پسین بر
پوشه‌های پیشین اولویت خواهند داشت.
به صورت پیش‌فرض مقادیر \f[B]uki\f[R]، \f[B]kernel\f[R] و \f[B]initrd\f[R]
تفکیک می‌شوند.
.RE.TP
\f[B]RepartDirectories=\f[R], \f[B]\-\-repart\-directory=\f[R]
مسیرهای دایرکتوری‌های حاوی فایل‌های تعریف پارتیشن \f[B]systemd\-repart\f[R] که هنگام فراخوانی \f[B]systemd\-repart\f[R] توسط \f[B]mkosi\f[R] در زمان ساخت ایمیج دیسک استفاده می‌شوند.
اگر \f[B]mkosi.repart/\f[R] در دایرکتوری محلی وجود داشته باشد، برای این منظور نیز استفاده خواهد شد.
توجه داشته باشید که \f[B]mkosi\f[R] ابزار repart را با \f[B]\-\-root=\f[R] تنظیم‌شده روی ریشهٔ ایمیج فراخوانی می‌کند، بنابراین هر مسیر مبدأ \f[B]CopyFiles=\f[R] در فایل‌های تعریف پارتیشن، نسبت به دایرکتوری ریشهٔ ایمیج در نظر گرفته خواهد شد.
.TP
\f[B]SectorSize=\f[R], \f[B]\-\-sector\-size=\f[R]
بازنویسی اندازه سکتور پیش‌فرضی که \f[B]systemd\-repart\f[R] هنگام ساخت ایمیج دیسک استفاده می‌کند.
.TP
\f[B]Overlay=\f[R], \f[B]\-\-overlay=\f[R]
هنگامی که همراه با \f[B]BaseTrees=\f[R] استفاده شود، خروجی تنها شامل تغییرات نسبت به درخت‌های پایه مشخص‌شده خواهد بود.
هر درخت پایه به عنوان یک لایه زیرین (lower layer) در یک ساختار overlayfs متصل می‌شود و خروجی تبدیل به لایه بالایی (upper layer) می‌شود که در ابتدا خالی است.
بنابراین فایل‌هایی که در مقایسه با درخت‌های پایه تغییری نکرده‌اند در خروجی نهایی حضور نخواهند داشت.
.RS
از این گزینه می‌توان برای ایجاد \c
.UR https://uapi-group.org/specifications/specs/extension_image
\f[I]system extensions\f[R] در systemd
.UE \c
\& استفاده کرد.
.RE
.TP
\f[B]Seed=\f[R], \f[B]\-\-seed=\f[R]
یک UUID یا مقدار ویژهٔ \f[B]random\f[R] را به عنوان آرگومان می‌پذیرد.
سید (seed) مورد استفاده توسط \f[B]systemd\-repart\f[R] را هنگام ساخت ایمیج دیسک بازنویسی می‌کند.
این مورد برای دستیابی به ساخت‌های بازتولیدپذیر (reproducible builds) مفید است، جایی که UUIDهای قطعی و سایر متاداده‌های پارتیشن باید در هر ساخت مشتق شوند.
اگر به صراحت مشخص نشده باشد و فایل \f[B]mkosi.seed\f[R] در دایرکتوری محلی وجود داشته باشد، UUID مورد استفاده از آن خوانده می‌شود.
در غیر این صورت، یک UUID تصادفی استفاده می‌شود.
.TP
\f[B]ElTorito=\f[R], \f[B]\-\-el\-torito=\f[R]
مشخص می‌کند که آیا هنگام ساخت ایمیج دیسک، کاتالوگ بوت El Torito برای بوت کردن ESP اضافه شود یا خیر.
یک مقدار بولی (boolean) یا \f[B]auto\f[R] می‌پذیرد.
پیش‌فرض آن \f[B]auto\f[R] است.
هنگامی که روی \f[B]auto\f[R] تنظیم شود، یک کاتالوگ بوت El Torito اضافه می‌شود مگر اینکه grub به عنوان بوت‌لودر BIOS نصب شده باشد (چرا که با آن ناسازگار است).
نیازمند systemd\-repart ≥ v261 است.
.TP
\f[B]ElToritoSystem=\f[R], \f[B]\-\-el\-torito\-system=\f[R]
تنظیم شناسه سیستم (system identifier) در توصیف‌گر ISO 9660.
.TP
\f[B]ElToritoVolume=\f[R], \f[B]\-\-el\-torito\-volume=\f[R]
تنظیم شناسه حجم (volume identifier) در توصیف‌گر ISO 9660.
.TP
\f[B]ElToritoPublisher=\f[R], \f[B]\-\-el\-torito\-publisher=\f[R]
تنظیم شناسه ناشر (publisher identifier) در توصیف‌گر ISO 9660.
.TP
\f[B]CleanScripts=\f[R], \f[B]\-\-clean\-script=\f[R]
فهرستی از مسیرهای فایل‌های اجرایی جداشده با کاما را می‌پذیرد که به عنوان اسکریپت‌های پاک‌سازی (clean scripts) برای این ایمیج استفاده می‌شوند.
الگوهای تطبیق مسیر (glob patterns) پشتیبانی می‌شوند و مسیرهای منطبق به ترتیب الفبایی مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.SS بخش [Content]
.TP
\f[B]Packages=\f[R], \f[B]\-\-package=\f[R], \f[B]\-p\f[R]
بسته‌های توزیع مشخص‌شده (مانند RPM، deb و \&...) را در ایمیج نصب می‌کند.
فهرستی از مشخصات بسته‌ها که با کاما جدا شده‌اند را می‌پذیرد.
این گزینه می‌تواند چندین بار استفاده شود که در این صورت فهرست بسته‌های مشخص‌شده با یکدیگر ترکیب می‌شوند.
از \f[B]BuildPackages=\f[R] برای مشخص کردن بسته‌هایی استفاده کنید که فقط باید در یک overlay نصب شوند؛ این overlay زمانی متصل می‌شود که اسکریپت‌های آماده‌سازی با آرگومان \f[B]build\f[R] و همچنین هنگام اجرای اسکریپت‌های ساخت اجرا شوند.
.RS
انواع و نحوِ (syntax) مجاز برای \f[I]مشخصات بسته\f[R]، به نصاب بسته بستگی دارد (مانند \f[B]dnf\f[R] برای توزیع‌های مبتنی بر RPM یا \f[B]apt\f[R] برای توزیع‌های مبتنی بر deb)، اما می‌تواند شامل نام بسته‌ها، نام بسته‌ها به همراه نسخه و/یا معماری، الگوهای نام بسته (globs)، گروه‌های بسته و موارد ارائه‌شدهٔ مجازی (virtual provides)، از جمله مسیرهای فایل باشد.
برای اطلاعات دربارهٔ نحوهٔ در دسترس قرار دادن بسته‌های محلی برای نصب با \f[B]Packages=\f[R]، گزینهٔ \f[B]PackageDirectories=\f[R] را ببینید.
\f[B]مثال\f[R]: هنگام استفاده از توزیعی که از \f[B]dnf\f[R] بهره می‌برد، پیکربندی زیر بستهٔ \f[B]meson\f[R] (در آخرین نسخه)، نسخهٔ ۳۲ بیتی بستهٔ \f[B]libfdisk\-devel\f[R]، تمام بسته‌های موجود با پیشوند \f[B]git\-\f[R]، یک بستهٔ RPM متعلق به \f[B]systemd\f[R] از سیستم‌فایل محلی، یکی از بسته‌هایی که \f[B]/usr/bin/ld\f[R] را ارائه می‌دهد، بسته‌های موجود در گروه \f[I]Development Tools\f[R] و بسته‌ای که حاوی ماژول پایتون \f[B]mypy\f[R] است را نصب می‌کند.
.IP
.EX
Packages=meson
         libfdisk\-devel.i686
         git\-*
         /usr/bin/ld
         \(atdevelopment\-tools
         python3dist(mypy)
.EE
.RE
.TP
\f[B]BuildPackages=\f[R], \f[B]\-\-build\-package=\f[R]
مشابه \f[B]Packages=\f[R] است، اما بسته‌ها را طوری پیکربندی می‌کند که فقط در یک overlay نصب شوند که در بالای ایمیج برای اسکریپت‌های آماده‌سازی (هنگام اجرا با آرگومان \f[B]build\f[R]) و اسکریپت‌های ساخت در دسترس قرار می‌گیرد.
این گزینه باید برای فهرست کردن بسته‌های حاوی فایل‌های هدر، کامپایلرها، سیستم‌های ساخت، پیونددهنده‌ها (linkers) و سایر ابزارهای ساختی که اسکریپت‌های \f[B]mkosi.build\f[R] برای کار به آن‌ها نیاز دارند استفاده شود.
توجه داشته باشید بسته‌هایی که در اینجا فهرست شده‌اند در ایمیج نهایی وجود نخواهند داشت.
.TP
\f[B]VolatilePackages=\f[R], \f[B]\-\-volatile\-package=\f[R]
مشابه \f[B]Packages=\f[R] است، اما بسته‌هایی که با این تنظیم پیکربندی می‌شوند در زمان فعال بودن \f[B]Incremental=\f[R] کَش نمی‌شوند و پس از اجرای اسکریپت‌های ساخت نصب می‌گردند.
.RS
به‌طور مشخص، از این تنظیم می‌توان برای نصب بسته‌هایی استفاده کرد که مکرراً تغییر می‌کنند یا توسط یک اسکریپت ساخت، ساخته می‌شوند.
.RE
.TP
\f[B]PackageDirectories=\f[R], \f[B]\-\-package\-directory=\f[R]
دایرکتوری‌های حاوی بسته‌های اضافی که باید در طول فرایند ساخت در دسترس باشند را مشخص می‌کند.
\f[B]mkosi\f[R] یک مخزن محلی شامل تمام بسته‌های موجود در این دایرکتوری‌ها ایجاد می‌کند و هنگام نصب بسته‌ها یا اجرای اسکریپت‌ها آن را در دسترس قرار می‌دهد.
اگر دایرکتوری \f[B]mkosi.packages/\f[R] در دایرکتوری محلی یافت شود، برای این منظور نیز استفاده خواهد شد.
.TP
\f[B]VolatilePackageDirectories=\f[R], \f[B]\-\-volatile\-package\-directory=\f[R]
مانند \f[B]PackageDirectories=\f[R] عمل می‌کند، با این تفاوت که در صورت فعال بودن \f[B]Incremental=\f[R]، هرگونه تغییر در بسته‌های این دایرکتوری‌ها باعث نامعتبر شدن ایمیج‌های کش‌شده نخواهد شد.
.RS
علاوه بر این، اسکریپت‌های ساخت می‌توانند با قرار دادن بسته‌های ساخته‌شده در \f[B]$PACKAGEDIR\f[R]، بسته‌های بیشتری به مخزن محلی اضافه کنند.
بسته‌های قرار گرفته در \f[B]$PACKAGEDIR\f[R] بین تمام فرایندهای ساخت ایمیج به اشتراک گذاشته می‌شوند و بنابراین برای نصب در همهٔ ایمیج‌هایی که از \f[B]VolatilePackages=\f[R] استفاده می‌کنند در دسترس خواهند بود.
.RE
.TP
\f[B]WithRecommends=\f[R], \f[B]\-\-with\-recommends=\f[R]
مشخص می‌کند که آیا وابستگی‌های توصیه‌شده (recommended) یا ضعیف (weak)، بسته به نحوهٔ نام‌گذاری آن‌ها توسط مدیر بسته مورد استفاده، نصب شوند یا خیر.
به‌طور پیش‌فرض، بسته‌های توصیه‌شده نصب نمی‌شوند.
این گزینه فقط برای مدیر بسته‌هایی کاربرد دارد که از این مفهوم پشتیبانی می‌کنند، که در حال حاضر شامل \f[B]apt\f[R]، \f[B]dnf\f[R] و \f[B]zypper\f[R] هستند.
.TP
\f[B]WithDocs=\f[R], \f[B]\-\-with\-docs=\f[R]
گنجاندن مستندات در ایمیج.
به‌طور پیش‌فرض فعال است.
در صورت غیرفعال بودن، چنانچه مدیر بستهٔ توزیع زیرین از آن پشتیبانی کند، مستندات در ایمیج گنجانده نمی‌شوند.
متغیر محیطی \f[B]$WITH_DOCS\f[R] که به اسکریپت‌های \f[B]mkosi.build\f[R] ارسال می‌شود، بسته به فعال یا غیرفعال بودن این گزینه روی \f[B]0\f[R] یا \f[B]1\f[R] تنظیم می‌شود.
.TP
\f[B]BaseTrees=\f[R], \f[B]\-\-base\-tree=\f[R]
فهرستی از مسیرهای جداشده با کاما را برای استفاده به عنوان درخت‌های پایه می‌پذیرد.
هنگام استفاده، هر یک از این درخت‌های پایه درون درخت سیستم‌عامل کپی می‌شوند و به جای نصب توزیع از ابتدا، توزیع پایه را تشکیل می‌دهند.
تنها بسته‌های اضافی روی مواردی که پیش‌تر در درخت‌های پایه نصب شده‌اند نصب می‌شوند.
توجه داشته باشید که برای کارکرد صحیح این قابلیت، ایمیج پایه همچنان باید متاداده‌های مدیر بسته را با تنظیم \f[B]CleanPackageMetadata=no\f[R] در خود داشته باشد (به \f[B]CleanPackageMetadata=\f[R] مراجعه کنید).
.RS
به جای یک دایرکتوری، می‌توان یک فایل tar یا یک ایمیج دیسک ارائه داد.
در این حالت، محتوای آن درون درخت سیستم‌عامل بازگشایی (unpack) می‌شود.
این شیوهٔ عملکرد امکان تنظیم صریح مجوزها و مالکیت فایل را فراهم می‌کند، به ویژه برای پروژه‌های ذخیره‌شده در سیستم کنترل نسخه‌ای مانند \f[B]git\f[R] که متاداده‌های کامل مالکیت فایل و سطح دسترسی را برای فایل‌های ثبت‌شده حفظ می‌کنند.
.RE
.TP
\f[B]SkeletonTrees=\f[R], \f[B]\-\-skeleton\-tree=\f[R]
فهرستی از جفت‌مسیرهای جداشده با دونقطه (:) را می‌پذیرد که با کاما از هم جدا شده‌اند.
مسیر اول در هر جفت به دایرکتوری‌ای اشاره دارد که باید پیش از فراخوانی مدیر بسته در درخت سیستم‌عامل کپی شود.
مسیر دوم در هر جفت به دایرکتوری مقصد در داخل ایمیج اشاره دارد.
اگر مسیر دوم ارائه نشود، دایرکتوری روی دایرکتوری ریشهٔ ایمیج کپی می‌شود.
مسیر دوم همیشه به عنوان یک مسیر مطلق تفسیر می‌شود.
از این گزینه برای قرار دادن فایل‌ها و دایرکتوری‌ها در درخت سیستم‌عامل پیش از آنکه مدیر بسته اقدام به نصب بسته‌ها کند استفاده کنید.
اگر دایرکتوری \f[B]mkosi.skeleton/\f[R] در دایرکتوری محلی یافت شود، با در نظر گرفتن دایرکتوری ریشه به عنوان مقصد برای این منظور نیز استفاده می‌شود (همچنین بخش \f[B]فایل‌ها (FILES)\f[R] را در زیر ببینید).
.RS
توجه داشته باشید که درخت‌های اسکلت (skeleton trees) کَش می‌شوند و هرگونه تغییر در درخت‌های اسکلت پس از ساخت یک ایمیج کَش‌شده (هنگام استفاده از \f[B]Incremental=\f[R])، تنها زمانی اعمال می‌شود که ایمیج کَش‌شده بازسازی شود (با استفاده از \f[B]\-ff\f[R] یا اجرای \f[B]mkosi \-f clean\f[R]).
مشابه سازوکار درخت پایه در بالا، به جای یک دایرکتوری می‌توان یک فایل tar نیز ارائه داد.
اگر \f[B]mkosi.skeleton.tar\f[R] در دایرکتوری محلی یافت شود، به‌طور خودکار استفاده خواهد شد.
برای افزودن فایل‌های پیکربندی اضافی مدیر بسته مانند مخازن بیشتر، از \f[B]SandboxTrees=\f[R] استفاده کنید زیرا \f[B]mkosi\f[R] مدیر بسته‌ها را از خارج ایمیج فراخوانی می‌کند و نه از داخل آن؛ بنابراین هرگونه فایل پیکربندی مدیر بسته که از طریق \f[B]SkeletonTrees=\f[R] ارائه شود، زمانی که \f[B]mkosi\f[R] یک مدیر بسته را برای نصب بسته‌ها فراخوانی می‌کند بی‌اثر خواهد بود.
.RE.TP
\f[B]ExtraTrees=\f[R], \f[B]\-\-extra\-tree=\f[R]
یک فهرست جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه دریافت می‌کند.
نخستین مسیر هر جفت به یک دایرکتوری برای کپی شدن از میزبان به درون تصویر اشاره دارد.
دومین مسیر هر جفت به دایرکتوری مقصد درون تصویر اشاره می‌کند.
اگر مسیر دوم مشخص نشده باشد، دایرکتوری بر روی دایرکتوری ریشهٔ تصویر کپی می‌شود.
مسیر دوم همیشه به عنوان یک مسیر مطلق تفسیر می‌شود.
از این گزینه برای جایگزینی هرگونه فایل پیکربندی پیش‌فرض ارائه‌شده با توزیع استفاده کنید.
اگر دایرکتوری \f[B]mkosi.extra/\f[R] در دایرکتوری محلی پیدا شود، برای این منظور با دایرکتوری ریشه به عنوان مقصد به کار گرفته می‌شود (همچنین بخش \f[B]فایل‌ها (FILES)\f[R] را در زیر ببینید).
.RS
همانند منطق درخت پایه در بالا، به جای یک دایرکتوری، یک فایل tar نیز می‌تواند مشخص شود.
در صورت پیدا شدن \f[B]mkosi.extra.tar\f[R] در دایرکتوری محلی، به طور خودکار استفاده خواهد شد.
.RE
.TP
\f[B]RemovePackages=\f[R], \f[B]\-\-remove\-package=\f[R]
یک فهرست جداشده با کاما از بسته‌های مشخص‌شده برای حذف را با همان ساختار \f[B]Packages=\f[R] دریافت می‌کند.
عملیات حذف به عنوان یکی از مراحل پایانی انجام خواهد شد.
در صورت استفاده از \f[B]CleanPackageMetadata=no\f[R]، از این مرحله صرف‌نظر می‌شود.
.TP
\f[B]RemoveFiles=\f[R], \f[B]\-\-remove\-files=\f[R]
فهرستی جداشده با کاما از الگوهای تطبیق (glob) می‌گیرد.
فایل‌هایی درون تصویر که با این الگوها مطابقت داشته باشند در پایان پاک‌سازی خواهند شد.
.TP
\f[B]CleanPackageMetadata=\f[R], \f[B]\-\-clean\-package\-metadata=\f[R]
فعال‌سازی/غیرفعال‌سازی حذف پایگاه‌های دادهٔ مدیر بسته و فراداده‌های مخزن در پایان نصب.
می‌تواند به صورت \f[B]true\f[R]، \f[B]false\f[R] یا \f[B]auto\f[R] (پیش‌فرض) تعیین شود.
در حالت \f[B]auto\f[R]، اگر فایل اجرایی مدیر بستهٔ مربوطه در پایان نصب وجود \f[I]نداشته\f[R] باشد، پایگاه‌های دادهٔ مدیر بسته و فراداده‌های مخزن حذف خواهند شد.
.TP
\f[B]SourceDateEpoch=\f[R], \f[B]\-\-source\-date\-epoch=\f[R]
یک برچسب زمانی بر حسب ثانیه از مبدأ زمانی یونیکس (UNIX epoch) به عنوان آرگومان دریافت می‌کند.
زمان تغییر (modification time) تمامی فایل‌ها به این مقدار محدود خواهد شد.
این متغیر به \f[B]systemd\-repart\f[R] و اسکریپت‌های اجراشده توسط \f[B]mkosi\f[R] نیز انتشار می‌یابد.
در صورت عدم تنظیم صریح، متغیر \f[B]SOURCE_DATE_EPOCH\f[R] به ترتیب از \f[B]\-\-environment=\f[R] و سپس از محیط میزبان بررسی می‌شود.
این گزینه برای دستیابی به ساخت‌های تکرارپذیر (reproducible builds) کاربردی است.
برای اطلاعات بیشتر \c
.UR https://reproducible-builds.org/specs/source-date-epoch
SOURCE_DATE_EPOCH
.UE \c
\ را ببینید.
.TP
\f[B]SyncScripts=\f[R], \f[B]\-\-sync\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های همگام‌سازی (sync) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]PrepareScripts=\f[R], \f[B]\-\-prepare\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های آماده‌سازی (prepare) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]BuildScripts=\f[R], \f[B]\-\-build\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های ساخت (build) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]PostInstallationScripts=\f[R], \f[B]\-\-postinst\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های پس از نصب (post\-installation) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]FinalizeScripts=\f[R], \f[B]\-\-finalize\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های نهایی‌سازی (finalize) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]PostOutputScripts=\f[R], \f[B]\-\-postoutput\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های پس از خروجی (post output) برای این تصویر استفاده می‌شوند.
الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]Bootable=\f[R], \f[B]\-\-bootable=\f[R]
یک مقدار بولی (boolean) یا \f[B]auto\f[R] می‌پذیرد.
تولید یک تصویر قابل راه‌اندازی (bootable) را فعال یا غیرفعال می‌کند.
در صورت فعال بودن، \f[B]mkosi\f[R] یک بارگذار بوت EFI نصب کرده و در صورت استفاده از خروجی تصویر دیسک، یک پارتیشن ESP اضافه می‌کند.
اگر بارگذار بوت EFI انتخاب‌شده (گزینهٔ \f[B]Bootloader=\f[R] را ببینید) نصب نشده باشد یا هیچ تصویر کرنلی پیدا نشود، فرآیند ساخت شکست خواهد خورد.
مقدار \f[B]auto\f[R] رفتاری مشابه با فعال بودن گزینه دارد، اما در صورت پیدا نشدن تصویر کرنل یا بارگذار بوت EFI انتخاب‌شده، ساخت با شکست مواجه نخواهد شد.
در صورت غیرفعال بودن، حتی در صورت وجود بارگذار بوت در تصویر، نصب نخواهد شد؛ هیچ تصویر کرنل یکپارچه‌ای (UKI) ایجاد نمی‌گردد و در صورت استفاده از قالب خروجی دیسک، هیچ پارتیشن ESP به تصویر اضافه نخواهد شد.
.RS
در صورت استفاده از قالب خروجی \f[B]esp\f[R]، پارتیشن ESP و بارگذار بوت همواره اضافه می‌شوند و گزینهٔ \f[B]Bootable=\f[R] تنها کنترل می‌کند که آیا یک UKI به پارتیشن ESP اضافه شود یا خیر.
.RE
.TP
\f[B]Bootloader=\f[R], \f[B]\-\-bootloader=\f[R]
یکی از مقادیر \f[B]none\f[R]، \f[B]systemd\-boot\f[R]، \f[B]uki\f[R]، \f[B]grub\f[R]، \f[B]systemd\-boot\-signed\f[R]، \f[B]uki\-signed\f[R] یا \f[B]grub\-signed\f[R] را می‌پذیرد.
پیش‌فرض آن \f[B]systemd\-boot\f[R] است.
اگر روی \f[B]none\f[R] تنظیم شود، هیچ بارگذار بوت EFI درون تصویر نصب نخواهد شد.
اگر روی \f[B]systemd\-boot\f[R] تنظیم شود، \f[B]systemd\-boot\f[R] نصب می‌شود و به ازای هر کرنلِ نصب‌شده، یک UKI تولید شده و در مسیر \f[B]EFI/Linux\f[R] درون ESP ذخیره می‌گردد.
اگر روی \f[B]uki\f[R] تنظیم شود، برای جدیدترین کرنلِ نصب‌شده (کرنلی با بالاترین نسخه) یک UKI واحد تولید می‌شود که در مسیر \f[B]EFI/BOOT/BOOTX64.EFI\f[R] در ESP نصب می‌گردد.
اگر روی \f[B]grub\f[R] تنظیم شود، به ازای هر کرنل نصب‌شده یک UKI تولید و در \f[B]EFI/Linux\f[R] در ESP ذخیره می‌شود.
به ازای هر UKI تولیدشده، یک مدخل منو به پیکربندی grub در مسیر \f[B]grub/grub.cfg\f[R] درون ESP الحاق می‌شود که اجرای زنجیره‌ای (chainload) به UKI را انجام می‌دهد.
همچنین یک grub.cfg واسط (shim) در مسیر \f[B]EFI/<distribution>/grub.cfg\f[R] در ESP نوشته می‌شود که جهت سازگاری با نسخه‌های امضاشدهٔ grub (که پیکربندی را از این مکان بارگذاری می‌کنند)، فایل \f[B]grub/grub.cfg\f[R] را در ESP بارگذاری می‌کند.
.RS
انواع \f[B]signed\f[R] تنها باینری‌های EFI از پیش امضاشده را که توسط توزیع ارائه شده است نصب خواهند کرد.
کرنل‌ها باید درون سیستم‌فایل ریشه (به عنوان نمونه با استفاده از \f[B]ExtraTrees=\f[R]) ذیل مسیر \f[B]/usr/lib/modules/$version\f[R]، با نام \f[B]vmlinux\f[R] یا \f[B]vmlinuz\f[R] قرار گیرند.
مقدار \f[B]$version\f[R] همان چیزی است که توسط هدف make مربوط به \f[B]kernelversion\f[R] در Kbuild تولید می‌شود.
نکته: هنگام استفاده از \f[B]systemd\-boot\f[R] یا \f[B]systemd\-boot\-signed\f[R]، ابزار \f[B]mkosi\f[R] انتظار دارد باینری‌های EFI مربوط به \f[B]systemd\-boot\f[R] در تصویر موجود باشند.
بسته به توزیع شما، این فایل‌ها ممکن است به صورت جداگانه بسته‌بندی شده باشند.
به عنوان مثال، تصاویر مبتنی بر دبیان به بستهٔ \f[B]systemd\-boot\-efi\f[R] نیاز خواهند داشت.
.RE
.TP
\f[B]BiosBootloader=\f[R], \f[B]\-\-bios\-bootloader=\f[R]
یکی از مقادیر \f[B]none\f[R] یا \f[B]grub\f[R] را می‌گیرد.
پیش‌فرض آن \f[B]none\f[R] است.
اگر روی \f[B]none\f[R] تنظیم شود، هیچ بارگذار بوت BIOS نصب نخواهد شد.
اگر روی \f[B]grub\f[R] تنظیم شود، در صورت درخواست تصویر قابل راه‌اندازی از طریق گزینهٔ \f[B]Bootable=\f[R]، نرم‌افزار grub به عنوان بارگذار بوت BIOS نصب می‌شود.
اگر هیچ فایل تعریف پارتیشن repart پیکربندی نشده باشد، \f[B]mkosi\f[R] یک پارتیشن بوت BIOS برای grub و یک پارتیشن سیستم EFI را به فایل‌های پیش‌فرض تعریف پارتیشن اضافه خواهد کرد.
.RS
توجه داشته باشید که این گزینه با \f[B]Bootloader=\f[R] ناسازگار یا مانعة‌الجمع نیست.
با پیکربندی هر دو گزینهٔ \f[B]Bootloader=\f[R] و \f[B]BiosBootloader=\f[R]، داشتن تصویری که هم روی UEFI و هم روی BIOS قابل راه‌اندازی باشد امکان‌پذیر است.
پارتیشن بوت BIOS برای grub باید دارای UUID به مقدار \f[B]21686148\-6449\-6e6f\-744e\-656564454649\f[R] و حداقل دارای ۱ مگابایت اندازه باشد.
حتی اگر هیچ بارگذار بوت EFI نصب نشده باشد، باز هم برای بوت BIOS به یک ESP نیاز است؛ چرا که کرنل، initrd و ماژول‌های grub در آنجا ذخیره می‌شوند.
.RE
.TP
\f[B]ShimBootloader=\f[R], \f[B]\-\-shim\-bootloader=\f[R]
یکی از مقادیر \f[B]none\f[R]، \f[B]unsigned\f[R] یا \f[B]signed\f[R] را می‌پذیرد.
پیش‌فرض آن \f[B]none\f[R] است.
اگر روی \f[B]none\f[R] تنظیم شود، shim و MokManager روی ESP نصب نخواهند شد.
اگر روی \f[B]unsigned\f[R] تنظیم شود، \f[B]mkosi\f[R] به دنبال باینری‌های EFI امضانشدهٔ shim و MokManager می‌گردد و آن‌ها را نصب می‌کند.
اگر \f[B]SecureBoot=\f[R] فعال باشد، \f[B]mkosi\f[R] پیش از نصب، باینری‌های EFI امضانشده را امضا خواهد کرد.
اگر روی \f[B]signed\f[R] تنظیم شود، \f[B]mkosi\f[R] به دنبال باینری‌های EFI امضاشده می‌گردد و آن‌ها را نصب می‌کند.
حتی در صورت فعال بودن \f[B]SecureBoot=\f[R]، \f[B]mkosi\f[R] این باینری‌ها را مجدداً امضا نخواهد کرد.
.RS
توجه داشته باشید که این گزینه تنها زمانی مؤثر است که ایجاد تصویری با قابلیت راه‌اندازی روی سفت‌افزار UEFI توسط گزینه‌های دیگر (\f[B]Bootable=\f[R]، \f[B]Bootloader=\f[R]) درخواست شده باشد.
توجه داشته باشید هنگامی که این گزینه فعال است، \f[B]mkosi\f[R] تنها باینری‌های بارگذار بوت، فایل‌های تصویر کرنل و تصاویر یکپارچهٔ کرنل از پیش امضاشده را نصب می‌کند، زیرا باینری‌های خود‌امضاشده توسط نسخهٔ امضاشدهٔ shim پذیرفته نخواهند شد.
.RE
.TP
\f[B]UnifiedKernelImages=\f[R], \f[B]\-\-unified\-kernel\-images=\f[R]
مشخص می‌کند که آیا در صورت تنظیم \f[B]Bootloader=\f[R] بر روی \f[B]systemd\-boot\f[R] یا \f[B]grub\f[R]، از تصاویر کرنل یکپارچه (UKI) استفاده شود یا خیر.
یکی از مقادیر \f[B]none\f[R]، \f[B]unsigned\f[R]، \f[B]signed\f[R] یا \f[B]auto\f[R] را می‌پذیرد.
پیش‌فرض آن \f[B]auto\f[R] است.
در صورت تنظیم روی \f[B]unsigned\f[R] یا \f[B]signed\f[R]، همواره از تصاویر کرنل یکپارچه استفاده می‌شود و در صورت مفقود بودن هر یک از مؤلفه‌های لازم برای ساخت تصویر کرنل یکپارچه، فرآیند ساخت شکست خواهد خورد.
اگر روی \f[B]auto\f[R] تنظیم شود، در صورت در دسترس بودن تمامی مؤلفه‌های لازم از تصاویر کرنل یکپارچه استفاده خواهد شد.
در غیر این صورت، مدخل‌های Type 1 طبق تعریفِ مشخصات بارگذار بوت (Boot Loader Specification) به جای آن به کار خواهند رفت.
در صورت غیرفعال بودن، همواره مدخل‌های Type 1 استفاده خواهند شد.
اگر \f[B]Bootloader=\f[R] روی یکی از انواع امضاشده (signed) تنظیم شود، یک UKI از پیش ساخته‌شده جستجو خواهد شد و در صورت پیدا نشدن، ساخت با شکست مواجه می‌شود؛ مگر اینکه \f[B]UnifiedKernelImages=\f[R] روی \f[B]unsigned\f[R] تنظیم شده باشد، که در این حالت UKI به صورت محلی ساخته می‌شود.
این مورد هنگام ترکیب با تنظیم گزینهٔ زمان اجرای \f[B]Firmware=\f[R] روی \f[B]custom\f[R] کاربرد دارد تا کلید امضای محلی در UEFI db ثبت گردد..TP
\f[B]UnifiedKernelImageFormat=\f[R], \f[B]\-\-unified\-kernel\-image\-format=\f[R]
نام فایلی را بدون هیچ‌گونه مؤلفه مسیری می‌گیرد تا قالبی را مشخص کند که تصویرهای یکپارچه هسته (UKI) باید با آن نام نصب شوند.
این مقدار می‌تواند هم شامل مشخص‌کننده‌های معمولی (بخش \f[B]Specifiers\f[R] را ببینید) و هم مشخص‌کننده‌های تأخیری ویژه باشد که در طول نصب فایل‌ها باز می‌شوند و در ادامه شرح داده شده‌اند.
قالب پیش‌فرض برای این پارامتر \f[B]&e\-&k\f[R] است؛ در صورتی که \f[B]roothash=\f[R] یا \f[B]usrhash=\f[R] در خط فرمان هسته یافت شود، \f[B]\-&h\f[R] و اگر \f[B]/etc/kernel/tries\f[R] در تصویر یافت شود، \f[B]+&c\f[R] به انتهای آن افزوده می‌شود.
.RS
مشخص‌کننده‌های زیر می‌توانند استفاده شوند:
.PP
.TS
tab(@);
l l.
T{
مشخص‌کننده
T}@T{
مقدار
T}
_
T{
\f[B]&&\f[R]
T}@T{
نویسه \f[B]&\f[R]
T}
T{
\f[B]&e\f[R]
T}@T{
توکن ورودی (Entry Token)
T}
T{
\f[B]&k\f[R]
T}@T{
نسخه هسته
T}
T{
\f[B]&h\f[R]
T}@T{
مقدار آرگومان هسته \f[B]roothash=\f[R] یا \f[B]usrhash=\f[R]
T}
.TE
.RE
.TP
\f[B]UnifiedKernelImageProfiles=\f[R], \f[B]\-\-uki\-profile=\f[R]
ساخت پروفایل‌های تکمیلی UKI.
فهرستی جداشده با کاما از مسیرهای فایل‌های پیکربندی پروفایل UKI را دریافت می‌کند.
این گزینه می‌تواند چندین بار استفاده شود که در این حالت هر پیکربندی به یک پروفایل متناظر UKI تبدیل و ساخته می‌شود.
فایل‌های پیکربندی موجود در دایرکتوری \f[B]mkosi.uki\-profiles/\f[R] به طور خودکار شناسایی و دریافت می‌شوند.
تمام پروفایل‌های پیکربندی‌شده UKI به عنوان پروفایل‌های تکمیلی UKI به هر UKI ساخته‌شده توسط \f[B]mkosi\f[R] اضافه می‌شوند.
.RS
برای اطلاعات درباره تنظیماتی که می‌توان در فایل‌های پیکربندی پروفایل UKI مشخص کرد، مستندات بخش \f[B]UKIProfile\f[R] را ببینید.
.RE
.TP
\f[B]Initrds=\f[R], \f[B]\-\-initrd=\f[R]
استفاده از initrd(های) ارائه‌شده توسط کاربر.
فهرستی جداشده با کاما از مسیرهای فایل‌های initrd را دریافت می‌کند.
این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست‌های initrd با یکدیگر ترکیب می‌شوند.
اگر این تنظیم مشخص نشده باشد و یک تصویر قابل بوت درخواست شود، چنانچه تصویر بر اساس چند عامل (قالب خروجی، نصب بودن بسته هسته، \&...) به نظر برسد که تصویری قابل بوت است، \f[B]mkosi\f[R] به طور خودکار یک initrd پیش‌فرض خواهد ساخت.
برای غیرفعال کردن ساخت initrd پیش‌فرض، یک رشته خالی به این تنظیم اختصاص دهید.
برای ساخت initrd پیش‌فرض حتی در صورت مشخص کردن این تنظیم، می‌توان مقدار ویژه \f[B]default\f[R] را در کنار سایر مقادیر اختصاص داد.
.RS
هنگامی که initrd پیش‌فرض استفاده می‌شود، می‌توان آن را با استفاده از تنظیمات زیر و با \f[B]mkosi.initrd.conf\f[R] که می‌تواند فایل یا دایرکتوری حاوی پیکربندی اضافی برای initrd پیش‌فرض باشد، بیشتر پیکربندی کرد.
همچنین \f[B]mkosi\f[R] در زیردایرکتوری \f[B]io.mkosi.initrd\f[R] از دایرکتوری دست‌ساخته‌ها (بخش \f[B]ENVIRONMENT VARIABLES\f[R] و متغیر \f[B]$ARTIFACTDIR\f[R] را ببینید) به دنبال initrdها می‌گردد.
هر initrd یافت‌شده در آنجا به initrd(های) ارائه‌شده توسط کاربر و هر initrd پیش‌فرض ساخته‌شده توسط mkosi پیوست می‌شود.
.RE
.TP
\f[B]InitrdProfiles=\f[R], \f[B]\-\-initrd\-profile=\f[R]
تنظیم پروفایل‌هایی که باید برای initrd پیش‌فرض فعال شوند.
فهرستی جداشده با کاما از پروفایل‌ها را دریافت می‌کند.
به طور پیش‌فرض، تمام پروفایل‌ها غیرفعال هستند.
.RS
پروفایل \f[B]lvm\f[R] پشتیبانی از LVM را فعال می‌کند.
پروفایل \f[B]network\f[R] پشتیبانی از شبکه را از طریق \f[B]systemd\-networkd\f[R] فعال می‌کند.
پروفایل \f[B]nfs\f[R] پشتیبانی از NFS را فعال می‌کند.
این گزینه نیازمند فعال بودن شبکه در initrd با استفاده از پروفایل \f[B]network\f[R] یا روش سفارشی دیگری است.
پروفایل \f[B]pkcs11\f[R] پشتیبانی از PKCS#11 را فعال می‌کند.
پروفایل \f[B]plymouth\f[R] یک رابط گرافیکی در زمان بوت (پویانمایی و اعلان گذرواژه) فراهم می‌کند.
پروفایل \f[B]raid\f[R] پشتیبانی از آرایه‌های RAID را فعال می‌کند.
.RE
.TP
\f[B]InitrdPackages=\f[R], \f[B]\-\-initrd\-package=\f[R]
بسته‌های اضافی برای نصب در initrd پیش‌فرض.
فهرستی جداشده با کاما از مشخصات بسته‌ها را دریافت می‌کند.
این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست‌های بسته‌های مشخص‌شده با یکدیگر ترکیب می‌شوند.
.TP
\f[B]InitrdVolatilePackages=\f[R], \f[B]\-\-initrd\-volatile\-package=\f[R]
مشابه \f[B]VolatilePackages=\f[R] است، با این تفاوت که بر روی initrd پیش‌فرض اعمال می‌شود.
.TP
\f[B]Devicetrees=\f[R], \f[B]\-\-devicetrees=\f[R]
فهرستی جداشده با کاما از الگوهای devicetree برای انتخاب خودکار مبتنی بر سخت‌افزار.
الگوها عبارت‌های تطبیق مسیر (glob) هستند.
\f[B]mkosi\f[R] فایل‌های devicetree را در مکان‌های استاندارد وابسته به \f[B]/usr/lib/modules/<kver>/dtb/\f[R]،
\f[B]/usr/lib/firmware/<kver>/device\-tree/\f[R] و
\f[B]/usr/lib/linux\-image\-<kver>/\f[R] جستجو می‌کند.
.RS
برای ساخت‌های UKI، چندین تطابق امکان انتخاب خودکار مبتنی بر سخت‌افزار را با استفاده از بخش‌های \f[B].dtbauto\f[R] فراهم می‌کند.
مدخل‌های بوت نوع ۱ (Type 1 boot entries) دقیقاً به یک تطابق نیاز دارند.
مثال: \f[B]Devicetrees=rockchip/*,imx.*\f[R] تمام دِوایس‌تری‌های Rockchip و هر دِوایس‌تری IMX را شامل می‌شود.
.RE
.TP
\f[B]Splash=\f[R], \f[B]\-\-splash=\f[R]
در صورت تنظیم، تصویر اسپلش بوت برای هر تصویر یکپارچه هسته ساخته‌شده توسط \f[B]mkosi\f[R] از مسیر داده‌شده در داخل تصویر برداشته خواهد شد.
.TP
\f[B]MicrocodeHost=\f[R], \f[B]\-\-microcode\-host=\f[R]
در صورت تنظیم بر روی true، تنها ریزکد (microcode) مربوط به پردازنده سیستم میزبان در تصویر گنجانده می‌شود.
.TP
\f[B]KernelCommandLine=\f[R], \f[B]\-\-kernel\-command\-line=\f[R]
استفاده از خط فرمان هسته مشخص‌شده هنگام ساخت تصویرها.
.RS
اگر پارتیشن root یا usr با فعال بودن verity ساخته شوند، \f[B]roothash=\f[R] یا \f[B]usrhash=\f[R] به ترتیب به طور خودکار به خط فرمان هسته افزوده می‌شوند و \f[B]root=\f[R] یا \f[B]mount.usr=\f[R] نباید اضافه شوند.
در غیر این صورت، اگر مقدار این تنظیم شامل عبارت دقیق \f[B]root=PARTUUID\f[R] یا \f[B]mount.usr=PARTUUID\f[R] باشد، این عبارت‌ها به ترتیب با شناسه یکتای پارتیشن (UUID) پارتیشن root یا usr جایگزین می‌شوند.
برای مثال، \f[B]root=PARTUUID\f[R] با \f[B]root=PARTUUID=58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] جایگزین می‌شود که در آن \f[B]58c7d0b2\-d224\-4834\-a16f\-e036322e88f7\f[R] همان UUID پارتیشن root است.
.RE
.TP
\f[B]KernelModules=\f[R], \f[B]\-\-kernel\-modules=\f[R]
فهرستی از الگوهای تطبیق (glob) را دریافت می‌کند که مشخص می‌سازند کدام ماژول‌های هسته باید در تصویر گنجانده شوند.
هر آرگومان می‌تواند با یک خط تیره (\f[B]\-\f[R]) شروع شود تا ماژول‌های منطبق را \f[I]مستثنی\f[R] کند.
آرگومان‌ها به ترتیب ارزیابی می‌شوند؛ آخرین الگوی تطبیق مثبت یا منفی نتیجه را تعیین می‌کند.
ماژول‌هایی که در نهایت با یک الگوی مثبت مطابقت داشته باشند، به همراه وابستگی‌های ماژولی و سفت‌افزاری‌شان در تصویر گنجانده می‌شوند.
.RS
پسوند \f[B].ko\f[R] و پسوند فشرده‌سازی در حین تطبیق نادیده گرفته می‌شوند.
الگوها با مسیرهای ماژول به صورت نسبی نسبت به \f[B]/usr/lib/module/<kver>\f[R] سنجیده می‌شوند؛ به عنوان مثال، ماژول در \f[B]/usr/lib/module/<kver>/kernel/foo/bar.ko.xz\f[R] برای اهداف تطبیق به \f[B]kernel/foo/bar\f[R] تبدیل می‌شود.
الگوهایی که با \(lq/\(rq شروع می‌شوند به صورت ویژه پردازش می‌شوند.
الگو \f[I]ابتدا\f[R] با مسیری نسبت به \f[B]/usr/lib/module/<kver>/kernel\f[R] و تنها پس از آن با \f[B]/usr/lib/module/<kver>/\f[R] تطبیق داده می‌شود.
این یک سهولت است، زیرا معمولاً تنها ماژول‌های داخل درخت اصلی (in\-tree) زیر \f[B]kernel/\f[R] مورد توجه هستند.
برای نمونه، ماژول در \f[B]/usr/lib/module/<kver>/kernel/foo/bar.ko.xz\f[R] می‌تواند هم با \f[B]/foo/bar\f[R] و هم با \f[B]/kernel/foo/bar\f[R] مطابقت داده شود.
الگوهای تطبیق می‌توانند فقط شامل نام پایه (مانند \f[B]loop\f[R]) باشند که باید با نام پایه ماژول مطابقت کند، مسیر نسبی باشند (مانند \f[B]block/loop\f[R]) که باید با مؤلفه‌های انتهایی مسیر ماژول تا نام پایه مطابقت داشته باشند، یا یک مسیر مطلق باشند (مانند \f[B]/drivers/block/loop\f[R]) که باید با کل مسیر ماژول منطبق باشد.
هنگامی که پسوند \f[B]/\f[R] داشته باشند، الگو با تمام ماژول‌های زیر آن دایرکتوری مطابقت خواهد داشت.
الگوها می‌توانند شامل الگوهای عمومی سبک پوسته باشند (\f[B]*\f[R]، \f[B]?\f[R]، \f[B][\&...\-\&...]\f[R]).
اگر مقدار ویژه \f[B]default\f[R] استفاده شود، ماژول‌های هسته پیش‌فرض تعریف‌شده در پیکربندی \f[B]mkosi\-initrd\f[R] نیز اضافه می‌شوند.
اگر مقدار ویژه \f[B]host\f[R] استفاده شود، ماژول‌هایی که هم‌اکنون روی سیستم میزبان بارگذاری شده‌اند نیز اضافه خواهند شد.
.RE
.TP
\f[B]KernelModulesInitrd=\f[R], \f[B]\-\-kernel\-modules\-initrd=\f[R]
یک مقدار بولی است که به طور پیش‌فرض فعال (true) است.
در صورت فعال بودن، هنگام ساخت یک تصویر قابل بوت، \f[B]mkosi\f[R] یک initrd اضافی برای هر تصویر یکپارچه هسته که سرهم می‌کند ایجاد خواهد کرد.
این initrd فقط شامل ماژول‌ها و احتمالاً سفت‌افزارها است و سپس به initrd پایه افزوده می‌شود تا فایل نهایی initrd تشکیل شود.
این کار initrd پایه را مستقل از هسته نگه می‌دارد و تنها هنگام سرهم‌بندی UKI، ماژول‌های لازم مختص به نسخه هسته را به آن می‌افزاید.
.RS
در صورت غیرفعال بودن، هیچ initrd اضافی تولید نمی‌شود.
توجه داشته باشید که ماژول‌های هسته همچنان در initrd پایه گنجانده \f[B]نخواهند شد\f[R] و آن initrd مستقل از هسته باقی می‌ماند.
در عوض، فرض بر این است که کاربر ماژول‌های لازم را، در صورت نیاز، از طریق یک initrd سفارشی تکمیلی فراهم می‌کند.
.RE.TP
\f[B]KernelInitrdModules=\f[R], \f[B]\-\-kernel\-modules\-initrd\-include=\f[R]
مانند \f[B]KernelModules=\f[R] است، اما ماژول‌های کرنل را برای گنجاندن در initrd مشخص می‌کند.
.TP
\f[B]FirmwareFiles=\f[R], \f[B]\-\-firmware\-files=\f[R]
فهرستی از الگوهای انطباق مسیر (glob) را می‌گیرد که مشخص می‌کنند کدام فایل‌های سفت‌افزار (firmware) در ایمیج گنجانده شوند.
الگوها به همان شیوهٔ تنظیمات \f[B]KernelModules=\f[R] تفسیر می‌شوند، جز اینکه مسیرها نسبت به \f[B]/usr/lib/firmware/<subdir>\f[R] سنجیده می‌شوند.
پسوند فشرده‌سازی نادیده گرفته می‌شود و نباید در الگو گنجانده شود.
.RS
وابستگی‌های سفت‌افزار ماژول‌های کرنلِ نصب‌شده در ایمیج به‌طور خودکار گنجانده می‌شوند.
مثال: هر دو مقدار \f[B]FirmwareFiles=cxgb4/bcm8483.bin\f[R] یا \f[B]FirmwareFiles=bcm8483.*\f[R] موجب می‌شوند که \f[B]/usr/lib/firmware/cxgb4/bcm8483.bin.xz\f[R] حتی اگر توسط ماژولی فهرست نشده باشد، اضافه شود.
.RE
.TP
\f[B]Locale=\f[R], \f[B]\-\-locale=\f[R], \f[B]LocaleMessages=\f[R], \f[B]\-\-locale\-messages=\f[R], \f[B]Keymap=\f[R], \f[B]\-\-keymap=\f[R], \f[B]Timezone=\f[R], \f[B]\-\-timezone=\f[R], \f[B]Hostname=\f[R], \f[B]\-\-hostname=\f[R], \f[B]RootShell=\f[R], \f[B]\-\-root\-shell=\f[R]
تنظیمات \f[B]Locale=\f[R]، \f[B]\-\-locale=\f[R]،
\f[B]LocaleMessages=\f[R]، \f[B]\-\-locale\-messages=\f[R]،
\f[B]Keymap=\f[R]، \f[B]\-\-keymap=\f[R]، \f[B]Timezone=\f[R]،
\f[B]\-\-timezone=\f[R]، \f[B]Hostname=\f[R]، \f[B]\-\-hostname=\f[R]،
\f[B]RootShell=\f[R]، \f[B]\-\-root\-shell=\f[R] متناظر با گزینه‌های
هم‌نام در systemd\-firstboot هستند.
برای اطلاعات بیشتر \f[B]systemd\-firstboot\f[R](1) را ببینید.
علاوه بر این، در صورت امکان، اعتبارسنجی‌های (credentials) متناظر systemd
برای این تنظیمات در \f[B]/usr/lib/credstore\f[R] نوشته می‌شوند تا
حتی در صورتی که فقط \f[B]/usr\f[R] در ایمیج ارائه شده باشد اعمال شوند.
.TP
\f[B]RootPassword=\f[R], \f[B]\-\-root\-password=\f[R],
گذرواژه ریشه (root) سیستم را تنظیم می‌کند.
اگر از این گزینه استفاده نشود، اما فایل \f[B]mkosi.rootpw\f[R] در دایرکتوری
محلی یافت شود، گذرواژه به‌طور خودکار از آن خوانده می‌شود، یا در صورت
اجرایی بودن فایل، مانند یک اسکریپت اجرا شده و به‌جای آن خروجی استاندارد
(stdout) خوانده می‌شود (بخش \f[B]SCRIPTS\f[R] در زیر را ببینید).
اگر گذرواژه با \f[B]hashed:\f[R] آغاز شود، با آن مانند یک گذرواژه ریشه
از قبل هش‌شده رفتار می‌شود.
گذرواژه ریشه همچنین در \f[B]/usr/lib/credstore\f[R] تحت credential
مناسب systemd ذخیره می‌شود تا حتی اگر فقط \f[B]/usr\f[R] در ایمیج
گنجانده شده باشد نیز اعمال گردد.
برای ایجاد یک حساب قفل‌نشده بدون گذرواژه، از \f[B]hashed:\f[R] بدون هیچ
هشی استفاده کنید.
.TP
\f[B]Autologin=\f[R], \f[B]\-\-autologin=\f[R], \f[B]\-a\f[R]
ورود خودکار (autologin) را برای کاربر \f[B]root\f[R] در \f[B]/dev/pts/0\f[R]
(nspawn)، \f[B]/dev/tty1\f[R] و \f[B]/dev/hvc0\f[R] فعال می‌کند.
.TP
\f[B]MakeInitrd=\f[R], \f[B]\-\-make\-initrd=\f[R]
فایل‌های \f[B]/etc/initrd\-release\f[R] و \f[B]/init\f[R] را به ایمیج
می‌افزاید تا بتواند به‌عنوان یک initramfs استفاده شود.
.TP
\f[B]Ssh=\f[R], \f[B]\-\-ssh=\f[R]
مشخص می‌کند که آیا یک واحد سوکت \f[B]sshd\f[R] و سرویس منطبق با آن
در ایمیج نهایی نصب شود یا خیر.
یکی از مقادیر \f[B]always\f[R]، \f[B]never\f[R]، \f[B]auto\f[R] یا
\f[B]runtime\f[R] را می‌گیرد.
پیش‌فرض \f[B]auto\f[R] است.
.RS
اگر روی \f[B]auto\f[R] تنظیم شود و \f[B]sshd\f[R] در ایمیج موجود باشد
اما باینری مولد \f[B]systemd\-ssh\-generator\f[R] وجود نداشته باشد،
یا اگر روی \f[B]always\f[R] تنظیم شود، mkosi واحدهای \f[B]sshd\f[R] را
در ایمیج نهایی نصب می‌کند که SSH را روی VSock ارائه می‌دهند.
اگر روی \f[B]never\f[R] تنظیم شود، mkosi این واحدها را نصب نمی‌کند.
اگر مقدار \f[B]runtime\f[R] استفاده شود، mkosi هیچ واحدی را نصب
نخواهد کرد اما در صورتی که هیچ اطلاعات اعتباری SSH پیکربندی نشده باشد،
راه‌اندازی \f[B]mkosi vm\f[R] را لغو می‌کند.
هنگام ساخت با این گزینه و اجرای ایمیج با استفاده از \f[B]mkosi vm\f[R]،
می‌توان از دستور \f[B]mkosi ssh\f[R] برای اتصال به کانتینر/ماشین مجازی
از طریق SSH استفاده کرد.
توجه داشته باشید که همچنان باید مطمئن شوید openssh در ایمیج نصب شده
است تا \f[B]mkosi ssh\f[R] به‌درستی کار کند.
دستور \f[B]mkosi genkey\f[R] را اجرا کنید تا به‌طور خودکار یک گواهی
X.509 و کلید خصوصی تولید شود که توسط \f[B]mkosi\f[R] جهت فعال‌سازی
دسترسی SSH به هر ماشین مجازی از طریق \f[B]mkosi ssh\f[R] استفاده می‌شود.
برای دسترسی به ایمیج‌های بوت‌شده با استفاده از \f[B]mkosi boot\f[R]،
از \f[B]machinectl\f[R] استفاده کنید.
از نسخه systemd v256 به بعد، systemd\-ssh\-generator(8) هنگام اجرا در
داخل یک ماشین مجازی به‌طور خودکار \f[B]sshd\f[R] را روی VSock ارائه می‌دهد.
بنابراین اگر از نسخهٔ جدیدی از systemd در یک ماشین مجازی استفاده می‌کنید،
این گزینه معمولاً به کار نمی‌رود.
همچنان لازم است openssh در ایمیج نصب باشد، و تنظیم پیش‌فرض
\f[B]\-\-vsock=auto\f[R] برای اطمینان از در دسترس بودن VSock درون ماشین
مجازی کافی است.
نکته: اگر توزیع ایمیج از SELinux استفاده می‌کند، دسترسی سرویس sshd
مربوط به mkosi به VSock مسدود خواهد شد که منجر به عدم اتصال به آن
از سمت میزبان می‌شود.
لازم است یا اجرای SELinux (حالت enforcement) را غیرفعال کنید، یا یک
ماژول سیاست سفارشی بسازید (برای مثال با \f[B]audit2allow\f[R]).
.RE
.TP
\f[B]SELinuxRelabel=\f[R], \f[B]\-\-selinux\-relabel=\f[R]
مشخص می‌کند که آیا برچسب‌گذاری مجدد فایل‌ها برای تطابق با سیاست
SELinux ایمیج انجام شود یا خیر.
یک مقدار بولی یا \f[B]auto\f[R] می‌گیرد.
پیش‌فرض \f[B]auto\f[R] است.
اگر غیرفعال باشد، برچسب فایل‌ها مجدداً تعیین نخواهد شد.
اگر فعال باشد، باید یک سیاست SELinux در ایمیج نصب شده باشد و
\f[B]setfiles\f[R] برای برچسب‌گذاری مجدد فایل‌ها در دسترس باشد.
اگر در حین \f[B]setfiles\f[R] خطایی رخ دهد، ساخت با شکست مواجه می‌شود.
اگر روی \f[B]auto\f[R] تنظیم شود، فایل‌ها در صورتی که mkosi در حال ساخت
یک ایمیج دایرکتوری نباشد، یک سیاست SELinux در ایمیج نصب باشد و
\f[B]setfiles\f[R] در دسترس باشد، برچسب‌گذاری مجدد خواهند شد.
هرگونه خطای رخ‌داده در حین \f[B]setfiles\f[R] نادیده گرفته خواهد شد.
.RS
توجه داشته باشید که هنگام اجرا با اختیارات غیرریشه (unprivileged)،
ابزار \f[B]setfiles\f[R] در اعمال برچسب‌هایی که در سیاست SELinux
سیستم میزبان وجود ندارند، با شکست مواجه خواهد شد.
برای اطمینان از اینکه \f[B]setfiles\f[R] بدون خطا با موفقیت انجام می‌شود،
مطمئن شوید که \f[B]mkosi\f[R] را با کاربر root اجرا می‌کنید یا ساخت را
از روی سیستم میزبانی انجام می‌دهید که سیاست SELinux یکسانی با ایمیج در
حال ساخت دارد.
.RE
.TP
\f[B]MachineId=\f[R], \f[B]\-\-machine\-id=\f[R]
یک UUID یا مقدار ویژهٔ \f[B]random\f[R] را می‌گیرد.
شناسه ماشین (machine ID) ایمیج را روی UUID مشخص‌شده تنظیم می‌کند.
اگر روی \f[B]random\f[R] تنظیم شود، یک UUID تصادفی در
\f[B]/etc/machine\-id\f[R] نوشته خواهد شد.
اگر به‌طور صریح مشخص نشود و فایل \f[B]mkosi.machine\-id\f[R] در دایرکتوری
محلی وجود داشته باشد، UUID مورد استفاده از آن خوانده می‌شود.
در غیر این صورت، مقدار \f[B]uninitialized\f[R] در
\f[B]/etc/machine\-id\f[R] نوشته خواهد شد..SS بخش [Validation]
.TP
\f[B]SecureBoot=\f[R], \f[B]\-\-secure\-boot=\f[R]
امضای \f[B]systemd\-boot\f[R] (اگر هنوز امضا نشده باشد) و هر تصویر هسته یکپارچه (unified kernel image) ایجاد شده برای UEFI SecureBoot.
.TP
\f[B]SecureBootAutoEnroll=\f[R], \f[B]\-\-secure\-boot\-auto\-enroll=\f[R]
راه‌اندازی ثبت خودکار کلیدهای secure boot در ماشین‌های مجازی بر اساس مستندات \f[B]systemd\-boot\f[R](7) در صورتی که \f[B]SecureBoot=\f[R] استفاده شده باشد.
توجه داشته باشید که \f[B]systemd\-boot\f[R] تنها از systemd نسخه v253 به بعد ثبت خودکار کلیدهای secure boot را در ماشین‌های مجازی انجام خواهد داد.
برای انجام ثبت خودکار در systemd نسخه v252 یا بر روی ماشین‌های فیزیکی (bare metal)، با استفاده از یک درخت اضافی (extra tree) یک فایل پیکربندی \f[B]systemd\-boot\f[R] حاوی \f[B]secure\-boot\-enroll force\f[R] یا \f[B]secure\-boot\-enroll manual\f[R] در مسیر \f[B]/efi/loader/loader.conf\f[R] بنویسید.
ثبت خودکار در نسخه‌های قدیمی‌تر از v252 در systemd پشتیبانی نمی‌شود.
پیش‌فرض \f[B]yes\f[R] است.
.TP
\f[B]SecureBootKey=\f[R], \f[B]\-\-secure\-boot\-key=\f[R]
مسیر فایل PEM حاوی کلید خصوصی برای امضای تصویر هسته UEFI در صورت استفاده از \f[B]SecureBoot=\f[R]، و همچنین امضاهای PCR در صورتی که \f[B]SignExpectedPcr=\f[R] نیز استفاده شده باشد.
هنگامی که \f[B]SecureBootKeySource=\f[R] تعیین شده باشد، نوع ورودی به منبع بستگی دارد.
.TP
\f[B]SecureBootCertificate=\f[R], \f[B]\-\-secure\-boot\-certificate=\f[R]
مسیر فایل X.509 حاوی گواهی برای تصویر هسته امضا شده UEFI، در صورتی که \f[B]SecureBoot=\f[R] استفاده شود.
.TP
\f[B]SecureBootSignTool=\f[R], \f[B]\-\-secure\-boot\-sign\-tool=\f[R]
ابزار مورد استفاده برای امضای فایل‌های باینری PE در secure boot.
یکی از مقادیر \f[B]systemd\-sbsign\f[R]، \f[B]sbsign\f[R] یا \f[B]auto\f[R] را می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
اگر بر روی \f[B]auto\f[R] تنظیم شود، در صورت در دسترس بودن، یکی از ابزارهای \f[B]systemd\-sbsign\f[R] یا \f[B]sbsign\f[R] استفاده می‌شود که اولویت با \f[B]systemd\-sbsign\f[R] خواهد بود.
.TP
\f[B]Verity=\f[R], \f[B]\-\-verity=\f[R]
تعیین اینکه آیا verity برای تصاویر افزونه (extension images) اعمال یا غیرفعال شود.
یکی از مقادیر \f[B]signed\f[R]، \f[B]hash\f[R]، \f[B]defer\f[R]، \f[B]auto\f[R] یا یک مقدار بولی را می‌پذیرد.
اگر بر روی \f[B]signed\f[R] تنظیم شود، کلید و گواهی verity باید موجود باشند و اگر هیچ پارتیشن verity در تصویر دیسک ایجاد شده توسط \f[B]systemd\-repart\f[R] شناسایی نشود، فرایند ساخت شکست خواهد خورد.
اگر غیرفعال شود، پارتیشن‌های verity از تصاویر افزونه تولید شده توسط \f[B]systemd\-repart\f[R] حذف خواهند شد.
اگر بر روی \f[B]hash\f[R] تنظیم شود، \f[B]mkosi\f[R] ابزار \f[B]systemd\-repart\f[R] را برای ایجاد یک پارتیشن هش verity بدون پارتیشن امضا پیکربندی می‌کند.
اگر بر روی \f[B]defer\f[R] تنظیم شود، فضا برای پارتیشن امضای verity اختصاص داده می‌شود اما هنوز پر نخواهد شد.
اگر بر روی \f[B]auto\f[R] تنظیم شده و کلید و گواهی verity موجود باشند، \f[B]mkosi\f[R] آن‌ها را به \f[B]systemd\-repart\f[R] منتقل کرده و انتظار دارد که تصویر دیسک تولید شده شامل پارتیشن‌های verity باشد، اما اگر هیچ پارتیشن verity در تصویر دیسک ایجاد شده توسط \f[B]systemd\-repart\f[R] یافت نشود، ساخت با خطا متوقف نخواهد شد.
.RS
توجه داشته باشید که غیرفعال‌سازی صریح امضا و/یا هش verity هنوز برای خروجی \f[B]disk\f[R] پیاده‌سازی نشده است و در حال حاضر فقط برای تصاویر افزونه کار می‌کند.
.RE
.TP
\f[B]VerityKey=\f[R], \f[B]\-\-verity\-key=\f[R]
مسیر فایل PEM حاوی کلید خصوصی برای امضای پارتیشن امضای verity، در صورتی که یک پارتیشن امضای verity با \f[B]systemd\-repart\f[R] افزوده شده باشد.
هنگامی که \f[B]VerityKeySource=\f[R] تعیین شده باشد، نوع ورودی به منبع بستگی دارد.
.TP
\f[B]VerityCertificate=\f[R], \f[B]\-\-verity\-certificate=\f[R]
مسیر فایل X.509 حاوی گواهی برای امضای پارتیشن امضای verity، در صورتی که یک پارتیشن امضای verity با \f[B]systemd\-repart\f[R] افزوده شده باشد.
.TP
\f[B]SignExpectedPcr=\f[R], \f[B]\-\-sign\-expected\-pcr=\f[R]
سنجش اجزای تصویر هسته یکپارچه (UKI) با استفاده از \f[B]systemd\-measure\f[R] و جاسازی امضای PCR درون تصویر هسته یکپارچه.
این گزینه یک مقدار بولی یا مقدار ویژه \f[B]auto\f[R] (که پیش‌فرض است) می‌پذیرد؛ در صورتی که باینری \f[B]systemd\-measure\f[R] در \f[B]PATH\f[R] موجود باشد، مقدار auto معادل یک مقدار true خواهد بود.
به فعال بودن \f[B]SecureBoot=\f[R] و کلید ارائه‌شده در \f[B]SecureBootKey=\f[R] وابسته است.
.TP
\f[B]SignExpectedPcrKey=\f[R], \f[B]\-\-sign\-expected\-pcr\-key=\f[R]
مسیر فایل PEM حاوی کلید خصوصی برای امضای امضاهای PCR مورد انتظار.
هنگامی که \f[B]SignExpectedPcrKeySource=\f[R] مشخص شده باشد، نوع ورودی به منبع بستگی دارد.
.TP
\f[B]SignExpectedPcrCertificate=\f[R], \f[B]\-\-sign\-expected\-pcr\-certificate=\f[R]
مسیر فایل X.509 حاوی گواهی برای امضای امضاهای PCR مورد انتظار.
.TP
\f[B]SignInitrdPCRs=\f[R], \f[B]\-\-sign\-initrd\-pcrs=\f[R]
تعیین اینکه آیا سیاست‌های PCR امضاشده‌ای که تنها از طریق initrd برآورده می‌شوند تولید گردند یا خیر.
این مورد برای مقداردهی اولیه NvPCRs الزامی است.
این گزینه یک مقدار بولی یا مقدار ویژه \f[B]auto\f[R] را می‌پذیرد که پیش‌فرض است و در صورتی که امضای PCR فعال باشد (نگاه کنید به \f[B]SignExpectedPcr=\f[R]) و نسخه \f[B]ukify\f[R] حداقل v262 باشد، معادل یک مقدار true است.
امضا با کلیدی انجام می‌شود که به \f[B]SignExpectedPcrKey=\f[R] داده شده است.
.TP
\f[B]SecureBootKeySource=\f[R], \f[B]\-\-secure\-boot\-key\-source=\f[R], \f[B]VerityKeySource=\f[R], \f[B]\-\-verity\-key\-source=\f[R], \f[B]SignExpectedPcrKeySource=\f[R], \f[B]\-\-sign\-expected\-key\-source=\f[R]
منبع کلید خصوصی متناظر، جهت پشتیبانی از موتورها (engines) و فراهم‌کننده‌های (providers) OpenSSL،
به‌عنوان مثال \f[B]\-\-secure\-boot\-key\-source=engine:pkcs11\f[R] یا \f[B]\-\-secure\-boot\-key\-source=provider:pkcs11\f[R].
.TP
\f[B]SecureBootCertificateSource=\f[R], \f[B]\-\-secure\-boot\-certificate\-source=\f[R], \f[B]VerityCertificateSource=\f[R], \f[B]\-\-verity\-certificate\-source=\f[R], \f[B]SignExpectedPcrCertificateSource=\f[R], \f[B]\-\-sign\-expected\-certificate\-source=\f[R]
منبع گواهی متناظر، جهت پشتیبانی از فراهم‌کننده‌های OpenSSL،
به‌عنوان مثال \f[B]\-\-secure\-boot\-certificate\-source=provider:pkcs11\f[R].
توجه داشته باشید که موتورها (engines) پشتیبانی نمی‌شوند.
.TP
\f[B]Passphrase=\f[R], \f[B]\-\-passphrase=\f[R]
تعیین مسیر فایل حاوی عبارت عبور (passphrase) برای استفاده در رمزگذاری LUKS.
این فایل باید شامل عبارت عبور به صورت کلمه‌به‌کلمه بوده و با نویسه خط جدید پایان نیابد (یعنی با همان قالبی که \f[B]cryptsetup\f[R] و \f[B]/etc/crypttab\f[R] برای فایل‌های عبارت عبور انتظار دارند).
فایل باید دارای حالت دسترسی 0600 یا محدودتر باشد.
.RS
توجه داشته باشید که این تنظیم به‌تنهایی هیچ رمزگذاری را فعال نمی‌کند.
همچنین باید یک یا چند فایل تعریف پارتیشن را با \f[B]Encrypt=key\-file\f[R] به \f[B]mkosi.repart/\f[R] اضافه کنید تا پارتیشن‌های رمزگذاری‌شده به تصویر اضافه شوند.
.RE
.TP
\f[B]Checksum=\f[R], \f[B]\-\-checksum=\f[R]
ایجاد یک فایل \f[B]<output>.SHA256SUMS\f[R] از تمام اقلام تولیدشده پس از اتمام فرایند ساخت.
.TP
\f[B]Sign=\f[R], \f[B]\-\-sign=\f[R]
امضای فایل \f[B]SHA256SUMS\f[R] تولیدشده با استفاده از \f[B]gpg\f[R] پس از پایان کار.
.TP
\f[B]OpenPGPTool=\f[R], \f[B]\-\-openpgp\-tool=\f[R]
پیاده‌سازی OpenPGP مورد استفاده برای امضا کردن.
پیش‌فرض \f[B]gpg\f[R] است.
انتخاب مقداری متفاوت از پیش‌فرض، از ابزار مشخص‌شده Stateless OpenPGP (SOP) برای امضای فایل \f[B]SHA256SUMS\f[R] استفاده خواهد کرد.
.RS
نمونه‌های انتخابی شامل \f[B]sqop\f[R] و \f[B]rsop\f[R] هستند، اما هر پیاده‌سازی از https://www.openpgp.org/about/sop که بتواند به‌صورت محلی نصب شود کار خواهد کرد.
.RE
.TP
\f[B]Key=\f[R], \f[B]\-\-key=\f[R]
انتخاب کلید \f[B]gpg\f[R] برای استفاده در امضای \f[B]SHA256SUMS\f[R].
این کلید باید از قبل در دسته‌کلید (keyring) برنامه \f[B]gpg\f[R] موجود باشد..SS بخش [Build]
.TP
\f[B]ToolsTree=\f[R], \f[B]\-\-tools\-tree=\f[R]
در صورت تعیین، برنامه‌های اجراشده توسط \f[B]mkosi\f[R] برای ساخت و بوت کردن یک ایمیج، به جای سیستم میزبان، درون درخت داده‌شده جستجو می‌شوند.
از این گزینه برای بازتولیدپذیرتر کردن ساخت ایمیج با استفادهٔ همیشگی از نسخه‌های یکسان برنامه‌ها جهت ساخت ایمیج نهایی استفاده کنید، به جای هر نسخه‌ای که روی سیستم میزبان نصب است.
اگر این گزینه استفاده نشود، اما دایرکتوری \f[B]mkosi.tools/\f[R] در دایرکتوری محلی یافت شود، به طور خودکار برای این منظور با دایرکتوری ریشه به عنوان مقصد استفاده خواهد شد.
.RS
دایرکتوری درخت ابزارها بین ساخت‌های مکرر ایمیج حفظ می‌شود، مگر آنکه با فراخوانی \f[B]mkosi clean \-f\f[R] پاکسازی شود.
توجه داشته باشید باینری‌های یافت‌شده در هر یک از مسیرهای پیکربندی‌شده با \f[B]ExtraSearchPaths=\f[R] با \f[B]/usr/\f[R] برگرفته از درخت ابزارها به جای سیستم میزبان اجرا خواهند شد.
اگر توزیع یا انتشار میزبان به ترتیب با توزیع یا انتشار درخت ابزارها مطابقت نداشته باشد، این امر ممکن است هنگام تلاش برای اجرای باینری‌ها از هر یک از مسیرهای جستجوی اضافی به شکست بیانجامد.
اگر روی \f[B]yes\f[R] تنظیم شود، \f[B]mkosi\f[R] به طور خودکار یک ایمیج اضافی از درخت ابزارها می‌افزاید و از آن به عنوان درخت ابزارها استفاده می‌کند.
این ایمیج را می‌توان با استفاده از تنظیمات زیر و با \f[B]mkosi.tools.conf\f[R] که می‌تواند فایل یا دایرکتوری حاوی پیکربندی اضافی برای درخت ابزارهای پیش‌فرض باشد، بیشتر پیکربندی کرد.
برای جزئیات بیشتر بخش \f[B]TOOLS TREE\f[R] را ببینید.
.RE
.TP
\f[B]ToolsTreeDistribution=\f[R], \f[B]\-\-tools\-tree\-distribution=\f[R]
توزیع مورد استفاده برای درخت ابزارهای پیش‌فرض را تعیین می‌کند.
به طور پیش‌فرض روی توزیع میزبان تنظیم است، مگر اینکه توزیع میزبان (نه مقصد) Ubuntu باشد که پیش‌فرض به Debian تغییر می‌کند، و RHEL، CentOS، Alma و Rocky که پیش‌فرض به Fedora تغییر می‌کنند، یا \f[B]custom\f[R] اگر توزیع میزبان یک توزیع پشتیبانی‌شده نباشد.
.TP
\f[B]ToolsTreeRelease=\f[R], \f[B]\-\-tools\-tree\-release=\f[R]
نسخه انتشار توزیع را برای استفاده در درخت ابزارهای پیش‌فرض تعیین می‌کند.
به طور پیش‌فرض، انتشار پیش‌فرض هاردکدشده در \f[B]mkosi\f[R] برای آن توزیع استفاده می‌شود.
.TP
\f[B]ToolsTreeProfiles=\f[R], \f[B]\-\-tools\-tree\-profile=\f[R]
پروفایل‌های فعال برای درخت ابزارهای پیش‌فرض را تعیین می‌کند.
یک فهرست جداشده با کاما متشکل از \f[B]devel\f[R]، \f[B]misc\f[R]، \f[B]package\-manager\f[R] و \f[B]runtime\f[R] می‌پذیرد.
به طور پیش‌فرض، تمام پروفایل‌ها به جز \f[B]devel\f[R] و \f[B]gui\f[R] فعال هستند.
.RS
پروفایل \f[B]devel\f[R] شامل ابزارهای مورد نیاز برای ساخت پروژه‌های (C/C++) است.
پروفایل \f[B]misc\f[R] شامل ابزارهای مفید گوناگونی است که داشتن آن‌ها در اسکریپت‌ها کاربردی و دم‌دست است.
پروفایل مدیر بسته شامل مدیرهای بسته و ابزارهای مرتبط به جز ابزارهای بومی توزیع درخت ابزارها است.
پروفایل \f[B]runtime\f[R] شامل ابزارهای مورد نیاز برای بوت کردن ایمیج‌ها در یک کانتینر systemd\-nspawn یا در یک ماشین مجازی است.
پروفایل \f[B]gui\f[R] شامل ابزارهای مورد نیاز برای بوت کردن ایمیج‌ها در یک ماشین مجازی همراه با پشتیبانی از صوت و تصویر است.
.RE
.TP
\f[B]ToolsTreeMirror=\f[R], \f[B]\-\-tools\-tree\-mirror=\f[R]
آینه (mirror) مورد استفاده برای درخت ابزارهای پیش‌فرض را تعیین می‌کند.
به طور پیش‌فرض، از آینهٔ پیش‌فرض توزیع درخت ابزارها استفاده می‌شود.
.TP
\f[B]ToolsTreeSnapshot=\f[R], \f[B]\-\-tools\-tree\-snapshot=\f[R]
مشابه \f[B]Snapshot=\f[R] اما برای درخت ابزارهای پیش‌فرض.
به طور پیش‌فرض، اگر توزیع درخت ابزارها با توزیع ایمیج مطابقت داشته باشد، از اسنپ‌شات ایمیج استفاده می‌شود.
.TP
\f[B]ToolsTreeRepositories=\f[R], \f[B]\-\-tools\-tree\-repository=\f[R]
مشابه \f[B]Repositories=\f[R] اما برای درخت ابزارهای پیش‌فرض.
.TP
\f[B]ToolsTreeSandboxTrees=\f[R], \f[B]\-\-tools\-tree\-sandbox\-tree=\f[R]
مشابه \f[B]SandboxTrees=\f[R] اما برای درخت ابزارهای پیش‌فرض.
.TP
\f[B]ToolsTreePackages=\f[R], \f[B]\-\-tools\-tree\-package=\f[R]
بسته‌های اضافی برای نصب در درخت ابزارهای پیش‌فرض.
فهرستی از مشخصات بسته‌ها که با کاما از هم جدا شده‌اند می‌پذیرد.
این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست بسته‌های مشخص‌شده با هم ترکیب می‌شوند.
.TP
\f[B]ToolsTreePackageDirectories=\f[R], \f[B]\-\-tools\-tree\-package\-directory=\f[R]
مشابه \f[B]PackageDirectories=\f[R]، اما برای درخت ابزارهای پیش‌فرض.
.TP
\f[B]ToolsTreeCertificates=\f[R], \f[B]\-\-tools\-tree\-certificates=\f[R]
مشخص می‌کند که آیا از گواهی‌ها و کلیدهای درون درخت ابزارها استفاده شود یا خیر.
به طور پیش‌فرض فعال است.
در صورت فعال بودن، \f[B]/etc/pki/ca\-trust\f[R]، \f[B]/etc/pki/tls\f[R]، \f[B]/etc/ssl\f[R]، \f[B]/etc/ca\-certificates\f[R] و \f[B]/var/lib/ca\-certificates\f[R] از درخت ابزارها استفاده می‌شوند.
در غیر این صورت، این دایرکتوری‌ها از سیستم میزبان دریافت می‌شوند.
.TP
\f[B]ExtraSearchPaths=\f[R], \f[B]\-\-extra\-search\-path=\f[R]
فهرستی از مسیرهای جداشده با دونقطه برای جستجوی ابزارها در آن‌ها، پیش از بررسی مسیر جستجوی معمولی \f[B]$PATH\f[R].
.TP
\f[B]Incremental=\f[R], \f[B]\-\-incremental=\f[R], \f[B]\-i\f[R]
یا \f[B]strict\f[R] یا یک مقدار بولی را به عنوان آرگومان می‌پذیرد.
حالت ساخت افزایشی را فعال می‌کند.
در این حالت، بلافاصله پس از نصب تمام بسته‌های سیستم‌عامل و اجرای اسکریپت‌های آماده‌سازی (prepare)، اما پیش از فراخوانی اسکریپت‌های \f[B]mkosi.build\f[R] (یا هر کاری که پس از آن رخ می‌دهد)، رونوشتی از ایمیج سیستم‌عامل ایجاد می‌شود.
در فراخوانی‌های بعدی \f[B]mkosi\f[R] همراه با سوییچ \f[B]\-i\f[R]، این ایمیج کَش‌شده می‌تواند برای صرف‌نظر از نصب بسته‌های سیستم‌عامل استفاده شود، و بدین‌سان زمان ساخت‌های تکراری را به شدت کاهش دهد.
توجه داشته باشید که اگرچه یک سازوکار ابتدایی برای باطل کردن کش وجود دارد، اما قطعاً بی‌نقص نیست.
برای اجبار به بازسازی ایمیج کَش‌شده، \f[B]\-i\f[R] را با \f[B]\-ff\f[R] ترکیب کنید تا مطمئن شوید ایمیج کش‌شده ابتدا حذف و سپس دوباره ساخته می‌شود.
.RS
اگر روی \f[B]strict\f[R] تنظیم شود، در صورت عدم وجود ایمیج کَش‌شدهٔ از پیش ساخته‌شده، ساخت با شکست مواجه می‌شود.
.RE
.TP
\f[B]CacheOnly=\f[R], \f[B]\-\-cache\-only=\f[R]
یکی از مقادیر \f[B]auto\f[R]، \f[B]metadata\f[R]، \f[B]always\f[R] یا \f[B]never\f[R] را می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
در صورت انتخاب \f[B]always\f[R]، به مدیر بسته دستور داده می‌شود که به شبکه متصل نشود.
تا زمانی که کش بسته‌ها از قبل کاملاً پر شده باشد، این کار سطح حداقلی از بازتولیدپذیری را فراهم می‌کند.
اگر روی \f[B]metadata\f[R] تنظیم شود، مدیر بسته همچنان می‌تواند بسته‌ها را بارگیری کند، اما متادیتای مخزن همگام‌سازی نخواهد شد.
اگر روی \f[B]auto\f[R] تنظیم شود، متادیتای مخزن هنگامی همگام‌سازی می‌شود که پیش از آن هیچ ایمیجی ساخته نشده باشد، یا زمانی که تمام ایمیج‌ها از قبل کَش شده باشند (به \f[B]Incremental=\f[R] مراجعه کنید) و حداقل یکی از آن کَش‌ها اکنون منسوخ شده باشد (که در این حالت تمام ایمیج‌های کَش‌شده باطل می‌شوند).
بسته‌ها می‌توانند در حین ساخت بارگیری شوند.
اگر روی \f[B]never\f[R] تنظیم شود، متادیتای مخزن همواره همگام‌سازی می‌شود و بسته‌ها می‌توانند در طول ساخت بارگیری شوند.
.TP
\f[B]SandboxTrees=\f[R], \f[B]\-\-sandbox\-tree=\f[R]
فهرستی جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه را می‌پذیرد.
مسیر نخست از هر جفت، به دایرکتوری‌ای اشاره دارد که باید پیش از اجرای یک ابزار، به درون سندباکس mkosi کپی شود.
مسیر دوم هر جفت، به دایرکتوری مقصد در درون سندباکس اشاره می‌کند.
اگر مسیر دوم ارائه نشود، دایرکتوری بر روی دایرکتوری ریشهٔ سندباکس کپی می‌شود.
مسیر دوم همواره به عنوان یک مسیر مطلق تفسیر می‌شود.
اگر دایرکتوری \f[B]mkosi.sandbox/\f[R] در دایرکتوری محلی یافت شود، با دایرکتوری ریشه به عنوان مقصد برای این منظور استفاده می‌شود (همچنین بخش \f[B]FILES\f[R] در زیر را ببینید).
.RS
دستور \f[B]mkosi\f[R] پیکربندی مدیر بسته و فایل‌های مرتبط را در درخت‌های سندباکس پیکربندی‌شده جستجو می‌کند.
مگر آنکه جور دیگری مشخص شده باشد، از فایل‌های پیکربندی در مکان‌های معمول آن‌ها در \f[B]/usr\f[R] یا \f[B]/etc\f[R] در درخت‌های سندباکس استفاده خواهد کرد.
به عنوان نمونه، در صورتی که برای نصب بسته‌ها از \f[B]dnf\f[R] استفاده شود، در درخت‌های سندباکس به دنبال \f[B]/etc/dnf/dnf.conf\f[R] خواهد گشت.
.RE
.TP
\f[B]WorkspaceDirectory=\f[R], \f[B]\-\-workspace\-directory=\f[R]
مسیر به دایرکتوری‌ای برای ذخیره داده‌های مورد نیاز به صورت موقت در حین ساخت ایمیج.
این دایرکتوری باید فضای کافی برای ذخیره کل ایمیج سیستم‌عامل داشته باشد، هرچند در بیشتر حالت‌ها فضای دیسکِ عملاً مصرف‌شده کمتر است.
در صورت عدم تعیین، زیردایرکتوری‌ای از \f[B]$XDG_CACHE_HOME\f[R] (در صورت تنظیم بودن)، \f[B]$CACHE_DIRECTORY\f[R] (در صورت تنظیم بودن)، \f[B]$HOME/.cache\f[R] (در صورت تنظیم بودن) یا \f[B]/var/tmp\f[R] استفاده می‌شود.
.RS
داده‌های درون این دایرکتوری پس از هر ساخت به طور خودکار پاک می‌شوند.
در صورتی که اجرای \f[B]mkosi\f[R] به طور غیرعادی لغو شود (برای نمونه به دلیل راه‌اندازی مجدد یا قطعی برق)، پاک کردن دستی محتویات این دایرکتوری خطری ندارد.
.RE
.TP
\f[B]CacheDirectory=\f[R], \f[B]\-\-cache\-directory=\f[R]
مسیری به یک دایرکتوری برای استفاده به عنوان دایرکتوری کش افزایشی برای ایمیج‌های افزایشی تولیدشده در هنگام فعال بودن گزینهٔ \f[B]Incremental=\f[R] می‌پذیرد.
اگر از این گزینه استفاده نشود، اما دایرکتوری \f[B]mkosi.cache/\f[R] در دایرکتوری محلی موجود باشد، به صورت خودکار برای این منظور به کار می‌رود.
.TP
\f[B]CacheKey=\f[R], \f[B]\-\-cache\-key=\f[R]
زیردایرکتوری درون دایرکتوری کش را که ایمیج کَش‌شده در آن ذخیره می‌شود، مشخص می‌کند.
این مقدار ممکن است شامل هر دو دستهٔ مشخصه‌گرهای عادی (به \f[B]Specifiers\f[R] مراجعه کنید) و مشخصه‌گرهای تأخیری ویژه باشد که در زیر شرح داده شده‌اند و به جای حین تحلیل پیکربندی، پس از اتمام تحلیل پیکربندی بسط می‌یابند.
قالب پیش‌فرض برای این پارامتر \f[B]&d\(ti&r\(ti&a\(ti&I\f[R] است.
.RS
مشخصه‌گرهای زیر می‌توانند استفاده شوند:
.PP
.TS
tab(@);
l l.
T{
مشخصه‌گر
T}@T{
مقدار
T}
_
T{
\f[B]&&\f[R]
T}@T{
نویسهٔ \f[B]&\f[R]
T}
T{
\f[B]&d\f[R]
T}@T{
\f[B]Distribution=\f[R]
T}
T{
\f[B]&r\f[R]
T}@T{
\f[B]Release=\f[R]
T}
T{
\f[B]&a\f[R]
T}@T{
\f[B]Architecture=\f[R]
T}
T{
\f[B]&i\f[R]
T}@T{
\f[B]ImageId=\f[R]
T}
T{
\f[B]&v\f[R]
T}@T{
\f[B]ImageVersion=\f[R]
T}
T{
\f[B]&I\f[R]
T}@T{
نام زیرایمیج درون mkosi.images/ یا \f[B]main\f[R]
T}
.TE
توجه داشته باشید که تمام ایمیج‌ها در یک ساخت باید یک کلید کش یکتا داشته باشند.
.RE.TP
\f[B]PackageCacheDirectory=\f[R], \f[B]\-\-package\-cache\-dir=\f[R]
مسیری به یک دایرکتوری را می‌گیرد تا به عنوان دایرکتوری حافظهٔ موقت بسته برای مدیر بستهٔ توزیعِ استفاده‌شده به کار رود.
اگر تنظیم نشده باشد، اما یک دایرکتوری \f[B]mkosi.pkgcache/\f[R] در دایرکتوری محلی یافت شود، به‌طور خودکار برای این منظور استفاده می‌شود؛ در غیر این صورت، دایرکتوری مناسبی در دایرکتوری خانگی کاربر یا سیستم استفاده خواهد شد.
.TP
\f[B]BuildDirectory=\f[R], \f[B]\-\-build\-directory=\f[R]
مسیری به یک دایرکتوری را می‌گیرد تا به عنوان دایرکتوری ساخت برای سامانه‌های ساختی که از ساخت خارج از درخت مبدأ پشتیبانی می‌کنند (مانند Meson) استفاده شود.
دایرکتوری استفاده‌شده به این روش، بین ساخت‌های مکرر به اشتراک گذاشته می‌شود و به سامانهٔ ساخت اجازه می‌دهد مصنوعاتی (مانند فایل‌های شیء، فایل‌های اجرایی و \&...) را که در فراخوانی‌های قبلی تولید شده‌اند مجدداً به کار گیرد.
اسکریپت‌های ساخت می‌توانند مسیر این دایرکتوری را در متغیر محیطی \f[B]$BUILDDIR\f[R] بیابند.
این دایرکتوری هنگام فراخوانی \f[B]mkosi\-chroot\f[R] در زمان اجرای اسکریپت‌های ساخت، به دایرکتوری ریشهٔ تصویر متصل (mount) می‌شود.
اگر این گزینه مشخص نشده باشد، اما دایرکتوری \f[B]mkosi.builddir/\f[R] در دایرکتوری محلی موجود باشد، به‌طور خودکار برای این منظور استفاده می‌شود (همچنین بخش \f[B]FILES\f[R] در زیر را ببینید).
.TP
\f[B]BuildKey=\f[R], \f[B]\-\-build\-key=\f[R]
زیردایرکتوری درون دایرکتوری ساخت را که مصنوعات ساخت افزایشی باید در آن ذخیره شوند، مشخص می‌کند.
این مقدار می‌تواند شامل هردوی مشخص‌کننده‌های معمولی (بخش \f[B]Specifiers\f[R] را ببینید) و مشخص‌کننده‌های خاص تأخیری باشد که به جای زمان تجزیهٔ پیکربندی، پس از پایان تجزیهٔ پیکربندی بسط داده می‌شوند؛ این‌ها همان مشخص‌کننده‌های تأخیری هستند که توسط \f[B]CacheKey=\f[R] نیز پشتیبانی می‌شوند.
قالب پیش‌فرض برای این پارامتر \f[B]&d\(ti&r\(ti&a\f[R] است.
.RS
برای غیرفعال کردن کامل استفاده از زیردایرکتوری ساخت، مقدار تحت‌اللفظی \f[B]\-\f[R] را به این تنظیم اختصاص دهید.
.RE
.TP
\f[B]UseSubvolumes=\f[R], \f[B]\-\-use\-subvolumes=\f[R]
یک مقدار بولی یا \f[B]auto\f[R] می‌گیرد.
استفاده از زیرحجم‌های btrfs را برای خروجی‌های درخت دایرکتوری فعال یا غیرفعال می‌کند.
اگر فعال باشد، \f[B]mkosi\f[R] دایرکتوری ریشه را به عنوان یک زیرحجم btrfs ایجاد می‌کند و در صورت امکان از رونوشت‌های فوری زیرحجم btrfs برای کپی کردن درخت‌های پایه یا کش‌شده استفاده می‌کند که بسیار سریع‌تر از انجام یک کپی بازگشتی است.
اگر صراحتاً فعال شده باشد و \f[B]btrfs\f[R] نصب نباشد یا امکان ایجاد زیرحجم‌ها وجود نداشته باشد، خطایی صادر می‌شود.
اگر بر روی \f[B]auto\f[R] تنظیم شده باشد، نبود \f[B]btrfs\f[R] یا خطا در ایجاد زیرحجم‌ها نادیده گرفته می‌شود.
.TP
\f[B]RepartOffline=\f[R], \f[B]\-\-repart\-offline=\f[R]
مشخص می‌کند که آیا تصاویر دیسک با استفاده از دستگاه‌های loopback ساخته شوند یا خیر.
به‌طور پیش‌فرض فعال است.
هنگامی که فعال باشد، \f[B]systemd\-repart\f[R] از دستگاه‌های loopback برای ساخت تصاویر دیسک استفاده نخواهد کرد.
هنگامی که غیرفعال باشد، \f[B]systemd\-repart\f[R] همیشه از دستگاه‌های loopback برای ساخت تصاویر دیسک استفاده خواهد کرد.
.RS
توجه داشته باشید که هنگام استفاده از \f[B]RepartOffline=no\f[R]، دستور \f[B]mkosi\f[R] نمی‌تواند بدون دسترسی ممتاز اجرا شود و ساخت تصویر باید به عنوان کاربر root، خارج از هرگونه کانتینر و با در دسترس بودن دستگاه‌های loopback در سیستم میزبان انجام گیرد.
در حال حاضر دو سناریوی شناخته‌شده وجود دارد که در آن‌ها باید از \f[B]RepartOffline=no\f[R] استفاده شود.
نخست، هنگام استفاده از \f[B]Subvolumes=\f[R] در فایل تعریف پارتیشن repart است، زیرا زیرحجم‌ها را نمی‌توان بدون استفاده از دستگاه‌های loopback ایجاد کرد.
دوم، هنگام ایجاد سیستمی با SELinux و یک پارتیشن ریشهٔ XFS است.
از آن‌جا که \f[B]mkfs.xfs\f[R] از مقداردهی اولیهٔ یک سیستم فایل XFS با ویژگی‌های توسعه‌یافته پشتیبانی نمی‌کند، باید از دستگاه‌های loopback استفاده شود تا اطمینان حاصل گردد که ویژگی‌های توسعه‌یافتهٔ SELinux در سیستم فایل XFS تولیدشده قرار می‌گیرند.
.RE
.TP
\f[B]History=\f[R], \f[B]\-\-history=\f[R]
یک مقدار بولی می‌گیرد.
اگر فعال باشد، \f[B]mkosi\f[R] پیکربندی ارائه‌شده از طریق خط فرمان برای آخرین ساخت را در زیردایرکتوری \f[B].mkosi\-private\f[R] واقع در دایرکتوری‌ای که از آن فراخوانی شده است می‌نویسد.
سپس تا زمانی که تصویر مجدداً ساخته نشود، از این آرگومان‌ها استفاده می‌شود تا از وارد کردن مکرر آن‌ها جلوگیری به عمل آید.
.RS
برای ارائهٔ مثالی از چرایی مفید بودن این گزینه: اگر دستور \f[B]mkosi \-O my\-custom\-output\-dir \-f\f[R] و در ادامه \f[B]mkosi vm\f[R] را اجرا کنید، \f[B]mkosi\f[R] با این خطا که تصویر هنوز ساخته نشده است متوقف خواهد شد.
اگر دستور \f[B]mkosi \-O my\-custom\-output\-dir \-\-history=yes \-f\f[R] و در ادامه \f[B]mkosi vm\f[R] را اجرا کنید، طبق انتظار تصویری را که در مرحلهٔ قبل ساخته شده است بوت می‌کند.
.RE
.TP
\f[B]BuildSources=\f[R], \f[B]\-\-build\-sources=\f[R]
فهرستی جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه را می‌گیرد.
مسیر اول از هر جفت، به دایرکتوری‌ای از میزبان اشاره دارد که باید متصل شود.
مسیر دوم از هر جفت، به دایرکتوری‌ای اشاره دارد که دایرکتوری مبدأ باید هنگام اجرای اسکریپت‌ها در آن متصل شود.
به ابتدای هر مسیر هدف، پیشوند \f[B]/work/src\f[R] اضافه می‌شود و تمام منابع ساخت پیش از اتصال، بر اساس هدفشان به ترتیب واژه‌نگاشتی مرتب می‌شوند تا مسیرهای سطح بالاتر ابتدا متصل گردند.
اگر صراحتاً پیکربندی نشده باشد، دایرکتوری کاری فعلی در \f[B]/work/src\f[R] متصل می‌شود.
.TP
\f[B]BuildSourcesEphemeral=\f[R], \f[B]\-\-build\-sources\-ephemeral=\f[R]
یک مقدار بولی یا مقدار ویژهٔ \f[B]buildcache\f[R] را می‌گیرد.
به‌طور پیش‌فرض غیرفعال است.
مشخص می‌کند که آیا تغییرات اعمال‌شده در دایرکتوری‌های مبدأ، دایرکتوری کاری و موارد پیکربندی‌شده با \f[B]BuildSources=\f[R] ذخیره و ماندگار شوند یا خیر.
اگر فعال باشد، تمام دایرکتوری‌های مبدأ پس از اجرای تمامی اسکریپت‌های یک نوع خاص (به‌جز اسکریپت‌های همگام‌سازی)، هر بار به وضعیت اولیهٔ خود بازنشانی می‌شوند.
.RS
💥💣💥 اگر روی \f[B]buildcache\f[R] تنظیم شود، لایهٔ روکش (overlay) هنگام اجرای اسکریپت‌های ساخت دور انداخته نمی‌شود، بلکه در دایرکتوری ساخت که از طریق \f[B]BuildDirectory=\f[R] پیکربندی شده ذخیره می‌شود و در اجراهای بعدی مجدداً استفاده خواهد شد.
لایهٔ روکش همچنان برای سایر اسکریپت‌ها دور انداخته می‌شود.
این گزینه می‌تواند برای پیاده‌سازی کشینگ پیشرفته‌ترِ ساخت‌ها استفاده شود، اما ممکن است به وضعیت‌های غیرمنتظره در دایرکتوری مبدأ منجر شود.
هنگام استفاده از این گزینه، یک دایرکتوری ساخت حتماً باید پیکربندی شده باشد.
💥💣💥
.RE
.TP
\f[B]Environment=\f[R], \f[B]\-\-environment=\f[R]
متغیرهایی را به محیطی که مدیران بسته و اسکریپت‌های prepare/build/postinstall/finalize با آن اجرا می‌شوند، اضافه می‌کند.
فهرستی از انتساب‌های متغیر یا فقط نام متغیرها را که با فاصله جدا شده‌اند می‌گیرد.
در حالت دوم، مقادیر آن متغیرها از محیطی که \f[B]mkosi\f[R] در آن فراخوانی شده است انتقال داده می‌شوند.
این گزینه ممکن است بیش از یک بار مشخص شود که در این صورت تمام متغیرهای فهرست‌شده تنظیم خواهند شد.
اگر یک متغیر دو بار تنظیم شود، تنظیم بعدی جایگزین تنظیم قبلی می‌شود.
.TP
\f[B]EnvironmentFiles=\f[R], \f[B]\-\-env\-file=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌هایی را می‌گیرد که حاوی تعاریف متغیرهای محیطی برای اضافه شدن به محیط اسکریپت‌نویسی هستند.
اگر فایل \f[B]mkosi.env\f[R] در دایرکتوری محلی یافت شود، از آن استفاده می‌کند.
متغیرها ابتدا از \f[B]mkosi.env\f[R] (در صورت وجود)، سپس از فهرست فایل‌های داده‌شده و پس از آن از تنظیمات \f[B]Environment=\f[R] خوانده می‌شوند.
.TP
\f[B]WithTests=\f[R], \f[B]\-\-with\-tests=\f[R], \f[B]\-T\f[R]
اگر روی نادرست (false) تنظیم شود (یا زمانی که گزینهٔ خط فرمان استفاده شود)، هنگام فراخوانی اسکریپت‌های \f[B]mkosi.build\f[R] متغیر محیطی \f[B]$WITH_TESTS\f[R] روی \f[B]0\f[R] تنظیم می‌شود.
این قابلیت برای آن در نظر گرفته شده که توسط اسکریپت‌های ساخت جهت دور زدن آزمون‌های واحد یا یکپارچه‌سازی که معمولاً در طول فرایند ساخت مبدأ اجرا می‌شوند، به کار رود.
توجه داشته باشید که این گزینه هیچ اثری ندارد مگر اینکه اسکریپت‌های ساخت \f[B]mkosi.build\f[R] آن را پردازش و رعایت کنند.
.TP
\f[B]WithNetwork=\f[R], \f[B]\-\-with\-network=\f[R]
هنگامی که درست (true) باشد، دسترسی به شبکه را در زمان فراخوانی اسکریپت‌های ساخت \f[B]mkosi.build\f[R] فعال می‌کند.
به‌طور پیش‌فرض، اسکریپت‌های ساخت در حالتی اجرا می‌شوند که شبکه غیرفعال است.
متغیر محیطی \f[B]$WITH_NETWORK\f[R] به اسکریپت‌های ساخت \f[B]mkosi.build\f[R] منتقل می‌شود که نشان می‌دهد ساخت با دسترسی به شبکه انجام می‌شود یا بدون آن.
.TP
\f[B]ProxyUrl=\f[R], \f[B]\-\-proxy\-url=\f[R]
یک پروکسی را برای استفاده در همهٔ اتصالات شبکهٔ خروجی پیکربندی می‌کند.
ابزارهای مختلفی که \f[B]mkosi\f[R] فراخوانی می‌کند و پروکسی برای آن‌ها قابل پیکربندی است، برای استفاده از این پروکسی تنظیم می‌شوند.
همچنین \f[B]mkosi\f[R] متغیرهای محیطی استاندارد مختلفی را برای تعیین پروکسیِ برنامه‌هایی که ممکن است به دسترسی اینترنت نیاز داشته باشند، تنظیم می‌نماید.
.TP
\f[B]ProxyExclude=\f[R], \f[B]\-\-proxy\-exclude=\f[R]
نام‌های میزبانی را پیکربندی می‌کند که درخواست‌های مربوط به آن‌ها نباید از پروکسی عبور کنند.
فهرستی جداشده با کاما از نام‌های میزبان را می‌گیرد.
.TP
\f[B]ProxyPeerCertificate=\f[R], \f[B]\-\-proxy\-peer\-certificate=\f[R]
فایلی شامل گواهی‌های مورد استفاده برای اعتبارسنجی پروکسی را مشخص می‌کند.
پیش‌فرض آن مخزن گواهی‌های سراسری سیستم است.
.RS
در حال حاضر، تنظیم گواهی همتای پروکسی تنها زمانی پشتیبانی می‌شود که از \f[B]dnf\f[R] یا \f[B]dnf5\f[R] برای ساخت تصویر استفاده شود.
.RE
.TP
\f[B]ProxyClientCertificate=\f[R], \f[B]\-\-proxy\-client\-certificate=\f[R]
فایلی حاوی گواهیِ مورد استفاده برای احراز هویت کلاینت در پروکسی را تنظیم می‌کند.
.RS
در حال حاضر، تنظیم گواهی کلاینت پروکسی تنها زمانی پشتیبانی می‌شود که از \f[B]dnf\f[R] یا \f[B]dnf5\f[R] برای ساخت تصویر استفاده شود.
.RE
.TP
\f[B]ProxyClientKey=\f[R], \f[B]\-\-proxy\-client\-key=\f[R]
فایلی حاوی کلید خصوصیِ مورد استفاده برای احراز هویت کلاینت در پروکسی را تنظیم می‌کند.
در صورت ارائه شدن گواهی کلاینت پروکسی، پیش‌فرض روی آن قرار می‌گیرد.
.RS
در حال حاضر، تنظیم کلید کلاینت پروکسی تنها زمانی پشتیبانی می‌شود که از \f[B]dnf\f[R] یا \f[B]dnf5\f[R] برای ساخت تصویر استفاده شود.
.RE
.TP
\f[B]MakeScriptsExecutable=\f[R], \f[B]\-\-make\-scripts\-executable=\f[R]
اگر یکی از اسکریپت‌های قلاب (بخش \f[B]SCRIPTS\f[R] را ببینید) به عنوان قابل‌اجرا علامت‌گذاری نشده باشد، به جای خطا دادنِ مستقیم، تلاش می‌کند با chmod آن را قابل‌اجرا کند.
پیش‌فرض بر روی \f[B]no\f[R] است.
.TP
\f[B]ForeignUIDRange=\f[R], \f[B]\-\-foreign\-uid\-range=\f[R]
اگر فعال باشد، تصاویر دایرکتوری روی دیسک به جای UID کاربر، تحت مالکیت محدودهٔ UID بیگانه قرار خواهند گرفت.
.RS
فعال کردن این گزینه برای استفاده از تصاویر دایرکتوری همراه با دستورهای \f[B]mkosi shell\f[R]، \f[B]mkosi boot\f[R] و \f[B]mkosi vm\f[R] الزامی است.
برای استفاده از این گزینه، نگارش ۲۶۰ یا جدیدترِ ابزارهای systemd\-nsresourced و systemd\-mountfsd روی میزبان مورد نیاز است.
.RE.SS بخش [Runtime] (پیش‌تر با نام بخش [Host] شناخته می‌شد)
.TP
\f[B]NSpawnSettings=\f[R], \f[B]\-\-settings=\f[R]
یک فایل تنظیمات \f[B].nspawn\f[R] را برای \f[B]systemd\-nspawn\f[R] مشخص می‌کند تا در فعل‌های \f[B]boot\f[R] و \f[B]shell\f[R] استفاده شده و در کنار فایل ایمیج تولیدشده قرار گیرد.
این گزینه برای پیکربندی محیط \f[B]systemd\-nspawn\f[R] هنگام اجرای ایمیج کاربرد دارد.
اگر این تنظیم استفاده نشود اما فایل \f[B]mkosi.nspawn\f[R] در دایرکتوری محلی یافت شود، به‌طور خودکار برای این منظور به کار می‌رود.
.TP
\f[B]VirtualMachineMonitor=\f[R], \f[B]\-\-vmm=\f[R]
پایشگر ماشین مجازی مورد استفاده را پیکربندی می‌کند.
یکی از مقادیر \f[B]qemu\f[R] یا \f[B]vmspawn\f[R] را می‌پذیرد.
پیش‌فرض \f[B]qemu\f[R] است.
.RS
هنگامی که روی \f[B]qemu\f[R] تنظیم شود، ایمیج با \f[B]qemu\f[R] بوت می‌شود.
بیشتر قالب‌های خروجی را می‌توان در \f[B]qemu\f[R] بوت کرد.
هر آرگومانی که پس از فعل مشخص شود به فراخوانی \f[B]qemu\f[R] الحاق شده و به عنوان آرگومان‌های اضافی خط فرمان \f[B]qemu\f[R] تفسیر می‌شود.
هنگامی که روی \f[B]vmspawn\f[R] تنظیم شود، از \f[B]systemd\-vmspawn\f[R] برای راه‌اندازی ایمیج استفاده می‌شود؛ \f[B]vmspawn\f[R] فقط از ایمیج‌های نوع دیسک و دایرکتوری پشتیبانی می‌کند.
هر آرگومانی که پس از فعل مشخص شود به فراخوانی \f[B]systemd\-vmspawn\f[R] پیوست شده و به عنوان گزینه‌های اضافی vmspawn و آرگومان‌های اضافی خط فرمان کرنل تفسیر می‌گردد.
.RE
.TP
\f[B]Console=\f[R], \f[B]\-\-console=\f[R]
نحوه راه‌اندازی کنسول ماشین مجازی را پیکربندی می‌کند.
یکی از مقادیر \f[B]interactive\f[R]، \f[B]read\-only\f[R]،
\f[B]native\f[R]، \f[B]gui\f[R] یا \f[B]headless\f[R] را می‌پذیرد.
پیش‌فرض \f[B]interactive\f[R] است.
مقدار \f[B]interactive\f[R] یک رابط ترمینال تعاملی با ماشین مجازی فراهم می‌کند.
مقدار \f[B]read\-only\f[R] مشابه است، اما کاملاً فقط‌خواندنی است؛ یعنی\ هیچ ورودی‌ای از سمت کاربر نمی‌پذیرد.
مقدار \f[B]native\f[R] نیز یک رابط مبتنی بر TTY ارائه می‌دهد، اما از پیاده‌سازی بومی \f[B]qemu\f[R] استفاده می‌کند (به این معنی که مانیتور \f[B]qemu\f[R] در دسترس است).
مقدار \f[B]gui\f[R] رابط کاربری گرافیکی \f[B]qemu\f[R] را نشان می‌دهد.
مقدار \f[B]headless\f[R] ماشین مجازی را بدون اتصال هیچ کنسولی اجرا می‌کند که برای استفاده‌های کاملاً خودکار یا اسکریپت‌شده ماشین مجازی مفید است.
مقدار \f[B]headless\f[R] فقط توسط فعل \f[B]qemu\f[R] پشتیبانی می‌شود.
.TP
\f[B]CPUs=\f[R], \f[B]\-\-cpus=\f[R]
تعداد هسته‌های CPU اختصاص‌یافته به سیستم‌عامل مهمان را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند.
پیش‌فرض \f[B]2\f[R] است.
.RS
هنگامی که روی \f[B]0\f[R] تنظیم شود، تعداد هسته‌های CPU در دسترس فرایند \f[B]mkosi\f[R] استفاده خواهد شد.
.RE
.TP
\f[B]RAM=\f[R], \f[B]\-\-ram=\f[R]
میزان حافظه RAM اختصاص‌یافته به مهمان را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند.
پیش‌فرض \f[B]2G\f[R] است.
.TP
\f[B]MaxMem=\f[R], \f[B]\-\-maxmem=\f[R]
حداکثر مقدار حافظه‌ای را که مهمان می‌تواند در مجموع مستقر کند (RAM + دستگاه‌های حافظه اتصال‌گرم) پیکربندی می‌کند.
پیش‌فرض برابر با میزان RAM پیکربندی‌شده است.
.TP
\f[B]KVM=\f[R], \f[B]\-\-kvm=\f[R]
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی از شتاب‌دهنده KVM استفاده شود یا خیر.
یک مقدار بولی یا \f[B]auto\f[R] می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
.TP
\f[B]CXL=\f[R], \f[B]\-\-cxl=\f[R]
فعال بودن دستگاه‌های CXL را برای یک ماشین معین پیکربندی می‌کند.
تنها در صورتی معتبر است که معماری از cxl پشتیبانی کند.
یک مقدار بولی می‌پذیرد.
پیش‌فرض \f[B]false\f[R] است.
.TP
\f[B]VSock=\f[R], \f[B]\-\-vsock=\f[R]
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی یک vsock تدارک دیده شود یا خیر.
یک مقدار بولی یا \f[B]auto\f[R] می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
.TP
\f[B]VSockCID=\f[R], \f[B]\-\-vsock\-cid=\f[R]
شناسه اتصال vsock مورد استفاده هنگام بوت کردن ماشین مجازی را پیکربندی می‌کند.
عددی در بازه \f[B][3, 0xFFFFFFFF)\f[R] یا \f[B]hash\f[R] یا \f[B]auto\f[R] را می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
هنگامی که روی \f[B]hash\f[R] تنظیم شود، شناسه اتصال از مسیر کامل به ایمیج مشتق می‌شود.
هنگامی که روی \f[B]auto\f[R] تنظیم شود، \f[B]mkosi\f[R] به‌طور خودکار برای یافتن یک شناسه اتصال آزاد تلاش خواهد کرد.
در غیر این صورت، عدد ارائه‌شده عینا استفاده خواهد شد.
.TP
\f[B]TPM=\f[R], \f[B]\-\-tpm=\f[R]
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی از یک TPM مجازی استفاده شود یا خیر.
یک مقدار بولی یا \f[B]auto\f[R] می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
.TP
\f[B]Removable=\f[R], \f[B]\-\-removable=\f[R]
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی، ایمیج به عنوان یک دستگاه جداشدنی متصل شود یا خیر.
یک مقدار بولی می‌پذیرد.
پیش‌فرض \f[B]no\f[R] است.
در صورت فعال بودن، دیسک ریشه همواره بدون در نظر گرفتن تنظیم \f[B]DiskType=\f[R] به عنوان یک دستگاه SCSI متصل می‌شود.
.TP
\f[B]DiskType=\f[R], \f[B]\-\-disk\-type=\f[R]
نوع دیسک مورد استفاده برای دیسک ریشه را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند.
یکی از مقادیر \f[B]virtio\-blk\f[R]، \f[B]virtio\-scsi\f[R]،
\f[B]nvme\f[R] یا \f[B]scsi\-cd\f[R] را می‌پذیرد.
پیش‌فرض \f[B]virtio\-blk\f[R] است.
از \f[B]scsi\-cd\f[R] برای اتصال ایمیج به عنوان درایو CD\-ROM استفاده کنید که برای بوت کردن ایمیج‌های ISO مبتنی بر El Torito مفید است.
.TP
\f[B]Firmware=\f[R], \f[B]\-\-firmware=\f[R]
سفت‌افزار ماشین مجازی مورد استفاده را پیکربندی می‌کند.
یکی از مقادیر \f[B]uefi\f[R]، \f[B]uefi\-secure\-boot\f[R]،
\f[B]linux\f[R]، \f[B]linux\-noinitrd\f[R] یا \f[B]auto\f[R] را می‌پذیرد.
پیش‌فرض \f[B]auto\f[R] است.
هنگامی که روی \f[B]uefi\f[R] تنظیم شود، از سفت‌افزار OVMF بدون پشتیبانی از بوت امن استفاده می‌شود.
هنگامی که روی \f[B]uefi\-secure\-boot\f[R] تنظیم شود، از سفت‌افزار OVMF با پشتیبانی از بوت امن استفاده می‌شود.
هنگامی که روی \f[B]linux\f[R] تنظیم شود، از بوت مستقیم کرنل استفاده می‌گردد.
برای جزئیات بیشتر درباره اینکه کدام ایمیج کرنل در بوت مستقیم کرنل استفاده می‌شود، گزینه \f[B]Linux=\f[R] را ببینید.
مقدار \f[B]linux\-noinitrd\f[R] کاملاً مشابه \f[B]linux\f[R] است جز اینکه هیچ initrdای استفاده نمی‌شود.
هنگامی که روی \f[B]auto\f[R] تنظیم شود، در صورت امکان از \f[B]uefi\-secure\-boot\f[R] و در غیر این صورت از \f[B]linux\f[R] استفاده می‌شود.
.TP
\f[B]FirmwareVariables=\f[R], \f[B]\-\-firmware\-variables=\f[R]
مسیر فایل متغیرهای سفت‌افزار ماشین مجازی مورد استفاده را پیکربندی می‌کند.
در حال حاضر، این گزینه فقط هنگامی در نظر گرفته می‌شود که از سفت‌افزار \f[B]uefi\f[R] یا \f[B]uefi\-secure\-boot\f[R] استفاده شود.
در صورت عدم تعیین، \f[B]mkosi\f[R] فایل متغیرهای پیش‌فرض را جستجو کرده و به جای آن استفاده می‌کند.
.RS
هنگامی که روی \f[B]microsoft\f[R] تنظیم شود، از فایل متغیرهای سفت‌افزاری که گواهی‌های بوت امن مایکروسافت از قبل در آن ثبت شده است استفاده خواهد شد.
هنگامی که روی \f[B]microsoft\-mok\f[R] تنظیم شود، فایل متغیرهای سفت‌افزاری که گواهی‌های بوت امن مایکروسافت از قبل در آن ثبت شده است، با یک متغیر \f[B]MokList\f[R] حاوی گواهی بوت امن از \f[B]SecureBootCertificate=\f[R] گسترش می‌یابد.
این مورد برای استفاده همراه با باینری‌های shim امضاشده توسط توزیع و باینری‌های EFI امضاشده محلی در نظر گرفته شده است.
هنگامی که روی \f[B]custom\f[R] تنظیم شود، گواهی بوت امن از \f[B]SecureBootCertificate=\f[R] درون فایل متغیرهای سفت‌افزار پیش‌فرض ثبت خواهد شد.
ابزار \f[B]virt\-fw\-vars\f[R] از پروژه \c
.UR https://gitlab.com/kraxel/virt-firmware
virt\-firmware
.UE \c
\ می‌تواند برای سفارشی‌سازی فایل‌های متغیر OVMF استفاده شود.
.RE
.TP
\f[B]Linux=\f[R], \f[B]\-\-linux=\f[R]
ایمیج کرنل مورد استفاده برای بوت مستقیم کرنل با \f[B]qemu\f[R] را تعیین می‌کند.
در صورت عدم تعیین، \f[B]mkosi\f[R] از کرنل ارائه‌شده از طریق خط فرمان (گزینه \f[B]\-kernel\f[R]) یا جدیدترین کرنل نصب‌شده درون ایمیج استفاده خواهد کرد (یا اگر هیچ کرنلی در ایمیج نصب نشده باشد با خطا متوقف می‌شود).
.RS
توجه داشته باشید که هنگام استفاده از قالب خروجی \f[B]cpio\f[R]، صرف‌نظر از سفت‌افزار پیکربندی‌شده، از بوت مستقیم کرنل استفاده می‌شود.
بسته به سفت‌افزار پیکربندی‌شده، ممکن است \f[B]qemu\f[R] خودش کرنل را بوت کند یا با استفاده از سفت‌افزار پیکربندی‌شده آن را بالا بیاورد.
این تنظیم می‌تواند شامل هر دو نوع مشخصه‌گرهای معمولی (بخش \f[B]Specifiers\f[R] را ببینید) و مشخصه‌گرهای تأخیری ویژه باشد که به جای زمان پردازش پیکربندی، پس از اتمام پردازش پیکربندی بسط داده می‌شوند و در زیر شرح داده شده‌اند.
مشخصه‌گرهای زیر ممکن است استفاده شوند:
.PP
.TS
tab(@);
l l.
T{
مشخصه‌گر
T}@T{
مقدار
T}
_
T{
\f[B]&&\f[R]
T}@T{
نویسه \f[B]&\f[R]
T}
T{
\f[B]&b\f[R]
T}@T{
پوشه نهایی ساخت (شامل زیرپوشه)
T}
.TE
.RE
.TP
\f[B]Drives=\f[R], \f[B]\-\-drive=\f[R]
یک درایو اضافه می‌کند.
رشته‌ای جداشده با دونقطه به قالب
\f[B]<id>:<size>[:<directory>[:<options>[:<file\-id>[:<flags>]]]]\f[R] می‌پذیرد.
پارامتر \f[B]id\f[R] شناسه اختصاص‌یافته به درایو را مشخص می‌کند.
این مقدار می‌تواند به عنوان ویژگی \f[B]drive=\f[R] در دستگاه‌های مختلف \f[B]qemu\f[R] استفاده شود.
پارامتر \f[B]size\f[R] اندازه درایو را مشخص می‌کند.
این گزینه اندازه را بر حسب بایت می‌گیرد.
علاوه‌بر این، پسوندهای \f[B]K\f[R]، \f[B]M\f[R] و \f[B]G\f[R] می‌توانند به ترتیب برای تعیین اندازه به کیلوبایت، مگابایت و گیگابایت استفاده شوند.
پارامتر \f[B]directory\f[R] به‌طور اختیاری دایرکتوری‌ای را که فایل پشتیبان درایو در آن ایجاد می‌شود مشخص می‌کند.
در صورت عدم تنظیم، فایل زیر \f[B]/var/tmp\f[R] ایجاد خواهد شد.
پارامتر \f[B]options\f[R] به‌طور اختیاری خصوصیات اضافی جداشده با کاما را مشخص می‌کند که عیناً به گزینه \f[B]\-blockdev\f[R] در \f[B]qemu\f[R] ارسال می‌شوند.
پارامتر \f[B]file\-id\f[R] شناسه فایل پشتیبان درایو را مشخص می‌کند.
در صورت عدم تنظیم، مقدار پیش‌فرض آن همان شناسه درایو خواهد بود.
درایوهایی با شناسه فایل یکسان از فایل پشتیبان مشترک استفاده خواهند کرد.
دایرکتوری و اندازه فایل بر اساس نخستین درایو با شناسه فایل مربوطه تعیین خواهد شد.
پارامتر \f[B]flags\f[R] فهرستی جداشده با کاما از پرچم‌های درایو می‌گیرد که در حال حاضر تنها از \f[B]persist\f[R] پشتیبانی می‌کند.
پرچم \f[B]persist\f[R] تعیین می‌کند که آیا درایو بین دفعات فراخوانی \f[B]qemu\f[R] باقی بماند یا خیر.
فایل‌های پشتیبان درایوها با الگوی
\f[B]/<directory>/mkosi\-drive\-<machine\-or\-image\-name>\-<file\-id>\f[R] ایجاد خواهند شد.
می‌توانید با تنظیم مقادیر روی رشته خالی از آن‌ها صرف‌نظر کنید؛ برای مثال تعیین \f[B]myfs:1G::::persist\f[R] یک درایو ماندگار تحت \f[B]/var/tmp/mkosi\-drive\-main\-myfs\f[R] ایجاد خواهد کرد.
.RS
\f[B]نمونه استفاده:\f[R].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
.EE
.RE
.TP
\f[B]QemuArgs=\f[R]
فهرستی جداشده با فاصله از آرگومان‌های اضافی برای ارسال هنگام فراخوانی
\f[B]qemu\f[R].
.TP
\f[B]Ephemeral=\f[R], \f[B]\-\-ephemeral=\f[R]
هنگامی که به همراه زیردستورهای \f[B]shell\f[R]، \f[B]boot\f[R] یا \f[B]vm\f[R]
استفاده شود، این گزینه دستور مشخص‌شده را روی یک تصویر لحظه‌ای (snapshot) موقت از
تصویر خروجی اجرا می‌کند که بلافاصله پس از خاتمهٔ کانتینر حذف می‌شود.
گرفتن تصویر لحظه‌ای موقت روی سیستم‌فایل‌هایی که به‌طور بومی از reflink پشتیبانی می‌کنند
(\f[B]btrfs\f[R] یا \f[B]xfs\f[R])، نسبت به سیستم‌فایل‌های سنتی‌تر که فاقد این قابلیت هستند
(ext4) بسیار کارآمدتر است.
.TP
\f[B]Credentials=\f[R], \f[B]\-\-credential=\f[R]
اعتبارنامه‌هایی را تنظیم می‌کند که هنگام استفاده از \f[B]mkosi shell/boot\f[R] یا
\f[B]mkosi vm\f[R]، به‌ترتیب به \f[B]systemd\-nspawn\f[R] یا ماشین مجازی ارسال می‌شوند.
این گزینه فهرستی از مقادیر جداشده با فاصله را می‌پذیرد که می‌توانند جفت‌های key=value یا مسیر فایل باشند.
اگر مسیری ارائه شود، در صورتی که فایل باشد، نام اعتبارنامه برابر با نام فایل خواهد بود.
اگر فایل قابل اجرا باشد، مقدار اعتبارنامه خروجی حاصل از اجرای فایل خواهد بود.
در غیر این صورت، مقدار اعتبارنامه برابر با محتویات فایل خواهد بود.
اگر مسیر یک دایرکتوری باشد، همین منطق برای هر فایل درون آن دایرکتوری اعمال می‌شود.
.RS
توجه داشته باشید که مقادیر تنها در صورتی به عنوان مسیر در نظر گرفته می‌شوند که حاوی
جداکننده (\f[B]=\f[R]) نباشند.
.RE
.TP
\f[B]KernelCommandLineExtra=\f[R], \f[B]\-\-kernel\-command\-line\-extra=\f[R]
ورودی‌های اضافی خط فرمان هسته را تعیین می‌کند که هنگام بوت تصویر در زمان اجرا،
به خط فرمان هسته اضافه می‌شوند.
هنگام بوت در یک کانتینر، این موارد به عنوان آرگومان‌های اضافی به systemd ارسال می‌شوند.
هنگام بوت در یک VM، این موارد از طریق رشتهٔ OEM در SMBIOS با شناسهٔ
io.systemd.stub.kernel\-cmdline\-extra به خط فرمان هسته اضافه می‌گردند.
این ورودی‌ها تنها توسط نسخه‌های \f[B]systemd\-boot\f[R] و \f[B]systemd\-stub\f[R]
برابر یا جدیدتر از v254 شناسایی خواهند شد.
.TP
\f[B]RuntimeTrees=\f[R], \f[B]\-\-runtime\-tree=\f[R]
یک جفت مسیر جداشده با دو نقطه (colon) را می‌پذیرد.
مسیر اول به دایرکتوری‌ای اشاره دارد که باید در هر ماشین (کانتینر یا VM)
راه‌اندازی‌شده توسط mkosi سوار (mount) شود.
مسیر دوم به دایرکتوری مقصد درون ماشین اشاره می‌کند.
اگر مسیر دوم ارائه نشود، دایرکتوری در \f[B]/root/src\f[R] در ماشین سوار می‌شود.
اگر مسیر دوم نسبی باشد، نسبت به \f[B]/root/src\f[R] در ماشین تفسیر خواهد شد.
.RS
به ازای هر دایرکتوری سوارشده، uid و gid کاربری که mkosi را اجرا می‌کند به کاربر root در
ماشین نگاشت می‌شود.
این بدان معناست که همهٔ فایل‌ها و دایرکتوری‌ها به‌گونه‌ای نمایش داده می‌شوند که گویی متعلق
به root در ماشین هستند، و تمام فایل‌ها و دایرکتوری‌های جدیدی که توسط root درون این
دایرکتوری‌ها در ماشین ایجاد شوند، در سیستم میزبان متعلق به کاربری خواهند بود که mkosi را اجرا کرده است.
توجه داشته باشید که هنگام استفاده از \f[B]mkosi vm\f[R] همراه با این ویژگی، باید نسخهٔ
v254 یا جدیدتر systemd روی تصویر نصب شده باشد.
.RE
.TP
\f[B]RuntimeSize=\f[R], \f[B]\-\-runtime\-size=\f[R]
در صورت تعیین، هنگام بوت تصاویر دیسک با \f[B]mkosi boot\f[R] یا \f[B]mkosi vm\f[R]،
اندازهٔ آن‌ها به اندازهٔ مشخص‌شده افزایش می‌یابد.
یک اندازه را بر حسب بایت می‌پذیرد.
علاوه بر این، پسوندهای \f[B]K\f[R]، \f[B]M\f[R] و \f[B]G\f[R] می‌توانند به‌ترتیب برای
مشخص کردن اندازه بر حسب کیلوبایت، مگابایت و گیگابایت استفاده شوند.
.TP
\f[B]RuntimeNetwork=\f[R], \f[B]\-\-runtime\-network=\f[R]
یکی از مقادیر \f[B]user\f[R]، \f[B]interface\f[R] یا \f[B]none\f[R] را می‌پذیرد.
پیش‌فرض آن \f[B]user\f[R] است.
وضعیت شبکه‌بندی برای راه‌اندازی هنگام بوت تصویر را مشخص می‌کند.
مقدار \f[B]user\f[R] شبکهٔ حالت کاربر (usermode networking) را برپا می‌سازد.
مقدار \f[B]interface\f[R] یک اتصال شبکهٔ مجازی بین میزبان و تصویر برقرار می‌کند.
این مورد برای \f[B]mkosi shell\f[R] و \f[B]mkosi boot\f[R] به یک رابط veth،
و برای \f[B]mkosi vm\f[R] و \f[B]mkosi vmspawn\f[R] به یک رابط tap تبدیل می‌شود.
.RS
توجه داشته باشید هنگام استفاده از \f[B]interface\f[R]، ابزار \f[B]mkosi\f[R] رابط میزبان
را به‌طور خودکار پیکربندی نمی‌کند.
انتظار می‌رود یک نسخهٔ جدید از \f[B]systemd\-networkd\f[R] روی میزبان در حال اجرا باشد
که رابط پیوند سمت میزبان را به‌طور خودکار پیکربندی نماید.
.RE
.TP
\f[B]RuntimeBuildSources=\f[R], \f[B]\-\-runtime\-build\-sources=\f[R]
هنگام استفاده از \f[B]mkosi boot\f[R] یا \f[B]mkosi vm\f[R]، منابع ساختی که با
\f[B]BuildSources=\f[R] پیکربندی شده‌اند و دایرکتوری ساخت را (در صورت پیکربندی)
در همان مکان‌هایی درون \f[B]/work\f[R] سوار می‌کند که در زمان اجرای اسکریپت ساخت سوار شده بودند.
.TP
\f[B]BindUser=\f[R], \f[B]\-\-bind\-user=\f[R]
دایرکتوری خانگی کاربر فعلی را درون کانتینر/vm متصل (bind mount) می‌کند.
یک مقدار بولی می‌پذیرد.
به‌طور پیش‌فرض غیرفعال است.
.TP
\f[B]SshKey=\f[R], \f[B]\-\-ssh\-key=\f[R]
مسیر کلید خصوصی X.509 با قالب PEM برای استفاده در اتصال به ماشین مجازی راه‌اندازی‌شده
با \f[B]mkosi vm\f[R] و ساخته‌شده با گزینهٔ فعال \f[B]Ssh=\f[R] (یا با
\f[B]systemd\-ssh\-generator\f[R] نصب‌شده) از طریق دستور \f[B]mkosi ssh\f[R].
اگر پیکربندی نشده باشد و فایل \f[B]mkosi.key\f[R] در دایرکتوری کاری موجود باشد،
به‌طور خودکار برای این منظور استفاده خواهد شد.
برای ایجاد خودکار یک کلید در \f[B]mkosi.key\f[R]، دستور \f[B]mkosi genkey\f[R] را اجرا کنید.
.TP
\f[B]SshCertificate=\f[R], \f[B]\-\-ssh\-certificate=\f[R]
مسیر گواهی X.509 با قالب PEM برای فراهم‌سازی به عنوان کلید عمومی SSH در ماشین‌های مجازی
راه‌اندازی‌شده با \f[B]mkosi vm\f[R].
اگر پیکربندی نشده باشد و فایل \f[B]mkosi.crt\f[R] در دایرکتوری کاری موجود باشد،
به‌طور خودکار برای این منظور استفاده خواهد شد.
برای ایجاد خودکار یک گواهی در \f[B]mkosi.crt\f[R]، دستور \f[B]mkosi genkey\f[R] را اجرا کنید.
.TP
\f[B]Machine=\f[R], \f[B]\-\-machine=\f[R]
نام ماشین مورد استفاده هنگام بوت تصویر را مشخص می‌کند.
همچنین می‌تواند برای اشاره به یک تصویر مشخص هنگام برقراری اتصال SSH به آن تصویر استفاده شود
(مانند \f[B]mkosi \-\-image=myimage ssh\f[R]).
.RS
توجه داشته باشید که برای راه‌اندازی چندین نمونه از یک تصویر یکسان، باید گزینهٔ
\f[B]Ephemeral=\f[R] فعال باشد.
پیش‌فرض آن نام دایرکتوری کاری فعلی است.
.RE
.TP
\f[B]Register=\f[R], \f[B]\-\-register=\f[R]
یک مقدار بولی یا \f[B]auto\f[R] می‌پذیرد.
مشخص می‌کند که آیا ماشین مجازی/کانتینر در systemd\-machined ثبت شود یا خیر.
در صورت فعال بودن، اگر mkosi نتواند ماشین مجازی/کانتینر را در systemd\-machined ثبت کند،
با خطا متوقف می‌شود.
در صورت غیرفعال بودن، mkosi ماشین مجازی/کانتینر را در systemd\-machined ثبت نخواهد کرد.
اگر روی \f[B]auto\f[R] تنظیم شود، در صورت در دسترس بودن systemd\-machined، ابزار mkosi
ماشین مجازی/کانتینر را ثبت می‌کند.
پیش‌فرض آن \f[B]auto\f[R] است.
.RS
توجه داشته باشید که mkosi تلاش می‌کند ماشین را در نشست کاربری (user session) در
systemd\-machined ثبت نماید.
برای در دسترس بودن systemd\-machined در نشست‌های کاربری، نسخهٔ v259 یا جدیدتر systemd
مورد نیاز است.
.RE
.TP
\f[B]ForwardJournal=\f[R], \f[B]\-\-forward\-journal=\f[R]
مسیری را مشخص می‌کند که گزارش‌های journal کانتینرها و ماشین‌های مجازی باید به آن
بازفرستاده شوند.
اگر مسیر دارای پسوند \f[B].journal\f[R] باشد، به عنوان فایلی تفسیر می‌شود که journal باید
درون آن نوشته شود.
در غیر این صورت، مسیر به عنوان دایرکتوری‌ای تفسیر می‌شود که journal باید در آن نوشته شود.
.RS
توجه داشته باشید برای کارکرد قابلیت بازفرستادن لاگ، به نسخهٔ v256 یا جدیدتر systemd در
ماشین مجازی نیاز است.
همچنین توجه داشته باشید اگر مسیری با پسوند \f[B].journal\f[R] داده شود، اندازهٔ journal
به \f[B]4G\f[R] محدود خواهد بود.
اگر بار کاری شما بیش از \f[B]4G\f[R] دادهٔ journal تولید می‌کند، به جای فایل، یک
دایرکتوری خروجی پیکربندی کنید.
.RE
.TP
\f[B]StorageTargetMode=\f[R], \f[B]\-\-storage\-target\-mode=\f[R]
مشخص می‌کند که آیا دستور \f[B]serve\f[R] باید \f[B]systemd\-storagetm\f[R] را برای
سرویس‌دهی تصاویر دیسک روی پروتکل NVME\-TCP راه‌اندازی کند یا خیر.
یک مقدار بولی یا \f[B]auto\f[R] می‌پذیرد.
اگر فعال باشد، systemd\-storagetm همیشه اجرا می‌شود و در صورت عدم امکان راه‌اندازی آن،
mkosi با خطا مواجه خواهد شد.
اگر غیرفعال باشد، systemd\-storagetm هرگز راه‌اندازی نمی‌شود.
اگر روی \f[B]auto\f[R] تنظیم شود، در صورتی که یک تصویر دیسک در حال ساخت باشد، فایل اجرایی
systemd\-storagetm پیدا شود و \f[B]mkosi serve\f[R] توسط کاربر root اجرا گردد،
سرویس systemd\-storagetm راه‌اندازی خواهد شد.
.TP
\f[B]SysupdateDirectory=\f[R], \f[B]\-\-sysupdate\-directory=\f[R]
مسیر دایرکتوری حاوی فایل‌های تعاریف انتقال systemd\-sysupdate که توسط
\f[B]mkosi sysupdate\f[R] استفاده می‌شوند.
اگر \f[B]mkosi.sysupdate/\f[R] در دایرکتوری محلی وجود داشته باشد، برای همین منظور
استفاده خواهد شد.
.RS
توجه داشته باشید که \f[B]mkosi sysupdate\f[R] دستور \f[B]systemd\-sysupdate\f[R] را
به‌گونه‌ای فراخوانی می‌کند که گزینهٔ \f[B]\-\-transfer\-source=\f[R] روی دایرکتوری
خروجی \f[B]mkosi\f[R] تنظیم شده است.
برای بهره‌گیری از این امکان در یک فایل تعریف انتقال، \f[B]PathRelativeTo=explicit\f[R]
را تنظیم کنید تا پیکربندی \f[B]Path=\f[R] برای مبدا انتقال، نسبت به دایرکتوری خروجی
\f[B]mkosi\f[R] تفسیر شود.
به‌طور کلی، تنظیم \f[B]PathRelativeTo=explicit\f[R] و \f[B]Path=/\f[R] برای مبدا انتقال
کافی است تا الگوی تطبیق نسبت به دایرکتوری خروجی \f[B]mkosi\f[R] تفسیر گردد.
.RE.SS بخش [Match]
.TP
\f[B]Profiles=\f[R]
با پروفایل‌های پیکربندی‌شده مطابقت می‌دهد.
.TP
\f[B]Distribution=\f[R]
با توزیع پیکربندی‌شده مطابقت می‌دهد.
.TP
\f[B]Release=\f[R]
با نسخهٔ انتشار (Release) توزیع پیکربندی‌شده مطابقت می‌دهد.
اگر از این شرط استفاده شود و هنوز هیچ توزیعی به‌طور صریح پیکربندی نشده باشد، توزیع و نسخهٔ انتشار میزبان استفاده می‌شوند.
.TP
\f[B]Architecture=\f[R]
با معماری پیکربندی‌شده مطابقت می‌دهد.
اگر از این شرط استفاده شود و هنوز هیچ معماری‌ای به‌طور صریح پیکربندی نشده باشد، معماری میزبان استفاده می‌شود.
.RS
می‌توان از \f[B]Architecture=uefi\f[R] برای مطابقت با هر معماری‌ای که از UEFI پشتیبانی می‌کند استفاده کرد.
.RE
.TP
\f[B]Repositories=\f[R]
با مخازن فعال‌شده از طریق تنظیم \f[B]Repositories=\f[R] مطابقت می‌دهد.
تنها یک نام مخزن واحد می‌پذیرد.
.TP
\f[B]OutputFormat=\f[R]
با مقدار پیکربندی‌شده برای \f[B]OutputFormat=\f[R] مطابقت می‌دهد.
.TP
\f[B]PathExists=\f[R]
این شرط در صورتی برآورده می‌شود که مسیر داده‌شده وجود داشته باشد.
مسیرهای نسبی، نسبت به دایرکتوری والد فایل پیکربندی‌ای که شرط از آن خوانده می‌شود، تفسیر می‌شوند.
.TP
\f[B]ImageId=\f[R]
با شناسهٔ تصویر (Image ID) پیکربندی‌شده مطابقت می‌دهد و از الگوهای glob پشتیبانی می‌کند.
اگر از این شرط استفاده شود و هنوز شناسهٔ تصویری به‌طور صریح پیکربندی نشده باشد، این شرط ناموفق خواهد بود.
.TP
\f[B]ImageVersion=\f[R]
با نسخهٔ تصویر پیکربندی‌شده مطابقت می‌دهد.
برای مقایسه‌های نگارشی پیشرفته طبق مشخصات قالب نگارش گروه UAPI، می‌توان نسخه‌های تصویر را با عملگرهای \f[B]==\f[R]، \f[B]!=\f[R]، \f[B]>=\f[R]، \f[B]<=\f[R]، \f[B]<\f[R] و \f[B]>\f[R] پیشوندگذاری کرد.
اگر هیچ عملگری مشخص نشود، به‌طور پیش‌فرض عملگر برابری در نظر گرفته می‌شود.
اگر از این شرط استفاده شود و هنوز نسخهٔ تصویری به‌طور صریح پیکربندی نشده باشد، این شرط ناموفق خواهد بود.
.TP
\f[B]Bootable=\f[R]
با مقدار پیکربندی‌شده برای قابلیت \f[B]Bootable=\f[R] مطابقت می‌دهد.
یک مقدار بولی (boolean) یا \f[B]auto\f[R] می‌پذیرد.
.TP
\f[B]Bootloader=\f[R]
با مقدار پیکربندی‌شده برای \f[B]Bootloader=\f[R] مطابقت می‌دهد.
.TP
\f[B]Format=\f[R]
با مقدار پیکربندی‌شده برای گزینهٔ \f[B]Format=\f[R] مطابقت می‌دهد.
یک قالب خروجی می‌پذیرد (گزینهٔ \f[B]Format=\f[R] را ببینید).
.TP
\f[B]SystemdVersion=\f[R]
با نسخهٔ systemd روی میزبان (طبق گزارش \f[B]systemctl \-\-version\f[R]) مطابقت می‌دهد.
برای مقایسه‌های نگارشی پیشرفته طبق مشخصات قالب نگارش گروه UAPI، مقادیر می‌توانند با عملگرهای \f[B]==\f[R]، \f[B]!=\f[R]، \f[B]>=\f[R]، \f[B]<=\f[R]، \f[B]<\f[R] و \f[B]>\f[R] پیشوندگذاری شوند.
اگر هیچ عملگری مشخص نشود، به‌طور پیش‌فرض عملگر برابری در نظر گرفته می‌شود.
.TP
\f[B]BuildSources=\f[R]
یک مسیر مقصد برای منبع ساخت می‌پذیرد (به \f[B]BuildSources=\f[R] مراجعه کنید).
این تطابق در صورتی برقرار می‌شود که هر یک از منابع ساخت پیکربندی‌شده از این مسیر مقصد استفاده کنند.
برای مثال، اگر فایل \f[B]mkosi.conf\f[R] شامل موارد زیر باشد:
.RS
.IP
.EX
\f[B][Build]\f[R]
BuildSources=../abc/qed:kernel
.EE
و یک فایل drop\-in شامل:
.IP
.EX
\f[B][Match]\f[R]
BuildSources=kernel
.EE
فایل drop\-in اعمال خواهد شد.
هر مسیر مطلقی که به این تنظیم داده شود، نسبت به دایرکتوری کاری فعلی تفسیر می‌شود.
.RE
.TP
\f[B]HostArchitecture=\f[R]
با معماری بومی میزبان مطابقت می‌دهد.
برای دیدن فهرست مقادیر ممکن، به تنظیم \f[B]Architecture=\f[R] مراجعه کنید.
.TP
\f[B]ToolsTreeDistribution=\f[R]
با توزیع درخت ابزار (tools tree) پیکربندی‌شده مطابقت می‌دهد.
.TP
\f[B]ToolsTreeRelease=\f[R]
با نسخهٔ انتشار درخت ابزار (tools tree) پیکربندی‌شده مطابقت می‌دهد.
.TP
\f[B]Environment=\f[R]
با یک جفت کلید/مقدار خاص پیکربندی‌شده توسط \f[B]Environment=\f[R] مطابقت می‌دهد.
اگر مقداری ارائه نشود، صرف‌نظر از اینکه مقدار آن چه باشد، وجود کلید داده‌شده در محیط بررسی می‌شود.
.TP
\f[B]Image=\f[R]
با نام تصویر (یا زیرتصویر) فعلی مطابقت می‌دهد.
نام یک زیرتصویر، همان نام آن در \f[B]mkosi.images/\f[R] است (بدون پسوند \f[B].conf\f[R]).
نام تصویر سطح بالا (top level) برابر با \f[B]main\f[R] است.
کاربرد اصلی این گزینه، امکان داشتن یک پیکربندی مشترک است که هم توسط تصویر سطح بالا و هم زیرتصاویر قابل استفاده باشد؛ این کار با مشروط کردن تنظیمات سراسری به شرط تطابق \f[B]Image=main\f[R] انجام می‌پذیرد.
.PP
این جدول نشان می‌دهد که کدام تطبیق‌دهنده‌ها از الگوهای glob و مقایسه‌های پیشرفته پشتیبانی می‌کنند، و در صورت عدم پیکربندی در زمان خوانده شدن فایل پیکربندی، با چه مقدار پیش‌فرضی تطبیق داده می‌شوند:
.PP
.TS
tab(@);
lw(13.1n) lw(3.5n) lw(9.1n) lw(44.3n).
T{
تطبیق‌دهنده
T}@T{
الگوهای Glob
T}@T{
مقایسه‌های پیشرفته
T}@T{
پیش‌فرض
T}
_
T{
\f[B]Profiles=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق ناموفق است
T}
T{
\f[B]Distribution=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با توزیع میزبان
T}
T{
\f[B]Release=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با نسخهٔ انتشار میزبان
T}
T{
\f[B]Architecture=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با معماری میزبان
T}
T{
\f[B]PathExists=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
نامربوط
T}
T{
\f[B]ImageId=\f[R]
T}@T{
بله
T}@T{
خیر
T}@T{
تطابق ناموفق است
T}
T{
\f[B]ImageVersion=\f[R]
T}@T{
خیر
T}@T{
بله
T}@T{
تطابق ناموفق است
T}
T{
\f[B]Bootable=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با قابلیت auto
T}
T{
\f[B]Format=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با قالب پیش‌فرض
T}
T{
\f[B]SystemdVersion=\f[R]
T}@T{
خیر
T}@T{
بله
T}@T{
نامربوط
T}
T{
\f[B]BuildSources=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق ناموفق است
T}
T{
\f[B]HostArchitecture=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
نامربوط
T}
T{
\f[B]ToolsTreeDistribution=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با توزیع جایگزین درخت ابزار (به
\f[B]ToolsTreeDistribution=\f[R] در \f[B][Build]\f[R] مراجعه کنید)
T}
T{
\f[B]ToolsTreeRelease=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
تطابق با نسخهٔ انتشار پیش‌فرض درخت ابزار
T}
T{
\f[B]Environment=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
نامربوط
T}
T{
\f[B]Image=\f[R]
T}@T{
خیر
T}@T{
خیر
T}@T{
نامربوط
T}
.TE.SS [Include]
.TP
\f[B]Include=\f[R], \f[B]\-\-include=\f[R], \f[B]\-I\f[R]
گنجاندن پیکربندی اضافی از فایل یا دایرکتوری داده‌شده.
پیکربندی اضافی بلافاصله پس از تجزیه این تنظیم اعمال می‌شود، مگر زمانی که در خط فرمان استفاده شود؛ در این صورت، پیکربندی اضافی پس از تجزیه تمام آرگومان‌های خط فرمان اعمال خواهد شد.
.RS
توجه داشته باشید که هر مسیر حاوی پیکربندی اضافی، تنها یک بار تجزیه می‌شود، حتی اگر بیش از یک بار با \f[B]Include=\f[R] آورده شده باشد.
پیکربندی‌های توکار برای initrd پیش‌فرض، درخت ابزارهای (tools tree) پیش‌فرض، تصویر ماشین مجازی پیش‌فرض و افزونه UKI پیش‌فرضِ \f[B]mkosi\f[R] را می‌توان به‌ترتیب با گنجاندن مقادیر لغوی \f[B]mkosi\-initrd\f[R]، \f[B]mkosi\-tools\f[R]، \f[B]mkosi\-vm\f[R] یا \f[B]mkosi\-addon\f[R] وارد کرد.
نکته: نام‌های گنجاندنی که با هر یک از عبارت‌های تحت‌اللفظی \f[B]mkosi\-\f[R] یا \f[B]contrib\-\f[R] آغاز می‌شوند، برای استفاده خودِ \f[B]mkosi\f[R] رزرو شده‌اند.
.RE
.SS بخش [Config]
.TP
\f[B]Profiles=\f[R], \f[B]\-\-profile=\f[R]
انتخاب پروفایل‌های مشخص‌شده.
یک پروفایل، یک فایل پیکربندی یا دایرکتوری در دایرکتوری \f[B]mkosi.profiles/\f[R] است.
فایل‌ها و دایرکتوری‌های پیکربندی هر پروفایل پس از تجزیه پیکربندی‌های تکمیلیِ (drop-in) \f[B]mkosi.conf.d/*.conf\f[R] گنجانده می‌شوند.
.TP
\f[B]Dependencies=\f[R], \f[B]\-\-dependency=\f[R]
تصاویری که این تصویر به آن‌ها وابسته است، به‌صورت فهرستی جداشده با کاما مشخص می‌شوند.
تمام تصاویری که در این گزینه پیکربندی شده‌اند پیش از این تصویر ساخته خواهند شد.
.RS
هنگامی که این تنظیم برای تصویر «اصلی» (\(lqmain\(rq) تعیین شود، مشخص می‌کند که کدام زیرتصویرها باید ساخته شوند.
برای اطلاعات بیشتر بخش \f[B]BUILDING MULTIPLE IMAGES\f[R] را ببینید.
.RE
.TP
\f[B]MinimumVersion=\f[R], \f[B]\-\-minimum\-version=\f[R]
حداقل نسخه \f[B]mkosi\f[R] مورد نیاز برای ساخت این پیکربندی.
اگر چندین بار مشخص شود، بالاترین نسخه تعیین‌شده به کار گرفته می‌شود.
.RS
حداقل نسخه را می‌توان با پیشوند \f[B]commit:\f[R] به‌صورت یک هش کامیت گیت نیز تعیین کرد؛ در این حالت mkosi باید از داخل یک checkout گیت اجرا شود و هش کامیت گیت مشخص‌شده باید از نیاکان (ancestor) کامیتِ در حال حاضر checkout شده در مخزنی باشد که mkosi از آن اجرا می‌شود.
.RE
.TP
\f[B]ConfigureScripts=\f[R], \f[B]\-\-configure\-script=\f[R]
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به‌عنوان اسکریپت‌های پیکربندی این تصویر استفاده می‌شوند.
الگوهای سراسری (Glob patterns) پشتیبانی می‌شوند و مسیرهای منطبق، به‌ترتیب الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش \f[B]SCRIPTS\f[R] را ببینید.
.TP
\f[B]PassEnvironment=\f[R], \f[B]\-\-pass\-environment=\f[R]
فهرستی از نام‌های متغیرهای محیطی که با فاصله از هم جدا شده‌اند می‌گیرد.
هنگام ساخت چندین تصویر، متغیرهای محیطی فهرست‌شده را به‌گونه‌ای به هر زیرتصویر مستقل ارسال می‌کند که گویی تنظیماتی «سراسری» (\(lquniversal\(rq) هستند.
برای اطلاعات بیشتر بخش \f[B]BUILDING MULTIPLE IMAGES\f[R] را ببینید.
.SS بخش [UKIProfile]
بخش \f[B]UKIProfile\f[R] می‌تواند در فایل‌های پیکربندی پروفایل UKI که به تنظیم \f[B]UnifiedKernelImageProfiles=\f[R] ارسال می‌شوند، استفاده شود.
تنظیمات زیر را می‌توان در بخش \f[B]UKIProfile\f[R] مشخص کرد:
.TP
\f[B]Profile=\f[R]
محتوای بخش \f[B].profile\f[R] مربوط به پروفایل UKI.
فهرستی از جفت‌های کلید/مقدار جداشده با \f[B]=\f[R] می‌گیرد.
کلید \f[B]ID=\f[R] حتماً باید مشخص شود.
برای دیدن فهرست کاملی از کلیدهای ممکن، به \c
.UR https://uapi-group.org/specifications/specs/unified_kernel_image/#multi-profile-ukis
مشخصات UKI
.UE \c
\ مراجعه کنید.
.TP
\f[B]Cmdline=\f[R]
گزینه‌های خط فرمان اضافی هسته برای پروفایل UKI.
فهرستی جداشده با فاصله از آرگومان‌های خط فرمان اضافی هسته می‌گیرد.
توجه داشته باشید که بخش نهایی \f[B].cmdline\f[R] ترکیبی از بخش پایه \f[B].cmdline\f[R] و آرگومان‌های خط فرمان اضافی هسته خواهد بود که با این تنظیم تعیین شده‌اند.
.TP
\f[B]SignExpectedPcr=\f[R]
امضای اندازه‌گیری‌های مورد انتظار PCR برای این پروفایل UKI.
یک مقدار بولیَن (boolean) می‌گیرد.
به‌طور پیش‌فرض فعال است.
.SS مشخص‌کننده‌ها (Specifiers)
مقدار فعلی تنظیمات مختلف را می‌توان هنگام تجزیه فایل‌های پیکربندی با استفاده از مشخص‌کننده‌ها دریافت کرد.
برای نوشتن یک نویسه لغوی \f[B]%\f[R] در فایل پیکربندی بدون اینکه به‌عنوان یک مشخص‌کننده تفسیر شود، از \f[B]%%\f[R] استفاده کنید.
مشخص‌کننده‌های زیر پشتیبانی می‌شوند:
.PP
.TS
tab(@);
l l.
T{
تنظیم
T}@T{
مشخص‌کننده
T}
_
T{
\f[B]Distribution=\f[R]
T}@T{
\f[B]%d\f[R]
T}
T{
\f[B]Release=\f[R]
T}@T{
\f[B]%r\f[R]
T}
T{
\f[B]Architecture=\f[R]
T}@T{
\f[B]%a\f[R]
T}
T{
\f[B]Format=\f[R]
T}@T{
\f[B]%t\f[R]
T}
T{
\f[B]Output=\f[R]
T}@T{
\f[B]%o\f[R]
T}
T{
\f[B]OutputDirectory=\f[R]
T}@T{
\f[B]%O\f[R]
T}
T{
\f[B]ImageId=\f[R]
T}@T{
\f[B]%i\f[R]
T}
T{
\f[B]ImageVersion=\f[R]
T}@T{
\f[B]%v\f[R]
T}
.TE
.PP
همچنین مشخص‌کننده‌هایی وجود دارند که مستقل از تنظیمات هستند:
.PP
.TS
tab(@);
l l.
T{
مشخص‌کننده
T}@T{
مقدار
T}
_
T{
\f[B]%C\f[R]
T}@T{
دایرکتوری والد فایل پیکربندی فعلی
T}
T{
\f[B]%P\f[R]
T}@T{
دایرکتوری کاری فعلی
T}
T{
\f[B]%D\f[R]
T}@T{
دایرکتوری‌ای که \f[B]mkosi\f[R] در آن فراخوانی شده است
T}
T{
\f[B]%I\f[R]
T}@T{
نام زیرتصویر فعلی در \f[B]mkosi.images\f[R]
T}
.TE
.PP
در نهایت، مشخص‌کننده‌هایی وجود دارند که از یک تنظیم مشتق می‌شوند:
.PP
.TS
tab(@);
l l.
T{
مشخص‌کننده
T}@T{
مقدار
T}
_
T{
\f[B]%F\f[R]
T}@T{
سیستم‌فایل پیش‌فرض توزیع پیکربندی‌شده
T}
.TE
.PP
توجه داشته باشید که دایرکتوری کاری فعلی با تجزیه پیکربندی توسط \f[B]mkosi\f[R] تغییر می‌کند.
به‌طور مشخص، هر بار که \f[B]mkosi\f[R] دایرکتوری حاوی یک فایل \f[B]mkosi.conf\f[R] را تجزیه می‌کند، دایرکتوری کاری خود را به آن دایرکتوری تغییر می‌دهد..PP
توجه داشته باشید دایرکتوری‌ای که \f[B]mkosi\f[R] در آن فراخوانی شده است،
تحت تأثیر آرگومان خط فرمان \f[B]\-\-directory=\f[R] قرار می‌گیرد.
.PP
جدول زیر مقادیر نمونه را برای مشخص‌کننده‌های دایرکتوری فهرست‌شده در بالا
نشان می‌دهد:
.PP
.TS
tab(@);
lw(4.7n) lw(13.4n) lw(25.2n) lw(26.7n).
T{
T}@T{
\f[B]$D/mkosi.conf\f[R]
T}@T{
\f[B]$D/mkosi.conf.d/abc/abc.conf\f[R]
T}@T{
\f[B]$D/mkosi.conf.d/abc/mkosi.conf\f[R]
T}
_
T{
\f[B]%C\f[R]
T}@T{
\f[B]$D\f[R]
T}@T{
\f[B]$D/mkosi.conf.d\f[R]
T}@T{
\f[B]$D/mkosi.conf.d/abc\f[R]
T}
T{
\f[B]%P\f[R]
T}@T{
\f[B]$D\f[R]
T}@T{
\f[B]$D\f[R]
T}@T{
\f[B]$D/mkosi.conf.d/abc\f[R]
T}
T{
\f[B]%D\f[R]
T}@T{
\f[B]$D\f[R]
T}@T{
\f[B]$D\f[R]
T}@T{
\f[B]$D\f[R]
T}
.TE
.SS "توزیع‌های پشتیبانی‌شده (Supported distributions)"
می‌توان ایمیج‌هایی حاوی نصب‌هایی از توزیع‌های زیر
ایجاد کرد:
.IP \(bu 2
\f[I]Fedora Linux\f[R]
.IP \(bu 2
\f[I]Debian\f[R]
.IP \(bu 2
\f[I]Kali Linux\f[R]
.IP \(bu 2
\f[I]Ubuntu\f[R]
.IP \(bu 2
\f[I]Arch Linux\f[R]
.IP \(bu 2
\f[I]openSUSE\f[R]
.IP \(bu 2
\f[I]Mageia\f[R]
.IP \(bu 2
\f[I]CentOS\f[R]
.IP \(bu 2
\f[I]RHEL\f[R]
.IP \(bu 2
\f[I]RHEL UBI\f[R]
.IP \(bu 2
\f[I]OpenMandriva\f[R]
.IP \(bu 2
\f[I]Rocky Linux\f[R]
.IP \(bu 2
\f[I]Alma Linux\f[R]
.IP \(bu 2
\f[I]Azure Linux\f[R]
.IP \(bu 2
\f[I]postmarketOS\f[R]
.IP \(bu 2
\f[I]None\f[R] (\f[B]نیازمند این است که کاربر یک rootfs از پیش ساخته‌شده فراهم کند\f[R])
.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] استفاده شود.
سایر توزیع‌ها و ابزارهای خودکارسازی ساخت برای سیستم‌های لینوکس تعبیه‌شده
(embedded) مانند Buildroot، OpenEmbedded و Yocto Project می‌توانند با انتخاب توزیع
\f[B]custom\f[R]، و پر کردن rootfs از طریق ترکیبی از درخت‌های پایه، درخت‌های
اسکلت و اسکریپت‌های آماده‌سازی استفاده شوند.
.PP
در حال حاضر، \f[I]Fedora Linux\f[R] از زمان Fedora 28 تمام ابزارهای مربوطه را بسته‌بندی
کرده است.
.PP
توجه داشته باشید هنگامی که از یک مخزن آینه‌ای سفارشی استفاده نمی‌شود، ایمیج‌های
\f[B]RHEL\f[R] تنها می‌توانند از یک سیستم میزبان دارای اشتراک \f[B]RHEL\f[R]
(که مثلاً با استفاده از \f[B]subscription\-manager\f[R] برقرار شده است) ساخته شوند.
.SH "جریان اجرا (EXECUTION FLOW)"
جریان اجرای \f[B]mkosi build\f[R].
مقادیر/فراخوانی‌های پیش‌فرض در پرانتز نشان داده شده‌اند.
هنگام ساخت با \f[B]\-\-incremental=yes\f[R]، در صورتی که حافظه پنهان (کَش) نصب توزیع
از قبل وجود نداشته باشد، \f[B]mkosi\f[R] آن را ایجاد می‌کند و در اجراهای متوالی،
نصب توزیع را با داده‌های نسخه کش‌شده جایگزین می‌نماید.
.IP "1." 3
تجزیه گزینه‌های خط فرمان (CLI)
.IP "2." 3
تجزیه فایل‌های پیکربندی
.IP "3." 3
اجرای اسکریپت‌های پیکربندی (\f[B]mkosi.configure\f[R])
.IP "4." 3
اگر به عنوان root اجرا نمی‌شود، لغو اشتراک فضای نام کاربری (unshare user namespace)
و نگاشت محدوده subuid پیکربندی‌شده در \f[B]/etc/subuid\f[R] و
\f[B]/etc/subgid\f[R] به درون آن.
.IP "5." 3
لغو اشتراک فضای نام سوار کردن (unshare mount namespace)
.IP "6." 3
سوار کردن مجدد دایرکتوری‌های زیر به صورت فقط‌خواندنی در صورت وجود:
.RS 4
.IP \(bu 2
\f[B]/usr\f[R]
.IP \(bu 2
\f[B]/etc\f[R]
.IP \(bu 2
\f[B]/opt\f[R]
.IP \(bu 2
\f[B]/srv\f[R]
.IP \(bu 2
\f[B]/boot\f[R]
.IP \(bu 2
\f[B]/efi\f[R]
.IP \(bu 2
\f[B]/media\f[R]
.IP \(bu 2
\f[B]/mnt\f[R]
.RE
.PP
سپس، برای هر ایمیج، مراحل زیر اجرا می‌شوند:
.IP " 1." 4
کپی درخت‌های محیط ایزوله (sandbox trees) به درون فضای کاری
.IP " 2." 4
همگام‌سازی متادیتای مخزن مدیر بسته
.IP " 3." 4
اجرای اسکریپت‌های همگام‌سازی (\f[B]mkosi.sync\f[R])
.IP " 4." 4
کپی درخت‌های پایه (\f[B]\-\-base\-tree=\f[R]) به درون ایمیج
.IP " 5." 4
استفاده مجدد از ایمیج کش‌شده در صورت در دسترس بودن
.IP " 6." 4
کپی یک رونوشت (snapshot) از متادیتای مخزن مدیر بسته به درون
ایمیج
.IP " 7." 4
کپی درخت‌های اسکلت (\f[B]mkosi.skeleton\f[R]) به درون ایمیج
.IP " 8." 4
نصب توزیع و بسته‌ها درون ایمیج
.IP " 9." 4
اجرای اسکریپت‌های آماده‌سازی روی ایمیج با آرگومان \f[B]final\f[R]
(\f[B]mkosi.prepare\f[R])
.IP "10." 4
نصب بسته‌های ساخت در لایه همپوشانی (overlay) در صورت پیکربندی هرگونه اسکریپت ساخت
.IP "11." 4
اجرای اسکریپت‌های آماده‌سازی روی overlay با آرگومان \f[B]build\f[R] در صورت
پیکربندی هرگونه اسکریپت ساخت (\f[B]mkosi.prepare\f[R])
.IP "12." 4
کش کردن ایمیج در صورت پیکربندی (\f[B]\-\-incremental=yes\f[R])
.IP "13." 4
اجرای اسکریپت‌های ساخت روی ایمیج + overlay در صورت پیکربندی هرگونه اسکریپت ساخت
(\f[B]mkosi.build\f[R])
.IP "14." 4
نهایی‌سازی ساخت در صورتی که قالب خروجی \f[B]none\f[R] پیکربندی شده باشد
.IP "15." 4
کپی خروجی‌های اسکریپت‌های ساخت به درون ایمیج
.IP "16." 4
کپی درخت‌های اضافی به درون ایمیج (\f[B]mkosi.extra\f[R])
.IP "17." 4
اجرای اسکریپت‌های پس از نصب (\f[B]mkosi.postinst\f[R])
.IP "18." 4
نوشتن فایل‌های پیکربندی مورد نیاز برای \f[B]Ssh=\f[R]، \f[B]Autologin=\f[R] و
\f[B]MakeInitrd=\f[R]
.IP "19." 4
نصب systemd\-boot و پیکربندی راه‌اندازی امن در صورت پیکربندی
(\f[B]\-\-secure\-boot=yes\f[R])
.IP "20." 4
اجرای \f[B]systemd\-sysusers\f[R]
.IP "21." 4
اجرای \f[B]systemd\-tmpfiles\f[R]
.IP "22." 4
اجرای \f[B]systemctl preset\-all\f[R]
.IP "23." 4
اجرای \f[B]depmod\f[R]
.IP "24." 4
اجرای \f[B]systemd\-firstboot\f[R].IP "25." 4
اجرای \f[B]systemd\-hwdb\f[R]
.IP "26." 4
حذف بسته‌ها و فایل‌ها (\f[B]RemovePackages=\f[R]،
\f[B]RemoveFiles=\f[R])
.IP "27." 4
اجرای برچسب‌گذاری مجدد SELinux در صورت نصب بودن یک شیوه‌نامهٔ SELinux
.IP "28." 4
اجرای اسکریپت‌های نهایی‌سازی (\f[B]mkosi.finalize\f[R])
.IP "29." 4
تولید تصویر یکپارچهٔ هسته (unified kernel image) در صورت پیکربندی شدن
.IP "30." 4
تولید قالب خروجی نهایی
.IP "31." 4
اجرای اسکریپت‌های پس از خروجی (\f[B]mkosi.postoutput\f[R])
.SH "اسکریپت‌ها (SCRIPTS)"
برای امکان‌پذیر ساختن سفارشی‌سازی‌هایی در تصویر که با ویژگی‌های توکار
\f[B]mkosi\f[R] قابل پیاده‌سازی نیستند، \f[B]mkosi\f[R] از اجرای اسکریپت‌ها
در نقاط مختلفی از فرایند ساخت تصویر پشتیبانی می‌کند که می‌توانند تصویر را بر
اساس نیاز سفارشی‌سازی کنند.
اسکریپت‌ها روی سیستم میزبان به عنوان ریشه (خواه ریشهٔ واقعی یا ریشه در
فضای نام کاربری که هنگام اجرای بدون‌امتیاز توسط \f[B]mkosi\f[R] ایجاد شده است)
همراه با یک محیط سفارشی‌شده اجرا می‌شوند تا تغییر تصویر را ساده‌تر کنند.
برای هر اسکریپت، سورس‌های ساخت پیکربندی‌شده (\f[B]BuildSources=\f[R])
پیش از اجرای اسکریپت در دایرکتوری کاری فعلی، بر روی دایرکتوری کاری فعلی سوار (mount) می‌شوند.
\f[B]$SRCDIR\f[R] طوری تنظیم می‌شود که به دایرکتوری کاری فعلی اشاره کند.
اسکریپت‌های زیر پشتیبانی می‌شوند:
.IP \(bu 2
اگر \f[B]mkosi.configure\f[R] (\f[B]ConfigureScripts=\f[R])
وجود داشته باشد، پیش از ساخت تصویر اجرا می‌شود.
از این اسکریپت می‌توان برای اصلاح پویای پیکربندی استفاده کرد.
این اسکریپت پیکربندی را به صورت سریالی‌شده در قالب JSON روی stdin دریافت می‌کند و باید
پیکربندی اصلاح‌شده را به صورت سریالی‌شده در قالب JSON روی stdout تحویل دهد.
توجه داشته باشید که این اسکریپت تنها هنگام ساخت یا بوت کردن تصویر
(افعال \f[B]build\f[R]، \f[B]vm\f[R]، \f[B]boot\f[R] و \f[B]shell\f[R])
اجرا می‌شود.
اگر یک درخت ابزار (tools tree) پیش‌فرض پیکربندی شده باشد، پیش از اجرای اسکریپت‌های پیکربندی
ساخته خواهد شد و اسکریپت‌های پیکربندی با در دسترس بودن درخت ابزار اجرا خواهند شد.
این همچنین بدان معناست که تغییرات اعمال‌شده توسط اسکریپت‌های پیکربندی در
خروجی \f[B]summary\f[R] قابل مشاهده نخواهد بود.
.IP \(bu 2
اگر \f[B]mkosi.sync\f[R] (\f[B]SyncScripts=\f[R]) وجود داشته باشد، پیش از
ساخته شدن تصویر اجرا می‌شود.
این اسکریپت ممکن است برای به‌روزرسانی سورس‌های مختلفی که برای ساخت
تصویر استفاده می‌شوند به کار رود.
یک مورد کاربرد، اجرای \f[B]git pull\f[R] روی مخازن مختلف سورس پیش از ساخت
تصویر است.
به طور مشخص، تنظیم \f[B]BuildSourcesEphemeral=\f[R] بر اسکریپت‌های همگام‌سازی
اعمال نمی‌شود، بدین معنی که اسکریپت‌های همگام‌سازی می‌توانند برای به‌روزرسانی سورس‌های ساخت
استفاده شوند حتی اگر \f[B]BuildSourcesEphemeral=\f[R] فعال باشد.
.IP \(bu 2
اگر \f[B]mkosi.prepare\f[R] (\f[B]PrepareScripts=\f[R]) وجود داشته باشد،
ابتدا درست پس از نصب بسته‌های نرم‌افزاری با آرگومان \f[B]final\f[R] فراخوانی می‌شود.
بار دوم درست پس از نصب بسته‌های ساخت و سوار شدن overlay ساخت بر روی دایرکتوری ریشهٔ
تصویر، با پارامتر خط فرمان \f[B]build\f[R] فراخوانی می‌شود.
این اسکریپت به شبکه دسترسی دارد و می‌توان از آن برای نصب بسته‌ها از منابعی غیر از
مدیر بستهٔ توزیع (مانند \f[B]pip\f[R]، \f[B]npm\f[R] و \&...)، پس از نصب همهٔ
بسته‌های نرم‌افزاری اما پیش از ذخیره در حافظهٔ پنهان (cache) تصویر (در صورت فعال بودن حالت افزایشی)
استفاده کرد.
برخلاف یک نصب همه‌منظوره، نصب بسته‌ها بر روی سیستم (\f[B]pip install\f[R]،
\f[B]npm install \-g\f[R]) به جای خودِ \f[B]$SRCDIR\f[R] ایمن است؛ چرا که تصویر
ساخت تنها برای یک پروژهٔ مشخص استفاده می‌شود و می‌تواند به راحتی دور انداخته شده و
مجدداً ساخته شود، بنابراین هیچ خطری برای تداخل وابستگی‌ها یا آلوده کردن سیستم میزبان وجود ندارد.
.IP \(bu 2
اگر \f[B]mkosi.build\f[R] (\f[B]BuildScripts=\f[R]) وجود داشته باشد، در حالی که
overlay ساخت بر روی دایرکتوری ریشهٔ تصویر سوار شده است اجرا می‌شود.
هنگام اجرای اسکریپت ساخت، \f[B]$DESTDIR\f[R] به دایرکتوری‌ای اشاره می‌کند که
اسکریپت باید هر فایل تولیدشده‌ای را که می‌خواهد در نهایت در تصویر قرار گیرد، در آن قرار دهد.
توجه داشته باشید که سیستم‌های ساخت مبتنی بر \f[B]make\f[R]\-، \f[B]automake\f[R]\-
و \f[B]meson\f[R]\- عموماً به \f[B]$DESTDIR\f[R] پایبند هستند، که این امر
ساخت درخت‌های \f[I]سورس\f[R] را از طریق اسکریپت ساخت بسیار طبیعی می‌سازد.
پس از اجرای اسکریپت ساخت، محتویات \f[B]$DESTDIR\f[R] درون تصویر کپی می‌شوند.
.IP \(bu 2
اگر \f[B]mkosi.postinst\f[R] (\f[B]PostInstallationScripts=\f[R])
وجود داشته باشد، پس از نصب درخت ساخت (اختیاری) و درخت‌های اضافی اجرا می‌شود.
از این اسکریپت می‌توان برای تغییر تصاویر بدون هیچ محدودیتی، پس از نصب همهٔ
بسته‌های نرم‌افزاری و سورس‌های ساخته‌شده استفاده کرد.
.IP \(bu 2
اگر \f[B]mkosi.finalize\f[R] (\f[B]FinalizeScripts=\f[R])
وجود داشته باشد، به عنوان آخرین گام از آماده‌سازی تصویر اجرا می‌شود.
.IP \(bu 2
اگر \f[B]mkosi.postoutput\f[R] (\f[B]PostOutputScripts=\f[R])
وجود داشته باشد، درست پس از تولید تمام فایل‌های خروجی و پیش از انتقال نهایی آن‌ها به دایرکتوری خروجی اجرا می‌شود.
این مورد می‌تواند برای تولید خروجی‌های اضافی یا جایگزین،
مانند \f[B]SHA256FILES\f[R] یا مانیفست‌های SBOM استفاده شود.
.IP \(bu 2
اگر \f[B]mkosi.clean\f[R] (\f[B]CleanScripts=\f[R]) وجود داشته باشد، درست پس از
پاک‌سازی خروجی‌های یک ساخت پیشین اجرا می‌شود.
یک اسکریپت پاک‌سازی می‌تواند هر خروجی‌ای را که \f[B]mkosi\f[R] از آن اطلاعی ندارد
(مانند دست‌ساخته‌ها از \f[B]SplitArtifacts=partitions\f[R] یا RPMهای ساخته‌شده در یک اسکریپت ساخت)
پاک‌سازی کند.
توجه داشته باشید که این اسکریپت حتی در صورت پیکربندی یک درخت ابزار، از آن استفاده نمی‌کند.
.IP \(bu 2
اگر \f[B]mkosi.version\f[R] وجود داشته باشد و قابل اجرا باشد، در حین تجزیهٔ
پیکربندی اجرا شده و مقدار \f[B]ImageVersion=\f[R] را با خروجی روی stdout مقداردهی می‌کند.
این مورد می‌تواند برای ردیابی نسخهٔ خارجی استفاده شود، به عنوان نمونه با \f[B]git
describe\f[R] یا \f[B]date \(aq+%Y\-%m\-%d\(aq\f[R].
توجه داشته باشید که این اسکریپت بدون هیچ‌گونه ایزوله‌سازی (sandboxing) روی سیستم میزبان اجرا می‌شود.
.IP \(bu 2
اگر \f[B]mkosi.rootpw\f[R] وجود داشته باشد و قابل اجرا باشد، در حین تجزیهٔ
پیکربندی اجرا شده و مقدار \f[B]RootPassword=\f[R] را با خروجی روی stdout مقداردهی می‌کند.
این مورد می‌تواند برای تولید تصادفی یک گذرواژه به کار رود و می‌توان آن را با خروجی دادن به
stderr یا خواندن \f[B]$MKOSI_CONFIG\f[R] در یک اسکریپت دیگر (مانند \f[B]mkosi.postoutput\f[R])
به یاد سپرد.
توجه داشته باشید که این اسکریپت بدون هیچ‌گونه ایزوله‌سازی (sandboxing) روی سیستم میزبان اجرا می‌شود.
.PP
اگر یک اسکریپت از پسوند \f[B].chroot\f[R] استفاده کند، \f[B]mkosi\f[R] پیش از
اجرای اسکریپت، با استفاده از \f[B]mkosi\-chroot\f[R] (پایین را ببینید) به درون تصویر chroot می‌کند.
به عنوان مثال، اگر \f[B]mkosi.postinst.chroot\f[R] وجود داشته باشد، \f[B]mkosi\f[R]
به درون تصویر chroot کرده و آن را به عنوان اسکریپت پس از نصب اجرا می‌کند.
.PP
به جای یک اسکریپت تک‌فایلی، \f[B]mkosi\f[R] همچنین تمام فایل‌ها را به ترتیب واژه‌نگاری (lexicographical)
از دایرکتوری‌های \f[B].d\f[R] با نام‌گذاری مناسب می‌خواند؛ مثلاً تمام فایل‌های موجود
در یک دایرکتوری \f[B]mkosi.build.d\f[R] به عنوان اسکریپت‌های ساخت استفاده خواهند شد.
این قابلیت توسط موارد زیر پشتیبانی می‌شود:
.IP \(bu 2
\f[B]mkosi.sync.d\f[R]،
.IP \(bu 2
\f[B]mkosi.prepare.d\f[R]،
.IP \(bu 2
\f[B]mkosi.build.d\f[R]،
.IP \(bu 2
\f[B]mkosi.postinst.d\f[R]،
.IP \(bu 2
\f[B]mkosi.finalize.d\f[R]،
.IP \(bu 2
\f[B]mkosi.postoutput.d\f[R]، و
.IP \(bu 2
\f[B]mkosi.clean.d\f[R].
.PP
این قابلیت می‌تواند با پسوند \f[B].chroot\f[R] ترکیب شود؛
مثلاً \f[B]mkosi.build.d/01\-foo.sh\f[R] بدون chroot به درون تصویر اجرا می‌شود و
\f[B]mkosi.build.d/02\-bar.sh.chroot\f[R] پس از chroot اولیه به درون تصویر اجرا خواهد شد.
.PP
اسکریپت‌های اجراشده توسط \f[B]mkosi\f[R] متغیرهای محیطی زیر را دریافت می‌کنند:
.IP \(bu 2
\f[B]$ARCHITECTURE\f[R] شامل معماری برگرفته از تنظیم \f[B]Architecture=\f[R] است.
اگر \f[B]Architecture=\f[R] تنظیم نشده باشد، حاوی معماری بومی ماشین میزبان خواهد بود.
برای مقادیر ممکن این متغیر، مستندات \f[B]Architecture=\f[R] را ببینید.
.IP \(bu 2
\f[B]$QEMU_ARCHITECTURE\f[R] شامل معماریِ \f[B]$ARCHITECTURE\f[R] در قالبی است
که توسط \f[B]qemu\f[R] استفاده می‌شود.
برای یافتن باینری qemu کاربردی است (
\f[B]qemu\-system\-$QEMU_ARCHITECTURE\f[R]).
.IP \(bu 2
\f[B]$EFI_ARCHITECTURE\f[R] شامل معماریِ \f[B]$ARCHITECTURE\f[R] در قالبی است
که توسط \f[B]UEFI\f[R] استفاده می‌شود.
این متغیر روی معماری‌هایی که از \f[B]UEFI\f[R] پشتیبانی نمی‌کنند، تنظیم‌نشده (unset) است.
.IP \(bu 2
\f[B]$DISTRIBUTION\f[R] حاوی توزیع برگرفته از تنظیم \f[B]Distribution=\f[R] است.
.IP \(bu 2
\f[B]$RELEASE\f[R] حاوی انتشار برگرفته از تنظیم \f[B]Release=\f[R] است.
.IP \(bu 2
\f[B]$DISTRIBUTION_ARCHITECTURE\f[R] شامل معماریِ \f[B]$ARCHITECTURE\f[R] در قالبی است
که توسط توزیع پیکربندی‌شده استفاده می‌شود.
.IP \(bu 2
\f[B]$PROFILES\f[R] شامل پروفایل‌های برگرفته از تنظیم \f[B]Profiles=\f[R] به صورت
یک رشتهٔ جداشده با کاما است.
.IP \(bu 2
اگر تصویر ذخیره‌شده در حافظهٔ پنهان در دسترس باشد، مقدار \f[B]$CACHED\f[R] برابر با \f[B]1\f[R]
و در غیر این صورت \f[B]0\f[R] تنظیم می‌شود.
.IP \(bu 2
\f[B]$CHROOT_SCRIPT\f[R] شامل مسیر اسکریپت در حال اجرا نسبت به دایرکتوری ریشهٔ تصویر است.
مورد کاربرد اصلی این متغیر در ترکیب با اسکریپت \f[B]mkosi\-chroot\f[R] است.
برای اطلاعات بیشتر، توضیحات \f[B]mkosi\-chroot\f[R] در زیر را ببینید.
.IP \(bu 2
\f[B]$SRCDIR\f[R] شامل مسیر دایرکتوری‌ای است که \f[B]mkosi\f[R] از آن فراخوانی شده بود،
به همراه هر سورس ساخت پیکربندی‌شده‌ای که روی آن سوار شده است.
\f[B]$CHROOT_SRCDIR\f[R] شامل مقداری است که \f[B]$SRCDIR\f[R] پس از فراخوانی
\f[B]mkosi\-chroot\f[R] خواهد داشت..IP \(bu 2
\f[B]$BUILDDIR\f[R] تنها در صورتی تعریف می‌شود که \f[B]mkosi.builddir\f[R] وجود داشته باشد
و به دایرکتوری ساختی اشاره می‌کند که باید استفاده شود.
این متغیر برای تمامی سیستم‌های ساختی که از ساخت‌های خارج از درخت منبع (out\-of\-tree)
پشتیبانی می‌کنند مفید است تا از دست‌ساخته‌های تولیدشده در اجراهای پیشین دوباره استفاده نمایند.
\f[B]$CHROOT_BUILDDIR\f[R] حاوی مقداری است که \f[B]$BUILDDIR\f[R]
پس از فراخوانی \f[B]mkosi\-chroot\f[R] خواهد داشت.
.IP \(bu 2
\f[B]$DESTDIR\f[R] دایرکتوری‌ای است که هر نرم‌افزار نصب‌شدهٔ ایجادشده توسط
یک اسکریپت ساخت می‌تواند درون آن قرار گیرد.
این متغیر تنها هنگام اجرای یک اسکریپت ساخت تنظیم می‌شود.
\f[B]$CHROOT_DESTDIR\f[R] حاوی مقداری است که \f[B]$DESTDIR\f[R]
پس از فراخوانی \f[B]mkosi\-chroot\f[R] خواهد داشت.
.IP \(bu 2
\f[B]$OUTPUTDIR\f[R] به دایرکتوری صحنه‌سازی (staging) اشاره دارد که برای ذخیرهٔ
دست‌ساخته‌های ساخت تولیدشده در طول فرایند ساخت استفاده می‌شود.
\f[B]$CHROOT_OUTPUTDIR\f[R] حاوی مقداری است که \f[B]$OUTPUTDIR\f[R]
پس از فراخوانی \f[B]mkosi\-chroot\f[R] خواهد داشت.
.IP \(bu 2
\f[B]$PACKAGEDIR\f[R] به دایرکتوری حاوی مخزن محلی بسته‌ها اشاره دارد.
اسکریپت‌های ساخت می‌توانند با نوشتن بسته‌ها در \f[B]$PACKAGEDIR\f[R]\،
بسته‌های بیشتری به این مخزن محلی بیفزایند.
.IP \(bu 2
\f[B]$ARTIFACTDIR\f[R] به دایرکتوری‌ای اشاره می‌کند که برای تبادل دست‌ساخته‌های ساخت
تولیدشده در طول ساخت و در دسترس قرار دادن آن‌ها برای استفاده توسط mkosi به کار می‌رود.
این متغیر شبیه به \f[B]PACKAGEDIR\f[R] است، اما برای دست‌ساخته‌هایی در نظر گرفته شده که
ممکن است بسته‌های شناخته‌شده برای مدیر بسته نباشند، مانند initrdهای تولیدشده توسط
مولدهایی به‌جز خود mkosi.
اسکریپت‌های ساخت می‌توانند با قرار دادن دست‌ساخته‌ها در \f[B]$ARTIFACTDIR\f[R]\،
موارد بیشتری را به این دایرکتوری بیفزایند.
فایل‌های این دایرکتوری تنها برای ساخت فعلی در دسترس هستند و برخلاف محتویات
\f[B]$OUTPUTDIR\f[R] به بیرون کپی نمی‌شوند.
.RS 2
.PP
\f[B]mkosi\f[R] همچنین از زیردایرکتوری‌های خاصی در یک دایرکتوری دست‌ساخته‌ها
استفاده می‌کند تا از محتویات آن‌ها به صورت خودکار در مراحلی معین بهره گیرد.
در حال حاضر دو زیردایرکتوری زیر در دایرکتوری دست‌ساخته‌ها توسط mkosi استفاده می‌شوند:
.IP \(bu 2
\f[B]io.mkosi.microcode\f[R]: تمام فایل‌های موجود در این دایرکتوری به عنوان فایل‌های
ریزکد (microcode) استفاده می‌شوند؛ به این صورت که با ترتیب الفبایی به ابتدای initrdها الحاق می‌گردند.
.IP \(bu 2
\f[B]io.mkosi.initrd\f[R]: تمام فایل‌های موجود در این دایرکتوری به عنوان initrd استفاده
شده و با ترتیب الفبایی به یکدیگر پیوست می‌شوند.
.PP
توصیه می‌شود کاربرانی که از \f[B]$ARTIFACTDIR\f[R] استفاده می‌کنند، موارد مورد استفادهٔ
خود را در یک دایرکتوری فضای نام مشابه قرار دهند، مانند \f[B]local.my.namespace\f[R].
.RE
.IP \(bu 2
\f[B]$BUILDROOT\f[R] دایرکتوری ریشهٔ ایمیج در حال ساخت است که بسته به اسکریپتی که در حال
اجراست، ممکن است لایهٔ هم‌پوشان ساخت (build overlay) نیز به صورت اختیاری بر روی آن سوار (mount) شده باشد.
.IP \(bu 2
\f[B]$WITH_DOCS\f[R] بسته به اینکه آیا ساخت بدون مستندات نصب‌شده یا همراه با آن
درخواست شده است (\f[B]WithDocs=yes\f[R])، برابر با \f[B]0\f[R] یا \f[B]1\f[R] است.
یک اسکریپت ساخت در صورتی که \f[B]$WITH_DOCS\f[R] روی \f[B]0\f[R] تنظیم شده باشد،
باید از نصب هرگونه مستندات بسته در \f[B]$DESTDIR\f[R] جلوگیری کند.
.IP \(bu 2
\f[B]$WITH_TESTS\f[R] بسته به اینکه آیا ساخت بدون اجرای مجموعهٔ آزمون‌ها یا همراه با آن
درخواست شده است (\f[B]WithTests=no\f[R])، برابر با \f[B]0\f[R] یا \f[B]1\f[R] است.
یک اسکریپت ساخت در صورتی که \f[B]$WITH_TESTS\f[R] برابر با \f[B]0\f[R] باشد،
باید از اجرای هرگونه آزمون واحد یا یکپارچه‌سازی خودداری کند.
.IP \(bu 2
\f[B]$WITH_NETWORK\f[R] بسته به اینکه ساخت بدون شبکه یا با دسترسی به شبکه
در حال اجرا باشد (\f[B]WithNetwork=no\f[R])، برابر با \f[B]0\f[R] یا \f[B]1\f[R] است.
یک اسکریپت ساخت در صورتی که \f[B]$WITH_NETWORK\f[R] برابر با \f[B]0\f[R] باشد،
باید از هرگونه ارتباط شبکه‌ای خودداری کند.
.IP \(bu 2
\f[B]$SOURCE_DATE_EPOCH\f[R] در صورت درخواست تعریف می‌شود
(\f[B]SourceDateEpoch=TIMESTAMP\f[R]،
\f[B]Environment=SOURCE_DATE_EPOCH=TIMESTAMP\f[R] یا متغیر محیطی میزبان
\f[B]$SOURCE_DATE_EPOCH\f[R]).
این متغیر برای بازتولیدپذیر ساختن فرایند ساخت مفید است.
برای اطلاعات بیشتر \c
.UR https://reproducible-builds.org/specs/source-date-epoch
SOURCE_DATE_EPOCH
.UE \c
\ را ببینید.
.IP \(bu 2
\f[B]$MKOSI_UID\f[R] و \f[B]$MKOSI_GID\f[R] به ترتیب شناسه کاربری (uid) و شناسه گروهی (gid)
کاربری هستند که mkosi را فراخوانی کرده است.
.IP \(bu 2
\f[B]$MKOSI_CONFIG\f[R] فایلی شامل یک خلاصه‌سازی json از تنظیمات ایمیج فعلی است.
این فایل را می‌توان در داخل اسکریپت‌ها تجزیه کرد تا به تمام تنظیمات ایمیج فعلی دسترسی پیدا کرد.
.IP \(bu 2
\f[B]$IMAGE_ID\f[R] حاوی شناسه برگرفته از تنظیم \f[B]ImageId=\f[R]
یا \f[B]\-\-image\-id=\f[R] است.
.IP \(bu 2
\f[B]$IMAGE_VERSION\f[R] حاوی نگارش برگرفته از تنظیم
\f[B]ImageVersion=\f[R] یا \f[B]\-\-image\-version=\f[R] است.
.IP \(bu 2
\f[B]$MKOSI_DEBUG\f[R] بسته به اینکه آیا خروجی اشکال‌زدایی فعال است یا خیر،
برابر با \f[B]0\f[R] یا \f[B]1\f[R] است.
.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[B]configure\f[R]
T}@T{
\f[B]sync\f[R]
T}@T{
\f[B]prepare\f[R]
T}@T{
\f[B]build\f[R]
T}@T{
\f[B]postinst\f[R]
T}@T{
\f[B]finalize\f[R]
T}@T{
\f[B]postoutput\f[R]
T}@T{
\f[B]clean\f[R]
T}
_
T{
\f[B]ARCHITECTURE\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]ARTIFACTDIR\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]BUILDDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]BUILDROOT\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]CACHED\f[R]
T}@T{
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]CHROOT_BUILDDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]CHROOT_DESTDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]CHROOT_OUTPUTDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]CHROOT_SCRIPT\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]CHROOT_SRCDIR\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]MKOSI_DEBUG\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]DESTDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]DISTRIBUTION\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]DISTRIBUTION_ARCHITECTURE\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]EFI_ARCHITECTURE\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]IMAGE_ID\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]IMAGE_VERSION\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]MKOSI_CONFIG\f[R]
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]MKOSI_GID\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]MKOSI_UID\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]OUTPUTDIR\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]PACKAGEDIR\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]PROFILES\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}
T{
\f[B]QEMU_ARCHITECTURE\f[R]
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]RELEASE\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]SOURCE_DATE_EPOCH\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}
T{
\f[B]SRCDIR\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]WITH_DOCS\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]WITH_NETWORK\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]WITH_TESTS\f[R]
T}@T{
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
.TE.PP
علاوه بر این، هنگام اجرای یک اسکریپت، چند اسکریپت از طریق \f[B]$PATH\f[R] در دسترس قرار می‌گیرند تا موارد استفاده معمول را ساده‌تر کنند.
.IP \(bu 2
\f[B]mkosi\-chroot\f[R]: این اسکریپت به درون ایمیج chroot کرده و دستور داده‌شده را اجرا می‌کند.
افزون بر chroot به داخل ایمیج، این اسکریپت فایل‌ها و دایرکتوری‌های گوناگونی (\f[B]$SRCDIR\f[R]، \f[B]$DESTDIR\f[R]، \f[B]$BUILDDIR\f[R]، \f[B]$OUTPUTDIR\f[R]، \f[B]$CHROOT_SCRIPT\f[R]) را نیز در ایمیج سوار (mount) کرده و متغیرهای محیطی متناظر را به‌گونه‌ای تغییر می‌دهد که به مکان‌های درون ایمیج اشاره کنند.
همچنین فایل‌سیستم‌های APIVFS (\f[B]/proc\f[R]، \f[B]/dev\f[R]، \&...) را سوار می‌کند تا اطمینان حاصل شود اسکریپت‌ها و ابزارهای اجراشده درون chroot به‌درستی کار می‌کنند.
همچنین در صورت درخواست، \f[B]/etc/resolv.conf\f[R] را از میزبان به درون chroot منتقل می‌کند تا تفکیک DNS درون chroot کار کند.
پس از خروج دستور mkosi\-chroot، نقاط اتصال مختلف پاک‌سازی می‌شوند.
.RS 2
.PP
برای نمونه، جهت فراخوانی \f[B]ls\f[R] درون ایمیج، از دستور زیر استفاده کنید:
.IP
.EX
mkosi\-chroot ls ...
.EE
.PP
برای اجرای کل اسکریپت درون ایمیج، یک پسوند \f[B].chroot\f[R] به نام آن بیفزایید (\f[B]mkosi.build.chroot\f[R] به‌جای \f[B]mkosi.build\f[R] و غیره).
.RE
.IP \(bu 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[B]$PATH\f[R] قرار می‌گیرند تا اطمینان حاصل شود این دستورها به‌جای سیستم میزبان، بر روی دایرکتوری ریشهٔ ایمیج و با پیکربندی ارائه‌شده توسط کاربر عمل می‌کنند.
این بدان معناست که از درون یک اسکریپت، می‌توانید برای مثال دستور \f[B]dnf install vim\f[R] را برای نصب vim در ایمیج اجرا کنید.
.RS 2
.PP
علاوه بر این، \f[B]mkosi\-install\f[R]، \f[B]mkosi\-reinstall\f[R]، \f[B]mkosi\-upgrade\f[R] و \f[B]mkosi\-remove\f[R] عملیات متناظر مدیر بسته‌ای را که برای ساخت ایمیج استفاده می‌شود، فراخوانی خواهند کرد.
.RE
.IP \(bu 2
دستور \f[B]git\f[R] به‌طور خودکار با \f[B]safe.directory=*\f[R] فراخوانی می‌شود تا هنگام اجرا به‌عنوان کاربر root در یک فضای‌نام کاربر (user namespace)، از خطاهای مجوز جلوگیری شود.
.IP \(bu 2
دستورهای \f[B]useradd\f[R] و \f[B]groupadd\f[R] هنگام اجرا در خارج از ایمیج، به‌طور خودکار با \f[B]\-\-root=$BUILDROOT\f[R] فراخوانی می‌شوند.
.PP
هنگام اجرای اسکریپت‌ها، هر دایرکتوری که هنوز قابل نوشتن باشد نیز فقط‌خواندنی می‌شود (\f[B]/home\f[R]، \f[B]/var\f[R]، \f[B]/root\f[R]، \&...) و تنها حداقل مجموعه دایرکتوری‌هایی که نیاز به نوشتن دارند، قابل نوشتن باقی می‌مانند.
این کار برای اطمینان از این است که هنگام اجرای \f[B]mkosi\f[R] به‌عنوان root، اسکریپت‌ها نتوانند به سیستم میزبان آسیبی برسانند یا در آن اختلال ایجاد کنند.
.PP
توجه داشته باشید که هنگام اجرای اسکریپت‌ها، همه دایرکتوری‌های منبع ناپایدار (ephemeral) می‌شوند، به این معنی که تمام تغییرات اعمال‌شده در دایرکتوری‌های منبع حین اجرای اسکریپت‌ها، پس از پایان اجرای آن‌ها دور ریخته می‌شوند.
اگر نیاز به ماندگاری داده‌ها بین دفعات ساخت دارید، از دایرکتوری‌های خروجی، ساخت یا حافظه پنهان (cache) استفاده کنید.
.SH "فایل‌ها (FILES)"
برای آسان‌تر ساختن ایجاد ایمیج‌ها برای نسخه‌های در حال توسعه پروژه‌هایتان، \f[B]mkosi\f[R] می‌تواند داده‌های پیکربندی را با این فرض که از یک درخت \f[I]منبع (source)\f[R] فراخوانی شده است، از دایرکتوری محلی بخواند.
به‌طور خاص، فایل‌های زیر در صورت وجود در دایرکتوری محلی استفاده می‌شوند:
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.skeleton/\f[B]\f[R] یا بایگانی \f[B]\f[R]mkosi.skeleton.tar\f[B]\f[R] می‌تواند برای درج فایل‌ها در ایمیج استفاده شود.
فایل‌ها \f[I]پیش از\f[R] نصب بسته‌های توزیع در ایمیج کپی می‌شوند.
این امر امکان ایجاد فایل‌هایی را که باید زودتر ارائه شوند، برای نمونه برای پیکربندی مدیر بسته یا اعمال پیش‌تنظیم‌های systemd، فراهم می‌کند.
.RS 2
.PP
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
.RE
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.extra/\f[B]\f[R] یا بایگانی \f[B]\f[R]mkosi.extra.tar\f[B]\f[R] می‌تواند برای درج فایل‌های اضافی در ایمیج، فراتر از آنچه توزیع در بسته‌های خود شامل می‌شود، استفاده شود.
آن‌ها شبیه به \f[B]mkosi.skeleton/\f[R] و \f[B]mkosi.skeleton.tar\f[R] هستند، اما فایل‌ها \f[I]پس از\f[R] نصب سیستم‌عامل در درخت دایرکتوری ایمیج کپی می‌شوند.
.RS 2
.PP
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
.RE
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.sandbox/\f[B]\f[R] یا بایگانی \f[B]\f[R]mkosi.sandbox.tar\f[B]\f[R] می‌تواند برای پیکربندی مدیر بسته بدون درج فایل‌ها در ایمیج استفاده شود.
اگر فایل‌ها باید درون ایمیج گنجانده شوند، به‌جای آن باید از \f[B]mkosi.skeleton/\f[R] و \f[B]mkosi.skeleton.tar\f[R] استفاده شود.
.RS 2
.PP
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
.RE
.IP \(bu 2
فایل تنظیمات nspawn با نام \f[B]\f[R]mkosi.nspawn\f[B]\f[R]، در صورت وجود، در همان محل فایل ایمیج خروجی کپی خواهد شد.
این امر کاربردی است زیرا nspawn برای تنظیمات بیشتر زمان اجرای کانتینر، به دنبال فایل‌های تنظیمات در کنار فایل‌های ایمیجی که بوت می‌کند می‌گردد.
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.cache/\f[B]\f[R]، در صورت وجود، به‌طور خودکار به‌عنوان حافظه پنهان بارگیری بسته‌ها استفاده می‌شود تا اجرای مکرر ابزار را سرعت ببخشد.
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.builddir/\f[B]\f[R]، در صورت وجود، چنانچه دستورهای ساخت در اسکریپت‌های \f[B]mkosi.build\f[R] از آن پشتیبانی کنند، به‌طور خودکار به‌عنوان دایرکتوری ساخت خارج از درخت منبع (out\-of\-tree) استفاده می‌شود.
به‌طور خاص، این دایرکتوری در کانتینر ساخت سوار خواهد شد و هنگام فراخوانی اسکریپت‌های ساخت، متغیر محیطی \f[B]$BUILDDIR\f[R] روی آن تنظیم می‌شود.
سپس یک اسکریپت ساخت می‌تواند از این دایرکتوری به‌عنوان دایرکتوری ساخت، برای ساخت‌های خارج از درخت به سبک \f[B]automake\f[R] یا \f[B]ninja\f[R] استفاده کند.
این امر سرعت ساخت را به‌میزان قابل‌توجهی افزایش می‌دهد، به‌ویژه زمانی که \f[B]mkosi\f[R] در حالت افزایشی (\f[B]\-i\f[R]) استفاده می‌شود: نه‌تنها ایمیج و لایهٔ ساخت، بلکه درخت ساخت نیز بین فراخوانی‌های بعدی مجدداً استفاده می‌شود.
توجه داشته باشید که اگر این دایرکتوری وجود نداشته باشد، متغیر محیطی \f[B]$BUILDDIR\f[R] تنظیم نمی‌شود و این بر عهدهٔ اسکریپت‌های ساخت است که تصمیم بگیرند ساخت درون درخت (in\-tree) انجام شود یا ساخت خارج از درخت (out\-of\-tree)، و از کدام دایرکتوری ساخت استفاده شود.
.IP \(bu 2
فایل \f[B]\f[R]mkosi.rootpw\f[B]\f[R] می‌تواند برای ارائه گذرواژه کاربر root ایمیج استفاده شود.
اگر گذرواژه دارای پیشوند \f[B]hashed:\f[R] باشد، به‌عنوان یک گذرواژهٔ root از پیش هش‌شده در نظر گرفته می‌شود.
گذرواژه می‌تواند به‌صورت اختیاری با یک نویسه خط جدید همراه باشد که به‌طور ضمنی حذف می‌شود.
فایل باید دارای حالت دسترسی 0600 یا کمتر باشد.
اگر این فایل وجود نداشته باشد، گذرواژه پیش‌فرض توزیع برای root تنظیم می‌شود (که معمولاً به این معنی است که دسترسی به کاربر root مسدود است).
.IP \(bu 2
فایل \f[B]\f[R]mkosi.passphrase\f[B]\f[R] عبارت عبور (passphrase) را جهت استفاده هنگام انتخاب رمزنگاری LUKS ارائه می‌دهد.
این فایل باید دقیقاً حاوی عبارت عبور باشد و به یک نویسه خط جدید ختم نشود (یعنی با همان قالبی که \f[B]cryptsetup\f[R] و \f[B]/etc/crypttab\f[R] برای فایل‌های عبارت عبور انتظار دارند).
فایل باید دارای حالت دسترسی 0600 یا کمتر باشد.
.IP \(bu 2
فایل‌های \f[B]\f[R]mkosi.crt\f[B]\f[R] و \f[B]\f[R]mkosi.key\f[B]\f[R] حاوی یک گواهی X.509 و کلید خصوصی PEM هستند که هنگام نیاز به امضا (UEFI SecureBoot، verity، \&...) استفاده می‌شوند.
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.output/\f[B]\f[R] برای ذخیره تمام دست‌ساخته‌های ساخت استفاده می‌شود.
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.credentials/\f[B]\f[R] به‌عنوان منبعی برای اعتبارنامه‌های اضافی مشابه گزینهٔ \f[B]Credentials=\f[R] استفاده می‌شود.
برای هر فایل در این دایرکتوری، نام فایل به‌عنوان نام اعتبارنامه و محتویات فایل به‌عنوان مقدار اعتبارنامه استفاده خواهد شد، یا چنانچه فایل قابل اجرا باشد، \f[B]mkosi\f[R] فایل را اجرا کرده و خروجی دستور در stdout به‌عنوان مقدار اعتبارنامه استفاده می‌شود.
خروجی به stderr نادیده گرفته خواهد شد.
اعتبارنامه‌های پیکربندی‌شده با \f[B]Credentials=\f[R] بر فایل‌های موجود در \f[B]mkosi.credentials\f[R] اولویت دارند.
.IP \(bu 2
دایرکتوری \f[B]\f[R]mkosi.repart/\f[B]\f[R] به‌عنوان منبعی برای فایل‌های تعریف پارتیشن \f[B]systemd\-repart\f[R] استفاده می‌شود که هنگام ساخت ایمیج دیسک به \f[B]systemd\-repart\f[R] ارسال می‌شوند.
اگر این دایرکتوری وجود نداشته باشد و تنظیم \f[B]RepartDirectories=\f[R] پیکربندی نشده باشد، \f[B]mkosi\f[R] به‌طور پیش‌فرض از فایل‌های تعریف پارتیشن زیر استفاده خواهد کرد:
.RS 2
.PP
\f[B]00\-esp.conf\f[R] (اگر در حال ساخت یک ایمیج قابل بوت باشیم):
.IP
.EX
\f[B][Partition]\f[R]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M
.EE
.PP
\f[B]05\-bios.conf\f[R] (اگر در حال ساخت یک ایمیج قابل بوت BIOS باشیم):
.IP
.EX
\f[B][Partition]\f[R]
\f[I]# UUID of the grub BIOS boot partition which grubs needs on GPT to\f[R]
\f[I]# embed itself into.\f[R]
Type=21686148\-6449\-6e6f\-744e\-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M
.EE.PP
\f[B]10\-root.conf\f[R]
.IP
.EX
\f[B][Partition]\f[R]
Type=root
Format=<distribution\-default\-filesystem>
CopyFiles=/
Minimize=guess
.EE
.PP
توجه داشته باشید که اگر \f[B]mkosi.repart/\f[R] یافت شود یا از \f[B]RepartDirectories=\f[R] استفاده گردد، هیچ‌یک از تعاریف پیش‌فرض پارتیشن استفاده نخواهند شد.
.RE
.PP
تمامی این فایل‌ها اختیاری هستند.
.PP
توجه داشته باشید که مکان همه این فایل‌ها همچنین می‌تواند هنگام فراخوانی از طریق سوئیچ‌های خط فرمان و به عنوان تنظیماتی در \f[B]mkosi.conf\f[R] پیکربندی شود، در صورتی که تنظیمات پیش‌فرض برای یک پروژه مناسب نباشند.
.SH "کَش‌کردن (CACHING)"
دستور \f[B]mkosi\f[R] از سه کَش مختلف برای افزایش سرعت ساخت مجدد و تکراری ایمیج‌ها پشتیبانی می‌کند.
به طور مشخص:
.IP "1." 3
کَش بسته‌های مدیر بسته توزیع بین دفعات ساخت نگهداری می‌شود.
مکان آن را می‌توان با گزینه \f[B]PackageCacheDirectory=\f[R] یا دایرکتوری \f[B]mkosi.pkgcache/\f[R] پیکربندی کرد.
این شیوه از کَش‌کردن بر مدیر بسته توزیع اتکا دارد و بسته‌های توزیع (RPM، deb و \&...) را پس از بارگیری، اما پیش از استخراج (unpack) ذخیره می‌کند.
.IP "2." 3
متادیتای مخزن توزیع در صورتی کَش می‌شود که یک دایرکتوری کَش با \f[B]CacheDirectory=\f[R] یا دایرکتوری \f[B]mkosi.cache/\f[R] پیکربندی شده باشد.
زمان همگام‌سازی مجدد متادیتای مخزن توسط گزینه \f[B]CacheOnly=\f[R] کنترل می‌شود که به طور پیش‌فرض همیشه متادیتای مخزن را مجدداً همگام‌سازی می‌کند، مگر اینکه تمامی ایمیج‌ها کَش شده باشند (گزینه \f[B]Incremental=\f[R] را ببینید).
هر زمان که متادیتای مخزن مجدداً همگام‌سازی شود، تمامی ایمیج‌های کَش‌شده نامعتبر می‌شوند.
.IP "3." 3
اگر حالت ساخت افزایشی با \f[B]Incremental=yes\f[R] فعال باشد، نسخه‌های کَش‌شده از ایمیج نهایی و build overlay بلافاصله پیش از کپی شدن سورس‌های ساخت (برای build overlay) یا کپی شدن مصنوعات تولیدشده توسط \f[B]mkosi.build\f[R] (در مورد ایمیج نهایی) ایجاد می‌شوند.
این شیوه از کَش‌کردن اجازه می‌دهد مرحله زمان‌بر استخراج بسته‌ها در مدیر بسته‌های توزیع دور زده شود، اما تنها زمانی مؤثر است که فهرست بسته‌های مورد استفاده ثابت بماند، در حالی که سورس‌های ساخت و اسکریپت‌های آن به طور منظم تغییر کنند.
.IP "4." 3
در نهایت، بین چندین ساخت مختلف، دایرکتوری مصنوعات ساخت ممکن است با استفاده از گزینه \f[B]BuildDirectory=\f[R] یا دایرکتوری \f[B]mkosi.builddir/\f[R] به اشتراک گذاشته شود.
این دایرکتوری به سیستم‌های ساختی مانند Meson اجازه می‌دهد تا سورس‌های کامپایل‌شده از ساخت قبلی را مجدداً استفاده کنند، و در نتیجه فرایند اجرای اسکریپت ساخت \f[B]mkosi.build\f[R] را سرعت بخشند.
.SH "درخت‌های ابزار (TOOLS TREES)"
درخت‌های ابزار (Tools trees) یک ایمیج ثانویه هستند که mkosi می‌تواند از آن برای ساخت ایمیج‌های اصلی استفاده کند.
این قابلیت برای بازتولیدپذیرتر کردن ساخت ایمیج‌ها مفید است، اما همچنین امکان استفاده از ابزارهای جدیدتری را فراهم می‌کند که هنوز در توزیع میزبانی که mkosi را اجرا می‌کند در دسترس نیستند.
.PP
درخت‌های ابزار می‌توانند از طریق گزینه \f[B]ToolsTree=\f[R]، دایرکتوری \f[B]mkosi.tools\f[R] ارائه شوند، یا در صورت تنظیم \f[B]ToolsTree=yes\f[R] به طور خودکار توسط mkosi ساخته شوند.
برای بیشتر موارد، استفاده از درخت‌های ابزار پیش‌فرض کافی است و به‌کارگیری یک درخت ابزار توصیه می‌شود.
.PP
درخت‌های ابزار کاملاً سفارشی را می‌توان مانند هر ایمیج دیگر mkosi ساخت، اما mkosi یک include داخلی ارائه می‌دهد که بسته‌های درخت ابزار پیش‌فرض را فراهم می‌کند:
.IP
.EX
mkosi \-\-include=mkosi\-tools \-\-format=directory
.EE
.PP
درخت‌های ابزار، از جمله درخت‌های ابزار پیش‌فرض، می‌توانند از طریق متغیرهای مختلف \f[B]ToolsTree*=\f[R] و همچنین فایل یا دایرکتوری پیکربندی \f[B]mkosi.tools.conf\f[R] بیشتر سفارشی‌سازی شوند.
فرمت خروجی برای درخت‌های ابزار در حال حاضر نمی‌تواند از طریق فایل‌های پیکربندی تغییر داده شود.
.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{
Fedora
T}@T{
CentOS
T}@T{
Debian
T}@T{
Kali
T}@T{
Ubuntu
T}@T{
Arch
T}@T{
openSUSE
T}@T{
postmarketOS
T}
_
T{
\f[B]acl\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]apt\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]archlinux\-keyring\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]attr\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]bash\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]btrfs\-progs\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]ca\-certificates\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]coreutils\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]cpio\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]createrepo_c\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]curl\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]debian\-keyring\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}
T{
\f[B]diffutils\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]distribution\-gpg\-keys\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]dnf\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]dosfstools\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]e2fsprogs\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]edk2\-ovmf\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]erofs\-utils\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]findutils\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]git\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]grep\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]grub\-tools\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]jq\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]kali\-archive\-keyring\f[R]
T}@T{
T}@T{
T}@T{
T}@T{
✓
T}@T{
T}@T{
T}@T{
T}@T{
T}
T{
\f[B]kmod\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]less\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]mtools\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]nano\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]opensc\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]openssh\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]openssl\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]pkcs11\-provider\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]perf\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]sed\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]pacman\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}
T{
\f[B]p11\-kit\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]policycoreutils\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]qemu\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]sbsigntools\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]socat\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]squashfs\-tools\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]strace\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]swtpm\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]systemd\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]ukify\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]tar\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]ubuntu\-keyring\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}@T{
T}
T{
\f[B]util\-linux\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]virtiofsd\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]virt\-firmware\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]xfsprogs\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]xz\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]zstd\f[R]
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}
T{
\f[B]zypper\f[R]
T}@T{
✓
T}@T{
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
✓
T}@T{
T}
.TE.SH "ساخت چندین ایمیج (BUILDING MULTIPLE IMAGES)"
اگر دایرکتوری \f[B]mkosi.images/\f[R] وجود داشته باشد، \f[B]mkosi\f[R]
پیکربندی‌های مجزای زیرایمیج‌ها را از آن بارگذاری کرده و هر یک از آن‌ها را می‌سازد.
پیکربندی‌های ایمیج می‌توانند دایرکتوری‌های حاوی فایل‌های پیکربندی
\f[B]mkosi\f[R] یا فایل‌های عادی با پسوند \f[B].conf\f[R] باشند.
.PP
هنگامی که پیکربندی‌های ایمیج در \f[B]mkosi.images/\f[R] یافت شوند،
\f[B]mkosi\f[R] ایمیج‌های مشخص‌شده در تنظیم \f[B]Dependencies=\f[R] ایمیج اصلی
و تمامی وابستگی‌های آن‌ها را می‌سازد (یا در صورتی که هیچ ایمیجی صراحتاً با استفاده از
\f[B]Dependencies=\f[R] در پیکربندی ایمیج اصلی مشخص نشده باشد، همه آن‌ها را می‌سازد).
برای افزودن وابستگی‌ها میان زیرایمیج‌ها، می‌توان از تنظیم \f[B]Dependencies=\f[R]
نیز استفاده کرد.
زیرایمیج‌ها همواره پیش از ایمیج اصلی ساخته می‌شوند.
.PP
هنگامی که ایمیج‌ها تعریف شوند، \f[B]mkosi\f[R] ابتدا پیکربندی ایمیج اصلی
(پیکربندی خارج از دایرکتوری \f[B]mkosi.images/\f[R]) و سپس پیکربندی مختص هر ایمیج را می‌خواند.
.PP
چندین تنظیم \(lqmultiversal\(rq بر درخت ابزارهای پیش‌فرض و ایمیج اصلی اعمال
می‌شوند و نمی‌توان آن‌ها را جداگانه در خارج از ایمیج اصلی پیکربندی کرد:
.IP \(bu 2
\f[B]RepositoryKeyCheck=\f[R]
.IP \(bu 2
\f[B]RepositoryKeyFetch=\f[R]
.IP \(bu 2
\f[B]SourceDateEpoch=\f[R]
.IP \(bu 2
\f[B]WorkspaceDirectory=\f[R]
.IP \(bu 2
\f[B]PackageCacheDirectory=\f[R]
.IP \(bu 2
\f[B]BuildSources=\f[R]
.IP \(bu 2
\f[B]BuildSourcesEphemeral=\f[R]
.IP \(bu 2
\f[B]ProxyClientCertificate=\f[R]
.IP \(bu 2
\f[B]ProxyClientKey=\f[R]
.IP \(bu 2
\f[B]ProxyExclude=\f[R]
.IP \(bu 2
\f[B]ProxyPeerCertificate=\f[R]
.IP \(bu 2
\f[B]ProxyUrl=\f[R]
.IP \(bu 2
\f[B]MakeScriptsExecutable=\f[R]
.PP
چندین تنظیم \(lquniversal\(rq بر ایمیج اصلی و تمامی زیرایمیج‌های آن اعمال
می‌شوند و نمی‌توان آن‌ها را جداگانه در زیرایمیج‌ها پیکربندی کرد.
تنظیمات زیر همگانی هستند و در زیرایمیج‌ها قابل پیکربندی نمی‌باشند:
.IP \(bu 2
\f[B]Architecture=\f[R]
.IP \(bu 2
\f[B]BuildDirectory=\f[R]
.IP \(bu 2
\f[B]CacheDirectory=\f[R]
.IP \(bu 2
\f[B]Distribution=\f[R]
.IP \(bu 2
\f[B]ExtraSearchPaths=\f[R]
.IP \(bu 2
\f[B]LocalMirror=\f[R]
.IP \(bu 2
\f[B]Mirror=\f[R]
.IP \(bu 2
\f[B]OutputDirectory=\f[R]
.IP \(bu 2
\f[B]OutputMode=\f[R]
.IP \(bu 2
\f[B]PackageDirectories=\f[R]
.IP \(bu 2
\f[B]Release=\f[R]
.IP \(bu 2
\f[B]RepartOffline=\f[R]
.IP \(bu 2
\f[B]Repositories=\f[R]
.IP \(bu 2
\f[B]SandboxTrees=\f[R]
.IP \(bu 2
\f[B]ToolsTree=\f[R]
.IP \(bu 2
\f[B]ToolsTreeCertificates=\f[R]
.IP \(bu 2
\f[B]UseSubvolumes=\f[R]
.IP \(bu 2
\f[B]SecureBootCertificate=\f[R]
.IP \(bu 2
\f[B]SecureBootCertificateSource=\f[R]
.IP \(bu 2
\f[B]SecureBootKey=\f[R]
.IP \(bu 2
\f[B]SecureBootKeySource=\f[R]
.IP \(bu 2
\f[B]VerityCertificate=\f[R]
.IP \(bu 2
\f[B]VerityCertificateSource=\f[R]
.IP \(bu 2
\f[B]VerityKey=\f[R]
.IP \(bu 2
\f[B]VerityKeySource=\f[R]
.IP \(bu 2
\f[B]VolatilePackageDirectories=\f[R]
.IP \(bu 2
\f[B]WithNetwork=\f[R]
.IP \(bu 2
\f[B]WithTests\f[R]
.PP
همچنین تنظیماتی وجود دارند که به زیرایمیج‌ها منتقل می‌شوند اما می‌توان آن‌ها را
بازنویسی کرد.
برای این تنظیمات، مقادیری که صراحتاً در زیرایمیج پیکربندی شده‌اند نسبت به مقادیر
پیکربندی‌شده در خط فرمان یا در پیکربندی ایمیج اصلی اولویت خواهند داشت.
در حال حاضر تنظیمات زیر به زیرایمیج‌ها منتقل می‌شوند اما امکان بازنویسی آن‌ها وجود دارد:
.IP \(bu 2
\f[B]Incremental=\f[R]
.IP \(bu 2
\f[B]CacheOnly=\f[R]
.IP \(bu 2
\f[B]Profiles=\f[R]
.IP \(bu 2
\f[B]ImageId=\f[R]
.IP \(bu 2
\f[B]ImageVersion=\f[R]
.IP \(bu 2
\f[B]SectorSize=\f[R]
.IP \(bu 2
\f[B]CacheKey=\f[R]
.IP \(bu 2
\f[B]BuildKey=\f[R]
.IP \(bu 2
\f[B]CompressLevel=\f[R]
.IP \(bu 2
\f[B]SignExpectedPcrKey=\f[R]
.IP \(bu 2
\f[B]SignExpectedPcrKeySource=\f[R]
.IP \(bu 2
\f[B]SignExpectedPcrCertificate=\f[R]
.IP \(bu 2
\f[B]SignExpectedPcrCertificateSource=\f[R]
.PP
علاوه بر این، تنظیمات متعددی وجود دارند که تنها در ایمیج اصلی قابل پیکربندی هستند
اما به زیرایمیج‌ها منتقل نمی‌شوند:
.IP \(bu 2
\f[B]MinimumVersion=\f[R]
.IP \(bu 2
\f[B]PassEnvironment=\f[R]
.IP \(bu 2
\f[B]ToolsTreeDistribution=\f[R]
.IP \(bu 2
\f[B]ToolsTreeRelease=\f[R]
.IP \(bu 2
\f[B]ToolsTreeProfiles=\f[R]
.IP \(bu 2
\f[B]ToolsTreeMirror=\f[R]
.IP \(bu 2
\f[B]ToolsTreeSnapshot=\f[R]
.IP \(bu 2
\f[B]ToolsTreeRepositories=\f[R]
.IP \(bu 2
\f[B]ToolsTreeSandboxTrees=\f[R]
.IP \(bu 2
\f[B]ToolsTreePackages=\f[R]
.IP \(bu 2
\f[B]ToolsTreePackageDirectories=\f[R]
.IP \(bu 2
\f[B]History=\f[R]
.IP \(bu 2
تمامی تنظیمات موجود در بخش \f[B][Runtime]\f[R]
.PP
ایمیج‌ها می‌توانند به خروجی‌های ایمیج‌هایی که به آن‌ها وابسته هستند ارجاع دهند.
به‌ویژه برای گزینه‌های زیر، \f[B]mkosi\f[R] تنها درست پیش از ساخت ایمیج بررسی می‌کند
که آیا ورودی‌ها وجود دارند یا خیر:
.IP \(bu 2
\f[B]BaseTrees=\f[R]
.IP \(bu 2
\f[B]ExtraTrees=\f[R]
.IP \(bu 2
\f[B]Initrds=\f[R]
.PP
برای ارجاع به خروجی‌های وابستگی‌های یک ایمیج، کافی است هر یک از این گزینه‌ها را
با مسیر نسبی به خروجی مورد نظر در دایرکتوری خروجیِ آن وابستگی پیکربندی کنید.
یا از مشخصه‌گر \f[B]%O\f[R] برای ارجاع به دایرکتوری خروجی استفاده نمایید.
.PP
یک مثال مناسب در مورد نحوه ساخت چندین ایمیج را می‌توان در مخزن \c
.UR https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images
systemd
.UE \c
\ یافت..SH "متغیرهای محیطی (ENVIRONMENT VARIABLES)"
.IP \(bu 2
\f[B]$MKOSI_LESS\f[R] گزینه‌های \f[B]less\f[R] را هنگامی که توسط \f[B]mkosi\f[R] برای صفحه‌بندی خروجی فراخوانی می‌شود بازنویسی می‌کند.
.IP \(bu 2
\f[B]$MKOSI_DNF\f[R] می‌تواند برای لغو و جایگزینی فایل اجراییِ مورد استفاده به عنوان \f[B]dnf\f[R] به کار رود.
این متغیر به‌ویژه برای انتخاب میان \f[B]dnf\f[R] و \f[B]dnf5\f[R] مفید است.
توجه داشته باشید که این متغیر تنها زمانی اعمال می‌شود که هیچ درخت ابزاری (tools tree) در حال استفاده نباشد؛
در صورت فعال بودن یک درخت ابزار، فایل اجرایی dnf به‌طور خودکار از درون درخت ابزار شناسایی می‌شود.
.IP \(bu 2
\f[B]$MKOSI_DNF_DISABLE_PLUGINS\f[R] می‌تواند برای غیرفعال کردن افزونه‌های dnf استفاده شود.
این مقدار به گزینهٔ \f[B]\-\-disableplugin=\f[R] در dnf ارسال می‌شود.
.IP \(bu 2
\f[B]$MKOSI_DNF_ENABLE_PLUGINS\f[R] می‌تواند برای فعال کردن افزونه‌های dnf استفاده شود.
این مقدار به گزینهٔ \f[B]\-\-enableplugin=\f[R] در dnf ارسال می‌شود.
.IP \(bu 2
\f[B]$EPEL_MIRROR\f[R] می‌تواند برای بازنویسی مکان پیش‌فرض مخزن آینه‌ای (mirror) مورد استفاده برای مخازن epel در هنگام استفاده از \f[B]Mirror=\f[R] به کار رود.
به‌طور پیش‌فرض، \f[B]mkosi\f[R] مخازن epel را در زیردایرکتوری \f[B]fedora\f[R] از دایرکتوری والد آینهٔ مشخص‌شده در \f[B]Mirror=\f[R] جستجو می‌کند.
برای مثال، اگر آینه روی \f[B]https://mirror.net/centos\-stream\f[R] تنظیم شده باشد، \f[B]mkosi\f[R] مخازن epel را در \f[B]https://mirror.net/fedora/epel\f[R] جستجو خواهد کرد.
.IP \(bu 2
\f[B]SYSEXT_SCOPE\f[R] و \f[B]CONFEXT_SCOPE\f[R] می‌توانند برای جایگزینی مقدار پیش‌فرض فایل \f[B]extension\-release\f[R] مربوطه در هنگام ساخت یک sysext یا confext استفاده شوند.
به‌طور پیش‌فرض این مقدار روی \f[B]initrd system portable\f[R] تنظیم شده است.
.SH "مثال‌ها (EXAMPLES)"
ساخت و اجرای یک ایمیج خام \f[I]GPT\f[R] با فایل‌سیستم \f[I]ext4\f[R]، با نام \f[B]image.raw\f[R]:
.IP
.EX
# mkosi \-p systemd \-i boot
.EE
.PP
ساخت و اجرای یک ایمیج بوت‌پذیر \f[I]GPT\f[R]، با نام \f[B]foobar.raw\f[R]:
.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] در یک دایرکتوری ساده:
.IP
.EX
# mkosi \-\-distribution fedora \-\-format directory boot
.EE
.PP
ساخت یک ایمیج فشرده‌شده به نام \f[B]image.raw.xz\f[R] به همراه بستهٔ نصب‌شدهٔ SSH و افزودن فایل مجموع مقابله‌ای (checksum):
.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] بدون هیچ پارامتری، یک ایمیج سیستم‌عامل حاوی نسخهٔ ساخته‌شده از وضعیت فعلی پروژه تولید کند:
.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 != \(dqmkosi\(dq ]; then
    exec mkosi\-chroot \(dq$CHROOT_SCRIPT\(dq \(dq$\(at\(dq
fi

cd $SRCDIR
\&./autogen.sh
\&./configure \-\-prefix=/usr
make \-j \(ganproc\(ga
make install
EOF
$ chmod +x mkosi.build
# mkosi \-i boot
# systemd\-nspawn \-bi image.raw
.EE
.SS روش‌های مختلف بوت با \f[B]vm\f[R]
ساده‌ترین راه برای بوت یک ماشین مجازی این است که یک ایمیج با مؤلفه‌های مورد نیاز ساخته و اجازه دهید \f[B]mkosi\f[R] برنامهٔ \f[B]qemu\f[R] را با تمام گزینه‌های مناسب فراخوانی کند:
.IP
.EX
$ mkosi \-d fedora \-p systemd\-udev,systemd\-boot,kernel\-core build
$ mkosi \-d fedora vm
\&...
fedora login: root (automatic login)
[root\(atfedora \(ti]#
.EE
.PP
حالت پیش‌فرض، بوت تنها با یک کنسول متنی است.
در این حالت، پیام‌های بارگذار بوت (boot loader)، هسته، systemd و سپس اعلان ورود \f[B]getty\f[R] و شل همگی از همان ترمینال مشترک استفاده می‌کنند.
امکان جابجایی بین کنسول و مانیتور \f[B]qemu\f[R] با فشردن کلیدهای \f[B]Ctrl\-a c\f[R] وجود دارد.
مانیتور \f[B]qemu\f[R] ممکن است برای نمونه جهت ارسال کلیدهای خاص یا خاموش کردن سریع ماشین به کار رود.
همچنین می‌توان ماشین را با استفاده از \f[B]Ctrl\-a x\f[R] خاموش کرد.
.PP
برای بوت به همراه یک پنجرهٔ گرافیکی، گزینهٔ \f[B]\-\-console=gui\f[R] را اضافه کنید:
.IP
.EX
$ mkosi \-d fedora \-\-console=gui qemu
.EE
.PP
یک هسته را می‌توان مستقیماً با دستور \f[B]mkosi vm \-kernel ... \-initrd ... \-append \(aq...\(aq\f[R] بوت کرد.
این کار کمی سریع‌تر است زیرا از بارگذار بوت استفاده نمی‌شود، و همچنین آزمایش هسته‌ها و خطوط فرمان هستهٔ مختلف را ساده‌تر می‌کند.
توجه داشته باشید که علی‌رغم نام آن، گزینهٔ \f[B]\-append\f[R] در \f[B]qemu\f[R] خط فرمان پیش‌فرض تعبیه‌شده در هسته و هر مشخصهٔ قبلیِ \f[B]\-append\f[R] را جایگزین می‌کند.
.PP
فایل UKI نیز در دایرکتوری خروجی کپی می‌شود و می‌تواند مستقیماً بوت شود:
.IP
.EX
$ mkosi vm \-\- \-kernel mkosi.output/fedora\(ti38/image.efi
.EE
.PP
هنگام بوت با استفاده از یک هستهٔ خارجی، نیازی به وجود خود هسته \f[I]درون\f[R] ایمیج نیست، اما همچنان تمایل داریم ماژول‌های هسته نصب شده باشند.
.PP
همچنین انجام یک \f[I]بوت مستقیم هسته (direct kernel boot)\f[R] به درون یک بارگذار بوت نیز امکان‌پذیر است، که از این واقعیت که \f[B]systemd\-boot\f[R](7) یک باینری معتبر UEFI است بهره می‌برد:
.IP
.EX
$ mkosi vm \-\- \-kernel /usr/lib/systemd/boot/efi/systemd\-bootx64.efi
.EE
.PP
در این سناریو، هسته از ESP درون ایمیج توسط \f[B]systemd\-boot\f[R] بارگذاری می‌شود..SH "نیازمندی‌ها (REQUIREMENTS)"
.IP \(bu 2
ابزار mkosi به یک هسته لینوکس نیاز دارد که \f[B]mount_setattr()\f[R] را ارائه دهد؛ این قابلیت در نگارش 5.12 معرفی شد.
.IP \(bu 2
ابزار mkosi در حال حاضر برای ساخت ایمیج‌های دیسک قابل بوت، به systemd 254 یا جدیدتر نیاز دارد.
.IP \(bu 2
ابزار mkosi نیازمند نصب وابستگی‌های گوناگونی است.
اگر از یک درخت ابزار (tools tree) استفاده شود (برای اطلاعات بیشتر به مستندات \f[B]ToolsTree=\f[R] مراجعه کنید)،
آنگاه mkosi همه وابستگی‌های خود (به‌جز python و یک مدیر بسته) را خودش بارگیری خواهد کرد.
در غیر این صورت، لازم است وابستگی‌های مورد نیاز را روی سیستم خود نصب کنید.
می‌توانید دستور \f[B]mkosi dependencies\f[R] را برای دریافت فهرستی از وابستگی‌های پایه‌ای لازم اجرا کنید.
برای استفاده معمول از mkosi، اکیداً توصیه می‌کنیم از یک درخت ابزار استفاده کنید.
.IP \(bu 2
در Debian/Kali/Ubuntu ممکن است بسته به اینکه قصد ساخت چه نوع ایمیج توزیعی را دارید،
نصب صریح بسته‌های \f[B]ubuntu\-keyring\f[R]، \f[B]ubuntu\-archive\-keyring\f[R]،
\f[B]kali\-archive\-keyring\f[R] و/یا \f[B]debian\-archive\-keyring\f[R] علاوه بر \f[B]apt\f[R] لازم باشد.
.IP \(bu 2
حداقل نسخه مورد نیاز Python، نگارش 3.9 است.
.SS "فضاهای نام کاربری غیرممتاز (Unprivileged User Namespaces)"
ابزار mkosi برای ایجاد و فعالیت درون فضاهای نام لینوکس (Linux namespaces) به اختیارات نامحدود نیاز دارد.
برخی توزیع‌ها ایجاد یا قابلیت‌های درون فضاهای نام کاربری را محدود می‌کنند که منجر به شکست عملکرد mkosi می‌شود.
.PP
برای اطلاعات درباره Ubuntu، که این محدودیت‌ها را با استفاده از AppArmor اعمال می‌کند، ببینید:
https://ubuntu.com/blog/ubuntu\-23\-10\-restricted\-unprivileged\-user\-namespaces
برای فعال‌سازی فضاهای نام کاربری غیرممتاز در اوبونتو، دستورهای زیر را اجرا کنید:
.IP
.EX
sudo sysctl \-w kernel.apparmor_restrict_unprivileged_unconfined=0
sudo sysctl \-w kernel.apparmor_restrict_unprivileged_userns=0
.EE
.PP
جهت پایدار ماندن این تنظیمات sysctl در راه‌اندازی‌های مجدد سیستم، فایل
\f[B]/etc/sysctl.d/unprivileged\-userns.conf\f[R] را با محتوای زیر ایجاد کنید:
.IP
.EX
kernel.apparmor_restrict_unprivileged_unconfined=0
kernel.apparmor_restrict_unprivileged_userns=0
.EE
.PP
برای سیستم‌های دیگر، متغیرهای sysctl مربوط به
\f[B]kernel.unprivileged_userns_clone\f[R] یا
\f[B]user.max.user_namespace\f[R] را بررسی کنید.
.SH "پرسش‌های متداول (FREQUENTLY ASKED QUESTIONS)"
.IP \(bu 2
چرا \f[B]mkosi vm\f[R] به همراه KVM در Debian/Kali/Ubuntu کار نمی‌کند؟
.RS 2
.PP
در حالی که توزیع‌های دیگر با دسترسی به \f[B]/dev/kvm\f[R] مشکلی ندارند، در Debian/Kali/Ubuntu این دسترسی فقط برای کاربران عضو گروه \f[B]kvm\f[R] مجاز است.
از آنجا که \f[B]mkosi\f[R] هنگام اجرا به صورت غیرممتاز یک فضای نام کاربری را unshare می‌کند، حتی اگر کاربر فراخواننده در گروه kvm بوده باشد، با این عمل دسترسی به گروه \f[B]kvm\f[R] را از دست می‌دهد و در زمان راه‌اندازی \f[B]qemu\f[R] دیگر دسترسی به \f[B]/dev/kvm\f[R] وجود نخواهد داشت.
به عنوان یک راهکار موقت، می‌توانید مجوزهای گره‌های دستگاه را به \f[B]0666\f[R] تغییر دهید که برای کارکرد بدون امتیاز KVM کافی است.
برای ماندگاری این تنظیمات پس از راه‌اندازی مجدد، فایل
\f[B]/usr/lib/tmpfiles.d/static\-nodes\-permissions.conf\f[R] را به
\f[B]/etc/tmpfiles.d/static\-nodes\-permissions.conf\f[R] رونوشت کرده و حالت (mode) دسترسی \f[B]/dev/kvm\f[R] را از \f[B]0660\f[R] به \f[B]0666\f[R] تغییر دهید.
.RE
.IP \(bu 2
چگونه یک کاربر عادی به یک ایمیج بیفزایم؟
.RS 2
.PP
می‌توانید از قطعه‌کد زیر در یک اسکریپت پس از نصب استفاده کنید:
.IP
.EX
useradd \-\-create\-home \-\-user\-group $USER \-\-password \(dq$(openssl passwd \-stdin \-6 <$USER_PASSWORD_FILE)\(dq
.EE
.PP
توجه داشته باشید که از نگارش systemd v256 به بعد، در صورت فعال بودن، اگر هیچ کاربر عادی وجود نداشته باشد، سرویس \f[B]systemd\-homed\-firstboot.service\f[R] در نخستین بوت برای ایجاد یک کاربر عادی اعلان درخواست خواهد داد.
.RE
.IP \(bu 2
چرا هنگام ساخت ایمیج‌ها با خطای تغییر مالکیت (chown) فایل‌ها مواجه می‌شوم؟
.RS 2
.PP
هنگامی که به عنوان ریشه (root) اجرا نمی‌کنید، کاربر شما مجاز به تغییر مالکیت فایل‌ها به مالکان دلخواه نیست.
توزیع‌های مختلف هنوز فایل‌هایی را در بسته‌های خود عرضه می‌کنند که متعلق به کاربر root نیستند.
هنگامی که به عنوان root اجرا نمی‌کنید، mkosi هنگام فراخوانی مدیران بسته، کاربر جاری را به root نگاشت می‌کند؛ به این معنی که تغییر مالکیت به root موفق خواهد بود اما تغییر مالکیت به هر کاربر یا گروه دیگر با شکست مواجه می‌شود.
.PP
توجه داشته باشید که فراخوانی‌های chown تنها هنگام اجرای مدیران بسته نادیده گرفته می‌شوند، نه هنگام اجرای اسکریپت‌ها.
اگر این کار ضروری باشد (برای مثال در یک اسکریپت ساخت)، می‌توانید متغیر \f[B]MKOSI_CHROOT_SUPPRESS_CHOWN\f[R] را روی یک مقدار درست
(\f[B]1\f[R]، \f[B]yes\f[R]، \f[B]true\f[R]) تنظیم کنید تا فراخوانی‌های chown در \f[B]mkosi\-chroot\f[R] و اسکریپت‌های \f[B].chroot\f[R] نادیده گرفته شوند.
.PP
اگر این رفتار باعث اختلال در اجرای برنامه‌ها در ایمیج شما می‌شود، می‌توانید اجرای \f[B]mkosi\f[R] با دسترسی ریشه (root) را مد نظر قرار دهید که از این مشکل جلوگیری می‌کند.
روش دیگر، چنانچه اجرای \f[B]mkosi\f[R] به عنوان root مطلوب نباشد، این است که با این فرض که نگاشت‌های UID/GID در \f[B]/etc/subuid\f[R] و \f[B]/etc/subgid\f[R] به درستی پیکربندی شده‌اند، از دستور
\f[B]unshare \-\-map\-auto \-\-map\-current\-user \-\-setuid 0 \-\-setgid 0\f[R] برای تبدیل شدن به root در یک فضای نام کاربری با بیش از یک کاربر استفاده کنید.
توجه داشته باشید که اجرای mkosi به صورت root یا با \f[B]unshare\f[R] به این معناست که تمام فایل‌های خروجی تولید شده توسط \f[B]mkosi\f[R] دیگر در مالکیت کاربر جاری شما نخواهند بود.
.PP
توجه کنید برای سرویس‌های systemd که نیاز به پوشه‌هایی در \f[B]/var\f[R] با مالکیت کاربر و گروه سرویس دارند، یک راه جایگزین به جای قرار دادن این دایرکتوری‌ها در بسته‌ها یا ساخت آن‌ها از طریق systemd\-tmpfiles، استفاده از \f[B]StateDirectory=\f[R]، \f[B]CacheDirectory=\f[R] یا \f[B]LogsDirectory=\f[R] در فایل سرویس است که به systemd دستور می‌دهد هنگام نخستین شروع سرویس، دایرکتوری را ایجاد کند.
.PP
همچنین، می‌توان از دستورالعمل‌های \f[B]z\f[R] یا \f[B]Z\f[R] برای \f[B]systemd\-tmpfiles\f[R] استفاده کرد تا مالکیت دایرکتوری‌ها و فایل‌های مختلف هنگام نخستین بوت سیستم به کاربر مالک آن‌ها تغییر یابد.
.RE
.IP \(bu 2
چرا \f[B]portablectl inspect <image>\f[R]/\f[B]systemd\-dissect <image>\f[R] اعلام می‌کنند که سرویس قابل‌حمل (portable service) من یک سرویس قابل‌حمل نیست؟
.RS 2
.PP
دستورهای \f[B]systemd\-dissect\f[R] و \f[B]portablectl inspect\f[R] به دنبال \f[B]PORTABLE_PREFIXES=\f[R] در \f[B]os\-release\f[R] می‌گردند و اگر این کلید وجود نداشته باشد، قادر به شناسایی آن به عنوان یک سرویس قابل‌حمل نخواهند بود و در مورد \f[B]systemd\-dissect\f[R] علامت ✗ را زیر \f[I]Use as\f[R] و برای \f[B]portablectl\f[R] عبارت \f[B]n/a\f[R] را زیر \f[I]Portable Service\f[R] نمایش می‌دهند.
.PP
از آنجا که هیچ مقدار پیش‌فرض مناسبی برای این کلید وجود ندارد و ایمیج‌های سرویس قابل‌حملِ تولید شده حتی در صورت تنظیم نبودن این کلید همچنان به درستی متصل (attach) می‌شوند، \f[B]mkosi\f[R] مقداری برای آن تنظیم نمی‌کند.
.PP
می‌توانید \f[B]PORTABLE_PREFIXES=\f[R] را با قرار دادن \f[B]Environment=PORTABLE_PREFIXES=XXX\f[R] در پیکربندی mkosi خود تنظیم کنید.
.RE.SH "مراجع (REFERENCES)"
.IP \(bu 2
\c
.UR https://github.com/systemd/mkosi
مخزن اصلی git ابزار mkosi در GitHub
.UE \c
.IP \(bu 2
\c
.UR https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html
mkosi \(em ابزاری برای تولید ایمیج‌های سیستم‌عامل
.UE \c
\ پست وبلاگی معرفی نوشته‌ی Lennart Poettering
.IP \(bu 2
\c
.UR https://lwn.net/Articles/726655
ابزار تولید سیستم‌عامل mkosi
.UE \c
\ مقاله‌ای در LWN
.SH "همچنین ببینید (SEE ALSO)"
\f[B]systemd\-nspawn\f[R](1), \f[B]systemd\-repart\f[R](8),
\f[B]dnf\f[R](8)