اولین بار که ویندوز ورودی بوت لینکس من را حذف کرد، ناگهان اتفاق افتاد؛ بدون کرش، بدون هشدار و بدون پیام خطا. تمام کاری که انجام داده بودم این بود که ویندوز را بهروزرسانی کنم و هنگام راهاندازی، رایانهام مستقیماً به ویندوز بوت شد. انگار لینکس هرگز روی رایانه وجود نداشته باشد. تمام پارتیشنهای من سالم باقی ماندند، اما وضعیت firmware من اینطور نبود.
بار اولی که ویندوز ورودی بوت لینوکس من را حذف کرد، ناگهان اتفاق افتاد؛ بدون کرش، بدون هشدار و بدون پیام خطا. تنها کاری که انجام داده بودم بهروزرسانی ویندوز بود و هنگام راهاندازی، کامپیوترم مستقیماً به ویندوز بوت شد. انگار لینوکس هرگز روی این کامپیوتر وجود نداشت. تمام پارتیشنهایم سالم ماندند، اما وضعیت firmware من خراب شد.
دوهبوت کردن آسان است؛ اما این سیستمها یک پارتیشن سیستم EFI مشترک دارند، متغیرهای بوت UEFI را تغییر میدهند، امنیت مبتنی بر TPM را مدیریت میکنند و فایلسیستمهایی را که بهطور کامل به یکدیگر اعتماد ندارند، اداره میکنند. رفتار با آن بهعنوان یک نصب معمول میتواند هزینهبر باشد.
عدم پشتیبانگیری و درک پارتیشن سیستم EFI
این پارتیشن کوچک FAT32 تعیین میکند چه چیزی بوت شود
پارتیشنهای سیستم EFI بین ۱۰۰ مگابایت تا ۵۱۲ مگابایت متغیر هستند و معمولاً بر روی کامپیوترهای مدرن بهصورت FAT32 فرمت میشوند. این پارتیشن در ابزار مدیریت دیسک ویندوز به صورت EFI System Partition ظاهر میشود و لینوکس آن را در مسیر /boot/efi سوار میکند. این پارتیشن شامل شاخه \\EFI\\Microsoft\\Boot است و پس از نصب اوبونتو، شاخه \\EFI\\ubuntu اضافه میشود. پارتیشنهای سیستم EFI شامل Windows Boot Manager و باینریهای EFI GRUB هستند؛ و firmware ابتدا از این مکان بارگذاری میشود پیش از اینکه سیستمعامل شروع کند.
با این حال، علاوه بر فایلهای موجود در ESP، زنجیره بوت شما به شناسههای پارتیشن صحیح وابسته است زیرا grub.cfg که فایل پیکربندی GRUB است، به UUID (شناسه یکتا) ارجاع میدهد. UUID اهمیت زیادی دارد، بهویژه اگر دیسکها را کلون کنید، SSDها را تعویض کنید یا ساختار پارتیشنها را تغییر دهید. ESP بیش از یک مخزن ساده فایل عمل میکند. این پارتیشن و متغیرهای NVRAM UEFI ذخیرهشده در firmware بخشهای جداییناپذیر اکوسیستم بوت هستند.
تلاش برای رفع یک محیط چندبوت معیوب با نصب مجدد GRUB از طریق USB زنده و chroot بهتنهایی کافی نیست. هنگامی که کامپیوتر شما یک عملیات بازیابی بزرگ را انجام میدهد، علاوه بر بازنویسی فایلهای ESP، ویندوز همچنین متغیرهای firmware UEFI را تغییر میدهد. این عمل Windows Boot Manager را دوباره در اولویت قرار میدهد، بنابراین پس از تعمیر، ضروری است ترتیب بوت را در BIOS/UEFI بررسی کنید، چرا که صرفاً بازگرداندن فایلها ترتیب بوت firmware را بازنمیگرداند.
راهحل اضطراری من این است که ESP را دو بار پشتیبانگیری کنم: یک حالت فقط ویندوز، سپس حالت دو‑بوت تأیید شده. این جریان کاری است: پشتیبانگیری، تغییر، دوباره پشتیبانگیری. به محض بروز مشکل، میتوانم از Clonezilla برای بازگرداندن تصویر ESP استفاده کنم قبل از تأیید ترتیب بوت در firmware. بازگرداندن یک پارتیشن ۱۰۰ تا ۵۱۲ مگابایتی بسیار قابلاعتمادتر و سریعتر از ساخت دستی ورودیهای بوت است. تا زمانی که بدون پشتیبانگیری از ESP دو‑بوت کنید، هر فاجعهی بعدی تنها یک بهروزرسانی دور است.
عدم مدیریت BitLocker، Secure Boot و وضعیت TPM
امنیت ویندوز فرض میکند کنترل زنجیره بوت را دارد
ویندوز ۱۱ بهطور معمول BitLocker را بهصورت پیشفرض در سیستمهای جدید و پیشساخته فعال میکند، بهویژه در دستگاههایی که TPM 2.0 دارند، یک تراشه امنیتی بر روی مادربورد کامپیوتر. ویژگی BitLocker رمزگشایی دیسک را به یکپارچگی بوتلودر و پیکربندی firmware پیوند میدهد که دو مؤلفهٔ اندازهگیریشدهٔ بوت هستند. سیستمعامل فرض میکند که در صورت تغییر هریک از این اندازهگیریها دستکاری رخ داده است و در آن لحظه TPM انتشار Volume Master Key را رد میکند.
با این حال، در حالی که میتوانید بین تعلیق و غیرفعالسازی BitLocker انتخاب کنید، این دو بهطور بحرانی متفاوت هستند. تعلیق موقت است و درایو را رمزگشایی نمیکند یا ارتباط آن با TPM را قطع نمیکند. خاموش کردن BitLocker، در مقابل، یک فرآیند کامل رمزگشایی است و گزینهٔ بهتری است اگر نیاز به تغییر اندازه پارتیشنها یا اصلاح پیکربندی بوت داشته باشید. میتوانید دستور زیر را برای تأیید وضعیت BitLocker در ویندوز اجرا کنید:
manage-bde -status
برای غیرفعالسازی BitLocker این فرمان را اجرا کنید: manage-bde -off C:
لایهٔ دیگر برای در نظر گرفتن Secure Boot است. برخی توزیعات بزرگ مانند اوبونتو، OpenSUSE و فدورا بوتلودرهای امضاشده دارند و میتوانند Secure Boot را پشتیبانی کنند. اما توزیعات دیگر بوتلودر امضا نشده دارند و ممکن است تحت Secure Boot شکست بخورد. نمیتوانید تضمین کنید ابزار اصلی بازیابی شما با Secure Boot فعال چگونه رفتار کند. من قبل از نصب آن را غیرفعال کردم. این به این معنی نیست که لینوکس نمیتواند با آن کار کند، بلکه باعث میشود بازیابی غیرقابل پیشبینی شود.
مشکلات واقعی TPM از تعویض درایوها ناشی میشود. در بعضی ماشینها که SSDها را تعویض کردم، دیدم ویندوز زمینهٔ بوت قبلی را نامعتبر میسازد. این کار احراز هویت با رمزعبور را اجبار میکند و اولویت بوت را بازنویسی میکند. بنابراین، اگرچه لینوکس پاک نشده بود، دیگر اولین گزینه نبود. پس از نصب هر دو سیستمعامل، تغییر وضعیت TPM، Secure Boot یا تنظیمات امنیتی firmware را Avoid کنید، زیرا این اقدامات بیطرف نیستند. فریز کردن تنظیمات امنیتی پس از نصب هر دو سیستمعامل برای پایداری ضروری است.
فرض اینکه ویندوز بارگردانی بوت لودر شما را انجام ندهد
بهروزرسانیهای ویژگی و بازیابی تنظیم مجدد اولویتهای UEFI
بهروزرسانیهای نسخهٔ ویندوز یک مشکل ایجاد میکنند. این فرآیند معمولاً ورودیهای بوت UEFI دستگاه شما را بازنشانی میکند. در حالی که بهروزرسانی GRUB را دستنخورده میگذارد، ویندوز GRUB را در NVRAM firmware اولویتبندی نمیکند. این باعث میشود بهنظر برسد لینوکس حذف شده است.
بازیابی ویندوز میتواند حتی مخربتر باشد زیرا دادههای پیکربندی بوت را داخل ESP بازسازی میکند و ورودیهای EFI لینوکس بازنویسی میشوند. یک پارتیشن که لینوکس را دارد ممکن است سالم باشد، اما firmware ممکن است هنوز نتواند به آن اشاره کند. در حالی که دادهها حفظ میشوند، مسیر بوت خراب میشود.
من معمولاً Fast Startup را روی کامپیوترم غیرفعال میکنم. یک مشکل این است که این ویژگی پرچمهای firmware را تنظیم میکند تا پس از نوشتن هسته ویندوز به فایل هیبرنیشن، یک بوت ترکیبی انجام دهد. چون این فرآیند میتواند منوی بوت عادی را دور بزند، بهنظر میرسد سیستم GRUB را نادیده گرفته است.
ممکن است نتوانید بهطور دائم در برابر بازاولویتبندی خود ویندوز پس از یک بهروزرسانی بزرگ دفاع کنید. هر گونه دفاعی که اعمال میکنید باید procedural باشد: یک پشتیبانگیری فعلی از ESP نگه دارید، پس از بهروزرسانیهای ویژگی ترتیب بوت را بررسی کنید و انتظار تداخلهای گاهبهگاه را داشته باشید. تنها راه پیشبینیپذیر کردن دو‑بوت این است که فرض کنید ویندوز زیرساخت مشترک بوت شما را حفظ نمیکند.
نگاه راحت به پارتیشنها و فایلسیستمهای مشترک
تغییر اندازه NTFS و ذخیرهسازی بینسیستمی نیاز به انضباط دارد
کاهش حجم ویندوز بهصورت ایمن غیرقابل مذاکره است، به این معنا که اگر NTFS در وضعیت تمیزی نباشد نمیتوانید آن را تغییر اندازه دهید. ویژگی Fast Startup بهصورت پیشفرض فعال است و معمولاً NTFS را در حالت نیمه‑هیبرنیت قرار میدهد، که خطر فساد را افزایش میدهد. باید Fast Startup را غیرفعال کنید، هیبرنیشن را غیرفعال کنید و BitLocker را بهطور کامل رمزگشایی کنید؛ فقط پس از این میتوانید پارتیشن را با استفاده از Windows Disk Management بهصورت امن کوچک کنید. من همیشه پس از آن ابزار chkdsk را اجرا میکنم تا یکپارچگی را تأیید کنم.
گزارش MUO: عضو شوید و هرگز از مهمترین مطالب محروم نشوید
ویندوز دارای چهار پارتیشن است و باید به آنها توجه کنید:
- پارتیشن سیستم EFI (FAT32)
- پارتیشن رزرو شده مایکروسافت (مخفی، حدود ۱۶ مگابایت)
- ویندوز C: (NTFS)
- گاهی اوقات، یک پارتیشن بازیابی ویندوز
میتوانید پارتیشن رزرو شده مایکروسافت را در ابزارهای لینوکس ببینید، اما در ویندوز مخفی است. بنابراین بهصورت فنی میتوانید آن را حذف کنید. اما اگر مدیریت دیسک ویندوز را بهطور کامل درک نکنید، حذف آن میتواند اشتباه بزرگی باشد زیرا برای برخی عملیات دیسک اساسی است و متادیتا را مدیریت میکند.
در فرآیندهای بازیابی، ویندوز احتمالاً ext4 یا Btrfs را بهعنوان فضای تخصیصنشده در نظر میگیرد زیرا آنها را نمیفهمد. انتخاب عملی برای دادههای مشترک NTFS است. با این حال، اگر ویندوز خاموش شود و لینوکس آن پارتیشن NTFS را بهصورت خواند و نوشتن سوار کند، ممکن است فساد رخ دهد. ایدهآل این است که قبل از بوت به لینوکس، یک خاموشی واقعی انجام دهید؛ بدون Fast Startup.
جایی که دو‑بوت شکست میخورد
زمانی که دو‑بوت شکست میخورد، این اتفاق در مرزهای firmware، مرزهای رمزنگاری و مرزهای فایلسیستم رخ میدهد. باید در این نقاط احتیاط اضافی کنید. اگر ESP را پشتیبانگیری کنید، وضعیت امنیتی firmware را ثابت نگه دارید، انتظار داشته باشید ویندوز ترتیب بوت را بازنشانی کند و NTFS را بهدرستی مدیریت کنید، از فاجعه جلوگیری خواهید کرد.
شما از فلشدرایوهای USB برای انتقال فایلها بین کامپیوترها و پشتیبانگیری استفاده کردهاید، اما کارهای بسیار بیشتری میتوانید با یک فلشدرایو انجام دهید.