All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: Vyacheslav Yurkov <uvv.mail@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2] overlayfs-etc: add option to skip creation of mount dirs
Date: Wed, 14 Feb 2024 08:54:47 +0200	[thread overview]
Message-ID: <8734tv34vo.fsf@tarshish> (raw)
In-Reply-To: <8f1c6048-235b-4786-811c-50e79c806da4@gmail.com>

Hi Slava,

On Mon, Feb 12 2024, Vyacheslav Yurkov wrote:
> On 12.02.2024 19:30, Baruch Siach wrote:
>> The 'preinit' script can't create mount directories when rootfs is
>> read-only. Add an option to skip this step. The user must make sure that
>> all required directories are already in the rootfs directory layout.
>>
>> Cc: Vyacheslav Yurkov <uvv.mail@gmail.com>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> v2: Add a user selectable option. Don't skip mkdir automatically when
>>      read-only-rootfs feature is enabled.
>> ---
>>   meta/classes-recipe/overlayfs-etc.bbclass |  5 ++++-
>>   meta/files/overlayfs-etc-preinit.sh.in    | 16 +++++++++-------
>>   2 files changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/meta/classes-recipe/overlayfs-etc.bbclass b/meta/classes-recipe/overlayfs-etc.bbclass
>> index 0c7834d01f43..d339fbbeee9f 100644
>> --- a/meta/classes-recipe/overlayfs-etc.bbclass
>> +++ b/meta/classes-recipe/overlayfs-etc.bbclass
>> @@ -41,6 +41,7 @@ OVERLAYFS_ETC_USE_ORIG_INIT_NAME ??= "1"
>>   OVERLAYFS_ETC_MOUNT_OPTIONS ??= "defaults"
>>   OVERLAYFS_ETC_INIT_TEMPLATE ??= "${COREBASE}/meta/files/overlayfs-etc-preinit.sh.in"
>>   OVERLAYFS_ETC_EXPOSE_LOWER ??= "0"
>> +OVERLAYFS_ETC_CREATE_MOUNT_DIRS ??= "1"
>>     python create_overlayfs_etc_preinit() {
>>       overlayEtcMountPoint = d.getVar("OVERLAYFS_ETC_MOUNT_POINT")
>> @@ -62,6 +63,7 @@ python create_overlayfs_etc_preinit() {
>>       initBaseName = oe.path.join(d.getVar("base_sbindir"), "init")
>>       origInitNameSuffix = ".orig"
>>       exposeLower = oe.types.boolean(d.getVar('OVERLAYFS_ETC_EXPOSE_LOWER'))
>> +    createMoundDirs = oe.types.boolean(d.getVar('OVERLAYFS_ETC_CREATE_MOUNT_DIRS'))
>>         args = {
>>           'OVERLAYFS_ETC_MOUNT_POINT': overlayEtcMountPoint,
>> @@ -69,7 +71,8 @@ python create_overlayfs_etc_preinit() {
>>           'OVERLAYFS_ETC_FSTYPE': overlayEtcFsType,
>>           'OVERLAYFS_ETC_DEVICE': overlayEtcDevice,
>>           'SBIN_INIT_NAME': initBaseName + origInitNameSuffix if useOrigInit else initBaseName,
>> -        'OVERLAYFS_ETC_EXPOSE_LOWER': "true" if exposeLower else "false"
>> +        'OVERLAYFS_ETC_EXPOSE_LOWER': "true" if exposeLower else "false",
>> +        'CREATE_MOUNT_DIRS': "true" if createMoundDirs else "false"
>>       }
>>         if useOrigInit:
>> diff --git a/meta/files/overlayfs-etc-preinit.sh.in b/meta/files/overlayfs-etc-preinit.sh.in
>> index 8db076f4ba65..b05e3957a382 100644
>> --- a/meta/files/overlayfs-etc-preinit.sh.in
>> +++ b/meta/files/overlayfs-etc-preinit.sh.in
>> @@ -3,12 +3,15 @@
>>   echo "PREINIT: Start"
>>     PATH=/sbin:/bin:/usr/sbin:/usr/bin
>> -mount -o remount,rw /
>> -
>> -mkdir -p /proc
>> -mkdir -p /sys
>> -mkdir -p /run
>> -mkdir -p /var/run
>> +if {CREATE_MOUNT_DIRS}; then
>> +    mount -o remount,rw /
>> +
>> +    mkdir -p /proc
>> +    mkdir -p /sys
>> +    mkdir -p /run
>> +    mkdir -p /var/run
>> +    mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
>> +fi
>>     mount -t proc proc /proc
>>   mount -t sysfs sysfs /sys
>> @@ -20,7 +23,6 @@ UPPER_DIR=$BASE_OVERLAY_ETC_DIR/upper
>>   WORK_DIR=$BASE_OVERLAY_ETC_DIR/work
>>   LOWER_DIR=$BASE_OVERLAY_ETC_DIR/lower
>>   -mkdir -p {OVERLAYFS_ETC_MOUNT_POINT}
>>   if mount -n -t {OVERLAYFS_ETC_FSTYPE} \
>>       -o {OVERLAYFS_ETC_MOUNT_OPTIONS} \
>>       {OVERLAYFS_ETC_DEVICE} {OVERLAYFS_ETC_MOUNT_POINT}
>
> Hi Baruch,
> Thanks for the v2. Looks good now. Could you please also add a test case to
> cover the new option?
>
> You saw from the test that mount output is parsed to confirm whether overlay
> is actually mounted. sda3 is a 3rd partition from
> https://git.openembedded.org/openembedded-core/tree/meta-selftest/wic/overlayfs_etc.wks.in
> . We could change rootfs (2nd partition) in the file to substitute the fs type
> (ext4/squashfs) from the test and then check that everything is mounted
> correctly. Does it make sense?

Makes sense.

I added mkdirhier of OVERLAYFS_ETC_MOUNT_POINT for the case of
OVERLAYFS_ETC_CREATE_MOUNT_DIRS == 0. Let me know if there is a better
solution for read-only filesystems.

The trouble with testing is that I could not find any existing feature
in yocto-kernel-cache that enables either CONFIG_SQUASHFS or
CONFIG_EROFS_FS. Is there another way to enable kernel features for the
test?

Thanks,
baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


  reply	other threads:[~2024-02-14  7:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 18:30 [PATCH v2] overlayfs-etc: add option to skip creation of mount dirs Baruch Siach
2024-02-12 19:40 ` Vyacheslav Yurkov
2024-02-14  6:54   ` Baruch Siach [this message]
2024-02-15 18:38     ` Vyacheslav Yurkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8734tv34vo.fsf@tarshish \
    --to=baruch@tkos.co.il \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=uvv.mail@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.