/etc/grub.d/10_linux needs to be patched to include "initramfs-genkernel-x86_64-${version}" \ in the initrd detection section Reproducible: Always
why doesnt initramfs-genkernel-${version} match ? we dont want to go hardcoding arch lists into the search.
@Travis I am using GRUB2-1.99_rc1 and genkernel on a x86_64 machine, and here grub-mkconfig uses my initramfs just fine. This is because in 10_linux, ${alt_version} becomes x86_64-2.6.38 ($version too if you have no kernel with the postfix .old). So please state your version of GRUB2 and why the current scheme dows not work with that version.
Sorry about the delay, been out of town. Here is what I have.. [ebuild R ] sys-boot/grub-1.99_rc1 USE="truetype -custom-cflags -debug -multislot -static" 0 kB lrwxrwxrwx 1 root root 48 Nov 16 02:17 /etc/make.profile -> ../usr/portage/profiles/default/linux/amd64/10.0 [ebuild R ] sys-kernel/genkernel-3.4.15 USE="bash-completion (-ibm) (-selinux)" 0 kB I create the initrd using.. genkernel --lvm --dmraid --mdadm --mdadm-config=/etc/mdadm.conf initramfs It creates an image in /boot named following the pattern below initramfs-genkernel-x86_64-2.6.38-gentoo-r1 grub-mkconfig does not detect that pattern by default so I don't end up with an initrd image line in my grub.cfg
(In reply to comment #3) > genkernel --lvm --dmraid --mdadm --mdadm-config=/etc/mdadm.conf initramfs > > It creates an image in /boot named following the pattern below > > initramfs-genkernel-x86_64-2.6.38-gentoo-r1 > Then what is you *kernel* named as GRUB2 uses that file as template?
further, if the issue is fixed in grub-9999, then that's that. i'm not back porting stuff to grub-1.x.
(In reply to comment #5) > further, if the issue is fixed in grub-9999, then that's that. i'm not back > porting stuff to grub-1.x. I think the problem is that he not uses genkernel to make the kernel but compiles it himself and names it wrong. grub2 requires that the kernel and the initramfs follows the same naming scheme, so if he names it for example kernel-2.6.38-gentoo-r1 then grub2 will not pick up the arch bit, as the kernel does not have the arch bit.
Xake is correct. I compile my kernel manually and install simply using `make install` The resultant file is copied to /boot as vmlinuz-2.6.38-gentoo-r1 I'm not 'naming it wrong', I'm simply installing using make install so I'm not naming it at all manually.
(In reply to comment #7) > I'm not 'naming it wrong', I'm simply installing using make install so I'm not > naming it at all manually. Well, the problem here is the kernel uses one naming scheme that does not take arch into consideration and genkernel uses one that does. So, yes. You are naming it wrong for the automation to work. And since it is you who does not follow the same naming convention for the kernel as for the initramfs, I guess a hack/workaround for your particular case will not be fitted into GRUB2. You will not get us to change the default naming scheme for genkernel. If there is anything to this report it may be a feature request for genkernel to be able to produce a ramdisk following another naming scheme than the default one (or having a totally other name, a quick look only shows an option to change the "-genkernel-" part). I am currently to tired to look into if that feature already exists as a badly documented feature of genkernel or not at all. @vapier you may do what you like with this bug, but this is not a GRUB2 bug.
(In reply to comment #8) > (In reply to comment #7) > > I'm not 'naming it wrong', I'm simply installing using make install so I'm not > > naming it at all manually. > > Well, the problem here is the kernel uses one naming scheme that does not take > arch into consideration and genkernel uses one that does. > So, yes. You are naming it wrong for the automation to work. Uh, OK. Again, I'm not manually naming anything. > And since it is you who does not follow the same naming convention for the > kernel as for the initramfs, I guess a hack/workaround for your particular case > will not be fitted into GRUB2. That file is already being patched, I don't see how adding arch rendition to the list is obtrusive. > > You will not get us to change the default naming scheme for genkernel. If there > is anything to this report it may be a feature request for genkernel to be able > to produce a ramdisk following another naming scheme than the default one (or > having a totally other name, a quick look only shows an option to change the > "-genkernel-" part). I am currently to tired to look into if that feature > already exists as a badly documented feature of genkernel or not at all. > > > @vapier you may do what you like with this bug, but this is not a GRUB2 bug.
(In reply to comment #9) > Uh, OK. Again, I'm not manually naming anything. > You *DO* still name them (even if you are using tools to do it instead of doing it manually) using *TWO DIFFERENT* systems which uses *TWO DIFFERENT* naming schemes to generate the kernel and the initramfs. Now I can tell you that just using "genkernel all" to generate everything will make grub-mkconfig find both the kernel and the initramfs, since then you are using *ONE* system, using *ONE* naming scheme. So still: if there is something to this bugreport, it is a feature request to genkernel, adding an option making it possible to have genkernel generate a initramfs not using genkernels default names, or document it if this function already exists. But to be honest, I feel less and less compelled to look into that possibility the more this bug goes on, since for me genkernel works like it should, and the one requesting the feature acts like a dense prick. > That file is already being patched, I don't see how adding arch rendition to > the list is obtrusive. > Because adding the arch rendition is a WORKAROUND for something other problem, and will only produce unnecessary code to handle corner cases which should be fixed someplace else. And if you want to really have a system today, working fine, just with the automatic tools, then try something else like say dracut instead of genkernel. If you 'emerge dracut && dracut "" $(make -C /usr/src/linux kernelrelease)' it should automagically generate a ramdisk using the same naming convention as the kernel, and you will not have to manually intervene to workaround, say using two tools who uses two naming schemes...
I won't stoop to silly name calling. Feel free to close the bug. I am obviously capable of solving the problem and am fully aware of how things are functioning. I simply thought it would be convenient to have the extra option in an already-patched file for those who use my same setup. My apologies for offending you by the suggestion. (In reply to comment #10) > (In reply to comment #9) > > Uh, OK. Again, I'm not manually naming anything. > > > > You *DO* still name them (even if you are using tools to do it instead of doing > it manually) using *TWO DIFFERENT* systems which uses *TWO DIFFERENT* naming > schemes to generate the kernel and the initramfs. > > > Now I can tell you that just using "genkernel all" to generate everything will > make grub-mkconfig find both the kernel and the initramfs, since then you are > using *ONE* system, using *ONE* naming scheme. > > So still: if there is something to this bugreport, it is a feature request to > genkernel, adding an option making it possible to have genkernel generate a > initramfs not using genkernels default names, or document it if this function > already exists. But to be honest, I feel less and less compelled to look into > that possibility the more this bug goes on, since for me genkernel works like > it should, and the one requesting the feature acts like a dense prick. > > > That file is already being patched, I don't see how adding arch rendition to > > the list is obtrusive. > > > > Because adding the arch rendition is a WORKAROUND for something other problem, > and will only produce unnecessary code to handle corner cases which should be > fixed someplace else. > > > And if you want to really have a system today, working fine, just with the > automatic tools, then try something else like say dracut instead of genkernel. > > If you 'emerge dracut && dracut "" $(make -C /usr/src/linux kernelrelease)' it > should automagically generate a ramdisk using the same naming convention as the > kernel, and you will not have to manually intervene to workaround, say using > two tools who uses two naming schemes...
(In reply to comment #11) > I won't stoop to silly name calling. Feel free to close the bug. I am > obviously capable of solving the problem and am fully aware of how things are > functioning. I simply thought it would be convenient to have the extra option > in an already-patched file for those who use my same setup. My apologies for > offending you by the suggestion. > Sorry about the name calling, it was uncalled for. I was a bit tired and frustrated over other things, and pressed "Save Changes" before I took the deep breath and rewrote the comment as I usually do when that is the case. So I apologize for that. But the point still stands wrt how I see about GRUB2, the kernel and genkernel. The kernel and genkernel uses two different naming schemes by default, and the "working around" should be done by the user who chooses this setup, not incorporate it into a packages which will only makes these packages harder to maintain. Remember that in this example we had to make a patch that takes every arch into consideration (genkernel is supposed to work with 11 different arches) and that will turn a patch like this to grub2 into a bit of nightmare. Even if we just add the strings like in the patch you did that would be an additional 22 posts to that list for things to be somewhat proper, making this patch much bigger and less simpler. And also every future patch based on this taking space in the portage tree, re-generated when ever upstream has touched that file. Just to work around a problem some few corner cases hit. Now if a package makes it harder for the user to do said work around (like genkernel not supporting generating a ramdisk under a custom name like dracut does, or configure it to use a different custom name scheme) than that is a feature request for that package. Also using dracut may be a good alternative if you only want a ramdisk, it already handles most of the stuff genkernel does and some more. Genkernel currently works towards using dracut to generate the ramdisk anyway, so the more people that tests dracut in gentoo, the better.
(In reply to comment #12) > Sorry about the name calling, it was uncalled for. I was a bit tired and > frustrated over other things, and pressed "Save Changes" before I took the deep > breath and rewrote the comment as I usually do when that is the case. > So I apologize for that. No worries. > > Remember that in this example we had to make a patch that takes every arch into > consideration (genkernel is supposed to work with 11 different arches) and that Good point. I was unaware that grub2 was compatible with all these arches. > will turn a patch like this to grub2 into a bit of nightmare. Even if we just > add the strings like in the patch you did that would be an additional 22 posts > to that list for things to be somewhat proper, making this patch much bigger > and less simpler. And also every future patch based on this taking space in the > portage tree, re-generated when ever upstream has touched that file. Just to > work around a problem some few corner cases hit. Certainly a much simpler way to resolving that is by adding an ${arch} variable filled with `uname -m` > > > Now if a package makes it harder for the user to do said work around (like > genkernel not supporting generating a ramdisk under a custom name like dracut > does, or configure it to use a different custom name scheme) than that is a > feature request for that package. This was the original intent of the 'bug'. It certainly is not a 'problem' with grub2 > > Also using dracut may be a good alternative if you only want a ramdisk, it > already handles most of the stuff genkernel does and some more. Genkernel > currently works towards using dracut to generate the ramdisk anyway, so the > more people that tests dracut in gentoo, the better. I tried dracut originally way back. It simply didn't work at the time but I can try it again. I'm certainly a fringe case, but I'll give a little explanation as to why I use genkernel to begin with. I became aware that grub2 supported being installed on mdraid/lvm devices. As such I ventured down the path of creating an installation that has /boot on a mirrored md device and / on an lvm device that contains a striped md device. Previous to this point I never used initrds at all (which I presume is relatively common in gentoo-land for those that compile by hand). In order to boot properly I needed support for dm/lvm in an initrd but didn't care to use genkernel to build/install my kernel. So I used it simply for the necessary initrd image that contains md/lvm requirements. I describe all this simply to point out that others will probably follow the same tracks when grub2 becomes the default. Custom compile/install the kernel (business as usual) and then use genkernel to create a minimal initrd that contains simply the tools needed to boot properly off an md and/or lvm devices. Having said all that, I'm completely comfortable closing this. I simply wanted to bring it up for discussion as I feel others will find themselves in the same situation.
(In reply to comment #13) > > > > Remember that in this example we had to make a patch that takes every arch into > > consideration (genkernel is supposed to work with 11 different arches) and that > > Good point. I was unaware that grub2 was compatible with all these arches. > Genkernel is. GRUB2 currently aims to support everything x86 and ppc, and I think there has been work on other arches as well. So that patch becomes something for the maintainer to track to see what arches has bee added and are not supported anymore in the two projects. > > Certainly a much simpler way to resolving that is by adding an ${arch} variable > filled with `uname -m` > And with that the patch becomes much more complex, as we have to if-it so that the arch only becomes added when they need to be added, and also remember you cannot take for granted that all initramfs are made for the same arch as you are currenty running since at least some devs from time to time dualboot x86 and x86_64 kernels. > I tried dracut originally way back. It simply didn't work at the time but I > can try it again. > Dracut has come a long way since then. First time I tried dracut it eve failed to geerate a initramfs for me, nowdays it has no bigger problem handling my system. > I describe all this simply to > point out that others will probably follow the same tracks when grub2 becomes > the default. I am a bit sorry to say that it is probably a way left before GRUB2 becomes default, it has not even hit ~arch yet, and last time I heard something there was not much work being done on it, since noone really had the time working on it. My guess is that you will find a working dracut, and maybe even a stable genkernel with dracut as image generator before grub2 becomes stable and the default. So by that time this specific problem has probably been fixed in another way.
if there's a patch that needs to be applied (and isnt some local issue), then file a bug upstream.
It is local. It's essentially an extension of grub-1.99-genkernel.patch That was the original intent anyhow.
