Dual Boot C7 With Window 10

Home » CentOS » Dual Boot C7 With Window 10
CentOS 11 Comments

I have a laptop with windows 10. I went into the Windows disk manager and shrunk the volume to make room for C7. That worked.

I also changed the BIOS from secure boot to “both” (secure/legacy)

I installed C7, went fine. About the time it was done I realized I never saw anything about “other” boot options (seems I saw that in the past).

Anyway sure enough, got done and C7 boots fine – no option there for Windows. I did searching and found I needed to add to the
/etc/grub.d/40_custom the following:
menuentry “Windows 10” {
set root='(hd0,1)’
chainloader +1
}

then re-run the grub2-mkconfig -o /boot/grub2/grub.cfg

I then rebooted and sure enough I got the menu item for “Windows 10”
however when I select it it does not boot.

How do I get Windows 10 to boot again ?

Thanks,

Jerry

11 thoughts on - Dual Boot C7 With Window 10

  • On my laptop, with windows-7, I have two differences.

    set root=(hd0,2)

    not … “(hd0,1)”. I also don’t have quotes, as you show, around that.

    insmod ntfs

    between the “menuentry” and “set root” lines.

    Exactly where your windows partition lives may vary, so you may need to play with that a little.

  • Thanks…

    I added the “insmod ntfs” re-ran config no boot… I change the hd1 to hd3 re-ran config no boot…

    This is what my partition table looks like.

    # Start End Size Type Name
    1 2048 534527 260M EFI System EFI system partition
    2 534528 567295 16M Microsoft reser Microsoft reserved partition
    3 567296 525326335 250.2G Microsoft basic Basic data partition
    4 998166528 1000214527 1000M Windows recover Basic data partition
    5 525326336 525330431 2M BIOS boot parti
    6 525330432 965732351 210G Microsoft basic
    7 965732352 982509567 8G Linux swap

    Thoughts?

    jerry

  • On CentOS 7, the NTFS filesystem is not installed by default. Make sure you have ntfs-3g and ntfsprogs both installed. You’ll need to configure the epel repo before you can install them.

    Fred

  • partition
    Microsoft reserved partition
    partition
    Basic data partition
    boot parti

    You need at least ntfs-3g to mount a ntfs partition from the linux side, but not for the booting on a dual-boot.

    On my c7/window7 machine, the windows boot partition that I have in the grub line is labeled type “boot” (filesystem ntfs) in the output from “parted /dev/sda print”. Based on that my bet is that it’s your partition 5 that you need to put there, but you may need to do some more probing to confirm that.

    As I’m avoiding windows10, I don’t know that they are still using ntfs.

  • Jerry Geis wrote:
    partition 2 534528 567295 16M Microsoft reser Microsoft reserved partition 4 998166528 1000214527 1000M Windows recover Basic data partition 5 525326336 525330431 2M BIOS boot parti

    I haven’t been following this, and perhaps I’m being dense… but I see BIOS boot partition, and I see 8G of Linux swap… where’s the Linux /boot and / partitions?

    mark

    PS: *FSCK* ix.manitu

  • Hi All,

    Partition 5 is what the linux partitioning add… Partition 6 is LINUX – Why it shows up as Microsoft Basic I dont know. Partition 7 is the normal swap

    I have tried booting partition 1 and it says.
    “an operating system wasnt found.”

    When booting partion 3 I get a screen “WINDOWS BOOT MANAGER”
    windows failed to start. A recent hardware change might the cause it wants a wnidwos install disk and says FILE: \Boot\BCD
    status 0xc0000225

    Thoughts?

    Jerry

    Jerry

  • Both is a problem. There’s no practical way for an installer to support both. Basically it makes the computer UEFI for Windows and BIOS for CentOS 7 instead of UEFI for both.

    You’ll have to use the firmware’s boot manager. The legacy mode enables a compatibility support module (CSM) so that UEFI presents a faux-BIOS to the operating system, Cent OS in this case. So Cent OS
    thinks it’s on a BIOS system, and installs a BIOS based bootloader. A
    BIOS bootloader cannot chainload a UEFI bootloader.

    What you should revert back to UEFI only, with Secure Boot enabled, and reinstall CentOS, deleting the previous partition/mount points including the BIOS Boot partition that was created for CentOS’s bootloader.

    The gotcha is that with Secure Boot enabled, the CentOS GRUB-efi package doesn’t support chainloading the Windows bootloader. This is getting fixed in Fedora 24 but I have no idea how long it’ll take to get to CentOS 7. You could either disable Secure Boot (which I don’t recommend) or you switch between CentOS and Windows using the firmware’s boot manager. You’ll have to figure out which F key brings up the boot manager. On my Intel NUC it’s F10, *shrug*.

  • CentOS 7 has inherited an old bug/bad design choice by parted developers, where they decided to use the partition type GUID for
    “basic data” that Microsoft came up with, rather than following the UEFI spec and creating their own partition type GUID for Linux filesystems. Presumably partition 3 is Windows on NTFS, and partition
    6 is a conventional partition with combined /boot / and /home. Just a guess.

    It’s not a bad idea to get gdisk on the system, and change the type code for the linux partition to gdisk code 8300, which translates to partition type GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4. Windows 10
    will ignore this, where at least Windows 8 and older invited the user to format anything with the “basic data” GUID that had a file system it didn’t recognize.

  • Chris Murphy wrote:

    May I ask a couple of questions which I’m afraid betray my ignorance.

    1. Why is it advisable to “revert back to UEFI”?
    Is this just a safety measure?
    I would have thought that if an intruder had got in this far, enabling him to install unsigned modules, he would have you at his mercy anyway?

    2. I installed CentOS-7.2.1511 from a Live USB stick, and I have a Windows 10 partition that I can boot into. So I assume that UEFI is not used by default?
    Will it become so at some point?

  • It’s much safer to betray ignorance and ask the question than end up stuck in the mud. It’s not your fault, we’ve kinda been betrayed with these changes with a combination of overly complicated implementation, massive piles of bugs, hideous documentation, and misleading terminology reusage (mainly by the manufacturers).

    Windows is already installed in UEFI mode. Mixed installations are just a PITA to support. You’ll get almost no help from anyone on a list because how this works will be firmware dependent and chances are no one else will have that same make/model and firmware revision.

    And yes, I can’t in good conscience recommend a setting that makes you less safe. The computer came to you with Secure Boot enabled, and you’re best off leaving it in that condition. CentOS 7 supports UEFI
    Secure Boot out the box. What it doesn’t support is dual boot, but that’s technically true even if Secure Boot is disabled, or this were a system with BIOS firmware. But the firmware boot manager can provide you with a way to switch between the two. Firmware setup might even have an option in there somewhere to present the boot manager by default for each boot. This is true on my Intel NUC which uses American Megatrends firmware.

    There are levels of compromise. The bootloader malware compromise means you can reformat and still be owned. Secure Boot pretty much assures that you’re not compromised except in user space, which is why you run with SELinux enabled, right?

    If your firmware setup has an option for Secure Boot and/or “legacy”
    anything, then it is UEFI firmware. Strictly speaking, UEFI != BIOS
    but the manufacturers think we’re all morons so they repurposed BIOS
    to apply to a completely different behavior of firmware, completely different discovery of the bootloader method, completely different bootloader installation and location for the binaries. Anything that comes with Windows 10 pre-installed has UEFI firmware, with Secure Boot enabled and any legacy option disabled as a requirement of the Windows hardware certification spec.

    And CentOS can support that condition, you’re best off not just security wise, but in terms of getting support on lists the less you customize things at a firmware level. And changing to a hybrid UEFI
    CSM-BIOS mode is a mess. If it works for you, great, and if some expert wants to hand hold, fine, but it’s not something I recommend. It’s already complicated enough, I think it’s made worse by enabling legacy stuff.

  • Oh and I can’t stress enough to check for firmware updates. There’s metric tons of UEFI bugs. This little baby NUC has had 6 firmware updates in 9 months. Some updates don’t fix things I care about, others do, and the changelogs aren’t always really detailed when it comes to thinks like user interface improvements or bug fixes.