Red Hat Bugzilla – Bug 731580
fails to find U-Boot if the boot directory is not on a separate partition
Last modified: 2013-07-23 18:00:11 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):
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
The uImage (and uInitrd) files are not created if /boot is just a subdirectory and not a separate mounted partition.
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 (/).
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.
-- 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.
Could this effort be merged with Bug 715460 ? Or what is the difference/disagreement?
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.
FWIW: I doubt grubby will be changed at all before f17, so it would perhaps be better to focus on the long term solution.
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.
We need to review this for F-18
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: