[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)

Aaron Griffin aaronmgriffin at gmail.com
Tue Jan 31 08:19:53 PST 2006


On 1/31/06, Milton Miller <miltonm at bga.com> wrote:
> I would request we not put in symlinks.  The problem is that they are
> difficult to override.  Loading a later cpio has the effect of
> (attempting to) write over the current target of the symlink.  There is
> no "remove existing file or directory" entry in cpio.  This and the
> fact that initramfs only extends files are the two biggest limitations
> I've run into during the past 3 plus years.

I kind of thought that was the point he was making.  /kinit exists as
a hard file, symlinked to /init so that a user built initramfs can
replace /init easier, while still keeping /kinit in place.  Sure, you
could load an initramfs which overwrites /kinit while still expecting
/init to work as normal, but at that point you're just trying to
protect fools from themselves.

Aaron



More information about the klibc mailing list