[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))
>>>