[Bug 774499] New: grub2-efi installation fails
https://bugzilla.novell.com/show_bug.cgi?id=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c0 Summary: grub2-efi installation fails Classification: openSUSE Product: openSUSE 12.2 Version: RC 2 Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mwenzel@suse.com QAContact: jsrain@suse.com Found By: Other Blocker: --- I've tried to install RC2 on an EFI system with and without image installation enabled. The initial install/file copy gets to about 70% then an error dialog pops up. Installation of package grub2-efi failed. Clicking on 'Show Details' box gives the following. Subprocess failed Error RPM failed error unpacking of archive failed on file /boot/efi/: cpio: chown failed - operation not permitted -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c kk zhang <kkzhang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkzhang@suse.com AssignedTo|bnc-team-screening@forge.pr |aj@suse.com |ovo.novell.com | -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|aj@suse.com |mchang@suse.com -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c1 Nued Wuesse <feuermail@bluemail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |feuermail@bluemail.ch --- Comment #1 from Nued Wuesse <feuermail@bluemail.ch> 2012-08-05 16:24:44 UTC --- I've tested RC2 with a Zenbook (UX31A with EFI): For starting the installation I cannot boot the installation usb-stick into EFI mode (with an Ubuntu installation stick it shows two choices: BIOS mode and EFI mode. With EFI mode the installation works perfectly). During installation I have to change manually from GRUB2 to GRUB2-EFI. Then in the installation overview there is the message "unsupported combination of hardware platform x86_64 and bootloader grub2-efi". -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c2 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #2 from Michael Chang <mchang@suse.com> 2012-08-07 07:36:12 UTC --- (In reply to comment #0)
Subprocess failed Error RPM failed error unpacking of archive failed on file /boot/efi/: cpio: chown failed - operation not permitted
The /boot/efi is ESP partition mount point, we would unpack grub.efi to it on this path "/boot/efi/EFI/opensuse/grub.efi". Sound to me unpacking this file to ESP partition encounters problem. By the way we don't use this packaged grub.efi, which is with most modules built-in. Instead we use a image created during grub2-install with minimal essential modules and by means of auto-loading and insmod to accomplish it's tasks. However fail to unpack it to ESP indicates some problem. Would you please give me the log in /var/log/YasT2 ? Thanks. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c3 --- Comment #3 from Michael Chang <mchang@suse.com> 2012-08-07 07:40:49 UTC --- (In reply to comment #1)
I've tested RC2 with a Zenbook (UX31A with EFI): For starting the installation I cannot boot the installation usb-stick into EFI mode (with an Ubuntu installation stick it shows two choices: BIOS mode and EFI mode. With EFI mode the installation works perfectly). During installation I have to change manually from GRUB2 to GRUB2-EFI. Then in the installation overview there is the message "unsupported combination of hardware platform x86_64 and bootloader grub2-efi".
Would you mind to open a new bug? It should be an separate issue IMHO. It sounds to me that YaST somehow detects your system is NOT EFI thus shows the error if you force to install grub2-efi on it. :( -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c4 --- Comment #4 from Murlin Wenzel <mwenzel@suse.com> 2012-08-07 15:03:05 UTC --- (In reply to comment #2)
(In reply to comment #0)
Subprocess failed Error RPM failed error unpacking of archive failed on file /boot/efi/: cpio: chown failed - operation not permitted
The /boot/efi is ESP partition mount point, we would unpack grub.efi to it on this path "/boot/efi/EFI/opensuse/grub.efi". Sound to me unpacking this file to ESP partition encounters problem.
By the way we don't use this packaged grub.efi, which is with most modules built-in. Instead we use a image created during grub2-install with minimal essential modules and by means of auto-loading and insmod to accomplish it's tasks. However fail to unpack it to ESP indicates some problem.
Would you please give me the log in /var/log/YasT2 ? Thanks.
Attaching YasT logs. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c5 --- Comment #5 from Murlin Wenzel <mwenzel@suse.com> 2012-08-07 15:04:04 UTC --- Created an attachment (id=501438) --> (http://bugzilla.novell.com/attachment.cgi?id=501438) yast logs yast logs from failed install of grub2-efi -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c6 --- Comment #6 from Murlin Wenzel <mwenzel@suse.com> 2012-08-07 15:11:05 UTC --- I don't know if this helps; When the grub2-efi install is failing, /boot/efi partition is mounted at /mnt/boot/efi but there are no files or sub-directories present. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c7 --- Comment #7 from Michael Chang <mchang@suse.com> 2012-08-08 07:17:49 UTC --- Hi Murlin, Would you please help to check my findings from the log? Thanks. Looks to me that your ESP partition (/dev/sda1) GUID is of type "Win95 FAT32 LBA" but doesn't follow the standard GUID using "EFI boot" ? YaST tried to create one ESP on /dev/sda4 but it get override via custom setup by setting /boot/efi to mount on the /dev/sda1 (Win95 FAT32 LBA) partition ? I could see the problem is that vfat doesn't support unix permissions (chown). It seems to me that we package grub.efi with %attr(0755,root,root)/boot/efi/EFI/opensuse/grub.efi Then it tries to chown if the owner not root. In our proposed setup for ESP partition this would not be a problem because the ESP partition is with mount options "umask=0002,utf8=true" so the new file's owner|group is the calling process (root). But if manually set /boot/efi to mount on /dev/sda1 the options are "users,gid=users,umask=0002,utf8=true" thus new files will have owner|group other than root thus leads to a chown failure. I'm not sure what problem will have if the ESP not with an expected GUID, probably grub2-install would rely on it to know what partition to copy the bootloader to, but I haven't checked the code. :( -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c8 --- Comment #8 from Michael Chang <mchang@suse.com> 2012-08-08 11:50:08 UTC --- I have looked a bit to libstorage and my explain above maybe incorrect. We use the gpt partition which is with any fat file system and boot flag set as the presumed ESP partition. It seems not check by the ESP GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) on the GPT scheme as my thought. Anyway your problem might be the boot flag not set? Please check system with the command $ parted -l And set the boot flag on if it's missing $ parted /dev/sda set 1 boot on And run the installation to see if yast reuse /dev/sda1 as ESP and could evade the chown error ? -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c9 --- Comment #9 from Murlin Wenzel <mwenzel@suse.com> 2012-08-08 18:57:06 UTC --- (In reply to comment #7)
Hi Murlin,
Would you please help to check my findings from the log? Thanks.
Looks to me that your ESP partition (/dev/sda1) GUID is of type "Win95 FAT32 LBA" but doesn't follow the standard GUID using "EFI boot" ? YaST tried to create one ESP on /dev/sda4 but it get override via custom setup by setting /boot/efi to mount on the /dev/sda1 (Win95 FAT32 LBA) partition ?
I could see the problem is that vfat doesn't support unix permissions (chown). It seems to me that we package grub.efi with %attr(0755,root,root)/boot/efi/EFI/opensuse/grub.efi Then it tries to chown if the owner not root.
Yes the /boot/efi partition is vfat. I defined that to match what I've always done with SLE. I thought fat32 was required for efi firmware code.
In our proposed setup for ESP partition this would not be a problem because the ESP partition is with mount options "umask=0002,utf8=true" so the new file's owner|group is the calling process (root). But if manually set /boot/efi to mount on /dev/sda1 the options are "users,gid=users,umask=0002,utf8=true" thus new files will have owner|group other than root thus leads to a chown failure.
I'm not sure what problem will have if the ESP not with an expected GUID, probably grub2-install would rely on it to know what partition to copy the bootloader to, but I haven't checked the code. :(
BTW what is your definition of ESP? -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c10 --- Comment #10 from Murlin Wenzel <mwenzel@suse.com> 2012-08-08 19:01:28 UTC --- (In reply to comment #8)
I have looked a bit to libstorage and my explain above maybe incorrect. We use the gpt partition which is with any fat file system and boot flag set as the presumed ESP partition. It seems not check by the ESP GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B) on the GPT scheme as my thought.
Anyway your problem might be the boot flag not set? Please check system with the command $ parted -l
And set the boot flag on if it's missing $ parted /dev/sda set 1 boot on
And run the installation to see if yast reuse /dev/sda1 as ESP and could evade the chown error ?
I'm pretty sure that the boot flag is not set at this point of the install. I think at least in the case of SLE it is the boot loader install at the end of the 1st install phase that sets the boot flag just before rebooting. I'll try setting the boot flag when I get back to the office. Do you think I can set it during the install and just retry the grub install, or do I need to start over with the boot flag set? I don't know if the flag is persistent with a new installation proposal. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c11 --- Comment #11 from Michael Chang <mchang@suse.com> 2012-08-09 03:21:50 UTC --- (In reply to comment #9)
(In reply to comment #7)
Yes the /boot/efi partition is vfat. I defined that to match what I've always done with SLE. I thought fat32 was required for efi firmware code.
Yes. As I know SLE uses elilo, somehow not stumbled in this file permission error? I think the filesystem is correct, but the problem is user defined partition may not set the boot flag and it get treated as user's partition and permissions. If parted not set the bootable then that GPT partition would not be set GUID Type as EFI System Partition, which would lead to problem on some UEFI firmware IMHO. This explanation (from the ArchLinux wiki) may help us understanding the issue better. :) "Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition""
BTW what is your definition of ESP?
EFI System Partition. http://en.wikipedia.org/wiki/EFI_System_partition You could also consult UEFI spec for more elaborate description (Probably in chapter 5 "GUID Partition Table (GPT) Disk Layout"). -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c12 --- Comment #12 from Michael Chang <mchang@suse.com> 2012-08-09 03:30:12 UTC --- (In reply to comment #10)
(In reply to comment #8)
I'm pretty sure that the boot flag is not set at this point of the install. I think at least in the case of SLE it is the boot loader install at the end of the 1st install phase that sets the boot flag just before rebooting. I'll try setting the boot flag when I get back to the office. Do you think I can set it during the install and just retry the grub install, or do I need to start over with the boot flag set? I don't know if the flag is persistent with a new installation proposal.
You should set it before you really start your installation. The purpose is to have yast storage to detect it as ESP partition correctly thus propose to (re)use it. So you never have to bother to point /boot/efi to that partition and format it on your own, let smart auto configuration do things for you. :) And please use parted and steps described above , don't use fdisk as it doesn't understand gpt. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c13 --- Comment #13 from Murlin Wenzel <mwenzel@suse.com> 2012-08-09 19:41:03 UTC --- (In reply to comment #12)
(In reply to comment #10)
(In reply to comment #8)
I'm pretty sure that the boot flag is not set at this point of the install. I think at least in the case of SLE it is the boot loader install at the end of the 1st install phase that sets the boot flag just before rebooting. I'll try setting the boot flag when I get back to the office. Do you think I can set it during the install and just retry the grub install, or do I need to start over with the boot flag set? I don't know if the flag is persistent with a new installation proposal.
You should set it before you really start your installation. The purpose is to have yast storage to detect it as ESP partition correctly thus propose to (re)use it. So you never have to bother to point /boot/efi to that partition and format it on your own, let smart auto configuration do things for you. :)
I restarted the install and accepted the default partitioning proposal which of course re-formated the entire drive. I checked the partition table as soon as the disk prep was complete and /boot/efi partiton was marked bootable. Install completed successfully.
And please use parted and steps described above , don't use fdisk as it doesn't understand gpt.
Yes I'm aware of that. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c14 --- Comment #14 from Michael Chang <mchang@suse.com> 2012-08-10 08:16:42 UTC --- Hi Murlin, Seems to me the issue was solved. Do you think this bug can close or not? Thanks. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c15 --- Comment #15 from Murlin Wenzel <mwenzel@suse.com> 2012-08-10 14:26:49 UTC --- (In reply to comment #14)
Hi Murlin,
Seems to me the issue was solved. Do you think this bug can close or not? Thanks.
The only thing that works is the default partitioning proposal. If you try any kind of custom scheme, it will still break. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c16 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |jsrain@suse.com --- Comment #16 from Michael Chang <mchang@suse.com> 2012-08-15 09:09:50 UTC --- Hi Jiri, Could you help to loop in yast people to check this. I think in the custom partition setting, the user manually set /boot/efi to mount on EFI System Partition, the "users,gid=users" option should not be set ? Thanks. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c17 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|jsrain@suse.com |fehr@suse.com --- Comment #17 from Jiri Srain <jsrain@suse.com> 2012-08-15 12:58:45 UTC --- Thomas, can you help here? Obviously, according to the log, these options were already set during installation, I just don't know whether by YaST or by user... 2012-08-03 15:38:44 <1> linux(3383) [YCP] FileSystems.ycp:1423 DefaultFstabOptions dev /dev/sda1 fsys `vfat is users,gid=users,umask=0002,utf8=true -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c18 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fehr@suse.com --- Comment #18 from Thomas Fehr <fehr@suse.com> 2012-08-15 13:20:38 UTC --- There is code that partitions starting with /boot do not have "users,gid=users" in fstab options but it may be there is a case that fstab options are determined before mount point is set to /boot/efi and not newly set after mount point changes. I will do a test with a faked efi setup right now and check if I can reproduce the 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c19 Thomas Fehr <fehr@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED InfoProvider|fehr@suse.com | Resolution| |FIXED --- Comment #19 from Thomas Fehr <fehr@suse.com> 2012-08-15 14:30:43 UTC --- Ok, found and fixed it. Default fstab options were not re-evaluated after mount point was changed. This was fine as long as default fstab options were only dependent on filesystem type and device. Later the dependency on mount point were added but the new evaluation after changing mount point was forgotten. As a workaround for current code: Set mount point to /boot/efi first and afterward change fs type (either to fat, or if it is already fat, change it to something else and back to fat). This triggers re-evaluation of default fstab options. Problem is fixed in current git head and also in SLES11 SP3 branch. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c20 --- Comment #20 from Michael Chang <mchang@suse.com> 2012-08-16 08:51:46 UTC --- Thomas and Jiri, Thanks a lot for quick respond and fix. -- 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=774499 https://bugzilla.novell.com/show_bug.cgi?id=774499#c21 --- Comment #21 from Bernhard Wiedemann <bwiedemann@suse.com> 2012-08-23 18:00:07 CEST --- This is an autogenerated message for OBS integration: This bug (774499) was mentioned in https://build.opensuse.org/request/show/131434 Factory / yast2-storage https://build.opensuse.org/request/show/131435 Factory / yast2-storage -- 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