Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 218611 - sys-boot/grub-0.97-r5: Segmentation fault during emerge
Summary: sys-boot/grub-0.97-r5: Segmentation fault during emerge
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-20 16:28 UTC by Martin von Gagern
Modified: 2008-11-05 22:44 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Commands passed through grub (grub-batch.txt,1.06 KB, text/plain)
2008-04-20 16:30 UTC, Martin von Gagern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin von Gagern 2008-04-20 16:28:04 UTC
When emerging grub, the ebuild runs the grub shell with some commands greped from the grub.conf. In sys-boot/grub-0.97-r5 this causes a SIGSEGV for me. While the correct solution to this immediate problem during emerge is not running these commands through grub shell, as I've just argued in bug 218599, it still is an indication of something going wrong inside grub, so it should be investigate further.

After some trickery with CFLAGS="-ggdb -O0" USE=custom-cflags FEATURES=nostrip I managed to get the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x08064df4 in load_image (kernel=0xb7bd1c67 "/boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1",
    arg=0xb7bbd000 "/boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1", suggested_type=KERNEL_TYPE_NONE, load_flags=1) at boot.c:408
408                   *(dest++) = *(src++);
(gdb) bt
#0  0x08064df4 in load_image (kernel=0xb7bd1c67 "/boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1",
    arg=0xb7bbd000 "/boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1", suggested_type=KERNEL_TYPE_NONE, load_flags=1) at boot.c:408
#1  0x0806008b in kernel_func (arg=0xb7bd1c67 "/boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1", flags=1) at builtins.c:2582
#2  0x0806354f in enter_cmdline (heap=0xb7bd1c60 "kernel /boot/vanilla/vmlinuz console=tty0 console=ttyS0,115200n8 libata.pata_dma=1", forever=1) at cmdline.c:172
#3  0x0805c1ee in cmain () at stage2.c:1079
#4  0x0804d188 in init_bios_info () at common.c:337
#5  0x08049dae in doit () at asmstub.c:180
#6  0x08049c56 in grub_stage2 () at asmstub.c:263
#7  0x08049905 in main (argc=1, argv=0xbfbf8544) at main.c:264

Notice that line 408 is not the one inserted by 550_all_grub-0.97-long-commandline.patch but rather the one directly before that, limited by LINUX_CL_END_OFFSET.
Comment 1 Martin von Gagern 2008-04-20 16:30:31 UTC
Created attachment 150424 [details]
Commands passed through grub

These are the commands that the ebuild greps from my grub.conf and passes through grub. The /boot/vanilla/vmlinuz where the error occurs is a linux-2.6.25-rc9 kernel with a built-in initfs.
Comment 2 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-05-02 19:55:52 UTC
Retest with newer grub please, make sure you get patchset 1.7.
Probably fix this in -r6 otherwise.
Comment 3 Martin von Gagern 2008-05-02 21:12:37 UTC
(In reply to comment #2)
> Retest with newer grub please, make sure you get patchset 1.7.
> Probably fix this in -r6 otherwise.

Still an issue with PATCHVER="1.7".

As my menu contains no setup or install commands, running them through grub to reproduce the issue should be fairly easy. I hope it doesn't depend on kernel image files, though.
Comment 4 Peter Levine 2008-05-11 03:01:33 UTC
I have gotten this same segfault for some time.
Same thing happens when using the "kernel" command in the grub shell in a booted linux environment.

Perhaps I'm missing the point of grepping the grub.conf into grub.
Wouldn't one expect a problem with loading a kernel in an already running linux environment?
Shouldn't grep filter the "kernel" line and simply pass the "root" and "setup" or "install" lines, assuming that that is the point of the post-install routine anyway?
Comment 5 Martin von Gagern 2008-05-11 09:53:08 UTC
(In reply to comment #4)
> Perhaps I'm missing the point of grepping the grub.conf into grub.
> Wouldn't one expect a problem with loading a kernel in an already running
> linux environment?

Loading the kernel into grub memory should be no problem. Only booting the kernel should be avoided, and I doubt that the grub shell would ever do that, it's not the "real" grub, after all.

> Shouldn't grep filter the "kernel" line and simply pass the "root" and "setup"
> or "install" lines, assuming that that is the point of the post-install
> routine anyway?

I agree that there is something wrong with this post-install setup, and wrote at length about it in bug 218599. Here, I'd like to focus on the SEGFAULT as an indication of an internal error, and delegate all discussion about how the ebuild should invoke the grub shell to more appropriate bug reports.
Comment 6 Peter Levine 2008-05-17 03:22:00 UTC
Installed from custom grub vanilla ebuild (no patches), using both gcc42 and gcc43. Still segfaults while loading kernel
Comment 7 Weedy 2008-07-05 03:11:24 UTC
I straced grub and got the following

sync()                                  = 0
open("/dev/sda", O_RDWR|O_LARGEFILE)    = 3
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
ioctl(3, BLKGETSIZE, 0xb7a20b3c)        = 0
ioctl(3, 0x301, 0xb7a20b34)             = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
ioctl(3, BLKFLSBUF, 0)                  = 0
open("/dev/sdb", O_RDWR|O_LARGEFILE)    = 4
read(4, "\353H\220\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKGETSIZE, 0xb7a20b3c)        = 0
ioctl(4, 0x301, 0xb7a20b34)             = 0
_llseek(4, 0, [0], SEEK_SET)            = 0
read(4, "\353H\220\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
ioctl(4, BLKFLSBUF, 0)                  = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Comment 8 T Chan 2008-07-14 23:59:43 UTC
Still present in grub-0.97-r6
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-05 22:44:08 UTC
Please test 0.97-r8 that is in package.mask very carefully (aka have a livecd
handy), but this should now be fixed.