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?
Same thing here on F8 with latest kernel update ...
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
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.