initramfs: drop comment against multiple formats

This patch removes an old comment against having multiple filesystem
formats which doesn't bring any value.

It is also wrong per-se: one may want to use Buildroot to prepare a
custom distribution containing a kernel+initramfs and a persistent
default rootfs to pivot to.

Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
---
 fs/initramfs/Config.in | 5 -----
 1 file changed, 5 deletions(-)

>>>>> "Vivien" == Vivien Didelot <vivien.didelot@gmail.com> writes:

 > This patch removes an old comment against having multiple filesystem
 > formats which doesn't bring any value.

 > It is also wrong per-se: one may want to use Buildroot to prepare a
 > custom distribution containing a kernel+initramfs and a persistent
 > default rootfs to pivot to.

Yes, but in that case the final persistent rootfs would contain
different files than the initramfs, right?

E.G. I handle such a use case by two different defconfigs, one building
the Linux kernel + initramfs and another for the final persistent
rootfs.

> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>

> ---
 >  fs/initramfs/Config.in | 5 -----
 >  1 file changed, 5 deletions(-)

 > diff --git a/fs/initramfs/Config.in b/fs/initramfs/Config.in
 > index 9d5a3f92e6..42a9d60524 100644
 > --- a/fs/initramfs/Config.in
 > +++ b/fs/initramfs/Config.in
 > @@ -13,10 +13,5 @@ config BR2_TARGET_ROOTFS_INITRAMFS
 >  	  is used, regardless of how buildroot's cpio archive is
 >  	  configured.
 
 > -	  Note that enabling initramfs together with another filesystem
 > -	  formats doesn't make sense: you would end up having two
 > -	  identical root filesystems, one embedded inside the kernel
 > -	  image, and one separately.
 > -
 >  comment "initramfs needs a Linux kernel to be built"
 >  	depends on !BR2_LINUX_KERNEL
 > -- 
 > 2.20.1

 > _______________________________________________
 > buildroot mailing list
 > buildroot@busybox.net
 > http://lists.busybox.net/mailman/listinfo/buildroot

Hi Peter,

On Sat, 26 Jan 2019 10:56:59 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:
> >>>>> "Vivien" == Vivien Didelot <vivien.didelot@gmail.com> writes:
> 
>  > This patch removes an old comment against having multiple filesystem
>  > formats which doesn't bring any value.
> 
>  > It is also wrong per-se: one may want to use Buildroot to prepare a
>  > custom distribution containing a kernel+initramfs and a persistent
>  > default rootfs to pivot to.
> 
> Yes, but in that case the final persistent rootfs would contain
> different files than the initramfs, right?

Not necessarily. You can prepare one rootfs base containing an init logic
which detects the initrd and eventually formats a partition, extracts a
persistent version, pivots root etc.

The persistent storage can evolve from there by the mean of a package manager
or whatever the board is meant to do with the persistent storage.

> E.G. I handle such a use case by two different defconfigs, one building
> the Linux kernel + initramfs and another for the final persistent
> rootfs.

My point is that it is actually possible to do so, and Buildroot allows that,
so this message has currently no value. So I suggest either we prevent one
to have a built-in initramfs enabled as well as other rootfs formats (which
seems to be a subjective limitation to me) or we get rid of this message
and let the user generate all formats she wants.


Best,

	Vivien

Hello Vivien,

On Fri, 25 Jan 2019 19:19:01 -0500
Vivien Didelot <vivien.didelot@gmail.com> wrote:

> This patch removes an old comment against having multiple filesystem
> formats which doesn't bring any value.
> 
> It is also wrong per-se: one may want to use Buildroot to prepare a
> custom distribution containing a kernel+initramfs and a persistent
> default rootfs to pivot to.
> 
> Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>

I understand your point, but I think we need to keep a comment. Indeed,
the use-cases for generating both an initramfs and another rootfs image
are very specific, and users (especially newcomers!) should still
understand that when building an initramfs with Buildroot, it's the
entire root filesystem that goes in the initramfs.

Perhaps we should reword it like this:

	Note that enabling this initramfs option together with another
	filesystem format may not make sense: you would end up having
	two identical root filesystems, one embedded inside the kernel
	image (initramfs) and one separately. Indeed, Buildroot is
	unable to generate an initramfs with different contents than
	the root filesystem. However, we still allow generating both an
	initramfs and a normal rootfs image in the same configuration
	as they are some specific use-cases for it.

Would that work for you ?

Best regards,

Thomas Petazzoni

Hi Thomas,

On Sun, 23 Jun 2019 18:09:32 +0200, Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello Vivien,
> 
> On Fri, 25 Jan 2019 19:19:01 -0500
> Vivien Didelot <vivien.didelot@gmail.com> wrote:
> 
> > This patch removes an old comment against having multiple filesystem
> > formats which doesn't bring any value.
> > 
> > It is also wrong per-se: one may want to use Buildroot to prepare a
> > custom distribution containing a kernel+initramfs and a persistent
> > default rootfs to pivot to.
> > 
> > Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
> 
> I understand your point, but I think we need to keep a comment. Indeed,
> the use-cases for generating both an initramfs and another rootfs image
> are very specific, and users (especially newcomers!) should still
> understand that when building an initramfs with Buildroot, it's the
> entire root filesystem that goes in the initramfs.
> 
> Perhaps we should reword it like this:
> 
> 	Note that enabling this initramfs option together with another
> 	filesystem format may not make sense: you would end up having
> 	two identical root filesystems, one embedded inside the kernel
> 	image (initramfs) and one separately. Indeed, Buildroot is
> 	unable to generate an initramfs with different contents than
> 	the root filesystem. However, we still allow generating both an
> 	initramfs and a normal rootfs image in the same configuration
> 	as they are some specific use-cases for it.
> 
> Would that work for you ?

Yes, that would work.


Thanks,
Vivien