I have a windows 8.1 installed in my lenovo z570.I installed linux mint 17 from an USB created using YUMI software. After installation the grub menu doesn't appear and windows gets booted up automatically.I turned off fast startup in windows also.I read that i should turn of secure boot as well.But in msinfo32 it shows secure boot : unsupported.I also tried grub-repair from a live cd.Still i am not able to get the grub boot menu.What would be the problem??

  • You're a lot more likely to have better luck eschewing grub altogether. UEFI + boot loader = unnecessary redundancy. See this. – mikeserv Aug 17 '14 at 4:01
  • I tried doing the same thing in my friend's laptop. But his bios has an option to change the type of bios .i.e. Legacy bios or UEFI.When i set it to legacy bios directly linux mint boots up and when i set it to UEFI windows gets booted up directly..But my bios doesn't have any such option.how can i boot into legacy mode? – srinivas Aug 20 '14 at 1:21
  • Well - without reinstalling Windows, you can't, unless you want to change that option in firmware everytime. But you don't want the legacy boot anyway. I wrote a script the other day - almost finished it - that creates bootable Mint installer UEFI USB disk image... Hang on... How is the Mint disk formatted? Is it just flat FAT? Or...? Wait - I've got it. If it boots right up I know what to do... – mikeserv Aug 20 '14 at 1:25
  • The bootable mint usb disk is in fat 32 with mbr partition style – srinivas Aug 20 '14 at 1:47

The answer to this question is multi-faceted.


The very first thing you must do is try to forget any BIOS-related boot knowledge you might have - it doesn't apply here. There is no MBR, there is no second-stage boot-loader, there is no boot partition. Those things are thankfully fast becoming as obsolete as the quarter-century old 16-bit BIOS INT-13H real-mode disk interface they were designed to prop-up.


Next you need to think about boot execution. When your computer starts up the firmware does a few things before calling on an EFI executable - your operating system kernel or some redundant chain-loader that is instructed to call on your operating system kernel.


It will first check power and interrupts then check video. It either calls on an older real-mode video BIOS oprom and waits for it to complete or it detects a protected-mode GOP video rom, throws a switch, and moves on. This is, in large-part, what is meant by fast-boot in most interfaces. Either the firmware must handle the real-mode bit with its CSM (compatibility support module) or it can implement a few GOP standards automatically and leave the rest of the video initialization to the OS it will soon call upon. You, apparently, have a GOP compatible video-card. Taking full advantage of this feature is not a Windows-specific option.


It will also load whatever UEFI-drivers the OEM has stored in flash-memory on your main-board, but, for the most part, we can ignore this, with the primary exception being the FAT filesystem driver. As I mentioned before, there is no MBR or boot partition, but there is an EFI-system partition. The two are fundamentally different in that the former was a partition from which the BIOS firmware would read in the first sector of the raw disk and execute whatever code it found there, whereas the latter is a partition that is mounted by the UEFI firmware as a file-system and from which it will execute a file.


There is at maximum one esp flagged partition per GPT formatted disk. You already have a GPT-formatted hard-disk else you would never have fast-booted Windows in the first place. The type of format of your USB disk is, at this point, unknown to me. For some UEFI firmwares removable disks are special cases in that they need not be flagged esp if they have no partition table at all - in other words it is often possible to boot from a USB-disk that was never partitioned and is formatted in whole with a FAT file-system. This is not necessarily a reliable feature, but it is common.


When the firmware mounts the esp partition it loads a path which it has stored in memory. The memory module is an on-board NVRAM chip on which the firmware stores information it will need between boots - such as the Boot0000-{GUID} variable. In your case the contents of this variable is very likely ${ESP-GUID}\EFI\BOOT\BOOTx64.efi which almost always points to Microsoft's own boot-manager - (which is not BOOTMGR.efi, by the way - it comes later in MS's boot process).


Commonly you can just:

mv ${ESP}/EFI/BOOT/BOOTx64.efi ${ESP}/EFI/BOOT/BOOTx64.efi.bak
mv ./${mybootmgr}.efi ${ESP}/EFI/BOOT/BOOTx64.efi

...without ever editing an NVRAM variable at all.


When booted in EFI-mode the Linux kernel should automatically load its efivarfs kernel module and mount the NVRAM contents in /sys/firmware/efi/efivars. You can ls that directory and see the names of all of your efi variables. Here's the contents of my Boot0002-{GUID} variable:

 printf %b $(
     od -An -t o1 -w1 -v \
         /sys/firmware/efi/efivars/Boot0002-* | 
     sed 's/ */\\0/'

The nonsense chars there are a result of UEFI's UTF-16 encoding as opposed to my Linux system's UTF-8 encoding. In any case, just imagine that the nonsense bit is my esp's GUID. I guess I no longer have a Boot0000-{GUID} variable - I must have deleted it at some point.


If I did, I probably did it using the efibootmgr program. If you call it without any arguments it will print your boot order.

BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0002,000F,000D
Boot0002* UEFI: KINGSTON SV300S37A120G
Boot000D* Hard Drive 
Boot000F* CD/DVD Drive 

Here's a snip of its man page:

man efibootmgr 2>/dev/null | 
sed '/^ *DESCRIPTION/,/^ *OPTIONS/!d;//c\\'
   efibootmgr is a userspace application used to  mod‐
   ify  the  Intel Extensible Firmware Interface (EFI)
   Boot Manager.   This  application  can  create  and
   destroy boot entries, change the boot order, change
   the next running boot option, and more.
   Details on the EFI Boot Manager are available  from
   the  EFI  Specification,  v1.02 or later, available
          Note: efibootmgr requires  that  the  kernel
          support access to EFI non-volatile variables
          through      /sys/firmware/efi/vars       or


My own recommendation is that you follow along from this point to this other answer of mine and from there to rodsbooks.com as is also linked there and that you forego grub altogether - it is an unnecessary complication in your case, as I hope you will soon see. But regardless of whether or not you choose grub as the EFI-executable your firmware will call upon at boot-time, you should really read rodsbooks.com.


The following bit of shell should - given default choices during the Mint installation process - be capable of converting your MBR flash drive to a UEFI bootable GPT-formatted drive with its own EFI system partition and boot manager. You can add other installations to this same stick easily - even Windows installations with a little care - and it is far easier to maintain in the long-run. I will confess I am a little dubious about the tar bit as I feel like I should be specifying some command-line options for preserving file-system permissions (hopefully someone knows better?). Still, it seemed to work fine for me in qemu - I went from a bootable USB Mint Live disk to a bootable USB Mint Live disk.

You should note though that if you were to configure your primary bootable partition with a satisfactory boot manager - such as rEFInd - you likely could boot a legacy formatted boot disk such as you have now.

If you run the following please take care to fill in the BIG_LONG_TAR_BACKUP_LOCATION_VAR_PATH with a path that is not located within the /tmp/usbwd directory path that it creates because it will also delete this directory when it is through. You will need at least the unzip, tar, gdisk, wget, and coreutils packages installed for it to work -- all of which are already likely installed on any Linux live bootable disk you would care to try, but are also available via any package manager I can think of.

mkdir -p /tmp/usbwd/mintmnt; cd /tmp/usbwd; mkdir esp
wget -qO ./refind.zip \
unzip -qq ./refind.zip
sudo sh -se -- "/dev/${USBDISK}" \
    mount "${1}1" ./mintmnt
    tar -C ./mintmnt -czf "$2" ./; umount ./mintmnt
    printf %s\\n o y n '' '' \+750M ef00 n 2 '' '' '' w y |
        gdisk "${1}" || :
    mkfs.vfat -n USBESP "${1}1"
    ./refind*/install.sh --usedefault "${1}1"
    mkfs.${YOUR_FS_OF_CHOICE=ext4} -L MINTROOT "${1}2"
    mount "${1}1" ./esp; mount "${1}2" ./mintmnt
    mkdir ./esp/EFI/mintboot
    >./esp/EFI/mintboot/refind_linux.conf \
        printf %s\  \
            '"Linux Mint"' \
            '"root=/dev/disk/by-label/MINTROOT quiet splash"'
    cd ./mintmnt && tar -xzf "$2"
    >>./etc/fstab \
        printf %s\\n \
            '/dev/disk/by-label/USBESP /esp vfat defaults 0 1' \
            '/esp/EFI/mintboot /boot none bind,defaults 0 0'
    cp -T ../esp/EFI/mintboot ./boot/vmlinuz* ./boot/init*
    cd ..; umount ./mintmnt; umount ./esp
    cd ~; rm -rf /tmp/usbwd
  • what boot loader should i install.and for the two mv commands you mentioned i should be able to login linux right? Should i use a live cd and execute those commands? – srinivas Aug 19 '14 at 14:39
  • @srinivas - is Linux Mint definitely installed to the USB disc? If so, can do sudo partx -svb /dev/${your_usb_disk_device} and paste it in the question? – mikeserv Aug 19 '14 at 14:51
  • I am just installing Linux mint by booting it from the pen drive. The os is installed in one of my ext4 partitions only – srinivas Aug 20 '14 at 1:33
  • @srinivas - But that's the thing - while some do, many UEFI firmwares do not allow you to boot in legacy BIOS mode without setting a configuration in firmware (if they provide a legacy boot mode at all) to toggle between the UEFI mode and BIOS CSM mode. So the switch would mean that for every time you wanted to boot Windows you'd have to change the UEFI config setting and vice versa for the USB disk. A boot manager might handle such a thing for you - as I note in the answer - but until you work that out you're stuck. PLEASE read rodbooks.com and learn about this. – mikeserv Aug 20 '14 at 2:59
  • Thanks a lot man for your effort! I ll try this and update soon – srinivas Aug 20 '14 at 18:21

Just boot to a live windows (no matter which version) using a hiren software, then just shutdown it. All new setting will be written in the disk and you can mount your disk created in windows easily.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.