I have installed the grub svn live ebuild. And I noticed two problems: 1) device.map and grub.cfg are automatically replaced (and note that if /boot is not mounted it'll write in the /boot dir anyways .. which shouldn't happen) 2) grub-mkconfig (that is automatically executed when the installation ends) can't find my /boot/kernel-version (i don't use genkernel so i havent an initrd for example) .. The biggest problem is that grub replaces the config with an empty one when i install it.
umm, i dont think so ... if you read the grub ebuild, it will only generate grub.cfg if one doesnt already exist. as for device.map, the same thing here. if the file doesnt exist, then one is created, otherwise it is left alone. we dont patch grub-mkconfig in any way. if you have a problem with it, report the issue upstream. grub2 is not supported here.
(In reply to comment #1) > umm, i dont think so ... if you read the grub ebuild, it will only generate > grub.cfg if one doesnt already exist. as for device.map, the same thing here. > if the file doesnt exist, then one is created, otherwise it is left alone. > > we dont patch grub-mkconfig in any way. if you have a problem with it, report > the issue upstream. grub2 is not supported here. > Yes, problem 1 was my fault. But /boot should either be automatically mounted before writing in it or not writing at all. As per problem 2, I think it's a template problem. So even if you don't patch it (I guess it's automatically created even though i can't see how), /etc/grub/ templates may need a patch to recognize gentoo-style kernels (so also manual configuration).
post the output of `ls /boot/` ... i dont use any Gentoo related packages to build my kernel, so i dont know what they look like
ok i got the same problem and solved it. it's a problem in the /etc/grub.d/10_linux script. this one searches for kernels that are named vmlinu[zx]-* if you named your kernel(s) different in the boot directory then grub-mkconfig won't find anything. So the easiest way to solve this is to rename your kernel to something complying to this script. This is however not a nice way to solve this for long term. the script should be rewritten to accept more than just these names. but this is a bug for the grub people because it is not gentoo related.
someone still needs to answer my comment #3 ... i dont use genkernel and so i have no idea what it outputs
from the gentoo handbook over genkernel http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7#doc_chap4 (in the genkernel chapter) Code Listing 4.4: Checking the created kernel image name and initrd # ls /boot/kernel* /boot/initramfs* so i would guess it is named kernel* sry i can't give more information i use the source of the kernel myself, never used genkernel
(In reply to comment #5) > someone still needs to answer my comment #3 ... > > i dont use genkernel and so i have no idea what it outputs > Without using genkernel you only have /boot/grub /boot/kernel-version-gentoo-release (or just kernel-version-release) While for genkernel I have one computer using it, so I can have a look. But I think for genkernel grub2 script would just work I guess since the kernel is called vmlinuz .. and there's a initrd* if I remember well.
if you use the normal `make install` method from the kernel, you get files named /boot/vmlinuz-<version> which means grub2 has no problems finding the files someone who has a system where grub2 didnt find any kernels has to post `ls /boot` or this bug goes nowhere
Ok i tried grub2 together with genkernel and it didn't find the kernel. $ ls /boot/ boot grub initramfs-genkernel-x86_64-2.6.28-gentoo-r1 kernel-genkernel-x86_64-2.6.28-gentoo-r1 System.map-genkernel-x86_64-2.6.28-gentoo-r1 The gentoo handbook suggests the manual way that is $ ls /boot/ boot grub kernel-2.6.28-r1 Neither the former or the latter are found by the grub2 template.
thanks, should be fixed now http://sources.gentoo.org/sys-boot/grub/files/grub-1.96-genkernel.patch?rev=1.1
I fixed the problem by installing the latest version of os-prober, which was version 1.44 at the time of this writing.
(In reply to comment #11) > I fixed the problem by installing the latest version of os-prober, which was > version 1.44 at the time of this writing. I was running Linux Mint 9, using grub-pc on a multi-boot system, with Gentoo on one of the partitions.
(In reply to comment #12) > (In reply to comment #11) > > I fixed the problem by upgrading to the latest version of os-prober, which was > > version 1.44 at the time of this writing. I was running Linux Mint 9, using grub-pc on a multi-boot system, with Gentoo on one of the partitions.
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > I fixed the problem by upgrading to the latest version of os-prober, which was > > > version 1.44 at the time of this writing. I was running Linux Mint 9, using grub-pc on a multi-boot system, with Gentoo on one of the partitions. I did not have to edit the 10_linux file according to this bug.
