[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