[Buildroot] [git commit master 1/1] initramfs: update help text

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

commit: http://git.buildroot.net/buildroot/commit/?id=c2a44f158eedf40be3ab3bc3c76f61fe032d7b34
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
 fs/initramfs/Config.in |   24 +++++++++++++-----------
 1 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/fs/initramfs/Config.in b/fs/initramfs/Config.in
index c76b2de..abb3c0c 100644
--- a/fs/initramfs/Config.in
+++ b/fs/initramfs/Config.in
@@ -2,17 +2,19 @@ config BR2_TARGET_ROOTFS_INITRAMFS
 	bool "initramfs for initial ramdisk of linux kernel"
 	depends on BR2_LINUX_KERNEL
 	help
-	  Build a file which is usable for the gen_init_cpio tool
-	  at linux kernel build.
-	  This file is normally called initramfs_list and can be
-	  generated with gen_initramfs_list.sh script from the root
-	  directory structure.
-	  The file is then used in the kernel build process to generate
-	  the cpio filesystem for the initial ramdisk. Make sure that
-	  you configure this file in kernel build configuration.
-	  The location in the kernel build configuration menu is
-	  Device Drivers -> Block devices -> Initramfs source file(s).
-	  The configuration variable is CONFIG_INITRAMFS_SOURCE
+	  Integrate the root filesystem generated by Buildroot as an
+	  initramfs inside the kernel image. This integration will
+	  take place automatically.
+
+	  The rootfs.initramfs file generated in the images/ directory
+	  is only a text file describing the contents of the initramfs
+	  in a format understood by the CONFIG_INITRAMFS_SOURCE kernel
+	  configuration option.
+
+	  Note that enabling initramfs together with other filesystem
+	  formats doesn't make sense: you would end up having two
+	  identical root filesystems, one embedded inside the kernel
+	  image, and one separatly.
 
 comment "initramfs requires a Linux kernel to be built"
 	depends on !BR2_LINUX_KERNEL
-- 
1.7.1

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-26, Peter Korsgaard <jacmet@sunsite.dk> wrote:

> commit: http://git.buildroot.net/buildroot/commit/?id=c2a44f158eedf40be3ab3bc3c76f61fe032d7b34
> branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master

>  comment "initramfs requires a Linux kernel to be built"
>  	depends on !BR2_LINUX_KERNEL

Hey, wait a minute.

I use this option and I don't use Buildroot to build my kernel.

Can somebody explain why this functionality is being removed?

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Thomas Petazzoni]

Hi,

On Sat, 26 Jun 2010 14:21:29 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> > commit: http://git.buildroot.net/buildroot/commit/?id=c2a44f158eedf40be3ab3bc3c76f61fe032d7b34
> > branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
> 
> >  comment "initramfs requires a Linux kernel to be built"
> >  	depends on !BR2_LINUX_KERNEL
> 
> Hey, wait a minute.
> 
> I use this option and I don't use Buildroot to build my kernel.
> 
> Can somebody explain why this functionality is being removed?

How are you using this functionality without using Buildroot to build
your kernel ? Are you pointing your kernel configuration to the
rootfs.initramfs file generated by Buildroot ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 >> comment "initramfs requires a Linux kernel to be built"
 >> depends on !BR2_LINUX_KERNEL

 Grant> Hey, wait a minute.

 Grant> I use this option and I don't use Buildroot to build my kernel.

 Grant> Can somebody explain why this functionality is being removed?

How about just using the tarball output instead?

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-26, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> > commit: http://git.buildroot.net/buildroot/commit/?id=c2a44f158eedf40be3ab3bc3c76f61fe032d7b34
>> > branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
>> 
>> >  comment "initramfs requires a Linux kernel to be built"
>> >  	depends on !BR2_LINUX_KERNEL
>> 
>> Hey, wait a minute.
>> 
>> I use this option and I don't use Buildroot to build my kernel.
>> 
>> Can somebody explain why this functionality is being removed?
>
> How are you using this functionality without using Buildroot to build
> your kernel ? Are you pointing your kernel configuration to the
> rootfs.initramfs file generated by Buildroot ?

To the rootfs.initramfs_list file, yes.

I suppose I could have buildroot make the cpio archive and point the
kernel at that.

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-26, Peter Korsgaard <jacmet@uclibc.org> wrote:

> >> comment "initramfs requires a Linux kernel to be built"
> >> depends on !BR2_LINUX_KERNEL
>
> Grant> Hey, wait a minute.
>
> Grant> I use this option and I don't use Buildroot to build my kernel.
>
> Grant> Can somebody explain why this functionality is being removed?
>
> How about just using the tarball output instead?

When building an initramfs into a kernel, a tarball isn't one of the
options that's accepted by the kernel build system.

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

 >> How about just using the tarball output instead?

 Grant> When building an initramfs into a kernel, a tarball isn't one of the
 Grant> options that's accepted by the kernel build system.

No, but you could extract the tarball (as root or using fakeroot) and
point CONFIG_INITRAMFS_SOURCE to it.

But yes, providing a way to generate the cpio archive without building a
kernel would be nicer.

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Thomas Petazzoni]

On Sun, 27 Jun 2010 08:22:56 +0200
Peter Korsgaard <jacmet@uclibc.org> wrote:

> No, but you could extract the tarball (as root or using fakeroot) and
> point CONFIG_INITRAMFS_SOURCE to it.
> 
> But yes, providing a way to generate the cpio archive without building a
> kernel would be nicer.

Well, a cpio archive can be generated by Buildroot without having to
build a kernel, see fs/cpio/Config.in. What Grant was complaining about
originally was the fs/initramfs case. However, last time I tried
pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.

Instead of my original solution, another solution would be to *not*
make initramfs depend on BR2_LINUX_KERNEL, and to remove the dependency
initramfs->kernel so that the kernel doesn't try to be built as soon as
initramfs is selected. If kernel is selected, it will anyway be built
*before* going through the initramfs code.

Would this be ok ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-27, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:
>
> >> How about just using the tarball output instead?
>
> Grant> When building an initramfs into a kernel, a tarball isn't one of the
> Grant> options that's accepted by the kernel build system.
>
> No, but you could extract the tarball (as root or using fakeroot) and
> point CONFIG_INITRAMFS_SOURCE to it.

An extracted tarball isn't one of the options either.
CONFIG_INITRAMFS_SOURCE can be pointed at either a cpio archive or the
source file list.

> But yes, providing a way to generate the cpio archive without building a
> kernel would be nicer.

It works fine the way it is.  What's the reason for disabling the
buildign of a cpio file source list?

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-27, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> On Sun, 27 Jun 2010 08:22:56 +0200
> Peter Korsgaard <jacmet@uclibc.org> wrote:
>
>> No, but you could extract the tarball (as root or using fakeroot) and
>> point CONFIG_INITRAMFS_SOURCE to it.
>> 
>> But yes, providing a way to generate the cpio archive without building a
>> kernel would be nicer.
>
> Well, a cpio archive can be generated by Buildroot without having to
> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
> originally was the fs/initramfs case. However, last time I tried
> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.

I tried it, and it appeared to build OK -- but I haven't had a chance
to test the resulting image.

> Instead of my original solution, another solution would be to *not*
> make initramfs depend on BR2_LINUX_KERNEL, and to remove the
> dependency initramfs->kernel so that the kernel doesn't try to be
> built as soon as initramfs is selected. If kernel is selected, it
> will anyway be built *before* going through the initramfs code.
>
> Would this be ok ?

That would be fine for me, but if somebody is building both rootfs and
kernel, the initramfs source list (or the cpio archive) needs to be
built before the kernel.

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Thomas Petazzoni]

On Sun, 27 Jun 2010 13:42:34 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> > No, but you could extract the tarball (as root or using fakeroot) and
> > point CONFIG_INITRAMFS_SOURCE to it.
> 
> An extracted tarball isn't one of the options either.
> CONFIG_INITRAMFS_SOURCE can be pointed at either a cpio archive or the
> source file list.

Or a directory containing the hierarchy of files/directories to include
in the initramfs.

> > But yes, providing a way to generate the cpio archive without building a
> > kernel would be nicer.
> 
> It works fine the way it is.  What's the reason for disabling the
> buildign of a cpio file source list?

It was to fix bug #2119.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 Thomas> On Sun, 27 Jun 2010 08:22:56 +0200
 Thomas> Peter Korsgaard <jacmet@uclibc.org> wrote:

 >> No, but you could extract the tarball (as root or using fakeroot) and
 >> point CONFIG_INITRAMFS_SOURCE to it.
 >> 
 >> But yes, providing a way to generate the cpio archive without building a
 >> kernel would be nicer.

 Thomas> Well, a cpio archive can be generated by Buildroot without having to
 Thomas> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
 Thomas> originally was the fs/initramfs case. However, last time I tried
 Thomas> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.

So what is the difference between initramfs and cpio? Just the
integration with the kernel build for the first? Maybe the initramfs
stuff should simply be a 'embed in kernel' question on the cpio package
if the internal kernel build is enabled?

 Thomas> Instead of my original solution, another solution would be to
 Thomas> *not* make initramfs depend on BR2_LINUX_KERNEL, and to remove
 Thomas> the dependency initramfs-> kernel so that the kernel doesn't
 Thomas> try to be built as soon as initramfs is selected. If kernel is
 Thomas> selected, it will anyway be built *before* going through the
 Thomas> initramfs code.

 Thomas> Would this be ok ?

What would then be the difference between this and the cpio target?
 
-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

 >> No, but you could extract the tarball (as root or using fakeroot) and
 >> point CONFIG_INITRAMFS_SOURCE to it.

 Grant> An extracted tarball isn't one of the options either.
 Grant> CONFIG_INITRAMFS_SOURCE can be pointed at either a cpio archive or the
 Grant> source file list.

No? I haven't used initramfs in years, but I'm pretty sure you can
simply point CONFIG_INITRAMFS_SOURCE at a directory to make it use that.

The help text and documentation seems to agree with me:

config INITRAMFS_SOURCE
        string "Initramfs source file(s)"
        default ""
        help
          This can be either a single cpio archive with a .cpio suffix or a
          space-separated list of directories and files for building the
          initramfs image.  A cpio archive should contain a filesystem archive
          to be used as an initramfs image.  Directories should contain a
          filesystem layout to be included in the initramfs image.  Files
          should contain entries according to the format described by the
          "usr/gen_init_cpio" program in the kernel tree.

          When multiple directories and files are specified then the
          initramfs image will be the aggregate of all of them.

 Grant> It works fine the way it is.  What's the reason for disabling the
 Grant> buildign of a cpio file source list?

Is there any advantage to using a source file for gen_init_cpio instead
of just building a cpio archive?

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Hi,

 Thomas> Well, a cpio archive can be generated by Buildroot without having to
 Thomas> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
 Thomas> originally was the fs/initramfs case. However, last time I tried
 Thomas> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.

 Peter> So what is the difference between initramfs and cpio? Just the
 Peter> integration with the kernel build for the first? Maybe the initramfs
 Peter> stuff should simply be a 'embed in kernel' question on the cpio package
 Peter> if the internal kernel build is enabled?

Ok, looked a bit closer and noticed that the initramfs target doesn't
actually create a cpio, but a command file for gen_init_cpio.

Nevertheless, is there any advantage to use that instead of just
creating a cpio archive (besides it not working for you somehow)?

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-27, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> On Sun, 27 Jun 2010 13:42:34 +0000 (UTC)
> Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> > No, but you could extract the tarball (as root or using fakeroot) and
>> > point CONFIG_INITRAMFS_SOURCE to it.
>> 
>> An extracted tarball isn't one of the options either.
>> CONFIG_INITRAMFS_SOURCE can be pointed at either a cpio archive or the
>> source file list.
>
> Or a directory containing the hierarchy of files/directories to include
> in the initramfs.

You're right.  I'd mis-read the help for the initramfs option.

Doesn't that means you have to do one step of the build as root?

I don't think I that's a viable option.

>> > But yes, providing a way to generate the cpio archive without building a
>> > kernel would be nicer.
>> 
>> It works fine the way it is.  What's the reason for disabling the
>> buildign of a cpio file source list?
>
> It was to fix bug #2119.

I currently build with the initramfs option without having to build a
kernel. Isn't there some way to fix bug 2119 without breaking a use
case for existing users?

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-27, Peter Korsgaard <jacmet@sunsite.dk> wrote:
>>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:
>
> Hi,
>
>  Thomas> Well, a cpio archive can be generated by Buildroot without having to
>  Thomas> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
>  Thomas> originally was the fs/initramfs case. However, last time I tried
>  Thomas> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.
>
> Peter> So what is the difference between initramfs and cpio? Just the
> Peter> integration with the kernel build for the first? Maybe the initramfs
> Peter> stuff should simply be a 'embed in kernel' question on the cpio package
> Peter> if the internal kernel build is enabled?
>
> Ok, looked a bit closer and noticed that the initramfs target doesn't
> actually create a cpio, but a command file for gen_init_cpio.

Right.  But why does that require building a kernel?  It's just a list
of files/nodes that goes into the cpio archive.  If you're allowed to
build a cpio archive or a tar archive, surely you should be allowed to
build the list of files that goes into the archive?

> Nevertheless, is there any advantage to use that instead of just
> creating a cpio archive (besides it not working for you somehow)?

If the cpio archive works, then I'm happy.  For no particular reason
I've always used the file-list method in the past.  I tried building
the kernel with the cpio archive instead, and the build worked fine.
But, my target HW seems go have gone walkabout for a few days, so I
haven't been able to test the impage built with the cpio archive
instead of the source file list.

You can point the kernel at an unpacked directory tree, but that's
undesirable since the unpacking has to be done as root (right?).  At
least that's what I remember.

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-27, Peter Korsgaard <jacmet@uclibc.org> wrote:

> Is there any advantage to using a source file for gen_init_cpio instead
> of just building a cpio archive?

No, I don't think so.  But if you're not allowed to build the list of
files/nodes to go into a cpio archive, surely building the cpio
archive is out of the question?

-- 
Grant

[Buildroot] [git commit master 1/1] initramfs: update help text

[Peter Korsgaard]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

Hi,

 >> Or a directory containing the hierarchy of files/directories to include
 >> in the initramfs.

 Grant> You're right.  I'd mis-read the help for the initramfs option.
 Grant> Doesn't that means you have to do one step of the build as root?
 Grant> I don't think I that's a viable option.

Either that, use fakeroot or use the cpio target.

 >>> > But yes, providing a way to generate the cpio archive without building a
 >>> > kernel would be nicer.
 >>> 
 >>> It works fine the way it is.  What's the reason for disabling the
 >>> buildign of a cpio file source list?
 >> 
 >> It was to fix bug #2119.

 Grant> I currently build with the initramfs option without having to build a
 Grant> kernel. Isn't there some way to fix bug 2119 without breaking a use
 Grant> case for existing users?

Yes, we could make the:

ROOTFS_INITRAMFS_POST_TARGETS += linux26-rebuild-with-initramfs

conditional on the kernel being built or not, but why are we having both
a cpio and initramfs target in the first place?

-- 
Bye, Peter Korsgaard

[Buildroot] [git commit master 1/1] initramfs: update help text

[Grant Edwards]

On 2010-06-28, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> On 2010-06-27, Peter Korsgaard <jacmet@sunsite.dk> wrote:

>>  Thomas> Well, a cpio archive can be generated by Buildroot without having to
>>  Thomas> build a kernel, see fs/cpio/Config.in. What Grant was complaining about
>>  Thomas> originally was the fs/initramfs case. However, last time I tried
>>  Thomas> pointing CONFIG_INITRAMFS_SOURCE to a cpio archive, it didn't work.
>>
>> Peter> So what is the difference between initramfs and cpio? Just the
>> Peter> integration with the kernel build for the first? Maybe the initramfs
>> Peter> stuff should simply be a 'embed in kernel' question on the cpio package
>> Peter> if the internal kernel build is enabled?
>>
>> Ok, looked a bit closer and noticed that the initramfs target doesn't
>> actually create a cpio, but a command file for gen_init_cpio.
>
> Right.  But why does that require building a kernel?  It's just a list
> of files/nodes that goes into the cpio archive.  If you're allowed to
> build a cpio archive or a tar archive, surely you should be allowed to
> build the list of files that goes into the archive?
>
>> Nevertheless, is there any advantage to use that instead of just
>> creating a cpio archive (besides it not working for you somehow)?
>
> If the cpio archive works, then I'm happy.  For no particular reason
> I've always used the file-list method in the past.  I tried building
> the kernel with the cpio archive instead, and the build worked fine.
> But, my target HW seems to have gone walkabout for a few days, so I
> haven't been able to test the impage built with the cpio archive
> instead of the source file list.

I've got target HW again, and building the kernel using a cpio archive
instead of the cpio-file-list seems to work fine, so that's what I'll
plan on doing.

I still don't understand why one can build a cpio archive without
building a kernel, but in order to create a list of what's in the cpio
archive a kernel must be built.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm sitting on my
                                  at               SPEED QUEEN ... To me,
                              gmail.com            it's ENJOYABLE ... I'm WARM
                                                   ... I'm VIBRATORY ...

[Buildroot] [git commit master 1/1] initramfs: update help text

[Thomas Petazzoni]

On Mon, 28 Jun 2010 15:13:04 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> I still don't understand why one can build a cpio archive without
> building a kernel, but in order to create a list of what's in the cpio
> archive a kernel must be built.

I think I've already said that it was just one choice to solve bug
#2119, but that there was also other ways to solve the same bug (for
example by enabling the dependency from initramfs to the kernel only
when the kernel build is enabled).

So there's nothing to understand: it was one way to fix the bug,
and it later turned out that this way was too restrictive and that the
bug must therefore be fixed another way. Which will be done.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com