Summary: | sys-kernel/genkernel - Initramfs-building clobbers /lib symlinks | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Greg Turner <gmturner007> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | gmturner007, zerochaos |
Priority: | Highest | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
a fix for the problem and some notes on cleaning up the aftermath
genkernel_say_no_to_clobbering.patch |
Description
Greg Turner
2013-02-13 23:42:33 UTC
Created attachment 338814 [details, diff]
a fix for the problem and some notes on cleaning up the aftermath
See enclosed notes for a script that may help resolve the mess this bug has left behind.
This is a genkernel issue; gen_package.sh is not part of baselayout or OpenRC. Assigning to the appropriate team. (In reply to comment #0) > Steps to Reproduce: > # ls -ld /lib && ( genkernel initramfs 2>&1 ) >/dev/null 2&1 && ls -ld /lib correction: # ls -ld /lib && ( genkernel initramfs 2>&1 ) >/dev/null 2>&1 && ls -ld /lib > Actual Results: > /lib -> lib64 > /lib > > Expected Results: > /lib -> lib64 > /lib -> lib64 Confirmed, theory: > /bin/tar -xjf ${KERNCACHE} We unpack from KERNCACHE, which contains /lib/modules/* > -C / > -C ${INSTALL_MOD_PATH} We write to either / or /lib/modules/kernel-release/$(uname -r) > lib Uh oh, we extract from "lib", not from "lib/modules" in the archive; therefore we overwrite the existing "lib" in /, instead of starting from "lib/modules" and leaving "lib" alone... (Ignore the bit about INSTALL_MOD_PATH, that expands to / as well; misread) Good news: my friend on stable amd64 confirms that he did not catch this "/lib" disease during a recent according-to-handbook genkernel install process. So, seemingly, the scope of the secondary "broken '/lib'" problem is limited to either ~amd64 (or perhaps to people like me who only use genkernel as an initramfs builder). Anyhow my prediction that everybody under the sun was going to be suffering from this broken /lib disease may have been overly pessimistic. ~amd64 folks -- I'm hoping that's the relevant difference between my friend and myself -- are on average a pretty handy bunch, and there are much fewer of us. I'd say it's OK, in other words, to just fix the underlying bug. Maybe ewarn if and only if /lib isn't, but should be, a symlink (see: baselayout) AND the ctime of /lib/modules is very close to the ctime of /lib, since otherwise its unlikely genkernel had anything to do with it. This still remains? That's silly. Just apply the enclosed patch, ignore everything else in this bug, and forget about it. When this bug strikes, it's quite disruptive, incredibly difficult to diagnose, and, worse, broken /lib "keeps coming back" so long as your kernel build process involves a genkernel-generated initramfs. It's an incredibly annoying bug and incredibly easy to fix -- I strongly advise whoever's baby genkernel is, just apply my patch; it's a noop except that it fixes the bug, IIRC. Created attachment 368456 [details, diff]
genkernel_say_no_to_clobbering.patch
Updated version of the patch without any text. Perhaps the text was distracting people.
This is how we fixed the same issue in catalyst. It feels a bit safer to me this way but that means almost nothing. http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commitdiff;h=1e49d72 We really need to get this fixed. A fix has been pushed to genkernel head. A new release will be done by Monday that will remedy this issue. Yaaay! <insert confetti/party-hat emoticon here> Some things are better late than never. Anyway, this is fixed in genkernel 3.4.48, which I just tagged. |