I'm a novice user. I've struggled with topics like eufi,gpt,grub etc.
I want to remove/add drives into my box without things getting screwed up when the drive with WinBootLoader has been removed or is now drive 2.
Drive 1 = Windows 10 3TB. uefi/gpt about 6 partitions (currently not booting)
Drive 2 = Windows 7 3TB. uefi/gpt about 5 partitions
Drive 3 = Linux (Future Planned) 60 GB.
I want to chainload, from a usb drive, to any hard drive's OS. I also want to be able to use the contents of the other drives. Write to first block of the USB drive, rather than have a bootloader write to first block of a HDD, and screw stuff up.
Perhaps my research is out of date, but it seems this is difficult. Especially because I want to boot to Windows (not linux) from the USB, and also because the 3tb drives are UEFI (due to their size).
At the end of the day I want to remove all but 1 drive, and remove the USB, make the appropriate changes in BIOS, and have it boot. How can I do this?
If it's doable, I hope can rescue a failing drive that is mbr - Is that doable under the same scheme? Pretty certain the USB has to be uefi.
Answer
The simplest way to achieve your goal is likely to be placing a boot manager on the USB flash drive and configuring it to boot either Windows installation. My own rEFInd can do this pretty easily, since it scans all readable volumes and builds a boot menu on a per-boot basis. In fact, there's a USB flash drive image available on the rEFInd downloads page that should do the job without modifications. Other boot managers can also be configured to do this, although most rely on static configuration files that you'll need to maintain manually.
Another approach is to install Windows 7 on drive #1, copy its Windows boot loader file (EFI/Microsoft/Boot/bootmgfw.efi) to the fallback filename (EFI/BOOT/bootx64.efi), unplug the drive, install Windows 10 on drive #2, and then copy its boot loader file to the fallback filename. (These file operations are done on the EFI System Partition (ESP).) When you add Linux to the mix, though, things get more complex; you'd need to either use rEFInd or move GRUB to the fallback filename and ensure the GRUB configuration file has entries for both Windows installations. This approach would not involve the USB drive (unless you put the ESP or the Linux /boot partition on the USB drive.) Keeping this working will require extra attention, since most distributions update their GRUB configuration files whenever the kernel or GRUB is updated, and if a disk is unplugged when this happens, any OSes installed on it will be omitted from the updated GRUB menu.
Stepping back a bit, the old trick of unplugging disks to ensure that OS A can't damage OS B (installed on a different disk) is more difficult under EFI than under BIOS, since EFIs store boot paths in NVRAM, and may delete a boot path when they detect that it's no longer valid. Thus, drive-swapping creates new problems that don't exist under BIOS. The rEFInd-on-USB approach bypasses this problem by using a replacement boot manager (I focused on rEFInd, although others can work) that scans for boot loaders at every boot rather than relying on built-in NVRAM entries. In this scenario, rEFInd is installed to the fallback filename on the USB drive, which is the normal way to boot a removable medium. My second approach bypasses the problem by using the fallback filename on regular hard disks -- but as I noted, GRUB has an analogous problem, so care must be taken with package updates. The point of this paragraph is that you might want to reconsider your approach. Isolating OSes from each other by physically plugging and unplugging cables has its benefits, but it also creates problems, especially under EFI.
No comments:
Post a Comment