Bug 731580

Summary: fails to find U-Boot if the boot directory is not on a separate partition
Product: [Fedora] Fedora Reporter: D. Marlin <dmarlin>
Component: grubbyAssignee: Peter Jones <pjones>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: bcl, mads, pbrobinson, pjones
Target Milestone: ---   
Target Release: ---   
Hardware: arm9   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-23 18:00:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 245418    
Description Flags
Correct the check for a U-Boot script in boot subdirectory none

Description D. Marlin 2011-08-17 17:35:17 EDT
Created attachment 518757 [details]
Correct the check for a U-Boot script in boot subdirectory

Description of problem:

The new-kernel-pkg script fails to find the U-Boot script (and detect U-Boot is configured) if the boot directory is not on a separate partition.  

Version-Release number of selected component (if applicable):


How reproducible:

  Always on systems where /boot is not on a separate partition.

Steps to Reproduce:
1. Install a new kernel RPM
2. Check for the creation of a new uImage in the boot directory
Actual results:

The uImage (and uInitrd) files are not created if /boot is just a subdirectory and not a separate mounted partition.

Expected results:

The uImage (and uInitrd) files should be created for the installed kernel, regardless of whether /boot is a mounted partition or only a subdirectory on the root partition (/).

Additional info:

This only affects the U-Boot image creation section of the new-kernel-pkg script, for ARM based systems.  My initial changes were only tested on specific ARM-OMAP systems that required a specific U-Boot partition.  Testing on additional systems (ARM-Tegra) revealed this incorrect assumption.

The attached patch includes the following:

- Cosmetic: Correction - change uBoot to U-Boot in comments.
- Additions:
  -- Recognize ARCH == armv7hl
  -- Make U-Boot load/execute address variable (based on machine)
- Bug: Correct invalid assumption that the U-Boot directory would always be on a separate partition.
Comment 1 Mads Kiilerich 2011-11-25 10:07:55 EST
Could this effort be merged with Bug 715460 ? Or what is the difference/disagreement?
Comment 2 D. Marlin 2011-11-25 12:08:26 EST
The major difference is that this patch is a minor change, extending the existing code, while Bug 715460 is a "Complete rework of uboot ARM support."

While Zoran's work includes support for more platforms, and is more extensible than what is in grub now, to my knowledge it has not been thoroughly tested on all those platforms in Fedora.  When I tried his patch on one of my boards it failed to create a bootable image.  This may be due to my specific configuration, but it does appear to cause at least some regressions, so I think it should be more thoroughly reviewed and tested before being released.

While I do believe an approach like that provided in Bug 715460 is probably a better approach for the long term, it might be better applied to grub's replacement (grub2), where it can be more thoroughly tested on all supported platforms in rawhide.  At a minimum, I don't think it should be included in existing releases (e.g., F15) due to the extensive nature of the changes and potential for regressions.
Comment 3 Mads Kiilerich 2011-11-25 12:26:13 EST
FWIW: I doubt grubby will be changed at all before f17, so it would perhaps be better to focus on the long term solution.
Comment 4 D. Marlin 2011-11-26 02:12:26 EST
I would not argue against working on the long term solution, but I would appreciate it if my patch could be applied to F15 in the mean time.  It is a small patch and affects nothing but U-Boot support for ARM in grubby.  I have been using it on Panda Boards, Beagle Boards, and the Trim Slice for three months without issue, but I am forced to build from my own local SRPM in order to include this patch.

Unless there is some reason that this patch would interfere with the longer term solution, I would appreciate it if it could be applied in Fedora 15.
Comment 5 Peter Robinson 2012-06-06 05:46:25 EDT
We need to review this for F-18
Comment 6 Fedora End Of Life 2013-04-03 13:02:44 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here: