mkosi(1) General Commands Manual mkosi(1)

mkosi - ساخت ایمیج‌های سفارشی سیستم‌عامل

mkosi [options...] init

mkosi [options...] summary

mkosi [options...] cat-config

mkosi [options...] build [-- command line...]

mkosi [options...] shell [-- command line...]

mkosi [options...] boot [-- nspawn settings...]

mkosi [options...] vm [-- vmm parameters...]

mkosi [options...] ssh [-- command line...]

mkosi [options...] journalctl [-- command line...]

mkosi [options...] coredumpctl [-- command line...]

mkosi [options...] sysupdate [-- sysupdate settings...]

mkosi [options...] box [-- command line...]

mkosi [options...] dependencies [-- options...]

mkosi [options...] clean

mkosi [options...] serve

mkosi [options...] burn <device>

mkosi [options...] bump

mkosi [options...] genkey

mkosi [options...] documentation [manual]

mkosi [options...] completion [shell]

mkosi [options...] latest-snapshot

mkosi [options...] help

دستور mkosi ابزاری برای ساخت آسان ایمیج‌های سفارشی سیستم‌عامل است. این ابزار یک پوشش پیشرفته بر روی dnf، apt، pacman و zypper است که می‌تواند ایمیج‌های دیسک را همراه با امکانات و قابلیت‌های متعددی ایجاد کند.

زیردستورهای خط فرمان زیر پشتیبانی می‌شوند:

مقداردهی اولیه mkosi. این یک عملیات یک‌باره است که فایل‌های پیکربندی مختلف مورد نیاز برای یک تجربه بهینه را راه‌اندازی می‌کند. در حال حاضر این دستور تنها یک دراپ‌این tmpfiles.d برای دایرکتوری حافظه موقت (cache) بسته‌های mkosi راه‌اندازی می‌کند تا اطمینان حاصل شود که فایل‌های قدیمی و بدون استفاده به‌طور خودکار پاک‌سازی می‌شوند.
نمایش خلاصه‌ای خوانا برای انسان از تمامی گزینه‌های استفاده‌شده برای ساخت ایمیج‌ها. این دستور خط فرمان و فایل‌های پیکربندی را تجزیه می‌کند، اما تنها تنظیمات اعمال‌شده را چاپ کرده و عملاً چیزی را نمی‌سازد یا اجرا نمی‌کند.
نمایش نام‌ها و محتوای تمام فایل‌های پیکربندی بارگذاری‌شده در خروجی. دستور mkosi مجموعه‌ای از فایل‌ها را از مکان‌های مختلف بارگذاری می‌کند و این دستور بررسی این‌که چه چیزی در کجا پیکربندی شده است را آسان‌تر می‌سازد.
ساخت ایمیج بر اساس تنظیمات ارائه‌شده در خط فرمان و فایل‌های پیکربندی. در صورتی که هیچ زیردستوری مشخص نشود، این دستور حالت پیش‌فرض است. در صورت تعریف شدن اسکریپت‌های ساخت، می‌توان آرگومان‌هایی را به آن‌ها ارسال کرد. برای ارسال گزینه‌ها به اسکریپت‌های ساخت، آن‌ها را با -- از گزینه‌های معمولی mkosi جدا کنید.
این دستور در صورتی که ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس systemd-nspawn را برای اجرای یک پوسته تعاملی درون ایمیج فراخوانی می‌کند. این کار نیازی به راه‌اندازی (بوت) سیستم ندارد و مانند نسخه‌ای پیشرفته‌تر از chroot عمل می‌کند. می‌توان یک خط فرمان اختیاری را پس از زیردستور shell مشخص کرد تا به جای پوسته درون کانتینر اجرا شود. برای ارسال گزینه‌های اضافی به nspawn، آن‌ها را با -- از گزینه‌های معمولی جدا کنید.
جهت استفاده از ایمیج‌های directory با shell، گزینه ForeignUIDRange= باید هنگام ساخت ایمیج فعال شده باشد.
مشابه shell، اما به جای اجرای یک پوسته، systemd را با استفاده از systemd-nspawn درون ایمیج بوت می‌کند. می‌توان آرگومان‌های اضافی را پس از زیردستور boot مشخص کرد که به عنوان خط فرمان کرنل (kernel command line) به سیستم init درون ایمیج ارسال می‌شوند. برای ارسال گزینه‌های اضافی به nspawn، آن‌ها را با -- از گزینه‌های معمولی جدا کنید.
جهت استفاده از ایمیج‌های directory با boot، گزینه ForeignUIDRange= باید هنگام ساخت ایمیج فعال شده باشد. برای استفاده از ایمیج‌های disk با boot، به systemd-nsresourced و systemd-mountfsd نسخه v260 یا جدیدتر روی سیستم میزبان نیاز است.
مشابه boot، اما از ناظر ماشین مجازی پیکربندی‌شده (به‌طور پیش‌فرض qemu) برای بوت کردن ایمیج استفاده می‌کند؛ یعنی به جای مجازی‌سازی کانتینری، از مجازی‌سازی ماشین مجازی استفاده می‌شود. نحوه تفسیر آرگومان‌های خط فرمان اضافی به ناظر ماشین مجازی پیکربندی‌شده بستگی دارد. برای اطلاعات بیشتر VirtualMachineMonitor= را ببینید. برای ارسال گزینه‌های اضافی به ناظر ماشین مجازی پیکربندی‌شده، آن‌ها را با -- از گزینه‌های معمولی جدا کنید.
جهت استفاده از ایمیج‌های directory با vm، گزینه ForeignUIDRange= باید هنگام ساخت ایمیج فعال شده باشد.
هنگامی که ایمیج با گزینه Ssh=always ساخته شده باشد یا سرویس sshd-vsock مربوط به systemd در ماشین مجازی در حال اجرا باشد (systemd نسخه v256 به بالا)، این دستور از طریق SSH به یک ماشین مجازی بوت‌شده متصل می‌شود. اطمینان حاصل کنید که mkosi ssh را با همان پیکربندی mkosi build اجرا می‌کنید تا اطلاعات لازم برای اتصال به ماشین مجازی در حال اجرا از طریق SSH در دسترس باشد. به‌ویژه، کلید خصوصی SSH از تنظیم SshKey= برای اتصال به ماشین مجازی استفاده می‌شود. از mkosi genkey برای تولید خودکار کلید و گواهی‌نامه‌ای که توسط mkosi شناسایی می‌شود استفاده کنید. هر آرگومانی که بعد از زیردستور ssh مشخص شود، به عنوان آرگومان به فراخوانی ssh ارسال می‌شود. برای ارسال گزینه‌های اضافی، آن‌ها را با -- از گزینه‌های معمولی جدا کنید. برای اتصال به یک کانتینر، از machinectl login یا machinectl shell استفاده کنید.
گزینه Machine= می‌تواند برای اختصاص یک نام میزبان (hostname) سفارشی به ماشین در زمان بوت استفاده شود که بعداً می‌توان از آن برای ssh به ایمیج استفاده کرد (به‌عنوان مثال، mkosi --machine=mymachine vm و به دنبال آن mkosi --machine=mymachine ssh).
از journalctl برای بررسی ژورنال درون ایمیج استفاده می‌کند. تمام آرگومان‌هایی که بعد از زیردستور journalctl مشخص شده و با -- از گزینه‌های معمولی جدا شوند، به فراخوانی journalctl پیوست می‌گردند.
از coredumpctl برای جستجوی coredumpها درون ایمیج استفاده می‌کند. تمام آرگومان‌هایی که بعد از زیردستور coredumpctl مشخص شده و با -- از گزینه‌های معمولی جدا شوند، به فراخوانی coredumpctl پیوست می‌گردند.
دستور systemd-sysupdate را با تنظیم گزینه --transfer-source= بر روی دایرکتوری خروجی و گزینه --definitions= بر روی دایرکتوری پیکربندی‌شده با SysupdateDirectory= فراخوانی می‌کند. تمام آرگومان‌هایی که بعد از زیردستور sysupdate مشخص شده و با -- از گزینه‌های معمولی جدا شوند، مستقیماً به systemd-sysupdate ارسال می‌شوند.
اجرای دستورات دلخواه درون همان محیطی که برای اجرای سایر زیردستورها مانند boot، shell، vm و غیره استفاده می‌شود. این بدان معناست که در صورت استفاده از درخت ابزارها (tools tree)، دایرکتوری /usr با /usr درخت ابزارها جایگزین خواهد شد، در حالی که همه چیز دیگر در جای خود باقی می‌ماند. اگر دستوری مشخص نشود، $SHELL یا در صورت تنظیم نبودن آن، bash اجرا خواهد شد. برای ارسال گزینه‌های اضافی به دستور داده‌شده، آن‌ها را با -- از گزینه‌های معمولی جدا کنید..TP clean مصنوعات ساخت تولیدشده در یک ساخت قبلی را حذف می‌کند. اگر با -f ترکیب شود، ایمیج‌های حافظهٔ پنهان ساخت افزایشی و درخت ابزارها (tools tree) را نیز حذف می‌کند. اگر -f دو بار مشخص شود، هرگونه حافظهٔ پنهان بسته‌ها را نیز حذف می‌کند.
این دستور اگر ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس دایرکتوری خروجی (یعنی معمولاً mkosi.output/، پایین‌تر را ببینید) را از طریق یک سرور HTTP توکار کوچک که روی درگاه ۸۰۸۱ شنود می‌کند، ارائه می‌دهد. برای بازسازی بدون قید و شرط ایمیج پیش از ارائهٔ آن، این دستور را با -f ترکیب کنید. این دستور برای آزمایش دریافت تحت شبکهٔ ایمیج‌های سیستم‌عامل، به عنوان مثال از طریق machinectl pull-raw ... و machinectl pull-tar ... مفید است.
این دستور اگر ایمیج هنوز ساخته نشده باشد آن را می‌سازد و سپس آن را در دستگاه بلوکی مشخص‌شده می‌نویسد. محتویات پارتیشن‌ها همان‌گونه که هستند نوشته می‌شوند، اما جدول پارتیشن GPT اصلاح می‌شود تا با اندازهٔ دیسک و سکتورهای رسانهٔ مشخص‌شده مطابقت یابد.
نسخهٔ ایمیج را از mkosi.version افزایش می‌دهد و رشتهٔ نسخهٔ حاصل را در mkosi.version می‌نویسد. این دستور برای پیاده‌سازی یک طرح نسخه‌بندی ساده مفید است: هر بار که این فعل فراخوانی می‌شود، نسخه در آمادگی برای ساخت بعدی افزایش می‌یابد. توجه داشته باشید که می‌توان از --auto-bump/-B برای افزایش خودکار نسخه به عنوان بخشی از فرایند ساخت استفاده کرد. در این حالت، نسخهٔ جدید تنها در صورتی در mkosi.version نوشته می‌شود که ساخت موفقیت‌آمیز باشد.
اگر mkosi.bump وجود داشته باشد، به جای استفاده از منطق درونی mkosi، برای تولید نسخهٔ جدید فراخوانی می‌شود.
یک جفت کلید SecureBoot برای استفاده با گزینه‌های SecureBootKey=/--secure-boot-key= و SecureBootCertificate=/--secure-boot-certificate= تولید می‌کند.
مستندات mkosi را نمایش می‌دهد. اگر هیچ آرگومانی داده نشود، صفحهٔ man مربوط به mkosi نمایش داده می‌شود، اما آرگومان‌های mkosi، mkosi-initrd، initrd، mkosi-sandbox، sandbox، mkosi.news و news نیز پشتیبانی می‌شوند و به ترتیب صفحات man مربوط به mkosi، mkosi-initrd، mkosi-sandbox و فایل NEWS مربوط به mkosi را نمایش می‌دهند.
به‌طور پیش‌فرض این فعل چندین روش را برای خروجی دادن مستندات امتحان می‌کند، اما می‌توان با گزینهٔ --doc-format گزینهٔ خاصی را انتخاب کرد. به بسته‌بندهای توزیع‌ها توصیه می‌شود در صورت موجود نبودن فایل mkosi.1، آن را به دایرکتوری mkosi/resources بستهٔ Python اضافه کنند و همچنین آن را در مسیر جستجوی مناسب برای صفحات man نصب نمایند. صفحهٔ man را می‌توان از فایل Markdown در mkosi/resources/man/mkosi.1.md تولید کرد، مثلاً از طریق pandoc -t man -s -o mkosi.1 mkosi.1.md.
تکمیل خودکار شل را برای پوسته‌ای که به عنوان آرگومان داده شده تولید کرده و در stdout چاپ می‌کند. آرگومان‌های bash، fish و zsh پشتیبانی می‌شوند.
فهرست بسته‌های مورد نیاز mkosi را برای ساخت و بوت کردن ایمیج‌ها خروجی می‌دهد.
این فهرست را می‌توان مستقیماً با لوله‌کشی (pipe) به یک مدیر بسته هدایت کرد تا بسته‌ها را نصب کند. برای مثال، اگر سیستم میزبان از مدیر بستهٔ dnf استفاده می‌کند، بسته‌ها را می‌توان به روش زیر نصب کرد: 
mkosi dependencies | xargs -d '\n' dnf install
به‌طور پیش‌فرض، تنها وابستگی‌های مورد نیاز برای ساخت ایمیج‌ها با mkosi نمایش داده می‌شوند. پروفایل‌های درخت ابزارهای اضافی را می‌توان فعال کرد تا بسته‌های متعلق به آن پروفایل‌ها را نیز خروجی دهد. به عنوان مثال، اجرای mkosi dependencies -- --profile runtime علاوه بر بسته‌های معمولی، بسته‌های موجود در پروفایل runtime را نیز نمایش می‌دهد. برای مشاهدهٔ فهرستی از پروفایل‌های موجود، مستندات مربوط به ToolsTreeProfiles= را ببینید.
جدیدترین اسنپ‌شات موجود در آینهٔ (mirror) پیکربندی‌شده را نمایش می‌دهد.
این فعل برای افزایش خودکار اسنپ‌شات‌ها در فواصل زمانی منظم مفید است. توجه داشته باشید که این فعل فقط جدیدترین اسنپ‌شات را در خروجی می‌آورد. اطمینان از نوشته شدن اسنپ‌شات در فایل پیکربندی مورد نظر بر عهدهٔ فراخواننده است.
این فعل معادل سوئیچ --help است که در ادامه توضیح داده شده است: توضیح مختصری از نحوهٔ استفاده را نشان می‌دهد.

این تنظیمات را نمی‌توان در فایل‌های پیکربندی تعیین کرد.

هنگام ساخت یک ایمیج، در صورتی که فایل خروجی از قبل وجود داشته باشد، آن را جایگزین می‌کند. به‌طور پیش‌فرض هنگام ساخت یک ایمیج، اگر یک مصنوع خروجی از قبل موجود باشد، mkosi از انجام عملیات خودداری خواهد کرد. این گزینه را یک بار مشخص کنید تا تمام مصنوعات ساخت یک اجرای قبلی، پیش از ساخت مجدد ایمیج حذف شوند. اگر ساخت‌های افزایشی فعال باشند، مشخص کردن دو بارهٔ این گزینه تضمین می‌کند که فایل‌های حافظهٔ پنهان میانی نیز قبل از شروع ساخت مجدد حذف شوند. اگر از حافظهٔ پنهان بسته استفاده می‌شود (همچنین بخش فایل‌ها (FILES) را در زیر ببینید)، مشخص کردن سه بارهٔ این گزینه تضمین می‌کند که حافظهٔ پنهان بسته‌ها نیز قبل از آغاز ساخت مجدد حذف شود. برای عملیات clean این گزینه تأثیر اندکی متفاوت دارد: به‌طور پیش‌فرض این فعل فقط مصنوعات ساخت اجرای قبلی را حذف می‌کند، هنگامی که یک بار مشخص شود فایل‌های حافظهٔ پنهان افزایشی و درخت ابزارها نیز حذف می‌شوند، و هنگامی که دو بار مشخص شود حافظهٔ پنهان بسته‌ها نیز حذف خواهد شد.
مسیری به یک دایرکتوری را می‌گیرد. mkosi پیش از انجام هر کاری به این دایرکتوری تغییر مکان می‌دهد. توجه داشته باشید که فایل‌های پیکربندی مختلف در این دایرکتوری جستجو می‌شوند، بنابراین استفاده از این گزینه روشی مؤثر برای ساخت پروژه‌ای است که در یک دایرکتوری خاص قرار دارد. پیش‌فرض آن دایرکتوری کاری فعلی است. اگر یک رشتهٔ خالی مشخص شود، تمام پیکربندی‌های موجود در دایرکتوری کاری فعلی نادیده گرفته می‌شوند.
خروجی اشکال‌زدایی اضافی را فعال می‌کند.
هنگامی که اجرای یک دستور در ایمیج با شکست مواجه می‌شود، mkosi یک پوستهٔ تعاملی را درون ایمیج اجرا می‌کند تا امکان اشکال‌زدایی بیشتر فراهم شود.
در صورت تعیین، دایرکتوری فضای کاری (workspace) حذف نخواهد شد و مکان آن هنگام خروج mkosi در لاگ ثبت می‌شود.
mkosi-sandbox را با strace اجرا می‌کند.
مدت‌زمان هر مرحله از ساخت را ثبت می‌کند.
نسخهٔ بسته را نشان می‌دهد.
اطلاعات مختصری دربارهٔ نحوهٔ استفاده را نمایش می‌دهد.
نام مشترک (Common Name) که هنگام تولید کلیدها از طریق دستور genkey در mkosi استفاده می‌شود. پیش‌فرض mkosi of %u است، که در آن %u به نام کاربری کاربری که mkosi را فراخوانی می‌کند گسترش می‌یابد.
تعداد روزهایی که کلیدها هنگام تولید از طریق دستور genkey در mkosi باید معتبر بمانند. پیش‌فرض دو سال (۷۳۰ روز) است.
در صورت مشخص شدن، نسخه افزایش می‌یابد و در صورت موفقیت‌آمیز بودن ساخت، نسخه به روشی معادل فعل bump در mkosi.version نوشته می‌شود. این گزینه برای مدیریت نسخهٔ خطی و ساده مفید است: هر ساخت در یک توالی، شماره نسخه‌ای یک واحد بالاتر از نسخهٔ قبلی خواهد داشت.
اگر mkosi.bump وجود داشته باشد، به جای استفاده از منطق درونی mkosi، برای تولید نسخهٔ جدید فراخوانی می‌شود.
قالبی که مستندات در آن نمایش داده می‌شوند. از مقادیر markdown، man، pandoc، system و auto پشتیبانی می‌کند. در صورت استفاده از markdown، مستندات در قالب اصلی Markdown نشان داده می‌شوند. man در صورت موجود بودن، مستندات را در قالب صفحهٔ man نمایش می‌دهد. pandoc در صورت در دسترس بودن، قالب صفحهٔ man را بلافاصله تولید خواهد کرد. system صفحهٔ man سراسری سیستم را برای mkosi نشان می‌دهد، که بسته به نحوهٔ نصب mkosi، ممکن است با نسخه‌ای که استفاده می‌کنید مطابقت داشته باشد یا خیر. auto که حالت پیش‌فرض است، تمام روش‌ها را به ترتیب man، pandoc، markdown و system امتحان خواهد کرد.
خروجی خلاصه را به صورت JSON-SEQ نمایش می‌دهد..TP --wipe-build-dir, -w پاک کردن دایرکتوری ساخت پیش از ساخت ایمیج، در صورتی که دایرکتوری‌ای پیکربندی شده باشد.
اجرای دوبارهٔ اسکریپت‌های ساخت. نیازمند این است که گزینهٔ Incremental= فعال باشد و ایمیج پیش‌تر یک‌بار ساخته شده باشد. اگر History= فعال باشد، تاریخچهٔ ساخت قبلی مجدداً استفاده خواهد شد و تاریخچهٔ جدیدی نوشته نمی‌شود.

قالب‌های خروجی زیر پشتیبانی می‌شوند:

  • ایمیج دیسک خام GPT، ایجادشده با استفاده از systemd-repart (disk)
  • دایرکتوری ساده، شامل درخت سیستم‌عامل (directory)
  • بایگانی Tar (tar)
  • بایگانی CPIO (cpio)
  • ایمیج یکپارچهٔ هسته یا Unified Kernel Image (UKI)
  • ... و موارد بسیار بیشتر. مستندات Format= در ادامه را ببینید.

قالب خروجی می‌تواند روی none نیز تنظیم شود تا mkosi هیچ ایمیجی تولید نکند. این حالت در صورتی مفید است که تنها بخواهید از ایمیج برای تولید یک خروجی دیگر در اسکریپت‌های ساخت استفاده کنید (برای نمونه، ساخت یک RPM).

هنگامی که یک ایمیج دیسک GPT ایجاد می‌شود، می‌توان فایل‌های تعریف پارتیشن repart را در mkosi.repart/ قرار داد تا ایمیج دیسک تولیدشده را پیکربندی کرد.

اکیداً توصیه می‌شود mkosi را روی یک سیستم‌فایل اجرا کنید که از reflinkها پشتیبانی می‌کند (مانند XFS و btrfs) و همهٔ دایرکتوری‌های مرتبط را روی همان سیستم‌فایل نگه دارید. این کار به mkosi اجازه می‌دهد با استفاده از reflinkها برای انجام کپی از طریق عملیات‌های رونوشت هنگام نوشتن (copy-on-write)، ایمیج‌ها را بسیار سریع ایجاد کند.

تنظیمات زیر را می‌توان از طریق فایل‌های پیکربندی (نحو با SomeSetting=value) و در خط فرمان (نحو با --some-setting=value) مشخص کرد. برای برخی از پارامترهای خط فرمان، میانبر تک‌حرفی نیز مجاز است. در فایل‌های پیکربندی، تنظیم باید در بخش مناسب قرار گیرد، از این رو تنظیمات زیر بر اساس بخش گروه‌بندی شده‌اند.

پیکربندی به ترتیب زیر تجزیه می‌شود:

  • آرگومان‌های خط فرمان تجزیه می‌شوند.
  • mkosi.local.conf و mkosi.local/ در صورت وجود تجزیه می‌شوند (به همین ترتیب). این فایل و دایرکتوری باید در .gitignore (یا معادل آن) قرار گیرند و برای پیکربندی محلی در نظر گرفته شده‌اند.
  • اگر گزینه‌ای دارای یک مسیر پیش‌فرض متناظر باشد، در صورت وجود آن مسیر پیش‌فرض، تجزیه می‌شود.
  • mkosi.conf در صورت وجود در دایرکتوریِ پیکربندی‌شده با --directory= تجزیه می‌شود؛ یا اگر از --directory= استفاده نشود، در دایرکتوری کاری جاری. اگر دایرکتوری مشخص‌شده شامل mkosi.conf یا mkosi.tools.conf نباشد و mkosi/mkosi.conf یا mkosi/mkosi.tools.conf وجود داشته باشد، پیکربندی به‌جای آن از زیردایرکتوری mkosi/ در دایرکتوری مشخص‌شده تجزیه خواهد شد.
  • mkosi.conf.d/ در صورت وجود، در همان دایرکتوریِ mkosi.conf تجزیه می‌شود. هر دایرکتوری و هر فایل با پسوند .conf در mkosi.conf.d/ تجزیه می‌شود. هر دایرکتوری درون mkosi.conf.d به گونه‌ای تجزیه می‌شود که گویی یک دایرکتوری سطح بالای عادی است، به‌جز mkosi.images/، mkosi.tools.conf و mkosi.initrd.conf که تنها در دایرکتوری سطح بالا دریافت می‌شوند.
  • اگر هر پروفایلی پیکربندی شده باشد، پیکربندی آن‌ها از دایرکتوری mkosi.profiles/ تجزیه می‌شود.
  • زیرایمیج‌ها در صورت وجود، از دایرکتوری mkosi.images/ تجزیه می‌شوند.

توجه داشته باشید که تنظیمات پیکربندی‌شده از طریق خط فرمان همواره تنظیمات مشخص‌شده از طریق فایل‌های پیکربندی را بازنویسی می‌کنند. اگر یک تنظیم، بیش از یک‌بار از طریق فایل‌های پیکربندی تعیین شده باشد، انتساب‌های بعدی انتساب‌های قبلی را بازنویسی می‌کنند، مگر برای تنظیماتی که مجموعه‌ای از مقادیر را می‌پذیرند. همچنین، تنظیمات خوانده‌شده از mkosi.local.conf یا mkosi.local/، تنظیمات فایل‌های پیکربندی که بعداً تجزیه می‌شوند را بازنویسی خواهند کرد، اما تنظیمات مشخص‌شده در خط فرمان را بازنویسی نمی‌کنند.

برای تنظیماتی که یک مقدار واحد را می‌پذیرند، انتساب خالی (SomeSetting= یا --some-setting=) می‌تواند برای بازنویسی تنظیم قبلی و بازنشانی آن به مقدار پیش‌فرض استفاده شود.

تنظیماتی که مجموعه‌ای از مقادیر را می‌پذیرند، با افزودن مقادیر جدید به انتهای مقادیر قبلاً پیکربندی‌شده، ادغام می‌شوند. انتساب یک رشتهٔ خالی به چنین تنظیمی، همهٔ مقادیر قبلاً انتساب‌داده‌شده را حذف کرده و هر مقدار پیش‌فرض پیکربندی‌شده را نیز بازنویسی می‌کند. مقادیر مشخص‌شده در خط فرمان، پس از همهٔ مقادیر فایل‌های پیکربندی به انتها افزوده می‌شوند.

برای گنجاندن شرطیِ فایل‌های پیکربندی، بخش [Match] می‌تواند استفاده شود. یک بخش [Match] از شرایط منفرد تشکیل شده است. شرایط می‌توانند از یک نویسهٔ پایپ (|) پس از علامت مساوی (...=|...) استفاده کنند که باعث می‌شود آن شرط به یک شرط راه‌انداز تبدیل شود. فایل پیکربندی در صورتی گنجانده می‌شود که «و»ی منطقی (AND) تمام شرایط غیرراه‌انداز و «یا»ی منطقی (OR) تمام شرایط راه‌انداز برقرار باشد. برای نقیض کردن نتیجهٔ یک شرط، قبل از آرگومان یک علامت تعجب قرار دهید. اگر آرگومانی با نویسهٔ پایپ و علامت تعجب شروع شود، ابتدا باید پایپ و سپس علامت تعجب درج گردد.

توجه داشته باشید که شرایط [Match] با مقادیر جاریِ تنظیمات خاص مقایسه می‌شوند و تغییرات اعمال‌شده بر آن تنظیم در فایل‌های پیکربندی که هنوز تجزیه نشده‌اند را در نظر نمی‌گیرند (تنظیمات مشخص‌شده در خط فرمان لحاظ می‌شوند). همچنین دقت کنید که تطبیق دادن با یک تنظیم و سپس تغییر مقدار آن در یک فایل پیکربندی دیگر ممکن است به نتایج غیرمنتظره منجر شود.

بخش [Match] یک فایل mkosi.conf درون یک دایرکتوری به کل آن دایرکتوری اعمال می‌شود. اگر شرایط برآورده نشوند، کل دایرکتوری نادیده گرفته می‌شود. بخش‌های [Match] فایل‌های موجود در mkosi.conf.d/ و mkosi.local.conf تنها برای خود آن فایل اعمال می‌شوند.

اگر چندین بخش [Match] در یک فایل پیکربندی یکسان وجود داشته باشد، تک‌تک آن‌ها باید برقرار باشند تا فایل پیکربندی گنجانده شود. به‌ویژه، شرایط راه‌انداز تنها برای بخش [Match] جاری اعمال شده و بین بخش‌های مختلف [Match] بازنشانی می‌شوند. به عنوان مثال، قطعه‌کد زیر تنها در صورتی مطابقت دارد که قالب خروجی یکی از disk یا directory بوده و معماری نیز یکی از x86-64 یا arm64 باشد:

[Match]
Format=|disk
Format=|directory
[Match]
Architecture=|x86-64
Architecture=|arm64

بخش [TriggerMatch] می‌تواند برای نشان دادن مطابقت‌های راه‌انداز استفاده شود. این بخش‌ها مشابه شرایط راه‌انداز در واحدهای systemd هستند، با این تفاوت که به جای یک شرط منفرد، به کل بخش تطبیق اعمال می‌شوند. به عنوان مثال، قطعه‌کد زیر در صورتی تطبیق می‌یابد که توزیع debian و انتشار bookworm باشد، یا توزیع ubuntu و انتشار noble باشد:

[TriggerMatch]
Distribution=debian
Release=bookworm
[TriggerMatch]
Distribution=ubuntu
Release=noble

معناشناسی شرایط در بخش‌های [TriggerMatch] مشابه با [Match] است؛ بدین معنی که تمام شرایط عادی با یک «و»ی منطقی و تمام شرایط راه‌انداز با یک «یا»ی منطقی به یکدیگر متصل می‌شوند. هنگام ترکیب بخش‌های [Match] و [TriggerMatch]، تطبیق در صورتی حاصل می‌شود که تمام بخش‌های [Match] برقرار باشند و دست‌کم یکی از بخش‌های [TriggerMatch] تطبیق یابد. نبود بخش‌های تطبیق، برابر با درست (true) در نظر گرفته می‌شود. از نظر منطقی این یعنی:

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

همچنین پشتیبانی از بخش‌های [Assert] و [TriggerAssert] وجود دارد که رفتاری مشابه بخش‌های تطبیق دارند، با این تفاوت که در صورت برقرار نبودن بخش‌های assert، تجزیهٔ پیکربندی شکست خواهد خورد؛ یعنی تمام بخش‌های [Assert] در یک فایل و همچنین دست‌کم یک بخش [TriggertAssert] باید برآورده شوند، وگرنه تجزیهٔ پیکربندی با شکست مواجه می‌شود.

گزینه‌های خط فرمان که هیچ آرگومانی نمی‌پذیرند، در نسخهٔ بلند خود بدون = نشان داده شده‌اند. در فایل‌های پیکربندی، این گزینه‌ها باید با یک آرگومان بولی مشخص شوند: یا 1، yes، یا true برای فعال‌سازی، یا 0، no، false برای غیرفعال‌سازی..SS بخش [Distribution]

توزیعی که باید در ایمیج نصب شود. یکی از این آرگومان‌ها را می‌پذیرد: fedora، debian، kali، ubuntu، arch، opensuse، mageia، centos، rhel، rhel-ubi، openmandriva، rocky، alma، azure یا custom. در صورت مشخص نشدن، به توزیع میزبان پیش‌فرض می‌شود، یا به custom اگر توزیع میزبان توزیع پشتیبانی‌شده‌ای نباشد.
انتشار توزیع برای نصب در ایمیج. نحو دقیق آرگومانی که این گزینه می‌پذیرد به توزیع مورد استفاده بستگی دارد، و یا یک رشته عددی است (در مورد Fedora Linux، CentOS و غیره، برای مثال 29)، یا یک نام نسخهٔ توزیع (در مورد Debian، Kali، Ubuntu و غیره، برای مثال artful). پیش‌فرض آن نسخهٔ جدیدی از توزیع انتخاب‌شده است، یا نسخهٔ توزیع در حال اجرا روی میزبان در صورتی که با توزیع پیکربندی‌شده مطابقت داشته باشد.
معماری‌ای که ایمیج برای آن ساخته می‌شود. معماری‌هایی که عملاً پشتیبانی می‌شوند به توزیع مورد استفاده و اینکه آیا ایمیج قابل بوت درخواست شده است یا خیر بستگی دارد. هنگام ساخت برای یک معماری بیگانه (foreign architecture)، لازم است یک شبیه‌ساز حالت کاربر (user mode emulator) را نیز برای آن معماری نصب و ثبت کنید.
به‌ازای هر ایمیج ساخته‌شده می‌توان یکی از معماری‌های زیر را مشخص کرد: alpha، arc، arm، arm64، ia64، loongarch64، mips64-le، mips-le، parisc، ppc، ppc64، ppc64-le، riscv32، riscv64، s390، s390x، tilegx، x86، x86-64.
مخزن آینه‌ای (mirror) مورد استفاده برای بارگیری بسته‌های توزیع. یک URL آینه را به عنوان آرگومان می‌پذیرد. در صورت ارائه نشدن، آینهٔ پیش‌فرض برای آن توزیع استفاده می‌شود.
آینه‌های پیش‌فرض برای هر توزیع به شرح زیر است (مگر اینکه مشخص شده باشد، همان آینه برای همه معماری‌ها استفاده می‌شود):
x86-64 aarch64
debian http://deb.debian.org
arch https://fastly.mirror.pkgbuild.com http://mirror.archlinuxarm.org
opensuse http://download.opensuse.org
kali http://http.kali.org/kali
ubuntu http://archive.ubuntu.com http://ports.ubuntu.com
centos https://mirrors.centos.org
rocky https://mirrors.rockylinux.org
alma https://mirrors.almalinux.org
fedora https://mirrors.fedoraproject.org
rhel-ubi https://cdn-ubi.redhat.com
mageia https://www.mageia.org
openmandriva http://mirrors.openmandriva.org
azure https://packages.microsoft.com
بارگیری بسته‌ها از تصویر لحظه‌ای (snapshot) مشخص‌شده به‌جای بارگیری جدیدترین بسته‌های توزیع از آینهٔ داده‌شده. یک شناسهٔ snapshot را می‌پذیرد (قالب شناسهٔ snapshot در هر توزیع متفاوت است)، از فعل latest-snapshot برای یافتن آخرین snapshot موجود استفاده کنید.
اگر این تنظیم پیکربندی شده باشد و Mirror= صریحاً تعیین نشده باشد، آینه‌های پیش‌فرض متفاوتی استفاده می‌شوند:
x86-64 aarch64
debian https://snapshot.debian.org
arch https://archive.archlinux.org http://mirror.archlinuxarm.org
opensuse http://download.opensuse.org
ubuntu http://archive.ubuntu.com http://ports.ubuntu.com
centos https://composes.stream.centos.org
fedora https://kojipkgs.fedoraproject.org
برای هر توزیعی که در بالا فهرست نشده باشد، snapshotها پشتیبانی نمی‌شوند. توجه داشته باشید که این تنظیم بر درخت ابزارهای پیش‌فرض اعمال نمی‌شود؛ برای آن از ToolsTreeSnapshot= استفاده کنید. LocalMirror=, --local-mirror= این آینه به عنوان یک آینه محلی، ساده و مستقیم استفاده خواهد شد، به جای آنکه به عنوان پیشوندی برای مجموعه کامل مخازنی که معمولاً توسط توزیع‌ها پشتیبانی می‌شوند به کار رود. برای ساخت‌های کاملاً آفلاین با یک مخزن واحد مفید است. در توزیع‌های مبتنی بر deb، rpm و pacman پشتیبانی می‌شود. این گزینه مقدار --mirror= را بازنویسی می‌کند، اما فقط برای ساخت محلی mkosi؛ این گزینه درون تصویر نهایی پیکربندی نخواهد شد و به جای آن، --mirror= (یا مخزن پیش‌فرض) در تصویر نهایی پیکربندی می‌شود.
بررسی‌های امضا/کلید را هنگام استفاده از مخازن کنترل می‌کند؛ به صورت پیش‌فرض فعال است. برای غیرفعال کردن بررسی‌ها در صورت ترکیب با --local-mirror= و استفادهٔ صرف از یک مخزن از سیستم‌فایل محلی مفید است.
کنترل می‌کند که آیا mkosi کلیدهای GPG توزیع را از راه دور دریافت کند یا خیر. به صورت پیش‌فرض در Ubuntu هنگام عدم استفاده از درخت ابزارها یا هنگام استفاده از درخت‌های ابزار Ubuntu برای ساخت Arch Linux یا توزیع‌های مبتنی بر RPM فعال است. به صورت پیش‌فرض در تمام توزیع‌های دیگر غیرفعال است. هنگام غیرفعال بودن، کلیدهای GPG توزیع برای توزیع مقصد باید به صورت محلی در سیستم میزبان در کنار مدیر بستهٔ آن توزیع نصب شده باشند.
این تنظیم تنها برای توزیع‌هایی پیاده‌سازی شده است که از dnf، pacman یا zypper به عنوان مدیر بستهٔ خود استفاده می‌کنند. برای سایر توزیع‌ها، کلیدهای GPG توزیع صرف‌نظر از مقدار این تنظیم همیشه به صورت محلی جستجو می‌شوند. برای دردسترس قرار دادن کلیدهای GPG توزیع‌ها بدون فعال‌سازی این تنظیم، بستهٔ مربوطه باید روی سیستم میزبان نصب شود. این بسته معمولاً یکی از بسته‌های archlinux-keyring، debian-keyring، kali-archive-keyring، ubuntu-keyring یا distribution-gpg-keys (برای توزیع‌های مبتنی بر RPM) است.
مخازن بسته‌ای را که به صورت پیش‌فرض غیرفعال هستند، فعال می‌کند. از این گزینه می‌توان برای فعال‌سازی مخازن EPEL برای CentOS یا مؤلفه‌های مختلف مخازن Debian/Kali/Ubuntu استفاده کرد.

نوع قالب تصویر برای تولید. یکی از مقادیر directory (برای تولید مستقیم تصویر سیستم‌عامل در یک پوشهٔ محلی)، tar (مشابه، اما یک بایگانی tarball از تصویر سیستم‌عامل تولید می‌شود)، cpio (مشابه، اما یک بایگانی cpio تولید می‌شود)، disk (یک تصویر سیستم‌عامل از نوع دستگاه بلوکی با جدول افراز GPT)، uki (یک تصویر هستهٔ یکپارچه با تصویر سیستم‌عامل در بخش PE با نام .initrd)، esp (یک تصویر دیسک تنها با یک افراز ESP، بوت‌لودر و به صورت اختیاری یک UKI)، oci (یک دایرکتوری سازگار با مشخصات تصویر OCI)، sysext، confext، portable، addon یا none (تصویر سیستم‌عامل صرفاً به عنوان یک تصویر ساخت برای تولید یک دست‌ساختهٔ دیگر در نظر گرفته شده است).
اگر از قالب خروجی disk استفاده شود، تصویر دیسک با استفاده از systemd-repart تولید می‌شود. فایل‌های تعریف افراز repart که باید استفاده شوند را می‌توان با استفاده از تنظیم RepartDirectories= یا از طریق mkosi.repart/ پیکربندی کرد. هنگامی که افرازهای verity با استفاده از تنظیم Verity= در systemd-repart پیکربندی شده باشند، mkosi به‌طور خودکار مقدار roothash افراز هش verity را از خروجی JSON برنامهٔ systemd-repart تجزیه کرده و آن را در خط فرمان هستهٔ هر تصویر هستهٔ یکپارچهٔ ساخته‌شده توسط mkosi قرار می‌دهد. اگر از قالب خروجی none استفاده شود، خروجی‌های ساخت قبلی حذف نمی‌شوند، اما اسکریپت‌های پاک‌سازی (نگاه کنید به CleanScripts=) همچنان اجرا می‌شوند. این امکان اجرای مجدد یک اسکریپت ساخت (نگاه کنید به BuildScripts=) را بدون حذف نتایج ساخت قبلی فراهم می‌کند.
نوع یا انواع قالب مانیفست برای تولید. یک فهرست جداشده با کاما شامل json (قالب خروجی استاندارد JSON که بسته‌های نصب‌شده را توصیف می‌کند) و changelog (یک قالب متنی خوانا برای انسان که برای مقایسهٔ تفاوت‌ها طراحی شده است). به صورت پیش‌فرض هیچ مانیفستی تولید نمی‌شود.
نام مورد استفاده برای فایل یا پوشهٔ تصویر خروجی تولیدشده. پیش‌فرض آن image است یا اگر ImageId= مشخص شده باشد، به عنوان نام خروجی پیش‌فرض استفاده می‌شود که به صورت اختیاری با نسخهٔ تعیین‌شده توسط ImageVersion= پسوند می‌گیرد، یا اگر تصویر خاصی از mkosi.images ساخته شود، نام تصویر بر ImageId ارجحیت دارد. توجه داشته باشید که این گزینه اجازهٔ پیکربندی دایرکتوری خروجی را نمی‌دهد؛ برای این منظور از OutputDirectory= استفاده کنید.
توجه داشته باشید که این گزینه فقط پیشوند خروجی را مشخص می‌کند؛ بسته به قالب خروجی خاص، فشرده‌سازی و نسخهٔ تصویر مورد استفاده، نام کامل خروجی ممکن است image_7.8.raw.xz باشد.
استفاده از پسوند مشخص‌شده برای فایل خروجی. به صورت پیش‌فرض به پسوند مناسب بر پایهٔ قالب خروجی تنظیم می‌شود. فقط شامل پسوند فایل است، نه پسوندهای فشرده‌سازی که در صورت فعال بودن فشرده‌سازی به این پسوند الصاق می‌شوند.
در صورت تنظیم، اندازهٔ تصویر دیسک خروجی به اندازهٔ داده‌شده تغییر می‌یابد. یک اندازه بر حسب بایت می‌گیرد. از پسوندهای K، M و G می‌توان برای تعیین اندازه به کیلوبایت، مگابایت و گیگابایت استفاده کرد. این تنظیم فقط اندازهٔ دیسک را افزایش می‌دهد و محدود به تصاویر کامل دیسک است و برای هیچ قالب خروجی دیگری کاربرد ندارد.
پیکربندی فشرده‌سازی برای تصویر یا بایگانی حاصل. آرگومان می‌تواند یک مقدار بولی (boolean) یا یک الگوریتم فشرده‌سازی (xz، zstd) باشد. فشرده‌سازی zstd به صورت پیش‌فرض استفاده می‌شود، به جز در CentOS و مشتقات آن تا نسخهٔ 8 که پیش‌فرض آن‌ها xz است، و تصاویر OCI که پیش‌فرض آن‌ها gzip است. توجه داشته باشید که هنگام اعمال بر انواع تصاویر دستگاه‌های بلوکی، فشرده‌سازی بدان معناست که تصویر نمی‌تواند مستقیماً راه‌اندازی شود، بلکه ابتدا باید از حالت فشرده خارج گردد. این همچنین بدان معناست که در صورت استفاده از این گزینه، افعال shell، boot و vm در دسترس نخواهند بود. برای مقادیر tar، cpio، uki، esp، oci و addon به طور ضمنی فعال است.
سطح فشرده‌سازی مورد استفاده را پیکربندی می‌کند. یک عدد صحیح می‌پذیرد. مقادیر ممکن به نوع فشرده‌سازی مورد استفاده بستگی دارد.
مسیر پوشه‌ای که تمام دست‌ساخته‌های تولیدشده در آن قرار می‌گیرند. اگر این گزینه مشخص نشده باشد و دایرکتوری mkosi.output/ در پوشهٔ محلی وجود داشته باشد، به‌طور خودکار برای این منظور استفاده می‌شود.
حالت دسترسی سیستم‌فایل که هنگام ایجاد فایل تصویر خروجی استفاده می‌شود. یک حالت دسترسی در نمادگذاری هشت‌هشتی (octal) می‌گیرد. در صورت تنظیم نشدن، از مقادیر پیش‌فرض فعلی سیستم استفاده می‌کند.
نسخهٔ تصویر را پیکربندی می‌کند. این گزینه هر رشته‌ای را می‌پذیرد، اما توصیه می‌شود مجموعه‌ای از مؤلفه‌های جداشده با نقطه مشخص شود. نسخه همچنین می‌تواند با خواندن یک فایل mkosi.version (که در این صورت می‌توان آن را به راحتی از طریق فعل bump یا گزینهٔ --auto-bump مدیریت کرد) یا در صورت قابل اجرا بودن با خواندن stdout پیکربندی شود (بخش Scripts در زیر را ببینید). هنگام مشخص شدن، نسخهٔ تصویر در نام پیش‌فرض فایل خروجی گنجانده می‌شود، یعنی به جای image.raw نام پیش‌فرض برای نسخهٔ 0.1 تصویر، image_0.1.raw خواهد بود و موارد مشابه. این نسخه همچنین از طریق $IMAGE_VERSION به تمام اسکریپت‌های ساخت فراخوانی‌شده ارسال می‌شود (که ممکن است برای اعمال آن در /usr/lib/os-release یا موارد مشابه، به ویژه در فیلد IMAGE_VERSION= آن، مفید باشد).
شناسهٔ تصویر را پیکربندی می‌کند. یک رشته آزاد را می‌پذیرد که برای شناسایی تصویر به کار خواهد رفت. در صورت تنظیم، نام فایل خروجی پیش‌فرض بر اساس آن نام‌گذاری می‌شود (احتمالاً همراه با پسوند نسخه). این شناسه همچنین از طریق $IMAGE_ID به تمام اسکریپت‌های ساخت فراخوانی‌شده ارسال می‌شود. شناسه تصویر به‌طور خودکار به /usr/lib/os-release افزوده می‌شود. هنگام استفاده از Format=oci، شناسه تصویر همچنین به عنوان حاشیه‌نویسی org.opencontainers.image.ref.name روی توصیف‌گر نمایهٔ OCI تنظیم می‌شود.
برچسب‌های پیکربندی OCI را روی تصاویر تولیدشده با Format=oci تنظیم می‌کند. فهرستی از انتساب‌های KEY=VALUE جداشده با فاصله را می‌گیرد. این برچسب‌ها در حباب پیکربندی تصویر OCI ذخیره می‌شوند و از طریق podman inspect یا docker inspect قابل مشاهده هستند (معادل LABEL در یک Containerfile). این گزینه می‌تواند بیش از یک بار مشخص شود که در این حالت تمام برچسب‌های فهرست‌شده تنظیم خواهند شد. اگر یک برچسب دو بار تنظیم شود، تنظیم پسین مقدار پیشین را بازنویسی می‌کند.
حاشیه‌نویسی‌های مانیفست OCI را روی تصاویر تولیدشده با Format=oci تنظیم می‌کند. فهرستی از انتساب‌های KEY=VALUE جداشده با فاصله را می‌پذیرد. این حاشیه‌نویسی‌ها در مانیفست تصویر OCI ذخیره می‌شوند. ابزار mkosi به‌طور خودکار io.systemd.mkosi.version و در صورت تنظیم ImageVersion=، مقدار org.opencontainers.image.version را تنظیم می‌کند. حاشیه‌نویسی‌های مشخص‌شده توسط کاربر این مقادیر پیش‌فرض را بازنویسی می‌کنند. این گزینه می‌تواند بیش از یک بار مشخص شود که در این حالت تمام حاشیه‌نویسی‌های فهرست‌شده اعمال خواهند شد.
انواع دست‌ساخته‌هایی که باید از تصویر نهایی تفکیک شوند. یک فهرست جداشده با کاما شامل uki، kernel، initrd، os-release، pcrs، partitions، roothash، kernel-modules-initrd، repart-definitions و tar. هنگام ساخت یک تصویر قابل بوت، kernel و initrd متناظر با دست‌ساختهٔ آن‌ها در تصویر (یا در UKI) هستند، در حالی که uki کل UKI را به بیرون کپی می‌کند. اگر pcrs مشخص شود، یک فایل JSON حاوی خلاصه‌های از‌پیش‌محاسبه‌شدهٔ TPM2 مطابق با مشخصات UKI نوشته می‌شود که برای امضای آفلاین مفید است.
هنگام ساخت یک تصویر دیسک و در صورت تعیین partitions، گزینهٔ --split=yes به systemd-repart داده می‌شود تا فایل‌های افراز تفکیک‌شده را برای هر افراز پیکربندی‌شده بنویسد. برای اطلاعات بیشتر صفحهٔ راهنما (man page) را مطالعه کنید. این قابلیت در سناریوهای به‌روزرسانی A/B که در آن یک تصویر دیسک موجود باید با نسخهٔ جدیدی از یک افراز root یا /usr همراه با افراز Verity و هستهٔ یکپارچهٔ آن ارتقا یابد، مفید است. هنگامی که tar مشخص شود، rootfs علاوه بر این به عنوان یک بایگانی tar (فشرده‌شده طبق CompressOutput=) بایگانی می‌شود. هنگامی که roothash مشخص شده و یک تصویر دیسک dm-verity ساخته شود، مقدار dm-verity roothash به عنوان یک فایل مجزا نوشته می‌شود که برای امضای آفلاین مفید است. مقدار kernel-modules-initrd متناظر با initrd مجزای ماژول‌های هسته است که mkosi آن را به انتهای initrd اصلی الصاق می‌کند. این مورد اصولاً برای اشکال‌زدایی در نظر گرفته شده است زیرا بسیاری از ابزارهای بررسی initrd الصاق چند initrd به یکدیگر را به درستی پشتیبانی نمی‌کنند. هنگامی که repart-definitions مشخص شود، پوشه‌ای حاوی فایل‌های تعاریف repart استفاده‌شده در پوشه خروجی نوشته می‌شود. اگر چندین پوشه از طریق RepartDirectories= پیکربندی شده باشد، آن‌ها ادغام می‌شوند و در صورت وجود فایل‌هایی با نام‌های یکسان، پوشه‌های پسین بر پوشه‌های پیشین اولویت خواهند داشت. به صورت پیش‌فرض مقادیر uki، kernel و initrd تفکیک می‌شوند. RepartDirectories=, --repart-directory= مسیرهای دایرکتوری‌های حاوی فایل‌های تعریف پارتیشن systemd-repart که هنگام فراخوانی systemd-repart توسط mkosi در زمان ساخت ایمیج دیسک استفاده می‌شوند. اگر mkosi.repart/ در دایرکتوری محلی وجود داشته باشد، برای این منظور نیز استفاده خواهد شد. توجه داشته باشید که mkosi ابزار repart را با --root= تنظیم‌شده روی ریشهٔ ایمیج فراخوانی می‌کند، بنابراین هر مسیر مبدأ CopyFiles= در فایل‌های تعریف پارتیشن، نسبت به دایرکتوری ریشهٔ ایمیج در نظر گرفته خواهد شد.
بازنویسی اندازه سکتور پیش‌فرضی که systemd-repart هنگام ساخت ایمیج دیسک استفاده می‌کند.
هنگامی که همراه با BaseTrees= استفاده شود، خروجی تنها شامل تغییرات نسبت به درخت‌های پایه مشخص‌شده خواهد بود. هر درخت پایه به عنوان یک لایه زیرین (lower layer) در یک ساختار overlayfs متصل می‌شود و خروجی تبدیل به لایه بالایی (upper layer) می‌شود که در ابتدا خالی است. بنابراین فایل‌هایی که در مقایسه با درخت‌های پایه تغییری نکرده‌اند در خروجی نهایی حضور نخواهند داشت.
از این گزینه می‌توان برای ایجاد system extensions در systemd استفاده کرد.
یک UUID یا مقدار ویژهٔ random را به عنوان آرگومان می‌پذیرد. سید (seed) مورد استفاده توسط systemd-repart را هنگام ساخت ایمیج دیسک بازنویسی می‌کند. این مورد برای دستیابی به ساخت‌های بازتولیدپذیر (reproducible builds) مفید است، جایی که UUIDهای قطعی و سایر متاداده‌های پارتیشن باید در هر ساخت مشتق شوند. اگر به صراحت مشخص نشده باشد و فایل mkosi.seed در دایرکتوری محلی وجود داشته باشد، UUID مورد استفاده از آن خوانده می‌شود. در غیر این صورت، یک UUID تصادفی استفاده می‌شود.
مشخص می‌کند که آیا هنگام ساخت ایمیج دیسک، کاتالوگ بوت El Torito برای بوت کردن ESP اضافه شود یا خیر. یک مقدار بولی (boolean) یا auto می‌پذیرد. پیش‌فرض آن auto است. هنگامی که روی auto تنظیم شود، یک کاتالوگ بوت El Torito اضافه می‌شود مگر اینکه grub به عنوان بوت‌لودر BIOS نصب شده باشد (چرا که با آن ناسازگار است). نیازمند systemd-repart ≥ v261 است.
تنظیم شناسه سیستم (system identifier) در توصیف‌گر ISO 9660.
تنظیم شناسه حجم (volume identifier) در توصیف‌گر ISO 9660.
تنظیم شناسه ناشر (publisher identifier) در توصیف‌گر ISO 9660.
فهرستی از مسیرهای فایل‌های اجرایی جداشده با کاما را می‌پذیرد که به عنوان اسکریپت‌های پاک‌سازی (clean scripts) برای این ایمیج استفاده می‌شوند. الگوهای تطبیق مسیر (glob patterns) پشتیبانی می‌شوند و مسیرهای منطبق به ترتیب الفبایی مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.

بسته‌های توزیع مشخص‌شده (مانند RPM، deb و ...) را در ایمیج نصب می‌کند. فهرستی از مشخصات بسته‌ها که با کاما جدا شده‌اند را می‌پذیرد. این گزینه می‌تواند چندین بار استفاده شود که در این صورت فهرست بسته‌های مشخص‌شده با یکدیگر ترکیب می‌شوند. از BuildPackages= برای مشخص کردن بسته‌هایی استفاده کنید که فقط باید در یک overlay نصب شوند؛ این overlay زمانی متصل می‌شود که اسکریپت‌های آماده‌سازی با آرگومان build و همچنین هنگام اجرای اسکریپت‌های ساخت اجرا شوند.
انواع و نحوِ (syntax) مجاز برای مشخصات بسته، به نصاب بسته بستگی دارد (مانند dnf برای توزیع‌های مبتنی بر RPM یا apt برای توزیع‌های مبتنی بر deb)، اما می‌تواند شامل نام بسته‌ها، نام بسته‌ها به همراه نسخه و/یا معماری، الگوهای نام بسته (globs)، گروه‌های بسته و موارد ارائه‌شدهٔ مجازی (virtual provides)، از جمله مسیرهای فایل باشد. برای اطلاعات دربارهٔ نحوهٔ در دسترس قرار دادن بسته‌های محلی برای نصب با Packages=، گزینهٔ PackageDirectories= را ببینید. مثال: هنگام استفاده از توزیعی که از dnf بهره می‌برد، پیکربندی زیر بستهٔ meson (در آخرین نسخه)، نسخهٔ ۳۲ بیتی بستهٔ libfdisk-devel، تمام بسته‌های موجود با پیشوند git-، یک بستهٔ RPM متعلق به systemd از سیستم‌فایل محلی، یکی از بسته‌هایی که /usr/bin/ld را ارائه می‌دهد، بسته‌های موجود در گروه Development Tools و بسته‌ای که حاوی ماژول پایتون mypy است را نصب می‌کند. 
Packages=meson
         libfdisk-devel.i686
         git-*
         /usr/bin/ld
         @development-tools
         python3dist(mypy)
مشابه Packages= است، اما بسته‌ها را طوری پیکربندی می‌کند که فقط در یک overlay نصب شوند که در بالای ایمیج برای اسکریپت‌های آماده‌سازی (هنگام اجرا با آرگومان build) و اسکریپت‌های ساخت در دسترس قرار می‌گیرد. این گزینه باید برای فهرست کردن بسته‌های حاوی فایل‌های هدر، کامپایلرها، سیستم‌های ساخت، پیونددهنده‌ها (linkers) و سایر ابزارهای ساختی که اسکریپت‌های mkosi.build برای کار به آن‌ها نیاز دارند استفاده شود. توجه داشته باشید بسته‌هایی که در اینجا فهرست شده‌اند در ایمیج نهایی وجود نخواهند داشت.
مشابه Packages= است، اما بسته‌هایی که با این تنظیم پیکربندی می‌شوند در زمان فعال بودن Incremental= کَش نمی‌شوند و پس از اجرای اسکریپت‌های ساخت نصب می‌گردند.
به‌طور مشخص، از این تنظیم می‌توان برای نصب بسته‌هایی استفاده کرد که مکرراً تغییر می‌کنند یا توسط یک اسکریپت ساخت، ساخته می‌شوند.
دایرکتوری‌های حاوی بسته‌های اضافی که باید در طول فرایند ساخت در دسترس باشند را مشخص می‌کند. mkosi یک مخزن محلی شامل تمام بسته‌های موجود در این دایرکتوری‌ها ایجاد می‌کند و هنگام نصب بسته‌ها یا اجرای اسکریپت‌ها آن را در دسترس قرار می‌دهد. اگر دایرکتوری mkosi.packages/ در دایرکتوری محلی یافت شود، برای این منظور نیز استفاده خواهد شد.
مانند PackageDirectories= عمل می‌کند، با این تفاوت که در صورت فعال بودن Incremental=، هرگونه تغییر در بسته‌های این دایرکتوری‌ها باعث نامعتبر شدن ایمیج‌های کش‌شده نخواهد شد.
علاوه بر این، اسکریپت‌های ساخت می‌توانند با قرار دادن بسته‌های ساخته‌شده در $PACKAGEDIR، بسته‌های بیشتری به مخزن محلی اضافه کنند. بسته‌های قرار گرفته در $PACKAGEDIR بین تمام فرایندهای ساخت ایمیج به اشتراک گذاشته می‌شوند و بنابراین برای نصب در همهٔ ایمیج‌هایی که از VolatilePackages= استفاده می‌کنند در دسترس خواهند بود.
مشخص می‌کند که آیا وابستگی‌های توصیه‌شده (recommended) یا ضعیف (weak)، بسته به نحوهٔ نام‌گذاری آن‌ها توسط مدیر بسته مورد استفاده، نصب شوند یا خیر. به‌طور پیش‌فرض، بسته‌های توصیه‌شده نصب نمی‌شوند. این گزینه فقط برای مدیر بسته‌هایی کاربرد دارد که از این مفهوم پشتیبانی می‌کنند، که در حال حاضر شامل apt، dnf و zypper هستند.
گنجاندن مستندات در ایمیج. به‌طور پیش‌فرض فعال است. در صورت غیرفعال بودن، چنانچه مدیر بستهٔ توزیع زیرین از آن پشتیبانی کند، مستندات در ایمیج گنجانده نمی‌شوند. متغیر محیطی $WITH_DOCS که به اسکریپت‌های mkosi.build ارسال می‌شود، بسته به فعال یا غیرفعال بودن این گزینه روی 0 یا 1 تنظیم می‌شود.
فهرستی از مسیرهای جداشده با کاما را برای استفاده به عنوان درخت‌های پایه می‌پذیرد. هنگام استفاده، هر یک از این درخت‌های پایه درون درخت سیستم‌عامل کپی می‌شوند و به جای نصب توزیع از ابتدا، توزیع پایه را تشکیل می‌دهند. تنها بسته‌های اضافی روی مواردی که پیش‌تر در درخت‌های پایه نصب شده‌اند نصب می‌شوند. توجه داشته باشید که برای کارکرد صحیح این قابلیت، ایمیج پایه همچنان باید متاداده‌های مدیر بسته را با تنظیم CleanPackageMetadata=no در خود داشته باشد (به CleanPackageMetadata= مراجعه کنید).
به جای یک دایرکتوری، می‌توان یک فایل tar یا یک ایمیج دیسک ارائه داد. در این حالت، محتوای آن درون درخت سیستم‌عامل بازگشایی (unpack) می‌شود. این شیوهٔ عملکرد امکان تنظیم صریح مجوزها و مالکیت فایل را فراهم می‌کند، به ویژه برای پروژه‌های ذخیره‌شده در سیستم کنترل نسخه‌ای مانند git که متاداده‌های کامل مالکیت فایل و سطح دسترسی را برای فایل‌های ثبت‌شده حفظ می‌کنند.
فهرستی از جفت‌مسیرهای جداشده با دونقطه (:) را می‌پذیرد که با کاما از هم جدا شده‌اند. مسیر اول در هر جفت به دایرکتوری‌ای اشاره دارد که باید پیش از فراخوانی مدیر بسته در درخت سیستم‌عامل کپی شود. مسیر دوم در هر جفت به دایرکتوری مقصد در داخل ایمیج اشاره دارد. اگر مسیر دوم ارائه نشود، دایرکتوری روی دایرکتوری ریشهٔ ایمیج کپی می‌شود. مسیر دوم همیشه به عنوان یک مسیر مطلق تفسیر می‌شود. از این گزینه برای قرار دادن فایل‌ها و دایرکتوری‌ها در درخت سیستم‌عامل پیش از آنکه مدیر بسته اقدام به نصب بسته‌ها کند استفاده کنید. اگر دایرکتوری mkosi.skeleton/ در دایرکتوری محلی یافت شود، با در نظر گرفتن دایرکتوری ریشه به عنوان مقصد برای این منظور نیز استفاده می‌شود (همچنین بخش فایل‌ها (FILES) را در زیر ببینید).
توجه داشته باشید که درخت‌های اسکلت (skeleton trees) کَش می‌شوند و هرگونه تغییر در درخت‌های اسکلت پس از ساخت یک ایمیج کَش‌شده (هنگام استفاده از Incremental=)، تنها زمانی اعمال می‌شود که ایمیج کَش‌شده بازسازی شود (با استفاده از -ff یا اجرای mkosi -f clean). مشابه سازوکار درخت پایه در بالا، به جای یک دایرکتوری می‌توان یک فایل tar نیز ارائه داد. اگر mkosi.skeleton.tar در دایرکتوری محلی یافت شود، به‌طور خودکار استفاده خواهد شد. برای افزودن فایل‌های پیکربندی اضافی مدیر بسته مانند مخازن بیشتر، از SandboxTrees= استفاده کنید زیرا mkosi مدیر بسته‌ها را از خارج ایمیج فراخوانی می‌کند و نه از داخل آن؛ بنابراین هرگونه فایل پیکربندی مدیر بسته که از طریق SkeletonTrees= ارائه شود، زمانی که mkosi یک مدیر بسته را برای نصب بسته‌ها فراخوانی می‌کند بی‌اثر خواهد بود. ExtraTrees=, --extra-tree= یک فهرست جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه دریافت می‌کند. نخستین مسیر هر جفت به یک دایرکتوری برای کپی شدن از میزبان به درون تصویر اشاره دارد. دومین مسیر هر جفت به دایرکتوری مقصد درون تصویر اشاره می‌کند. اگر مسیر دوم مشخص نشده باشد، دایرکتوری بر روی دایرکتوری ریشهٔ تصویر کپی می‌شود. مسیر دوم همیشه به عنوان یک مسیر مطلق تفسیر می‌شود. از این گزینه برای جایگزینی هرگونه فایل پیکربندی پیش‌فرض ارائه‌شده با توزیع استفاده کنید. اگر دایرکتوری mkosi.extra/ در دایرکتوری محلی پیدا شود، برای این منظور با دایرکتوری ریشه به عنوان مقصد به کار گرفته می‌شود (همچنین بخش فایل‌ها (FILES) را در زیر ببینید).
همانند منطق درخت پایه در بالا، به جای یک دایرکتوری، یک فایل tar نیز می‌تواند مشخص شود. در صورت پیدا شدن mkosi.extra.tar در دایرکتوری محلی، به طور خودکار استفاده خواهد شد.
یک فهرست جداشده با کاما از بسته‌های مشخص‌شده برای حذف را با همان ساختار Packages= دریافت می‌کند. عملیات حذف به عنوان یکی از مراحل پایانی انجام خواهد شد. در صورت استفاده از CleanPackageMetadata=no، از این مرحله صرف‌نظر می‌شود.
فهرستی جداشده با کاما از الگوهای تطبیق (glob) می‌گیرد. فایل‌هایی درون تصویر که با این الگوها مطابقت داشته باشند در پایان پاک‌سازی خواهند شد.
فعال‌سازی/غیرفعال‌سازی حذف پایگاه‌های دادهٔ مدیر بسته و فراداده‌های مخزن در پایان نصب. می‌تواند به صورت true، false یا auto (پیش‌فرض) تعیین شود. در حالت auto، اگر فایل اجرایی مدیر بستهٔ مربوطه در پایان نصب وجود نداشته باشد، پایگاه‌های دادهٔ مدیر بسته و فراداده‌های مخزن حذف خواهند شد.
یک برچسب زمانی بر حسب ثانیه از مبدأ زمانی یونیکس (UNIX epoch) به عنوان آرگومان دریافت می‌کند. زمان تغییر (modification time) تمامی فایل‌ها به این مقدار محدود خواهد شد. این متغیر به systemd-repart و اسکریپت‌های اجراشده توسط mkosi نیز انتشار می‌یابد. در صورت عدم تنظیم صریح، متغیر SOURCE_DATE_EPOCH به ترتیب از --environment= و سپس از محیط میزبان بررسی می‌شود. این گزینه برای دستیابی به ساخت‌های تکرارپذیر (reproducible builds) کاربردی است. برای اطلاعات بیشتر SOURCE_DATE_EPOCH را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های همگام‌سازی (sync) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های آماده‌سازی (prepare) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های ساخت (build) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های پس از نصب (post-installation) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های نهایی‌سازی (finalize) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به عنوان اسکریپت‌های پس از خروجی (post output) برای این تصویر استفاده می‌شوند. الگوهای تطبیق (glob) پشتیبانی می‌شوند و مسیرهای منطبق، بر اساس الفبا مرتب می‌گردند. برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
یک مقدار بولی (boolean) یا auto می‌پذیرد. تولید یک تصویر قابل راه‌اندازی (bootable) را فعال یا غیرفعال می‌کند. در صورت فعال بودن، mkosi یک بارگذار بوت EFI نصب کرده و در صورت استفاده از خروجی تصویر دیسک، یک پارتیشن ESP اضافه می‌کند. اگر بارگذار بوت EFI انتخاب‌شده (گزینهٔ Bootloader= را ببینید) نصب نشده باشد یا هیچ تصویر کرنلی پیدا نشود، فرآیند ساخت شکست خواهد خورد. مقدار auto رفتاری مشابه با فعال بودن گزینه دارد، اما در صورت پیدا نشدن تصویر کرنل یا بارگذار بوت EFI انتخاب‌شده، ساخت با شکست مواجه نخواهد شد. در صورت غیرفعال بودن، حتی در صورت وجود بارگذار بوت در تصویر، نصب نخواهد شد؛ هیچ تصویر کرنل یکپارچه‌ای (UKI) ایجاد نمی‌گردد و در صورت استفاده از قالب خروجی دیسک، هیچ پارتیشن ESP به تصویر اضافه نخواهد شد.
در صورت استفاده از قالب خروجی esp، پارتیشن ESP و بارگذار بوت همواره اضافه می‌شوند و گزینهٔ Bootable= تنها کنترل می‌کند که آیا یک UKI به پارتیشن ESP اضافه شود یا خیر.
یکی از مقادیر none، systemd-boot، uki، grub، systemd-boot-signed، uki-signed یا grub-signed را می‌پذیرد. پیش‌فرض آن systemd-boot است. اگر روی none تنظیم شود، هیچ بارگذار بوت EFI درون تصویر نصب نخواهد شد. اگر روی systemd-boot تنظیم شود، systemd-boot نصب می‌شود و به ازای هر کرنلِ نصب‌شده، یک UKI تولید شده و در مسیر EFI/Linux درون ESP ذخیره می‌گردد. اگر روی uki تنظیم شود، برای جدیدترین کرنلِ نصب‌شده (کرنلی با بالاترین نسخه) یک UKI واحد تولید می‌شود که در مسیر EFI/BOOT/BOOTX64.EFI در ESP نصب می‌گردد. اگر روی grub تنظیم شود، به ازای هر کرنل نصب‌شده یک UKI تولید و در EFI/Linux در ESP ذخیره می‌شود. به ازای هر UKI تولیدشده، یک مدخل منو به پیکربندی grub در مسیر grub/grub.cfg درون ESP الحاق می‌شود که اجرای زنجیره‌ای (chainload) به UKI را انجام می‌دهد. همچنین یک grub.cfg واسط (shim) در مسیر EFI/<distribution>/grub.cfg در ESP نوشته می‌شود که جهت سازگاری با نسخه‌های امضاشدهٔ grub (که پیکربندی را از این مکان بارگذاری می‌کنند)، فایل grub/grub.cfg را در ESP بارگذاری می‌کند.
انواع signed تنها باینری‌های EFI از پیش امضاشده را که توسط توزیع ارائه شده است نصب خواهند کرد. کرنل‌ها باید درون سیستم‌فایل ریشه (به عنوان نمونه با استفاده از ExtraTrees=) ذیل مسیر /usr/lib/modules/$version، با نام vmlinux یا vmlinuz قرار گیرند. مقدار $version همان چیزی است که توسط هدف make مربوط به kernelversion در Kbuild تولید می‌شود. نکته: هنگام استفاده از systemd-boot یا systemd-boot-signed، ابزار mkosi انتظار دارد باینری‌های EFI مربوط به systemd-boot در تصویر موجود باشند. بسته به توزیع شما، این فایل‌ها ممکن است به صورت جداگانه بسته‌بندی شده باشند. به عنوان مثال، تصاویر مبتنی بر دبیان به بستهٔ systemd-boot-efi نیاز خواهند داشت.
یکی از مقادیر none یا grub را می‌گیرد. پیش‌فرض آن none است. اگر روی none تنظیم شود، هیچ بارگذار بوت BIOS نصب نخواهد شد. اگر روی grub تنظیم شود، در صورت درخواست تصویر قابل راه‌اندازی از طریق گزینهٔ Bootable=، نرم‌افزار grub به عنوان بارگذار بوت BIOS نصب می‌شود. اگر هیچ فایل تعریف پارتیشن repart پیکربندی نشده باشد، mkosi یک پارتیشن بوت BIOS برای grub و یک پارتیشن سیستم EFI را به فایل‌های پیش‌فرض تعریف پارتیشن اضافه خواهد کرد.
توجه داشته باشید که این گزینه با Bootloader= ناسازگار یا مانعة‌الجمع نیست. با پیکربندی هر دو گزینهٔ Bootloader= و BiosBootloader=، داشتن تصویری که هم روی UEFI و هم روی BIOS قابل راه‌اندازی باشد امکان‌پذیر است. پارتیشن بوت BIOS برای grub باید دارای UUID به مقدار 21686148-6449-6e6f-744e-656564454649 و حداقل دارای ۱ مگابایت اندازه باشد. حتی اگر هیچ بارگذار بوت EFI نصب نشده باشد، باز هم برای بوت BIOS به یک ESP نیاز است؛ چرا که کرنل، initrd و ماژول‌های grub در آنجا ذخیره می‌شوند.
یکی از مقادیر none، unsigned یا signed را می‌پذیرد. پیش‌فرض آن none است. اگر روی none تنظیم شود، shim و MokManager روی ESP نصب نخواهند شد. اگر روی unsigned تنظیم شود، mkosi به دنبال باینری‌های EFI امضانشدهٔ shim و MokManager می‌گردد و آن‌ها را نصب می‌کند. اگر SecureBoot= فعال باشد، mkosi پیش از نصب، باینری‌های EFI امضانشده را امضا خواهد کرد. اگر روی signed تنظیم شود، mkosi به دنبال باینری‌های EFI امضاشده می‌گردد و آن‌ها را نصب می‌کند. حتی در صورت فعال بودن SecureBoot=، mkosi این باینری‌ها را مجدداً امضا نخواهد کرد.
توجه داشته باشید که این گزینه تنها زمانی مؤثر است که ایجاد تصویری با قابلیت راه‌اندازی روی سفت‌افزار UEFI توسط گزینه‌های دیگر (Bootable=، Bootloader=) درخواست شده باشد. توجه داشته باشید هنگامی که این گزینه فعال است، mkosi تنها باینری‌های بارگذار بوت، فایل‌های تصویر کرنل و تصاویر یکپارچهٔ کرنل از پیش امضاشده را نصب می‌کند، زیرا باینری‌های خود‌امضاشده توسط نسخهٔ امضاشدهٔ shim پذیرفته نخواهند شد.
مشخص می‌کند که آیا در صورت تنظیم Bootloader= بر روی systemd-boot یا grub، از تصاویر کرنل یکپارچه (UKI) استفاده شود یا خیر. یکی از مقادیر none، unsigned، signed یا auto را می‌پذیرد. پیش‌فرض آن auto است. در صورت تنظیم روی unsigned یا signed، همواره از تصاویر کرنل یکپارچه استفاده می‌شود و در صورت مفقود بودن هر یک از مؤلفه‌های لازم برای ساخت تصویر کرنل یکپارچه، فرآیند ساخت شکست خواهد خورد. اگر روی auto تنظیم شود، در صورت در دسترس بودن تمامی مؤلفه‌های لازم از تصاویر کرنل یکپارچه استفاده خواهد شد. در غیر این صورت، مدخل‌های Type 1 طبق تعریفِ مشخصات بارگذار بوت (Boot Loader Specification) به جای آن به کار خواهند رفت. در صورت غیرفعال بودن، همواره مدخل‌های Type 1 استفاده خواهند شد. اگر Bootloader= روی یکی از انواع امضاشده (signed) تنظیم شود، یک UKI از پیش ساخته‌شده جستجو خواهد شد و در صورت پیدا نشدن، ساخت با شکست مواجه می‌شود؛ مگر اینکه UnifiedKernelImages= روی unsigned تنظیم شده باشد، که در این حالت UKI به صورت محلی ساخته می‌شود. این مورد هنگام ترکیب با تنظیم گزینهٔ زمان اجرای Firmware= روی custom کاربرد دارد تا کلید امضای محلی در UEFI db ثبت گردد..TP UnifiedKernelImageFormat=, --unified-kernel-image-format= نام فایلی را بدون هیچ‌گونه مؤلفه مسیری می‌گیرد تا قالبی را مشخص کند که تصویرهای یکپارچه هسته (UKI) باید با آن نام نصب شوند. این مقدار می‌تواند هم شامل مشخص‌کننده‌های معمولی (بخش Specifiers را ببینید) و هم مشخص‌کننده‌های تأخیری ویژه باشد که در طول نصب فایل‌ها باز می‌شوند و در ادامه شرح داده شده‌اند. قالب پیش‌فرض برای این پارامتر &e-&k است؛ در صورتی که roothash= یا usrhash= در خط فرمان هسته یافت شود، -&h و اگر /etc/kernel/tries در تصویر یافت شود، +&c به انتهای آن افزوده می‌شود.
مشخص‌کننده‌های زیر می‌توانند استفاده شوند:
مشخص‌کننده مقدار
&& نویسه &
&e توکن ورودی (Entry Token)
&k نسخه هسته
&h مقدار آرگومان هسته roothash= یا usrhash=
ساخت پروفایل‌های تکمیلی UKI. فهرستی جداشده با کاما از مسیرهای فایل‌های پیکربندی پروفایل UKI را دریافت می‌کند. این گزینه می‌تواند چندین بار استفاده شود که در این حالت هر پیکربندی به یک پروفایل متناظر UKI تبدیل و ساخته می‌شود. فایل‌های پیکربندی موجود در دایرکتوری mkosi.uki-profiles/ به طور خودکار شناسایی و دریافت می‌شوند. تمام پروفایل‌های پیکربندی‌شده UKI به عنوان پروفایل‌های تکمیلی UKI به هر UKI ساخته‌شده توسط mkosi اضافه می‌شوند.
برای اطلاعات درباره تنظیماتی که می‌توان در فایل‌های پیکربندی پروفایل UKI مشخص کرد، مستندات بخش UKIProfile را ببینید.
استفاده از initrd(های) ارائه‌شده توسط کاربر. فهرستی جداشده با کاما از مسیرهای فایل‌های initrd را دریافت می‌کند. این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست‌های initrd با یکدیگر ترکیب می‌شوند. اگر این تنظیم مشخص نشده باشد و یک تصویر قابل بوت درخواست شود، چنانچه تصویر بر اساس چند عامل (قالب خروجی، نصب بودن بسته هسته، ...) به نظر برسد که تصویری قابل بوت است، mkosi به طور خودکار یک initrd پیش‌فرض خواهد ساخت. برای غیرفعال کردن ساخت initrd پیش‌فرض، یک رشته خالی به این تنظیم اختصاص دهید. برای ساخت initrd پیش‌فرض حتی در صورت مشخص کردن این تنظیم، می‌توان مقدار ویژه default را در کنار سایر مقادیر اختصاص داد.
هنگامی که initrd پیش‌فرض استفاده می‌شود، می‌توان آن را با استفاده از تنظیمات زیر و با mkosi.initrd.conf که می‌تواند فایل یا دایرکتوری حاوی پیکربندی اضافی برای initrd پیش‌فرض باشد، بیشتر پیکربندی کرد. همچنین mkosi در زیردایرکتوری io.mkosi.initrd از دایرکتوری دست‌ساخته‌ها (بخش ENVIRONMENT VARIABLES و متغیر $ARTIFACTDIR را ببینید) به دنبال initrdها می‌گردد. هر initrd یافت‌شده در آنجا به initrd(های) ارائه‌شده توسط کاربر و هر initrd پیش‌فرض ساخته‌شده توسط mkosi پیوست می‌شود.
تنظیم پروفایل‌هایی که باید برای initrd پیش‌فرض فعال شوند. فهرستی جداشده با کاما از پروفایل‌ها را دریافت می‌کند. به طور پیش‌فرض، تمام پروفایل‌ها غیرفعال هستند.
پروفایل lvm پشتیبانی از LVM را فعال می‌کند. پروفایل network پشتیبانی از شبکه را از طریق systemd-networkd فعال می‌کند. پروفایل nfs پشتیبانی از NFS را فعال می‌کند. این گزینه نیازمند فعال بودن شبکه در initrd با استفاده از پروفایل network یا روش سفارشی دیگری است. پروفایل pkcs11 پشتیبانی از PKCS#11 را فعال می‌کند. پروفایل plymouth یک رابط گرافیکی در زمان بوت (پویانمایی و اعلان گذرواژه) فراهم می‌کند. پروفایل raid پشتیبانی از آرایه‌های RAID را فعال می‌کند.
بسته‌های اضافی برای نصب در initrd پیش‌فرض. فهرستی جداشده با کاما از مشخصات بسته‌ها را دریافت می‌کند. این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست‌های بسته‌های مشخص‌شده با یکدیگر ترکیب می‌شوند.
مشابه VolatilePackages= است، با این تفاوت که بر روی initrd پیش‌فرض اعمال می‌شود.
فهرستی جداشده با کاما از الگوهای devicetree برای انتخاب خودکار مبتنی بر سخت‌افزار. الگوها عبارت‌های تطبیق مسیر (glob) هستند. mkosi فایل‌های devicetree را در مکان‌های استاندارد وابسته به /usr/lib/modules/<kver>/dtb/، /usr/lib/firmware/<kver>/device-tree/ و /usr/lib/linux-image-<kver>/ جستجو می‌کند.
برای ساخت‌های UKI، چندین تطابق امکان انتخاب خودکار مبتنی بر سخت‌افزار را با استفاده از بخش‌های .dtbauto فراهم می‌کند. مدخل‌های بوت نوع ۱ (Type 1 boot entries) دقیقاً به یک تطابق نیاز دارند. مثال: Devicetrees=rockchip/*,imx.* تمام دِوایس‌تری‌های Rockchip و هر دِوایس‌تری IMX را شامل می‌شود.
در صورت تنظیم، تصویر اسپلش بوت برای هر تصویر یکپارچه هسته ساخته‌شده توسط mkosi از مسیر داده‌شده در داخل تصویر برداشته خواهد شد.
در صورت تنظیم بر روی true، تنها ریزکد (microcode) مربوط به پردازنده سیستم میزبان در تصویر گنجانده می‌شود.
استفاده از خط فرمان هسته مشخص‌شده هنگام ساخت تصویرها.
اگر پارتیشن root یا usr با فعال بودن verity ساخته شوند، roothash= یا usrhash= به ترتیب به طور خودکار به خط فرمان هسته افزوده می‌شوند و root= یا mount.usr= نباید اضافه شوند. در غیر این صورت، اگر مقدار این تنظیم شامل عبارت دقیق root=PARTUUID یا mount.usr=PARTUUID باشد، این عبارت‌ها به ترتیب با شناسه یکتای پارتیشن (UUID) پارتیشن root یا usr جایگزین می‌شوند. برای مثال، root=PARTUUID با root=PARTUUID=58c7d0b2-d224-4834-a16f-e036322e88f7 جایگزین می‌شود که در آن 58c7d0b2-d224-4834-a16f-e036322e88f7 همان UUID پارتیشن root است.
فهرستی از الگوهای تطبیق (glob) را دریافت می‌کند که مشخص می‌سازند کدام ماژول‌های هسته باید در تصویر گنجانده شوند. هر آرگومان می‌تواند با یک خط تیره (-) شروع شود تا ماژول‌های منطبق را مستثنی کند. آرگومان‌ها به ترتیب ارزیابی می‌شوند؛ آخرین الگوی تطبیق مثبت یا منفی نتیجه را تعیین می‌کند. ماژول‌هایی که در نهایت با یک الگوی مثبت مطابقت داشته باشند، به همراه وابستگی‌های ماژولی و سفت‌افزاری‌شان در تصویر گنجانده می‌شوند.
پسوند .ko و پسوند فشرده‌سازی در حین تطبیق نادیده گرفته می‌شوند. الگوها با مسیرهای ماژول به صورت نسبی نسبت به /usr/lib/module/<kver> سنجیده می‌شوند؛ به عنوان مثال، ماژول در /usr/lib/module/<kver>/kernel/foo/bar.ko.xz برای اهداف تطبیق به kernel/foo/bar تبدیل می‌شود. الگوهایی که با “/” شروع می‌شوند به صورت ویژه پردازش می‌شوند. الگو ابتدا با مسیری نسبت به /usr/lib/module/<kver>/kernel و تنها پس از آن با /usr/lib/module/<kver>/ تطبیق داده می‌شود. این یک سهولت است، زیرا معمولاً تنها ماژول‌های داخل درخت اصلی (in-tree) زیر kernel/ مورد توجه هستند. برای نمونه، ماژول در /usr/lib/module/<kver>/kernel/foo/bar.ko.xz می‌تواند هم با /foo/bar و هم با /kernel/foo/bar مطابقت داده شود. الگوهای تطبیق می‌توانند فقط شامل نام پایه (مانند loop) باشند که باید با نام پایه ماژول مطابقت کند، مسیر نسبی باشند (مانند block/loop) که باید با مؤلفه‌های انتهایی مسیر ماژول تا نام پایه مطابقت داشته باشند، یا یک مسیر مطلق باشند (مانند /drivers/block/loop) که باید با کل مسیر ماژول منطبق باشد. هنگامی که پسوند / داشته باشند، الگو با تمام ماژول‌های زیر آن دایرکتوری مطابقت خواهد داشت. الگوها می‌توانند شامل الگوهای عمومی سبک پوسته باشند (*، ?، [...-...]). اگر مقدار ویژه default استفاده شود، ماژول‌های هسته پیش‌فرض تعریف‌شده در پیکربندی mkosi-initrd نیز اضافه می‌شوند. اگر مقدار ویژه host استفاده شود، ماژول‌هایی که هم‌اکنون روی سیستم میزبان بارگذاری شده‌اند نیز اضافه خواهند شد.
یک مقدار بولی است که به طور پیش‌فرض فعال (true) است. در صورت فعال بودن، هنگام ساخت یک تصویر قابل بوت، mkosi یک initrd اضافی برای هر تصویر یکپارچه هسته که سرهم می‌کند ایجاد خواهد کرد. این initrd فقط شامل ماژول‌ها و احتمالاً سفت‌افزارها است و سپس به initrd پایه افزوده می‌شود تا فایل نهایی initrd تشکیل شود. این کار initrd پایه را مستقل از هسته نگه می‌دارد و تنها هنگام سرهم‌بندی UKI، ماژول‌های لازم مختص به نسخه هسته را به آن می‌افزاید.
در صورت غیرفعال بودن، هیچ initrd اضافی تولید نمی‌شود. توجه داشته باشید که ماژول‌های هسته همچنان در initrd پایه گنجانده نخواهند شد و آن initrd مستقل از هسته باقی می‌ماند. در عوض، فرض بر این است که کاربر ماژول‌های لازم را، در صورت نیاز، از طریق یک initrd سفارشی تکمیلی فراهم می‌کند. KernelInitrdModules=, --kernel-modules-initrd-include= مانند KernelModules= است، اما ماژول‌های کرنل را برای گنجاندن در initrd مشخص می‌کند.
فهرستی از الگوهای انطباق مسیر (glob) را می‌گیرد که مشخص می‌کنند کدام فایل‌های سفت‌افزار (firmware) در ایمیج گنجانده شوند. الگوها به همان شیوهٔ تنظیمات KernelModules= تفسیر می‌شوند، جز اینکه مسیرها نسبت به /usr/lib/firmware/<subdir> سنجیده می‌شوند. پسوند فشرده‌سازی نادیده گرفته می‌شود و نباید در الگو گنجانده شود.
وابستگی‌های سفت‌افزار ماژول‌های کرنلِ نصب‌شده در ایمیج به‌طور خودکار گنجانده می‌شوند. مثال: هر دو مقدار FirmwareFiles=cxgb4/bcm8483.bin یا FirmwareFiles=bcm8483.* موجب می‌شوند که /usr/lib/firmware/cxgb4/bcm8483.bin.xz حتی اگر توسط ماژولی فهرست نشده باشد، اضافه شود.
تنظیمات Locale=، --locale=، LocaleMessages=، --locale-messages=، Keymap=، --keymap=، Timezone=، --timezone=، Hostname=، --hostname=، RootShell=، --root-shell= متناظر با گزینه‌های هم‌نام در systemd-firstboot هستند. برای اطلاعات بیشتر systemd-firstboot(1) را ببینید. علاوه بر این، در صورت امکان، اعتبارسنجی‌های (credentials) متناظر systemd برای این تنظیمات در /usr/lib/credstore نوشته می‌شوند تا حتی در صورتی که فقط /usr در ایمیج ارائه شده باشد اعمال شوند.
گذرواژه ریشه (root) سیستم را تنظیم می‌کند. اگر از این گزینه استفاده نشود، اما فایل mkosi.rootpw در دایرکتوری محلی یافت شود، گذرواژه به‌طور خودکار از آن خوانده می‌شود، یا در صورت اجرایی بودن فایل، مانند یک اسکریپت اجرا شده و به‌جای آن خروجی استاندارد (stdout) خوانده می‌شود (بخش SCRIPTS در زیر را ببینید). اگر گذرواژه با hashed: آغاز شود، با آن مانند یک گذرواژه ریشه از قبل هش‌شده رفتار می‌شود. گذرواژه ریشه همچنین در /usr/lib/credstore تحت credential مناسب systemd ذخیره می‌شود تا حتی اگر فقط /usr در ایمیج گنجانده شده باشد نیز اعمال گردد. برای ایجاد یک حساب قفل‌نشده بدون گذرواژه، از hashed: بدون هیچ هشی استفاده کنید.
ورود خودکار (autologin) را برای کاربر root در /dev/pts/0 (nspawn)، /dev/tty1 و /dev/hvc0 فعال می‌کند.
فایل‌های /etc/initrd-release و /init را به ایمیج می‌افزاید تا بتواند به‌عنوان یک initramfs استفاده شود.
مشخص می‌کند که آیا یک واحد سوکت sshd و سرویس منطبق با آن در ایمیج نهایی نصب شود یا خیر. یکی از مقادیر always، never، auto یا runtime را می‌گیرد. پیش‌فرض auto است.
اگر روی auto تنظیم شود و sshd در ایمیج موجود باشد اما باینری مولد systemd-ssh-generator وجود نداشته باشد، یا اگر روی always تنظیم شود، mkosi واحدهای sshd را در ایمیج نهایی نصب می‌کند که SSH را روی VSock ارائه می‌دهند. اگر روی never تنظیم شود، mkosi این واحدها را نصب نمی‌کند. اگر مقدار runtime استفاده شود، mkosi هیچ واحدی را نصب نخواهد کرد اما در صورتی که هیچ اطلاعات اعتباری SSH پیکربندی نشده باشد، راه‌اندازی mkosi vm را لغو می‌کند. هنگام ساخت با این گزینه و اجرای ایمیج با استفاده از mkosi vm، می‌توان از دستور mkosi ssh برای اتصال به کانتینر/ماشین مجازی از طریق SSH استفاده کرد. توجه داشته باشید که همچنان باید مطمئن شوید openssh در ایمیج نصب شده است تا mkosi ssh به‌درستی کار کند. دستور mkosi genkey را اجرا کنید تا به‌طور خودکار یک گواهی X.509 و کلید خصوصی تولید شود که توسط mkosi جهت فعال‌سازی دسترسی SSH به هر ماشین مجازی از طریق mkosi ssh استفاده می‌شود. برای دسترسی به ایمیج‌های بوت‌شده با استفاده از mkosi boot، از machinectl استفاده کنید. از نسخه systemd v256 به بعد، systemd-ssh-generator(8) هنگام اجرا در داخل یک ماشین مجازی به‌طور خودکار sshd را روی VSock ارائه می‌دهد. بنابراین اگر از نسخهٔ جدیدی از systemd در یک ماشین مجازی استفاده می‌کنید، این گزینه معمولاً به کار نمی‌رود. همچنان لازم است openssh در ایمیج نصب باشد، و تنظیم پیش‌فرض --vsock=auto برای اطمینان از در دسترس بودن VSock درون ماشین مجازی کافی است. نکته: اگر توزیع ایمیج از SELinux استفاده می‌کند، دسترسی سرویس sshd مربوط به mkosi به VSock مسدود خواهد شد که منجر به عدم اتصال به آن از سمت میزبان می‌شود. لازم است یا اجرای SELinux (حالت enforcement) را غیرفعال کنید، یا یک ماژول سیاست سفارشی بسازید (برای مثال با audit2allow).
مشخص می‌کند که آیا برچسب‌گذاری مجدد فایل‌ها برای تطابق با سیاست SELinux ایمیج انجام شود یا خیر. یک مقدار بولی یا auto می‌گیرد. پیش‌فرض auto است. اگر غیرفعال باشد، برچسب فایل‌ها مجدداً تعیین نخواهد شد. اگر فعال باشد، باید یک سیاست SELinux در ایمیج نصب شده باشد و setfiles برای برچسب‌گذاری مجدد فایل‌ها در دسترس باشد. اگر در حین setfiles خطایی رخ دهد، ساخت با شکست مواجه می‌شود. اگر روی auto تنظیم شود، فایل‌ها در صورتی که mkosi در حال ساخت یک ایمیج دایرکتوری نباشد، یک سیاست SELinux در ایمیج نصب باشد و setfiles در دسترس باشد، برچسب‌گذاری مجدد خواهند شد. هرگونه خطای رخ‌داده در حین setfiles نادیده گرفته خواهد شد.
توجه داشته باشید که هنگام اجرا با اختیارات غیرریشه (unprivileged)، ابزار setfiles در اعمال برچسب‌هایی که در سیاست SELinux سیستم میزبان وجود ندارند، با شکست مواجه خواهد شد. برای اطمینان از اینکه setfiles بدون خطا با موفقیت انجام می‌شود، مطمئن شوید که mkosi را با کاربر root اجرا می‌کنید یا ساخت را از روی سیستم میزبانی انجام می‌دهید که سیاست SELinux یکسانی با ایمیج در حال ساخت دارد.
یک UUID یا مقدار ویژهٔ random را می‌گیرد. شناسه ماشین (machine ID) ایمیج را روی UUID مشخص‌شده تنظیم می‌کند. اگر روی random تنظیم شود، یک UUID تصادفی در /etc/machine-id نوشته خواهد شد. اگر به‌طور صریح مشخص نشود و فایل mkosi.machine-id در دایرکتوری محلی وجود داشته باشد، UUID مورد استفاده از آن خوانده می‌شود. در غیر این صورت، مقدار uninitialized در /etc/machine-id نوشته خواهد شد..SS بخش [Validation]
امضای systemd-boot (اگر هنوز امضا نشده باشد) و هر تصویر هسته یکپارچه (unified kernel image) ایجاد شده برای UEFI SecureBoot.
راه‌اندازی ثبت خودکار کلیدهای secure boot در ماشین‌های مجازی بر اساس مستندات systemd-boot(7) در صورتی که SecureBoot= استفاده شده باشد. توجه داشته باشید که systemd-boot تنها از systemd نسخه v253 به بعد ثبت خودکار کلیدهای secure boot را در ماشین‌های مجازی انجام خواهد داد. برای انجام ثبت خودکار در systemd نسخه v252 یا بر روی ماشین‌های فیزیکی (bare metal)، با استفاده از یک درخت اضافی (extra tree) یک فایل پیکربندی systemd-boot حاوی secure-boot-enroll force یا secure-boot-enroll manual در مسیر /efi/loader/loader.conf بنویسید. ثبت خودکار در نسخه‌های قدیمی‌تر از v252 در systemd پشتیبانی نمی‌شود. پیش‌فرض yes است.
مسیر فایل PEM حاوی کلید خصوصی برای امضای تصویر هسته UEFI در صورت استفاده از SecureBoot=، و همچنین امضاهای PCR در صورتی که SignExpectedPcr= نیز استفاده شده باشد. هنگامی که SecureBootKeySource= تعیین شده باشد، نوع ورودی به منبع بستگی دارد.
مسیر فایل X.509 حاوی گواهی برای تصویر هسته امضا شده UEFI، در صورتی که SecureBoot= استفاده شود.
ابزار مورد استفاده برای امضای فایل‌های باینری PE در secure boot. یکی از مقادیر systemd-sbsign، sbsign یا auto را می‌پذیرد. پیش‌فرض auto است. اگر بر روی auto تنظیم شود، در صورت در دسترس بودن، یکی از ابزارهای systemd-sbsign یا sbsign استفاده می‌شود که اولویت با systemd-sbsign خواهد بود.
تعیین اینکه آیا verity برای تصاویر افزونه (extension images) اعمال یا غیرفعال شود. یکی از مقادیر signed، hash، defer، auto یا یک مقدار بولی را می‌پذیرد. اگر بر روی signed تنظیم شود، کلید و گواهی verity باید موجود باشند و اگر هیچ پارتیشن verity در تصویر دیسک ایجاد شده توسط systemd-repart شناسایی نشود، فرایند ساخت شکست خواهد خورد. اگر غیرفعال شود، پارتیشن‌های verity از تصاویر افزونه تولید شده توسط systemd-repart حذف خواهند شد. اگر بر روی hash تنظیم شود، mkosi ابزار systemd-repart را برای ایجاد یک پارتیشن هش verity بدون پارتیشن امضا پیکربندی می‌کند. اگر بر روی defer تنظیم شود، فضا برای پارتیشن امضای verity اختصاص داده می‌شود اما هنوز پر نخواهد شد. اگر بر روی auto تنظیم شده و کلید و گواهی verity موجود باشند، mkosi آن‌ها را به systemd-repart منتقل کرده و انتظار دارد که تصویر دیسک تولید شده شامل پارتیشن‌های verity باشد، اما اگر هیچ پارتیشن verity در تصویر دیسک ایجاد شده توسط systemd-repart یافت نشود، ساخت با خطا متوقف نخواهد شد.
توجه داشته باشید که غیرفعال‌سازی صریح امضا و/یا هش verity هنوز برای خروجی disk پیاده‌سازی نشده است و در حال حاضر فقط برای تصاویر افزونه کار می‌کند.
مسیر فایل PEM حاوی کلید خصوصی برای امضای پارتیشن امضای verity، در صورتی که یک پارتیشن امضای verity با systemd-repart افزوده شده باشد. هنگامی که VerityKeySource= تعیین شده باشد، نوع ورودی به منبع بستگی دارد.
مسیر فایل X.509 حاوی گواهی برای امضای پارتیشن امضای verity، در صورتی که یک پارتیشن امضای verity با systemd-repart افزوده شده باشد.
سنجش اجزای تصویر هسته یکپارچه (UKI) با استفاده از systemd-measure و جاسازی امضای PCR درون تصویر هسته یکپارچه. این گزینه یک مقدار بولی یا مقدار ویژه auto (که پیش‌فرض است) می‌پذیرد؛ در صورتی که باینری systemd-measure در PATH موجود باشد، مقدار auto معادل یک مقدار true خواهد بود. به فعال بودن SecureBoot= و کلید ارائه‌شده در SecureBootKey= وابسته است.
مسیر فایل PEM حاوی کلید خصوصی برای امضای امضاهای PCR مورد انتظار. هنگامی که SignExpectedPcrKeySource= مشخص شده باشد، نوع ورودی به منبع بستگی دارد.
مسیر فایل X.509 حاوی گواهی برای امضای امضاهای PCR مورد انتظار.
تعیین اینکه آیا سیاست‌های PCR امضاشده‌ای که تنها از طریق initrd برآورده می‌شوند تولید گردند یا خیر. این مورد برای مقداردهی اولیه NvPCRs الزامی است. این گزینه یک مقدار بولی یا مقدار ویژه auto را می‌پذیرد که پیش‌فرض است و در صورتی که امضای PCR فعال باشد (نگاه کنید به SignExpectedPcr=) و نسخه ukify حداقل v262 باشد، معادل یک مقدار true است. امضا با کلیدی انجام می‌شود که به SignExpectedPcrKey= داده شده است.
منبع کلید خصوصی متناظر، جهت پشتیبانی از موتورها (engines) و فراهم‌کننده‌های (providers) OpenSSL، به‌عنوان مثال --secure-boot-key-source=engine:pkcs11 یا --secure-boot-key-source=provider:pkcs11.
منبع گواهی متناظر، جهت پشتیبانی از فراهم‌کننده‌های OpenSSL، به‌عنوان مثال --secure-boot-certificate-source=provider:pkcs11. توجه داشته باشید که موتورها (engines) پشتیبانی نمی‌شوند.
تعیین مسیر فایل حاوی عبارت عبور (passphrase) برای استفاده در رمزگذاری LUKS. این فایل باید شامل عبارت عبور به صورت کلمه‌به‌کلمه بوده و با نویسه خط جدید پایان نیابد (یعنی با همان قالبی که cryptsetup و /etc/crypttab برای فایل‌های عبارت عبور انتظار دارند). فایل باید دارای حالت دسترسی 0600 یا محدودتر باشد.
توجه داشته باشید که این تنظیم به‌تنهایی هیچ رمزگذاری را فعال نمی‌کند. همچنین باید یک یا چند فایل تعریف پارتیشن را با Encrypt=key-file به mkosi.repart/ اضافه کنید تا پارتیشن‌های رمزگذاری‌شده به تصویر اضافه شوند.
ایجاد یک فایل <output>.SHA256SUMS از تمام اقلام تولیدشده پس از اتمام فرایند ساخت.
امضای فایل SHA256SUMS تولیدشده با استفاده از gpg پس از پایان کار.
پیاده‌سازی OpenPGP مورد استفاده برای امضا کردن. پیش‌فرض gpg است. انتخاب مقداری متفاوت از پیش‌فرض، از ابزار مشخص‌شده Stateless OpenPGP (SOP) برای امضای فایل SHA256SUMS استفاده خواهد کرد.
نمونه‌های انتخابی شامل sqop و rsop هستند، اما هر پیاده‌سازی از https://www.openpgp.org/about/sop که بتواند به‌صورت محلی نصب شود کار خواهد کرد.
انتخاب کلید gpg برای استفاده در امضای SHA256SUMS. این کلید باید از قبل در دسته‌کلید (keyring) برنامه gpg موجود باشد..SS بخش [Build]
در صورت تعیین، برنامه‌های اجراشده توسط mkosi برای ساخت و بوت کردن یک ایمیج، به جای سیستم میزبان، درون درخت داده‌شده جستجو می‌شوند. از این گزینه برای بازتولیدپذیرتر کردن ساخت ایمیج با استفادهٔ همیشگی از نسخه‌های یکسان برنامه‌ها جهت ساخت ایمیج نهایی استفاده کنید، به جای هر نسخه‌ای که روی سیستم میزبان نصب است. اگر این گزینه استفاده نشود، اما دایرکتوری mkosi.tools/ در دایرکتوری محلی یافت شود، به طور خودکار برای این منظور با دایرکتوری ریشه به عنوان مقصد استفاده خواهد شد.
دایرکتوری درخت ابزارها بین ساخت‌های مکرر ایمیج حفظ می‌شود، مگر آنکه با فراخوانی mkosi clean -f پاکسازی شود. توجه داشته باشید باینری‌های یافت‌شده در هر یک از مسیرهای پیکربندی‌شده با ExtraSearchPaths= با /usr/ برگرفته از درخت ابزارها به جای سیستم میزبان اجرا خواهند شد. اگر توزیع یا انتشار میزبان به ترتیب با توزیع یا انتشار درخت ابزارها مطابقت نداشته باشد، این امر ممکن است هنگام تلاش برای اجرای باینری‌ها از هر یک از مسیرهای جستجوی اضافی به شکست بیانجامد. اگر روی yes تنظیم شود، mkosi به طور خودکار یک ایمیج اضافی از درخت ابزارها می‌افزاید و از آن به عنوان درخت ابزارها استفاده می‌کند. این ایمیج را می‌توان با استفاده از تنظیمات زیر و با mkosi.tools.conf که می‌تواند فایل یا دایرکتوری حاوی پیکربندی اضافی برای درخت ابزارهای پیش‌فرض باشد، بیشتر پیکربندی کرد. برای جزئیات بیشتر بخش TOOLS TREE را ببینید.
توزیع مورد استفاده برای درخت ابزارهای پیش‌فرض را تعیین می‌کند. به طور پیش‌فرض روی توزیع میزبان تنظیم است، مگر اینکه توزیع میزبان (نه مقصد) Ubuntu باشد که پیش‌فرض به Debian تغییر می‌کند، و RHEL، CentOS، Alma و Rocky که پیش‌فرض به Fedora تغییر می‌کنند، یا custom اگر توزیع میزبان یک توزیع پشتیبانی‌شده نباشد.
نسخه انتشار توزیع را برای استفاده در درخت ابزارهای پیش‌فرض تعیین می‌کند. به طور پیش‌فرض، انتشار پیش‌فرض هاردکدشده در mkosi برای آن توزیع استفاده می‌شود.
پروفایل‌های فعال برای درخت ابزارهای پیش‌فرض را تعیین می‌کند. یک فهرست جداشده با کاما متشکل از devel، misc، package-manager و runtime می‌پذیرد. به طور پیش‌فرض، تمام پروفایل‌ها به جز devel و gui فعال هستند.
پروفایل devel شامل ابزارهای مورد نیاز برای ساخت پروژه‌های (C/C++) است. پروفایل misc شامل ابزارهای مفید گوناگونی است که داشتن آن‌ها در اسکریپت‌ها کاربردی و دم‌دست است. پروفایل مدیر بسته شامل مدیرهای بسته و ابزارهای مرتبط به جز ابزارهای بومی توزیع درخت ابزارها است. پروفایل runtime شامل ابزارهای مورد نیاز برای بوت کردن ایمیج‌ها در یک کانتینر systemd-nspawn یا در یک ماشین مجازی است. پروفایل gui شامل ابزارهای مورد نیاز برای بوت کردن ایمیج‌ها در یک ماشین مجازی همراه با پشتیبانی از صوت و تصویر است.
آینه (mirror) مورد استفاده برای درخت ابزارهای پیش‌فرض را تعیین می‌کند. به طور پیش‌فرض، از آینهٔ پیش‌فرض توزیع درخت ابزارها استفاده می‌شود.
مشابه Snapshot= اما برای درخت ابزارهای پیش‌فرض. به طور پیش‌فرض، اگر توزیع درخت ابزارها با توزیع ایمیج مطابقت داشته باشد، از اسنپ‌شات ایمیج استفاده می‌شود.
مشابه Repositories= اما برای درخت ابزارهای پیش‌فرض.
مشابه SandboxTrees= اما برای درخت ابزارهای پیش‌فرض.
بسته‌های اضافی برای نصب در درخت ابزارهای پیش‌فرض. فهرستی از مشخصات بسته‌ها که با کاما از هم جدا شده‌اند می‌پذیرد. این گزینه می‌تواند چندین بار استفاده شود که در این حالت فهرست بسته‌های مشخص‌شده با هم ترکیب می‌شوند.
مشابه PackageDirectories=، اما برای درخت ابزارهای پیش‌فرض.
مشخص می‌کند که آیا از گواهی‌ها و کلیدهای درون درخت ابزارها استفاده شود یا خیر. به طور پیش‌فرض فعال است. در صورت فعال بودن، /etc/pki/ca-trust، /etc/pki/tls، /etc/ssl، /etc/ca-certificates و /var/lib/ca-certificates از درخت ابزارها استفاده می‌شوند. در غیر این صورت، این دایرکتوری‌ها از سیستم میزبان دریافت می‌شوند.
فهرستی از مسیرهای جداشده با دونقطه برای جستجوی ابزارها در آن‌ها، پیش از بررسی مسیر جستجوی معمولی $PATH.
یا strict یا یک مقدار بولی را به عنوان آرگومان می‌پذیرد. حالت ساخت افزایشی را فعال می‌کند. در این حالت، بلافاصله پس از نصب تمام بسته‌های سیستم‌عامل و اجرای اسکریپت‌های آماده‌سازی (prepare)، اما پیش از فراخوانی اسکریپت‌های mkosi.build (یا هر کاری که پس از آن رخ می‌دهد)، رونوشتی از ایمیج سیستم‌عامل ایجاد می‌شود. در فراخوانی‌های بعدی mkosi همراه با سوییچ -i، این ایمیج کَش‌شده می‌تواند برای صرف‌نظر از نصب بسته‌های سیستم‌عامل استفاده شود، و بدین‌سان زمان ساخت‌های تکراری را به شدت کاهش دهد. توجه داشته باشید که اگرچه یک سازوکار ابتدایی برای باطل کردن کش وجود دارد، اما قطعاً بی‌نقص نیست. برای اجبار به بازسازی ایمیج کَش‌شده، -i را با -ff ترکیب کنید تا مطمئن شوید ایمیج کش‌شده ابتدا حذف و سپس دوباره ساخته می‌شود.
اگر روی strict تنظیم شود، در صورت عدم وجود ایمیج کَش‌شدهٔ از پیش ساخته‌شده، ساخت با شکست مواجه می‌شود.
یکی از مقادیر auto، metadata، always یا never را می‌پذیرد. پیش‌فرض auto است. در صورت انتخاب always، به مدیر بسته دستور داده می‌شود که به شبکه متصل نشود. تا زمانی که کش بسته‌ها از قبل کاملاً پر شده باشد، این کار سطح حداقلی از بازتولیدپذیری را فراهم می‌کند. اگر روی metadata تنظیم شود، مدیر بسته همچنان می‌تواند بسته‌ها را بارگیری کند، اما متادیتای مخزن همگام‌سازی نخواهد شد. اگر روی auto تنظیم شود، متادیتای مخزن هنگامی همگام‌سازی می‌شود که پیش از آن هیچ ایمیجی ساخته نشده باشد، یا زمانی که تمام ایمیج‌ها از قبل کَش شده باشند (به Incremental= مراجعه کنید) و حداقل یکی از آن کَش‌ها اکنون منسوخ شده باشد (که در این حالت تمام ایمیج‌های کَش‌شده باطل می‌شوند). بسته‌ها می‌توانند در حین ساخت بارگیری شوند. اگر روی never تنظیم شود، متادیتای مخزن همواره همگام‌سازی می‌شود و بسته‌ها می‌توانند در طول ساخت بارگیری شوند.
فهرستی جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه را می‌پذیرد. مسیر نخست از هر جفت، به دایرکتوری‌ای اشاره دارد که باید پیش از اجرای یک ابزار، به درون سندباکس mkosi کپی شود. مسیر دوم هر جفت، به دایرکتوری مقصد در درون سندباکس اشاره می‌کند. اگر مسیر دوم ارائه نشود، دایرکتوری بر روی دایرکتوری ریشهٔ سندباکس کپی می‌شود. مسیر دوم همواره به عنوان یک مسیر مطلق تفسیر می‌شود. اگر دایرکتوری mkosi.sandbox/ در دایرکتوری محلی یافت شود، با دایرکتوری ریشه به عنوان مقصد برای این منظور استفاده می‌شود (همچنین بخش FILES در زیر را ببینید).
دستور mkosi پیکربندی مدیر بسته و فایل‌های مرتبط را در درخت‌های سندباکس پیکربندی‌شده جستجو می‌کند. مگر آنکه جور دیگری مشخص شده باشد، از فایل‌های پیکربندی در مکان‌های معمول آن‌ها در /usr یا /etc در درخت‌های سندباکس استفاده خواهد کرد. به عنوان نمونه، در صورتی که برای نصب بسته‌ها از dnf استفاده شود، در درخت‌های سندباکس به دنبال /etc/dnf/dnf.conf خواهد گشت.
مسیر به دایرکتوری‌ای برای ذخیره داده‌های مورد نیاز به صورت موقت در حین ساخت ایمیج. این دایرکتوری باید فضای کافی برای ذخیره کل ایمیج سیستم‌عامل داشته باشد، هرچند در بیشتر حالت‌ها فضای دیسکِ عملاً مصرف‌شده کمتر است. در صورت عدم تعیین، زیردایرکتوری‌ای از $XDG_CACHE_HOME (در صورت تنظیم بودن)، $CACHE_DIRECTORY (در صورت تنظیم بودن)، $HOME/.cache (در صورت تنظیم بودن) یا /var/tmp استفاده می‌شود.
داده‌های درون این دایرکتوری پس از هر ساخت به طور خودکار پاک می‌شوند. در صورتی که اجرای mkosi به طور غیرعادی لغو شود (برای نمونه به دلیل راه‌اندازی مجدد یا قطعی برق)، پاک کردن دستی محتویات این دایرکتوری خطری ندارد.
مسیری به یک دایرکتوری برای استفاده به عنوان دایرکتوری کش افزایشی برای ایمیج‌های افزایشی تولیدشده در هنگام فعال بودن گزینهٔ Incremental= می‌پذیرد. اگر از این گزینه استفاده نشود، اما دایرکتوری mkosi.cache/ در دایرکتوری محلی موجود باشد، به صورت خودکار برای این منظور به کار می‌رود.
زیردایرکتوری درون دایرکتوری کش را که ایمیج کَش‌شده در آن ذخیره می‌شود، مشخص می‌کند. این مقدار ممکن است شامل هر دو دستهٔ مشخصه‌گرهای عادی (به Specifiers مراجعه کنید) و مشخصه‌گرهای تأخیری ویژه باشد که در زیر شرح داده شده‌اند و به جای حین تحلیل پیکربندی، پس از اتمام تحلیل پیکربندی بسط می‌یابند. قالب پیش‌فرض برای این پارامتر &d~&r~&a~&I است.
مشخصه‌گرهای زیر می‌توانند استفاده شوند:
مشخصه‌گر مقدار
&& نویسهٔ &
&d Distribution=
&r Release=
&a Architecture=
&i ImageId=
&v ImageVersion=
&I نام زیرایمیج درون mkosi.images/ یا main
توجه داشته باشید که تمام ایمیج‌ها در یک ساخت باید یک کلید کش یکتا داشته باشند. PackageCacheDirectory=, --package-cache-dir= مسیری به یک دایرکتوری را می‌گیرد تا به عنوان دایرکتوری حافظهٔ موقت بسته برای مدیر بستهٔ توزیعِ استفاده‌شده به کار رود. اگر تنظیم نشده باشد، اما یک دایرکتوری mkosi.pkgcache/ در دایرکتوری محلی یافت شود، به‌طور خودکار برای این منظور استفاده می‌شود؛ در غیر این صورت، دایرکتوری مناسبی در دایرکتوری خانگی کاربر یا سیستم استفاده خواهد شد.
مسیری به یک دایرکتوری را می‌گیرد تا به عنوان دایرکتوری ساخت برای سامانه‌های ساختی که از ساخت خارج از درخت مبدأ پشتیبانی می‌کنند (مانند Meson) استفاده شود. دایرکتوری استفاده‌شده به این روش، بین ساخت‌های مکرر به اشتراک گذاشته می‌شود و به سامانهٔ ساخت اجازه می‌دهد مصنوعاتی (مانند فایل‌های شیء، فایل‌های اجرایی و ...) را که در فراخوانی‌های قبلی تولید شده‌اند مجدداً به کار گیرد. اسکریپت‌های ساخت می‌توانند مسیر این دایرکتوری را در متغیر محیطی $BUILDDIR بیابند. این دایرکتوری هنگام فراخوانی mkosi-chroot در زمان اجرای اسکریپت‌های ساخت، به دایرکتوری ریشهٔ تصویر متصل (mount) می‌شود. اگر این گزینه مشخص نشده باشد، اما دایرکتوری mkosi.builddir/ در دایرکتوری محلی موجود باشد، به‌طور خودکار برای این منظور استفاده می‌شود (همچنین بخش FILES در زیر را ببینید).
زیردایرکتوری درون دایرکتوری ساخت را که مصنوعات ساخت افزایشی باید در آن ذخیره شوند، مشخص می‌کند. این مقدار می‌تواند شامل هردوی مشخص‌کننده‌های معمولی (بخش Specifiers را ببینید) و مشخص‌کننده‌های خاص تأخیری باشد که به جای زمان تجزیهٔ پیکربندی، پس از پایان تجزیهٔ پیکربندی بسط داده می‌شوند؛ این‌ها همان مشخص‌کننده‌های تأخیری هستند که توسط CacheKey= نیز پشتیبانی می‌شوند. قالب پیش‌فرض برای این پارامتر &d~&r~&a است.
برای غیرفعال کردن کامل استفاده از زیردایرکتوری ساخت، مقدار تحت‌اللفظی - را به این تنظیم اختصاص دهید.
یک مقدار بولی یا auto می‌گیرد. استفاده از زیرحجم‌های btrfs را برای خروجی‌های درخت دایرکتوری فعال یا غیرفعال می‌کند. اگر فعال باشد، mkosi دایرکتوری ریشه را به عنوان یک زیرحجم btrfs ایجاد می‌کند و در صورت امکان از رونوشت‌های فوری زیرحجم btrfs برای کپی کردن درخت‌های پایه یا کش‌شده استفاده می‌کند که بسیار سریع‌تر از انجام یک کپی بازگشتی است. اگر صراحتاً فعال شده باشد و btrfs نصب نباشد یا امکان ایجاد زیرحجم‌ها وجود نداشته باشد، خطایی صادر می‌شود. اگر بر روی auto تنظیم شده باشد، نبود btrfs یا خطا در ایجاد زیرحجم‌ها نادیده گرفته می‌شود.
مشخص می‌کند که آیا تصاویر دیسک با استفاده از دستگاه‌های loopback ساخته شوند یا خیر. به‌طور پیش‌فرض فعال است. هنگامی که فعال باشد، systemd-repart از دستگاه‌های loopback برای ساخت تصاویر دیسک استفاده نخواهد کرد. هنگامی که غیرفعال باشد، systemd-repart همیشه از دستگاه‌های loopback برای ساخت تصاویر دیسک استفاده خواهد کرد.
توجه داشته باشید که هنگام استفاده از RepartOffline=no، دستور mkosi نمی‌تواند بدون دسترسی ممتاز اجرا شود و ساخت تصویر باید به عنوان کاربر root، خارج از هرگونه کانتینر و با در دسترس بودن دستگاه‌های loopback در سیستم میزبان انجام گیرد. در حال حاضر دو سناریوی شناخته‌شده وجود دارد که در آن‌ها باید از RepartOffline=no استفاده شود. نخست، هنگام استفاده از Subvolumes= در فایل تعریف پارتیشن repart است، زیرا زیرحجم‌ها را نمی‌توان بدون استفاده از دستگاه‌های loopback ایجاد کرد. دوم، هنگام ایجاد سیستمی با SELinux و یک پارتیشن ریشهٔ XFS است. از آن‌جا که mkfs.xfs از مقداردهی اولیهٔ یک سیستم فایل XFS با ویژگی‌های توسعه‌یافته پشتیبانی نمی‌کند، باید از دستگاه‌های loopback استفاده شود تا اطمینان حاصل گردد که ویژگی‌های توسعه‌یافتهٔ SELinux در سیستم فایل XFS تولیدشده قرار می‌گیرند.
یک مقدار بولی می‌گیرد. اگر فعال باشد، mkosi پیکربندی ارائه‌شده از طریق خط فرمان برای آخرین ساخت را در زیردایرکتوری .mkosi-private واقع در دایرکتوری‌ای که از آن فراخوانی شده است می‌نویسد. سپس تا زمانی که تصویر مجدداً ساخته نشود، از این آرگومان‌ها استفاده می‌شود تا از وارد کردن مکرر آن‌ها جلوگیری به عمل آید.
برای ارائهٔ مثالی از چرایی مفید بودن این گزینه: اگر دستور mkosi -O my-custom-output-dir -f و در ادامه mkosi vm را اجرا کنید، mkosi با این خطا که تصویر هنوز ساخته نشده است متوقف خواهد شد. اگر دستور mkosi -O my-custom-output-dir --history=yes -f و در ادامه mkosi vm را اجرا کنید، طبق انتظار تصویری را که در مرحلهٔ قبل ساخته شده است بوت می‌کند.
فهرستی جداشده با کاما از جفت‌مسیرهای جداشده با دونقطه را می‌گیرد. مسیر اول از هر جفت، به دایرکتوری‌ای از میزبان اشاره دارد که باید متصل شود. مسیر دوم از هر جفت، به دایرکتوری‌ای اشاره دارد که دایرکتوری مبدأ باید هنگام اجرای اسکریپت‌ها در آن متصل شود. به ابتدای هر مسیر هدف، پیشوند /work/src اضافه می‌شود و تمام منابع ساخت پیش از اتصال، بر اساس هدفشان به ترتیب واژه‌نگاشتی مرتب می‌شوند تا مسیرهای سطح بالاتر ابتدا متصل گردند. اگر صراحتاً پیکربندی نشده باشد، دایرکتوری کاری فعلی در /work/src متصل می‌شود.
یک مقدار بولی یا مقدار ویژهٔ buildcache را می‌گیرد. به‌طور پیش‌فرض غیرفعال است. مشخص می‌کند که آیا تغییرات اعمال‌شده در دایرکتوری‌های مبدأ، دایرکتوری کاری و موارد پیکربندی‌شده با BuildSources= ذخیره و ماندگار شوند یا خیر. اگر فعال باشد، تمام دایرکتوری‌های مبدأ پس از اجرای تمامی اسکریپت‌های یک نوع خاص (به‌جز اسکریپت‌های همگام‌سازی)، هر بار به وضعیت اولیهٔ خود بازنشانی می‌شوند.
💥💣💥 اگر روی buildcache تنظیم شود، لایهٔ روکش (overlay) هنگام اجرای اسکریپت‌های ساخت دور انداخته نمی‌شود، بلکه در دایرکتوری ساخت که از طریق BuildDirectory= پیکربندی شده ذخیره می‌شود و در اجراهای بعدی مجدداً استفاده خواهد شد. لایهٔ روکش همچنان برای سایر اسکریپت‌ها دور انداخته می‌شود. این گزینه می‌تواند برای پیاده‌سازی کشینگ پیشرفته‌ترِ ساخت‌ها استفاده شود، اما ممکن است به وضعیت‌های غیرمنتظره در دایرکتوری مبدأ منجر شود. هنگام استفاده از این گزینه، یک دایرکتوری ساخت حتماً باید پیکربندی شده باشد. 💥💣💥
متغیرهایی را به محیطی که مدیران بسته و اسکریپت‌های prepare/build/postinstall/finalize با آن اجرا می‌شوند، اضافه می‌کند. فهرستی از انتساب‌های متغیر یا فقط نام متغیرها را که با فاصله جدا شده‌اند می‌گیرد. در حالت دوم، مقادیر آن متغیرها از محیطی که mkosi در آن فراخوانی شده است انتقال داده می‌شوند. این گزینه ممکن است بیش از یک بار مشخص شود که در این صورت تمام متغیرهای فهرست‌شده تنظیم خواهند شد. اگر یک متغیر دو بار تنظیم شود، تنظیم بعدی جایگزین تنظیم قبلی می‌شود.
فهرستی جداشده با کاما از مسیرهای فایل‌هایی را می‌گیرد که حاوی تعاریف متغیرهای محیطی برای اضافه شدن به محیط اسکریپت‌نویسی هستند. اگر فایل mkosi.env در دایرکتوری محلی یافت شود، از آن استفاده می‌کند. متغیرها ابتدا از mkosi.env (در صورت وجود)، سپس از فهرست فایل‌های داده‌شده و پس از آن از تنظیمات Environment= خوانده می‌شوند.
اگر روی نادرست (false) تنظیم شود (یا زمانی که گزینهٔ خط فرمان استفاده شود)، هنگام فراخوانی اسکریپت‌های mkosi.build متغیر محیطی $WITH_TESTS روی 0 تنظیم می‌شود. این قابلیت برای آن در نظر گرفته شده که توسط اسکریپت‌های ساخت جهت دور زدن آزمون‌های واحد یا یکپارچه‌سازی که معمولاً در طول فرایند ساخت مبدأ اجرا می‌شوند، به کار رود. توجه داشته باشید که این گزینه هیچ اثری ندارد مگر اینکه اسکریپت‌های ساخت mkosi.build آن را پردازش و رعایت کنند.
هنگامی که درست (true) باشد، دسترسی به شبکه را در زمان فراخوانی اسکریپت‌های ساخت mkosi.build فعال می‌کند. به‌طور پیش‌فرض، اسکریپت‌های ساخت در حالتی اجرا می‌شوند که شبکه غیرفعال است. متغیر محیطی $WITH_NETWORK به اسکریپت‌های ساخت mkosi.build منتقل می‌شود که نشان می‌دهد ساخت با دسترسی به شبکه انجام می‌شود یا بدون آن.
یک پروکسی را برای استفاده در همهٔ اتصالات شبکهٔ خروجی پیکربندی می‌کند. ابزارهای مختلفی که mkosi فراخوانی می‌کند و پروکسی برای آن‌ها قابل پیکربندی است، برای استفاده از این پروکسی تنظیم می‌شوند. همچنین mkosi متغیرهای محیطی استاندارد مختلفی را برای تعیین پروکسیِ برنامه‌هایی که ممکن است به دسترسی اینترنت نیاز داشته باشند، تنظیم می‌نماید.
نام‌های میزبانی را پیکربندی می‌کند که درخواست‌های مربوط به آن‌ها نباید از پروکسی عبور کنند. فهرستی جداشده با کاما از نام‌های میزبان را می‌گیرد.
فایلی شامل گواهی‌های مورد استفاده برای اعتبارسنجی پروکسی را مشخص می‌کند. پیش‌فرض آن مخزن گواهی‌های سراسری سیستم است.
در حال حاضر، تنظیم گواهی همتای پروکسی تنها زمانی پشتیبانی می‌شود که از dnf یا dnf5 برای ساخت تصویر استفاده شود.
فایلی حاوی گواهیِ مورد استفاده برای احراز هویت کلاینت در پروکسی را تنظیم می‌کند.
در حال حاضر، تنظیم گواهی کلاینت پروکسی تنها زمانی پشتیبانی می‌شود که از dnf یا dnf5 برای ساخت تصویر استفاده شود.
فایلی حاوی کلید خصوصیِ مورد استفاده برای احراز هویت کلاینت در پروکسی را تنظیم می‌کند. در صورت ارائه شدن گواهی کلاینت پروکسی، پیش‌فرض روی آن قرار می‌گیرد.
در حال حاضر، تنظیم کلید کلاینت پروکسی تنها زمانی پشتیبانی می‌شود که از dnf یا dnf5 برای ساخت تصویر استفاده شود.
اگر یکی از اسکریپت‌های قلاب (بخش SCRIPTS را ببینید) به عنوان قابل‌اجرا علامت‌گذاری نشده باشد، به جای خطا دادنِ مستقیم، تلاش می‌کند با chmod آن را قابل‌اجرا کند. پیش‌فرض بر روی no است.
اگر فعال باشد، تصاویر دایرکتوری روی دیسک به جای UID کاربر، تحت مالکیت محدودهٔ UID بیگانه قرار خواهند گرفت.
فعال کردن این گزینه برای استفاده از تصاویر دایرکتوری همراه با دستورهای mkosi shell، mkosi boot و mkosi vm الزامی است. برای استفاده از این گزینه، نگارش ۲۶۰ یا جدیدترِ ابزارهای systemd-nsresourced و systemd-mountfsd روی میزبان مورد نیاز است.
یک فایل تنظیمات .nspawn را برای systemd-nspawn مشخص می‌کند تا در فعل‌های boot و shell استفاده شده و در کنار فایل ایمیج تولیدشده قرار گیرد. این گزینه برای پیکربندی محیط systemd-nspawn هنگام اجرای ایمیج کاربرد دارد. اگر این تنظیم استفاده نشود اما فایل mkosi.nspawn در دایرکتوری محلی یافت شود، به‌طور خودکار برای این منظور به کار می‌رود.
پایشگر ماشین مجازی مورد استفاده را پیکربندی می‌کند. یکی از مقادیر qemu یا vmspawn را می‌پذیرد. پیش‌فرض qemu است.
هنگامی که روی qemu تنظیم شود، ایمیج با qemu بوت می‌شود. بیشتر قالب‌های خروجی را می‌توان در qemu بوت کرد. هر آرگومانی که پس از فعل مشخص شود به فراخوانی qemu الحاق شده و به عنوان آرگومان‌های اضافی خط فرمان qemu تفسیر می‌شود. هنگامی که روی vmspawn تنظیم شود، از systemd-vmspawn برای راه‌اندازی ایمیج استفاده می‌شود؛ vmspawn فقط از ایمیج‌های نوع دیسک و دایرکتوری پشتیبانی می‌کند. هر آرگومانی که پس از فعل مشخص شود به فراخوانی systemd-vmspawn پیوست شده و به عنوان گزینه‌های اضافی vmspawn و آرگومان‌های اضافی خط فرمان کرنل تفسیر می‌گردد.
نحوه راه‌اندازی کنسول ماشین مجازی را پیکربندی می‌کند. یکی از مقادیر interactive، read-only، native، gui یا headless را می‌پذیرد. پیش‌فرض interactive است. مقدار interactive یک رابط ترمینال تعاملی با ماشین مجازی فراهم می‌کند. مقدار read-only مشابه است، اما کاملاً فقط‌خواندنی است؛ یعنی هیچ ورودی‌ای از سمت کاربر نمی‌پذیرد. مقدار native نیز یک رابط مبتنی بر TTY ارائه می‌دهد، اما از پیاده‌سازی بومی qemu استفاده می‌کند (به این معنی که مانیتور qemu در دسترس است). مقدار gui رابط کاربری گرافیکی qemu را نشان می‌دهد. مقدار headless ماشین مجازی را بدون اتصال هیچ کنسولی اجرا می‌کند که برای استفاده‌های کاملاً خودکار یا اسکریپت‌شده ماشین مجازی مفید است. مقدار headless فقط توسط فعل qemu پشتیبانی می‌شود.
تعداد هسته‌های CPU اختصاص‌یافته به سیستم‌عامل مهمان را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند. پیش‌فرض 2 است.
هنگامی که روی 0 تنظیم شود، تعداد هسته‌های CPU در دسترس فرایند mkosi استفاده خواهد شد.
میزان حافظه RAM اختصاص‌یافته به مهمان را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند. پیش‌فرض 2G است.
حداکثر مقدار حافظه‌ای را که مهمان می‌تواند در مجموع مستقر کند (RAM + دستگاه‌های حافظه اتصال‌گرم) پیکربندی می‌کند. پیش‌فرض برابر با میزان RAM پیکربندی‌شده است.
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی از شتاب‌دهنده KVM استفاده شود یا خیر. یک مقدار بولی یا auto می‌پذیرد. پیش‌فرض auto است.
فعال بودن دستگاه‌های CXL را برای یک ماشین معین پیکربندی می‌کند. تنها در صورتی معتبر است که معماری از cxl پشتیبانی کند. یک مقدار بولی می‌پذیرد. پیش‌فرض false است.
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی یک vsock تدارک دیده شود یا خیر. یک مقدار بولی یا auto می‌پذیرد. پیش‌فرض auto است.
شناسه اتصال vsock مورد استفاده هنگام بوت کردن ماشین مجازی را پیکربندی می‌کند. عددی در بازه [3, 0xFFFFFFFF) یا hash یا auto را می‌پذیرد. پیش‌فرض auto است. هنگامی که روی hash تنظیم شود، شناسه اتصال از مسیر کامل به ایمیج مشتق می‌شود. هنگامی که روی auto تنظیم شود، mkosi به‌طور خودکار برای یافتن یک شناسه اتصال آزاد تلاش خواهد کرد. در غیر این صورت، عدد ارائه‌شده عینا استفاده خواهد شد.
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی از یک TPM مجازی استفاده شود یا خیر. یک مقدار بولی یا auto می‌پذیرد. پیش‌فرض auto است.
تعیین می‌کند که آیا هنگام بوت کردن ماشین مجازی، ایمیج به عنوان یک دستگاه جداشدنی متصل شود یا خیر. یک مقدار بولی می‌پذیرد. پیش‌فرض no است. در صورت فعال بودن، دیسک ریشه همواره بدون در نظر گرفتن تنظیم DiskType= به عنوان یک دستگاه SCSI متصل می‌شود.
نوع دیسک مورد استفاده برای دیسک ریشه را هنگام بوت کردن ماشین مجازی پیکربندی می‌کند. یکی از مقادیر virtio-blk، virtio-scsi، nvme یا scsi-cd را می‌پذیرد. پیش‌فرض virtio-blk است. از scsi-cd برای اتصال ایمیج به عنوان درایو CD-ROM استفاده کنید که برای بوت کردن ایمیج‌های ISO مبتنی بر El Torito مفید است.
سفت‌افزار ماشین مجازی مورد استفاده را پیکربندی می‌کند. یکی از مقادیر uefi، uefi-secure-boot، linux، linux-noinitrd یا auto را می‌پذیرد. پیش‌فرض auto است. هنگامی که روی uefi تنظیم شود، از سفت‌افزار OVMF بدون پشتیبانی از بوت امن استفاده می‌شود. هنگامی که روی uefi-secure-boot تنظیم شود، از سفت‌افزار OVMF با پشتیبانی از بوت امن استفاده می‌شود. هنگامی که روی linux تنظیم شود، از بوت مستقیم کرنل استفاده می‌گردد. برای جزئیات بیشتر درباره اینکه کدام ایمیج کرنل در بوت مستقیم کرنل استفاده می‌شود، گزینه Linux= را ببینید. مقدار linux-noinitrd کاملاً مشابه linux است جز اینکه هیچ initrdای استفاده نمی‌شود. هنگامی که روی auto تنظیم شود، در صورت امکان از uefi-secure-boot و در غیر این صورت از linux استفاده می‌شود.
مسیر فایل متغیرهای سفت‌افزار ماشین مجازی مورد استفاده را پیکربندی می‌کند. در حال حاضر، این گزینه فقط هنگامی در نظر گرفته می‌شود که از سفت‌افزار uefi یا uefi-secure-boot استفاده شود. در صورت عدم تعیین، mkosi فایل متغیرهای پیش‌فرض را جستجو کرده و به جای آن استفاده می‌کند.
هنگامی که روی microsoft تنظیم شود، از فایل متغیرهای سفت‌افزاری که گواهی‌های بوت امن مایکروسافت از قبل در آن ثبت شده است استفاده خواهد شد. هنگامی که روی microsoft-mok تنظیم شود، فایل متغیرهای سفت‌افزاری که گواهی‌های بوت امن مایکروسافت از قبل در آن ثبت شده است، با یک متغیر MokList حاوی گواهی بوت امن از SecureBootCertificate= گسترش می‌یابد. این مورد برای استفاده همراه با باینری‌های shim امضاشده توسط توزیع و باینری‌های EFI امضاشده محلی در نظر گرفته شده است. هنگامی که روی custom تنظیم شود، گواهی بوت امن از SecureBootCertificate= درون فایل متغیرهای سفت‌افزار پیش‌فرض ثبت خواهد شد. ابزار virt-fw-vars از پروژه virt-firmware می‌تواند برای سفارشی‌سازی فایل‌های متغیر OVMF استفاده شود.
ایمیج کرنل مورد استفاده برای بوت مستقیم کرنل با qemu را تعیین می‌کند. در صورت عدم تعیین، mkosi از کرنل ارائه‌شده از طریق خط فرمان (گزینه -kernel) یا جدیدترین کرنل نصب‌شده درون ایمیج استفاده خواهد کرد (یا اگر هیچ کرنلی در ایمیج نصب نشده باشد با خطا متوقف می‌شود).
توجه داشته باشید که هنگام استفاده از قالب خروجی cpio، صرف‌نظر از سفت‌افزار پیکربندی‌شده، از بوت مستقیم کرنل استفاده می‌شود. بسته به سفت‌افزار پیکربندی‌شده، ممکن است qemu خودش کرنل را بوت کند یا با استفاده از سفت‌افزار پیکربندی‌شده آن را بالا بیاورد. این تنظیم می‌تواند شامل هر دو نوع مشخصه‌گرهای معمولی (بخش Specifiers را ببینید) و مشخصه‌گرهای تأخیری ویژه باشد که به جای زمان پردازش پیکربندی، پس از اتمام پردازش پیکربندی بسط داده می‌شوند و در زیر شرح داده شده‌اند. مشخصه‌گرهای زیر ممکن است استفاده شوند:
مشخصه‌گر مقدار
&& نویسه &
&b پوشه نهایی ساخت (شامل زیرپوشه)
یک درایو اضافه می‌کند. رشته‌ای جداشده با دونقطه به قالب <id>:<size>[:<directory>[:<options>[:<file-id>[:<flags>]]]] می‌پذیرد. پارامتر id شناسه اختصاص‌یافته به درایو را مشخص می‌کند. این مقدار می‌تواند به عنوان ویژگی drive= در دستگاه‌های مختلف qemu استفاده شود. پارامتر size اندازه درایو را مشخص می‌کند. این گزینه اندازه را بر حسب بایت می‌گیرد. علاوه‌بر این، پسوندهای K، M و G می‌توانند به ترتیب برای تعیین اندازه به کیلوبایت، مگابایت و گیگابایت استفاده شوند. پارامتر directory به‌طور اختیاری دایرکتوری‌ای را که فایل پشتیبان درایو در آن ایجاد می‌شود مشخص می‌کند. در صورت عدم تنظیم، فایل زیر /var/tmp ایجاد خواهد شد. پارامتر options به‌طور اختیاری خصوصیات اضافی جداشده با کاما را مشخص می‌کند که عیناً به گزینه -blockdev در qemu ارسال می‌شوند. پارامتر file-id شناسه فایل پشتیبان درایو را مشخص می‌کند. در صورت عدم تنظیم، مقدار پیش‌فرض آن همان شناسه درایو خواهد بود. درایوهایی با شناسه فایل یکسان از فایل پشتیبان مشترک استفاده خواهند کرد. دایرکتوری و اندازه فایل بر اساس نخستین درایو با شناسه فایل مربوطه تعیین خواهد شد. پارامتر flags فهرستی جداشده با کاما از پرچم‌های درایو می‌گیرد که در حال حاضر تنها از persist پشتیبانی می‌کند. پرچم persist تعیین می‌کند که آیا درایو بین دفعات فراخوانی qemu باقی بماند یا خیر. فایل‌های پشتیبان درایوها با الگوی /<directory>/mkosi-drive-<machine-or-image-name>-<file-id> ایجاد خواهند شد. می‌توانید با تنظیم مقادیر روی رشته خالی از آن‌ها صرف‌نظر کنید؛ برای مثال تعیین myfs:1G::::persist یک درایو ماندگار تحت /var/tmp/mkosi-drive-main-myfs ایجاد خواهد کرد.
نمونه استفاده:.IP 
[Runtime]
Drives=btrfs:10G
       ext4:20G
QemuArgs=-device nvme,serial=btrfs,drive=btrfs
         -device nvme,serial=ext4,drive=ext4
فهرستی جداشده با فاصله از آرگومان‌های اضافی برای ارسال هنگام فراخوانی qemu.
هنگامی که به همراه زیردستورهای shell، boot یا vm استفاده شود، این گزینه دستور مشخص‌شده را روی یک تصویر لحظه‌ای (snapshot) موقت از تصویر خروجی اجرا می‌کند که بلافاصله پس از خاتمهٔ کانتینر حذف می‌شود. گرفتن تصویر لحظه‌ای موقت روی سیستم‌فایل‌هایی که به‌طور بومی از reflink پشتیبانی می‌کنند (btrfs یا xfs)، نسبت به سیستم‌فایل‌های سنتی‌تر که فاقد این قابلیت هستند (ext4) بسیار کارآمدتر است.
اعتبارنامه‌هایی را تنظیم می‌کند که هنگام استفاده از mkosi shell/boot یا mkosi vm، به‌ترتیب به systemd-nspawn یا ماشین مجازی ارسال می‌شوند. این گزینه فهرستی از مقادیر جداشده با فاصله را می‌پذیرد که می‌توانند جفت‌های key=value یا مسیر فایل باشند. اگر مسیری ارائه شود، در صورتی که فایل باشد، نام اعتبارنامه برابر با نام فایل خواهد بود. اگر فایل قابل اجرا باشد، مقدار اعتبارنامه خروجی حاصل از اجرای فایل خواهد بود. در غیر این صورت، مقدار اعتبارنامه برابر با محتویات فایل خواهد بود. اگر مسیر یک دایرکتوری باشد، همین منطق برای هر فایل درون آن دایرکتوری اعمال می‌شود.
توجه داشته باشید که مقادیر تنها در صورتی به عنوان مسیر در نظر گرفته می‌شوند که حاوی جداکننده (=) نباشند.
ورودی‌های اضافی خط فرمان هسته را تعیین می‌کند که هنگام بوت تصویر در زمان اجرا، به خط فرمان هسته اضافه می‌شوند. هنگام بوت در یک کانتینر، این موارد به عنوان آرگومان‌های اضافی به systemd ارسال می‌شوند. هنگام بوت در یک VM، این موارد از طریق رشتهٔ OEM در SMBIOS با شناسهٔ io.systemd.stub.kernel-cmdline-extra به خط فرمان هسته اضافه می‌گردند. این ورودی‌ها تنها توسط نسخه‌های systemd-boot و systemd-stub برابر یا جدیدتر از v254 شناسایی خواهند شد.
یک جفت مسیر جداشده با دو نقطه (colon) را می‌پذیرد. مسیر اول به دایرکتوری‌ای اشاره دارد که باید در هر ماشین (کانتینر یا VM) راه‌اندازی‌شده توسط mkosi سوار (mount) شود. مسیر دوم به دایرکتوری مقصد درون ماشین اشاره می‌کند. اگر مسیر دوم ارائه نشود، دایرکتوری در /root/src در ماشین سوار می‌شود. اگر مسیر دوم نسبی باشد، نسبت به /root/src در ماشین تفسیر خواهد شد.
به ازای هر دایرکتوری سوارشده، uid و gid کاربری که mkosi را اجرا می‌کند به کاربر root در ماشین نگاشت می‌شود. این بدان معناست که همهٔ فایل‌ها و دایرکتوری‌ها به‌گونه‌ای نمایش داده می‌شوند که گویی متعلق به root در ماشین هستند، و تمام فایل‌ها و دایرکتوری‌های جدیدی که توسط root درون این دایرکتوری‌ها در ماشین ایجاد شوند، در سیستم میزبان متعلق به کاربری خواهند بود که mkosi را اجرا کرده است. توجه داشته باشید که هنگام استفاده از mkosi vm همراه با این ویژگی، باید نسخهٔ v254 یا جدیدتر systemd روی تصویر نصب شده باشد.
در صورت تعیین، هنگام بوت تصاویر دیسک با mkosi boot یا mkosi vm، اندازهٔ آن‌ها به اندازهٔ مشخص‌شده افزایش می‌یابد. یک اندازه را بر حسب بایت می‌پذیرد. علاوه بر این، پسوندهای K، M و G می‌توانند به‌ترتیب برای مشخص کردن اندازه بر حسب کیلوبایت، مگابایت و گیگابایت استفاده شوند.
یکی از مقادیر user، interface یا none را می‌پذیرد. پیش‌فرض آن user است. وضعیت شبکه‌بندی برای راه‌اندازی هنگام بوت تصویر را مشخص می‌کند. مقدار user شبکهٔ حالت کاربر (usermode networking) را برپا می‌سازد. مقدار interface یک اتصال شبکهٔ مجازی بین میزبان و تصویر برقرار می‌کند. این مورد برای mkosi shell و mkosi boot به یک رابط veth، و برای mkosi vm و mkosi vmspawn به یک رابط tap تبدیل می‌شود.
توجه داشته باشید هنگام استفاده از interface، ابزار mkosi رابط میزبان را به‌طور خودکار پیکربندی نمی‌کند. انتظار می‌رود یک نسخهٔ جدید از systemd-networkd روی میزبان در حال اجرا باشد که رابط پیوند سمت میزبان را به‌طور خودکار پیکربندی نماید.
هنگام استفاده از mkosi boot یا mkosi vm، منابع ساختی که با BuildSources= پیکربندی شده‌اند و دایرکتوری ساخت را (در صورت پیکربندی) در همان مکان‌هایی درون /work سوار می‌کند که در زمان اجرای اسکریپت ساخت سوار شده بودند.
دایرکتوری خانگی کاربر فعلی را درون کانتینر/vm متصل (bind mount) می‌کند. یک مقدار بولی می‌پذیرد. به‌طور پیش‌فرض غیرفعال است.
مسیر کلید خصوصی X.509 با قالب PEM برای استفاده در اتصال به ماشین مجازی راه‌اندازی‌شده با mkosi vm و ساخته‌شده با گزینهٔ فعال Ssh= (یا با systemd-ssh-generator نصب‌شده) از طریق دستور mkosi ssh. اگر پیکربندی نشده باشد و فایل mkosi.key در دایرکتوری کاری موجود باشد، به‌طور خودکار برای این منظور استفاده خواهد شد. برای ایجاد خودکار یک کلید در mkosi.key، دستور mkosi genkey را اجرا کنید.
مسیر گواهی X.509 با قالب PEM برای فراهم‌سازی به عنوان کلید عمومی SSH در ماشین‌های مجازی راه‌اندازی‌شده با mkosi vm. اگر پیکربندی نشده باشد و فایل mkosi.crt در دایرکتوری کاری موجود باشد، به‌طور خودکار برای این منظور استفاده خواهد شد. برای ایجاد خودکار یک گواهی در mkosi.crt، دستور mkosi genkey را اجرا کنید.
نام ماشین مورد استفاده هنگام بوت تصویر را مشخص می‌کند. همچنین می‌تواند برای اشاره به یک تصویر مشخص هنگام برقراری اتصال SSH به آن تصویر استفاده شود (مانند mkosi --image=myimage ssh).
توجه داشته باشید که برای راه‌اندازی چندین نمونه از یک تصویر یکسان، باید گزینهٔ Ephemeral= فعال باشد. پیش‌فرض آن نام دایرکتوری کاری فعلی است.
یک مقدار بولی یا auto می‌پذیرد. مشخص می‌کند که آیا ماشین مجازی/کانتینر در systemd-machined ثبت شود یا خیر. در صورت فعال بودن، اگر mkosi نتواند ماشین مجازی/کانتینر را در systemd-machined ثبت کند، با خطا متوقف می‌شود. در صورت غیرفعال بودن، mkosi ماشین مجازی/کانتینر را در systemd-machined ثبت نخواهد کرد. اگر روی auto تنظیم شود، در صورت در دسترس بودن systemd-machined، ابزار mkosi ماشین مجازی/کانتینر را ثبت می‌کند. پیش‌فرض آن auto است.
توجه داشته باشید که mkosi تلاش می‌کند ماشین را در نشست کاربری (user session) در systemd-machined ثبت نماید. برای در دسترس بودن systemd-machined در نشست‌های کاربری، نسخهٔ v259 یا جدیدتر systemd مورد نیاز است.
مسیری را مشخص می‌کند که گزارش‌های journal کانتینرها و ماشین‌های مجازی باید به آن بازفرستاده شوند. اگر مسیر دارای پسوند .journal باشد، به عنوان فایلی تفسیر می‌شود که journal باید درون آن نوشته شود. در غیر این صورت، مسیر به عنوان دایرکتوری‌ای تفسیر می‌شود که journal باید در آن نوشته شود.
توجه داشته باشید برای کارکرد قابلیت بازفرستادن لاگ، به نسخهٔ v256 یا جدیدتر systemd در ماشین مجازی نیاز است. همچنین توجه داشته باشید اگر مسیری با پسوند .journal داده شود، اندازهٔ journal به 4G محدود خواهد بود. اگر بار کاری شما بیش از 4G دادهٔ journal تولید می‌کند، به جای فایل، یک دایرکتوری خروجی پیکربندی کنید.
مشخص می‌کند که آیا دستور serve باید systemd-storagetm را برای سرویس‌دهی تصاویر دیسک روی پروتکل NVME-TCP راه‌اندازی کند یا خیر. یک مقدار بولی یا auto می‌پذیرد. اگر فعال باشد، systemd-storagetm همیشه اجرا می‌شود و در صورت عدم امکان راه‌اندازی آن، mkosi با خطا مواجه خواهد شد. اگر غیرفعال باشد، systemd-storagetm هرگز راه‌اندازی نمی‌شود. اگر روی auto تنظیم شود، در صورتی که یک تصویر دیسک در حال ساخت باشد، فایل اجرایی systemd-storagetm پیدا شود و mkosi serve توسط کاربر root اجرا گردد، سرویس systemd-storagetm راه‌اندازی خواهد شد.
مسیر دایرکتوری حاوی فایل‌های تعاریف انتقال systemd-sysupdate که توسط mkosi sysupdate استفاده می‌شوند. اگر mkosi.sysupdate/ در دایرکتوری محلی وجود داشته باشد، برای همین منظور استفاده خواهد شد.
توجه داشته باشید که mkosi sysupdate دستور systemd-sysupdate را به‌گونه‌ای فراخوانی می‌کند که گزینهٔ --transfer-source= روی دایرکتوری خروجی mkosi تنظیم شده است. برای بهره‌گیری از این امکان در یک فایل تعریف انتقال، PathRelativeTo=explicit را تنظیم کنید تا پیکربندی Path= برای مبدا انتقال، نسبت به دایرکتوری خروجی mkosi تفسیر شود. به‌طور کلی، تنظیم PathRelativeTo=explicit و Path=/ برای مبدا انتقال کافی است تا الگوی تطبیق نسبت به دایرکتوری خروجی mkosi تفسیر گردد.
با پروفایل‌های پیکربندی‌شده مطابقت می‌دهد.
با توزیع پیکربندی‌شده مطابقت می‌دهد.
با نسخهٔ انتشار (Release) توزیع پیکربندی‌شده مطابقت می‌دهد. اگر از این شرط استفاده شود و هنوز هیچ توزیعی به‌طور صریح پیکربندی نشده باشد، توزیع و نسخهٔ انتشار میزبان استفاده می‌شوند.
با معماری پیکربندی‌شده مطابقت می‌دهد. اگر از این شرط استفاده شود و هنوز هیچ معماری‌ای به‌طور صریح پیکربندی نشده باشد، معماری میزبان استفاده می‌شود.
می‌توان از Architecture=uefi برای مطابقت با هر معماری‌ای که از UEFI پشتیبانی می‌کند استفاده کرد.
با مخازن فعال‌شده از طریق تنظیم Repositories= مطابقت می‌دهد. تنها یک نام مخزن واحد می‌پذیرد.
با مقدار پیکربندی‌شده برای OutputFormat= مطابقت می‌دهد.
این شرط در صورتی برآورده می‌شود که مسیر داده‌شده وجود داشته باشد. مسیرهای نسبی، نسبت به دایرکتوری والد فایل پیکربندی‌ای که شرط از آن خوانده می‌شود، تفسیر می‌شوند.
با شناسهٔ تصویر (Image ID) پیکربندی‌شده مطابقت می‌دهد و از الگوهای glob پشتیبانی می‌کند. اگر از این شرط استفاده شود و هنوز شناسهٔ تصویری به‌طور صریح پیکربندی نشده باشد، این شرط ناموفق خواهد بود.
با نسخهٔ تصویر پیکربندی‌شده مطابقت می‌دهد. برای مقایسه‌های نگارشی پیشرفته طبق مشخصات قالب نگارش گروه UAPI، می‌توان نسخه‌های تصویر را با عملگرهای ==، !=، >=، <=، < و > پیشوندگذاری کرد. اگر هیچ عملگری مشخص نشود، به‌طور پیش‌فرض عملگر برابری در نظر گرفته می‌شود. اگر از این شرط استفاده شود و هنوز نسخهٔ تصویری به‌طور صریح پیکربندی نشده باشد، این شرط ناموفق خواهد بود.
با مقدار پیکربندی‌شده برای قابلیت Bootable= مطابقت می‌دهد. یک مقدار بولی (boolean) یا auto می‌پذیرد.
با مقدار پیکربندی‌شده برای Bootloader= مطابقت می‌دهد.
با مقدار پیکربندی‌شده برای گزینهٔ Format= مطابقت می‌دهد. یک قالب خروجی می‌پذیرد (گزینهٔ Format= را ببینید).
با نسخهٔ systemd روی میزبان (طبق گزارش systemctl --version) مطابقت می‌دهد. برای مقایسه‌های نگارشی پیشرفته طبق مشخصات قالب نگارش گروه UAPI، مقادیر می‌توانند با عملگرهای ==، !=، >=، <=، < و > پیشوندگذاری شوند. اگر هیچ عملگری مشخص نشود، به‌طور پیش‌فرض عملگر برابری در نظر گرفته می‌شود.
یک مسیر مقصد برای منبع ساخت می‌پذیرد (به BuildSources= مراجعه کنید). این تطابق در صورتی برقرار می‌شود که هر یک از منابع ساخت پیکربندی‌شده از این مسیر مقصد استفاده کنند. برای مثال، اگر فایل mkosi.conf شامل موارد زیر باشد:
[Build]
BuildSources=../abc/qed:kernel
و یک فایل drop-in شامل:
[Match]
BuildSources=kernel
فایل drop-in اعمال خواهد شد. هر مسیر مطلقی که به این تنظیم داده شود، نسبت به دایرکتوری کاری فعلی تفسیر می‌شود.
با معماری بومی میزبان مطابقت می‌دهد. برای دیدن فهرست مقادیر ممکن، به تنظیم Architecture= مراجعه کنید.
با توزیع درخت ابزار (tools tree) پیکربندی‌شده مطابقت می‌دهد.
با نسخهٔ انتشار درخت ابزار (tools tree) پیکربندی‌شده مطابقت می‌دهد.
با یک جفت کلید/مقدار خاص پیکربندی‌شده توسط Environment= مطابقت می‌دهد. اگر مقداری ارائه نشود، صرف‌نظر از اینکه مقدار آن چه باشد، وجود کلید داده‌شده در محیط بررسی می‌شود.
با نام تصویر (یا زیرتصویر) فعلی مطابقت می‌دهد. نام یک زیرتصویر، همان نام آن در mkosi.images/ است (بدون پسوند .conf). نام تصویر سطح بالا (top level) برابر با main است. کاربرد اصلی این گزینه، امکان داشتن یک پیکربندی مشترک است که هم توسط تصویر سطح بالا و هم زیرتصاویر قابل استفاده باشد؛ این کار با مشروط کردن تنظیمات سراسری به شرط تطابق Image=main انجام می‌پذیرد.

این جدول نشان می‌دهد که کدام تطبیق‌دهنده‌ها از الگوهای glob و مقایسه‌های پیشرفته پشتیبانی می‌کنند، و در صورت عدم پیکربندی در زمان خوانده شدن فایل پیکربندی، با چه مقدار پیش‌فرضی تطبیق داده می‌شوند:

تطبیق‌دهنده الگوهای Glob مقایسه‌های پیشرفته پیش‌فرض
Profiles= خیر خیر تطابق ناموفق است
Distribution= خیر خیر تطابق با توزیع میزبان
Release= خیر خیر تطابق با نسخهٔ انتشار میزبان
Architecture= خیر خیر تطابق با معماری میزبان
PathExists= خیر خیر نامربوط
ImageId= بله خیر تطابق ناموفق است
ImageVersion= خیر بله تطابق ناموفق است
Bootable= خیر خیر تطابق با قابلیت auto
Format= خیر خیر تطابق با قالب پیش‌فرض
SystemdVersion= خیر بله نامربوط
BuildSources= خیر خیر تطابق ناموفق است
HostArchitecture= خیر خیر نامربوط
ToolsTreeDistribution= خیر خیر تطابق با توزیع جایگزین درخت ابزار (به ToolsTreeDistribution= در [Build] مراجعه کنید)
ToolsTreeRelease= خیر خیر تطابق با نسخهٔ انتشار پیش‌فرض درخت ابزار
Environment= خیر خیر نامربوط
Image= خیر خیر نامربوط
[Include]
Include=, --include=, -I
گنجاندن پیکربندی اضافی از فایل یا دایرکتوری داده‌شده.
پیکربندی اضافی بلافاصله پس از تجزیه این تنظیم اعمال می‌شود، مگر زمانی که در خط فرمان استفاده شود؛ در این صورت، پیکربندی اضافی پس از تجزیه تمام آرگومان‌های خط فرمان اعمال خواهد شد.
توجه داشته باشید که هر مسیر حاوی پیکربندی اضافی، تنها یک بار تجزیه می‌شود، حتی اگر بیش از یک بار با Include= آورده شده باشد.
پیکربندی‌های توکار برای initrd پیش‌فرض، درخت ابزارهای (tools tree) پیش‌فرض، تصویر ماشین مجازی پیش‌فرض و افزونه UKI پیش‌فرضِ mkosi را می‌توان به‌ترتیب با گنجاندن مقادیر لغوی mkosi-initrd، mkosi-tools، mkosi-vm یا mkosi-addon وارد کرد.
نکته: نام‌های گنجاندنی که با هر یک از عبارت‌های تحت‌اللفظی mkosi- یا contrib- آغاز می‌شوند، برای استفاده خودِ mkosi رزرو شده‌اند.
بخش [Config]
Profiles=, --profile=
انتخاب پروفایل‌های مشخص‌شده.
یک پروفایل، یک فایل پیکربندی یا دایرکتوری در دایرکتوری mkosi.profiles/ است.
فایل‌ها و دایرکتوری‌های پیکربندی هر پروفایل پس از تجزیه پیکربندی‌های تکمیلیِ (drop-in) mkosi.conf.d/*.conf گنجانده می‌شوند.
Dependencies=, --dependency=
تصاویری که این تصویر به آن‌ها وابسته است، به‌صورت فهرستی جداشده با کاما مشخص می‌شوند.
تمام تصاویری که در این گزینه پیکربندی شده‌اند پیش از این تصویر ساخته خواهند شد.
هنگامی که این تنظیم برای تصویر «اصلی» (“main”) تعیین شود، مشخص می‌کند که کدام زیرتصویرها باید ساخته شوند.
برای اطلاعات بیشتر بخش BUILDING MULTIPLE IMAGES را ببینید.
MinimumVersion=, --minimum-version=
حداقل نسخه mkosi مورد نیاز برای ساخت این پیکربندی.
اگر چندین بار مشخص شود، بالاترین نسخه تعیین‌شده به کار گرفته می‌شود.
حداقل نسخه را می‌توان با پیشوند commit: به‌صورت یک هش کامیت گیت نیز تعیین کرد؛ در این حالت mkosi باید از داخل یک checkout گیت اجرا شود و هش کامیت گیت مشخص‌شده باید از نیاکان (ancestor) کامیتِ در حال حاضر checkout شده در مخزنی باشد که mkosi از آن اجرا می‌شود.
ConfigureScripts=, --configure-script=
فهرستی جداشده با کاما از مسیرهای فایل‌های اجرایی می‌گیرد که به‌عنوان اسکریپت‌های پیکربندی این تصویر استفاده می‌شوند.
الگوهای سراسری (Glob patterns) پشتیبانی می‌شوند و مسیرهای منطبق، به‌ترتیب الفبا مرتب می‌گردند.
برای اطلاعات بیشتر بخش SCRIPTS را ببینید.
PassEnvironment=, --pass-environment=
فهرستی از نام‌های متغیرهای محیطی که با فاصله از هم جدا شده‌اند می‌گیرد.
هنگام ساخت چندین تصویر، متغیرهای محیطی فهرست‌شده را به‌گونه‌ای به هر زیرتصویر مستقل ارسال می‌کند که گویی تنظیماتی «سراسری» (“universal”) هستند.
برای اطلاعات بیشتر بخش BUILDING MULTIPLE IMAGES را ببینید.
بخش [UKIProfile]
بخش UKIProfile می‌تواند در فایل‌های پیکربندی پروفایل UKI که به تنظیم UnifiedKernelImageProfiles= ارسال می‌شوند، استفاده شود.
تنظیمات زیر را می‌توان در بخش UKIProfile مشخص کرد:
Profile=
محتوای بخش .profile مربوط به پروفایل UKI.
فهرستی از جفت‌های کلید/مقدار جداشده با = می‌گیرد.
کلید ID= حتماً باید مشخص شود.
برای دیدن فهرست کاملی از کلیدهای ممکن، به
https://uapi-group.org/specifications/specs/unified_kernel_image/#multi-profile-ukis
مشخصات UKI
 مراجعه کنید.
Cmdline=
گزینه‌های خط فرمان اضافی هسته برای پروفایل UKI.
فهرستی جداشده با فاصله از آرگومان‌های خط فرمان اضافی هسته می‌گیرد.
توجه داشته باشید که بخش نهایی .cmdline ترکیبی از بخش پایه .cmdline و آرگومان‌های خط فرمان اضافی هسته خواهد بود که با این تنظیم تعیین شده‌اند.
SignExpectedPcr=
امضای اندازه‌گیری‌های مورد انتظار PCR برای این پروفایل UKI.
یک مقدار بولیَن (boolean) می‌گیرد.
به‌طور پیش‌فرض فعال است.
مشخص‌کننده‌ها (Specifiers)
مقدار فعلی تنظیمات مختلف را می‌توان هنگام تجزیه فایل‌های پیکربندی با استفاده از مشخص‌کننده‌ها دریافت کرد.
برای نوشتن یک نویسه لغوی % در فایل پیکربندی بدون اینکه به‌عنوان یک مشخص‌کننده تفسیر شود، از %% استفاده کنید.
مشخص‌کننده‌های زیر پشتیبانی می‌شوند:
tab( );
l l.
تنظیم مشخص‌کننده
Distribution= %d
Release= %r
Architecture= %a
Format= %t
Output= %o
OutputDirectory= %O
ImageId= %i
ImageVersion= %v

همچنین مشخص‌کننده‌هایی وجود دارند که مستقل از تنظیمات هستند:

مشخص‌کننده مقدار
%C دایرکتوری والد فایل پیکربندی فعلی
%P دایرکتوری کاری فعلی
%D دایرکتوری‌ای که mkosi در آن فراخوانی شده است
%I نام زیرتصویر فعلی در mkosi.images

در نهایت، مشخص‌کننده‌هایی وجود دارند که از یک تنظیم مشتق می‌شوند:

مشخص‌کننده مقدار
%F سیستم‌فایل پیش‌فرض توزیع پیکربندی‌شده

توجه داشته باشید که دایرکتوری کاری فعلی با تجزیه پیکربندی توسط mkosi تغییر می‌کند. به‌طور مشخص، هر بار که mkosi دایرکتوری حاوی یک فایل mkosi.conf را تجزیه می‌کند، دایرکتوری کاری خود را به آن دایرکتوری تغییر می‌دهد..PP توجه داشته باشید دایرکتوری‌ای که mkosi در آن فراخوانی شده است، تحت تأثیر آرگومان خط فرمان --directory= قرار می‌گیرد.

جدول زیر مقادیر نمونه را برای مشخص‌کننده‌های دایرکتوری فهرست‌شده در بالا نشان می‌دهد:

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

می‌توان ایمیج‌هایی حاوی نصب‌هایی از توزیع‌های زیر ایجاد کرد:

  • Fedora Linux
  • Debian
  • Kali Linux
  • Ubuntu
  • Arch Linux
  • openSUSE
  • Mageia
  • CentOS
  • RHEL
  • RHEL UBI
  • OpenMandriva
  • Rocky Linux
  • Alma Linux
  • Azure Linux
  • postmarketOS
  • None (نیازمند این است که کاربر یک rootfs از پیش ساخته‌شده فراهم کند)

از نظر تئوری، تا زمانی که ابزارهای لازم در دسترس باشند، هر توزیعی می‌تواند روی سیستم میزبان برای ساخت ایمیج‌های حاوی هر توزیع دیگری استفاده شود. به‌طور مشخص، هر توزیعی که apt را بسته‌بندی می‌کند می‌تواند برای ساخت ایمیج‌های Debian، Kali یا Ubuntu به کار رود. هر توزیعی که dnf را بسته‌بندی می‌کند می‌تواند برای ساخت ایمیج‌ها برای هر یک از توزیع‌های مبتنی بر RPM استفاده شود. هر توزیعی که pacman را بسته‌بندی می‌کند می‌تواند برای ساخت ایمیج‌های Arch Linux به کار رود. هر توزیعی که zypper را بسته‌بندی می‌کند می‌تواند برای ساخت ایمیج‌های openSUSE استفاده شود. سایر توزیع‌ها و ابزارهای خودکارسازی ساخت برای سیستم‌های لینوکس تعبیه‌شده (embedded) مانند Buildroot، OpenEmbedded و Yocto Project می‌توانند با انتخاب توزیع custom، و پر کردن rootfs از طریق ترکیبی از درخت‌های پایه، درخت‌های اسکلت و اسکریپت‌های آماده‌سازی استفاده شوند.

در حال حاضر، Fedora Linux از زمان Fedora 28 تمام ابزارهای مربوطه را بسته‌بندی کرده است.

توجه داشته باشید هنگامی که از یک مخزن آینه‌ای سفارشی استفاده نمی‌شود، ایمیج‌های RHEL تنها می‌توانند از یک سیستم میزبان دارای اشتراک RHEL (که مثلاً با استفاده از subscription-manager برقرار شده است) ساخته شوند.

جریان اجرای mkosi build. مقادیر/فراخوانی‌های پیش‌فرض در پرانتز نشان داده شده‌اند. هنگام ساخت با --incremental=yes، در صورتی که حافظه پنهان (کَش) نصب توزیع از قبل وجود نداشته باشد، mkosi آن را ایجاد می‌کند و در اجراهای متوالی، نصب توزیع را با داده‌های نسخه کش‌شده جایگزین می‌نماید.

1.
تجزیه گزینه‌های خط فرمان (CLI)
2.
تجزیه فایل‌های پیکربندی
3.
اجرای اسکریپت‌های پیکربندی (mkosi.configure)
4.
اگر به عنوان root اجرا نمی‌شود، لغو اشتراک فضای نام کاربری (unshare user namespace) و نگاشت محدوده subuid پیکربندی‌شده در /etc/subuid و /etc/subgid به درون آن.
5.
لغو اشتراک فضای نام سوار کردن (unshare mount namespace)
6.
سوار کردن مجدد دایرکتوری‌های زیر به صورت فقط‌خواندنی در صورت وجود:
  • /usr
  • /etc
  • /opt
  • /srv
  • /boot
  • /efi
  • /media
  • /mnt

سپس، برای هر ایمیج، مراحل زیر اجرا می‌شوند:

1.
کپی درخت‌های محیط ایزوله (sandbox trees) به درون فضای کاری
2.
همگام‌سازی متادیتای مخزن مدیر بسته
3.
اجرای اسکریپت‌های همگام‌سازی (mkosi.sync)
4.
کپی درخت‌های پایه (--base-tree=) به درون ایمیج
5.
استفاده مجدد از ایمیج کش‌شده در صورت در دسترس بودن
6.
کپی یک رونوشت (snapshot) از متادیتای مخزن مدیر بسته به درون ایمیج
7.
کپی درخت‌های اسکلت (mkosi.skeleton) به درون ایمیج
8.
نصب توزیع و بسته‌ها درون ایمیج
9.
اجرای اسکریپت‌های آماده‌سازی روی ایمیج با آرگومان final (mkosi.prepare)
10.
نصب بسته‌های ساخت در لایه همپوشانی (overlay) در صورت پیکربندی هرگونه اسکریپت ساخت
11.
اجرای اسکریپت‌های آماده‌سازی روی overlay با آرگومان build در صورت پیکربندی هرگونه اسکریپت ساخت (mkosi.prepare)
12.
کش کردن ایمیج در صورت پیکربندی (--incremental=yes)
13.
اجرای اسکریپت‌های ساخت روی ایمیج + overlay در صورت پیکربندی هرگونه اسکریپت ساخت (mkosi.build)
14.
نهایی‌سازی ساخت در صورتی که قالب خروجی none پیکربندی شده باشد
15.
کپی خروجی‌های اسکریپت‌های ساخت به درون ایمیج
16.
کپی درخت‌های اضافی به درون ایمیج (mkosi.extra)
17.
اجرای اسکریپت‌های پس از نصب (mkosi.postinst)
18.
نوشتن فایل‌های پیکربندی مورد نیاز برای Ssh=، Autologin= و MakeInitrd=
19.
نصب systemd-boot و پیکربندی راه‌اندازی امن در صورت پیکربندی (--secure-boot=yes)
20.
اجرای systemd-sysusers
21.
اجرای systemd-tmpfiles
22.
اجرای systemctl preset-all
23.
اجرای depmod
24.
اجرای systemd-firstboot.IP "25." 4 اجرای systemd-hwdb
26.
حذف بسته‌ها و فایل‌ها (RemovePackages=، RemoveFiles=)
27.
اجرای برچسب‌گذاری مجدد SELinux در صورت نصب بودن یک شیوه‌نامهٔ SELinux
28.
اجرای اسکریپت‌های نهایی‌سازی (mkosi.finalize)
29.
تولید تصویر یکپارچهٔ هسته (unified kernel image) در صورت پیکربندی شدن
30.
تولید قالب خروجی نهایی
31.
اجرای اسکریپت‌های پس از خروجی (mkosi.postoutput)

برای امکان‌پذیر ساختن سفارشی‌سازی‌هایی در تصویر که با ویژگی‌های توکار mkosi قابل پیاده‌سازی نیستند، mkosi از اجرای اسکریپت‌ها در نقاط مختلفی از فرایند ساخت تصویر پشتیبانی می‌کند که می‌توانند تصویر را بر اساس نیاز سفارشی‌سازی کنند. اسکریپت‌ها روی سیستم میزبان به عنوان ریشه (خواه ریشهٔ واقعی یا ریشه در فضای نام کاربری که هنگام اجرای بدون‌امتیاز توسط mkosi ایجاد شده است) همراه با یک محیط سفارشی‌شده اجرا می‌شوند تا تغییر تصویر را ساده‌تر کنند. برای هر اسکریپت، سورس‌های ساخت پیکربندی‌شده (BuildSources=) پیش از اجرای اسکریپت در دایرکتوری کاری فعلی، بر روی دایرکتوری کاری فعلی سوار (mount) می‌شوند. $SRCDIR طوری تنظیم می‌شود که به دایرکتوری کاری فعلی اشاره کند. اسکریپت‌های زیر پشتیبانی می‌شوند:

  • اگر mkosi.configure (ConfigureScripts=) وجود داشته باشد، پیش از ساخت تصویر اجرا می‌شود. از این اسکریپت می‌توان برای اصلاح پویای پیکربندی استفاده کرد. این اسکریپت پیکربندی را به صورت سریالی‌شده در قالب JSON روی stdin دریافت می‌کند و باید پیکربندی اصلاح‌شده را به صورت سریالی‌شده در قالب JSON روی stdout تحویل دهد. توجه داشته باشید که این اسکریپت تنها هنگام ساخت یا بوت کردن تصویر (افعال build، vm، boot و shell) اجرا می‌شود. اگر یک درخت ابزار (tools tree) پیش‌فرض پیکربندی شده باشد، پیش از اجرای اسکریپت‌های پیکربندی ساخته خواهد شد و اسکریپت‌های پیکربندی با در دسترس بودن درخت ابزار اجرا خواهند شد. این همچنین بدان معناست که تغییرات اعمال‌شده توسط اسکریپت‌های پیکربندی در خروجی summary قابل مشاهده نخواهد بود.
  • اگر mkosi.sync (SyncScripts=) وجود داشته باشد، پیش از ساخته شدن تصویر اجرا می‌شود. این اسکریپت ممکن است برای به‌روزرسانی سورس‌های مختلفی که برای ساخت تصویر استفاده می‌شوند به کار رود. یک مورد کاربرد، اجرای git pull روی مخازن مختلف سورس پیش از ساخت تصویر است. به طور مشخص، تنظیم BuildSourcesEphemeral= بر اسکریپت‌های همگام‌سازی اعمال نمی‌شود، بدین معنی که اسکریپت‌های همگام‌سازی می‌توانند برای به‌روزرسانی سورس‌های ساخت استفاده شوند حتی اگر BuildSourcesEphemeral= فعال باشد.
  • اگر mkosi.prepare (PrepareScripts=) وجود داشته باشد، ابتدا درست پس از نصب بسته‌های نرم‌افزاری با آرگومان final فراخوانی می‌شود. بار دوم درست پس از نصب بسته‌های ساخت و سوار شدن overlay ساخت بر روی دایرکتوری ریشهٔ تصویر، با پارامتر خط فرمان build فراخوانی می‌شود. این اسکریپت به شبکه دسترسی دارد و می‌توان از آن برای نصب بسته‌ها از منابعی غیر از مدیر بستهٔ توزیع (مانند pip، npm و ...)، پس از نصب همهٔ بسته‌های نرم‌افزاری اما پیش از ذخیره در حافظهٔ پنهان (cache) تصویر (در صورت فعال بودن حالت افزایشی) استفاده کرد. برخلاف یک نصب همه‌منظوره، نصب بسته‌ها بر روی سیستم (pip install، npm install -g) به جای خودِ $SRCDIR ایمن است؛ چرا که تصویر ساخت تنها برای یک پروژهٔ مشخص استفاده می‌شود و می‌تواند به راحتی دور انداخته شده و مجدداً ساخته شود، بنابراین هیچ خطری برای تداخل وابستگی‌ها یا آلوده کردن سیستم میزبان وجود ندارد.
  • اگر mkosi.build (BuildScripts=) وجود داشته باشد، در حالی که overlay ساخت بر روی دایرکتوری ریشهٔ تصویر سوار شده است اجرا می‌شود. هنگام اجرای اسکریپت ساخت، $DESTDIR به دایرکتوری‌ای اشاره می‌کند که اسکریپت باید هر فایل تولیدشده‌ای را که می‌خواهد در نهایت در تصویر قرار گیرد، در آن قرار دهد. توجه داشته باشید که سیستم‌های ساخت مبتنی بر make-، automake- و meson- عموماً به $DESTDIR پایبند هستند، که این امر ساخت درخت‌های سورس را از طریق اسکریپت ساخت بسیار طبیعی می‌سازد. پس از اجرای اسکریپت ساخت، محتویات $DESTDIR درون تصویر کپی می‌شوند.
  • اگر mkosi.postinst (PostInstallationScripts=) وجود داشته باشد، پس از نصب درخت ساخت (اختیاری) و درخت‌های اضافی اجرا می‌شود. از این اسکریپت می‌توان برای تغییر تصاویر بدون هیچ محدودیتی، پس از نصب همهٔ بسته‌های نرم‌افزاری و سورس‌های ساخته‌شده استفاده کرد.
  • اگر mkosi.finalize (FinalizeScripts=) وجود داشته باشد، به عنوان آخرین گام از آماده‌سازی تصویر اجرا می‌شود.
  • اگر mkosi.postoutput (PostOutputScripts=) وجود داشته باشد، درست پس از تولید تمام فایل‌های خروجی و پیش از انتقال نهایی آن‌ها به دایرکتوری خروجی اجرا می‌شود. این مورد می‌تواند برای تولید خروجی‌های اضافی یا جایگزین، مانند SHA256FILES یا مانیفست‌های SBOM استفاده شود.
  • اگر mkosi.clean (CleanScripts=) وجود داشته باشد، درست پس از پاک‌سازی خروجی‌های یک ساخت پیشین اجرا می‌شود. یک اسکریپت پاک‌سازی می‌تواند هر خروجی‌ای را که mkosi از آن اطلاعی ندارد (مانند دست‌ساخته‌ها از SplitArtifacts=partitions یا RPMهای ساخته‌شده در یک اسکریپت ساخت) پاک‌سازی کند. توجه داشته باشید که این اسکریپت حتی در صورت پیکربندی یک درخت ابزار، از آن استفاده نمی‌کند.
  • اگر mkosi.version وجود داشته باشد و قابل اجرا باشد، در حین تجزیهٔ پیکربندی اجرا شده و مقدار ImageVersion= را با خروجی روی stdout مقداردهی می‌کند. این مورد می‌تواند برای ردیابی نسخهٔ خارجی استفاده شود، به عنوان نمونه با git describe یا date '+%Y-%m-%d'. توجه داشته باشید که این اسکریپت بدون هیچ‌گونه ایزوله‌سازی (sandboxing) روی سیستم میزبان اجرا می‌شود.
  • اگر mkosi.rootpw وجود داشته باشد و قابل اجرا باشد، در حین تجزیهٔ پیکربندی اجرا شده و مقدار RootPassword= را با خروجی روی stdout مقداردهی می‌کند. این مورد می‌تواند برای تولید تصادفی یک گذرواژه به کار رود و می‌توان آن را با خروجی دادن به stderr یا خواندن $MKOSI_CONFIG در یک اسکریپت دیگر (مانند mkosi.postoutput) به یاد سپرد. توجه داشته باشید که این اسکریپت بدون هیچ‌گونه ایزوله‌سازی (sandboxing) روی سیستم میزبان اجرا می‌شود.

اگر یک اسکریپت از پسوند .chroot استفاده کند، mkosi پیش از اجرای اسکریپت، با استفاده از mkosi-chroot (پایین را ببینید) به درون تصویر chroot می‌کند. به عنوان مثال، اگر mkosi.postinst.chroot وجود داشته باشد، mkosi به درون تصویر chroot کرده و آن را به عنوان اسکریپت پس از نصب اجرا می‌کند.

به جای یک اسکریپت تک‌فایلی، mkosi همچنین تمام فایل‌ها را به ترتیب واژه‌نگاری (lexicographical) از دایرکتوری‌های .d با نام‌گذاری مناسب می‌خواند؛ مثلاً تمام فایل‌های موجود در یک دایرکتوری mkosi.build.d به عنوان اسکریپت‌های ساخت استفاده خواهند شد. این قابلیت توسط موارد زیر پشتیبانی می‌شود:

  • mkosi.sync.d،
  • mkosi.prepare.d،
  • mkosi.build.d،
  • mkosi.postinst.d،
  • mkosi.finalize.d،
  • mkosi.postoutput.d، و
  • mkosi.clean.d.

این قابلیت می‌تواند با پسوند .chroot ترکیب شود؛ مثلاً mkosi.build.d/01-foo.sh بدون chroot به درون تصویر اجرا می‌شود و mkosi.build.d/02-bar.sh.chroot پس از chroot اولیه به درون تصویر اجرا خواهد شد.

اسکریپت‌های اجراشده توسط mkosi متغیرهای محیطی زیر را دریافت می‌کنند:

  • $ARCHITECTURE شامل معماری برگرفته از تنظیم Architecture= است. اگر Architecture= تنظیم نشده باشد، حاوی معماری بومی ماشین میزبان خواهد بود. برای مقادیر ممکن این متغیر، مستندات Architecture= را ببینید.
  • $QEMU_ARCHITECTURE شامل معماریِ $ARCHITECTURE در قالبی است که توسط qemu استفاده می‌شود. برای یافتن باینری qemu کاربردی است ( qemu-system-$QEMU_ARCHITECTURE).
  • $EFI_ARCHITECTURE شامل معماریِ $ARCHITECTURE در قالبی است که توسط UEFI استفاده می‌شود. این متغیر روی معماری‌هایی که از UEFI پشتیبانی نمی‌کنند، تنظیم‌نشده (unset) است.
  • $DISTRIBUTION حاوی توزیع برگرفته از تنظیم Distribution= است.
  • $RELEASE حاوی انتشار برگرفته از تنظیم Release= است.
  • $DISTRIBUTION_ARCHITECTURE شامل معماریِ $ARCHITECTURE در قالبی است که توسط توزیع پیکربندی‌شده استفاده می‌شود.
  • $PROFILES شامل پروفایل‌های برگرفته از تنظیم Profiles= به صورت یک رشتهٔ جداشده با کاما است.
  • اگر تصویر ذخیره‌شده در حافظهٔ پنهان در دسترس باشد، مقدار $CACHED برابر با 1 و در غیر این صورت 0 تنظیم می‌شود.
  • $CHROOT_SCRIPT شامل مسیر اسکریپت در حال اجرا نسبت به دایرکتوری ریشهٔ تصویر است. مورد کاربرد اصلی این متغیر در ترکیب با اسکریپت mkosi-chroot است. برای اطلاعات بیشتر، توضیحات mkosi-chroot در زیر را ببینید.
  • $SRCDIR شامل مسیر دایرکتوری‌ای است که mkosi از آن فراخوانی شده بود، به همراه هر سورس ساخت پیکربندی‌شده‌ای که روی آن سوار شده است. $CHROOT_SRCDIR شامل مقداری است که $SRCDIR پس از فراخوانی mkosi-chroot خواهد داشت..IP • 2 $BUILDDIR تنها در صورتی تعریف می‌شود که mkosi.builddir وجود داشته باشد و به دایرکتوری ساختی اشاره می‌کند که باید استفاده شود. این متغیر برای تمامی سیستم‌های ساختی که از ساخت‌های خارج از درخت منبع (out-of-tree) پشتیبانی می‌کنند مفید است تا از دست‌ساخته‌های تولیدشده در اجراهای پیشین دوباره استفاده نمایند. $CHROOT_BUILDDIR حاوی مقداری است که $BUILDDIR پس از فراخوانی mkosi-chroot خواهد داشت.
  • $DESTDIR دایرکتوری‌ای است که هر نرم‌افزار نصب‌شدهٔ ایجادشده توسط یک اسکریپت ساخت می‌تواند درون آن قرار گیرد. این متغیر تنها هنگام اجرای یک اسکریپت ساخت تنظیم می‌شود. $CHROOT_DESTDIR حاوی مقداری است که $DESTDIR پس از فراخوانی mkosi-chroot خواهد داشت.
  • $OUTPUTDIR به دایرکتوری صحنه‌سازی (staging) اشاره دارد که برای ذخیرهٔ دست‌ساخته‌های ساخت تولیدشده در طول فرایند ساخت استفاده می‌شود. $CHROOT_OUTPUTDIR حاوی مقداری است که $OUTPUTDIR پس از فراخوانی mkosi-chroot خواهد داشت.
  • $PACKAGEDIR به دایرکتوری حاوی مخزن محلی بسته‌ها اشاره دارد. اسکریپت‌های ساخت می‌توانند با نوشتن بسته‌ها در $PACKAGEDIR\[u060C] بسته‌های بیشتری به این مخزن محلی بیفزایند.
  • $ARTIFACTDIR به دایرکتوری‌ای اشاره می‌کند که برای تبادل دست‌ساخته‌های ساخت تولیدشده در طول ساخت و در دسترس قرار دادن آن‌ها برای استفاده توسط mkosi به کار می‌رود. این متغیر شبیه به PACKAGEDIR است، اما برای دست‌ساخته‌هایی در نظر گرفته شده که ممکن است بسته‌های شناخته‌شده برای مدیر بسته نباشند، مانند initrdهای تولیدشده توسط مولدهایی به‌جز خود mkosi. اسکریپت‌های ساخت می‌توانند با قرار دادن دست‌ساخته‌ها در $ARTIFACTDIR\[u060C] موارد بیشتری را به این دایرکتوری بیفزایند. فایل‌های این دایرکتوری تنها برای ساخت فعلی در دسترس هستند و برخلاف محتویات $OUTPUTDIR به بیرون کپی نمی‌شوند.

mkosi همچنین از زیردایرکتوری‌های خاصی در یک دایرکتوری دست‌ساخته‌ها استفاده می‌کند تا از محتویات آن‌ها به صورت خودکار در مراحلی معین بهره گیرد. در حال حاضر دو زیردایرکتوری زیر در دایرکتوری دست‌ساخته‌ها توسط mkosi استفاده می‌شوند:

  • io.mkosi.microcode: تمام فایل‌های موجود در این دایرکتوری به عنوان فایل‌های ریزکد (microcode) استفاده می‌شوند؛ به این صورت که با ترتیب الفبایی به ابتدای initrdها الحاق می‌گردند.
  • io.mkosi.initrd: تمام فایل‌های موجود در این دایرکتوری به عنوان initrd استفاده شده و با ترتیب الفبایی به یکدیگر پیوست می‌شوند.

توصیه می‌شود کاربرانی که از $ARTIFACTDIR استفاده می‌کنند، موارد مورد استفادهٔ خود را در یک دایرکتوری فضای نام مشابه قرار دهند، مانند local.my.namespace.

  • $BUILDROOT دایرکتوری ریشهٔ ایمیج در حال ساخت است که بسته به اسکریپتی که در حال اجراست، ممکن است لایهٔ هم‌پوشان ساخت (build overlay) نیز به صورت اختیاری بر روی آن سوار (mount) شده باشد.
  • $WITH_DOCS بسته به اینکه آیا ساخت بدون مستندات نصب‌شده یا همراه با آن درخواست شده است (WithDocs=yes)، برابر با 0 یا 1 است. یک اسکریپت ساخت در صورتی که $WITH_DOCS روی 0 تنظیم شده باشد، باید از نصب هرگونه مستندات بسته در $DESTDIR جلوگیری کند.
  • $WITH_TESTS بسته به اینکه آیا ساخت بدون اجرای مجموعهٔ آزمون‌ها یا همراه با آن درخواست شده است (WithTests=no)، برابر با 0 یا 1 است. یک اسکریپت ساخت در صورتی که $WITH_TESTS برابر با 0 باشد، باید از اجرای هرگونه آزمون واحد یا یکپارچه‌سازی خودداری کند.
  • $WITH_NETWORK بسته به اینکه ساخت بدون شبکه یا با دسترسی به شبکه در حال اجرا باشد (WithNetwork=no)، برابر با 0 یا 1 است. یک اسکریپت ساخت در صورتی که $WITH_NETWORK برابر با 0 باشد، باید از هرگونه ارتباط شبکه‌ای خودداری کند.
  • $SOURCE_DATE_EPOCH در صورت درخواست تعریف می‌شود (SourceDateEpoch=TIMESTAMP، Environment=SOURCE_DATE_EPOCH=TIMESTAMP یا متغیر محیطی میزبان $SOURCE_DATE_EPOCH). این متغیر برای بازتولیدپذیر ساختن فرایند ساخت مفید است. برای اطلاعات بیشتر SOURCE_DATE_EPOCH را ببینید.
  • $MKOSI_UID و $MKOSI_GID به ترتیب شناسه کاربری (uid) و شناسه گروهی (gid) کاربری هستند که mkosi را فراخوانی کرده است.
  • $MKOSI_CONFIG فایلی شامل یک خلاصه‌سازی json از تنظیمات ایمیج فعلی است. این فایل را می‌توان در داخل اسکریپت‌ها تجزیه کرد تا به تمام تنظیمات ایمیج فعلی دسترسی پیدا کرد.
  • $IMAGE_ID حاوی شناسه برگرفته از تنظیم ImageId= یا --image-id= است.
  • $IMAGE_VERSION حاوی نگارش برگرفته از تنظیم ImageVersion= یا --image-version= است.
  • $MKOSI_DEBUG بسته به اینکه آیا خروجی اشکال‌زدایی فعال است یا خیر، برابر با 0 یا 1 است.

برای آگاهی از اینکه کدام اسکریپت چه متغیرهای محیطی را دریافت می‌کند، این جدول را بررسی کنید:

متغیر configure sync prepare build postinst finalize postoutput clean
ARCHITECTURE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ARTIFACTDIR ✓ ✓ ✓ ✓
BUILDDIR ✓ ✓ ✓
BUILDROOT ✓ ✓ ✓ ✓
CACHED ✓
CHROOT_BUILDDIR ✓
CHROOT_DESTDIR ✓
CHROOT_OUTPUTDIR ✓ ✓
CHROOT_SCRIPT ✓ ✓ ✓ ✓
CHROOT_SRCDIR ✓ ✓ ✓ ✓
MKOSI_DEBUG ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
DESTDIR ✓
DISTRIBUTION ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
DISTRIBUTION_ARCHITECTURE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
EFI_ARCHITECTURE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
IMAGE_ID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
IMAGE_VERSION ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
MKOSI_CONFIG ✓ ✓ ✓ ✓ ✓ ✓ ✓
MKOSI_GID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
MKOSI_UID ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
OUTPUTDIR ✓ ✓ ✓ ✓
PACKAGEDIR ✓ ✓ ✓ ✓
PROFILES ✓ ✓ ✓ ✓ ✓ ✓ ✓
QEMU_ARCHITECTURE ✓
RELEASE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
SOURCE_DATE_EPOCH ✓ ✓ ✓ ✓ ✓
SRCDIR ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
WITH_DOCS ✓ ✓
WITH_NETWORK ✓ ✓ ✓ ✓
WITH_TESTS ✓ ✓
علاوه بر این، هنگام اجرای یک اسکریپت، چند اسکریپت از طریق $PATH در دسترس قرار می‌گیرند تا موارد استفاده معمول را ساده‌تر کنند.
• 2
mkosi-chroot: این اسکریپت به درون ایمیج chroot کرده و دستور داده‌شده را اجرا می‌کند.
افزون بر chroot به داخل ایمیج، این اسکریپت فایل‌ها و دایرکتوری‌های گوناگونی ($SRCDIR، $DESTDIR، $BUILDDIR، $OUTPUTDIR، $CHROOT_SCRIPT) را نیز در ایمیج سوار (mount) کرده و متغیرهای محیطی متناظر را به‌گونه‌ای تغییر می‌دهد که به مکان‌های درون ایمیج اشاره کنند.
همچنین فایل‌سیستم‌های APIVFS (/proc، /dev، ...) را سوار می‌کند تا اطمینان حاصل شود اسکریپت‌ها و ابزارهای اجراشده درون chroot به‌درستی کار می‌کنند.
همچنین در صورت درخواست، /etc/resolv.conf را از میزبان به درون chroot منتقل می‌کند تا تفکیک DNS درون chroot کار کند.
پس از خروج دستور mkosi-chroot، نقاط اتصال مختلف پاک‌سازی می‌شوند.
2
برای نمونه، جهت فراخوانی ls درون ایمیج، از دستور زیر استفاده کنید:
mkosi-chroot ls ...
برای اجرای کل اسکریپت درون ایمیج، یک پسوند .chroot به نام آن بیفزایید (mkosi.build.chroot به‌جای mkosi.build و غیره).
• 2
برای تمامی مدیر بسته‌های پشتیبانی‌شده (dnf، rpm، apt، dpkg، pacman، zypper)، اسکریپت‌هایی با همان نام در $PATH قرار می‌گیرند تا اطمینان حاصل شود این دستورها به‌جای سیستم میزبان، بر روی دایرکتوری ریشهٔ ایمیج و با پیکربندی ارائه‌شده توسط کاربر عمل می‌کنند.
این بدان معناست که از درون یک اسکریپت، می‌توانید برای مثال دستور dnf install vim را برای نصب vim در ایمیج اجرا کنید.
2
علاوه بر این، mkosi-install، mkosi-reinstall، mkosi-upgrade و mkosi-remove عملیات متناظر مدیر بسته‌ای را که برای ساخت ایمیج استفاده می‌شود، فراخوانی خواهند کرد.
• 2
دستور git به‌طور خودکار با safe.directory=* فراخوانی می‌شود تا هنگام اجرا به‌عنوان کاربر root در یک فضای‌نام کاربر (user namespace)، از خطاهای مجوز جلوگیری شود.
• 2
دستورهای useradd و groupadd هنگام اجرا در خارج از ایمیج، به‌طور خودکار با --root=$BUILDROOT فراخوانی می‌شوند.
هنگام اجرای اسکریپت‌ها، هر دایرکتوری که هنوز قابل نوشتن باشد نیز فقط‌خواندنی می‌شود (/home، /var، /root، ...) و تنها حداقل مجموعه دایرکتوری‌هایی که نیاز به نوشتن دارند، قابل نوشتن باقی می‌مانند.
این کار برای اطمینان از این است که هنگام اجرای mkosi به‌عنوان root، اسکریپت‌ها نتوانند به سیستم میزبان آسیبی برسانند یا در آن اختلال ایجاد کنند.
توجه داشته باشید که هنگام اجرای اسکریپت‌ها، همه دایرکتوری‌های منبع ناپایدار (ephemeral) می‌شوند، به این معنی که تمام تغییرات اعمال‌شده در دایرکتوری‌های منبع حین اجرای اسکریپت‌ها، پس از پایان اجرای آن‌ها دور ریخته می‌شوند.
اگر نیاز به ماندگاری داده‌ها بین دفعات ساخت دارید، از دایرکتوری‌های خروجی، ساخت یا حافظه پنهان (cache) استفاده کنید.
"فایل‌ها (FILES)"
برای آسان‌تر ساختن ایجاد ایمیج‌ها برای نسخه‌های در حال توسعه پروژه‌هایتان، mkosi می‌تواند داده‌های پیکربندی را با این فرض که از یک درخت منبع (source) فراخوانی شده است، از دایرکتوری محلی بخواند.
به‌طور خاص، فایل‌های زیر در صورت وجود در دایرکتوری محلی استفاده می‌شوند:
• 2
دایرکتوری mkosi.skeleton/ یا بایگانی mkosi.skeleton.tar می‌تواند برای درج فایل‌ها در ایمیج استفاده شود.
فایل‌ها پیش از نصب بسته‌های توزیع در ایمیج کپی می‌شوند.
این امر امکان ایجاد فایل‌هایی را که باید زودتر ارائه شوند، برای نمونه برای پیکربندی مدیر بسته یا اعمال پیش‌تنظیم‌های systemd، فراهم می‌کند.
2
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
• 2
دایرکتوری mkosi.extra/ یا بایگانی mkosi.extra.tar می‌تواند برای درج فایل‌های اضافی در ایمیج، فراتر از آنچه توزیع در بسته‌های خود شامل می‌شود، استفاده شود.
آن‌ها شبیه به mkosi.skeleton/ و mkosi.skeleton.tar هستند، اما فایل‌ها پس از نصب سیستم‌عامل در درخت دایرکتوری ایمیج کپی می‌شوند.
2
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
• 2
دایرکتوری mkosi.sandbox/ یا بایگانی mkosi.sandbox.tar می‌تواند برای پیکربندی مدیر بسته بدون درج فایل‌ها در ایمیج استفاده شود.
اگر فایل‌ها باید درون ایمیج گنجانده شوند، به‌جای آن باید از mkosi.skeleton/ و mkosi.skeleton.tar استفاده شود.
2
هنگام استفاده از دایرکتوری، مالکیت فایل‌ها حفظ نمی‌شود: تمام فایل‌های کپی‌شده متعلق به root خواهند بود.
برای حفظ مالکیت، از یک بایگانی tar استفاده کنید.
• 2
فایل تنظیمات nspawn با نام mkosi.nspawn، در صورت وجود، در همان محل فایل ایمیج خروجی کپی خواهد شد.
این امر کاربردی است زیرا nspawn برای تنظیمات بیشتر زمان اجرای کانتینر، به دنبال فایل‌های تنظیمات در کنار فایل‌های ایمیجی که بوت می‌کند می‌گردد.
• 2
دایرکتوری mkosi.cache/، در صورت وجود، به‌طور خودکار به‌عنوان حافظه پنهان بارگیری بسته‌ها استفاده می‌شود تا اجرای مکرر ابزار را سرعت ببخشد.
• 2
دایرکتوری mkosi.builddir/، در صورت وجود، چنانچه دستورهای ساخت در اسکریپت‌های mkosi.build از آن پشتیبانی کنند، به‌طور خودکار به‌عنوان دایرکتوری ساخت خارج از درخت منبع (out-of-tree) استفاده می‌شود.
به‌طور خاص، این دایرکتوری در کانتینر ساخت سوار خواهد شد و هنگام فراخوانی اسکریپت‌های ساخت، متغیر محیطی $BUILDDIR روی آن تنظیم می‌شود.
سپس یک اسکریپت ساخت می‌تواند از این دایرکتوری به‌عنوان دایرکتوری ساخت، برای ساخت‌های خارج از درخت به سبک automake یا ninja استفاده کند.
این امر سرعت ساخت را به‌میزان قابل‌توجهی افزایش می‌دهد، به‌ویژه زمانی که mkosi در حالت افزایشی (-i) استفاده می‌شود: نه‌تنها ایمیج و لایهٔ ساخت، بلکه درخت ساخت نیز بین فراخوانی‌های بعدی مجدداً استفاده می‌شود.
توجه داشته باشید که اگر این دایرکتوری وجود نداشته باشد، متغیر محیطی $BUILDDIR تنظیم نمی‌شود و این بر عهدهٔ اسکریپت‌های ساخت است که تصمیم بگیرند ساخت درون درخت (in-tree) انجام شود یا ساخت خارج از درخت (out-of-tree)، و از کدام دایرکتوری ساخت استفاده شود.
• 2
فایل mkosi.rootpw می‌تواند برای ارائه گذرواژه کاربر root ایمیج استفاده شود.
اگر گذرواژه دارای پیشوند hashed: باشد، به‌عنوان یک گذرواژهٔ root از پیش هش‌شده در نظر گرفته می‌شود.
گذرواژه می‌تواند به‌صورت اختیاری با یک نویسه خط جدید همراه باشد که به‌طور ضمنی حذف می‌شود.
فایل باید دارای حالت دسترسی 0600 یا کمتر باشد.
اگر این فایل وجود نداشته باشد، گذرواژه پیش‌فرض توزیع برای root تنظیم می‌شود (که معمولاً به این معنی است که دسترسی به کاربر root مسدود است).
• 2
فایل mkosi.passphrase عبارت عبور (passphrase) را جهت استفاده هنگام انتخاب رمزنگاری LUKS ارائه می‌دهد.
این فایل باید دقیقاً حاوی عبارت عبور باشد و به یک نویسه خط جدید ختم نشود (یعنی با همان قالبی که cryptsetup و /etc/crypttab برای فایل‌های عبارت عبور انتظار دارند).
فایل باید دارای حالت دسترسی 0600 یا کمتر باشد.
• 2
فایل‌های mkosi.crt و mkosi.key حاوی یک گواهی X.509 و کلید خصوصی PEM هستند که هنگام نیاز به امضا (UEFI SecureBoot، verity، ...) استفاده می‌شوند.
• 2
دایرکتوری mkosi.output/ برای ذخیره تمام دست‌ساخته‌های ساخت استفاده می‌شود.
• 2
دایرکتوری mkosi.credentials/ به‌عنوان منبعی برای اعتبارنامه‌های اضافی مشابه گزینهٔ Credentials= استفاده می‌شود.
برای هر فایل در این دایرکتوری، نام فایل به‌عنوان نام اعتبارنامه و محتویات فایل به‌عنوان مقدار اعتبارنامه استفاده خواهد شد، یا چنانچه فایل قابل اجرا باشد، mkosi فایل را اجرا کرده و خروجی دستور در stdout به‌عنوان مقدار اعتبارنامه استفاده می‌شود.
خروجی به stderr نادیده گرفته خواهد شد.
اعتبارنامه‌های پیکربندی‌شده با Credentials= بر فایل‌های موجود در mkosi.credentials اولویت دارند.
• 2
دایرکتوری mkosi.repart/ به‌عنوان منبعی برای فایل‌های تعریف پارتیشن systemd-repart استفاده می‌شود که هنگام ساخت ایمیج دیسک به systemd-repart ارسال می‌شوند.
اگر این دایرکتوری وجود نداشته باشد و تنظیم RepartDirectories= پیکربندی نشده باشد، mkosi به‌طور پیش‌فرض از فایل‌های تعریف پارتیشن زیر استفاده خواهد کرد:
2
00-esp.conf (اگر در حال ساخت یک ایمیج قابل بوت باشیم):
[Partition]
Type=esp
Format=vfat
CopyFiles=/boot:/
CopyFiles=/efi:/
SizeMinBytes=512M
SizeMaxBytes=512M
05-bios.conf (اگر در حال ساخت یک ایمیج قابل بوت BIOS باشیم):
[Partition]
# UUID of the grub BIOS boot partition which grubs needs on GPT to
# embed itself into.
Type=21686148-6449-6e6f-744e-656564454649
SizeMinBytes=1M
SizeMaxBytes=1M
10-root.conf
[Partition]
Type=root
Format=<distribution-default-filesystem>
CopyFiles=/
Minimize=guess
توجه داشته باشید که اگر mkosi.repart/ یافت شود یا از RepartDirectories= استفاده گردد، هیچ‌یک از تعاریف پیش‌فرض پارتیشن استفاده نخواهند شد.
تمامی این فایل‌ها اختیاری هستند.
توجه داشته باشید که مکان همه این فایل‌ها همچنین می‌تواند هنگام فراخوانی از طریق سوئیچ‌های خط فرمان و به عنوان تنظیماتی در mkosi.conf پیکربندی شود، در صورتی که تنظیمات پیش‌فرض برای یک پروژه مناسب نباشند.
"کَش‌کردن (CACHING)"
دستور mkosi از سه کَش مختلف برای افزایش سرعت ساخت مجدد و تکراری ایمیج‌ها پشتیبانی می‌کند.
به طور مشخص:
"1." 3
کَش بسته‌های مدیر بسته توزیع بین دفعات ساخت نگهداری می‌شود.
مکان آن را می‌توان با گزینه PackageCacheDirectory= یا دایرکتوری mkosi.pkgcache/ پیکربندی کرد.
این شیوه از کَش‌کردن بر مدیر بسته توزیع اتکا دارد و بسته‌های توزیع (RPM، deb و ...) را پس از بارگیری، اما پیش از استخراج (unpack) ذخیره می‌کند.
"2." 3
متادیتای مخزن توزیع در صورتی کَش می‌شود که یک دایرکتوری کَش با CacheDirectory= یا دایرکتوری mkosi.cache/ پیکربندی شده باشد.
زمان همگام‌سازی مجدد متادیتای مخزن توسط گزینه CacheOnly= کنترل می‌شود که به طور پیش‌فرض همیشه متادیتای مخزن را مجدداً همگام‌سازی می‌کند، مگر اینکه تمامی ایمیج‌ها کَش شده باشند (گزینه Incremental= را ببینید).
هر زمان که متادیتای مخزن مجدداً همگام‌سازی شود، تمامی ایمیج‌های کَش‌شده نامعتبر می‌شوند.
"3." 3
اگر حالت ساخت افزایشی با Incremental=yes فعال باشد، نسخه‌های کَش‌شده از ایمیج نهایی و build overlay بلافاصله پیش از کپی شدن سورس‌های ساخت (برای build overlay) یا کپی شدن مصنوعات تولیدشده توسط mkosi.build (در مورد ایمیج نهایی) ایجاد می‌شوند.
این شیوه از کَش‌کردن اجازه می‌دهد مرحله زمان‌بر استخراج بسته‌ها در مدیر بسته‌های توزیع دور زده شود، اما تنها زمانی مؤثر است که فهرست بسته‌های مورد استفاده ثابت بماند، در حالی که سورس‌های ساخت و اسکریپت‌های آن به طور منظم تغییر کنند.
"4." 3
در نهایت، بین چندین ساخت مختلف، دایرکتوری مصنوعات ساخت ممکن است با استفاده از گزینه BuildDirectory= یا دایرکتوری mkosi.builddir/ به اشتراک گذاشته شود.
این دایرکتوری به سیستم‌های ساختی مانند Meson اجازه می‌دهد تا سورس‌های کامپایل‌شده از ساخت قبلی را مجدداً استفاده کنند، و در نتیجه فرایند اجرای اسکریپت ساخت mkosi.build را سرعت بخشند.
"درخت‌های ابزار (TOOLS TREES)"
درخت‌های ابزار (Tools trees) یک ایمیج ثانویه هستند که mkosi می‌تواند از آن برای ساخت ایمیج‌های اصلی استفاده کند.
این قابلیت برای بازتولیدپذیرتر کردن ساخت ایمیج‌ها مفید است، اما همچنین امکان استفاده از ابزارهای جدیدتری را فراهم می‌کند که هنوز در توزیع میزبانی که mkosi را اجرا می‌کند در دسترس نیستند.
درخت‌های ابزار می‌توانند از طریق گزینه ToolsTree=، دایرکتوری mkosi.tools ارائه شوند، یا در صورت تنظیم ToolsTree=yes به طور خودکار توسط mkosi ساخته شوند.
برای بیشتر موارد، استفاده از درخت‌های ابزار پیش‌فرض کافی است و به‌کارگیری یک درخت ابزار توصیه می‌شود.
درخت‌های ابزار کاملاً سفارشی را می‌توان مانند هر ایمیج دیگر mkosi ساخت، اما mkosi یک include داخلی ارائه می‌دهد که بسته‌های درخت ابزار پیش‌فرض را فراهم می‌کند:
mkosi --include=mkosi-tools --format=directory
درخت‌های ابزار، از جمله درخت‌های ابزار پیش‌فرض، می‌توانند از طریق متغیرهای مختلف ToolsTree*= و همچنین فایل یا دایرکتوری پیکربندی mkosi.tools.conf بیشتر سفارشی‌سازی شوند.
فرمت خروجی برای درخت‌های ابزار در حال حاضر نمی‌تواند از طریق فایل‌های پیکربندی تغییر داده شود.
جدول زیر نشان می‌دهد که بسته‌های درخت ابزار پیش‌فرض برای کدام توزیع‌ها تعریف شده‌اند و کدام بسته‌ها در آن درخت‌های ابزار پیش‌فرض گنجانده شده‌اند:
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).
Fedora CentOS Debian Kali Ubuntu Arch openSUSE postmarketOS
acl ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
apt ✓ ✓ ✓ ✓ ✓ ✓
archlinux-keyring ✓ ✓ ✓ ✓ ✓ ✓
attr ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
bash ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
btrfs-progs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ca-certificates ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
coreutils ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
cpio ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
createrepo_c ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
curl ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
debian-keyring ✓ ✓ ✓ ✓ ✓ ✓ ✓
diffutils ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
distribution-gpg-keys ✓ ✓ ✓ ✓ ✓ ✓ ✓
dnf ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
dosfstools ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
e2fsprogs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
edk2-ovmf ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
erofs-utils ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
findutils ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
git ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
grep ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
grub-tools ✓ ✓ ✓ ✓ ✓ ✓
jq ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
kali-archive-keyring ✓
kmod ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
less ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
mtools ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
nano ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
opensc ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
openssh ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
openssl ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
pkcs11-provider ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
perf ✓ ✓ ✓ ✓ ✓ ✓ ✓
sed ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
pacman ✓ ✓ ✓ ✓ ✓ ✓ ✓
p11-kit ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
policycoreutils ✓ ✓ ✓ ✓ ✓ ✓ ✓
qemu ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
sbsigntools ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
socat ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
squashfs-tools ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
strace ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
swtpm ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
systemd ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ukify ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
tar ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ubuntu-keyring ✓ ✓ ✓ ✓ ✓ ✓
util-linux ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
virtiofsd ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
virt-firmware ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
xfsprogs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
xz ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
zstd ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
zypper ✓ ✓ ✓ ✓ ✓ ✓
"ساخت چندین ایمیج (BUILDING MULTIPLE IMAGES)"
اگر دایرکتوری mkosi.images/ وجود داشته باشد، mkosi
پیکربندی‌های مجزای زیرایمیج‌ها را از آن بارگذاری کرده و هر یک از آن‌ها را می‌سازد.
پیکربندی‌های ایمیج می‌توانند دایرکتوری‌های حاوی فایل‌های پیکربندی
mkosi یا فایل‌های عادی با پسوند .conf باشند.
هنگامی که پیکربندی‌های ایمیج در mkosi.images/ یافت شوند،
mkosi ایمیج‌های مشخص‌شده در تنظیم Dependencies= ایمیج اصلی
و تمامی وابستگی‌های آن‌ها را می‌سازد (یا در صورتی که هیچ ایمیجی صراحتاً با استفاده از
Dependencies= در پیکربندی ایمیج اصلی مشخص نشده باشد، همه آن‌ها را می‌سازد).
برای افزودن وابستگی‌ها میان زیرایمیج‌ها، می‌توان از تنظیم Dependencies=
نیز استفاده کرد.
زیرایمیج‌ها همواره پیش از ایمیج اصلی ساخته می‌شوند.
هنگامی که ایمیج‌ها تعریف شوند، mkosi ابتدا پیکربندی ایمیج اصلی
(پیکربندی خارج از دایرکتوری mkosi.images/) و سپس پیکربندی مختص هر ایمیج را می‌خواند.
چندین تنظیم “multiversal” بر درخت ابزارهای پیش‌فرض و ایمیج اصلی اعمال
می‌شوند و نمی‌توان آن‌ها را جداگانه در خارج از ایمیج اصلی پیکربندی کرد:
• 2
RepositoryKeyCheck=
• 2
RepositoryKeyFetch=
• 2
SourceDateEpoch=
• 2
WorkspaceDirectory=
• 2
PackageCacheDirectory=
• 2
BuildSources=
• 2
BuildSourcesEphemeral=
• 2
ProxyClientCertificate=
• 2
ProxyClientKey=
• 2
ProxyExclude=
• 2
ProxyPeerCertificate=
• 2
ProxyUrl=
• 2
MakeScriptsExecutable=
چندین تنظیم “universal” بر ایمیج اصلی و تمامی زیرایمیج‌های آن اعمال
می‌شوند و نمی‌توان آن‌ها را جداگانه در زیرایمیج‌ها پیکربندی کرد.
تنظیمات زیر همگانی هستند و در زیرایمیج‌ها قابل پیکربندی نمی‌باشند:
• 2
Architecture=
• 2
BuildDirectory=
• 2
CacheDirectory=
• 2
Distribution=
• 2
ExtraSearchPaths=
• 2
LocalMirror=
• 2
Mirror=
• 2
OutputDirectory=
• 2
OutputMode=
• 2
PackageDirectories=
• 2
Release=
• 2
RepartOffline=
• 2
Repositories=
• 2
SandboxTrees=
• 2
ToolsTree=
• 2
ToolsTreeCertificates=
• 2
UseSubvolumes=
• 2
SecureBootCertificate=
• 2
SecureBootCertificateSource=
• 2
SecureBootKey=
• 2
SecureBootKeySource=
• 2
VerityCertificate=
• 2
VerityCertificateSource=
• 2
VerityKey=
• 2
VerityKeySource=
• 2
VolatilePackageDirectories=
• 2
WithNetwork=
• 2
WithTests
همچنین تنظیماتی وجود دارند که به زیرایمیج‌ها منتقل می‌شوند اما می‌توان آن‌ها را
بازنویسی کرد.
برای این تنظیمات، مقادیری که صراحتاً در زیرایمیج پیکربندی شده‌اند نسبت به مقادیر
پیکربندی‌شده در خط فرمان یا در پیکربندی ایمیج اصلی اولویت خواهند داشت.
در حال حاضر تنظیمات زیر به زیرایمیج‌ها منتقل می‌شوند اما امکان بازنویسی آن‌ها وجود دارد:
• 2
Incremental=
• 2
CacheOnly=
• 2
Profiles=
• 2
ImageId=
• 2
ImageVersion=
• 2
SectorSize=
• 2
CacheKey=
• 2
BuildKey=
• 2
CompressLevel=
• 2
SignExpectedPcrKey=
• 2
SignExpectedPcrKeySource=
• 2
SignExpectedPcrCertificate=
• 2
SignExpectedPcrCertificateSource=
علاوه بر این، تنظیمات متعددی وجود دارند که تنها در ایمیج اصلی قابل پیکربندی هستند
اما به زیرایمیج‌ها منتقل نمی‌شوند:
• 2
MinimumVersion=
• 2
PassEnvironment=
• 2
ToolsTreeDistribution=
• 2
ToolsTreeRelease=
• 2
ToolsTreeProfiles=
• 2
ToolsTreeMirror=
• 2
ToolsTreeSnapshot=
• 2
ToolsTreeRepositories=
• 2
ToolsTreeSandboxTrees=
• 2
ToolsTreePackages=
• 2
ToolsTreePackageDirectories=
• 2
History=
• 2
تمامی تنظیمات موجود در بخش [Runtime]
ایمیج‌ها می‌توانند به خروجی‌های ایمیج‌هایی که به آن‌ها وابسته هستند ارجاع دهند.
به‌ویژه برای گزینه‌های زیر، mkosi تنها درست پیش از ساخت ایمیج بررسی می‌کند
که آیا ورودی‌ها وجود دارند یا خیر:
• 2
BaseTrees=
• 2
ExtraTrees=
• 2
Initrds=
برای ارجاع به خروجی‌های وابستگی‌های یک ایمیج، کافی است هر یک از این گزینه‌ها را
با مسیر نسبی به خروجی مورد نظر در دایرکتوری خروجیِ آن وابستگی پیکربندی کنید.
یا از مشخصه‌گر %O برای ارجاع به دایرکتوری خروجی استفاده نمایید.
یک مثال مناسب در مورد نحوه ساخت چندین ایمیج را می‌توان در مخزن
https://github.com/systemd/systemd/tree/main/mkosi/mkosi.images
systemd
 یافت..SH "متغیرهای محیطی (ENVIRONMENT VARIABLES)"
• 2
$MKOSI_LESS گزینه‌های less را هنگامی که توسط mkosi برای صفحه‌بندی خروجی فراخوانی می‌شود بازنویسی می‌کند.
• 2
$MKOSI_DNF می‌تواند برای لغو و جایگزینی فایل اجراییِ مورد استفاده به عنوان dnf به کار رود.
این متغیر به‌ویژه برای انتخاب میان dnf و dnf5 مفید است.
توجه داشته باشید که این متغیر تنها زمانی اعمال می‌شود که هیچ درخت ابزاری (tools tree) در حال استفاده نباشد؛
در صورت فعال بودن یک درخت ابزار، فایل اجرایی dnf به‌طور خودکار از درون درخت ابزار شناسایی می‌شود.
• 2
$MKOSI_DNF_DISABLE_PLUGINS می‌تواند برای غیرفعال کردن افزونه‌های dnf استفاده شود.
این مقدار به گزینهٔ --disableplugin= در dnf ارسال می‌شود.
• 2
$MKOSI_DNF_ENABLE_PLUGINS می‌تواند برای فعال کردن افزونه‌های dnf استفاده شود.
این مقدار به گزینهٔ --enableplugin= در dnf ارسال می‌شود.
• 2
$EPEL_MIRROR می‌تواند برای بازنویسی مکان پیش‌فرض مخزن آینه‌ای (mirror) مورد استفاده برای مخازن epel در هنگام استفاده از Mirror= به کار رود.
به‌طور پیش‌فرض، mkosi مخازن epel را در زیردایرکتوری fedora از دایرکتوری والد آینهٔ مشخص‌شده در Mirror= جستجو می‌کند.
برای مثال، اگر آینه روی https://mirror.net/centos-stream تنظیم شده باشد، mkosi مخازن epel را در https://mirror.net/fedora/epel جستجو خواهد کرد.
• 2
SYSEXT_SCOPE و CONFEXT_SCOPE می‌توانند برای جایگزینی مقدار پیش‌فرض فایل extension-release مربوطه در هنگام ساخت یک sysext یا confext استفاده شوند.
به‌طور پیش‌فرض این مقدار روی initrd system portable تنظیم شده است.
"مثال‌ها (EXAMPLES)"
ساخت و اجرای یک ایمیج خام GPT با فایل‌سیستم ext4، با نام image.raw:
# mkosi -p systemd -i boot
ساخت و اجرای یک ایمیج بوت‌پذیر GPT، با نام foobar.raw:
$ mkosi -d fedora -p kernel-core -p systemd -p systemd-boot -p udev -o foobar.raw
# mkosi --output foobar.raw boot
$ mkosi --output foobar.raw vm
ساخت و اجرای یک ایمیج Fedora Linux در یک دایرکتوری ساده:
# mkosi --distribution fedora --format directory boot
ساخت یک ایمیج فشرده‌شده به نام image.raw.xz به همراه بستهٔ نصب‌شدهٔ SSH و افزودن فایل مجموع مقابله‌ای (checksum):
$ mkosi --distribution fedora --format disk --checksum=yes --compress-output=yes --package=openssh-clients
در دایرکتوری ریشهٔ منبع یک پروژهٔ مبتنی بر automake، نرم‌افزار mkosi را طوری پیکربندی کنید که اجرای سادهٔ mkosi بدون هیچ پارامتری، یک ایمیج سیستم‌عامل حاوی نسخهٔ ساخته‌شده از وضعیت فعلی پروژه تولید کند:
$ cat >mkosi.conf <<EOF
[Distribution]
Distribution=fedora
[Output]
Format=disk
[Content]
Packages=kernel,systemd,systemd-udev,openssh-clients,httpd
BuildPackages=make,gcc,libcurl-devel
EOF
$ cat >mkosi.build <<EOF
#!/bin/sh
if [ "$container" != "mkosi" ]; then
exec mkosi-chroot "$CHROOT_SCRIPT" "$@"
fi
cd $SRCDIR
./autogen.sh
./configure --prefix=/usr
make -j `nproc`
make install
EOF
$ chmod +x mkosi.build
# mkosi -i boot
# systemd-nspawn -bi image.raw
روش‌های مختلف بوت با vm
ساده‌ترین راه برای بوت یک ماشین مجازی این است که یک ایمیج با مؤلفه‌های مورد نیاز ساخته و اجازه دهید mkosi برنامهٔ qemu را با تمام گزینه‌های مناسب فراخوانی کند:
$ mkosi -d fedora -p systemd-udev,systemd-boot,kernel-core build
$ mkosi -d fedora vm
...
fedora login: root (automatic login)
[root@fedora ~]#
حالت پیش‌فرض، بوت تنها با یک کنسول متنی است.
در این حالت، پیام‌های بارگذار بوت (boot loader)، هسته، systemd و سپس اعلان ورود getty و شل همگی از همان ترمینال مشترک استفاده می‌کنند.
امکان جابجایی بین کنسول و مانیتور qemu با فشردن کلیدهای Ctrl-a c وجود دارد.
مانیتور qemu ممکن است برای نمونه جهت ارسال کلیدهای خاص یا خاموش کردن سریع ماشین به کار رود.
همچنین می‌توان ماشین را با استفاده از Ctrl-a x خاموش کرد.
برای بوت به همراه یک پنجرهٔ گرافیکی، گزینهٔ --console=gui را اضافه کنید:
$ mkosi -d fedora --console=gui qemu
یک هسته را می‌توان مستقیماً با دستور mkosi vm -kernel ... -initrd ... -append '...' بوت کرد.
این کار کمی سریع‌تر است زیرا از بارگذار بوت استفاده نمی‌شود، و همچنین آزمایش هسته‌ها و خطوط فرمان هستهٔ مختلف را ساده‌تر می‌کند.
توجه داشته باشید که علی‌رغم نام آن، گزینهٔ -append در qemu خط فرمان پیش‌فرض تعبیه‌شده در هسته و هر مشخصهٔ قبلیِ -append را جایگزین می‌کند.
فایل UKI نیز در دایرکتوری خروجی کپی می‌شود و می‌تواند مستقیماً بوت شود:
$ mkosi vm -- -kernel mkosi.output/fedora~38/image.efi
هنگام بوت با استفاده از یک هستهٔ خارجی، نیازی به وجود خود هسته درون ایمیج نیست، اما همچنان تمایل داریم ماژول‌های هسته نصب شده باشند.
همچنین انجام یک بوت مستقیم هسته (direct kernel boot) به درون یک بارگذار بوت نیز امکان‌پذیر است، که از این واقعیت که systemd-boot(7) یک باینری معتبر UEFI است بهره می‌برد:
$ mkosi vm -- -kernel /usr/lib/systemd/boot/efi/systemd-bootx64.efi
در این سناریو، هسته از ESP درون ایمیج توسط systemd-boot بارگذاری می‌شود..SH "نیازمندی‌ها (REQUIREMENTS)"
• 2
ابزار mkosi به یک هسته لینوکس نیاز دارد که mount_setattr() را ارائه دهد؛ این قابلیت در نگارش 5.12 معرفی شد.
• 2
ابزار mkosi در حال حاضر برای ساخت ایمیج‌های دیسک قابل بوت، به systemd 254 یا جدیدتر نیاز دارد.
• 2
ابزار mkosi نیازمند نصب وابستگی‌های گوناگونی است.
اگر از یک درخت ابزار (tools tree) استفاده شود (برای اطلاعات بیشتر به مستندات ToolsTree= مراجعه کنید)،
آنگاه mkosi همه وابستگی‌های خود (به‌جز python و یک مدیر بسته) را خودش بارگیری خواهد کرد.
در غیر این صورت، لازم است وابستگی‌های مورد نیاز را روی سیستم خود نصب کنید.
می‌توانید دستور mkosi dependencies را برای دریافت فهرستی از وابستگی‌های پایه‌ای لازم اجرا کنید.
برای استفاده معمول از mkosi، اکیداً توصیه می‌کنیم از یک درخت ابزار استفاده کنید.
• 2
در Debian/Kali/Ubuntu ممکن است بسته به اینکه قصد ساخت چه نوع ایمیج توزیعی را دارید،
نصب صریح بسته‌های ubuntu-keyring، ubuntu-archive-keyring،
kali-archive-keyring و/یا debian-archive-keyring علاوه بر apt لازم باشد.
• 2
حداقل نسخه مورد نیاز Python، نگارش 3.9 است.
"فضاهای نام کاربری غیرممتاز (Unprivileged User Namespaces)"
ابزار mkosi برای ایجاد و فعالیت درون فضاهای نام لینوکس (Linux namespaces) به اختیارات نامحدود نیاز دارد.
برخی توزیع‌ها ایجاد یا قابلیت‌های درون فضاهای نام کاربری را محدود می‌کنند که منجر به شکست عملکرد mkosi می‌شود.
برای اطلاعات درباره Ubuntu، که این محدودیت‌ها را با استفاده از AppArmor اعمال می‌کند، ببینید:
https://ubuntu.com/blog/ubuntu-23-10-restricted-unprivileged-user-namespaces
برای فعال‌سازی فضاهای نام کاربری غیرممتاز در اوبونتو، دستورهای زیر را اجرا کنید:
sudo sysctl -w kernel.apparmor_restrict_unprivileged_unconfined=0
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
جهت پایدار ماندن این تنظیمات sysctl در راه‌اندازی‌های مجدد سیستم، فایل
/etc/sysctl.d/unprivileged-userns.conf را با محتوای زیر ایجاد کنید:
kernel.apparmor_restrict_unprivileged_unconfined=0
kernel.apparmor_restrict_unprivileged_userns=0
برای سیستم‌های دیگر، متغیرهای sysctl مربوط به
kernel.unprivileged_userns_clone یا
user.max.user_namespace را بررسی کنید.
"پرسش‌های متداول (FREQUENTLY ASKED QUESTIONS)"
• 2
چرا mkosi vm به همراه KVM در Debian/Kali/Ubuntu کار نمی‌کند؟
2
در حالی که توزیع‌های دیگر با دسترسی به /dev/kvm مشکلی ندارند، در Debian/Kali/Ubuntu این دسترسی فقط برای کاربران عضو گروه kvm مجاز است.
از آنجا که mkosi هنگام اجرا به صورت غیرممتاز یک فضای نام کاربری را unshare می‌کند، حتی اگر کاربر فراخواننده در گروه kvm بوده باشد، با این عمل دسترسی به گروه kvm را از دست می‌دهد و در زمان راه‌اندازی qemu دیگر دسترسی به /dev/kvm وجود نخواهد داشت.
به عنوان یک راهکار موقت، می‌توانید مجوزهای گره‌های دستگاه را به 0666 تغییر دهید که برای کارکرد بدون امتیاز KVM کافی است.
برای ماندگاری این تنظیمات پس از راه‌اندازی مجدد، فایل
/usr/lib/tmpfiles.d/static-nodes-permissions.conf را به
/etc/tmpfiles.d/static-nodes-permissions.conf رونوشت کرده و حالت (mode) دسترسی /dev/kvm را از 0660 به 0666 تغییر دهید.
• 2
چگونه یک کاربر عادی به یک ایمیج بیفزایم؟
2
می‌توانید از قطعه‌کد زیر در یک اسکریپت پس از نصب استفاده کنید:
useradd --create-home --user-group $USER --password "$(openssl passwd -stdin -6 <$USER_PASSWORD_FILE)"
توجه داشته باشید که از نگارش systemd v256 به بعد، در صورت فعال بودن، اگر هیچ کاربر عادی وجود نداشته باشد، سرویس systemd-homed-firstboot.service در نخستین بوت برای ایجاد یک کاربر عادی اعلان درخواست خواهد داد.
• 2
چرا هنگام ساخت ایمیج‌ها با خطای تغییر مالکیت (chown) فایل‌ها مواجه می‌شوم؟
2
هنگامی که به عنوان ریشه (root) اجرا نمی‌کنید، کاربر شما مجاز به تغییر مالکیت فایل‌ها به مالکان دلخواه نیست.
توزیع‌های مختلف هنوز فایل‌هایی را در بسته‌های خود عرضه می‌کنند که متعلق به کاربر root نیستند.
هنگامی که به عنوان root اجرا نمی‌کنید، mkosi هنگام فراخوانی مدیران بسته، کاربر جاری را به root نگاشت می‌کند؛ به این معنی که تغییر مالکیت به root موفق خواهد بود اما تغییر مالکیت به هر کاربر یا گروه دیگر با شکست مواجه می‌شود.
توجه داشته باشید که فراخوانی‌های chown تنها هنگام اجرای مدیران بسته نادیده گرفته می‌شوند، نه هنگام اجرای اسکریپت‌ها.
اگر این کار ضروری باشد (برای مثال در یک اسکریپت ساخت)، می‌توانید متغیر MKOSI_CHROOT_SUPPRESS_CHOWN را روی یک مقدار درست
(1، yes، true) تنظیم کنید تا فراخوانی‌های chown در mkosi-chroot و اسکریپت‌های .chroot نادیده گرفته شوند.
اگر این رفتار باعث اختلال در اجرای برنامه‌ها در ایمیج شما می‌شود، می‌توانید اجرای mkosi با دسترسی ریشه (root) را مد نظر قرار دهید که از این مشکل جلوگیری می‌کند.
روش دیگر، چنانچه اجرای mkosi به عنوان root مطلوب نباشد، این است که با این فرض که نگاشت‌های UID/GID در /etc/subuid و /etc/subgid به درستی پیکربندی شده‌اند، از دستور
unshare --map-auto --map-current-user --setuid 0 --setgid 0 برای تبدیل شدن به root در یک فضای نام کاربری با بیش از یک کاربر استفاده کنید.
توجه داشته باشید که اجرای mkosi به صورت root یا با unshare به این معناست که تمام فایل‌های خروجی تولید شده توسط mkosi دیگر در مالکیت کاربر جاری شما نخواهند بود.
توجه کنید برای سرویس‌های systemd که نیاز به پوشه‌هایی در /var با مالکیت کاربر و گروه سرویس دارند، یک راه جایگزین به جای قرار دادن این دایرکتوری‌ها در بسته‌ها یا ساخت آن‌ها از طریق systemd-tmpfiles، استفاده از StateDirectory=، CacheDirectory= یا LogsDirectory= در فایل سرویس است که به systemd دستور می‌دهد هنگام نخستین شروع سرویس، دایرکتوری را ایجاد کند.
همچنین، می‌توان از دستورالعمل‌های z یا Z برای systemd-tmpfiles استفاده کرد تا مالکیت دایرکتوری‌ها و فایل‌های مختلف هنگام نخستین بوت سیستم به کاربر مالک آن‌ها تغییر یابد.
• 2
چرا portablectl inspect <image>/systemd-dissect <image> اعلام می‌کنند که سرویس قابل‌حمل (portable service) من یک سرویس قابل‌حمل نیست؟
2
دستورهای systemd-dissect و portablectl inspect به دنبال PORTABLE_PREFIXES= در os-release می‌گردند و اگر این کلید وجود نداشته باشد، قادر به شناسایی آن به عنوان یک سرویس قابل‌حمل نخواهند بود و در مورد systemd-dissect علامت ✗ را زیر Use as و برای portablectl عبارت n/a را زیر Portable Service نمایش می‌دهند.
از آنجا که هیچ مقدار پیش‌فرض مناسبی برای این کلید وجود ندارد و ایمیج‌های سرویس قابل‌حملِ تولید شده حتی در صورت تنظیم نبودن این کلید همچنان به درستی متصل (attach) می‌شوند، mkosi مقداری برای آن تنظیم نمی‌کند.
می‌توانید PORTABLE_PREFIXES= را با قرار دادن Environment=PORTABLE_PREFIXES=XXX در پیکربندی mkosi خود تنظیم کنید.
"مراجع (REFERENCES)"
• 2
https://github.com/systemd/mkosi
مخزن اصلی git ابزار mkosi در GitHub
• 2
https://0pointer.net/blog/mkosi-a-tool-for-generating-os-images.html
mkosi — ابزاری برای تولید ایمیج‌های سیستم‌عامل
 پست وبلاگی معرفی نوشته‌ی Lennart Poettering
• 2
https://lwn.net/Articles/726655
ابزار تولید سیستم‌عامل mkosi
 مقاله‌ای در LWN
"همچنین ببینید (SEE ALSO)"
systemd-nspawn(1), systemd-repart(8),
dnf(8)