I recently tried to redo my kernel to support iptables and dhcpd. After many recompiles, I realized that the modules wern't getting installed because of some wierd dependancy... one module that I selected depended on another that i didn't include... (so there is a bug in the make menuconfig too,because it lets me make a non working kernel) anyway, It would be nice to have the || die portion actually tail the log and say... Failed! check the log at /var/log/genkernel Reproducible: Always Steps to Reproduce: 1.genkernel --config 2.turn on some things that need otherthings 3.don't include other things 4. Don't see error message 5. think it worked 6. reboot (edit grub.conf in this step) Actual Results: 7. have different errors from last time because modules are bad. Expected Results: spit out an error message: Kernel Compilation Failed, Check your options, and read /var/log/genkernel I wasted 16 hours of my life to this problem (well including the fact that it always does a make mrproper, which is a different issue... there could be an option --fast or such allowing make to use already compiled components)
This may be a duplicate of bug 35130, "genkernel fail". That bug has a complete kernel config file that generates the problem. I've been hit by this too. I haven't tracked it down as did the original poster, but the symptom is identical: genkernel exits after making modules and before installing them, and there is nothing in /var/log/genkernel.log indicating why it bailed out. This is with version 1.8 of genkernel, during a fresh install with 'emerge rsync' run yesterday.
this is to the original poster: what genkernel version are you using? You should be using genkernel 3.0.1 these days, we will not support genkernel 1.x also, /var/log/genkernel.log will ALWAYS show you the error. If the modules did not build, that's not a genkernel problem, there's nothing genkernel can do about that. It cannot fix bad kernel sources.
The problem is that genkernel only reported on success. So something could die in the kernel building process... and the user wouldn't know untill he tried to reboot. or run lilo. I'm always using a version that was released less than a week ago. I think I've had a kernel fail to compile, and got a bit of an error message... so part of this bug is fixed... The other part is tailing the log. just give 5 lines or so of the log. That should include some sort of message on how to fix it. rather than leaving a novice to read the /var/log/genkernel.log file
uhh, no. if that person is such a novice, then the last 5 lines of the log are going to cause us developers a lot of headaches. You have no clue how many people post a tail of a genkernel.log here, and the error is much further up. If they're a novice they're not going to figure out how to fix it themselves. Also, we'll be providing binary kernel packages in the future for these people. This will NEVER NEVER NEVER get added, do NOT reopen.
great point about the tail being a bad option. So... I think there are tools to search for error messages and spit out the area surrounding that So, I guess research into this has to be done (by me)... I think grepping for "In file included" and then getting the line number... and then grabbing the line above, and 1/2 page worth of text... should be enough to help. an --interactive option would be cool... or on by default... and ask the user if ve wants to debug, put said chunk into a less window. also looking for Error 2 could be helpfull. Note: I won't be offended by marking my bugs invalid, because marking bugs invalid is a good way to clear the system, and see how serious/willing to help the people are about a bug. I do wish for a bit more discussion before marking bugs as invalid... but... We're all busy. I don't mean offence by reopening bugs that you close... I was getting a bit aggitated earlier, but I found a good reason for your behavior, and am attempting to justify mine. as always, I'll take an unpopular bug as a reminder/incentive for me to work on it. ***************** LD [M] fs/exportfs/exportfs.o CC [M] crypto/ucl_compress.o In file included from /usr/include/features.h:295, from /usr/include/limits.h:26, from include/ucl/uclconf.h:46, from include/ucl/ucl.h:39, from crypto/ucl_compress.c:22: /usr/include/sys/cdefs.h:183:1: warning: "__attribute_pure__" redefined In file included from include/linux/compiler.h:16, from include/linux/init.h:5, from crypto/ucl_compress.c:19: include/linux/compiler-gcc3.h:22:1: warning: this is the location of the previous definition In file included from /usr/include/features.h:295, from /usr/include/limits.h:26, from include/ucl/uclconf.h:46, from include/ucl/ucl.h:39, from crypto/ucl_compress.c:22: /usr/include/sys/cdefs.h:192:1: warning: "__attribute_used__" redefined In file included from include/linux/compiler.h:16, from include/linux/init.h:5, from crypto/ucl_compress.c:19: include/linux/compiler-gcc3.h:17:1: warning: this is the location of the previous definition cp /usr/lib/libucl.a crypto/ cp: cannot stat `/usr/lib/libucl.a': No such file or directory make[1]: *** [crypto/libucl.a] Error 1 make: *** [crypto] Error 2 make: *** Waiting for unfinished jobs.... CC [M] fs/hfs/balloc.o CC [M] fs/intermezzo/cache.o CC [M] fs/hfs/bdelete.o
poking through man grep reveals: -B NUM, --before-context=NUM Print NUM lines of leading context before matching lines. Places a line containing -- between contiguous groups of matches. -A NUM, --after-context=NUM Print NUM lines of trailing context after matching lines. Places a line containing -- between contiguous groups of matches. the most common error messages are similar to: In file included from and make[number]: make[1]: *** [crypto/libucl.a] Error 1 make: *** [crypto] Error 2 make: *** Waiting for unfinished jobs.... The other things is that failure of some modules is "ok" as in not required to continue.. There perhaps should be a "trudge ahead" option and a genkernel --resume option will post a new bug for those... and I'm looking into this, I just need to learn bash scripting a bit better and maybe sommore awk sed or grep...
This will be fixed in my branch of genkernel in about a week or so.. http://www.student.northpark.edu/pemente/sed/sed1line.txt # print the line immediately before a regexp, but not the line # containing the regexp sed -n '/regexp/{g;1!p;};h' # print the line immediately after a regexp, but not the line # containing the regexp sed -n '/regexp/{n;p;}' # print 1 line of context before and after regexp, with line number # indicating where the regexp occurred (similar to "grep -A1 -B1") sed -n -e '/regexp/{=;x;1!p;g;$!N;p;D;}' -e h
I'm thinking about having the error message give additional advice... like say: The kernel compiled, but the initrd compile failed... you have these options: 1) fix the initrd configuration found in ...blah then run genkernel initrd then genkernel busybox 2) you might need to change (blah option.. in which case you can: rerun genkernel with --no-mrproper --no-clean to make it go faster Of course I don't know the sound advice... but I sure hate waiting for a half hour between kernel compiles just to find that something failed. also, I'm getting pretty sick of genkernel telling me too, my patch set changed the error message: * DO NOT REPORT KERNEL COMPILE FAILURES AS GENKERNEL BUGS! * * Report real genkernel bugs to bugs.gentoo.org
Automatic log grepping for problems on errors is now in; try out genkernel-3.0.2_rc1.
