Re: [PATCH 2/3][try 1] init: enable system-on-initramfs: root-on-tmpfs

Re: [PATCH 2/3][try 1] init: enable system-on-initramfs: root-on-tmpfs

[Bodo Eggert]

Al Boldi <a1426z@gawab.com> wrote:
> Bodo Eggert wrote:

Please reply-to-all, I'm not subscribed, but reading through a news gateway.

>> This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to use
>> tmpfs instead of ramfs". All the fame belongs to him, the bugs belong to
>> me.
> 
> Actually, my patch was a rework of John Zielinski's
> http://marc.info/?l=linux-kernel&m=107013630212011&w=4 patch, so the credit
> really goes to him.

>> Signed-Off-By: Bodo Eggert <7eggert@gmx.de>
>>
>>
>> diff -Xdontdiff -pruN linux-2.6.22.base/fs/Kconfig
>> linux-2.6.22.tmpfsroot/fs/Kconfig --- linux-2.6.22.base/fs/Kconfig
>> 2007-07-12 14:05:16.000000000 +0200 +++ linux-2.6.22.tmpfsroot/fs/Kconfig
>>  2007-07-12 15:10:09.000000000 +0200 @@ -989,6 +989,22 @@ config
>> TMPFS_POSIX_ACL
> 
> Setting this in fs/Kconfig is way to deep, and too far away from the
> initramfs Kconfig, which makes it obscure.

If it were under general setup, you'd have to enter fs to select tmpfs,
enter general setup to replace ramfs, and re-enter fs to disable ramfs.
I consider making people do that to be an evil deed.

The current position is very convenient, ramfs is below tmpfs, and while you
go from top to the bottom, you can enable tmpfs, tmpfs-replaces-ramfs and
ramfs=n.

>>           If you don't know what Access Control Lists are, say N.
>>
>> +config TMPFS_ROOT
>> +       bool "Use tmpfs instrad of ramfs for initramfs"
> 
> Check typo.
> 
>> +       depends on TMPFS
> 
> Should probably depend on SHMEM too.

Sounds reasonable.

>> @@ -1003,7 +1019,7 @@ config HUGETLB_PAGE
>>         def_bool HUGETLBFS
>>
>>  config RAMFS
>> -       bool
>> +       bool "Ramfs file system support" if TMPFS_ROOT
> 
> What's wrong with the original Kconfig of making this tristate?

I tested =m, found it not to compile because of a nonexported __symbol
and decided it wasn't worth the effort of adding another export while
other people struggle to reduce their number.

>> diff -Xdontdiff -pruN linux-2.6.22.base/mm/shmem.c
>> linux-2.6.22.tmpfsroot/mm/shmem.c --- linux-2.6.22.base/mm/shmem.c
>> 2007-07-12 14:05:25.000000000 +0200 +++ linux-2.6.22.tmpfsroot/mm/shmem.c
>>  2007-07-12 15:01:32.000000000 +0200 @@ -2369,6 +2369,8 @@ static void
>> init_once(void *foo, struct
>>
>>  static int init_inodecache(void)
>>  {
>> +       if (shmem_inode_cachep)
>> +               return 0;
>>         shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
>>                                 sizeof(struct shmem_inode_info),
>>                                 0, 0, init_once, NULL);
>> @@ -2582,6 +2584,34 @@ put_memory:
>>         return ERR_PTR(error);
>>  }
>>
>> +#ifdef CONFIG_TMPFS_ROOT
>> +static int rootfs_get_sb(struct file_system_type *fs_type,
>> +       int flags, const char *dev_name, void *data, struct vfsmount *mnt)
>> +{
>> +       return get_sb_nodev(fs_type, flags|MS_NOUSER, data,
>> shmem_fill_super, +                           mnt);
> 
> Setting the MS_NOUSER flag will make this invisible to df (diskfree).

Which is obviously a bad thing for my cause, but good if you'd boot a
normal system. Is there any way out?

>> +}
>> +
>> +/*static struct super_block *rootfs_get_sb(struct file_system_type
>> *fs_type, +       int flags, const char *dev_name, void *data)
>> +{
>> +       return get_sb_single(fs_type, flags, data, shmem_fill_super);
>> +}*/
> 
> You commented this out, probably asking for clarification:  IIRC, it's
> get_sb_single instead of get_sb_nodev, because tmpfs can be mounted more
> than once and thus needs to be reference counted.

No, I had left it there accidentially. Your comment tells me it was ment to
happen.
-- 
If at first you don't succeed call in an air-strike. 

Friß, Spammer: zbyUv@7nKzeel.7eggert.dyndns.org J@op16.7eggert.dyndns.org
 NS6uqbvhd9@d.7eggert.dyndns.org QcPun@SgLk.7eggert.dyndns.org

Re: [PATCH 2/3][try 1] init: enable system-on-initramfs: root-on-tmpfs

[Al Boldi]

Bodo Eggert wrote:
> Al Boldi <a1426z@gawab.com> wrote:
> > Bodo Eggert wrote:
>
> Please reply-to-all, I'm not subscribed, but reading through a news
> gateway.

Same here.  The problem is, I have no idea who's on the cc, and expected you 
to be on the list.  Sorry.

> >> This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to use
> >> tmpfs instead of ramfs". All the fame belongs to him, the bugs belong
> >> to me.
> >
> > Actually, my patch was a rework of John Zielinski's
> > http://marc.info/?l=linux-kernel&m=107013630212011&w=4 patch, so the
> > credit really goes to him.
> >
> >> Signed-Off-By: Bodo Eggert <7eggert@gmx.de>
> >>
> >>
> >> diff -Xdontdiff -pruN linux-2.6.22.base/fs/Kconfig
> >> linux-2.6.22.tmpfsroot/fs/Kconfig --- linux-2.6.22.base/fs/Kconfig
> >> 2007-07-12 14:05:16.000000000 +0200 +++
> >> linux-2.6.22.tmpfsroot/fs/Kconfig 2007-07-12 15:10:09.000000000 +0200
> >> @@ -989,6 +989,22 @@ config TMPFS_POSIX_ACL
> >
> > Setting this in fs/Kconfig is way to deep, and too far away from the
> > initramfs Kconfig, which makes it obscure.
>
> If it were under general setup, you'd have to enter fs to select tmpfs,
> enter general setup to replace ramfs, and re-enter fs to disable ramfs.
> I consider making people do that to be an evil deed.

That's easy to fix, just change "depends on" to "select" in Kconfig.

> The current position is very convenient, ramfs is below tmpfs, and while
> you go from top to the bottom, you can enable tmpfs, tmpfs-replaces-ramfs
> and ramfs=n.
>
> >>           If you don't know what Access Control Lists are, say N.
> >>
> >> +config TMPFS_ROOT
> >> +       bool "Use tmpfs instrad of ramfs for initramfs"
> >
> > Check typo.
> >
> >> +       depends on TMPFS
> >
> > Should probably depend on SHMEM too.
>
> Sounds reasonable.
>
> >> @@ -1003,7 +1019,7 @@ config HUGETLB_PAGE
> >>         def_bool HUGETLBFS
> >>
> >>  config RAMFS
> >> -       bool
> >> +       bool "Ramfs file system support" if TMPFS_ROOT
> >
> > What's wrong with the original Kconfig of making this tristate?
>
> I tested =m, found it not to compile because of a nonexported __symbol
> and decided it wasn't worth the effort of adding another export while
> other people struggle to reduce their number.

Ok.

> >> diff -Xdontdiff -pruN linux-2.6.22.base/mm/shmem.c
> >> linux-2.6.22.tmpfsroot/mm/shmem.c --- linux-2.6.22.base/mm/shmem.c
> >> 2007-07-12 14:05:25.000000000 +0200 +++
> >> linux-2.6.22.tmpfsroot/mm/shmem.c 2007-07-12 15:01:32.000000000 +0200
> >> @@ -2369,6 +2369,8 @@ static void init_once(void *foo, struct
> >>
> >>  static int init_inodecache(void)
> >>  {
> >> +       if (shmem_inode_cachep)
> >> +               return 0;
> >>         shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
> >>                                 sizeof(struct shmem_inode_info),
> >>                                 0, 0, init_once, NULL);
> >> @@ -2582,6 +2584,34 @@ put_memory:
> >>         return ERR_PTR(error);
> >>  }
> >>
> >> +#ifdef CONFIG_TMPFS_ROOT
> >> +static int rootfs_get_sb(struct file_system_type *fs_type,
> >> +       int flags, const char *dev_name, void *data, struct vfsmount
> >> *mnt) +{
> >> +       return get_sb_nodev(fs_type, flags|MS_NOUSER, data,
> >> shmem_fill_super, +                           mnt);
> >
> > Setting the MS_NOUSER flag will make this invisible to df (diskfree).
>
> Which is obviously a bad thing for my cause, but good if you'd boot a
> normal system. Is there any way out?

Just remove the MS_NOUSER flag.  Normal systems would want to umount it after 
pivoting, so it won't be visible then.

> >> +}
> >> +
> >> +/*static struct super_block *rootfs_get_sb(struct file_system_type
> >> *fs_type, +       int flags, const char *dev_name, void *data)
> >> +{
> >> +       return get_sb_single(fs_type, flags, data, shmem_fill_super);
> >> +}*/
> >
> > You commented this out, probably asking for clarification:  IIRC, it's
> > get_sb_single instead of get_sb_nodev, because tmpfs can be mounted more
> > than once and thus needs to be reference counted.
>
> No, I had left it there accidentially. Your comment tells me it was ment
> to happen.


Thanks!

--
Al

Re: [PATCH 2/3][try 1] init: enable system-on-initramfs: root-on-tmpfs

[Al Boldi]

 
What happened to this one?  Is it in -mm?


Thanks!

--
Al

Al Boldi wrote:
> Bodo Eggert wrote:
> > Al Boldi <a1426z@gawab.com> wrote:
> > > Bodo Eggert wrote:
> > >> This is a rework of Al Boldi's "[PATCH] initramfs: Allow rootfs to
> > >> use tmpfs instead of ramfs". All the fame belongs to him, the bugs
> > >> belong to me.
> > >
> > > Actually, my patch was a rework of John Zielinski's
> > > http://marc.info/?l=linux-kernel&m=107013630212011&w=4 patch, so the
> > > credit really goes to him.
> > >
> > >> Signed-Off-By: Bodo Eggert <7eggert@gmx.de>
> > >>
> > >>
> > >> diff -Xdontdiff -pruN linux-2.6.22.base/fs/Kconfig
> > >> linux-2.6.22.tmpfsroot/fs/Kconfig --- linux-2.6.22.base/fs/Kconfig
> > >> 2007-07-12 14:05:16.000000000 +0200 +++
> > >> linux-2.6.22.tmpfsroot/fs/Kconfig 2007-07-12 15:10:09.000000000 +0200
> > >> @@ -989,6 +989,22 @@ config TMPFS_POSIX_ACL
> > >
> > > Setting this in fs/Kconfig is way to deep, and too far away from the
> > > initramfs Kconfig, which makes it obscure.
> >
> > If it were under general setup, you'd have to enter fs to select tmpfs,
> > enter general setup to replace ramfs, and re-enter fs to disable ramfs.
> > I consider making people do that to be an evil deed.
>
> That's easy to fix, just change "depends on" to "select" in Kconfig.
>
> > The current position is very convenient, ramfs is below tmpfs, and while
> > you go from top to the bottom, you can enable tmpfs,
> > tmpfs-replaces-ramfs and ramfs=n.
> >
> > >>           If you don't know what Access Control Lists are, say N.
> > >>
> > >> +config TMPFS_ROOT
> > >> +       bool "Use tmpfs instrad of ramfs for initramfs"
> > >
> > > Check typo.
> > >
> > >> +       depends on TMPFS
> > >
> > > Should probably depend on SHMEM too.
> >
> > Sounds reasonable.
> >
> > >> @@ -1003,7 +1019,7 @@ config HUGETLB_PAGE
> > >>         def_bool HUGETLBFS
> > >>
> > >>  config RAMFS
> > >> -       bool
> > >> +       bool "Ramfs file system support" if TMPFS_ROOT
> > >
> > > What's wrong with the original Kconfig of making this tristate?
> >
> > I tested =m, found it not to compile because of a nonexported __symbol
> > and decided it wasn't worth the effort of adding another export while
> > other people struggle to reduce their number.
>
> Ok.
>
> > >> diff -Xdontdiff -pruN linux-2.6.22.base/mm/shmem.c
> > >> linux-2.6.22.tmpfsroot/mm/shmem.c --- linux-2.6.22.base/mm/shmem.c
> > >> 2007-07-12 14:05:25.000000000 +0200 +++
> > >> linux-2.6.22.tmpfsroot/mm/shmem.c 2007-07-12 15:01:32.000000000 +0200
> > >> @@ -2369,6 +2369,8 @@ static void init_once(void *foo, struct
> > >>
> > >>  static int init_inodecache(void)
> > >>  {
> > >> +       if (shmem_inode_cachep)
> > >> +               return 0;
> > >>         shmem_inode_cachep = kmem_cache_create("shmem_inode_cache",
> > >>                                 sizeof(struct shmem_inode_info),
> > >>                                 0, 0, init_once, NULL);
> > >> @@ -2582,6 +2584,34 @@ put_memory:
> > >>         return ERR_PTR(error);
> > >>  }
> > >>
> > >> +#ifdef CONFIG_TMPFS_ROOT
> > >> +static int rootfs_get_sb(struct file_system_type *fs_type,
> > >> +       int flags, const char *dev_name, void *data, struct vfsmount
> > >> *mnt) +{
> > >> +       return get_sb_nodev(fs_type, flags|MS_NOUSER, data,
> > >> shmem_fill_super, +                           mnt);
> > >
> > > Setting the MS_NOUSER flag will make this invisible to df (diskfree).
> >
> > Which is obviously a bad thing for my cause, but good if you'd boot a
> > normal system. Is there any way out?
>
> Just remove the MS_NOUSER flag.  Normal systems would want to umount it
> after pivoting, so it won't be visible then.
>
> > >> +}
> > >> +
> > >> +/*static struct super_block *rootfs_get_sb(struct file_system_type
> > >> *fs_type, +       int flags, const char *dev_name, void *data)
> > >> +{
> > >> +       return get_sb_single(fs_type, flags, data, shmem_fill_super);
> > >> +}*/
> > >
> > > You commented this out, probably asking for clarification:  IIRC, it's
> > > get_sb_single instead of get_sb_nodev, because tmpfs can be mounted
> > > more than once and thus needs to be reference counted.
> >
> > No, I had left it there accidentially. Your comment tells me it was ment
> > to happen.
>
> Thanks!
>
> --
> Al

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Al Boldi]

Bodo Eggert wrote:
> On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> > Bodo Eggert wrote:
> > > On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> > >> Bodo Eggert wrote:
> > >>> Setting the name of the rdinit process to the name of the init
> > >>> process in order to select the root device should not be the right
> > >>> knob.
> > >>
> > >> What's wrong with it?
> > >
> > > rdinit is supposed to be the program that mounts, root is supposed to
> > > be whatever is mounted and init is supposed to run the system. Three
> > > different things. Now if you want to change the third, just set the
> > > first to the second ...
> >
> > That only applies to a model that you explicitly doesn't want to use.
>
> I don't want to use rdinit, because there is no task for rdinit(3), and I
> don't want to mount a filesystem(3). But I do want to use init(2).
>
> I have to lie to the kernel saying (2) is (1) in order to trick it into
> beleaving I'd do (3) myself, which I don't, just in order to not do (3).
> If the bug of not calling the security hook would be fixed, this trick
> would use the path where rdinit is expected to trigger the callback, but
> since that rdinit would be no rdinit, that callback would still be wrongly
> skipped. That would not be a bad thing for my setup, but it clearly shows
> this setup to be wrong.
>
> The correct solution is tell the kernel not to do (3) if you don't want
> it to do (3). The rest will work as intended.

Sounds rather confusing.

This is how I see it:

  initrd=initrd.img.gz implies root=rootfs
  rdinit=/bin/sh is the special init=/bin/sh for initrd.

Both initrd/root and rdinit/init must be separate for pivoting to succeed.  
If you want to drop into the initrd (i.e. rootfs), then instruct your 
initrd.img.gz not to pivot (i.e. not over-mount another filesystem).


Thanks!

--
Al

[PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

I toyed with setting up a diskless system in initramfs. In the process, I
came across some things:

1)  There is no way to have the kernel not mount a filesystem,
    unless you use /init or rdinit=.

1a) In the process of writing these patches, I found prepare_namespace not to
    be called if /init is present. prepare_namespace will call
    security_sb_post_mountroot after mounting the root fs. I did not yet see
    a way to call this from /init, and grepping kinit for "security" did not
    help, too.

   This is probably a bug, but using the features of this patchset, you'll
   avoid hitting it. Therefore this patchset does nothing about that.
 
2)  If you want to use tmpfs, you need a script which essentially duplicates
    the work the kernel just did: Mount the root fs, unpack or move the files.
    Using tmpfs instead for the first root mount is as cheap as using ramfs,
    as long as tmpfs is used anyway (and most likely it is).

2a) I figured if you prepared the root fs to contain a running system, you
    woud probably also set up a runnable system on it. Therefore I changed
    the default to boot from tmpfs if there was no /init nor a root= option.
    (If there is a /init, it will be executed as usural.)

    Unfortunately the way I do it, this will override the rdev setting, but
    that should be OK, since rdev is dead. Isn't it?

3)  While I was at it, I figured I would not need most of the init/mount*
    code anymore. Therefore I made patch 3, which ifdefs it out as far as
    possible while still aiming for a small change.

Patch 1 adds the capability to use root=rootfs.
Patch 2 adds the capability to use tmpfs for root, default root=rootfs.
        ramfs becomes optional if rootfs=tmpfs.
Patch 3 allows to remove the capability of automounting filesystems.

All patches appyl to 2.6.22.1
-- 
Fun things to slip into your budget
Remuneration compensation upgrade. (otherwise called a pay raise).

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[H. Peter Anvin]

Bodo Eggert wrote:
> I toyed with setting up a diskless system in initramfs. In the process, I
> came across some things:
> 
> 1)  There is no way to have the kernel not mount a filesystem,
>     unless you use /init or rdinit=.

And?  Just use rdinit=/sbin/init and no patch is needed.

> 2a) I figured if you prepared the root fs to contain a running system, you
>     woud probably also set up a runnable system on it. Therefore I changed
>     the default to boot from tmpfs if there was no /init nor a root= option.
>     (If there is a /init, it will be executed as usural.)
> 
>     Unfortunately the way I do it, this will override the rdev setting, but
>     that should be OK, since rdev is dead. Isn't it?

That's pretty hideous.  There shouldn't be a need for doing that.

rdev, unfortunately, isn't dead -- it lives on in the form of
/proc/sys/kernel/real-root-dev, as I found out doing the klibc set.

	-hpa

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:

> > I toyed with setting up a diskless system in initramfs. In the process, I
> > came across some things:
> > 
> > 1)  There is no way to have the kernel not mount a filesystem,
> >     unless you use /init or rdinit=.
> 
> And?  Just use rdinit=/sbin/init and no patch is needed.

rdinit is supposed to do a different job from /sbin/init, therefore it
will not do the security callbacks the original code would do.

And besides that, it feels like turning the wrong knob for that task.

> > 2a) I figured if you prepared the root fs to contain a running system, you
> >     woud probably also set up a runnable system on it. Therefore I changed
> >     the default to boot from tmpfs if there was no /init nor a root= option.
> >     (If there is a /init, it will be executed as usural.)
> > 
> >     Unfortunately the way I do it, this will override the rdev setting, but
> >     that should be OK, since rdev is dead. Isn't it?
> 
> That's pretty hideous.  There shouldn't be a need for doing that.
> 
> rdev, unfortunately, isn't dead -- it lives on in the form of
> /proc/sys/kernel/real-root-dev, as I found out doing the klibc set.

It just missed it's own funeral:
"Obsolete root change mechanism
 ------------------------------

 The following mechanism was used before the introduction of pivot_root.
 Current kernels still support it, but you should _not_ rely on its
 continued availability." (Documentation/initrd.txt)


I don't insist on changing the default, it was just a logical step from 
preparing initramfs to hold a system.

-- 
Top 100 things you don't want the sysadmin to say:
48. Tell me again what that '-r' option to rm does

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[H. Peter Anvin]

Bodo Eggert wrote:
> On Fri, 13 Jul 2007, H. Peter Anvin wrote:
>> Bodo Eggert wrote:
> 
>>> I toyed with setting up a diskless system in initramfs. In the process, I
>>> came across some things:
>>>
>>> 1)  There is no way to have the kernel not mount a filesystem,
>>>     unless you use /init or rdinit=.
>> And?  Just use rdinit=/sbin/init and no patch is needed.
> 
> rdinit is supposed to do a different job from /sbin/init, therefore it
> will not do the security callbacks the original code would do.
> 
> And besides that, it feels like turning the wrong knob for that task.

No, it is exactly the right knob for the task.

The fact that the security callbacks don't get invoked when using an
initramfs *AT ALL* is the real problem.

	-hpa

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > On Fri, 13 Jul 2007, H. Peter Anvin wrote:
> >> Bodo Eggert wrote:

> >>> I toyed with setting up a diskless system in initramfs. In the process, I
> >>> came across some things:
> >>>
> >>> 1)  There is no way to have the kernel not mount a filesystem,
> >>>     unless you use /init or rdinit=.
> >> And?  Just use rdinit=/sbin/init and no patch is needed.
> > 
> > rdinit is supposed to do a different job from /sbin/init, therefore it
> > will not do the security callbacks the original code would do.
> > 
> > And besides that, it feels like turning the wrong knob for that task.
> 
> No, it is exactly the right knob for the task.

Setting the name of the rdinit process to the name of the init process
in order to select the root device should not be the right knob.

> The fact that the security callbacks don't get invoked when using an
> initramfs *AT ALL* is the real problem.

It's one more problem.
-- 
Interchangeable parts aren't. 

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[H. Peter Anvin]

Bodo Eggert wrote:
> 
> Setting the name of the rdinit process to the name of the init process
> in order to select the root device should not be the right knob.
> 

What's wrong with it?

	-hpa

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:

> > Setting the name of the rdinit process to the name of the init process
> > in order to select the root device should not be the right knob.
> > 
> 
> What's wrong with it?

rdinit is supposed to be the program that mounts, root is supposed to be 
whatever is mounted and init is supposed to run the system. Three 
different things. Now if you want to change the third, just set the first 
to the second ...

-- 
Whenever you have plenty of ammo, you never miss. Whenever you are low on
ammo, you can't hit the broad side of a barn.

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[H. Peter Anvin]

Bodo Eggert wrote:
> On Sat, 14 Jul 2007, H. Peter Anvin wrote:
>> Bodo Eggert wrote:
> 
>>> Setting the name of the rdinit process to the name of the init process
>>> in order to select the root device should not be the right knob.
>>>
>> What's wrong with it?
> 
> rdinit is supposed to be the program that mounts, root is supposed to be 
> whatever is mounted and init is supposed to run the system. Three 
> different things. Now if you want to change the third, just set the first 
> to the second ...

That only applies to a model that you explicitly doesn't want to use.

	-hpa

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> Bodo Eggert wrote:
> > On Sat, 14 Jul 2007, H. Peter Anvin wrote:
> >> Bodo Eggert wrote:

> >>> Setting the name of the rdinit process to the name of the init process
> >>> in order to select the root device should not be the right knob.
> >>>
> >> What's wrong with it?
> > 
> > rdinit is supposed to be the program that mounts, root is supposed to be 
> > whatever is mounted and init is supposed to run the system. Three 
> > different things. Now if you want to change the third, just set the first 
> > to the second ...
> 
> That only applies to a model that you explicitly doesn't want to use.

I don't want to use rdinit, because there is no task for rdinit(3), and I 
don't want to mount a filesystem(3). But I do want to use init(2).

I have to lie to the kernel saying (2) is (1) in order to trick it into
beleaving I'd do (3) myself, which I don't, just in order to not do (3).
If the bug of not calling the security hook would be fixed, this trick
would use the path where rdinit is expected to trigger the callback, but
since that rdinit would be no rdinit, that callback would still be wrongly
skipped. That would not be a bad thing for my setup, but it clearly shows
this setup to be wrong.

The correct solution is tell the kernel not to do (3) if you don't want 
it to do (3). The rest will work as intended.

-- 
This message transmitted on 100% recycled electrons. 

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Rob Landley]

On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote:
> I toyed with setting up a diskless system in initramfs. In the process, I
> came across some things:
>
> 1)  There is no way to have the kernel not mount a filesystem,
>     unless you use /init or rdinit=.

Er, yes.  By design.

The kernel has to run an init program in order to hand off control to 
userspace.  In initramfs, this is defined as /init.  It looks in exactly one 
documented place.

The older root= mechanism fell back to a half-dozen places (eventually trying 
things like /bin/sh if it couldn't find anything else).  This is because 
there wasn't a documented standard for what should be executed, like there is 
with initramfs.

> 1a) In the process of writing these patches, I found prepare_namespace not
> to be called if /init is present. prepare_namespace will call
>     security_sb_post_mountroot after mounting the root fs. I did not yet
> see a way to call this from /init, and grepping kinit for "security" did
> not help, too.

I don't use selinux.  I'm neither a Fortune 500 company nor the NSA.

However, if you don't trust your own initramfs, where everything starts out 
running as root, you have bigger problems.

>    This is probably a bug, but using the features of this patchset, you'll
>    avoid hitting it. Therefore this patchset does nothing about that.
>
> 2)  If you want to use tmpfs, you need a script which essentially
> duplicates the work the kernel just did: Mount the root fs, unpack or move
> the files.

mkdir sub
mount -t tmpfs sub sub
cp -ax / sub
switch_root sub /init-stage-2

I haven't tried it but it really doesn't sound like brain surgery.  If your 
switch_root is statically linked, you can use mv instead of cp.

> Using tmpfs instead for the first root mount is as cheap as 
> using ramfs, as long as tmpfs is used anyway (and most likely it is).

*shrug*  I don't object to doing so, but I've heard nebulous technical 
objections from people who know more about the implementation details fo 
tmpfs than I do.

> 2a) I figured if you prepared the root fs to contain a running system, you
>     woud probably also set up a runnable system on it.

*scratches head*

That's a tautology, right?

>     Therefore I changed 
>     the default to boot from tmpfs if there was no /init nor a root=
> option. (If there is a /init, it will be executed as usural.)

I have no idea what you just said.  If there's an /init, we boot from it.  If 
there's no /init, they just violated the spec and we don't know what to boot 
from.

They made an initramfs.  They constructed it, explicitly, for the Linux 
kernel, and /init is what the kernel will try to boot.  I documented this 
years ago.  If they chose not to put an /init, then they didn't want us to 
boot from initramfs.  (Maybe they're supplying firmware and an /sbin/hotplug 
for a statically linked device.  I dunno.)

>     Unfortunately the way I do it, this will override the rdev setting, but
>     that should be OK, since rdev is dead. Isn't it?
>
> 3)  While I was at it, I figured I would not need most of the init/mount*
>     code anymore. Therefore I made patch 3, which ifdefs it out as far as
>     possible while still aiming for a small change.
>
> Patch 1 adds the capability to use root=rootfs.

I've been using initramfs since back around 2.6.12.  It works fine.  Why are 
you patching the kernel for something that already works?

> Patch 2 adds the capability to use tmpfs for root, default root=rootfs.
>         ramfs becomes optional if rootfs=tmpfs.
> Patch 3 allows to remove the capability of automounting filesystems.
>
> All patches appyl to 2.6.22.1

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Wed, 18 Jul 2007, Rob Landley wrote:
> On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote:

> > I toyed with setting up a diskless system in initramfs. In the process, I
> > came across some things:
> >
> > 1)  There is no way to have the kernel not mount a filesystem,
> >     unless you use /init or rdinit=.
> 
> Er, yes.  By design.
> 
> The kernel has to run an init program in order to hand off control to 
> userspace.  In initramfs, this is defined as /init.  It looks in exactly one 
> documented place.
> 
> The older root= mechanism fell back to a half-dozen places (eventually trying 
> things like /bin/sh if it couldn't find anything else).  This is because 
> there wasn't a documented standard for what should be executed, like there is 
> with initramfs.

Ever since I started using linux in 1997, the first program to run from an
installed system was /sbin/init. (I might think about removing the other 
paths.)

The ramfs' /init was intended for system setup, which is a separate job.
It is not intended to be the program running the system. Mixing those two
up just does not feel right. Setting root= in order to change the root
directory is much more natural.

> > 1a) In the process of writing these patches, I found prepare_namespace not
> > to be called if /init is present. prepare_namespace will call
> >     security_sb_post_mountroot after mounting the root fs. I did not yet
> > see a way to call this from /init, and grepping kinit for "security" did
> > not help, too.
> 
> I don't use selinux.  I'm neither a Fortune 500 company nor the NSA.

That's no reason for keeping bugs in that part.

> However, if you don't trust your own initramfs, where everything starts out 
> running as root, you have bigger problems.

Using that argument, you can deduce that nobody would need selinux at all.
Obviously some people disagree, and maybe some of them are no fools,
therefore we should try to DTRT for them and do the callback when it's
supposed to happen.

BTW: The problems start as soon as you have to do "reflections on trusting 
trust".

> >    This is probably a bug, but using the features of this patchset, you'll
> >    avoid hitting it. Therefore this patchset does nothing about that.
> >
> > 2)  If you want to use tmpfs, you need a script which essentially
> > duplicates the work the kernel just did: Mount the root fs, unpack or move
> > the files.
> 
> mkdir sub
> mount -t tmpfs sub sub
> cp -ax / sub
> switch_root sub /init-stage-2
> 
> I haven't tried it but it really doesn't sound like brain surgery.  If your 
> switch_root is statically linked, you can use mv instead of cp.

Why should I have to do that if I can do the right thing in the first 
place with in each respect negative costs?

> > Using tmpfs instead for the first root mount is as cheap as 
> > using ramfs, as long as tmpfs is used anyway (and most likely it is).
> 
> *shrug*  I don't object to doing so, but I've heard nebulous technical 
> objections from people who know more about the implementation details fo 
> tmpfs than I do.

Obviously these problems were solved.

> > 2a) I figured if you prepared the root fs to contain a running system, you
> >     woud probably also set up a runnable system on it.
> 
> *scratches head*
> 
> That's a tautology, right?

You may also use the same kernel with the same initramfs in order to start
a classic system, just by changing root=. This may be nice for rescue
systems. Off cause after applying the third patch, you may also unselect
that feature.

> >     Therefore I changed 
> >     the default to boot from tmpfs if there was no /init nor a root=
> > option. (If there is a /init, it will be executed as usural.)
> 
> I have no idea what you just said.  If there's an /init, we boot from it.  If 
> there's no /init, they just violated the spec and we don't know what to boot 
> from.

These patches changes the spec in order to support system-on-rootfs:

If there is an init, it will run. No change from the current situation 
ever, at least if not using rdev.

If you use root=rootfs, a system-on-rootfs will run.

If you use rootfs=tmpfs, root= will default to rootfs, and I did it in a 
way disabeling that obsolete rdev.

> They made an initramfs.  They constructed it, explicitly, for the Linux 
> kernel, and /init is what the kernel will try to boot.  I documented this 
> years ago.  If they chose not to put an /init, then they didn't want us to 
> boot from initramfs.  (Maybe they're supplying firmware and an /sbin/hotplug 
> for a statically linked device.  I dunno.)

Not booting /using/ an intramfs differs from not booting /from/ an 
intramfs. Mixing them works by accident.

> >     Unfortunately the way I do it, this will override the rdev setting, but
> >     that should be OK, since rdev is dead. Isn't it?
> >
> > 3)  While I was at it, I figured I would not need most of the init/mount*
> >     code anymore. Therefore I made patch 3, which ifdefs it out as far as
> >     possible while still aiming for a small change.
> >
> > Patch 1 adds the capability to use root=rootfs.
> 
> I've been using initramfs since back around 2.6.12.  It works fine.  Why are 
> you patching the kernel for something that already works?

Why do you build a way if walking through the fields already works?
Besides that, using all these features safes about 3KB.
-- 
bus error. passengers dumped.

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Stephen Smalley]

On Thu, 2007-07-19 at 15:56 +0200, Bodo Eggert wrote:
> On Wed, 18 Jul 2007, Rob Landley wrote:
> > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote:
> 
> > > I toyed with setting up a diskless system in initramfs. In the process, I
> > > came across some things:
> > >
> > > 1)  There is no way to have the kernel not mount a filesystem,
> > >     unless you use /init or rdinit=.
> > 
> > Er, yes.  By design.
> > 
> > The kernel has to run an init program in order to hand off control to 
> > userspace.  In initramfs, this is defined as /init.  It looks in exactly one 
> > documented place.
> > 
> > The older root= mechanism fell back to a half-dozen places (eventually trying 
> > things like /bin/sh if it couldn't find anything else).  This is because 
> > there wasn't a documented standard for what should be executed, like there is 
> > with initramfs.
> 
> Ever since I started using linux in 1997, the first program to run from an
> installed system was /sbin/init. (I might think about removing the other 
> paths.)
> 
> The ramfs' /init was intended for system setup, which is a separate job.
> It is not intended to be the program running the system. Mixing those two
> up just does not feel right. Setting root= in order to change the root
> directory is much more natural.
> 
> > > 1a) In the process of writing these patches, I found prepare_namespace not
> > > to be called if /init is present. prepare_namespace will call
> > >     security_sb_post_mountroot after mounting the root fs. I did not yet
> > > see a way to call this from /init, and grepping kinit for "security" did
> > > not help, too.
> > 
> > I don't use selinux.  I'm neither a Fortune 500 company nor the NSA.
> 
> That's no reason for keeping bugs in that part.
> 
> > However, if you don't trust your own initramfs, where everything starts out 
> > running as root, you have bigger problems.
> 
> Using that argument, you can deduce that nobody would need selinux at all.
> Obviously some people disagree, and maybe some of them are no fools,
> therefore we should try to DTRT for them and do the callback when it's
> supposed to happen.

Not wanting to get into any flamewars here about selinux, but just FYI:
security_sb_post_mountroot is obsolete and can be removed without harm
to selinux; it is a leftover of selinux before we moved the initial
policy load to userspace.  These days, initial policy load is done
by /sbin/init in most distros that support selinux, although I'd prefer
to do it earlier from the initramfs (the Fedora folks didn't like that
idea though at the time, so /sbin/init got patched instead - but that
was back in 2003, so maybe things have changed).

-- 
Stephen Smalley
National Security Agency

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Bodo Eggert]

On Thu, 19 Jul 2007, Stephen Smalley wrote:

> Not wanting to get into any flamewars here about selinux, but just FYI:
> security_sb_post_mountroot is obsolete and can be removed without harm
> to selinux; it is a leftover of selinux before we moved the initial
> policy load to userspace.  These days, initial policy load is done
> by /sbin/init in most distros that support selinux, although I'd prefer
> to do it earlier from the initramfs (the Fedora folks didn't like that
> idea though at the time, so /sbin/init got patched instead - but that
> was back in 2003, so maybe things have changed).

Thanks, that information will help a lot.
-- 
Funny quotes:
7. You have the right to remain silent. Anything you say will be misquoted,
   then used against you.

Re: [PATCH 0/3][try 1] init: enable system-on-initramfs

[Rob Landley]

I had this unsent on my desktop, buried by other windows.  Let me know if the 
conversation's moved on since, but if so I wasn't cc'd...

On Thursday 19 July 2007 9:56:11 am Bodo Eggert wrote:
> On Wed, 18 Jul 2007, Rob Landley wrote:
> > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote:
> > > I toyed with setting up a diskless system in initramfs. In the process,
> > > I came across some things:
> > >
> > > 1)  There is no way to have the kernel not mount a filesystem,
> > >     unless you use /init or rdinit=.
> >
> > Er, yes.  By design.
> >
> > The kernel has to run an init program in order to hand off control to
> > userspace.  In initramfs, this is defined as /init.  It looks in exactly
> > one documented place.
> >
> > The older root= mechanism fell back to a half-dozen places (eventually
> > trying things like /bin/sh if it couldn't find anything else).  This is
> > because there wasn't a documented standard for what should be executed,
> > like there is with initramfs.
>
> Ever since I started using linux in 1997, the first program to run from an
> installed system was /sbin/init. (I might think about removing the other
> paths.)

So pass in rdinit=/sbin/init.  (Back in 1997 you didn't have to 
specify "root=", you used rdev.)

> The ramfs' /init was intended for system setup, which is a separate job.

The ramfs /init was "intended" to be the first process to run, which inherits 
PID 1 and thus all responsibility for further system setup.  You can't return 
back to the kernel from that, it panics if PID 1 exits.  Whether you choose 
to do "system setup" or keep running with rootfs as your root filesystem 
(very popular with embedded devices) is not the kernel's problem.

This has been documented and has worked fine for years.

Note that the initrd mechanism (which used to run /linuxrc) was _not_ PID 1, 
and expected you to return to the kernel.  That's one of the big improvements 
initramfs made over initrd.

> It is not intended to be the program running the system.

That's policy, and none of the kernel's business.

> Mixing those two 
> up just does not feel right.

You're mixing them in your head, and it sounds like you don't understand what 
it's doing.

> Setting root= in order to change the root 
> directory is much more natural.

Setting root= is not _used_ if initramfs triggers, because /init gets run 
before ever reaching that code.  In initramfs, the root filesystem is rootfs, 
and no attempt to mount anything else is made by the kernel unless userspace 
explicitly asks for it.  Userspace is welcome to mount anything it wants, and 
userspace can switch_root to it, but that's not the kernel's problem.

> > > 1a) In the process of writing these patches, I found prepare_namespace
> > > not to be called if /init is present. prepare_namespace will call
> > >     security_sb_post_mountroot after mounting the root fs. I did not
> > > yet see a way to call this from /init, and grepping kinit for
> > > "security" did not help, too.
> >
> > I don't use selinux.  I'm neither a Fortune 500 company nor the NSA.
>
> That's no reason for keeping bugs in that part.

*shrug*  I was saying I can't really comment much on a subsystem I neither use 
nor see much point in.

> > However, if you don't trust your own initramfs, where everything starts
> > out running as root, you have bigger problems.
>
> Using that argument, you can deduce that nobody would need selinux at all.

Yeah, pretty much.  Then again I feel the same way about the Itanium, and try 
to stay out of the way of people who feel they do need it.

> Obviously some people disagree, and maybe some of them are no fools,
> therefore we should try to DTRT for them and do the callback when it's
> supposed to happen.
>
> BTW: The problems start as soon as you have to do "reflections on trusting
> trust".

Which led to David Wheeler's "diverse double-compiling": 
http://www.dwheeler.com/trusting-trust/

Which led to rather a lot of patches being integrated into the tcc fork I 
maintain in my nonexistent free time, such as: 
http://www.landley.net/hg/tinycc?cs=e6ddaffce6a8

> > > Using tmpfs instead for the first root mount is as cheap as
> > > using ramfs, as long as tmpfs is used anyway (and most likely it is).
> >
> > *shrug*  I don't object to doing so, but I've heard nebulous technical
> > objections from people who know more about the implementation details fo
> > tmpfs than I do.
>
> Obviously these problems were solved.

I'm all for a patch to make initramfs use tmpfs.  I'm kind of dubious about 
one coming from somebody who thinks that the initramfs interface in use by 
thousands of developers for years now needs to be totally rewritten as a 
prerequisite of doing so.

> > > 2a) I figured if you prepared the root fs to contain a running system,
> > > you woud probably also set up a runnable system on it.
> >
> > *scratches head*
> >
> > That's a tautology, right?
>
> You may also use the same kernel with the same initramfs in order to start
> a classic system, just by changing root=.

Do you mean if you program initramfs to parse the environment variable "root", 
or if you set rdinit=/nonexistent and fall back to the old root= code?

> > I have no idea what you just said.  If there's an /init, we boot from it.
> >  If there's no /init, they just violated the spec and we don't know what
> > to boot from.
>
> These patches changes the spec in order to support system-on-rootfs:

When I said the existing initramfs interface has been "in use by thousands of 
developers for years now", I wasn't speaking metaphorically.  I was speaking 
from personal experience.

Hi.  I used to maintain busybox, which is probably _the_ most widely used 
embedded Linux package.  I wrote the kernel's current 
Documentation/filesystems/ramfs-rootfs-initramfs.txt and some other random
documentation on initramfs (http://linuxdevices.com/articles/AT4017834659.html 
and http://www.timesys.com/timesource/initramfs.htm).  I have personally 
taken apart a dozen or more different systems using "system-on-rootfs", and 
know _of_ over a hundred.  I can tell you the plusses and minuses of doing 
that vs jffs2 vs squashfs vs ext2.  Entire system generators like buildroot 
and uClinux create initramfs images by default.

This is why I'm fairly certain the current initramfs interface is usable by a 
large variety of people.

> If there is an init, it will run. No change from the current situation
> ever, at least if not using rdev.
>
> If you use root=rootfs, a system-on-rootfs will run.
>
> If you use rootfs=tmpfs, root= will default to rootfs, and I did it in a
> way disabeling that obsolete rdev.

The way to specify a filesystem type to go with the mount "root=" does is 
actually "rootfstype=".  I use this when mounting a hostfs root for User Mode 
Linux, ala this woefully out of date document:
http://landley.net/writing/docs/UML.html

You don't specify a filesystem type for "root=", you specify a path there.

> > They made an initramfs.  They constructed it, explicitly, for the Linux
> > kernel, and /init is what the kernel will try to boot.  I documented this
> > years ago.  If they chose not to put an /init, then they didn't want us
> > to boot from initramfs.  (Maybe they're supplying firmware and an
> > /sbin/hotplug for a statically linked device.  I dunno.)
>
> Not booting /using/ an intramfs differs from not booting /from/ an
> intramfs. Mixing them works by accident.

I have no idea what you just said.

> > >     Unfortunately the way I do it, this will override the rdev setting,
> > > but that should be OK, since rdev is dead. Isn't it?
> > >
> > > 3)  While I was at it, I figured I would not need most of the
> > > init/mount* code anymore. Therefore I made patch 3, which ifdefs it out
> > > as far as possible while still aiming for a small change.
> > >
> > > Patch 1 adds the capability to use root=rootfs.
> >
> > I've been using initramfs since back around 2.6.12.  It works fine.  Why
> > are you patching the kernel for something that already works?
>
> Why do you build a way if walking through the fields already works?
> Besides that, using all these features safes about 3KB.

An option to removing the "root=" infrastructure that never gets reached if 
you use initramfs should save space, yes.  The other stuff you added just 
shows you don't seem to understand the existing, documented way to use 
initramfs.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.