Bug 235593

Summary: grubby segfaults on new kernel instal and also on simple things like --default-kernel
Product: [Fedora] Fedora Reporter: Phil Lobbes <phil>
Component: mkinitrdAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: phil, triage
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 19:29:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Phil Lobbes 2007-04-07 17:33:15 UTC
Description of problem:
grubby segfaults during installation of new kernel, but only on one system I
have while others work just fine.

I was installing the latest kernel, 2.6.20-1.2933.fc6xen, via yum update when I
received a segfault from grubby.  The error was:

/sbin/new-kernel-pkg: line 90: 29189 Segmentation fault      $grubby --ad
d-kernel=$bootPrefix/$kernelName-$version $INITRD --copy-default $makedefault --
title "$title" ${mbkernel:+--add-multiboot="$mbkernel"} ${mbargs:+--mbargs="$mba
rgs"} --args="root=$rootdevice $kernargs" --remove-kernel="TITLE=$title"

Running grubby by hand returns the same errors.  Running under gdb I don't get
much more information, but here it is:

# gdb /sbin/grubby
...
(gdb) run --add-kernel=/boot/vmlinuz-2.6.20-1.2933.fc6xen --initrd
/boot/initrd-2.6.20-1.2933.fc6xen.img --copy-default --title 'Fedora Core
(2.6.20-1.2933.fc6xen)' '--args=root=/dev/VG01/LVRoot '
'--remove-kernel=TITLE=Fedora Core (2.6.20-1.2933.fc6xen)'
Starting program: /sbin/grubby --add-kernel=/boot/vmlinuz-2.6.20-1.2933.fc6xen
--initrd /boot/initrd-2.6.20-1.2933.fc6xen.img --copy-default --title 'Fedora
Core (2.6.20-1.2933.fc6xen)' '--args=root=/dev/VG01/LVRoot '
'--remove-kernel=TITLE=Fedora Core (2.6.20-1.2933.fc6xen)'
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x008ee2a3 in strlen () from /lib/i686/nosegneg/libc.so.6

In fact, grubby seems to blow up even on "simple" things like trying to list the
default kernel:

(gdb) run --default-kernel
Starting program: /sbin/grubby --default-kernel
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x008ee2a3 in strlen () from /lib/i686/nosegneg/libc.so.6

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

How reproducible (only on one of my systems, others with exact same hardware and
packages besides the kernel run fine):

# /sbin/grubby --add-kernel=/boot/vmlinuz-2.6.20-1.2933.fc6xen --initrd
/boot/initrd-2.6.20-1.2933.fc6xen.img --copy-default --title 'Fedora Core
(2.6.20-1.2933.fc6xen)' '--args=root=/dev/VG01/LVRoot '
'--remove-kernel=TITLE=Fedora Core (2.6.20-1.2933.fc6xen)'

Steps to Reproduce:
Unfortunately, in the bigger picture I don't know how/what caused this to occur
on a single system.  So I can't say how to reproduce from scratch on a working
system.
  
Additional info:
It appears the problem must be related to /dev/mapper/control.  I have rebooted
the box to see if that helps clear out the problem but it does not.  Here is the
last part of an strace in case that helps...

10471 open("/dev/mapper/control", O_RDWR|O_LARGEFILE) = 4
10471 open("/proc/devices", O_RDONLY|O_LARGEFILE) = 5
10471 fstat64(5, {st_dev=makedev(0, 3), st_ino=4026531850, st_mode=S_IFREG|0444,
 st_nlink=1, st_uid=0, st_gid=0, st_blksize=1024, st_blocks=0, st_size=0, st_ati
me=2007/04/07-09:47:58, st_mtime=2007/04/07-09:47:58, st_ctime=2007/04/07-09:47:
58}) = 0
10471 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0xb7f13000
10471 read(5, "Character devices:\n  1 mem\n  4 /"..., 1024) = 405
10471 read(5, "", 1024)                 = 0
10471 close(5)                          = 0
10471 munmap(0xb7f13000, 4096)          = 0
10471 ioctl(4, DM_VERSION, 0x95eed98)   = 0
10471 ioctl(4, DM_LIST_DEVICES, 0x95eed98) = 0
10471 ioctl(4, DM_DEV_STATUS, 0x95eedf8) = 0
10471 ioctl(4, DM_TABLE_STATUS, 0x95eedf8) = 0
10471 ioctl(4, DM_DEV_STATUS, 0x95f2e10) = 0
10471 ioctl(4, DM_TABLE_STATUS, 0x95f2e10) = 0
10471 ioctl(4, DM_DEV_STATUS, 0x95f2e10) = 0
10471 ioctl(4, DM_TABLE_STATUS, 0x95f2e10) = 0
10471 ioctl(4, DM_DEV_STATUS, 0x95f2e10) = 0
10471 ioctl(4, DM_TABLE_STATUS, 0x95f2e10) = 0
10471 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
10471 +++ killed by SIGSEGV +++

I've verified that grub.conf is exactly the same as another on a working system,
except for the working system now has entries for the new kernel while this
system's grub.conf does not get updated because grubby blows up.

Any ideas what is causing this?

Comment 1 Jérôme Benoit 2007-12-04 17:49:00 UTC
Same thing here on F8 with latest kernel update ...

Comment 2 Bug Zapper 2008-04-04 06:48:39 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 3 Bug Zapper 2008-05-06 19:29:02 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.