[Bug 784980] New: Error "source_dir does not exist. Please specify --target or --directory" when updating GRUB2 on UEFI platform
https://bugzilla.novell.com/show_bug.cgi?id=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c0 Summary: Error "source_dir does not exist. Please specify --target or --directory" when updating GRUB2 on UEFI platform Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Bootloader AssignedTo: jsrain@suse.com ReportedBy: arvidjaar@gmail.com QAContact: jsrain@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.8) Gecko/20100101 Firefox/10.0.8 When updating grub2 package it tries to update core.img in postinstall script. grub2-install auto-detects current architecture, which in case of UEFI system is always {i386,x86_64}-efi. Because it runs /usr/sbin/grub2-install which was compiled with "grub2" transform, it looks for architecture specific modules under /usr/lib/grub2/{i386,x86_64}-efi. This directory does not exist because it is unstalled under different prefix - /usr/lib/grub2-efi. Even if it existed, grub2-efi is not yet updated when grub2 post runs; it has to be done in grub2-efi post. I set it to MAJOR because effectively it means core.img (or grub{32,64}.efi) is NOT updated on update on UEFI systems. Leading to any hard to debug errors (when it tries to access modules from different version). This is related to https://bugzilla.novell.com/show_bug.cgi?id=782891. Unifying grub2 and grub2-efi would eliminate this issue entirely. Alternative clean fix would be to split each /usr/lib/grub2/${target} in separate subpackage and run grub2-install with explicit --target=${target} in each subpackage. Is there any mailing list where this can be discussed (it is probably not for Bugzilla)? I think that for 12.2 the minimal fix is to add grub2-efi-mkconfig to grub2-efi post and explicitly specify --target in post for grub2 package. WDYT? Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c1 --- Comment #1 from Andrey Borzenkov <arvidjaar@gmail.com> 2012-10-14 05:22:38 UTC --- Created an attachment (id=509471) --> (http://bugzilla.novell.com/attachment.cgi?id=509471) Patch to update EFI bootloader in the grub2-efi Suggested patch for 12.2 -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|jsrain@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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c2 --- Comment #2 from Michael Chang <mchang@suse.com> 2012-10-15 10:15:14 UTC --- Hi Andrey, Thanks for your patch. It looks great to me but the issue has been addressed and fixed in factory several days ago. The new script now looks like this: %post efi /sbin/install-info %{_infodir}/grub-dev.info %{_infodir}/dir || : /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : # To check by current loader settings if [ -f %{_sysconfdir}/sysconfig/bootloader ]; then . %{_sysconfdir}/etc/sysconfig/bootloader fi if [ "x${LOADER_TYPE}" = "xgrub2-efi" ]; then # It's enought to call update-bootloader --refesh to install grub2 and update it's config /sbin/update-bootloader --refresh || true fi %endif The update-bootloader is SUSE specific tools for managing bootloader settings & installation and which honers sysconfig settings. Let me know if you still have any problem. Thanks, Michael -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c3 --- Comment #3 from Andrey Borzenkov <arvidjaar@gmail.com> 2012-10-15 10:35:12 UTC --- But this does not eliminate error message which triggered this bug report. grub2 post still runs. I think, it has to check for LOADER_TYPE too and skip if LOADER_TYPE is grub2-efi. Is it planned for 12.2 update? -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c4 --- Comment #4 from Michael Chang <mchang@suse.com> 2012-10-16 06:46:39 UTC --- (In reply to comment #3)
But this does not eliminate error message which triggered this bug report. grub2 post still runs. I think, it has to check for LOADER_TYPE too and skip if LOADER_TYPE is grub2-efi.
Hi Andrey, Ok. Now I'm getting clear about the issue. Those errors are triggered in the %post which tries to add testing grub2 sections to legacy grub menu if current loader is set to grub (It's a relic from 11.4, and for certain reason it's still there). It's obvious to fail in what you mentioned way because there's no additional checks thus grub2-install run blindly. The new improved fix in factory seems to fix the problem, as it now checks current loader and performing actions accordingly .. == # If the grub is the current loader, we'll handle the grub2 testing entry if [ "x${LOADER_TYPE}" = "xgrub" ]; then exec >/dev/null 2>&1 # check if entry for grub2's core.img exists in the config # if yes, we will correct obsoleted path and update grub2 stuff and config to make it work # if no, do nothing if [ -f /boot/grub/menu.lst ]; then # If grub config contains obsolete core.img path, remove and use the new one if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/core.img" /boot/grub/menu.lst; then /sbin/update-bootloader --remove --image /boot/%{name}/core.img || true /sbin/update-bootloader --add --image /boot/%{name}/i386-pc/core.img --name "GNU GRUB 2" || true fi # Install grub2 stuff and config to make the grub2 testing entry to work with updated version if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/i386-pc/core.img" /boot/grub/menu.lst; then # Determine the partition with /boot BOOT_PARTITION=$(df -h /boot |(read; awk '{print $1; exit}')) # Generate core.img, but don't let it be installed in boot sector %{name}-install --grub-setup=/bin/true $BOOT_PARTITION || true # Create a working grub2 config, otherwise that entry is un-bootable /usr/sbin/grub2-mkconfig -o /boot/%{name}/grub.cfg fi fi elif [ "x${LOADER_TYPE}" = "xgrub2" ]; then # It's enought to call update-bootloader --refesh to install grub2 and update it's config /sbin/update-bootloader --refresh || true fi == It's not likely to be grub set as current bootloader in use on UEFI platform but to be more conservative your patch would still be valid to fix the problem completely.
Is it planned for 12.2 update?
No. not yet .. I'll do it. Base on where we are at, the right fix would be to finish bnc#782891 and completely drop supporting the nasty "testing grub2 sections" in grub1 to get out all of the mess. 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c5 --- Comment #5 from Andrey Borzenkov <arvidjaar@gmail.com> 2012-10-17 02:55:28 UTC --- (In reply to comment #4)
# If the grub is the current loader, we'll handle the grub2 testing entry if [ "x${LOADER_TYPE}" = "xgrub" ]; then
Should not it really be x$LOADER_TYPE != xgrub2 -a x$LOADER_TYPE != grub2-efi? YaST2 still offers LILO and ELILO, and users may use them. Or are they completely unsupported now?
if [ -f /boot/grub/menu.lst ]; then
see above. Do you intentionally exclude (E)LILO?
# If grub config contains obsolete core.img path, remove and use the new one if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/core.img" /boot/grub/menu.lst; then /sbin/update-bootloader --remove --image /boot/%{name}/core.img || true /sbin/update-bootloader --add --image /boot/%{name}/i386-pc/core.img --name "GNU GRUB 2" || true fi
# Install grub2 stuff and config to make the grub2 testing entry to work with updated version if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/i386-pc/core.img" /boot/grub/menu.lst; then
So this means from now on GRUB2 will not be added to existing bootloader on update unless it was already present from earlier attempts. Is it intentional? -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c6 --- Comment #6 from Michael Chang <mchang@suse.com> 2012-10-17 04:05:02 UTC --- (In reply to comment #5)
(In reply to comment #4)
# If the grub is the current loader, we'll handle the grub2 testing entry if [ "x${LOADER_TYPE}" = "xgrub" ]; then
Should not it really be x$LOADER_TYPE != xgrub2 -a x$LOADER_TYPE != grub2-efi? YaST2 still offers LILO and ELILO, and users may use them. Or are they completely unsupported now?
LILO is not supported, although it's still available to be installed via YaST. You'll encounter warning message about it's unsupported and you are on your own. ELILO should be considered supported, as openSUSE 12.2 media (DVD) still rely on it to boot off from UEFI and it could be a fallback replacement of grub2 when it did not work as expected ..
if [ -f /boot/grub/menu.lst ]; then
see above. Do you intentionally exclude (E)LILO?
Yes. The purpose of the testing entry is to test grub2 without really installing it to replace your grub. You could switch to use it if you're happy with it then. The problem of elilo is that we're not sure about it's multiboot support. Yes we (openSUSE) build the 32-bit bootloader on x86_64 so expecting it to work better with multiboot but, afaics, no one (including me) really test on it. so intentionally didn't offer this option. But I get your point, to be honest it's a bit headache. I just realized that due to wrong %post script, elilo would be added with those grub2 sections as well which is unexpected.
# If grub config contains obsolete core.img path, remove and use the new one if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/core.img" /boot/grub/menu.lst; then /sbin/update-bootloader --remove --image /boot/%{name}/core.img || true /sbin/update-bootloader --add --image /boot/%{name}/i386-pc/core.img --name "GNU GRUB 2" || true fi
# Install grub2 stuff and config to make the grub2 testing entry to work with updated version if /usr/bin/grep -l "^\s*kernel\s*.*/boot/%{name}/i386-pc/core.img" /boot/grub/menu.lst; then
So this means from now on GRUB2 will not be added to existing bootloader on update unless it was already present from earlier attempts. Is it intentional?
Yes. We'll only maintain existing entries but not to add new one for new installation. As we has been transiting to grub2 as default bootloader the plan is to gradually drop this testing entry feature as we are now more confident on it. :-) Thanks, Michael -- 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=784980 https://bugzilla.novell.com/show_bug.cgi?id=784980#c7 Michael Chang <mchang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #7 from Michael Chang <mchang@suse.com> 2013-04-26 08:14:51 UTC --- Set to resolved fix. thanks for the patch. -- 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