Bug 485486 - RPM install script does not update grub.conf
Summary: RPM install script does not update grub.conf
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: bootchart
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL: http://cvs.fedoraproject.org/viewvc/r...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-13 18:39 UTC by Chris Gardner
Modified: 2011-03-31 20:45 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-03-31 12:16:17 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch suggestion (667 bytes, text/plain)
2009-02-13 19:05 UTC, Chris Gardner
no flags Details

Description Chris Gardner 2009-02-13 18:39:51 UTC
Description of problem:
Installing 'bootchart' does not update grub.conf with the relevent parameter to use bootchart.
The post-install scriptlet calls 'grubby' to update grub.conf but is using '/boot/boot/vmlinuz...' as the kernel path and fails to find a valid matching stanza to update.

bootchart.spec (%post) contains two lines which prepend '/boot' to an already absolute kernel path, leading to the bug. 

A fix would be to change the text from:
--update-kernel=/boot"$kernel"
to:
--update-kernel="$kernel"

Version-Release number of selected component (if applicable):
bootchart-0.9-9.fc9

How reproducible:
always

Steps to Reproduce:
1. sudo yum install bootchart
2. sudo grep -q bootchartd /boot/grub/grub.conf || echo "Bootchart not set in GRUB"
3. rpm -q --scripts bootchart
  
Actual results:
The text 'init=/sbin/bootchartd' is not added to grub.conf....
[chris@chris ~]$ sudo yum install bootchart
### snip ###
Running Transaction
  Installing     : jakarta-commons-lang                                     1/4 
  Installing     : jakarta-commons-logging                                  2/4 
  Installing     : jakarta-commons-cli                                      3/4 
  Installing     : bootchart                                                4/4 
/sbin/grubby --update-kernel=/boot/boot/vmlinuz-2.6.27.12-170.2.5.fc10.i686.PAE --args=init=/sbin/bootchartd

Installed:
  bootchart.i386 0:0.9-9.fc9                                                    

Expected results:


Additional info:

Comment 1 Chris Gardner 2009-02-13 19:05:58 UTC
Created attachment 331857 [details]
Patch suggestion

Have downloaded 'bootchart.spec' from CVS and attempted to create a diff/patch. Hope it makes sense!

Comment 2 Chris Gardner 2009-09-03 21:55:30 UTC
Still present in Fedora 11.
Doing 'yum update' showed the following:
/sbin/grubby --update-kernel=/boot/boot/vmlinuz-2.6.29.4-167.fc11.i686.PAE --args=init=/sbin/bootchartd

Note the double 'boot' in the path.

Comment 3 Bug Zapper 2010-04-27 12:57:49 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 4 Fabien Archambault 2010-05-27 14:47:50 UTC
Hello,

I would like to bump this to F13 as I have the same problem.

I made a "yum install bootchart" to try then rebooted the system and it seemed that nothing was created...
I watched inside the /boot and I have got no information on bootchart written inside it.

Tried to reinstall:
# yum reinstall bootchart
Loaded plugins: fastestmirror, presto, refresh-packagekit, security
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
 * fedora: ftp.lip6.fr
 * livna: rpm.livna.org
 * rpmfusion-free: download1.rpmfusion.org
 * rpmfusion-free-updates: download1.rpmfusion.org
 * rpmfusion-nonfree: download1.rpmfusion.org
 * rpmfusion-nonfree-updates: download1.rpmfusion.org
 * updates: ftp.lip6.fr
Resolving Dependencies
--> Running transaction check
---> Package bootchart.x86_64 0:0.9-11.fc12 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

===========================================================================================================================================
 Package                           Arch                           Version                             Repository                      Size
===========================================================================================================================================
Reinstalling:
 bootchart                         x86_64                         0.9-11.fc12                         fedora                         242 k

Transaction Summary
===========================================================================================================================================
Remove        0 Package(s)
Reinstall     1 Package(s)
Downgrade     0 Package(s)

Total download size: 242 k
Installed size: 897 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 242 k
bootchart-0.9-11.fc12.x86_64.rpm                                                                                    | 242 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : bootchart-0.9-11.fc12.x86_64                                                                                        1/1 
/sbin/grubby --update-kernel=/boot/boot/vmlinuz-2.6.33.4-95.fc13.x86_64 --args=init=/sbin/bootchartd

Installed:
  bootchart.x86_64 0:0.9-11.fc12                                                                                                           

Complete!


As you can see the path for the update kernel is wrong...

Comment 5 Chris Gardner 2010-05-31 15:25:06 UTC
This is still here in Fedora 13.
It's a 10 second fix and only 2 lines in 'bootchart.spec' need tweaking!

Lines 63 and 64 from [1] need changing as follows...
Replace:
--update-kernel=/boot"$kernel"
with:
--update-kernel="$kernel"

The variable "$kernel" is already an absolute path, it doesn't need the extra '/boot' putting in front of it.

regards,
Chris

=====
[1] http://cvs.fedoraproject.org/viewvc/rpms/bootchart/F-13/bootchart.spec?view=markup

Comment 6 Harald Hoyer 2011-02-18 12:34:04 UTC
Hmmm... on Fedora 14, it is:

$ sudo  /sbin/grubby --info /boot/vmlinuz-$(uname -r) |grep kernel=
kernel=/vmlinuz-2.6.35.10-74.fc14.x86_64


So, has grubby changed? Or do I miss something?

Comment 7 Chris Gardner 2011-03-31 20:45:43 UTC
Looks like grubby's behaviour changed. On F13:

$ sudo /sbin/grubby --info /boot/vmlinuz-$(uname -r) |grep kernel=
kernel=/boot/vmlinuz-2.6.34.8-68.fc13.x86_64

I don't have a Fedora 14 system to test on but it looks like the issue will be resolved... but something still doesn't seem right.

From comment #6, grubby in F14 seems to think that:
  /vmlinuz-* == /boot/vmlinuz-*
Is this right? Is grubby supposed to return an absolute or relative path to the kernel?


Note You need to log in before you can comment on or make changes to this bug.