public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Quirin Gylstorff <quirin.gylstorff@siemens.com>,
	cip-dev@lists.cip-project.org
Subject: Re: [PATCH 1/2] initramfs: add hook for data-reset
Date: Mon, 28 Apr 2025 11:03:11 +0200	[thread overview]
Message-ID: <3d45d258-6aba-415a-b894-dae3594844ff@siemens.com> (raw)
In-Reply-To: <d8e87b5b-0869-4805-b087-f7bdcbc9185e@siemens.com>

On 28.04.25 10:23, Quirin Gylstorff wrote:
> 
> 
> On 4/28/25 08:35, Jan Kiszka wrote:
>> On 24.04.25 11:22, Quirin Gylstorff wrote:
>>> From: Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>>
>>> This allows to reset the device data by deleting
>>> all files in the persistent partitions.
>>>
>>> The reset occurs if a file defined by the variable
>>> INITRAMFS_DATA_RESET_MARKER
>>> exists in the device INITRAMFS_DATA_RESET_MARKER_DEVICE.
>>>
>>> This feature allows to add device specific trigger to restore
>>> the persistent file system to the first-boot state.
>>>
>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>> ---
>>>   .../files/local-bottom-complete.tmpl          | 76 +++++++++++++++++++
>>>   .../initramfs-data-reset-hook_0.1.bb          | 36 +++++++++
>>>   2 files changed, 112 insertions(+)
>>>   create mode 100644 recipes-initramfs/initramfs-factory-reset-hook/
>>> files/local-bottom-complete.tmpl
>>>   create mode 100644 recipes-initramfs/initramfs-factory-reset-hook/
>>> initramfs-data-reset-hook_0.1.bb
>>>
>>> diff --git a/recipes-initramfs/initramfs-factory-reset-hook/files/
>>> local-bottom-complete.tmpl b/recipes-initramfs/initramfs-factory-
>>> reset-hook/files/local-bottom-complete.tmpl
>>> new file mode 100644
>>> index 0000000..f02f95c
>>> --- /dev/null
>>> +++ b/recipes-initramfs/initramfs-factory-reset-hook/files/local-
>>> bottom-complete.tmpl
>>> @@ -0,0 +1,76 @@
>>> +#!/bin/sh
>>> +#
>>> +# CIP Core, generic profile
>>> +#
>>> +# Copyright (c) Siemens AG, 2025
>>> +#
>>> +# Authors:
>>> +#  Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>> +#
>>> +prereqs()
>>> +{
>>> +    # Make sure that this script is run last in local-top
>>
>> But it is called "local-bottom-complete"...
>>
>>> +    # but before overlay
>>> +    local req
>>> +    for req in "${0%/*}"/*; do
>>> +        script="${req##*/}"
>>> +        if [ "$script" != "${0##*/}" ] &&
>>> +            [ "$script" != "overlay" ] ; then
>>> +            printf '%s\n' "$script"
>>> +        fi
>>
>> Will create undefined dependencies between this and the crypt hook.
>> Please sort that out.
> 
> I will move this before the crypt hook for now.

Don't you need crypt to run first to unlock the data partition?

>  >> +    done
>>> +}
>>> +case $1 in
>>> +prereqs)
>>> +    prereqs
>>> +    exit 0
>>> +    ;;
>>> +esac
>>> +
>>> +. /scripts/functions
>>> +
>>> +marker="${INITRAMFS_DATA_RESET_MARKER}"
>>> +marker_storage_device="${INITRAMFS_DATA_RESET_MARKER_STORAGE_DEVICE}"
>>> +target_devices="${INITRAMFS_DATA_RESET_DEVICES}"
>>> +
>>> +storage_mnt="$(findmnt "${marker_storage_device}")"
>>> +factory_reset=false
>>
>> I thought you didn't want to call it "factory reset"?
> As the hook does not to a complete factory reset ( the disk encryption
> stays) I used data reset for now. If we add formatting a throw a way
>  the disk keys I can rename it.
> 
> 
>>
>>> +tmp_mount=$(mktemp -d)
>>> +# check for marker
>>> +if [ -z "${storage_mnt}" ]; then
>>> +    if ! mount -t "$(get_fstype "${marker_storage_device}")" \
>>> +         "${marker_storage_device}" \
>>> +         "${tmp_mount}"; then
>>> +        panic "Can't mount ${marker_storage_device}!"
>>> +    fi
>>> +    storage_mnt="$tmp_mount"
>>> +fi
>>> +if [ -e "${storage_mnt}${marker}" ]; then
>>> +    factory_reset=true
>>> +fi
>>> +if mountpoint -q "$tmp_mount"; then
>>> +    umount "$tmp_mount"
>>> +fi
>>> +if [ "${factory_reset}" = "true" ]; then
>>> +    log_begin_msg "Factory Reset"
>>> +    for target in ${target_devices}; do
>>> +        target_mnt="$(findmnt "${target}")"
>>> +        if [ -z "$target_mnt" ]; then
>>> +            if ! mount -t "$(get_fstype "${target}")" \
>>> +                 "${marker_storage_device}" \
>>> +                 "${tmp_mount}"; then
>>> +                panic "Can't mount ${target}!"
>>> +            fi
>>> +            target_mnt="$tmp_mount"
>>> +        fi
>>> +
>>> +        # delete all files in the target mount point
>>> +        find "${target_mnt}" ! -wholename "${target_mnt}" \
>>> +            ! -name "lost+found" -exec rm -rf {} +
>>
>> rm --one-file-system
>>
>> But wouldn't reformatting be simpler?
>>
> That is the question - My first thought was reformatting but then we
> lose the information from snapshot based file systems (e.g. btrfs).
> 

Which information? Aren't snapshot considered data here as well - which
we want to reset?

For a future solution that uses a/b btrfs plus some factory reset
snapshot state, this logic here will surely need adjustments. Or we
won't use the hook but rather embed related logic into some a/b data
partition hook.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center


  reply	other threads:[~2025-04-28  9:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-24  9:22 [PATCH 0/2] Add data-reset to initramfs Quirin Gylstorff
2025-04-24  9:22 ` [PATCH 1/2] initramfs: add hook for data-reset Quirin Gylstorff
2025-04-28  6:35   ` Jan Kiszka
2025-04-28  8:23     ` Quirin Gylstorff
2025-04-28  9:03       ` Jan Kiszka [this message]
2025-04-29 12:30         ` Quirin Gylstorff
2025-04-30  5:11           ` Jan Kiszka
2025-04-24  9:22 ` [PATCH 2/2] add data-reset hook to cip-core-initramfs Quirin Gylstorff

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=3d45d258-6aba-415a-b894-dae3594844ff@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=cip-dev@lists.cip-project.org \
    --cc=quirin.gylstorff@siemens.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox