Sager NP8651 - Can't Boot from USB

So recently I ordered an NP8651 from XoticPC with no preinstalled OS and received it a few days ago. However, when I try to boot the system with a bootable Win7 USB in the slot the function keys seem to stop working in the BIOS: pressing F7 or F2 does nothing while the drive is plugged in. If I remove the drive, however, the keypresses seem to register: for example, I can press F7, wait a while, pull out the USB, and then the BIOS gives me options to choose the boot device. This is a problem since I can't select to boot from USB without a drive to choose, and I can't choose the drive while the drive is plugged in.

Is this a hardware error or just something wrong with the way I'm doing things? I've installed OS from USB several times before on other laptops without any problems. Is there a BIOS setting I need to change? Any help would be much appreciated.

 

You should be able to change the boot order without the USB drive present. That being said, you should not have any issues with your function keys while the USB device is plugged in. Does the USB drive work with another computer? Does it happen with all of the USB ports? If you are installing Windows 7 I would recommend installing from the one on the back side of the laptop to avoid any issues with USB 3.0 drivers.

 

I have that same exact laptop. I bought it without an OS and was able to install it via a USB drive. When you turn on the laptop with the USB drive, do you see the Sager logo, "F2" on the lower left and "F7" on the lower right? If so, when you press the F2 button, do the letters on the screen turn bold face, " F2"? It does that for me and takes about 15 to 20 seconds to get into the BIOS.

 

Try another stick and also make sure you are in the right UEFI/legacy boot mode for the image you have created.

 

I have the same problem with one of my USB drives, Patriot brand. Works perfectly fine for external storage, but when trying to boot from it, my experience often mirrors yours. Every now and then, keys do respond and it manages to boot, but most of the time POST and keyboard freeze until I unplug the drive. Happens on a variety of desktops and laptops, old and new, USB 2.0 and 3.0 ports.

Bottom line, for me anyway, it's the USB drive. No problem with other random drives I own.

Edit: Never tried it on your notebook model though. And when I say old and new, I mean computers ranging from about 2007 era to late 2013. I guess that's not exactly new, but it's relatively new for me

 

Some flash storage not designed for the purpose can have hickups causing long delays in access time, the early SSDs did this a fair bit.

 

FYI, in case this is your issue ...

Microsoft's Windows USB Installation Tool/Creator does NOT create devices correctly for native 64-bit uEFI Installation. The Windows 7 installer expects a GUID Partition Table (GPT) disk label be used on the USB, hence why the common, Master Boot Record (MBR) Partition Table format the Microsoft USB Tool creates fails to boot, despite the uEFI firmware targeting the USB proper (up to the point the BOOTMGR tries to load NTkernel).

Side Note: This assumes, of course, it's native uEFI booting the USB, and not using a Compatibility Support Module (CSM) in uEFI to get legacy, 16-bit Int13h Disk Services. Then the Microsoft Tool Format will work, and install in a legacy mode.

You want a Tool like Rufus to explicitly create an USB Installer, from the Windows 7 ISO, for the specific firmware mode. Unlike the Microsoft Tool that only does legacy BIOS/uEFI-CSM, Rufus can create the explicit USB format required by Windows 7 for the firmware mode.
- https://rufus.akeo.ie

I know this might seem confusing, especially since you don't have to differentiate when booting the ISO from an optical (or emulated optical) device. It's also confusing because ISOLINUX also supports either mode, including when sector-copied to USB (although not GRUB v. GRUB-EFI, hence why most Linux installers stick with ISOLINUX).

But Windows 7 x64 requires different USB Installer organizations depending on what firmware disk services are used. Hence why you need to use something like Rufus, so the BOOTMGR/NTkernel doesn't hang when it loads and sees itself on a MBR Partition Table, not GPT, which the Microsoft Tool does not create.

Side Note: Rufus can also create other modes, including BIOS Boot for GPT but legacy BIOS, FreeDOS USB sticks for firmware updates (at least older systems that dont have an uEFI network/Internet update facility), etc...

Rufus is a self-contained EXE, so drop it somewhere and just run it.

 

I would recommend using Universal USB Installer for creating Windows installer USBs rather than Rufus, I've had Rufus make installers that don't quite work right yet with UUI I have never had any issues. Of course, Rufus is better for Prema BIOSes.

 

Have they added support in Universal USB Installer for creating GPT USBs so you can boot with using the native, 64-bit Disk API in uEFI?

I.e., sites still note the following on Universal USB Installer pages ( bold added)...

Again ... the Windows Preinstallation Environment (WinPE), especially at BOOTMGR/NTkernel load time, requires the USB be formatted GPT in native, 64-bit uEFI booting mode (no CSMs, no 16-bit Int13h Disk Services) -- at least for Vista and 7 (I personally haven't tried 8.x, but it seems to be the same issue for most). There is virtually no useful error message, and it took me a good 2 days to finally figure this out several years back, once I discovered (and thanx to the docs for) Rufus.

Again, the only solution is to either manually create the USB with GPT by hand (which is possible in an OS like Linux, or with added NT tools), or use one of the very select tools -- I only know of Rufus -- designed explicitly for this. If this has changed with Universal USB Installer, please let me know. But the l last time I checked, it's limited to MBR-only, which precludes it supporting native uEFI boot of USB for installation.

This continues to be the #1 gotcha for most people [re-]installing Windows on newer systems (usually 8.x only) with limited (i.e., usually no) CSM support for legacy disk boot (no option to get legacy BIOS Int13h disk services), requiring native uEFI boot/install (ergo, the aforementioned). I wouldn't bring it up if I didn't run into it constantly, and very few seem to know about this.

 

You are absolutely right that UUI does not support native UEFI booting, however, Rufus does and yet I still have issues with it - as do some of my friends, and lots of others. When I'm installing a new OS, I just create the installer on the USB with UUI, turn UEFI boot off, install it, turn it back on. Works perfectly fine for me, no error messages about partition issues of the drive, etc. Works perfect, every time and that's good enough for me.

If you don't have CSM/non-UEFI support then yeah obviously don't use it, but all my computers do and I only buy Clevo laptops which have UEFI and non-UEFI booting options - which is why we're actually posting in the Clevo section right now.

Don't get me wrong - Rufus is GREAT for me for when I want to flash a nice new Prema BIOS, but when I want to install a new OS? Forget about it.

 

Are you sure it's actually installing in uEFI mode? Are you sure you're actually getting a native uEFI install? Or is a CSM loading?

I.e., there is no way to allegedly "disable" uEFI. Everything is uEFI today.

All you're doing is telling it to either:
- Disable CSMs, such as for Storage ...
or, more likely ...
- Favor the CSM, such as for Storage, over native uEFI storage

E.g., even if you put uEFI Storage first in boot, it can "fall back" to a legacy CSM Storage, if your boot device doesn't load with native uEFI boot.

I've found most people don't realize they've actually installed their OS in a legacy, 16-bit BIOS Int13h Disk Services mode. You can tell because either ...
- The disk is formatted with a MBR Partition Table aka msdos disk label (4 primary + extended/logical) ...
or, also very common ...
- The disk is formatted with a GUID Partition Table aka gpt disk label (at least 128 partitions) with a BIOS Boot partition (type EF02), not or in addition to, the EFI System Partition (type EF00).

The GUID provides for MBR emulation, and if 16-bit BIOS Int13h Disk Services are used to install/boot, then the BIOS Boot partition (EF02) will exist. The BIOS Boot partition is basically an emulated, but writable, Master Boot Record area (typically 1MiB in size), whereas a "native" GUID has a read-only MBR emulated.

If it does not, you should only have a EFI System Partition (type EF00) and there is no MBR. The uEFI firmware has to be updated with a "target" OS entry. I.e., native uEFI never "boots a disk" -- that's a MBR concept. Native uEFI has an entry in the firmware itself that says where the boot loader is in the EFI System Partition (ESP).

I.e., when you go into the firmware (fka BIOS/CMOS) setup, you will see "Windows Boot Manager" instead of "uEFI Disk." If you Multi-Boot (e.g., Linux), you will have an entry for each OS in the firmware -- e.g., Red Hat Enterprise Linux, Fedora, Ubuntu LTS, etc... You can actually see the entries and location in the ESP, like \EFI\BOOT\BOOTX64.EFI, etc...

If you don't, then you're not booting native uEFI, and using a legacy CSM, likely with a BIOS Boot Partition in the case of GUID Partition Tables.

As I said, don't be surprised with more and more systems lacking a Storage CSM. The Intel-Microsoft requirements are forcing most ODMs to drop CSMs, including for Storage, in their uEFI implementations.

I.e., I'm not recommending Rufus ... I'm saying Rufus is one of the few (only?) options to deal with this situation. Understand that context.

 

Yes, I am 100% positive that it is installing in UEFI mode and I am getting a native UEFI install. I wish it worked because that would be great being able to use only one tool instead of having to use two.

 

The only time I've had issues are when ...
- The USB has bad blocks ... hence why one should scan it first (and purchase quality devices), or ...
- The uEFI firmware is incomplete and does not support full, native 64-bit boot with a full Disk API

In the case of the latter, yes, a Rufus created native uEFI+GPT will fail to install with uEFI firmware that actually only has a legacy CSM for emulated 16-bit BIOS Int13h disk services, because it was not created for such. I've seen this with legacy PROMs that were only 2Mb, and not the 4Mb required to store the full Intel uEFI 2.0 implementation.

I've just always had problems with most uEFI fimwares today -- when the CSMs were disabled (and not merely "order" after uEFI) -- in getting a native install, from USB. From ISO is not an issue, because ISOLinux and MS BOOTMGR for ISO, have no issue booting with either 16-bit BIOS Int13h disk (uEFI CSM) or 64-bit Disk API (native uEFI), because El'Torito et al. disk organization was defined to be firmware agnostic (PC BIOS, SRM, MS ARC, etc... well before Itanium introduce EFI, later adopted for IA-32e aka AMD x86-64).

But there are a lot of home installs out there that are uEFI w/CSM, despite using GPT. The proof is in the BIOS Boot Partition (existence of partition type EF02), or a similar solution, with the lack of entries in the uEFI Firmware itself ("boot to disk"). Even if uEFI is first, doesn't mean it's used ... quite the opposite (one needs to see an OS entry in the firmware).

 

It was 100% UEFI, no GPT whatsoever. The USB was brand new and had absolutely no bad blocks (I did scan it). From what I understand, there is no reason why it shouldn't have worked, but my friends have also had problems with Rufus for creating Windows installers, which is why they recommended UUI to me which worked fine. It would be really nice if Rufus just worked for me but oh well.

 

Wait?! Did you mean you used Rufus with no GPT USB? If so, yeah, that would fail with native uEFI, because Rufus wouldn't be created as MBR for a native uEFI install.

BTW ... for an installed system, can you boot a Linux Live USB and dump your hard drive partition table with "sfdisk -d /dev/sda"? That would be the "true tale" if you actually got a native uEFI install, and not uEFI w/a Storage CSM loaded (MBR or GPT + BIOS Boot). Again, lots of people claim they installed uEFI, but they actually did not once I looked at the system.

Or in Windows, Disk Administrator, or diskpart, shows some of these details, although not the "Raw" partition types (especially those key values).

Again, if you were not actually booting into native uEFI, but used Rufus to format via GPT+uEFI, then yes, Rufus would fail. That's kinda my point here.

Lots of people either have issues installing in native uEFI, until they use Rufus ... which was my original point.
Or in your "counter case" (remember, you responded to my post, not vice-versa) -- actual don't install in a native uEFI mode, but uEFI w/CSM (and the CSM was used, even if listed later) and wonder why Rufus' GPT+uEFI didn't work.

Unless you actually have a "Windows Boot Manager" (and not something left over from the original install, which is now broken) in your firmware (fka CMOS/BIOS setup) entries, you're booting from disk (via CSM) and not using native uEFI (booting from firmware entry). This is where I spend most of my time helping people ... broken uEFI setup, and then they re-installed and thought it was uEFI (firmware entry), but it was CSM (disk boot).

 

No, sorry, I mean no CSM, not no GPT, my bad!

As for the Linux Live USB, thanks for the tip I will definitely have to do that some time!

I definitely had Windows Boot Manager which meant I was using UEFI. No offense but I am not a clueless user I actually have a good idea of what I am doing, and the guy who suggested UUI to me over Rufus is a LOT smarter and better at computers than I am, which makes this all the more puzzling.