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 08:35:45 +0200	[thread overview]
Message-ID: <79b2bf60-e5f3-42b6-9542-e91ba0bed677@siemens.com> (raw)
In-Reply-To: <20250424092302.2066773-2-Quirin.Gylstorff@siemens.com>

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.

> +	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"?

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

> +
> +		if mountpoint -q "$tmp_mount"; then
> +			umount "$tmp_mount"
> +		fi
> +	done
> +	log_end_msg "Factory Reset"
> +fi
> diff --git a/recipes-initramfs/initramfs-factory-reset-hook/initramfs-data-reset-hook_0.1.bb b/recipes-initramfs/initramfs-factory-reset-hook/initramfs-data-reset-hook_0.1.bb
> new file mode 100644
> index 0000000..6dfd896
> --- /dev/null
> +++ b/recipes-initramfs/initramfs-factory-reset-hook/initramfs-data-reset-hook_0.1.bb
> @@ -0,0 +1,36 @@
> +#
> +# CIP Core, generic profile
> +#
> +# Copyright (c) Siemens AG, 2025
> +#
> +# Authors:
> +#  Quirin Gylstorff <quirin.gylstorff@siemens.com>
> +#
> +# SPDX-License-Identifier: MIT
> +
> +require recipes-initramfs/initramfs-hook/hook.inc
> +SRC_URI += " \
> +    file://local-bottom-complete.tmpl"
> +
> +DESCRIPTION = "Delete the content of the given Devices"
> +
> +# if this file exists execute a factory reset for the given
> +# list of factory-reset targets.
> +INITRAMFS_DATA_RESET_MARKER ?= "/.data-reset"

Hmm, not really a working default if you have a read-only rootfs, no?

> +
> +# use labels as crypt setup replaces the label links if
> +# an partition is encrypted
> +INITRAMFS_DATA_RESET_MARKER_STORAGE_DEVICE ??= "/dev/disk/by-label/var"
> +
> +# list of partitions by label
> +INITRAMFS_DATA_RESET_DEVICES ??= "/dev/disk/by-label/var"
> +
> +TEMPLATE_FILES += "local-bottom-complete.tmpl"
> +TEMPLATE_VARS += " INITRAMFS_DATA_RESET_MARKER \
> +                   INITRAMFS_DATA_RESET_MARKER_STORAGE_DEVICE \
> +                   INITRAMFS_DATA_RESET_DEVICES"
> +
> +DEBIAN_DEPENDS .= ", coreutils, util-linux"
> +
> +HOOK_ADD_MODULES = "factory-reset"

What's that module?

> +HOOK_COPY_EXECS = "mountpoint findmnt mktemp rm find"

Should we already prepare alternative reset triggers by sticking the
file-based variant here into some callback?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center


  reply	other threads:[~2025-04-28  6:37 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 [this message]
2025-04-28  8:23     ` Quirin Gylstorff
2025-04-28  9:03       ` Jan Kiszka
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=79b2bf60-e5f3-42b6-9542-e91ba0bed677@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=Quirin.Gylstorff@siemens.com \
    --cc=cip-dev@lists.cip-project.org \
    /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