[SOLVED] UEFI-boot on Intel-NUC

Anyone got UEFI-boot working on Intel NUC?
In BIOS i have enabled UEFI and disabled secure boot.
With the latest bootable arch media it boots okay in UEFI-mode.
ls -l /sys/firmware/efi shows a list of files.
If i boot into UEFI shell v 2.0 (from the USB) i can start arch with
fs1:\EFI\arch_grub\grubx64.efi
I have followed the installation guide and created a EFI (fat32) partition on GPT.
I tried to add the entry with both efibootmgr and bcfg, but it doesn't seem like it's being read. I find the entries with bcfg boot dump, but not in intels BIOS under (boot drive order)
It only gives me "a bootable device has not been detected" on startup
Last edited by cybe-arch (2013-08-21 10:29:30)

cybe-arch wrote:
I have followed the installation guide and created a EFI (fat32) partition on GPT.
I tried to add the entry with both efibootmgr and bcfg, but it doesn't seem like it's being read. I find the entries with bcfg boot dump, but not in intels BIOS under (boot drive order)
Please tell us the exact commands you used, and the errors you get, I don't know if I have an answer after that, but now I definitely don't.

Similar Messages

[Solved/Workaround] System freeze during boot on Intel NUC DN2820FYKH

Edit: When using the latest mainline kernel from here (3.14rc5 at the time of writing) all the problems go away. I'm hoping that this means I simply have to wait for 3.14 to release and hit [core] eventually. Also, my system clock *was* set incorrectly, because "ntpd -q" didn't print any sort of warning when I forgot the "-g" parameter.
Original message preserved in case anyone has the same problem:
On a fresh install, if I boot the latest kernel (3.13.5-1 at the time of writing) booting will stop midway through the systemd startup sequence. The specific line it ends on varies, sometimes it's "Starting Sound Card", other times it's "Starting Load/Save Random Seed." The system cursor stop blinking.
Adding debug to my boot parameters gives a large number of errors along the line of "Assertion: dual_timestamp_is_set has failed in sd_event_now_get_monotonic".
After this boot continues for a while, before freezing as described, without any sort of error or noteworthy output (as far as I can tell.)
Using the latest lts kernel (3.10.32-1) boot does finish, although it gives the same Assertion error as above. Also, the i915 module gives the error "preliminary hardware support disabled" and no modesetting is done. When trying to start X there are "No screens found"
As far as I can tell, the system clock and all related config files are configured correctly. All packages are up to date.
The system is an Intel NUC DN2820FYKH with a Bay Trail Celeron N2820 processor. For full specs:
http://www.intel.com/content/www/us/en/ … 0fykh.html
Last edited by Hellrespawn (2014-03-08 21:13:53)

Heres what I see after everything > 3.12.9 . It has a blinking cursor underneath that freezes, hdd light then stays on solid and doesn't do anything.

[SOLVED] UEFI boot configuration using efibootmgr

Hello All,
I've been having a very frustrating time with efibootmgr on my HP Laptop.
I've been searching around for some information regarding the OS Bootmanager in UEFI boot and cannot find anything that works for me.
I'm trying to get efibootmgr to load the boot entries in the order that I specify, but, although it lists exactly what I want in the terminal, when it comes to a reboot, the OS Bootmanager is failing and writing new entries every boot and I cannot fathom why.
Please could someone point me in the direction of a good guide to UEFI boot/OS Bootmanager and it's configuration using efibootmgr? I have read info found in the Archwiki, but was hoping for something focussing on efibootmgr alone as a configuration tool.
Many thanks for your help,
Frazer
Last edited by frazer (2014-03-10 22:21:14)

It's likely that the firmware (or maybe Windows, if you're booting into Windows between boots and haven't mentioned that fact) is changing the boot order. Unfortunately, some EFIs do that, or worse.
I recommend you start by upgrading your firmware. (In some cases, this will wipe out all your boot entries, so be prepared.) If the problem continues, either file a bug report with the manufacturer or return the hardware for a refund and buy something else. The manufacturers have had a long enough time to work out such major problems with their firmware, and returning defective hardware is really the only thing we as consumers can do that will get the manufacturers' attention.
If you must keep the hardware and a firmware update doesn't help, you may just need to find a workaround. If you need advice on doing that, you'll need to provide more details about what your setup is -- in particular, what you want the boot manager's boot list to look like (as in "efibootmgr -v" output once it's configured) and how the firmware is reshaping that when you reboot.

[SOLVED] UEFI Boot Troubles (ASUS UX31A-DH51)

Hello. I'm a casual linux user - I develop on linux, but I've never really explored the system itself. In an attempt to do so, I am installing Arch on my Asus UX31A-DH51. I copied the image to my external harddrive and followed the beginner's guide; Everything seemed to be going smoothly, except when I tried to boot into the system, it didn't work.
I suspect this has something to do with the bios being UEFI. However, I followed the instructions here to modify GRUB and, when going to "Launch EFI shell from filesystem device", the screen flickers and then a popup is displayed saying "Warning: Not found". I've also tried installing gummiboot, but that didn't work either. In the BIOS, the main HD isn't displayed as one of the devices that I can boot from either.
I've read this post, and I tried again from scratch using the information, but nothing helped. I didn't try archboot, though, since I don't know where to find the ISO or how to make a USB out of it.
The steps I followed are thus (pretty much all of them follow the beginner's guide):
I created a USB from the latest Arch linux iso, using these intstructions from my desktop computer (Mint 15).
I booted into said drive, and was presented with five options. I chose the one too boot into Arch. I tested UEFI support using the method at the beginning of the Beginner's guide; this succeeded.
I connected to the internet using wifi-menu.
Using cgdisk, I erased all the existing partitions on the SSD. I then created three partitions on the drive; a 1.5G EFI System Partition (sda3) - I used the code "ef00" to make it an ESP; a 15G linux partition (sda1); and a 99G linux partition (sda2).
I formatted the partitions. I formatted sda1 and sda2 to ext4, and I formatted sda3 to FAT32.
I mounted sda1 to /mnt, sda2 to /mnt/home, and sda3 to /mnt/boot/efi (I changed "/boot" to "/boot/efi" here because of the link above; here it is again).
I ran pacstrap -i /mnt base, which completed successfully; then, I generated an fstab at /mnt/etc/fstab, which I left as default.
I chrooted into /mnt, uncommented the en_US.UTF8 locale, symlinked the America/New_York timezone, updated the hardware clock, set the hostname, and ran passwd.
I skipped setting up the initial ramdisk environment.
I setup GRUB using the commands under the UEFI section in the guide; I first exited out of the chroot to run the three commands it says to run out of chroot, and then went back into chroot and followed the rest of the steps. The only thing I changed there was to change "/boot" to "/boot/efi". GRUB installed successfully, without any errors.
I ran
grub-mkconfig -o /boot/grub/grub.cfg
Finally, I rebooted, went into the bios, and chose "Launch EFI shell from filesystem device", which gave me "Warning: Not found". The main HD isn't listed as something I can boot from, though it is recognized as a SATA device. I'm kind of stumped after this. I also tried updating the BIOS, to no avail.
I'm feeling a little out of my depth here; hopefully someone can help me get this running. You'll probably need more info to diagnose the issue, but I'm not really certain how I should post those files from my laptop using just the arch shell. Anyhow, hopefully someone can help. In the meantime, I'm going to try the install from scratch again, reading more carefully.
Last edited by Chaosed0 (2013-09-27 18:48:25)

the.ridikulus.rat wrote:I think this is one of the brain-dead issues with some firmwares which expect /EFI/Microsoft/Boot/bootmgfw.efi to be present. Just copy a version of uefi shell to /EFI/Microsoft/Boot/bootmgfw.efi and then reboot into the system and recreate the entry using efibootmgr. For "Launch EFI shell from filesystem device", the shell application needs to be present at <EFISYS>/shellx64.efi (in the root of the efisys partition itself).
I copied "/EFI/grub/grubx64.efi" to "/EFI/Microsoft/Boot/bootmgfw.efi" and created an entry using the same efibootmgr command as two posts above; still no luck. The entry still gets deleted on a reboot, the disk doesn't show up in the devices, etc. I also copied grubx64.efi to /shellx64.efi, but the bios still refuses to recognize it's there.
Here's some output of efibootmgr. This is what it looks like before adding any entries:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002
Boot0001* UEFI: WD My Passport 070A2003
Boot0002* Hard Drive
Here's after adding the entry:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001,0002
Boot0000* grub
Boot0001* UEFI: WD My Passport 070A2003
Boot0002* Hard Drive
After rebooting, it goes back to exactly like it was before adding any entries.
Here's my fstab, if it helps at all:
# /etc/fstab: static file system information
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/sda1
UUID=556e2aff-a493-4ca9-a62e-175a890b0d03 / ext4 rw,relatime,data=ordered 0 1
# /dev/sda3
UUID=5B17-E429 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
# /dev/sda2
UUID=90dee4b7-caac-4d46-a9c6-4dae5bfc4cea /home ext4 rw,relatime,data=ordered 0 2
(Figured out how to set up ssh on my desktop, so feel free to ask for any more output or files.)

[Solved] UEFI Boot Failure

So I just got a now mobo that is UEFI and I tried loading Arch using the normal method.
i.e.( Partition, mkfs, mount, modprobe, chroot, install, reboot)
However when I arrive to what should be the boot I get a Black Screen with cursor.
I have read plenty of posts of the same issue, but to no avail.
This was using the EFIstub only, when I tried gummiboot I was unable to create EFI Boot variables. (I did check if in UEFI)
So now I am scratching my head as to what is going on.
Partitions are standard (gpt)
sda1 512M Fat32 ESP
sda2 10G Swap
sda3 100G Root
sda4 1.7T Home
Mobo is
M5A99FX ASUS
Any help is greatly appreciated.
Last edited by Teito (2013-08-30 19:43:20)

I think yuo might have forgotten to actually install and configure gummiboot.
Gummiboot is really just a boot manager. That means it does not load the kernel and initramfs as a typical bootloader would do. Instead, it simply allows the selection of an efi application and the option to pass arguments if desired/needed. The Linux kernel these days has CONFIG_EFISTUB, which allows the kernel to act as its own UEFI bootloader. So in reality gummiboot is just a menu to select that real bootloader.
So what you actually tried to do there is create a direct firmware entry. This is also using Linux as its own bootloader (via efistub). But instead, you simply append the kernel command line arguments to the bootloader (the kernel) directly in that firmware entry. So I am not sure if this was actually your intended goal or not.
I would recommend using the boot manager, and personally I like gummiboot because it is super straight forward to configure. But you are welcome to try using the direct firmware entry as well. Some would argue that the direct entry is faster, but the time it takes for my machine to load gummiboot is typically 14ms, so I consider that argument a bit silly. The advantages of being able to edit the kernel command line before booting are worth far more than 14ms, which is far less than what we used to wait for grub to load from the disk's boot sector.
In order to be absolutely sure you are getting gummiboot, you should install gummiboot (which should actually automatically install itself as /boot/EFI/gummiboot/gummiboot.efi as well as /boot/EFI/boot/bootx64.efi and attempt to make a firmware entry as "Linux Boot Manager"). But instead of trying to use the firmware entry, boot from the disk that the ESP resides on. \EFI\boot\bootx64.efi is the "default" position, so it is what the firmware is designed to search for in the event that it is booting with UEFI and a disk has been selected (instead of an efibootmgr firmware entry). If you have configured gummiboot properly, you will at least make it to the gummiboot menu and know that your UEFI is at least working… as long as you set a timeout >0.
I guess you should clarify what your actualy goal/preference is here, and then we can go from there.

[SOLVED]UEFI boot gives 'failed to install override security policy'

Hi, newb here who has hit a dead end quite early in the process of installing Arch.
When trying to boot Arch into EFI mode, it says
'failed to install override security policy'
Of course I did my research and it seems that only three other people on this planet have had the same problem, and their solutions do not work for me.
http://superuser.com/questions/615142/u … ity-policy
Overwriting EFI/boot/bootx64.efi with loader.efi enables me to see a menu where I can choose from booting Arch, UEFI shell v1 or UEFI shell v2. Still, selecting Arch results in a blank screen with two grey bars at the top and bottom of the screen, so not really not much help.
I'm not a UNIX nor an EFI wizard, so please bear with me. I'm a Windows user with some anecdotal Linux knowledge (I have installed Ubuntu countless times, wanted a bit of a challenge this time) who wanted to make the switch to the Linux ecosystem, but this error prevents me from doing so. I also tried to install rEFInd as suggested here: https://bbs.archlinux.org/viewtopic.php?id=174734
But I seem to be unable to boot into any UEFI shell v2, it's also printing the errors:
ASSERT_EFI_ERROR (Status = Not Found)
ASSERT C:\svn_code...and so on )
My Windows installation is on BIOS/MBR, so I cannot install rEFInd manually using Windows, and I also cannot use the v1 UEFI shell because of the lacking bcfg command. I don't know how to procede from here. My board is an AsRock P67 Extreme4 Rev 09 with a 2.10 EFI. This board doesn't even have Secure Boot if I'm correct, I also searched every possible submenu of the EFI for an option to disable Secure Boot, but haven't found anything.
Last edited by 0x33 (2015-03-11 17:35:56)

I presume you are trying to use gummiboot?
Please post the contents of /boot/loader/loader.conf and also your gummiboot configuration file for your Arch system (if you are not using gummiboot post the config. files for whichever boot loader/manager you are using).
Load the Arch live ISO, mount all your partitions and `arch-chroot` into your system and then post the output of:
lsblk -f
# parted -l
# efibootmgr -v
Last edited by Head_on_a_Stick (2015-03-10 21:05:43)

[SOLVED] Intel NUC using second dvb-t device causes usb lockup

I have an intel NUC D54250WYK running latest non-testing arch.
linux minikat 3.17.3-1-ARCH #1 SMP PREEMPT Fri Nov 14 23:13:48 CET 2014 x86_64 GNU/Linux
I have two PCTV 290e cards.
Bus 001 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 009: ID 2013:024f PCTV Systems nanoStick T2 290e
Bus 002 Device 008: ID 2013:024f PCTV Systems nanoStick T2 290e
Bus 002 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 002 Device 007: ID 0461:4d15 Primax Electronics, Ltd Dell Optical Mouse
Bus 002 Device 010: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 002 Device 006: ID 0557:7000 ATEN International Co., Ltd Hub
Bus 002 Device 005: ID 9e88:9e8f
Bus 002 Device 004: ID 1e4e:0110 Cubeternet
Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Both of these work fine running alone (ie using just /dev/dvb/adapter0 or adapter1). However, when I run both together all my usb devices seem to disappear. Using the power button I can shut the system down. In the logs I see this
Nov 17 22:42:44 minikat kernel: tda18271: performing RF tracking filter calibration
Nov 17 22:42:46 minikat kernel: tda18271: RF tracking filter calibration complete
Nov 17 22:42:51 minikat kernel: xhci_hcd 0000:00:14.0: xHCI host not responding to stop endpoint command.
Nov 17 22:42:51 minikat kernel: xhci_hcd 0000:00:14.0: Assuming host is dying, halting host.
Nov 17 22:42:51 minikat kernel: xhci_hcd 0000:00:14.0: HC died; cleaning up
Nov 17 22:42:51 minikat kernel: usb 1-3: USB disconnect, device number 2
Nov 17 22:42:51 minikat kernel: usb 1-3.1: USB disconnect, device number 4
Nov 17 22:42:51 minikat kernel: em28174 #1: writing to i2c device at 0xd8 failed (error=-5)
Nov 17 22:42:51 minikat kernel: i2c i2c-11: cxd2820r: i2c rd failed=-5 reg=db len=1
Nov 17 22:42:51 minikat kernel: em28174 #1: writing to i2c device at 0xc0 failed (error=-19)
Nov 17 22:42:51 minikat kernel: em28174 #1: writing to i2c device at 0xd8 failed (error=-19)
Nov 17 22:42:51 minikat kernel: i2c i2c-11: cxd2820r: i2c rd failed=-19 reg=db len=1
Nov 17 22:42:51 minikat kernel: __tda18271_write_regs: [11-0060|M] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -19
Nov 17 22:42:51 minikat kernel: tda18271_set_params: [11-0060|M] error -19 on line 985
Nov 17 22:42:51 minikat kernel: em28174 #1: writing to i2c device at 0xd8 failed (error=-19)
searching reveals a similar problem here https://bugs.launchpad.net/ubuntu/+sour … ug/1306712.
It doesn't seem to matter which device is used second or which application is using them; ie 2 x vlc or vlc + tzap etc etc all seem to cause the problem.
I used the same devices on my old acer revo 3610 and they work fine together there.
I would like to report this to Intel if I can get the right information together. Is there something I can do to clarify the problem?
Edit: added relevant device stuff from the same boot
Nov 17 22:40:35 minikat kernel: em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0)
Nov 17 22:40:35 minikat kernel: em28xx: DVB interface 0 found: isoc
Nov 17 22:40:35 minikat kernel: em28xx: chip ID is em28174
Nov 17 22:40:36 minikat kernel: em28174 #0: EEPROM ID = 26 00 01 00, EEPROM hash = 0x924125c8
Nov 17 22:40:36 minikat kernel: em28174 #0: EEPROM info:
Nov 17 22:40:36 minikat kernel: em28174 #0: microcode start address = 0x0004, boot configuration = 0x01
Nov 17 22:40:36 minikat kernel: em28174 #0: No audio on board.
Nov 17 22:40:36 minikat kernel: em28174 #0: 500mA max power
Nov 17 22:40:36 minikat kernel: em28174 #0: Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace
Nov 17 22:40:36 minikat kernel: em28174 #0: Identified as PCTV nanoStick T2 290e (card=78)
Nov 17 22:40:36 minikat kernel: em28174 #0: dvb set to isoc mode.
Nov 17 22:40:36 minikat kernel: em28xx: New device PCTV Systems PCTV 290e @ 480 Mbps (2013:024f, interface 0, class 0)
Nov 17 22:40:36 minikat kernel: em28xx: DVB interface 0 found: isoc
Nov 17 22:40:36 minikat kernel: em28xx: chip ID is em28174
Nov 17 22:40:36 minikat kernel: em28174 #1: EEPROM ID = 26 00 01 00, EEPROM hash = 0x9de637c6
Nov 17 22:40:36 minikat kernel: em28174 #1: EEPROM info:
Nov 17 22:40:36 minikat kernel: em28174 #1: microcode start address = 0x0004, boot configuration = 0x01
Nov 17 22:40:36 minikat kernel: em28174 #1: No audio on board.
Nov 17 22:40:36 minikat kernel: em28174 #1: 500mA max power
Nov 17 22:40:36 minikat kernel: em28174 #1: Table at offset 0x39, strings=0x1aa0, 0x14ba, 0x1ace
Nov 17 22:40:36 minikat kernel: em28174 #1: Identified as PCTV nanoStick T2 290e (card=78)
Nov 17 22:40:36 minikat kernel: em28174 #1: dvb set to isoc mode.
Nov 17 22:40:36 minikat kernel: usbcore: registered new interface driver em28xx
Nov 17 22:40:36 minikat kernel: em28174 #0: Binding DVB extension
Nov 17 22:40:36 minikat kernel: DVB: registering new adapter (em28174 #0)
Nov 17 22:40:36 minikat kernel: em28174 #0: DVB extension successfully initialized
Nov 17 22:40:36 minikat kernel: em28174 #1: Binding DVB extension
Nov 17 22:40:36 minikat kernel: DVB: registering new adapter (em28174 #1)
Nov 17 22:40:36 minikat kernel: em28174 #1: DVB extension successfully initialized
Nov 17 22:40:36 minikat kernel: em28xx: Registered (Em28xx dvb Extension) extension
Nov 17 22:40:36 minikat kernel: em28174 #0: Registering input extension
Nov 17 22:40:36 minikat kernel: input: em28xx IR (em28174 #0) as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/rc/rc1/input14
Nov 17 22:40:36 minikat kernel: rc1: em28xx IR (em28174 #0) as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.1/rc/rc1
Nov 17 22:40:36 minikat kernel: em28174 #0: Input extension successfully initalized
Nov 17 22:40:36 minikat kernel: em28174 #1: Registering input extension
Nov 17 22:40:36 minikat kernel: input: em28xx IR (em28174 #1) as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.2/rc/rc2/input15
Nov 17 22:40:36 minikat kernel: rc2: em28xx IR (em28174 #1) as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4.2/rc/rc2
Nov 17 22:40:36 minikat kernel: em28174 #1: Input extension successfully initalized
Nov 17 22:40:36 minikat kernel: em28xx: Registered (Em28xx Input Extension) extension
I think the above indicates the devices are separately recognized.
Last edited by replabrobin (2015-01-25 19:12:37)

I'm having a similar problem with the WinTV HVR 950Q on my i7 laptop. Any time something (tvtime, ffplay, etc) tries to read from the device, USB dies with the same "Assuming host is dying" message in dmesg. Fortunately my laptop keyboard & touchpad aren't connected via usb, so I'm not forced to power cycle, but I'ld like to figure out the problem so I can use the device.
Currently I'm thinking there is a problem with the xhci driver module, but I'm still working on tracking it down. Let me know if you figure this out.
Update:
Just confirmed that at least in my case this is an issue with xhci. I compiled a kernel with no xhci support and booted to it (since blacklisting xhci_hcd doesn't seem to work), now the capture device seems to work properly. Unfortunately this means I can have USB3, or the capture device, but not both (for now).
There is a "quirks" parameter that can be passed to the xhci_hcd module. It seems to be a bitmask AFAICT, but I haven't been able to find any documentation as to what it does yet. Maybe there's something in there that can help here.
Last edited by mcgrew (2014-11-18 20:43:48)

[SOLVED, sort of] Yet another UEFI boot issue

Hello everyone,
Let me start by saying sorry for the long (first) post.
I've ended up with a UEFI boot problem I can't solve. I've searched the forum and internet and I realize I'm not the only one who ran into problems with UEFI. Unfortunately, the problems other have had seem not similar to mine. I've spent almost 2 days now trying to figure this out, and I'm getting nowhere (though I've learnt some more about UEFI, which I guess is good). I was hoping someone here can give me some hints on how to proceed.
So lets start with the background. I recently bought a new computer (Lenovo Thinkpad Edge E530 with Windows 8) and of course I want to run ArchLinux on it (been using ArchLinux for almost 7 years now and no plans on switching). Installation went ok with only a few problems during installation that I managed to solve (or so I thought). I must admit I didn't follow the guide fully. I didn't want to remove the Restore and Windows partitions, so I figured it would be safe to reuse the existing UEFI System Partition, as long as there was enough room, which there was. Anyway, I now have a computer I can boot into ArchLinux and also Windows 8, just the way I want it, almost. There is this one final issue I haven't been able to figure out how to solve.
The problem
Whenever I reset/power on the computer, I must press Enter during the initial screen (showing a Lenovo logo, and a message about pressing Enter to interrupt normal startup). If I don't press Enter before the timeout (a second or so), the screen will go white and that's it. No beep, no message, no nothing but a white screen. A power cycle is the only way to leave this state. Occasionally the screen will be a white bar at the top and random colours below, but I'm guessing this only represents what is in graphics memory at the time (0x00, 0xFF or any other random value).
If i do press Enter however, then I'm presented with a menu where I can select what to boot; rEFInd (which is preselected) along with Windows 8 and some restore and diagnostic entries. Pressing enter will take me to the preselected rEFInd, pressing enter again (or wait for timeout) will boot linux, and I'm in. Nothing weird there. And if I select Windows in rEFInd, then windows boot, just as expected.
There is no difference whether I'm switching from Windows to Linux or Linux to Windows or just reboot the same OS I was using again. The result is the same whatever I choose to boot.
So the question is: Why do I have to select rEFInd manually and go through all these menus? Should I not be able to just power it on and let it boot the preselected rEFInd entry and continue from there, without me helping it?
Trying to solve it
Searching here and on the internet gave me some ideas on what to try, so here is a list of my attempts:
efibootmgr show me there is a rEFInd entry, and that it is the first one in boot order
I copied refindx64.efi to /boot/efi/EFI/Boot/bootx64.efi (replacing an existing entry)
I've updated the EFI firmware (from Lenovo) to the latest and greatest
One other guy had almost the same issue, but with a single boot of Windows. He solved it with Microsoft Boot Manager (there is an Automatic Repair, or something). I even dared trying this, though I must admit I was a bit hesitant about letting some Microsoft program trying to repair my computer. Anyway, it said it couldn't repair my problem, nor did it say I had one, so I am none the wiser.
None of the above gave anything.
So, that's it. I guess I can live with having to press Enter on every power up/reset, but it is very annoying having to do so, and even more so when I forget it because then I'm forced to power cycle it. I hope someone reading this can figure out what's going on, because I am clueless.
Best regards,
Johan
Last edited by 6feet5 (2013-01-08 19:03:50)

WonderWoofy wrote:@srs5694, have you thought about filing a bug report/feature request about the naming scheme here? I would imagine that something coming directly from the upstream developer would be something that they should take into consideration. Also, I imagine that renaming it to refindx64.efi kind of goes against the whole "vanilla packages" thing we tout around here... so it really makes me wonder why it is done in the first place.
I've just done that:
https://bugs.archlinux.org/task/33326
It's not been very important until recently; but I've been putting a lot of effort into the ancillary support scripts (install.sh and mvrefind.sh). They necessarily rely on the files having certain names, so installing them under other names robs users of functionality.
6feet5 wrote:I've decided to try and restore the whole unit, thinking it would take maybe an hour or two. It's been running now for almost 3 hours and only completed 20%.
Good luck with that!
FWIW, it seems that the number of EFI-related bug reports on Linux forums has gone way up recently. No doubt this is because EFI is now pretty much universal on new computers, so problems that used to affect one or two people now affect dozens or hundreds, and some of those post about them.

[SOLVED] Can't setup UEFI boot

Hi, I'm in the process of installing a newly bought laptop (Sony Vaio SVS1311P9EB). I'm able to boot from the install media and to install the system but when it comes to setting up the boot I run into some issues.
The HDD is formated with GPT with a EFI partition on /dev/sda3 (there is actually on on sda1 as well, but I think that one is for system recovery. It does lack the boot flag) and the arch system root on /dev/sda6, the partitions in between is used by Windows 7 (pre installed from factory). Works perfectly by the way...
The BIOS is set to use UEFI, "Boot mode" = UEFI. However even though i run 'modprobe efivars' the kernel can't detect any EFI variables, in fact the directory /sys/firmware/efi doesn't even exist.
This causes problems when I run (from the newbie install guide);
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck
and
efibootmgr -c -g -d /dev/sda -p 3 -w -L "Arch Linux (GRUB)" -l '\EFI\arch_grub\grubx64.efi
The error both times are;
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables
If I reboot the computer the BIOS ignores arch (not surprising I guess) and just jumps straight to Windows.
Any ideas how I can get around this problem?
Last edited by nojan (2012-11-07 22:27:12)

The module loads fine, but that directory does not get created. If I'm reading the wiki correctly that means that UEFI isn't being used, however that doesn't make any sense since the BIOS is setup to use UEFI
Edit: Found this link; http://www.linuxquestions.org/questions … 175411129/. Seems that the guys at H2O BIOS has decided to hardcode the paths to UEFI system files. Renaming the windows file solved the problem, although it is hack alert on the highest level!
Last edited by nojan (2012-11-07 20:20:24)

[SOLVED] Dual Boot Window 7 & Arch on a Uefi system.

From the Wiki
Windows 7 x86_64 versions support booting in x86_64 UEFI mode from GPT disk only, OR in BIOS mode from MBR/msdos disk only. They do not support IA32 (x86 32-bit) UEFI boot from GPT/MBR disk, x86_64 UEFI boot from MBR/msdos disk, or BIOS boot from GPT disk.
I don't understand this. As stated in the title I have a ueif system so that means I have to create a GPT disk ? I already have a gpt disk which I confirmed by running Arch Live USB. Under type it said GPT. I don't understand this at all
However if Arch is installed in BIOS-GPT in one disk and Windows is installed in BIOS-MBR mode in another disk, then the BIOS bootloader used by Arch CAN boot the Windows in the other disk, if the bootloader itself has the ability to chainload from another disk.
Note: If Arch and Windows are dual-booting from same disk, then Arch SHOULD follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk.
In the Note above it says both Arch and Windows follow the same boot mode if they are dual booting from same disk. I DO NOT want to do this. I have already decided to partition my drive with 200 Gb going to Windows and 500 Gb going to Arch. Does this mean that I should install both in different modes i.e. Arch in Bios-GPT and Windows in Bios-MBR.
The recommended way to setup a Linux/Windows dual booting system is to first install Windows, only using part of the disk for its partitions. When you have finished the Windows setup, boot into the Linux install environment where you can create additional partitions for Linux while leaving the existing Windows partitions untouched.
UEFI systems
Both Gummiboot and rEFInd autodetect Windows Boot Manager \EFI\Microsoft\Boot\bootmgfw.efi and show it in their boot menu, so there is no manual config required.
For GRUB(2) follow GRUB#Windows_Installed_in_UEFI-GPT_Mode_menu_entry.
Syslinux (as of version 6.02 and 6.03-pre9) and ELILO do not support chainloading other EFI applications, so they cannot be used to chainload \EFI\Microsoft\Boot\bootmgfw.efi .
Computers that come with newer versions of Windows often have secure boot enabled. You will need to take extra steps to either disable secure boot or to make your installation media compatible with secure boot.
Being a beginner should I go with Gummiboot then. GRUB made a mess last time.
Also my secure boot is NOT enabled so is that good.
I have read the FAQs, Beginner's guide, Installation Guide, Dual Boot wiki entry but I just don't understand the above concepts. But it looks this this is the main thing in dual booting. Almost everything else is doable but this I have to get right on account of what happened the last time I installed Arch without getting the above right.
Last edited by Some Arch Lovin (2014-06-14 08:53:14)

A few issues with the dual boot setup
Hello again, I lost my dual factor authentication grid from lastpass. Opensuse was acutally overwriting new pdf files over my old pdf files so now that grid pdf is actually an Arch cheat cheet with the name last_pass_grid.pdf. And the gmail account I used to register to Arch forums is also in last pass.
This is why I created another account. I am some arch lovin.
The installation went smoothly but I could not dual boot Windows7 with Arch because my Win7 image is not UEFI bootable so had to dual boot win8(not a fan at all) and arch.
Almost everything is working correctly. I have a few issues that aren't affecting how the system is working but they still need sorting out.
I'll do them one at a time but I want to know from the admins if I should start a new thread? Because in a way this thread accomplished it job i.e. win7 and arch dual booting in uefi system.
If the answer is yes I should create a new thread depending upon the issue then I will do that but in case its a no since I have only 2-3 problems I am going to ask help for the first one.
My gummiboot is not working on startup. I have to press f12 and use bios booting menu to boot. The problem with that is if I put Windows at the top of the boot priority the bios does not show F12 and F2 at the time of booting up so I can't access the boot menu. I have to boot into Windows and crash it by holding the power button and then the F12 options shows up and I am able to boot into Arch. If I put Arch at the top then Windows keeps restoring back to an earlier version due to start up options.
NOTE : I can't be sure but one it did work(only once). I checked the images online to compare with what I saw and its very similar. An all black screen with three bootloading options
Windows
Arch
Opensuse(don't know why I created a completely new GPT partition table)
This is what I did while installing Gummiboot
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
# pacman -S gummiboot
# gummiboot install
I tried going through the gummiboot to see if I can do something but it very difficult to comprehend as a beginner. All I get is the characters gummiboot understands but thats all.
Last edited by Archer61 (2014-06-11 13:48:56)

[SOLVED] UEFI installation - booting failure

Hi All,
Setting in BIOS: UEFI boot mode, Secure Boot Off
Booting from USB in UEFI mode, everything is OK. Then I did this:
gdisk /dev/sda
create new GPT partition
cgdisk /dev/sda
Part. # Size Partition Type Partition Name
1007.0 KiB free space
1 512 Mb EFI system efi
2 6 GiB Linux filesystem root
3 122 GiB Linux filesystem home
mkfs.vfat -F32 -n efi /dev/sda1
mkfs.ext4 /dev/sda2
mkfs.ext4 /dev/sda3
mkdir -p /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
mount /dev/sda2 /mnt
mkdir -p /mnt/home
mount /dev/sda3 /mnt/home
Then I followed the installation guide. At the "Install a bootloader" section I tried both EFISTUB and GRUB:.
At Point 5 here https://wiki.archlinux.org/index.php/Beginners'_Guide#EFISTUB I created refind_linux.conf with sdax = sda2
# nano /boot/efi/EFI/arch/refind_linux.conf
"Boot to X" "root=/dev/sda2 ro rootfstype=ext4 systemd.unit=graphical.target"
"Boot to console" "root=/dev/sda2 ro rootfstype=ext4 systemd.unit=multi-user.target"
and at Point 6 X=a, Y=1:
# efibootmgr -c -d /dev/sda -p 1 -w -L "rEFInd" -l '\EFI\refind\refind_x64.efi'
GRUB is quite straightforward.
After restart I got "no bootable device" error. The strange thing is that in BIOS I can see and select "rEFInd" or "arch_grub" in booting options, but anyhow it just won't boot.
Thank you for your help.
Last edited by totolotto (2013-06-22 17:33:39)

totolotto wrote:rEFInd boot manager shows 2 Arch logos:
1) Boot EFI\arch\vmlinuz.efi from 512 MiB FAT volume
2) Boot boot\vmlinuz-linux from 6 GiB ext4 volume
This means that you've got your kernel (or possibly different kernels) stored on two partitions. The first looks like it's a kernel on your ESP, and the second looks like it's your root (/) Linux filesystem, accessed via the rEFInd ext4fs driver. To simplify your life, I recommend deleting the kernel from the ESP and using the kernel in your Linux /boot directory (that is, kernel #2). If you try to keep both of them, you'll have to copy new kernels from /boot to the ESP whenever you upgrade your kernel, and you'll end up with two entries in rEFInd that boot the same kernel, which is sort of pointless.
That said, if you don't want to use rEFInd in the long term, copying your kernels to the ESP, or reconfiguring your mount point so that the ESP is mounted at /boot and therefore your kernels get stored there automatically, can make sense. Given where you are, though, the quickest path to an efficient setup is to just ditch the kernels on the ESP and boot your kernels off of your root (/) partition's /boot directory.
totolotto wrote:With regard to "boot into Arch directly" I understand that it is possilbe with efibootmgr described here, however efrbootmgr does not work for me
Some people do like to boot their kernels directly, without using rEFInd, gummiboot, GRUB, or anything else. Note that efibootmgr isn't involved in the boot process per se; it's just used to set up the firmware's boot manager. Thus, saying you want to "boot with efibootmgr" (or words to that effect) is confusing, even to experts -- because this makes no sense, it's not clear what you really want. This uncertainty has been cleared up in subsequent posts, but I want to point it out to help you (and perhaps others who read this) communicate more clearly in the future.
FWIW, I tend to agree with WonderWoofy on this score -- although it's possible to configure the firmware to boot the kernel directly, the down sides to this approach more than outweigh whatever small speed benefits you get from it. In your case, totolotto, given the problems you're having with efibootmgr, it may not be a practical alternative -- at least, not unless and until you can overcome those problems.
WonderWoofy wrote: I think a better option would be to give rEFInd a timeout of zero. I believe there is a key (or keys?) that you can hold down to have the menu show up when the timeout is set to zero. This is how gummiboot works anyway,
rEFInd doesn't have a 0-timeout option. In rEFInd, setting the timeout to 0 disables the countdown timer, so it never times out. The closest you can get to a 0-timeout in rEFInd is setting it to 1 second. If you must have a true 0 timeout, use gummiboot. Unfortunately, that means you won't be able to read the kernel files from a Linux filesystem, but mounting the ESP at /boot can create something that works about as well. Doing this will require some significant reconfiguration from where totolotto is now, but it can be done if getting a 0-timeout configuration is important.

[SOLVED] Removing archiso's UEFI boot failed using xorriso

I'm trying to remove UEFI boot support of the latest archiso since I have to boot the install CD on my MacBook2,1 (which doesn't support UEFI, only supports 32-bit EFI).
I follow this guide but this is the xorriso output:
libburn : SORRY : Neither stdio-path nor its directory exist
xorriso : FAILURE : Cannot aquire drive 'stdio:~/archiso.iso'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
Can anyone help me with this?
Last edited by mirakulous (2013-05-30 09:34:04)

Hi,
as upstream programmer of xorriso i would really appreciate
to see this fixed in the wiki ... or yielding a bug report
if xorriso is to blame.
I tried the following with success on my quite outdated
GNU/Linux system:
$ wget http://mirror.de.leaseweb.net/archlinux … 1-dual.iso
# mount -o loop /dvdbuffer/archlinux-2013.05.01-dual.iso /mnt/iso
$ xorriso -as mkisofs -iso-level 3 \
-full-iso9660-filenames\
-volid "ARCH_201305" \
-appid "Arch Linux CD" \
-publisher "Arch Linux <https://www.archlinux.org>" \
-preparer "prepared like a BAWSE" \
-eltorito-boot isolinux/isolinux.bin \
-eltorito-catalog isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
-isohybrid-mbr "/dvdbuffer/archlinux-2013.05.01-dual.iso" \
-output "$HOME/archiso.iso" "/mnt/iso/"
(I do not have SYSLINUX development installed, but the ISO image
bears a suitable -isohybrid-mbr template at its start. So i use
that one.)
This yields
GNU xorriso 1.3.0 : RockRidge filesystem manipulator, libburnia project.
xorriso : UPDATE : 107 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 32768 bytes from file '/dvdbuffer/archlinux-2013.05.01-dual.iso'
libisofs: NOTE : Aligned image size to cylinder size by 55 blocks
Written to medium : 260608 sectors at LBA 0
Writing to 'stdio:/home/thomas/archiso.iso' completed successfully.
The original ISO reports on inquiry of its content
$ xorriso -indev /dvdbuffer/archlinux-2013.05.01-dual.iso -toc
Boot record : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/isolinux/boot.cat'
Boot image : '/isolinux/isolinux.bin' , boot_info_table=on
Boot image : '/EFI/archiso/efiboot.img' , platform_id=0xEF
The repacked one reports no EFI boot image that is reachable
via El Torito
$ xorriso -indev /home/thomas/archiso.iso -toc
Boot record : El Torito , ISOLINUX isohybrid MBR pointing to boot image
Boot catalog : '/isolinux/boot.cat'
Boot image : '/isolinux/isolinux.bin' , boot_info_table=on
If this does not work for archlinux users, then please tell
me the version of xorriso that fails, the necessary preparations,
the program arguments used, and the messages of xorriso.
Have a nice day
Thomas

[SOLVED] UEFI system booting from MBR partition table and GRUB legacy

I'm trying to understand once and for all the process by which Arch can be booted from a system with UEFI firmware and an MBR partition table. Some of the information on the wiki seems conflictual / non-nonsensical at times. Apologies in advance if this has been answered time and time again, but I did search around and all I found was fixes to get Arch to boot rather than comprehensive explanations of the boot process.
Now, the way I would imagine it works is that it's just completely identical to the way it would work with a BIOS firmware. The UEFI firmware detects an MBR partitioning scheme (or is configured to know it's an MBR partitioning scheme), activates some "legacy" mode and executes the MBR boot code, just like a BIOS firmware would.
The wiki however, says different. From the Macbook article: "Do not install GRUB onto /dev/sda !!! Doing so is likely to lead to an unstable post-environment."?
So what is there in the MBR boot sector? Nothing?
How does the firmware know what to boot if there's no 0xEF BIOS boot partition and no Grub stage 1 in the MBR boot sector?
Also, how does installing Grub stage 1 to a partition work? Does it have to be at the beginning of the partition? Wouldn't that overwrite some existing data?
I'm especially puzzled since many guides to installing Vista on a macbook recommend simply formatting as MBR, and installing as normal, which I suppose entails having the Windows installation process write its boot code to the MBR, ie the equivalent of installing grub stage 1 to /dev/sda rather than to the /boot partition, as the Macbook article suggests.
Any input is appreciated.
P.S. I realize it's probably simpler, if I just want to dual boot Windows and Arch, to install Windows 7 in UEFI-GPT mode, let it create the EFI System Partition, and then install GRUB 2 to that partition, but I'm still curious about the UEFI-MBR boot process.
Last edited by padavoine (2012-06-06 09:35:10)

padavoine wrote:
CSM in UEFI firmwares do the exact same job as normal BIOS firmware.
So it's something specific to the Mac that it's able to boot from a partition's VBR while ignoring the MBR?
The reason that warning is given is because grub-legacy modifies more than just the MBR boot code region. It can overwrite some parts of GPT header.
Not true, the instruction is given in the context of an MBR format, not in the context of a GPT format, so there's nothing to overwrite and Stage 1.5 should be safely embeddable in the post-MBR gap.
In BIOS boot (normal case in non-UEFI firmwares or CSM in UEFI firmwares) does not read the partitition table (atleast it is supposed to be dumb in this regard), it simply launches whatever boot code exists in the 1st 440-byte of the MBR region.
So again, you're saying it's specific to the Mac UEFI that it lets you choose a partition whose VBR to load, regardless of what's in the MBR?
I haven't used Macs so I can't comment on Mac firmware behaviour. But normal BIOS firmwares (legacy and CSM) launch only the MBR boot code and not the partition boot code. We need some chainload capable boot manager in the MBR to launch the partition VBR.
grub-legacy does not know anything about GPT. So when you install grub-legacy to /dev/sda, it install the MBR boot code (stage1) and stage 1.5 code to the (supposed) post MBR gap. Since there is no actual post MBR gap in GPT (which has been taken over by the header and partition table), grub-legacy does not check for GPT and it assumes the post MBR gap actually exists which is invalid in case of GPT. grub-legacy embeds the stage 1.5 code in GPT header and table region (which grub assumes to be unused post MBR gap) and thus corrupts it.
0xEF is the MBR type code for UEFISYS partition. grub stage 1 (used in grub-legacy, not in grub2) is the 440-byte boot code stored in MBR for use in BIOS boot.
That's precisely my point: with neither proper executable code in the MBR (since grub was installed to a partition, not to the MBR) nor a UEFI system partition, what does the firmware default to, and how does it know what partition to boot from?
In that case it might fallback to UEFI Shell (if it exists) or give an error similar to the case where BIOS does not find any bootable code in 440-byte MBR region.
So even with bootcamp/CSM, the disk also needs to be MBR partitioned. So Macs use something called "Hybrid GPT/MBR" ( http://rodsbooks.com/gdisk/hybrid.html ) where the MBR table is synced to match the first 3 partitions in the GPT table.
I know what Bootcamp does, and that's not what I was referring to. I was referring to standalone Vista installs. I wasn't puzzled at the fact that they were using MBR, I was puzzled at the fact that contrary to the recommendations for the standalone Arch install on the wiki (with MBR partitioning, not GPT), they didn't do anything to try and prevent Windows from writing to the MBR.
You can't prevent Windows from overwriting the MBR region. You have to re-install the bootloader (grub2/syslinux etc.) after installing Windows. That is the reason why it is recommended to install Windows first and linux later.
Thats not true. I actually find it is much easier to install Windows UEFI-GPT using USB rather than a DVD.
I haven't done it since the only UEFI system I own has no DVD drive, but I was under the impression that it was simply a matter of choosing DVD UEFI boot in the firmware's boot menu.
format the USB as FAT32 and extract the iso to it. That it.
No, thats not it, precisely, it doesn't work out of the box with a standard Windows install USB, you need to fiddle around:
2.3 Extract bootmgfw.efi from [WINDOWS_x86_64_ISO]/sources/install.wim => [INSTALL.WIM]/1/Windows/Boot/EFI/bootmgfw.efi (using 7-zip aka p7zip for both the files), or copy it from C:\Windows\Boot\EFI\bootmgfw.efi from a working Windows x86_64 installation.
2.4 Copy the extracted bootmgfw.efi file to [MOUNTPOINT]/efi/microsoft/boot/bootmgfw.efi .
Most of the Windows isos already have /EFI/BOOT/BOOTX64.EFI file, so no need to extract the bootmgfw.efi file.
There is no difference between in BIOS booting in UEFI firmwares and BIOS booting with legacy firmware.
There has to be a difference, at least in the Mac firmware (sorry, I keep switching), since legacy firmware, AFAIK, cannot chainload a bootloader in a partition's VBR without there being some sort of "stage1" code in the MBR.
No idea about Mac EFI. Apple made a spagetti out of UEFI Spec. To actually understand how Mac firmwares work, read the blog posts by Matthew Garrett of Redhat, about his efforts in getting Fedora to boot in Macs.

[SOLVED] UEFI Virtualbox installation boot problems

Before I install Arch on my computer, I wanted to test the installation in Virtualbox. Because my motherboard has UEFI, I selected the EFI option in Virtualbox for a 64 bit Arch install.
I ran through the Beginners' Guide on the wiki and all seemed to go well. I rebooted the VM after the installation (forgetting to remove the ISO from the drive) and got the refind menu showing correctly and managed to boot in to my new Arch system from there. I also did a reboot (with the ISO still in the drive) and all was well. However, I then shutdown the system (shutdown -h now) and then powered it back on again and instead of going in to the refind menu, it goes to the archiso uefi boot menu and continues to boot from the ISO. So I powered down the VM again, removed the ISO from the drive and powered the VM back on again. This time, nothing booted and I was left in the UEFI shell.
Does anyone have any ideas why this has happened?
Last edited by ryan117 (2013-02-13 20:15:44)

This is probably because VirtualBox tends to forget its "NVRAM" settings when you reboot. There are a number of solutions to this problem. IMHO, the easiest is:
Boot using an emergency system.
Mount the ESP (probably /dev/sda1 -- the FAT partition that holds the boot loader).
Rename EFI/refind on the ESP to EFI/BOOT
Rename EFI/BOOT/refind_x64.efi to EFI/BOOT/bootx64.efi
Thereafter, rEFInd should appear when you reboot. If you subsequently upgrade rEFInd, you'll need to install it to its new location rather than to EFI/refind.
Alternatively, you can use the bcfg command in an EFI version 2 shell to register refind_x64.efi as the default boot program. This tends to get remembered, even when entries created by efibootmgr don't. This will require installing an EFI 2 shell, running it, and running the suitable bcfg command. (I think it's documented in the Arch wiki somewhere.)

Using UEFI boot to override Lenovo BIOS limitation (X220)

Hi,
I purchased and installed a new wireless card (Intel Centrino N-6205) to replace the Realtek that came with my X220.
When I rebooted the system was halted by the BIOS (Unauthorized network card).
Basically the BIOS checks for a valid Lenovo signature on the card and refuses to boot.
I digged a bit and found some modified BIOSes on google, however I am not very tempted by this option.
I was wondering if UEFI boot would override this limitation.
Thanks for your replies.wE2wXQLV

UEFI will not get you around this issue. Lenovo whitelists their own wireless cards, so you cannot boot in any case with an unauthorized card. I have a Lenovo E430, and I also had that terrible realtek card. I found someone willing to help me on mydigitallife forums to modify a bios image to remove this whitelist. I got myself an Intel Centrino 6235, flashed the bios, installed the card, and I couldn't be happier with the results.
The only issue is that if there is ever a bios update where I think it solves an issue that appeals to me, I would have to get that new bios modified for me again. Though to date, I have not found any real bios issues that are worth going through this.
I linked to the thread where i found help on the Thinkpad E430 page that I wrote. Maybe you could use that as a starting point...

[SOLVED] UEFI-boot on Intel-NUC

Similar Messages

Maybe you are looking for