uefi ntfs

UEFI: NTFS - Boot NTFS أو أقسام exfat من UEFI

UEFI: NTFS هو محمل تمهيد عام ، مصمم للسماح بالتمهيد من NTFS أو أقسام exfat ، في وضع UEFI النقي ، حتى لو لم يدعمه نظامك. هذا مخصص في المقام الأول للاستخدام مع RUFUS ، ولكن يمكن أيضًا استخدامه بشكل مستقل.

بمعنى آخر ، تم تصميم UEFI: NTFS لإزالة القيود ، التي لدى معظم أنظمة UEFI ، من توفير دعم التمهيد فقط من قسم FAT32 ، وتمكين القدرة على التمهيد أيضًا من أقسام NTFS.

يمكن استخدام هذا ، على سبيل المثال ، لتوصيل وسائط تثبيت Windows NTFS ، والتي تحتوي على install.wim wim أكبر من 4 جيجابايت (شيء لا يمكن أن يدعمه FAT32) أو للسماح BIOS + UEFI بمحركات "Windows".

جانبا ، ولأن هناك الكثير من المعلومات غير الدقيقة حول هذا الموضوع على الإنترنت ، يجب التأكيد على أنه لا يوجد شيء على الإطلاق في مواصفات UEFI التي تجبر في الواقع استخدام FAT32 لتمهيد UEFI. على العكس من ذلك ، ستقوم UEFI بالتمهيد بسعادة من أي نظام ملفات ، طالما أن البرنامج الثابت الخاص بك يحتوي على برنامج تشغيل له. على هذا النحو ، فإن اختيار الشركات المصنعة للنظام فقط ، الذين يميلون إلى تضمين برنامج تشغيل لـ FAT32 ، هو الذي يحد من إمكانيات التمهيد الافتراضية لـ UEFI ، وهذا يؤدي إلى الاعتقاد خطأً بأن FAT32 فقط يمكن استخدامها في حذاء UEFI.

ومع ذلك ، كما هو موضح في هذا المشروع ، من الممكن للغاية العمل حول هذا القيد وتمكين أي برامج ثابتة UEFI من التمهيد من أنظمة ملفات غير FAT32.

ملخص

الطريقة التي تعمل بها UEFI: NTFS ، بالاقتران مع Rufus ، كما يلي:

• يقوم Rufus بإنشاء أقسام على قرص USB المستهدف (يمكن أن تكون هذه الأقسام MBR أو GPT). الأول هو قسم NTFS يشغل جميع محرك الأقراص تقريبًا ، والذي يحتوي على ملفات Windows (لكي تنطلق Windows ، أو للتثبيت العادي) ، والثاني هو قسم صغير جدًا من الدهون ، يقع في النهاية ، والذي يحتوي على برنامج تشغيل NTFS UEFI (انظر Https://efi.iake.ie) بالإضافة إلى uefi: ntfs.
• عندما يتم تجاهل USB Drive في وضع UEFI ، يتم تجاهل قسم NTFS الأول بواسطة برنامج UEFI الثابت (ما لم يتضمن هذا البرنامج الثابت بالفعل برنامج تشغيل NTFS ، وفي هذه الحالة ، سيتم تنفيذ خيارات التمهيد 2 ، والتي تؤدي نفس الشيء) و UEFI: NTFS Bootloader من قسم الدهون القابل للتمهيد.
• UEFI: يقوم NTFS بعد ذلك بتحميل برنامج تشغيل NTFS uefi ذي الصلة ، ويحدد موقع NTFS الحالي على نفس الوسائط ، ويقوم بتنفيذ /efi/boot/bootia32.efi ، /efi/boot/bootx64.efi ، /efi/boot/bootarm.efi أو /efi/boot/bootaa64.efi ذلك. هذا يحقق نفس النتيجة بالضبط كما لو أن البرامج الثابتة UEFI لديها دعم أصلي لـ NTFs ويمكنه التمهيد مباشرة منه.

تأمين توافق الحذاء

• UEFI: NTFS متوافق مع الحذاء الآمن وتم توقيعه بواسطة Microsoft.

• يمكنك العثور على ثنائيات موقعة من الحذاء الآمنة (لـ X86_64 و X86_32 و ARM64) في أرشيف uefi-ntfs.img من RUFUS.

• ومع ذلك ، لاحظ أنه نظرًا لقيود Microsoft التعسفية المتعلقة GPLV3 ، فإن الدوافع الوحيدة التي يمكن استخدامها حاليًا مع UEFI: NTFs في بيئة التمهيد الآمنة هي تلك المرخصة NTFS-3G المرخصة. على وجه الخصوص ، لا يمكن تقديم برامج تشغيل NTFS و EXFAT من EFIFs ، والتي يتم اشتقاقها من Grub 2.0 ، وبالتالي GPLV3 ، إلى Microsoft للتوقيع.

• أخيرًا ، تتطلب سياسات توقيع الحذاء الآمنة الحالية من Microsoft التحقق من صحة إضافية للذراع 32 بت ، وبالتالي فإن ثنائيات الذراع 32 بت غير آمنة. لا يؤثر هذا على ذراع 64 بت (ويعرف أيضًا باسم ARM64 / AARCH64 / AA64 ) والتي لدينا ثنائيات موقعة تمامًا من الحذاء.

المتطلبات الأساسية

• Visual Studio 2022 أو Mingw/Mingw64 (يفضل تثبيته باستخدام MSYS2) أو GCC
• QEMU v2.7 أو أحدث (NB: يمكنك العثور على ثنائيات Windows QEMU هنا)
• غيت
• wget ، unzip ، إذا لم تستخدم Visual Studio

تهيئة الوحدة الفرعية

للراحة ، يمكن تجميع المشروع مقابل مكتبة GNU-EFI بدلاً من EDK2 ، لذلك قد تحتاج إلى تهيئة الجهاز الفرعي GIT مع:

 git submodule update --init

التجميع والاختبار

• إذا كنت تستخدم حل Visual Studio ( .sln ) ، ما عليك سوى الضغط على F5 لتجميع التطبيق وإطلاقه في محاكي QEMU.

• إذا كنت تستخدم GCC مع GNU-EFI ، فيجب أن تكون قادرًا على إصدار make .
  إذا لزم الأمر ، يمكنك أيضًا إصدار شيء مثل make ARCH=<arch> CROSS_COMPILE=<tuple> حيث يكون <arch> واحدًا من ia32 و x64 أو arm أو aa64 و TUPLE هو واحد من أجل المقطع العرضي الخاص بك (مثل aarch64-linux-gnu- ).
  يمكنك أيضًا التصحيح من خلال QEMU من خلال تحديد qemu make الاحتجاج. ومع ذلك ، كن على دراية بأن هذا يعمل على تشغيل وضع _DEBUG الخاص ، ويجب أن تعمل دون استدعاء qemu لإنتاج ثنائيات الإصدار المناسبة.

• إذا كنت تستخدم VS2022 مع EDK2 على Windows ، على افتراض أن دليل EDK2 الخاص بك في D:edk2 وأن nasm موجود في D:edk2BaseToolsBinWin32 ، يجب أن تكون قادرًا على إصدار:

    set EDK2_PATH=D:edk2
    set NASM_PREFIX=D:edk2BaseToolsBinWin32
    set WORKSPACE=%CD%
    set PACKAGES_PATH=%WORKSPACE%;%EDK2_PATH%
    %EDK2_PATH%edksetup.bat reconfig
    build -a X64 -b RELEASE -t VS2022 -p uefi-ntfs.dsc
  

• إذا كنت تستخدم GCC مع EDK2 على Linux ، وافتراض أن دليل EDK2 الخاص بك موجود في /usr/src/edk2 :

    export EDK2_PATH="/usr/src/edk2"
    export WORKSPACE=$PWD
    export PACKAGES_PATH=$WORKSPACE:$EDK2_PATH
    . $EDK2_PATH/edksetup.sh --reconfig
    build -a X64 -b RELEASE -t GCC5 -p uefi-ntfs.dsc
  

تنزيل وتثبيت

يمكنك العثور على صورة تقسيم الدهون جاهزة للاستخدام ، تحتوي على إصدارات X86 و ARM من UEFI: NTFS Loader (كلاهما 32 و 64 بت) وسائق في مشروع RUFUS ، تحت /RES /UEFI.

إذا قمت بإنشاء قسم من نفس الحجم في نهاية محرك الأقراص ونسخ uefi-ntfs.img هناك (في وضع DD بالطبع) ، فيجب أن يكون لديك كل ما تحتاجه لجعل أول قسم NTFS على محرك الأقراص UEFI قابل للتشغيل.

Visual Studio 2022 و ARM/ARM64

يرجى النظر في أنه لتمكين دعم تجميع ARM أو ARM64 في Visual Studio 2022 ، يجب عليك الانتقال إلى شاشة المكونات الفردية في تطبيق الإعداد وتحديد أدوات الإنشاء ARM/ARM64 هناك ، حيث لا تظهر في شاشة عبء العمل الافتراضية: