[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