Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 457168 - sys-kernel/genkernel - Initramfs-building clobbers /lib symlinks
Summary: sys-kernel/genkernel - Initramfs-building clobbers /lib symlinks
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: All Linux
: Highest critical (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2013-02-13 23:42 UTC by Greg Turner
Modified: 2014-02-27 23:07 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
a fix for the problem and some notes on cleaning up the aftermath (dont-clobber-lib-symilnks.patch,3.93 KB, patch)
2013-02-13 23:45 UTC, Greg Turner
Details | Diff
genkernel_say_no_to_clobbering.patch (genkernel.patch,524 bytes, patch)
2014-01-22 19:55 UTC, Greg Turner
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Turner 2013-02-13 23:42:33 UTC
after ~amd64 genkernel builds the initramfs, the /lib symlink is replaced by a regular directory with kernel modules in it.  The problem still exists in git master.

Reproducible: Always

Steps to Reproduce:
# 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

bad, bad, naughty, naughty genkernel!

This creates confusingly subtle, partial breakage that will exhibit "fluctuating," unpredictable results if the user starts re-emerging stuff to try and resolve the problem.  Unsurprisingly, it particularly tends to fuck up the correct operation of the gentoo initramfs and {e,}udev.

This can render systems unbootable (it did mine).  Recent baselayouts attempt to fix trivial cases but punt if it gets hairy.  See my enclosed patch for some code that could possibly be integrated into a more aggressive automatic and/or user-initiated repair operation.  One possibility would be to somehow put such a repair surgery into the initramfs itself -- otherwise, people are going to have trouble implementing the fix due to processes like udev locking up /lib.
Comment 1 Greg Turner 2013-02-13 23:45:15 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.
Comment 2 William Hubbs gentoo-dev 2013-02-14 18:26:50 UTC
This is a genkernel issue; gen_package.sh is not part of baselayout or
OpenRC.
Assigning to the appropriate team.
Comment 3 Greg Turner 2013-02-15 10:34:53 UTC
(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
Comment 4 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-17 02:41:20 UTC
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...
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-02-17 02:44:56 UTC
(Ignore the bit about INSTALL_MOD_PATH, that expands to / as well; misread)
Comment 6 Greg Turner 2013-02-18 07:44:44 UTC
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.
Comment 7 Greg Turner 2013-09-14 23:18:18 UTC
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.
Comment 8 Greg Turner 2014-01-22 19:55:13 UTC
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.
Comment 9 Rick Farina (Zero_Chaos) gentoo-dev 2014-01-24 17:23:54 UTC
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.
Comment 10 Richard Yao (RETIRED) gentoo-dev 2014-01-24 19:17:31 UTC
A fix has been pushed to genkernel head. A new release will be done by Monday that will remedy this issue.
Comment 11 Greg Turner 2014-01-24 20:18:43 UTC
Yaaay!

<insert confetti/party-hat emoticon here>
Comment 12 Richard Yao (RETIRED) gentoo-dev 2014-02-27 23:07:48 UTC
Some things are better late than never. Anyway, this is fixed in genkernel 3.4.48, which I just tagged.