[Bug 854353] New: YaST incorrectly removes UEFI boot variables on installation and kernel update.
https://bugzilla.novell.com/show_bug.cgi?id=854353 https://bugzilla.novell.com/show_bug.cgi?id=854353#c0 Summary: YaST incorrectly removes UEFI boot variables on installation and kernel update. Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: yast2-maintainers@suse.de ReportedBy: dexter.1234@hotmail.com QAContact: jsrain@suse.com Found By: --- Blocker: --- Created an attachment (id=570740) --> (http://bugzilla.novell.com/attachment.cgi?id=570740) YaST logs and hwinfo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 On installation, or when a kernel update is installed, YaST assumes any boot variable with the term "opensuse" in the label field refers to an installation residing in /boot/efi/EFI/opensuse and removes all boot variable containing "opensuse". This behavior is wrong and contrary to the UEFI specification. The behavior occurs in 13.1 and 12.3. Background. The UEFI specification provides for vendor specific directories in the boot partition. OpenSuse uses /EFI/opensuse. During installation/kernel update, YaST is not checking that a boot variable actually belongs to opensuse by examining the path in the UEFI boot variable (via efivars or efivarfs), but rather, it simply examines the label field in the UEFI boot variable and if it contains "opensuse" it removes the boot variable even if: 1) the path points to some location other than /EFI/opensuse, and 2) there are multiple instances of "opensuse" in EFI boot variables. The label field is intended as a descriptive field that a user may freely change without restriction other than character set. The way YaST utilizes the lablel field adds a restriction not embraced in the UEFI specification. This behavior causes problems where there are multiple installations of opensuse on a system in which the boot directories exist in the boot partition in directories other than /EFI/opensuse. Discussion. One area of the UEFI specification that is problematic is that it does not address the installation of multiple versions of an OS as is common in the Linux community. Rather, it assumes that each vendor will use a specific directory in the boot partition and leaves open the issue of multiple installations by a single vendor on a platform. To date, the Linux community has not addressed this issue. Since I use multiple OS installations on UEFI platforms, I do this by using differently named directories in /EFI and boot via the kernel efi boot stub. Since I uses labels on the UEFI boot variables like "openSUSE 12.2", "openSUSE 12.3", and so on, each time there is an install or kernel update in 12.3 or 13.1, all UEFI boot variables containing the term "opensuse" are summarily removed by YaST. The fix has been to remove "opensuse" from all UEFI boot variable labels so YaST does not erroneously remove them. Reproducible: Always Steps to Reproduce: 1.Install opensuse 12.3 or 13.1 then rename the uefi boot directory to something other than /EFI/opensuse, for example, /EFI/foobar. 2.Rename the initrd and vmlinuz files in /EFI/foobar to "initrd" and "vmlinuz.efi", respectively. Use efibootmgr to create a UEFI boot entry as: efibootmgr -c -d /dev/sda -p 1 -L "openSUSE YaST will clobber this" -l "\EFI\foobar\vmlinuz.efi" -@ vmlinuxargs-ucs2 Note: vmlinuxargs-ucs2 is simply a UCS2 encoded file that contains the kernel command line parameters which are written to the boot variable. In my case, this file contains: initrd=\EFI\foobar\initrd root=/dev/disk/by-id/ata-WDC_WD10EALX-009BA0_WD-WCATR9648710-part5 resume=/dev/disk/by-id/ata-WDC_WD10EALX-009BA0_WD-WCATR9648710-part2 splash=silent quiet showopts 3.Boot the system and note the UEFI bios will have a boot entry "openSUSE YaST will clobber this". 4.Install opensuse 12.3 or 13.1 again. This will install to /EFI/opensuse. Now, checking the boot variables via the UEFI bios boot manager or efibootmgr in linux it will be noted that the boot variable containing "openSUSE YaST will clobber this" will have been removed by YaST on the second installation. Note that the contents of /EFI/foobar are unaltered and can be made bootable by rewriting the boot entry with efibootmgr. Actual Results: As described, YaST arbitrarily removes any and all UEFI boot variables containing the term "opensuse" with regard for the path in the boot variable. Expected Results: YaST should not remove any UEFI boot variable that does not have the path /EFI/opensuse. FYI, I do have a UEFI boot manager solution which I will release to the community in about 3 months (currenty implementing all the secure boot shims) which has a solution to the multiple os issue in UEFI and allows multiple installations to reside in the vendor directory without conflict. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c
Dexter Foster
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c
Vladimir Moravec
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c
Steffen Winterfeldt
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c1
--- Comment #1 from Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c2
--- Comment #2 from Michael Chang
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c3
Michael Chang
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.
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c5
--- Comment #5 from Neil Rickert
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.
Call me a skeptic, but I very much doubt this. We have to deal with the UEFI implementations that actually exist. On my Dell system, only one boot entry is retained in NVRAM. So I need that to provide a menu that I can use to boot other systems. In practice, I have a second EFI partition on a second hard drive, and my BIOS allows one NVRAM entry per hard drive. On another issue: why "/EFI/opensuse/opensuse12.2" rather than, say, "/EFI/opensuse/12.2"? Currently, I am using "/EFI/tumbleweed" and "/EFI/opensuse_alt" to get around the multiple version problem. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c6
--- Comment #6 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.
Greetings Michael, I tested your fix on my systems and it works fine, no more boot variables being erroneously removed. 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.
https://bugzilla.novell.com/show_bug.cgi?id=854353
https://bugzilla.novell.com/show_bug.cgi?id=854353#c7
--- Comment #7 from Dexter Foster
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.
Call me a skeptic, but I very much doubt this.
GRUB fixes the lack of a boot manager in legacy bios. UEFI includes the boot manager, GRUB is simply redundant. UEFI is not without its problems which is why I wrote some UEFI apps to get around them.
We have to deal with the UEFI implementations that actually exist.
On my Dell system, only one boot entry is retained in NVRAM. So I need that to provide a menu that I can use to boot other systems. In practice, I have a second EFI partition on a second hard drive, and my BIOS allows one NVRAM entry per hard drive.
As a hardware engineer who has designed many motherboards and as a software engineer who had written quite a bit of bios code for a major bios vendor, I would say exactly one boot variable is quite notable. Notable for the following reasons: 1. The UEFI bios uses NVRAM for persistent storage. In addition to any boot variables there are quite a number of parameters plus file system(s) stored in NVRAM. The amount of NVRAM needed is determined by the hardware designed into the motherboard and the UEFI bios features supported by the UEFI bios for the motherboard. Motherboard vendors will use the least amount of NVRAM necessary to support the UEFI bios and motherboard to control manufacture cost. However, if the motherboard is so designed so as to have exactly enough NVRAM available to support just one boot variable, this is indeed a quite a design accomplishment! Not to mention, with a lack of NVRAM, the UEFI bios is probably upgradable. A little extra NVRAM is usually designed in to support upgrades. 2. UEFI bios supports as many boot variables as available NVRAM will allow up to the specification limit of 65,535 boot variables. The Tianocore UEFI bios has no configuration parameter to limit the number of boot variables to one or any other number other than the spec limit of 64k. For this to happen the UEFI bios vendor would have to fork Tianocore and maintain this fork, which they will not do unless Dell requested and paid for this, which seems unlikely but not impossible. The source code for the part of UEFI bios that handles boot variables is open source and freely available at Tianocore. Nobody to date has noted a change that limits the boot variables. 3. Dell could be using a non-Tianocore implementation of UEFI but this seems unlikely as they are part of the Tianocore community. I would suggest you see if there is a bios update for your system because this is not proper UEFI bios behavior. Between bugs an implementor misunderstandings the road to UEFI has been bumpy to say the least. Now, it is not beyond the realm of possibility that Dell has in fact forked Tianocore, or used a different implementation, to limit a UEFI system to just one boot variable. If this is true then Microsoft has found yet another way to prevent Linux on PC platforms. However, I have not heard any such scuttlebutt. I have heard of a lot of weird things with UEFI but this is the first time for a UEFI bios that has only one boot variable.
On another issue: why "/EFI/opensuse/opensuse12.2" rather than, say, "/EFI/opensuse/12.2"? Currently, I am using "/EFI/tumbleweed" and "/EFI/opensuse_alt" to get around the multiple version problem.
As I mentioned previously, this pollutes the boot partition with a lot of directories at the top level and is contrary to the UEFI specification. As called for in the UEFI specification, each vendor should use one unique top level directory and place vendor specific data in the vendor directory. In the case of Linux, the vendor is a distribution. The subdirectory name is a distribution installer issue. Each distribution needs to handle subdirectories for multi-instance OS installation via whatever naming conventions suits them: random name generation, GUID, numbers, color of the rainbow, whatever. The only thing that is important in UEFI is that a different subdirectory be used for each OS install instance in the distribution UEFI directory. There is still more work to be done by the distros to support UEFI. -- 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.
participants (1)
-
bugzilla_noreply＠novell.com