https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c4
--- Comment #4 from Dexter Foster
Hi Dexter,
Can you help to test above patch in this repo ?
http://download.opensuse.org/repositories/home:/michael-chang:/13.1:/bnc:/85...
Follow the steps.
$ zypper ar --repo http://download.opensuse.org/repositories/home:/michael-chang:/13.1:/bnc:/85... $ zypper ref $ zypper dup -r home_michael-chang_13.1_bnc_854353
Please disable secure-boot to test. Thanks.
Greeting Michael, Sorry for the delay in responding, long holiday break. Will be happy to test your fix but won't be able to do so until Jan 13, need to catch up with the work that piled up while on holiday. Will post my findings. Testing the EFI boot partition path alone will fix the problem and is consistent with the UEFI specification. The label field should not be considered as it is just that, a label which should be left to the user to decide what goes there. However, be aware that there is a subtle gotcha lurking due to how the UEFI spec defines vendor usage of the boot partition. The spec states each vendor will have a unique directory in the partition, all well and good, makes it easy for multiple OSes to inhabit the same system. But the spec says nothing about how to handle multiple versions of the same vendor, for example, opensuse 12.2, 12.3, and 13.1 all installed in the opensuse directory (which is how my system is set up). With respect to boot variables, UEFI could care less if multiple versions of an OS live is the same directory since all that is required is to correctly write the path to the UEFI boot variable for each OS instance. The problem resides in the Linux community having not yet realized the problem and trying to retain the legacy BIOS method. There are two basic ways to solve the problem of multiple instances of the same vendor OS being installed. First solution is to use a different top level directory for each OS instance, for example, /EFI/opensuse12.2, /EFI/opensuse12.3, and so on. While this will work, it would rapidly pollute the EFI boot partition, would require all vendors to implement a directory naming convention (good luck), and is inconsistent with the spirit of the UEFI specification. Second solution is to put each OS instance in a subdirectory of the vendor directory, for example, /EFI/opensuse/opensuse12.2, /EFI/opensuse12.3, and so on. This is consistent with the intention of the UEFI specification, avoids polluting the top level partition, and requires not common convention be adopted by vendors - each vendor can use whatever make them happy in their UEFI boot directory (this is possible because this is an OS installer issue not a UEFI issue - UEFI only cares about the pathname in the boot variable). Keep in mind also that not only might multiple versions of the same vendor exist, but also, multiple instances of the same vendor OS version. In my case, for each version of opensuse installed there are three OS types: desktop, server, and virtual machine variants. I use this second approach on my systems. So, for say opensuse12.2, I have the following subdirectories: /EFI/opensuse/opensuse12.2/desktop, /EFI/opensuse/opensuse12.2/server, and /EFI/opensuse/opensuse12.2/virtual. Obviously this is not supported by YaST/GRUB2 and I have to manually fixup everything post install and after kernel updates, a PIA, but this structure works consistent with the intent of UEFI. As I mentioned, I wrote a UEFI bootloader (the UEFI BIOS boot manager sucks on my mobos) and decided to address this issue and will be publishing the bootloader and recommended solution (solution 2) in the near future. Bottom line is this bug is the tip of the iceberg. GRUB is simply not necessary on UEFI platforms. All that an OS installer need do is to correctly write the path to the OS/OS loader into a UEFI boot variable and the UEFI BIOS handles everything else. For mobos whose UEFI BIOS has a hideous interface then Gummiboot or mine will make life nice. Oh, then there are the shims for secure boot - here again GRUB is pointless. I am currently adding support for the secure boot shims to my bootloader, don't know if Gummiboot does the same. Anyhow, UEFI makes life simpler if we play by the spec! enjoy... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.