[Buildroot] [PATCH 1/3] package/cross-ldd: new package

[Buildroot] [PATCH 1/3] package/cross-ldd: new package

[Thierry Bultel]

cross-ldd works just as ldd, but supports
other architectures. It is needed by dracut, for instance.

Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
---
 package/Config.in.host           |  1 +
 package/cross-ldd/Config.in.host |  5 +++++
 package/cross-ldd/cross-ldd.mk   | 20 ++++++++++++++++++++
 3 files changed, 26 insertions(+)
 create mode 100644 package/cross-ldd/Config.in.host
 create mode 100644 package/cross-ldd/cross-ldd.mk

diff --git a/package/Config.in.host b/package/Config.in.host
index 6e5a5c5fc5..0e8b071a2b 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -12,6 +12,7 @@ menu "Host utilities"
 	source "package/checksec/Config.in.host"
 	source "package/cmake/Config.in.host"
 	source "package/cramfs/Config.in.host"
+	source "package/cross-ldd/Config.in.host"
 	source "package/cryptsetup/Config.in.host"
 	source "package/dbus-python/Config.in.host"
 	source "package/dfu-util/Config.in.host"
diff --git a/package/cross-ldd/Config.in.host b/package/cross-ldd/Config.in.host
new file mode 100644
index 0000000000..237af701d2
--- /dev/null
+++ b/package/cross-ldd/Config.in.host
@@ -0,0 +1,5 @@
+config BR2_PACKAGE_HOST_CROSS_LDD
+	bool "cross ldd"
+	help
+	ldd drop-in replacement for cross-compilation toolchains.
+	This is the officially supported version mentioned in the dracut documentation
diff --git a/package/cross-ldd/cross-ldd.mk b/package/cross-ldd/cross-ldd.mk
new file mode 100644
index 0000000000..9326a508bb
--- /dev/null
+++ b/package/cross-ldd/cross-ldd.mk
@@ -0,0 +1,20 @@
+################################################################################
+#
+# cross-ldd
+#
+################################################################################
+
+CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
+CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION).zip
+CROSS_LDD_SITE = https://gist.github.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f/archive
+
+define HOST_CROSS_LDD_EXTRACT_CMDS
+	unzip $(HOST_CROSS_LDD_DL_DIR)/$(CROSS_LDD_SOURCE) -d $(@D)
+	find $(@D) -name cross-compile-ldd -exec mv {} $(@D) \;
+endef
+
+define HOST_CROSS_LDD_INSTALL_CMDS
+	install -m 755 $(@D)/cross-compile-ldd $(TARGET_CROSS)ldd
+endef
+
+$(eval $(host-generic-package))
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/3] package/dracut: new host package

[Thierry Bultel]

dracut is the tool used by desktop distributions to
build initrds. In the embedded world, it can be
very usefull, too, for instance when wanting to
create an initramfs for a system recovery mode.
Whereas it is definitively possible to achieve
this with buildroot, the process is to have a
dedicated buildroot configuration for that,
and perform a full build. Instead of doing that,
the idea is to use dracut to pick the needed
binaries/shared libraries, configuration files,
or kernel modules from the 'target' directory.
The advantage is to save build time, and also
to have a consistency between the packages versions
taken for the recovery and the production filesystem.

Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
---
 package/Config.in.host        |  1 +
 package/dracut/Config.in.host |  8 ++++++++
 package/dracut/dracut.mk      | 22 ++++++++++++++++++++++
 3 files changed, 31 insertions(+)
 create mode 100644 package/dracut/Config.in.host
 create mode 100644 package/dracut/dracut.mk

diff --git a/package/Config.in.host b/package/Config.in.host
index 0e8b071a2b..42f671a78f 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -15,6 +15,7 @@ menu "Host utilities"
 	source "package/cross-ldd/Config.in.host"
 	source "package/cryptsetup/Config.in.host"
 	source "package/dbus-python/Config.in.host"
+	source "package/dracut/Config.in.host"
 	source "package/dfu-util/Config.in.host"
 	source "package/dos2unix/Config.in.host"
 	source "package/dosfstools/Config.in.host"
diff --git a/package/dracut/Config.in.host b/package/dracut/Config.in.host
new file mode 100644
index 0000000000..8ed41d3719
--- /dev/null
+++ b/package/dracut/Config.in.host
@@ -0,0 +1,8 @@
+config BR2_PACKAGE_HOST_DRACUT
+	bool "host dracut"
+	select BR2_PACKAGE_HOST_KMOD
+	select BR2_PACKAGE_HOST_CROSS_LDD
+	help
+	dracut is used to create an initramfs image by copying tools and files from an installed system and combining it with the dracut framework.
+
+	https://dracut.wiki.kernel.org
diff --git a/package/dracut/dracut.mk b/package/dracut/dracut.mk
new file mode 100644
index 0000000000..8de89603a5
--- /dev/null
+++ b/package/dracut/dracut.mk
@@ -0,0 +1,22 @@
+################################################################################
+#
+# dracut
+#
+################################################################################
+
+DRACUT_VERSION = 055
+DRACUT_SOURCE = dracut-$(DRACUT_VERSION).tar.xz
+DRACUT_SITE = https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut
+DRACUT_LICENSE = GPL-2.0
+DRACUT_LICENSE_FILES = COPYING
+
+HOST_DRACUT_DEPENDENCIES += host-pkgconf host-kmod host-cross-ldd
+
+define HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
+	$(SED) '/unset LD_LIBRARY_PATH/d' $(HOST_DIR)/bin/dracut
+	$(SED) '/unset LD_PRELOAD/d' $(HOST_DIR)/bin/dracut
+endef
+
+HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
+
+$(eval $(host-autotools-package))
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/3] package/dracut: new host package

[Arnout Vandecappelle]

On 15/12/2021 19:00, Thierry Bultel wrote:
> dracut is the tool used by desktop distributions to
> build initrds. In the embedded world, it can be
> very usefull, too, for instance when wanting to
> create an initramfs for a system recovery mode.
> Whereas it is definitively possible to achieve
> this with buildroot, the process is to have a
> dedicated buildroot configuration for that,
> and perform a full build. Instead of doing that,
> the idea is to use dracut to pick the needed
> binaries/shared libraries, configuration files,
> or kernel modules from the 'target' directory.
> The advantage is to save build time, and also
> to have a consistency between the packages versions
> taken for the recovery and the production filesystem.
> 
> Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
> ---
>   package/Config.in.host        |  1 +
>   package/dracut/Config.in.host |  8 ++++++++
>   package/dracut/dracut.mk      | 22 ++++++++++++++++++++++
>   3 files changed, 31 insertions(+)
>   create mode 100644 package/dracut/Config.in.host
>   create mode 100644 package/dracut/dracut.mk
> 
> diff --git a/package/Config.in.host b/package/Config.in.host
> index 0e8b071a2b..42f671a78f 100644
> --- a/package/Config.in.host
> +++ b/package/Config.in.host
> @@ -15,6 +15,7 @@ menu "Host utilities"
>   	source "package/cross-ldd/Config.in.host"
>   	source "package/cryptsetup/Config.in.host"
>   	source "package/dbus-python/Config.in.host"
> +	source "package/dracut/Config.in.host"
>   	source "package/dfu-util/Config.in.host"
>   	source "package/dos2unix/Config.in.host"
>   	source "package/dosfstools/Config.in.host"
> diff --git a/package/dracut/Config.in.host b/package/dracut/Config.in.host
> new file mode 100644
> index 0000000000..8ed41d3719
> --- /dev/null
> +++ b/package/dracut/Config.in.host
> @@ -0,0 +1,8 @@
> +config BR2_PACKAGE_HOST_DRACUT
> +	bool "host dracut"

  Contrary to cross-ldd, I *do* think that it's useful to have a Config.in.host 
for host-dracut, because that is indeed a tool you'd use in post-image scripts.
Even if there's a dracut fs, there are probably still use cases not covered by 
it so it's useful standalone as well.

> +	select BR2_PACKAGE_HOST_KMOD
> +	select BR2_PACKAGE_HOST_CROSS_LDD
> +	help
> +	dracut is used to create an initramfs image by copying tools and files from an installed system and combining it with the dracut framework.

  Wrapping is not correct here. Please use utils/check-package before submitting.

> +
> +	https://dracut.wiki.kernel.org
> diff --git a/package/dracut/dracut.mk b/package/dracut/dracut.mk
> new file mode 100644
> index 0000000000..8de89603a5
> --- /dev/null
> +++ b/package/dracut/dracut.mk
> @@ -0,0 +1,22 @@
> +################################################################################
> +#
> +# dracut
> +#
> +################################################################################
> +
> +DRACUT_VERSION = 055
> +DRACUT_SOURCE = dracut-$(DRACUT_VERSION).tar.xz
> +DRACUT_SITE = https://mirrors.edge.kernel.org/pub/linux/utils/boot/dracut

  Use BR2_KERNEL_MIRROR instead (at least, I think that should work, right?)

  Regards,
  Arnout

> +DRACUT_LICENSE = GPL-2.0
> +DRACUT_LICENSE_FILES = COPYING
> +
> +HOST_DRACUT_DEPENDENCIES += host-pkgconf host-kmod host-cross-ldd
> +
> +define HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
> +	$(SED) '/unset LD_LIBRARY_PATH/d' $(HOST_DIR)/bin/dracut
> +	$(SED) '/unset LD_PRELOAD/d' $(HOST_DIR)/bin/dracut
> +endef
> +
> +HOST_DRACUT_POST_INSTALL_HOOKS+=HOST_DRACUT_POST_INSTALL_ENABLE_FAKEROOT
> +
> +$(eval $(host-autotools-package))
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

Adds an option to build an initramfs image,
using the dracut host tool.

Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
---
 fs/Config.in        |  1 +
 fs/dracut/Config.in | 13 +++++++++++
 fs/dracut/dracut.mk | 55 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 69 insertions(+)
 create mode 100644 fs/dracut/Config.in
 create mode 100644 fs/dracut/dracut.mk

diff --git a/fs/Config.in b/fs/Config.in
index eee5e26bb2..3938f3b9a7 100644
--- a/fs/Config.in
+++ b/fs/Config.in
@@ -5,6 +5,7 @@ source "fs/btrfs/Config.in"
 source "fs/cloop/Config.in"
 source "fs/cpio/Config.in"
 source "fs/cramfs/Config.in"
+source "fs/dracut/Config.in"
 source "fs/erofs/Config.in"
 source "fs/ext2/Config.in"
 source "fs/f2fs/Config.in"
diff --git a/fs/dracut/Config.in b/fs/dracut/Config.in
new file mode 100644
index 0000000000..ee4220def8
--- /dev/null
+++ b/fs/dracut/Config.in
@@ -0,0 +1,13 @@
+config BR2_TARGET_ROOTFS_DRACUT
+	bool "Invoke dracut to make an initramfs"
+	default n
+	select BR2_PACKAGE_HOST_DRACUT
+	select BR2_PACKAGE_HOST_UBOOT_TOOLS
+	help
+	  Builds an additional initramfs using dracut. This can be useful to create a recovery system, for instance.
+	
+if BR2_TARGET_ROOTFS_DRACUT
+config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
+	string "configuration file"
+endif
+
diff --git a/fs/dracut/dracut.mk b/fs/dracut/dracut.mk
new file mode 100644
index 0000000000..9c91150e82
--- /dev/null
+++ b/fs/dracut/dracut.mk
@@ -0,0 +1,55 @@
+################################################################################
+#
+# dracut to archive target filesystem
+#
+################################################################################
+
+ROOTFS_DRACUT_DEPENDENCIES = host-dracut host-uboot-tools
+
+ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
+
+define ROOTFS_DRACUT_ADD_INIT
+	if [ ! -e $(TARGET_DIR)/init ]; then \
+		ln -sf sbin/init $(TARGET_DIR)/init; \
+	fi
+endef
+
+else
+
+# devtmpfs does not get automounted when initramfs is used.
+# Add a pre-init script to mount it before running init
+# We must have /dev/console very early, even before /init runs,
+# for stdin/stdout/stderr
+define ROOTFS_DRACUT_ADD_INIT
+	if [ ! -e $(TARGET_DIR)/init ]; then \
+		$(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
+	fi
+	mkdir -p $(TARGET_DIR)/dev
+	mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
+endef
+
+endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
+
+ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
+
+define ROOTFS_DRACUT_CMD
+
+	mkdir -p $(@D)/tmp
+	rm -rf $(@D)/tmp/*
+
+	DRACUT_LDD=$(TARGET_CROSS)ldd \
+	DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
+	dracutbasedir=$(HOST_DIR)/usr/lib/dracut \
+	dracutsysrootdir=$(TARGET_DIR) \
+	$(HOST_DIR)/bin/dracut \
+	--kver $(BR2_LINUX_KERNEL_VERSION).0 \
+	-c $(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE) \
+	--tmpdir $(@D)/tmp \
+	-M \
+	--force \
+	--keep \
+	$@
+
+endef
+
+$(eval $(rootfs))
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Arnout Vandecappelle]

On 15/12/2021 19:00, Thierry Bultel wrote:
> Adds an option to build an initramfs image,
> using the dracut host tool.
> 
> Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
> ---
>   fs/Config.in        |  1 +
>   fs/dracut/Config.in | 13 +++++++++++
>   fs/dracut/dracut.mk | 55 +++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 69 insertions(+)
>   create mode 100644 fs/dracut/Config.in
>   create mode 100644 fs/dracut/dracut.mk
> 
> diff --git a/fs/Config.in b/fs/Config.in
> index eee5e26bb2..3938f3b9a7 100644
> --- a/fs/Config.in
> +++ b/fs/Config.in
> @@ -5,6 +5,7 @@ source "fs/btrfs/Config.in"
>   source "fs/cloop/Config.in"
>   source "fs/cpio/Config.in"
>   source "fs/cramfs/Config.in"
> +source "fs/dracut/Config.in"
>   source "fs/erofs/Config.in"
>   source "fs/ext2/Config.in"
>   source "fs/f2fs/Config.in"
> diff --git a/fs/dracut/Config.in b/fs/dracut/Config.in
> new file mode 100644
> index 0000000000..ee4220def8
> --- /dev/null
> +++ b/fs/dracut/Config.in
> @@ -0,0 +1,13 @@
> +config BR2_TARGET_ROOTFS_DRACUT
> +	bool "Invoke dracut to make an initramfs"
> +	default n

  Don't add "default n", it's the default :-)

> +	select BR2_PACKAGE_HOST_DRACUT
> +	select BR2_PACKAGE_HOST_UBOOT_TOOLS
> +	help
> +	  Builds an additional initramfs using dracut. This can be useful to create a recovery system, for instance.
> +	
> +if BR2_TARGET_ROOTFS_DRACUT
> +config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
> +	string "configuration file"

  Is there a possibility for a default configuration file?

> +endif
> +
> diff --git a/fs/dracut/dracut.mk b/fs/dracut/dracut.mk
> new file mode 100644
> index 0000000000..9c91150e82
> --- /dev/null
> +++ b/fs/dracut/dracut.mk
> @@ -0,0 +1,55 @@
> +################################################################################
> +#
> +# dracut to archive target filesystem
> +#
> +################################################################################
> +
> +ROOTFS_DRACUT_DEPENDENCIES = host-dracut host-uboot-tools
> +
> +ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
> +
> +define ROOTFS_DRACUT_ADD_INIT
> +	if [ ! -e $(TARGET_DIR)/init ]; then \
> +		ln -sf sbin/init $(TARGET_DIR)/init; \
> +	fi
> +endef
> +
> +else
> +
> +# devtmpfs does not get automounted when initramfs is used.
> +# Add a pre-init script to mount it before running init
> +# We must have /dev/console very early, even before /init runs,
> +# for stdin/stdout/stderr
> +define ROOTFS_DRACUT_ADD_INIT
> +	if [ ! -e $(TARGET_DIR)/init ]; then \
> +		$(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
> +	fi
> +	mkdir -p $(TARGET_DIR)/dev
> +	mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
> +endef
> +
> +endif # BR2_ROOTFS_DEVICE_CREATION_STATIC

  The above is the same logic as in cpio.mk. It would be better if we could 
refactor that to a common place.

> +
> +ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
> +
> +define ROOTFS_DRACUT_CMD
> +
> +	mkdir -p $(@D)/tmp
> +	rm -rf $(@D)/tmp/*
> +
> +	DRACUT_LDD=$(TARGET_CROSS)ldd \
> +	DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
> +	dracutbasedir=$(HOST_DIR)/usr/lib/dracut \

  It would be nice if all of the above could be patches into host-dracut, so 
when called from a post-image script, it's not needed to pass all of that in.

  You should also check then if it gets properly updated by 
support/misc/relocate-sdk.sh (I think yes).


> +	dracutsysrootdir=$(TARGET_DIR) \
> +	$(HOST_DIR)/bin/dracut \
> +	--kver $(BR2_LINUX_KERNEL_VERSION).0 \

  This should be indented with a second tab.

  Also, you can't use BR2_LINUX_KERNEL_VERSION because that's only available if 
BR2_LINUX_KERNEL=y. So either you have to depend on that, or you need to add an 
option to Config.in to be able to set it. Also, you should probably use 
LINUX_VERSION_PROBED instead (at least if you need an actual kernel version, and 
not some commit hash or something). Also, what is the .0 appended to it?


> +	-c $(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE) \

  We normally have a check in the makefile to exit immediately if the option is 
not set. See for example in linux-backports. Note that it needs to be in a 
BR_BUILDING condition.


  Regards,
  Arnout

> +	--tmpdir $(@D)/tmp \
> +	-M \
> +	--force \
> +	--keep \
> +	$@
> +
> +endef
> +
> +$(eval $(rootfs))
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

[-- Attachment #1.1: Type: text/plain, Size: 4592 bytes --]

Hi,
>> +    select BR2_PACKAGE_HOST_DRACUT
>> +    select BR2_PACKAGE_HOST_UBOOT_TOOLS
>> +    help
>> +      Builds an additional initramfs using dracut. This can be 
>> useful to create a recovery system, for instance.
>> +
>> +if BR2_TARGET_ROOTFS_DRACUT
>> +config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
>> +    string "configuration file"
>
>  Is there a possibility for a default configuration file?
Would that really make sense ? What would be default the expected 
packages in the ram disk ?
Notice that the content of the config file strongly depends on the init 
system (dracut being mostly
thought for systemd, but I use it with busybox/init.d in my case).
But I agree that I must add an error in the .mk when the file is not 
specified/does not exist

(more notes below)
>
>> +endif
>> +
>> diff --git a/fs/dracut/dracut.mk b/fs/dracut/dracut.mk
>> new file mode 100644
>> index 0000000000..9c91150e82
>> --- /dev/null
>> +++ b/fs/dracut/dracut.mk
>> @@ -0,0 +1,55 @@
>> +################################################################################ 
>>
>> +#
>> +# dracut to archive target filesystem
>> +#
>> +################################################################################ 
>>
>> +
>> +ROOTFS_DRACUT_DEPENDENCIES = host-dracut host-uboot-tools
>> +
>> +ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
>> +
>> +define ROOTFS_DRACUT_ADD_INIT
>> +    if [ ! -e $(TARGET_DIR)/init ]; then \
>> +        ln -sf sbin/init $(TARGET_DIR)/init; \
>> +    fi
>> +endef
>> +
>> +else
>> +
>> +# devtmpfs does not get automounted when initramfs is used.
>> +# Add a pre-init script to mount it before running init
>> +# We must have /dev/console very early, even before /init runs,
>> +# for stdin/stdout/stderr
>> +define ROOTFS_DRACUT_ADD_INIT
>> +    if [ ! -e $(TARGET_DIR)/init ]; then \
>> +        $(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
>> +    fi
>> +    mkdir -p $(TARGET_DIR)/dev
>> +    mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
>> +endef
>> +
>> +endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
>
>  The above is the same logic as in cpio.mk. It would be better if we 
> could refactor that to a common place.

I definitively agree, that is what I said myself. But what is the most 
appropriate place to put it ?

>
>> +
>> +ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
>> +
>> +define ROOTFS_DRACUT_CMD
>> +
>> +    mkdir -p $(@D)/tmp
>> +    rm -rf $(@D)/tmp/*
>> +
>> +    DRACUT_LDD=$(TARGET_CROSS)ldd \
>> +    DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
>> +    dracutbasedir=$(HOST_DIR)/usr/lib/dracut \
>
>  It would be nice if all of the above could be patches into 
> host-dracut, so when called from a post-image script, it's not needed 
> to pass all of that in.

This time, I do not agree. I contrary to some tools that are not thought 
for cross environments, and that deserve patching to behave the
appropriate way, dracut is designed for that.
At various places it checks the given environment variables (in both 
bash and C), and this is the way to use it.


>
>  You should also check then if it gets properly updated by 
> support/misc/relocate-sdk.sh (I think yes).
I am sorry, but I do not see the point here, would you mind explain please ?
>
>
>> +    dracutsysrootdir=$(TARGET_DIR) \
>> +    $(HOST_DIR)/bin/dracut \
>> +    --kver $(BR2_LINUX_KERNEL_VERSION).0 \
>
>  This should be indented with a second tab.
>
>  Also, you can't use BR2_LINUX_KERNEL_VERSION because that's only 
> available if BR2_LINUX_KERNEL=y. So either you have to depend on that, 
> or you need to add an option to Config.in to be able to set it. Also, 
> you should probably use LINUX_VERSION_PROBED instead (at least if you 
> need an actual kernel version, and not some commit hash or something). 
> Also, what is the .0 appended to it?

Dracut needs the /lib/modules/x.x.x directory name
When a 5.10 kernel is selected, modules go to /lib/modules/5.10.0
Thanks for the LINUX_VERSION_PROBED, this is what I needed !

>
>
>> +    -c $(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE) \
>
>  We normally have a check in the makefile to exit immediately if the 
> option is not set. See for example in linux-backports. Note that it 
> needs to be in a BR_BUILDING condition.
Ok, I will check that
Regards
Thierrt
>
>
>  Regards,
>  Arnout
>
>> +    --tmpdir $(@D)/tmp \
>> +    -M \
>> +    --force \
>> +    --keep \
>> +    $@
>> +
>> +endef
>> +
>> +$(eval $(rootfs))
>>

-- 
Re: test
www.linatsea.fr <www.linatsea.fr>
-- 
www.linatsea.fr

[-- Attachment #1.2.1: Type: text/html, Size: 8200 bytes --]

[-- Attachment #1.2.2: penguin.png --]
[-- Type: image/png, Size: 60087 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Arnout Vandecappelle]

On 17/12/2021 12:04, Thierry Bultel wrote:
> Hi,
>>> +    select BR2_PACKAGE_HOST_DRACUT
>>> +    select BR2_PACKAGE_HOST_UBOOT_TOOLS
>>> +    help
>>> +      Builds an additional initramfs using dracut. This can be useful to 
>>> create a recovery system, for instance.
>>> +
>>> +if BR2_TARGET_ROOTFS_DRACUT
>>> +config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
>>> +    string "configuration file"
>>
>>  Is there a possibility for a default configuration file?
> Would that really make sense ? What would be default the expected packages in 
> the ram disk ?

  Yeah, OK, good point...

> Notice that the content of the config file strongly depends on the init system 
> (dracut being mostly
> thought for systemd, but I use it with busybox/init.d in my case).
> But I agree that I must add an error in the .mk when the file is not 
> specified/does not exist
> 
> (more notes below)
>>

[snip]
>>> +# devtmpfs does not get automounted when initramfs is used.
>>> +# Add a pre-init script to mount it before running init
>>> +# We must have /dev/console very early, even before /init runs,
>>> +# for stdin/stdout/stderr
>>> +define ROOTFS_DRACUT_ADD_INIT
>>> +    if [ ! -e $(TARGET_DIR)/init ]; then \
>>> +        $(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
>>> +    fi
>>> +    mkdir -p $(TARGET_DIR)/dev
>>> +    mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
>>> +endef
>>> +
>>> +endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
>>
>>  The above is the same logic as in cpio.mk. It would be better if we could 
>> refactor that to a common place.
> 
> I definitively agree, that is what I said myself. But what is the most 
> appropriate place to put it ?

  I wouldn't be opposed to putting it in fs/common.mk. Yann, what do you think?

  I am, however, thinking something else as well. What does the dracut fs 
produce? Is it a cpio image? If so, then it might be a good idea to instead make 
this a suboption of cpio. This, in turn, would make it possible to use dracut 
for an initramfs.


>>> +
>>> +ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
>>> +
>>> +define ROOTFS_DRACUT_CMD
>>> +
>>> +    mkdir -p $(@D)/tmp
>>> +    rm -rf $(@D)/tmp/*
>>> +
>>> +    DRACUT_LDD=$(TARGET_CROSS)ldd \
>>> +    DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
>>> +    dracutbasedir=$(HOST_DIR)/usr/lib/dracut \
>>
>>  It would be nice if all of the above could be patches into host-dracut, so 
>> when called from a post-image script, it's not needed to pass all of that in.
> 
> This time, I do not agree. I contrary to some tools that are not thought for 
> cross environments, and that deserve patching to behave the
> appropriate way, dracut is designed for that.
> At various places it checks the given environment variables (in both bash and 
> C), and this is the way to use it.

  OK, let me reconsider that. It would be nice to add a wrapper script to the 
host-dracut package that sets these environment variables. This way it becomes a 
lot easier to use dracut in a post-image script instead of as a filesystem.

  But maybe I'm overthinking things - the dracut fs could very well be enough to 
start with. In that case, the probably shouldn't be a user-visible HOST_DRACUT 
option either.


>>  You should also check then if it gets properly updated by 
>> support/misc/relocate-sdk.sh (I think yes).
> I am sorry, but I do not see the point here, would you mind explain please ?

  If there's such a wrapper script that sets the environment variables 
correctly, the idea is to be able to use that as part of the SDK. That also 
means it must be possible to move it to a different place. Since it contains 
hardcoded paths to HOST_DIR, these need to be change when the SDK is relocated. 
The relocate-sdk.sh script should do that, but it's important to check that 
indeed it does.


>>> +    dracutsysrootdir=$(TARGET_DIR) \
>>> +    $(HOST_DIR)/bin/dracut \
>>> +    --kver $(BR2_LINUX_KERNEL_VERSION).0 \
>>
>>  This should be indented with a second tab.
>>
>>  Also, you can't use BR2_LINUX_KERNEL_VERSION because that's only available if 
>> BR2_LINUX_KERNEL=y. So either you have to depend on that, or you need to add 
>> an option to Config.in to be able to set it. Also, you should probably use 
>> LINUX_VERSION_PROBED instead (at least if you need an actual kernel version, 
>> and not some commit hash or something). Also, what is the .0 appended to it?
> 
> Dracut needs the /lib/modules/x.x.x directory name
> When a 5.10 kernel is selected, modules go to /lib/modules/5.10.0
> Thanks for the LINUX_VERSION_PROBED, this is what I needed !

  This is only needed if you actually have modules to add to the cpio image 
(which is only the case if you build the kernel, obviously). There are plenty of 
use cases where an initrd is useful but no modules are used (or they aren't 
needed during until the rootfs is mounted).

  So, does dracut have an option to not install modules? If yes, you can use 
--kver is the kernel is built, and whatever option is needed to skip modules if not.


  Regards,
  Arnout


>>> +    -c $(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE) \
>>
>>  We normally have a check in the makefile to exit immediately if the option is 
>> not set. See for example in linux-backports. Note that it needs to be in a 
>> BR_BUILDING condition.
> Ok, I will check that
> Regards
> Thierrt
>>
>>
>>  Regards,
>>  Arnout
>>
>>> +    --tmpdir $(@D)/tmp \
>>> +    -M \
>>> +    --force \
>>> +    --keep \
>>> +    $@
>>> +
>>> +endef
>>> +
>>> +$(eval $(rootfs))
>>>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

[-- Attachment #1.1: Type: text/plain, Size: 4308 bytes --]


>> I definitively agree, that is what I said myself. But what is the 
>> most appropriate place to put it ?
>
>  I wouldn't be opposed to putting it in fs/common.mk. Yann, what do 
> you think?
>
>  I am, however, thinking something else as well. What does the dracut 
> fs produce? Is it a cpio image? If so, then it might be a good idea to 
> instead make this a suboption of cpio. This, in turn, would make it 
> possible to use dracut for an initramfs.
>
Good idea. But dracut generates a gzipped cpio image. Maybe, instead, 
the "cpio" and "dracut" options (exclusives) could be but in a "Initial 
RAM filesystem" menu.
(This is not a use case to create both a cpio -and- a dracut image, imho)

>>>> +
>>>> +ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
>>>> +
>>>> +define ROOTFS_DRACUT_CMD
>>>> +
>>>> +    mkdir -p $(@D)/tmp
>>>> +    rm -rf $(@D)/tmp/*
>>>> +
>>>> +    DRACUT_LDD=$(TARGET_CROSS)ldd \
>>>> +    DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
>>>> +    dracutbasedir=$(HOST_DIR)/usr/lib/dracut \
>>>
>>>  It would be nice if all of the above could be patches into 
>>> host-dracut, so when called from a post-image script, it's not 
>>> needed to pass all of that in.
>>
>> This time, I do not agree. I contrary to some tools that are not 
>> thought for cross environments, and that deserve patching to behave the
>> appropriate way, dracut is designed for that.
>> At various places it checks the given environment variables (in both 
>> bash and C), and this is the way to use it.
>
>  OK, let me reconsider that. It would be nice to add a wrapper script 
> to the host-dracut package that sets these environment variables. This 
> way it becomes a lot easier to use dracut in a post-image script 
> instead of as a filesystem.
>
>  But maybe I'm overthinking things - the dracut fs could very well be 
> enough to start with. In that case, the probably shouldn't be a 
> user-visible HOST_DRACUT option either.
>
>
Let's do that,ok. Having host-dracut without using it at the end is 
nonsense, I agree.
>>>  You should also check then if it gets properly updated by 
>>> support/misc/relocate-sdk.sh (I think yes).
>> I am sorry, but I do not see the point here, would you mind explain 
>> please ?
>
>  If there's such a wrapper script that sets the environment variables 
> correctly, the idea is to be able to use that as part of the SDK. That 
> also means it must be possible to move it to a different place. Since 
> it contains hardcoded paths to HOST_DIR, these need to be change when 
> the SDK is relocated. The relocate-sdk.sh script should do that, but 
> it's important to check that indeed it does.
>
ok, thanks
>
>>>> +    dracutsysrootdir=$(TARGET_DIR) \
>>>> +    $(HOST_DIR)/bin/dracut \
>>>> +    --kver $(BR2_LINUX_KERNEL_VERSION).0 \
>>>
>>>  This should be indented with a second tab.
>>>
>>>  Also, you can't use BR2_LINUX_KERNEL_VERSION because that's only 
>>> available if BR2_LINUX_KERNEL=y. So either you have to depend on 
>>> that, or you need to add an option to Config.in to be able to set 
>>> it. Also, you should probably use LINUX_VERSION_PROBED instead (at 
>>> least if you need an actual kernel version, and not some commit hash 
>>> or something). Also, what is the .0 appended to it?
>>
>> Dracut needs the /lib/modules/x.x.x directory name
>> When a 5.10 kernel is selected, modules go to /lib/modules/5.10.0
>> Thanks for the LINUX_VERSION_PROBED, this is what I needed !
>
>  This is only needed if you actually have modules to add to the cpio 
> image (which is only the case if you build the kernel, obviously). 
> There are plenty of use cases where an initrd is useful but no modules 
> are used (or they aren't needed during until the rootfs is mounted).
>
>  So, does dracut have an option to not install modules? If yes, you 
> can use --kver is the kernel is built, and whatever option is needed 
> to skip modules if not.
The dracut "--no-kernel" option (which is badly named) makes the modules 
and firmwares to be skipped. So ok, If I do not have BR2_LINUX_KERNEL 
(which is a case I have never met, honestly),
I will put that option instead, and set the dependencies accordingly.

Regards,
Thierry
>
>

-- 
Re: test
www.linatsea.fr <www.linatsea.fr>
-- 
www.linatsea.fr

[-- Attachment #1.2.1: Type: text/html, Size: 7193 bytes --]

[-- Attachment #1.2.2: penguin.png --]
[-- Type: image/png, Size: 60087 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Yann E. MORIN]

Thierry, All,

On 2021-12-17 22:50 +0100, Thierry Bultel spake thusly:
> Good idea. But dracut generates a gzipped cpio image.

That the cpio is gzipped is unfortuante, because the kernel will again
compress it as part of its own compression (whem it is used as an
initramfs, IIRC).

> Maybe, instead, the
> "cpio" and "dracut" options (exclusives) could be but in a "Initial RAM
> filesystem" menu.

We already have such a filesystem:
    fs/initramfs/
        "initial RAM filesystem linked into linux kernel"

And this one is tricky, because it hooks into linux/linux.mk with manual
and custom dependencies (see linux/linux.mk@571). I am not 100% happy on
how this is done, but we can't really have better...

So, I think that having dracut be an option of cpio is the easiest way
to go...

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 mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

Le 18/12/2021 à 14:22, Yann E. MORIN a écrit :
> Thierry, All,
Hi Yann,
Nice to hear from you again
>
> On 2021-12-17 22:50 +0100, Thierry Bultel spake thusly:
>> Good idea. But dracut generates a gzipped cpio image.
> That the cpio is gzipped is unfortuante, because the kernel will again
> compress it as part of its own compression (whem it is used as an
> initramfs, IIRC).
Yes, it is not aimed to be used like that.

Clearly, the origin of dracut is the desktop world (where the initrd is 
separated)

But I really found it convenient (as I say in the commit description) 
for the embedded
world, typically to build a recovery system (this is my use case)
In addition to the dracut features you mention in your other mail, there 
are also
the handling of dependencies to firmwares (provided that the kernel 
modules declare it
by the MODULE_FIRMWARE macro, and that is not the case of all of them, I
encountered some staging drivers that do not)
and the respect of symlinks.
The concept of dracut modules is nice, too.
>
>> Maybe, instead, the
>> "cpio" and "dracut" options (exclusives) could be but in a "Initial RAM
>> filesystem" menu.
> We already have such a filesystem:
>      fs/initramfs/
>          "initial RAM filesystem linked into linux kernel"
>
> And this one is tricky, because it hooks into linux/linux.mk with manual
> and custom dependencies (see linux/linux.mk@571). I am not 100% happy on
> how this is done, but we can't really have better...
>
> So, I think that having dracut be an option of cpio is the easiest way
> to go...

Thanks Yann, I agree, and I am about to send a patch set that does the 
trick like that.
Regards,
Thierry

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Yann E. MORIN]

Arnout, Thierry, All,

On 2021-12-17 19:05 +0100, Arnout Vandecappelle spake thusly:
> >>>+if BR2_TARGET_ROOTFS_DRACUT
> >>>+config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
> >>>+    string "configuration file"
> >> Is there a possibility for a default configuration file?
> >Would that really make sense ? What would be default the expected packages
> >in the ram disk ?
>  Yeah, OK, good point...

Agreed, there can't be a reasonable default.

> >Notice that the content of the config file strongly depends on the init
> >system (dracut being mostly
> >thought for systemd, but I use it with busybox/init.d in my case).
> >But I agree that I must add an error in the .mk when the file is not
> >specified/does not exist

Yes, catching that nicely would be better. What we usually do is:

    ifeq ($(BR_DUILDING).$(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE),y.)
    $(error No file specified in BR2_TARGET_ROOTFS_DRACUT_CONF_FILE)
    endif

And if the file is missing, then presumably dracut will exit in error,
which is sufficient for me.

> [snip]
> >>>+# devtmpfs does not get automounted when initramfs is used.
> >>>+# Add a pre-init script to mount it before running init
> >>>+# We must have /dev/console very early, even before /init runs,
> >>>+# for stdin/stdout/stderr
> >>>+define ROOTFS_DRACUT_ADD_INIT
> >>>+    if [ ! -e $(TARGET_DIR)/init ]; then \
> >>>+        $(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
> >>>+    fi
> >>>+    mkdir -p $(TARGET_DIR)/dev
> >>>+    mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
> >>>+endef
> >>>+
> >>>+endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
> >>
> >> The above is the same logic as in cpio.mk. It would be better if we
> >>could refactor that to a common place.
> >
> >I definitively agree, that is what I said myself. But what is the most
> >appropriate place to put it ?
> 
>  I wouldn't be opposed to putting it in fs/common.mk. Yann, what do you think?

Not sure. Usually, we try not to comonalise things until we have at
least a few users.

In  this case, it is very improbably that we have enough users to
warrant common code, so duplication is still OK in my opinion.

However...

>  I am, however, thinking something else as well. What does the dracut fs
> produce? Is it a cpio image? If so, then it might be a good idea to instead
> make this a suboption of cpio. This, in turn, would make it possible to use
> dracut for an initramfs.

This was to be my proposal too: extends the existing fs/cpio to
optionally use dracut to prepare the file list.

I was wondering why we did not just hand over such a list to cpio
(replacing the existing 'find'). But dracut is more than jsut a file
list: it presumably knows how to handle library dependencies (NEEDED)
and follows recursively, and similarly for kernel modules. Otherwise,
dracut would be of very little interest...

(I see that Thierry also replied, but I was not on Cc so I nearly missed
it... I'll reply further to Thierry message in a moment...)

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 mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

>
>>>  You should also check then if it gets properly updated by 
>>> support/misc/relocate-sdk.sh (I think yes).
>> I am sorry, but I do not see the point here, would you mind explain 
>> please ?
>
>  If there's such a wrapper script that sets the environment variables 
> correctly, the idea is to be able to use that as part of the SDK. That 
> also means it must be possible to move it to a different place. Since 
> it contains hardcoded paths to HOST_DIR, these need to be change when 
> the SDK is relocated. The relocate-sdk.sh script should do that, but 
> it's important to check that indeed it does.

I probably miss something here. Is it a bad idea to -not- use hardcoded 
paths in the wrapper script, but environment variables instead ?
It should be something like:

-------------
#!/bin/bash
set -e

if [ -z "$*" ]; then
     echo "No argument supplied"
     exit
fi

DRACUT_LDD=${TARGET_CROSS}ldd \
DRACUT_INSTALL="${HOST_DIR}/lib/dracut/dracut-install" \
dracutbasedir=${HOST_DIR}/usr/lib/dracut \
dracutsysrootdir=${TARGET_DIR} \
${HOST_DIR}/bin/dracut "$@"
----------

So that should not impact the relocation ...

By the way, in cpio.mk, I also had to

export TARGET_CROSS


Regards

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Yann E. MORIN]

Thierry, All,

On 2021-12-19 07:55 +0100, Thierry Bultel spake thusly:
> >>> You should also check then if it gets properly updated by
> >>>support/misc/relocate-sdk.sh (I think yes).
> >>I am sorry, but I do not see the point here, would you mind explain
> >>please ?
> >
> > If there's such a wrapper script that sets the environment variables
> >correctly, the idea is to be able to use that as part of the SDK. That
> >also means it must be possible to move it to a different place. Since it
> >contains hardcoded paths to HOST_DIR, these need to be change when the SDK
> >is relocated. The relocate-sdk.sh script should do that, but it's
> >important to check that indeed it does.
> 
> I probably miss something here. Is it a bad idea to -not- use hardcoded
> paths in the wrapper script, but environment variables instead ?
> It should be something like:
> 
> -------------
> #!/bin/bash
> set -e
> 
> if [ -z "$*" ]; then
>     echo "No argument supplied"
>     exit
> fi
> 
> DRACUT_LDD=${TARGET_CROSS}ldd \
> DRACUT_INSTALL="${HOST_DIR}/lib/dracut/dracut-install" \
> dracutbasedir=${HOST_DIR}/usr/lib/dracut \
> dracutsysrootdir=${TARGET_DIR} \
> ${HOST_DIR}/bin/dracut "$@"
> ----------

The thing is, with the SDK, those variables are not set.

  - HOST_DIR can be easily derived; it is: $(dirname $(dirname "${0}"))
    or a little be simpler: $(dirname "${0%/*}")

  - TARGET_CROSS can probably be derived somehow, but not even sure...

  - TAGET_DIR has to be specified explicitly.

So, I think for now it would be over-engineering to try and catter for
the SDK; this can be acted upon later...

Regards,
Yann E. MORIN.

> So that should not impact the relocation ...
> 
> By the way, in cpio.mk, I also had to
> 
> export TARGET_CROSS
> 
> 
> Regards
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/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 mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Arnout Vandecappelle]

On 19/12/2021 09:23, Yann E. MORIN wrote:
> Thierry, All,
> 
> On 2021-12-19 07:55 +0100, Thierry Bultel spake thusly:
>>>>>   You should also check then if it gets properly updated by
>>>>> support/misc/relocate-sdk.sh (I think yes).
>>>> I am sorry, but I do not see the point here, would you mind explain
>>>> please ?
>>>
>>>   If there's such a wrapper script that sets the environment variables
>>> correctly, the idea is to be able to use that as part of the SDK. That
>>> also means it must be possible to move it to a different place. Since it
>>> contains hardcoded paths to HOST_DIR, these need to be change when the SDK
>>> is relocated. The relocate-sdk.sh script should do that, but it's
>>> important to check that indeed it does.
>>
>> I probably miss something here. Is it a bad idea to -not- use hardcoded
>> paths in the wrapper script, but environment variables instead ?

  No, I meant to generate a wrapper script that has the paths hardcoded. This 
way, you can call the script externally without having to set up anything in the 
environment. Similar like how you can call cross-gcc to build something and it 
Just Works, thanks to our toolchain wrapper.

  Since the paths would be hardcoded, it needs to be treated by relocate-sdk.sh 
when moving the SDK around.

  However...

>> It should be something like:
>>
>> -------------
>> #!/bin/bash
>> set -e
>>
>> if [ -z "$*" ]; then
>>      echo "No argument supplied"
>>      exit
>> fi
>>
>> DRACUT_LDD=${TARGET_CROSS}ldd \
>> DRACUT_INSTALL="${HOST_DIR}/lib/dracut/dracut-install" \
>> dracutbasedir=${HOST_DIR}/usr/lib/dracut \
>> dracutsysrootdir=${TARGET_DIR} \
>> ${HOST_DIR}/bin/dracut "$@"
>> ----------
> 
> The thing is, with the SDK, those variables are not set.
> 
>    - HOST_DIR can be easily derived; it is: $(dirname $(dirname "${0}"))
>      or a little be simpler: $(dirname "${0%/*}")
> 
>    - TARGET_CROSS can probably be derived somehow, but not even sure...
> 
>    - TAGET_DIR has to be specified explicitly.
> 
> So, I think for now it would be over-engineering to try and catter for
> the SDK; this can be acted upon later...

  ... this is very true. So for the time being, let's not worry about such a 
wrapper script, and instead focus on fs/dracut.

  Regards,
  Arnout


> 
> Regards,
> Yann E. MORIN.
> 
>> So that should not impact the relocation ...
>>
>> By the way, in cpio.mk, I also had to
>>
>> export TARGET_CROSS
>>
>>
>> Regards
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

>> So, I think for now it would be over-engineering to try and catter for
>> the SDK; this can be acted upon later...
>
>  ... this is very true. So for the time being, let's not worry about 
> such a wrapper script, and instead focus on fs/dracut.
>
>  Regards,
>  Arnout
Arnoult,
I have added the wrapper to my latest patch series, do you want it to be 
removed ?

Regards,
Thierry
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/3] package/cross-ldd: new package

[Arnout Vandecappelle]

On 15/12/2021 19:00, Thierry Bultel wrote:
> cross-ldd works just as ldd, but supports
> other architectures. It is needed by dracut, for instance.

  I vaguely remember that at some point we considered adding cross-ldd, but 
instead opted for a different approach. I can't find anything in the archives 
however. Adam, I suspect this must have been for gobject-introspection, do you 
remember anything like that?

> Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
> ---
>   package/Config.in.host           |  1 +
>   package/cross-ldd/Config.in.host |  5 +++++
>   package/cross-ldd/cross-ldd.mk   | 20 ++++++++++++++++++++
>   3 files changed, 26 insertions(+)
>   create mode 100644 package/cross-ldd/Config.in.host
>   create mode 100644 package/cross-ldd/cross-ldd.mk
> 
> diff --git a/package/Config.in.host b/package/Config.in.host
> index 6e5a5c5fc5..0e8b071a2b 100644
> --- a/package/Config.in.host
> +++ b/package/Config.in.host
> @@ -12,6 +12,7 @@ menu "Host utilities"
>   	source "package/checksec/Config.in.host"
>   	source "package/cmake/Config.in.host"
>   	source "package/cramfs/Config.in.host"
> +	source "package/cross-ldd/Config.in.host"
>   	source "package/cryptsetup/Config.in.host"
>   	source "package/dbus-python/Config.in.host"
>   	source "package/dfu-util/Config.in.host"
> diff --git a/package/cross-ldd/Config.in.host b/package/cross-ldd/Config.in.host
> new file mode 100644
> index 0000000000..237af701d2
> --- /dev/null
> +++ b/package/cross-ldd/Config.in.host
> @@ -0,0 +1,5 @@
> +config BR2_PACKAGE_HOST_CROSS_LDD
> +	bool "cross ldd"

  We only add Config.in.host options for tools that are expected to be useful in 
post-install scripts. I don't think that that's the case here though?

> +	help
> +	ldd drop-in replacement for cross-compilation toolchains.
> +	This is the officially supported version mentioned in the dracut documentation
> diff --git a/package/cross-ldd/cross-ldd.mk b/package/cross-ldd/cross-ldd.mk
> new file mode 100644
> index 0000000000..9326a508bb
> --- /dev/null
> +++ b/package/cross-ldd/cross-ldd.mk
> @@ -0,0 +1,20 @@
> +################################################################################
> +#
> +# cross-ldd
> +#
> +################################################################################
> +
> +CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
> +CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION).zip

  AFAICS there's no reason to use a zip file. Just remove this line and the 
EXTRACT_CMDS and it should work as well.


  Regards,
  Arnout

> +CROSS_LDD_SITE = https://gist.github.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f/archive
> +
> +define HOST_CROSS_LDD_EXTRACT_CMDS
> +	unzip $(HOST_CROSS_LDD_DL_DIR)/$(CROSS_LDD_SOURCE) -d $(@D)
> +	find $(@D) -name cross-compile-ldd -exec mv {} $(@D) \;
> +endef
> +
> +define HOST_CROSS_LDD_INSTALL_CMDS
> +	install -m 755 $(@D)/cross-compile-ldd $(TARGET_CROSS)ldd
> +endef
> +
> +$(eval $(host-generic-package))
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/3] package/cross-ldd: new package

[Thierry Bultel]

+    help
>> +    ldd drop-in replacement for cross-compilation toolchains.
>> +    This is the officially supported version mentioned in the dracut 
>> documentation
>> diff --git a/package/cross-ldd/cross-ldd.mk 
>> b/package/cross-ldd/cross-ldd.mk
>> new file mode 100644
>> index 0000000000..9326a508bb
>> --- /dev/null
>> +++ b/package/cross-ldd/cross-ldd.mk
>> @@ -0,0 +1,20 @@
>> +################################################################################ 
>>
>> +#
>> +# cross-ldd
>> +#
>> +################################################################################ 
>>
>> +
>> +CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
>> +CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION).zip
>
>  AFAICS there's no reason to use a zip file. Just remove this line and 
> the EXTRACT_CMDS and it should work as well.
>
Hi,
Unfortunately, this is not that simple, I cannot find a simply way to 
download a single flat file,
because the download system makes a strong assumption that it is a tar file.

my best option seems to be something like:


CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION)/cross-compile-ldd

CROSS_LDD_SITE = 
https://gist.githubusercontent.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f/raw

define HOST_CROSS_LDD_EXTRACT_CMDS
     # Single file, no extract needed
     cp $(HOST_CROSS_LDD_DL_DIR)/cross-compile-ldd $(@D)
endef

Regards,
Thierry

>
>  Regards,
>  Arnout 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/3] package/cross-ldd: new package

[Arnout Vandecappelle]

On 17/12/2021 11:10, Thierry Bultel wrote:
> +    help
>>> +    ldd drop-in replacement for cross-compilation toolchains.
>>> +    This is the officially supported version mentioned in the dracut 
>>> documentation
>>> diff --git a/package/cross-ldd/cross-ldd.mk b/package/cross-ldd/cross-ldd.mk
>>> new file mode 100644
>>> index 0000000000..9326a508bb
>>> --- /dev/null
>>> +++ b/package/cross-ldd/cross-ldd.mk
>>> @@ -0,0 +1,20 @@
>>> +################################################################################ 
>>>
>>> +#
>>> +# cross-ldd
>>> +#
>>> +################################################################################ 
>>>
>>> +
>>> +CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
>>> +CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION).zip
>>
>>  AFAICS there's no reason to use a zip file. Just remove this line and the 
>> EXTRACT_CMDS and it should work as well.
>>
> Hi,
> Unfortunately, this is not that simple, I cannot find a simply way to download a 
> single flat file,
> because the download system makes a strong assumption that it is a tar file.

  Yes, but why is that a problem?

  This works:

CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION).tar.gz
CROSS_LDD_SITE = 
https://gist.github.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f/archive

So indeed I was wrong about just removing the line. But a tarball works just fine.

  Regards,
  Arnout

> 
> my best option seems to be something like:
> 
> 
> CROSS_LDD_VERSION = 6c9c724ebd6a29c279c6e5734e44c07f067808ec
> CROSS_LDD_SOURCE = $(CROSS_LDD_VERSION)/cross-compile-ldd
> 
> CROSS_LDD_SITE = 
> https://gist.githubusercontent.com/jerome-pouiller/c403786c1394f53f44a3b61214489e6f/raw 
> 
> 
> define HOST_CROSS_LDD_EXTRACT_CMDS
>      # Single file, no extract needed
>      cp $(HOST_CROSS_LDD_DL_DIR)/cross-compile-ldd $(@D)
> endef
> 
> Regards,
> Thierry
> 
>>
>>  Regards,
>>  Arnout 
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/3] fs/dracut: new fs type

[Thierry Bultel]

Adds an option to build an initramfs image,
using the dracut host tool.

Signed-off-by: Thierry Bultel <thierry.bultel@linatsea.fr>
---
 fs/Config.in        |  1 +
 fs/dracut/Config.in | 13 +++++++++++
 fs/dracut/dracut.mk | 55 +++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 69 insertions(+)
 create mode 100644 fs/dracut/Config.in
 create mode 100644 fs/dracut/dracut.mk

diff --git a/fs/Config.in b/fs/Config.in
index eee5e26bb2..3938f3b9a7 100644
--- a/fs/Config.in
+++ b/fs/Config.in
@@ -5,6 +5,7 @@ source "fs/btrfs/Config.in"
 source "fs/cloop/Config.in"
 source "fs/cpio/Config.in"
 source "fs/cramfs/Config.in"
+source "fs/dracut/Config.in"
 source "fs/erofs/Config.in"
 source "fs/ext2/Config.in"
 source "fs/f2fs/Config.in"
diff --git a/fs/dracut/Config.in b/fs/dracut/Config.in
new file mode 100644
index 0000000000..ee4220def8
--- /dev/null
+++ b/fs/dracut/Config.in
@@ -0,0 +1,13 @@
+config BR2_TARGET_ROOTFS_DRACUT
+	bool "Invoke dracut to make an initramfs"
+	default n
+	select BR2_PACKAGE_HOST_DRACUT
+	select BR2_PACKAGE_HOST_UBOOT_TOOLS
+	help
+	  Builds an additional initramfs using dracut. This can be useful to create a recovery system, for instance.
+	
+if BR2_TARGET_ROOTFS_DRACUT
+config BR2_TARGET_ROOTFS_DRACUT_CONF_FILE
+	string "configuration file"
+endif
+
diff --git a/fs/dracut/dracut.mk b/fs/dracut/dracut.mk
new file mode 100644
index 0000000000..9c91150e82
--- /dev/null
+++ b/fs/dracut/dracut.mk
@@ -0,0 +1,55 @@
+################################################################################
+#
+# dracut to archive target filesystem
+#
+################################################################################
+
+ROOTFS_DRACUT_DEPENDENCIES = host-dracut host-uboot-tools
+
+ifeq ($(BR2_ROOTFS_DEVICE_CREATION_STATIC),y)
+
+define ROOTFS_DRACUT_ADD_INIT
+	if [ ! -e $(TARGET_DIR)/init ]; then \
+		ln -sf sbin/init $(TARGET_DIR)/init; \
+	fi
+endef
+
+else
+
+# devtmpfs does not get automounted when initramfs is used.
+# Add a pre-init script to mount it before running init
+# We must have /dev/console very early, even before /init runs,
+# for stdin/stdout/stderr
+define ROOTFS_DRACUT_ADD_INIT
+	if [ ! -e $(TARGET_DIR)/init ]; then \
+		$(INSTALL) -m 0755 fs/cpio/init $(TARGET_DIR)/init; \
+	fi
+	mkdir -p $(TARGET_DIR)/dev
+	mknod -m 0622 $(TARGET_DIR)/dev/console c 5 1
+endef
+
+endif # BR2_ROOTFS_DEVICE_CREATION_STATIC
+
+ROOTFS_DRACUT_PRE_GEN_HOOKS += ROOTFS_DRACUT_ADD_INIT
+
+define ROOTFS_DRACUT_CMD
+
+	mkdir -p $(@D)/tmp
+	rm -rf $(@D)/tmp/*
+
+	DRACUT_LDD=$(TARGET_CROSS)ldd \
+	DRACUT_INSTALL="$(HOST_DIR)/lib/dracut/dracut-install"\
+	dracutbasedir=$(HOST_DIR)/usr/lib/dracut \
+	dracutsysrootdir=$(TARGET_DIR) \
+	$(HOST_DIR)/bin/dracut \
+	--kver $(BR2_LINUX_KERNEL_VERSION).0 \
+	-c $(BR2_TARGET_ROOTFS_DRACUT_CONF_FILE) \
+	--tmpdir $(@D)/tmp \
+	-M \
+	--force \
+	--keep \
+	$@
+
+endef
+
+$(eval $(rootfs))
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot