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

Aaron Griffin aaronmgriffin at gmail.com
Tue Jan 31 10:07:11 PST 2006


On 1/31/06, H. Peter Anvin <hpa at zytor.com> wrote:
> Aaron Griffin wrote:
> > 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.
> >
>
> No, the point he's making is that we need to make sure that the
> in-kernel cpio extractor can handle overwriting a symlink with a file,
> which I'm not sure the current one does.

Ah, I misread.  Thanks for the correction.



More information about the klibc mailing list