First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 218611
Alias:
Product:
Component:
Status: RESOLVED
Resolution: TEST-REQUEST
Assigned To: Gentoo's Team for Core System packages <base-system@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Martin von Gagern <Martin.vGagern@gmx.net>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
grub-batch.txt Commands passed through grub text/plain Martin von Gagern 2008-04-20 16:30 0000 1.06 KB Details
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 218611 depends on: Show dependency tree
Bug 218611 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)


Not eligible to see or edit group visibility for this bug.






View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2008-04-20 16:28 0000
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 From Martin von Gagern 2008-04-20 16:30:31 0000 -------
Created an attachment (id=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 From Robin Johnson 2008-05-02 19:55:52 0000 -------
Retest with newer grub please, make sure you get patchset 1.7.
Probably fix this in -r6 otherwise.

------- Comment #3 From Martin von Gagern 2008-05-02 21:12:37 0000 -------
(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 From P. Levine 2008-05-11 03:01:33 0000 -------
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 From Martin von Gagern 2008-05-11 09:53:08 0000 -------
(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 From P. Levine 2008-05-17 03:22:00 0000 -------
Installed from custom grub vanilla ebuild (no patches), using both gcc42 and
gcc43. Still segfaults while loading kernel

------- Comment #7 From Weedy 2008-07-05 03:11:24 0000 -------
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 From T Chan 2008-07-14 23:59:43 0000 -------
Still present in grub-0.97-r6

------- Comment #9 From Robin Johnson 2008-11-05 22:44:08 0000 -------
Please test 0.97-r8 that is in package.mask very carefully (aka have a livecd
handy), but this should now be fixed.

First Last Prev Next    No search results available      Search page      Enter new bug