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

quoted

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)

quoted

quoted

quoted

+
+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.

quoted

quoted

 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

quoted

quoted

quoted

+    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