[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Norbert Lange]

For read-only root file systems, the kernel-modules
will be mounted over this directory.
This directory should always exist for this reason,
just as /mnt and /opt are in the skeleton.

Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
---
 package/skeleton-init-common/skeleton-init-common.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/skeleton-init-common/skeleton-init-common.mk b/package/skeleton-init-common/skeleton-init-common.mk
index e429b13d78..b39794eddc 100644
--- a/package/skeleton-init-common/skeleton-init-common.mk
+++ b/package/skeleton-init-common/skeleton-init-common.mk
@@ -20,6 +20,7 @@ define SKELETON_INIT_COMMON_INSTALL_TARGET_CMDS
 	$(call SYSTEM_RSYNC,$(SKELETON_INIT_COMMON_PATH),$(TARGET_DIR))
 	$(call SYSTEM_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR))
 	$(call SYSTEM_LIB_SYMLINK,$(TARGET_DIR))
+	$(INSTALL) -d -m 0755 $(TARGET_DIR)/lib/modules
 	$(SED) 's, at PATH@,$(BR2_SYSTEM_DEFAULT_PATH),' $(TARGET_DIR)/etc/profile
 	$(INSTALL) -m 0644 support/misc/target-dir-warning.txt \
 		$(TARGET_DIR_WARNING_FILE)
-- 
2.20.1

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Yann E. MORIN]

On 2019-03-18 17:30 +0100, Norbert Lange spake thusly:
> For read-only root file systems, the kernel-modules
> will be mounted over this directory.

This does not mean anything.

Either you build your kernel with Buildroot, and the kernel does the
installation of modules in /lib/modules, and thus you do not need to
create it, or you build your kernel outside of Buildroot and you install
the modules at build time in there.

So, having a read-only filesystem is of no consequence here.

Also, I don;t see how "the kernel-modules will be mounted over this
directory", which imply this is done at runtime. If your system uses
special means to store the kernel modules, then it's your duty to
provide it on your own, like as an overlay (or a specific package) that
install those files/direcoties.

> This directory should always exist for this reason,

This is wrong: one can have a no-module kernel, in which case
/lib/modules is useless.

> just as /mnt and /opt are in the skeleton.

Those are madanted by the FHS [0].

[0] https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard.

Regards,
Yann E. MORIN.

> Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
> ---
>  package/skeleton-init-common/skeleton-init-common.mk | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/skeleton-init-common/skeleton-init-common.mk b/package/skeleton-init-common/skeleton-init-common.mk
> index e429b13d78..b39794eddc 100644
> --- a/package/skeleton-init-common/skeleton-init-common.mk
> +++ b/package/skeleton-init-common/skeleton-init-common.mk
> @@ -20,6 +20,7 @@ define SKELETON_INIT_COMMON_INSTALL_TARGET_CMDS
>  	$(call SYSTEM_RSYNC,$(SKELETON_INIT_COMMON_PATH),$(TARGET_DIR))
>  	$(call SYSTEM_USR_SYMLINKS_OR_DIRS,$(TARGET_DIR))
>  	$(call SYSTEM_LIB_SYMLINK,$(TARGET_DIR))
> +	$(INSTALL) -d -m 0755 $(TARGET_DIR)/lib/modules
>  	$(SED) 's, at PATH@,$(BR2_SYSTEM_DEFAULT_PATH),' $(TARGET_DIR)/etc/profile
>  	$(INSTALL) -m 0644 support/misc/target-dir-warning.txt \
>  		$(TARGET_DIR_WARNING_FILE)
> -- 
> 2.20.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Norbert Lange]

Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> On 2019-03-18 17:30 +0100, Norbert Lange spake thusly:
> > For read-only root file systems, the kernel-modules
> > will be mounted over this directory.
>
> This does not mean anything.
>
> Either you build your kernel with Buildroot, and the kernel does the
> installation of modules in /lib/modules, and thus you do not need to
> create it, or you build your kernel outside of Buildroot and you install
> the modules at build time in there.
>
> So, having a read-only filesystem is of no consequence here.
>
> Also, I don;t see how "the kernel-modules will be mounted over this
> directory", which imply this is done at runtime. If your system uses
> special means to store the kernel modules, then it's your duty to
> provide it on your own, like as an overlay (or a specific package) that
> install those files/direcoties.

If you prepare a kernel with an builtin initramfs containing
the modules and an initscript to mount those over /lib/modules,
then you wont have to touch the root fs.
(can be replaced independently of each other).

>
> > This directory should always exist for this reason,
>
> This is wrong: one can have a no-module kernel, in which case
> /lib/modules is useless.

One could also have nothing to use with  /mnt, /media and /opt.

> > just as /mnt and /opt are in the skeleton.
>
> Those are madanted by the FHS [0].

Ok, if I red that right, then /boot and /srv would be required/mandated aswell?

I guess I wont get the change up-streamed, and thats fine (minor annoyance
that I cant use verbatim buildroot's with such kernels). But this seems
to be pretty arbitrary given that buildroot seems rather lenient
otherwise (for good reasons).

Norbert.

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Yann E. MORIN]

Norbert, All,

On 2019-03-18 19:11 +0100, Norbert Lange spake thusly:
> Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
> > On 2019-03-18 17:30 +0100, Norbert Lange spake thusly:
> > > For read-only root file systems, the kernel-modules
> > > will be mounted over this directory.
> >
> > This does not mean anything.
> >
> > Either you build your kernel with Buildroot, and the kernel does the
> > installation of modules in /lib/modules, and thus you do not need to
> > create it, or you build your kernel outside of Buildroot and you install
> > the modules at build time in there.
> >
> > So, having a read-only filesystem is of no consequence here.
> >
> > Also, I don;t see how "the kernel-modules will be mounted over this
> > directory", which imply this is done at runtime. If your system uses
> > special means to store the kernel modules, then it's your duty to
> > provide it on your own, like as an overlay (or a specific package) that
> > install those files/direcoties.
> 
> If you prepare a kernel with an builtin initramfs containing
> the modules and an initscript to mount those over /lib/modules,
> then you wont have to touch the root fs.
> (can be replaced independently of each other).

*That* is the real reason, and that's what you should have explained in
your commit log.

(Incidentally, I knew where this was coming from; I just wanted it to be
explained by you, not I.)

> > > This directory should always exist for this reason,
> > This is wrong: one can have a no-module kernel, in which case
> > /lib/modules is useless.
> One could also have nothing to use with  /mnt, /media and /opt.
> 
> > > just as /mnt and /opt are in the skeleton.
> > Those are madanted by the FHS [0].
> Ok, if I red that right, then /boot and /srv would be required/mandated aswell?

"red"? But who am I for pointing at others typoes? Hehe! ;-)

And sorry, I wrote "mandated" (with typoes, at that), when I should have
written "documented". So, I was just pointing out that /mnt and /opt do
have some standard backing them, while /lib/modules does not, and thus
/lib/modules does not have to "always exist like /mnt/ or /opt" as you
wrote.

Additionally, if one is building a filesystem (possibly readonly) to run
in a container, they'd probably have no use for /lib/modules either. So,
again, /lib/modules does not *have* to always exist.

> I guess I wont get the change up-streamed, and thats fine (minor annoyance
> that I cant use verbatim buildroot's with such kernels).

As I said, you need not do that in skeleton. You can do it in an
overlay, or as a custom package, or even as a custom skeleton. And if
you do not want to "pollute" your Buildroot tree with your custom stuff,
you can host it in a br2-external tree, for example. My professional
alter-ego gave a talk about that some time ago:
    https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf

And Arnout wrote a nice summary of the presentation:
    https://mindlinux.wordpress.com/2017/10/24/buildroot-making-embedded-linux-easy-a-real-life-example-yann-morin-orange/

> But this seems
> to be pretty arbitrary given that buildroot seems rather lenient
> otherwise (for good reasons).

Given the proper explanations for a change, we'd consider it, yes. But I
just pointed out that your explanations were not correct/accurate, as
the conditions you *described* did not *require* that change. The
explanations above is the real reason, and that is what you have said in
your commit log instead, and that would have given it a better chance to
get applied.

And yes, drawing the boundary line is arbitrary at times.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Norbert Lange]

Am Mo., 18. M?rz 2019 um 20:03 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Norbert, All,
>
> On 2019-03-18 19:11 +0100, Norbert Lange spake thusly:
> > Am Mo., 18. M?rz 2019 um 18:44 Uhr schrieb Yann E. MORIN
> > <yann.morin.1998@free.fr>:
> > > On 2019-03-18 17:30 +0100, Norbert Lange spake thusly:
> > > > For read-only root file systems, the kernel-modules
> > > > will be mounted over this directory.
> > >
> > > This does not mean anything.
> > >
> > > Either you build your kernel with Buildroot, and the kernel does the
> > > installation of modules in /lib/modules, and thus you do not need to
> > > create it, or you build your kernel outside of Buildroot and you install
> > > the modules at build time in there.
> > >
> > > So, having a read-only filesystem is of no consequence here.
> > >
> > > Also, I don;t see how "the kernel-modules will be mounted over this
> > > directory", which imply this is done at runtime. If your system uses
> > > special means to store the kernel modules, then it's your duty to
> > > provide it on your own, like as an overlay (or a specific package) that
> > > install those files/direcoties.
> >
> > If you prepare a kernel with an builtin initramfs containing
> > the modules and an initscript to mount those over /lib/modules,
> > then you wont have to touch the root fs.
> > (can be replaced independently of each other).
>
> *That* is the real reason, and that's what you should have explained in
> your commit log.
>
> (Incidentally, I knew where this was coming from; I just wanted it to be
> explained by you, not I.)

I did not want to be too specific, but the basic idea is to separate
the lowlevel
stuff (kernel, -modules and initramfs) from a read-only OS-image.
My usecase is the above, primary because I have to stick the lowlevel stuff
into onboard storage, then load the rootfs.

Doing some small maintainance scripts in intramfs is preferable than
having to mess
with the rootfs all time.

Next thing would be "UsrMerge" and OS-as-usr-subdirectory. the kernel modules
in /lib/modules (/usr/lib/modules) is in the way there too.

> > > > This directory should always exist for this reason,
> > > This is wrong: one can have a no-module kernel, in which case
> > > /lib/modules is useless.
> > One could also have nothing to use with  /mnt, /media and /opt.
> >
> > > > just as /mnt and /opt are in the skeleton.
> > > Those are madanted by the FHS [0].
> > Ok, if I red that right, then /boot and /srv would be required/mandated aswell?
>
> "red"? But who am I for pointing at others typoes? Hehe! ;-)

yeah, by making me explain things thoroughly, your evil scheme for
more tiptoes worked ;)

>
> And sorry, I wrote "mandated" (with typoes, at that), when I should have
> written "documented". So, I was just pointing out that /mnt and /opt do
> have some standard backing them, while /lib/modules does not, and thus
> /lib/modules does not have to "always exist like /mnt/ or /opt" as you
> wrote.

err.. look at FHS Section 3.9.3.

> Additionally, if one is building a filesystem (possibly readonly) to run
> in a container, they'd probably have no use for /lib/modules either. So,
> again, /lib/modules does not *have* to always exist.

nope, there's just the question of how-much-it-helps vs how-much-it-hurts.
building everything static would make /lib empty and unused as well,
the cost of having it around always is reasonably low.

> > I guess I wont get the change up-streamed, and thats fine (minor annoyance
> > that I cant use verbatim buildroot's with such kernels).
>
> As I said, you need not do that in skeleton. You can do it in an
> overlay, or as a custom package, or even as a custom skeleton. And if
> you do not want to "pollute" your Buildroot tree with your custom stuff,
> you can host it in a br2-external tree, for example. My professional
> alter-ego gave a talk about that some time ago:
>     https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf
>
> And Arnout wrote a nice summary of the presentation:
>     https://mindlinux.wordpress.com/2017/10/24/buildroot-making-embedded-linux-easy-a-real-life-example-yann-morin-orange/

sure, getting it upstream is still the best bet.

> > But this seems
> > to be pretty arbitrary given that buildroot seems rather lenient
> > otherwise (for good reasons).
>
> Given the proper explanations for a change, we'd consider it, yes. But I
> just pointed out that your explanations were not correct/accurate, as
> the conditions you *described* did not *require* that change. The
> explanations above is the real reason, and that is what you have said in
> your commit log instead, and that would have given it a better chance to
> get applied.
>
> And yes, drawing the boundary line is arbitrary at times.

No problem with that.
Should I re-roll the patch next, or can we continue this discussion
until you decide on whether you will include the change.

Norbert

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Arnout Vandecappelle]

On 18/03/2019 21:43, Norbert Lange wrote:
> Should I re-roll the patch next, or can we continue this discussion
> until you decide on whether you will include the change.

 For me as well, the direction should be to remove things from the skeleton
rather than adding to it. So if you would get rid of /media etc. I'd maybe be in
favour of it, but I'm certainly not going to defend adding yet another directory.

 I'll add Peter in Cc to draw a line in the sand.

 Regards,
 Arnout

[Buildroot] [PATCH 1/1] package/skeleton-init-common: Create /lib/modules directory

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 > On 18/03/2019 21:43, Norbert Lange wrote:
 >> Should I re-roll the patch next, or can we continue this discussion
 >> until you decide on whether you will include the change.

 >  For me as well, the direction should be to remove things from the skeleton
 > rather than adding to it. So if you would get rid of /media etc. I'd maybe be in
 > favour of it, but I'm certainly not going to defend adding yet another directory.

 >  I'll add Peter in Cc to draw a line in the sand.

I'm with Arnout here. Buildroot has always been about minimalism, so
having extra things just-in-case isn't really nice.

If you really want to, you can create extra directories in the target
without any buildroot customizations, just call mkdir as a post-build
script:

BR2_ROOTFS_POST_BUILD_SCRIPT="mkdir"
BR2_ROOTFS_POST_SCRIPT_ARGS="-p $(TARGET_DIR)/path/to/somewhere"

-- 
Bye, Peter Korsgaard