Summary: | sys-boot/grub-0.97-r5: Segmentation fault during emerge | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | something-bz |
Priority: | High | ||
Version: | 2007.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Commands passed through grub |
Description
Martin von Gagern
2008-04-20 16:28:04 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.
Retest with newer grub please, make sure you get patchset 1.7. Probably fix this in -r6 otherwise. (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. 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? (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. Installed from custom grub vanilla ebuild (no patches), using both gcc42 and gcc43. Still segfaults while loading kernel 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 +++ Still present in grub-0.97-r6 Please test 0.97-r8 that is in package.mask very carefully (aka have a livecd handy), but this should now be fixed. |