Milton Miller
2006-Jan-30 23:10 UTC
[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)
On Mon Jan 30 08:56:06 PST 2006, H. Peter Anvin wrote:> That being said, there is no reason that you can't run code before it; > to make that simpler, in fact, I'm trying to set it up so that the > default initramfs looks like: > > /dev/console > /dev/zero > /dev/null > /kinit > /init -> /kinitI 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. We would be better off with a #! script instead, although that means the target has to accept at least the file name. milton
Aaron Griffin
2006-Jan-31 08:20 UTC
[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)
On 1/31/06, Milton Miller <miltonm@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
H. Peter Anvin
2006-Feb-01 18:40 UTC
[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)
Chris Wedgwood wrote:> On Wed, Feb 01, 2006 at 06:26:35PM -0800, H. Peter Anvin wrote: > >>Since the issue in question was overwriting a symbolic link with >>either another symbolic link or a file, it should be a non-issue. > > On reflection though I think it should just unlink in both cases.Which two cases? -hpa
Chris Wedgwood
2006-Feb-02 10:35 UTC
[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)
On Thu, Feb 02, 2006 at 10:10:29AM -0800, H. Peter Anvin wrote:> Unless linkable.linkable? what do you mean?
H. Peter Anvin
2006-Feb-02 15:47 UTC
[klibc] symlinks and initramfs (was klibc-1.2.1: kinit works...)
Chris Wedgwood wrote:> On Thu, Feb 02, 2006 at 10:10:29AM -0800, H. Peter Anvin wrote: > >>Unless linkable. > > linkable? what do you mean?Match the conditions for making a hard link. -hpa