Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

11ghjones · 2013-07-08 06:02:10

I've been in the process of migrating a working Arch install for the last 8 hours from MBR/BIOS/GRUB2 to GPT/UEFI/GRUB2. I managed to do the MBR to GPT conversion as detailed on the wiki, but I cannot seem to create a persistent boot entry for grub. I've installed it according to the Beginner's Guide with some slight variation, /boot/EFI/arch_grub/grubx64.efi, and the ESP is mounted at /boot). I can create entries with efibootmgr with no error, using:

efibootmgr -c -d /dev/sda -p 5 -l EFI\\arch_grub\\grubx64.efi -L GRUB

Which would yield a setup of:

BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0002,0000,0001
Boot0000* EFI DVD/CDROM ACPI(a0841d0,0)PCI(1f,2)ATAPI(1,1,0)
Boot0001* OsLoader0000 ACPI(a0841d0,0)PCI(1f,5)ATAPI(1,0,0)HD(5,d000,100000,0c278261-b734-485f-9f88-72870f5f6085)File(\EFI\BOOT\BOOTX64.EFI)
Boot0002* GRUB HD(5,d000,100000,0c278261-b734-485f-9f88-72870f5f6085)File(EFI\arch_grub\grubx64.efi)

Only the top two entries persist. I imagine the top entry is automagically created on selecting the Arch CD to boot, but the second is a mystery to me. I've tried replacing that particular file with a copy of the grub loader, but to no avail.

My partitioning setup is as follows:

Disk /dev/sda: 250069680 sectors, 119.2 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 9682A19F-F28A-4C16-95DC-A1ACBDC0821C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 250069646
Partitions will be aligned on 2048-sector boundaries
Total free space is 45116013 sectors (21.5 GiB)
Number Start (sector) End (sector) Size Code Name
1 1101824 1255423 75.0 MiB 0700 Microsoft basic data
2 1255424 143566847 67.9 GiB 0700 Microsoft basic data
3 143566848 205006847 29.3 GiB 8300 Linux filesystem
5 53248 1101823 512.0 MiB EF00 Boot

As you notice, I do have a Windows install on this machine, but I'll get around to messing with it after my Arch install is back up and running. I'm afraid Windows may not be as resilient with this big of a change in boot configuration.

After trying with efibootmgr failed to work numerous times, I tried using the EFI v2 shell on the Arch CD, using bcfg. I was also able to add entries, but they did not persist across reboots. Rebooting without manually selecting the CD boot yields a black screen and a hang, regardless of whether the CD is in the tray or not. I can boot Arch by directly loading GRUB from the UEFI shell, but constantly using a boot CD to jumpstart my boot process is less than desirable. My motherboard is a Gigabyte GA-Z68-UD3-B3 with the U1F BIOS, released this March.

Any ideas would be greatly appreciated!

Last edited by 11ghjones (2013-07-09 01:03:28)

blablubb1234 · 2013-07-08 08:17:17

Welcome to the painful world of UEFI...

I recently heard of a bug - or maybe at Microsoft they call it feature - that is responsible for the Secure Boot thingy to be enabled in UEFI after doing Windows Updates in WIndows 8. Given that we don't know about your configuration this is a shot in the dark, but I could imagine that something the like might be the reason why you can create entries but they don't persist. I on my Lenovo Laptop can't even create EFI boot entries without destroying my EFI menu I hope it works out for you somehow and keep us updated

Best regards.

swordfish · 2013-07-08 08:25:53

Just a guess: Is secure boot active in your BIOS? And if not, have you checked if the UEFI-mode is activated in your BIOS? Normaly you could switch between a so called "legacy"-mode (i.e. classical BIOS) and the UEFI-mode.

Then you could try to delete all UEFI entries and create just one new entry for the UEFI-Grub. By the way - did you follow this instruction: https://wiki.archlinux.org/index.php/Gr … _partition ?

Another thing, you could try: Delete Grub (just for the moment) and install rEFInd or Gummiboot. In my opinion both are much easier to handle than Grub. If one of them is up and running, you could try again with Grub (if you still want to).

themax · 2013-07-08 08:43:25

As a fallback, you can put a file "startup.nsh" into your EFI partition
I am booting directly into efistub with this script:

fs0:
\EFI\arch\vmlinuz-arch.efi root=/dev/sda3 ro rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch-fallback.img

11ghjones · 2013-07-08 09:23:34

Likely not Secure Boot, as it's pure Windows 7 retail edition. I've tried Gummiboot and rEFInd with less luck than GRUB, sadly. Both crash from the UEFI shell. The only options as far as BIOS v UEFI booting is being able to force CD/DVDs uno one or the other. No other control over it without an external shell. I've also tried removing all entries then adding mine, in case of a full NVRAM, but no cigar. I might set up a startup script, though.

srs5694 · 2013-07-08 14:14:32

My suspicion is that you've got Gigabyte's absolutely abysmal Hybrid EFI firmware. This is a true EFI implementation, but it exists as a layer atop a traditional BIOS. That's not the real problem, though; the problem is that this EFI is so bug-laden that it's nearly useless. My page on the subject describes the details. One of these details is that the board tends to forget any NVRAM entries made with efibootmgr or bcfg, just as you describe.

On my own system, giving the boot loader of choice the filename EFI/BOOT/bootx64.efi works around this problem. I realize you say you've tried that without luck, but you could try again -- perhaps there was a typo in your first attempt at moving the file, for instance. Also, be sure to copy any support files that you need. I don't recall offhand what support files Arch's implementation of GRUB 2 needs, but if it needs anything at all, be sure to copy them -- or rename GRUB's original directory and grubx64.efi within that directory.

Overall, my recommendation is to convert your partition table back to MBR form and switch back to BIOS-mode booting. There are few reasons to struggle with Hybrid EFI's awfulness. This is doubly true because you seem to be saying you've got a BIOS-mode Windows installation that you want to convert. That process, although possible, is a hassle.

the.ridikulus.rat · 2013-07-08 14:54:47

@11ghjones: Can you check if placing any valid file at /EFI/Microsoft/Boot/bootmgfw.efi works around the problem. I have read about firmwares that will refuse to touch EFI variables or do not show all the created menu entries (using efibootmgr) unless first the /EFI/Microsoft/Boot/bootmgfw.efi exists. See https://bbs.archlinux.org/viewtopic.php … 2#p1259012 or https://bbs.archlinux.org/viewtopic.php?id=152967 . I recommended placing UEFI Shell binary at that place.

11ghjones · 2013-07-09 01:01:30

I've tried the Microsoft efi before, with no luck. I think I'm going to go back to BIOS boot. srs5694, you were quite correct in that I do have a board with the hybrid BIOS/UEFI implementation, and now that I see how much a pain it is, I have no interest in this. It started as a fun project to toy with UEFI, but ended with me almost losing access to my production system (I know, don't screw with production systems... but it's all I've got!). I'm gonna look into whether it's going to be more trouble to do GPT + BIOS, or try to convert back to MBR with BIOS. Thanks all for the help!

WonderWoofy · 2013-07-09 02:01:18

GPT/bios *should* be fine. Of course I have heard of people having funky firmware that prevented them from doing so. The only thing should be that you will have to create a 1-2MB grub bios partition if you want to use grub2. But if you are okay with using something else like syslinux or lilo, then this funky little partition is not needed.

11ghjones · 2013-07-09 02:09:13

Believe it or not, in the process of moving a the ESP to make room for the grub bios partition, the mobo recognized the EFI\Boot\bootx64.efi, and loaded Gummiboot (which I had just randomly thrown there in the midst of checking different loaders). It found rEFInd, which was at the Microsoft location, which could find everything else. I added entries to Gummiboot for GRUB and then did the Windows repair (not nearly as hard as I thought it'd be) and I'm now completely EFI booting! I think it all had to do with needing the ESP to be at sector 2048 for some reason.... Odd, but workable.

Sanjeev K Sharma · 2013-08-14 20:40:11

I've been reading this thread trying to make this work - I'm using an Asus p9x79pro motherboard, bios version 3501

Secure boot is on for these motherboards by default, I disabled that first thing

I've tried all the directions in the "beginner's" page for gummiboot and efibootmgr and the motherboard just does not want to boot from the first hard drive

booting with efi_no_storage_paranoia produced the same results

I did note that in the chroot directory
/sys/firmware/efi/vars was full of files and directories but
/sys/firmware/efi/efivars was empty

so I tried mounting mount -t efivarfs none /sys/firmware/efi/efivars the documentation says that a recent version of

arch-chroot /mnt does this automatically but I tried it anyway

and got that directory populated

gummiboot doesn't complain when I install in this case but on reboot the motherboard sees the hard drive but does not seem to see any EFI information on it.
Same with efibootmgr

When I boot from the USB into UEFI shell v2.0 and try bcfg, the shell does not see the hard drive at all - just FS0:, and a couple of BLK, none appear to be the hard drive

The last thing I tried was to delete all the partitions and create the EFI system partition starting at sector 2048. Still a no go. the BIOS sees the hard drive (just the SATA port, no EFI information) and lets me pick that to boot from but boots nothing

copying the gummiboot bootx64 file into the MS directory on the EFI system partition had no effect too.

I'm going to try grub2 next, then I'll revert to legacy, non-UEFI mode (which I'm not sure will work with this motherboard anyway ..)

Does UEFI require a modern hard drive for any reason? I'm using an old 300Gig maxtor, the only drive I had that I could reformat without losing some data.

update: playing around with the x86_64 EFI shells, commands "devices" and "devtree" are not showing the SATA drive at all. the BLK3: entry occasionally claims it's connected to an "HD" but when I try to switch to BLK3: and "dir" or "ls" there's nothing there.

Last edited by Sanjeev K Sharma (2013-08-14 21:12:21)

WonderWoofy · 2013-08-14 21:21:01

This seems like a firmware bug to me. I think that the only thing that you can do at this point would be to simply move to bios booting. Changing to grub-efi or elilo or whatever is not going to solve the problem if the firmware cannot find the proper drive to boot.

You should really start your own thread for this instead of tacking onto an old one. If you want, you can "report" your post and ask to have it moved to a new thread. Or you can simply start a new thread and link back to this post (hint: linking to the post directly can be done with the time/date of the post).

Sanjeev K Sharma · 2013-08-14 23:38:03

thanks for the heads up. I thought this might be the right thread, my problem seemed related.

I did indeed try the grub just after I posted the last comment and it didn't work.

BUT I got it booting in the end via EFI.

man oh man what a FRACKING PAIN

this is post-facto analysis but here 'tis anyway - OK, I believe the last time I used this hard drive a couple of years ago I was doing LILO and SYSLINUX and windows, often b0rkening the MBR and restoring it.

I repartitioned / reformatted the drive many times in the past, and a lot more again in the last few days, varying the EFU partition size and then the formatting with several different FAT "-F xx" parameters.

Finally in gdisk I realized the bootable USB I've been using started at sector 34. I tried formatting the hard drive using this setting and gdisk would not let me (always setting the start partition to something else, 48 or 1024 or 2048)

I zapped the existing partition table completely (option "x" for extended options, "z" for zap) then option "l" (lowercase L) for sector alignment, and typing in "1" (the digit one), then partitioned with the EFI partition starting at sector 34, size +1G. Formatted with mkfs.vfat -F 32

I don't know which specific action (the zapping might have fixed something by itself, the sector alignment may have been "the thing" ... but it's booting now in EFI -all the options show up (gummiboot, kernel stub set up with efibootmgr).

Last edited by Sanjeev K Sharma (2013-08-14 23:46:19)

WonderWoofy · 2013-08-15 00:56:12

The reason that gdisk wouldn't let you do that is beacuse the GPT spec states taht the area in which the partition table is held is to be after the MBR, but before the first partition. This is why the first partition starts at 2048, as by default GPT is able to store 128 "primary" partitions (really, there are nothing but primary partitions in GPT). This is why it requires as much space as it does.

How large were you trying to make your ESP before? Apparently the FAT filesystem has trouble making it 32bit if it is less than 512MB. So if you have something smaller there is a chance that you could end up with FAT16. Theoretically, this shouldn't matter, since firmwares are supposed to be able to read this fine as well. This is intended to be a compatibility measure for things like USBs and optical discs, where the idea of a 512MB ESP might not be practical. But in practice, I have heard of many firmwares what will not read from a FAT16 implementation.

In theory, UEFI is awesome. It is a nice spec that if implemented right, would provide a very robust firmware environemnt with which to work. But unfortunately, mosts bioses are closed source and have a bunch of vendor specific crap duct taped to the top. This introduces all kinds of bugs and whatnot, and some vendors are not so good at addressing these kinds of things. Unfortuanetly the standard of acceptability is whether or not the thing will boot windows. So they spend only as much effort as needed to get it working there.

Anyway, I'm glad you got it working.

Sanjeev K Sharma · 2013-08-15 01:09:28

WonderWoofy wrote:

This is why the first partition starts at 2048, as by default GPT is able to store 128 "primary" partitions (really, there are nothing but primary partitions in GPT). This is why it requires as much space as it does.

The first few dozen times it was automatically starting at sector 48, then when I read one of the posts above I chose to play with aligning the boundaries at numbers I remember from my various experiences, first 1024 then 2048 (this last number was invoked above to explain why an action worked). After I made that choice gdisk kept defaulting to 2048 (even after "zap" commands). I think changing the alignment parameter in the expert menu let me change this;

WonderWoofy wrote:

How large were you trying to make your ESP before?

the smallest I tried was 512M, largest 1024M (that last time that worked I typed the size as "+1G"

WonderWoofy wrote:

In theory, UEFI is awesome. It is a nice spec that if implemented right, would provide a very robust firmware environemnt with which to work. But unfortunately, mosts bioses are closed source and have a bunch of vendor specific crap duct taped to the top. This introduces all kinds of bugs and whatnot, and some vendors are not so good at addressing these kinds of things. Unfortuanetly the standard of acceptability is whether or not the thing will boot windows. So they spend only as much effort as needed to get it working there.

Matthew Garrett's talk at linuxconf.au (it's on Youtube) accentuates the many defects/bugs. UEFI code base is bigger than the Linux kernel, and probably debugged by many fewer developers.

Last edited by Sanjeev K Sharma (2013-08-15 01:12:08)

srs5694 · 2013-08-17 17:15:51

Sanjeev K Sharma wrote:

Finally in gdisk I realized the bootable USB I've been using started at sector 34. I tried formatting the hard drive using this setting and gdisk would not let me (always setting the start partition to something else, 48 or 1024 or 2048)
I zapped the existing partition table completely (option "x" for extended options, "z" for zap) then option "l" (lowercase L) for sector alignment, and typing in "1" (the digit one), then partitioned with the EFI partition starting at sector 34, size +1G. Formatted with mkfs.vfat -F 32

Be aware that most modern disks use Advanced Format, which means they have physical sectors that are 4096 bytes in size, but they still report a sector size of 512 bytes to the computer. The result can be severe performance problems unless partitions are aligned to begin on 8-(logical-)sector boundaries (that is, on physical sector boundaries). If the ESP starts on sector 34, that is not an 8-sector boundary, and so ESP performance may suffer. This probably isn't all that big of a deal, since the worst problems are with writing data, and you seldom write data to the ESP. If your subsequent partitions aren't properly aligned, though, you could end up with badly degraded performance.

Note also that the start sector of the ESP isn't an issue from the point of view of the EFI's ability to load boot loaders or otherwise work with the disk; it's just a performance issue. I don't know what was causing your problems, but it was not the start point of the partition being 2048 vs. 48 vs. 34.

WonderWoofy wrote:

The reason that gdisk wouldn't let you do that is beacuse the GPT spec states taht the area in which the partition table is held is to be after the MBR, but before the first partition. This is why the first partition starts at 2048, as by default GPT is able to store 128 "primary" partitions (really, there are nothing but primary partitions in GPT). This is why it requires as much space as it does.

Given the sizes of a 128-entry GPT and a 512-byte sector size, the first usable sector for GPT purposes is 34. (MBR sector + GPT metadata sector + 32 sectors holding 128 entries at 128 bytes apiece -- thus, the GPT consumes 34 sectors, and numbering starting from 0, the first usable sector is 34.) Given a blank disk, gdisk defaults to starting the first partition at sector 2048 because that value works well for most disk technologies -- it's a multiple of 8 for Advanced Format disks, and it's a multiple of higher power-of-2 values for best results with certain types of RAID arrays and for most SSDs, which have their own performance issues. Recent versions of libparted and fdisk also start the first partition at sector 2048, even on MBR disks. So do Microsoft's partitioning tools since Windows Vista.

WonderWoofy · 2013-08-18 00:02:42

@srs5694, as always, thanks for the awesome information. I especially the article on advanced format disks you linked to above. I never bothered to actually try to determine how much space 128 partition entries might actually take, and thus always gave that generic answer as to why it works in this way. But reading through your answer and that article I am even more curious now why sector 2048 has been chosen. You say above that 2048 is a good place because it is a divisible 8 for advanced format, as well as being a multiple of a power-of-2. But isn't every power-of-2 value (after 8) also a multiple of eight? Why not put it at 64 or 128 or 256 etc.?

Edit: Whoops, when swtching back to that article to close it, I realized I didn't read the box about "Aligning RAID partitions" and somehow missed the "Windows Vista and Windows 7 begin the first partition at sector 2048, so that's a safe place to start it from a cross-platform point of view"... so nevermind.

Last edited by WonderWoofy (2013-08-18 01:40:16)

Sanjeev K Sharma · 2013-08-18 17:07:44

> 096 bytes in size, but they still report a sector size of 512 bytes to the computer. The result can be severe performance problems

many thanks for this information.

> the start sector of the ESP isn't an issue from the point of view of the EFI's ability to load boot loaders or otherwise work with the disk;

yes, I changed too many things at once to be able to tell which action worked (or didn't) to get me a bootable system

On the next install I'll definitely test out a zap plus 2048 alignment (or use a completely new disk if I have enough $$$$$) I need to use this machine NOW so that'll have to wait a bit

I'll probably disable the swap on this disk, but ..

If you get a chance, does this look like it will affect current performance a lot?

lsblk -t /dev/sda
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sda 0 512 0 512 512 1 cfq 128 128 0B
├─sda1 0 512 0 512 512 1 cfq 128 128 0B
├─sda2 0 512 0 512 512 1 cfq 128 128 0B
└─sda3 0 512 0 512 512 1 cfq 128 128 0B

fdisk -l /dev/sda
Disk /dev/sda: 300.1 GB, 300090728448 bytes, 586114704 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt

_____________________________
another disk on the system:
lsblk -t /dev/sdn
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sdn 0 4096 0 4096 512 1 cfq 128 128 0B

fdisk -l /dev/sdn
Disk /dev/sdn: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Last edited by Sanjeev K Sharma (2013-08-18 18:00:35)

srs5694 · 2013-08-19 02:33:00

Sanjeev K Sharma wrote:

If you get a chance, does this look like it will affect current performance a lot?
lsblk -t /dev/sda
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME
sda 0 512 0 512 512 1 cfq 128 128 0B
fdisk -l /dev/sda
Disk /dev/sda: 300.1 GB, 300090728448 bytes, 586114704 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt

The logical/physical sector size data reported by these tools suggests that your disk is a traditional 512-byte-per-sector model; however, I don't fully trust this data. I've seen too many disks that fib about this sort of thing. Furthermore, you cut off the fdisk output before the partition data, which is what's required to determine if your partitions are properly aligned. Thus, I can't offer any reassurances on this score. The test is easy, though: Find the start sector value and divide it by 8. If the result is a whole number, that partition is properly aligned. If the value you get is not a whole number (if it has a decimal point and a non-0 value following it), then your alignment is improper for an Advanced Format disk. Unless you're positive that your disk is not an Advanced Format model, you should align your partitions properly.

Sanjeev K Sharma · 2013-08-19 19:47:59

I completely b0rkn3d the system by accident so got the chance to do reinstall

Now it has the 2048 alignment and is working fine.

So the cause of my previous problems was not the alignment - now it's down to 2 culprits, old boot stuff or old partitioning stuff - gdisk's "zap" was probably the thing that solved it either way.

1. old MBR stuff (old LILO, SYSlinux, maybe GRUB, winXP/NT2k stuff ... this disk has seen a lot since the first time I booted it with an ABIT BP6) I did that prevented EFI from seeing the right partition properly

2. something that had got stuck in those first couple of sectors (I had also installed qnx at one time, to play with real time stuff, purchased and used BeOS for a couple of months)

Thanks for taking the time to answer my questions.

Last edited by Sanjeev K Sharma (2013-08-19 21:46:38)

Sanjeev K Sharma · 2013-08-20 03:18:53

additional note on this last install - I forgot to use the kernel boot parameter

efi_no_storage_paranoia

Which I earlier thought was needed (it's writ in a couple of docs that some Asus boards need this)

and despite not using it this go round grub installed in the EFI system partition fine at the first attempt simply following the beginner instructions.

DarksideEE7 · 2013-08-20 04:02:34

I'm having the same problem on a Gigabyte Z77X-UD5h board. What a joke. To be honest UEFI should not be even considered in the default installation media if it's this buggy. Well, back to BIOS I go.

WonderWoofy · 2013-08-20 04:53:11

DarksideEE7 wrote:

I'm having the same problem on a Gigabyte Z77X-UD5h board. What a joke. To be honest UEFI should not be even considered in the default installation media if it's this buggy. Well, back to BIOS I go.

UEFI is new, and as with all new software (and old), there are bound to be bugs. Admittedly, there are some pretty prevalent bugs with the efistub in particular. But it is hard to tell how much of that it really attributable to the kernel's code or each individual's firmware. Judging by how vastly different each vendor's ability to implement UEFI well is, I would have to lean toward the side of firmware bugs. So saying that there should not be the inclusion of a feature because your firmware freaks out (or possibly that you don't fully understand what you're getting into) is a bit short sighted I think.

Besides, this is Arch Linux, which is a distribution which welcomes the new and bleeding edge. So I think that this fits perfectly into the nature of how things work around here.

Sanjeev K Sharma · 2013-08-20 15:48:40

DarksideEE7 wrote:

I'm having the same problem on a Gigabyte Z77X-UD5h board. What a joke. To be honest UEFI should not be even considered in the default installation media if it's this buggy. Well, back to BIOS I go.

yeah ... tianocore (the code base for EFI) is bigger than the Linux kernel (as I wrote above)

Matthew Garrett's talk:
http://www.youtube.com/watch?v=V2aq5M3Q76U

Next time I'm buying a machine I would LOVE to get a coreboot capable motherboard[0]. Will probably have to be AMD (they're doing the right thing iMHO, saving companies and customers money by using Linux) and not Intel.

Does Intel have a bad case of "not invented here" synrome?

coreboot plus systemd ... maybe even the entire kernel plus image plus systemd in BIOS ... depending on hardware I bet this could go from power on to full server services plus xorg in less than 3 seconds flat?

[0] will be hard to do because coreboot support seems to arrive a couple of months after the motherboard's discontinued : (

Last edited by Sanjeev K Sharma (2013-08-20 15:49:52)

Arch Linux

#1 2013-07-08 06:02:10

Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#2 2013-07-08 08:17:17

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#3 2013-07-08 08:25:53

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#4 2013-07-08 08:43:25

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#5 2013-07-08 09:23:34

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#6 2013-07-08 14:14:32

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#7 2013-07-08 14:54:47

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#8 2013-07-09 01:01:30

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#9 2013-07-09 02:01:18

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#10 2013-07-09 02:09:13

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#11 2013-08-14 20:40:11

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#12 2013-08-14 21:21:01

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#13 2013-08-14 23:38:03

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#14 2013-08-15 00:56:12

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#15 2013-08-15 01:09:28

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#16 2013-08-17 17:15:51

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#17 2013-08-18 00:02:42

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#18 2013-08-18 17:07:44

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#19 2013-08-19 02:33:00

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#20 2013-08-19 19:47:59

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#21 2013-08-20 03:18:53

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#22 2013-08-20 04:02:34

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#23 2013-08-20 04:53:11

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

#24 2013-08-20 15:48:40

Re: Neither efibootmgr nor bcfg create persistent UEFI entries [SOLVED]

Board footer