* [RFC PATCH] classes: Add initramfs class
@ 2020-09-21 10:42 Harald Seiler
2020-09-21 19:25 ` Jan Kiszka
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Harald Seiler @ 2020-09-21 10:42 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler
Add a new "image" class for generating a custom initramfs. It works
like this: A new minimal debian rootfs is bootstrapped and all
dependency packages for the new initramfs are installed. Then, an
initramfs is generated from this rootfs and deployed like usual.
This new initramfs.bbclass "image" class should be pulled in by an
"initramfs image" recipe. Said recipe then specifies all dependencies
of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
are analogous to the respective IMAGE_* variables).
initramfs.bbclass intentionally does _not_ expose a mechanism to change
/etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
Changes to their settings are better done via packages that deploy
conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
fragment files to /usr/share/initramfs-tools/modules.d/.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
I had this idea while searching for a way to build an initramfs that
uses dm-verity to assert integrity of the rootfs. To me, this feels
like a much cleaner solution than anything else I tried and I'm happy to
report that, using this approach, I got everything working nicely in the
original project.
In my opinion, this design has a number of advantages over the previous
solutions we have seen so far:
- It does not suffer any kind of initramfs pollution, caused by
packages installed into a rootfs. This is a big problem when trying
to generated an initramfs from e.g. `buildchroot-target` as many
unrelated packaged could be installed there which would all get
pulled into the initrd (if they install hooks/scripts).
This also means, with this new approach, the integrator has maximum
control over the contents of the initramfs.
- There are no needs to change the initramfs generation process in any
way, the debian tooling can be used exactly like its meant to.
- As most isar-generated images will never regenerate the initramfs
from the running system, all initramfs related packages are dead-weight
to the image. This is a problem when trying to generate the initramfs
from the actual image rootfs.
When it is necessary to rebuild the initramfs in a running system,
the packages designed for this new class could just be installed into
the rootfs, without any changes necessary. This means, any generic
initramfs module packages can be used both with the in-rootfs mechanism
and initramfs.bbclass.
- Because of this complete isolation and independence, implementation
of complex logic is much easier: For example dm-verity needs
a root-hash that is only available after the rootfs has been cast into
a filesystem image. With this new approach, this can be modelled with
a simple task dependency.
meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 meta/classes/initramfs.bbclass
diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
new file mode 100644
index 000000000000..8af9b4b379a5
--- /dev/null
+++ b/meta/classes/initramfs.bbclass
@@ -0,0 +1,41 @@
+# This software is a part of ISAR.
+
+# Make workdir and stamps machine-specific without changing common PN target
+WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
+
+INITRAMFS_INSTALL ?= ""
+INITRAMFS_PREINSTALL ?= ""
+INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
+INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
+
+# Install proper kernel
+INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
+
+# Name of the initramfs including distro&machine names
+INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
+
+DEPENDS += "${INITRAMFS_INSTALL}"
+
+ROOTFSDIR = "${INITRAMFS_ROOTFS}"
+ROOTFS_FEATURES = ""
+ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
+
+inherit rootfs
+
+do_generate_initramfs() {
+ rootfs_do_mounts
+ rootfs_do_qemu
+
+ sudo -E chroot "${INITRAMFS_ROOTFS}" \
+ update-initramfs -u -v
+
+ if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
+ die "No initramfs was found after generation!"
+ fi
+
+ rm -rf "${INITRAMFS_IMAGE_FILE}"
+ cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
+}
+addtask generate_initramfs after do_rootfs before do_build
--
2.26.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] classes: Add initramfs class
2020-09-21 10:42 [RFC PATCH] classes: Add initramfs class Harald Seiler
@ 2020-09-21 19:25 ` Jan Kiszka
2020-09-22 10:34 ` Harald Seiler
2020-09-22 12:10 ` Gylstorff Quirin
2020-09-23 16:20 ` [PATCH v2 1/3] " Harald Seiler
` (2 subsequent siblings)
3 siblings, 2 replies; 19+ messages in thread
From: Jan Kiszka @ 2020-09-21 19:25 UTC (permalink / raw)
To: Harald Seiler, isar-users, Quirin Gylstorff
On 21.09.20 12:42, Harald Seiler wrote:
> Add a new "image" class for generating a custom initramfs. It works
> like this: A new minimal debian rootfs is bootstrapped and all
> dependency packages for the new initramfs are installed. Then, an
> initramfs is generated from this rootfs and deployed like usual.
>
> This new initramfs.bbclass "image" class should be pulled in by an
> "initramfs image" recipe. Said recipe then specifies all dependencies
> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> are analogous to the respective IMAGE_* variables).
>
> initramfs.bbclass intentionally does _not_ expose a mechanism to change
> /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
> Changes to their settings are better done via packages that deploy
> conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
> fragment files to /usr/share/initramfs-tools/modules.d/.
>
> Signed-off-by: Harald Seiler <hws@denx.de>
> ---
>
> Notes:
> I had this idea while searching for a way to build an initramfs that
> uses dm-verity to assert integrity of the rootfs. To me, this feels
> like a much cleaner solution than anything else I tried and I'm happy to
> report that, using this approach, I got everything working nicely in the
> original project.
>
> In my opinion, this design has a number of advantages over the previous
> solutions we have seen so far:
>
> - It does not suffer any kind of initramfs pollution, caused by
> packages installed into a rootfs. This is a big problem when trying
> to generated an initramfs from e.g. `buildchroot-target` as many
> unrelated packaged could be installed there which would all get
> pulled into the initrd (if they install hooks/scripts).
>
> This also means, with this new approach, the integrator has maximum
> control over the contents of the initramfs.
>
> - There are no needs to change the initramfs generation process in any
> way, the debian tooling can be used exactly like its meant to.
>
> - As most isar-generated images will never regenerate the initramfs
> from the running system, all initramfs related packages are dead-weight
> to the image. This is a problem when trying to generate the initramfs
> from the actual image rootfs.
>
> When it is necessary to rebuild the initramfs in a running system,
> the packages designed for this new class could just be installed into
> the rootfs, without any changes necessary. This means, any generic
> initramfs module packages can be used both with the in-rootfs mechanism
> and initramfs.bbclass.
>
> - Because of this complete isolation and independence, implementation
> of complex logic is much easier: For example dm-verity needs
> a root-hash that is only available after the rootfs has been cast into
> a filesystem image. With this new approach, this can be modelled with
> a simple task dependency.
>
> meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 meta/classes/initramfs.bbclass
>
> diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
> new file mode 100644
> index 000000000000..8af9b4b379a5
> --- /dev/null
> +++ b/meta/classes/initramfs.bbclass
> @@ -0,0 +1,41 @@
> +# This software is a part of ISAR.
> +
> +# Make workdir and stamps machine-specific without changing common PN target
> +WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
> +
> +INITRAMFS_INSTALL ?= ""
> +INITRAMFS_PREINSTALL ?= ""
> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
> +INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
> +
> +# Install proper kernel
> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
> +
> +# Name of the initramfs including distro&machine names
> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> +
> +DEPENDS += "${INITRAMFS_INSTALL}"
> +
> +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> +ROOTFS_FEATURES = ""
> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
> +
> +inherit rootfs
> +
> +do_generate_initramfs() {
> + rootfs_do_mounts
> + rootfs_do_qemu
> +
> + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> + update-initramfs -u -v
> +
> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> + die "No initramfs was found after generation!"
> + fi
> +
> + rm -rf "${INITRAMFS_IMAGE_FILE}"
> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
> +}
> +addtask generate_initramfs after do_rootfs before do_build
>
I think the public would also benefit from a use / test case, i.e. some
recipe that inherits this and generates an own initramfs with
extensions. For merging this, that will be mandatory anyway.
Quirin, what is your impression of this approach?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] classes: Add initramfs class
2020-09-21 19:25 ` Jan Kiszka
@ 2020-09-22 10:34 ` Harald Seiler
2020-09-22 11:04 ` Jan Kiszka
2020-09-22 12:10 ` Gylstorff Quirin
1 sibling, 1 reply; 19+ messages in thread
From: Harald Seiler @ 2020-09-22 10:34 UTC (permalink / raw)
To: Jan Kiszka, isar-users; +Cc: Quirin Gylstorff
On Mon, 2020-09-21 at 21:25 +0200, Jan Kiszka wrote:
> On 21.09.20 12:42, Harald Seiler wrote:
> > Add a new "image" class for generating a custom initramfs. It works
> > like this: A new minimal debian rootfs is bootstrapped and all
> > dependency packages for the new initramfs are installed. Then, an
> > initramfs is generated from this rootfs and deployed like usual.
> >
> > This new initramfs.bbclass "image" class should be pulled in by an
> > "initramfs image" recipe. Said recipe then specifies all dependencies
> > of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> > are analogous to the respective IMAGE_* variables).
> >
> > initramfs.bbclass intentionally does _not_ expose a mechanism to change
> > /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
> > Changes to their settings are better done via packages that deploy
> > conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
> > fragment files to /usr/share/initramfs-tools/modules.d/.
> >
> > Signed-off-by: Harald Seiler <hws@denx.de>
> > ---
> >
> > Notes:
> > I had this idea while searching for a way to build an initramfs that
> > uses dm-verity to assert integrity of the rootfs. To me, this feels
> > like a much cleaner solution than anything else I tried and I'm happy to
> > report that, using this approach, I got everything working nicely in the
> > original project.
> >
> > In my opinion, this design has a number of advantages over the previous
> > solutions we have seen so far:
> >
> > - It does not suffer any kind of initramfs pollution, caused by
> > packages installed into a rootfs. This is a big problem when trying
> > to generated an initramfs from e.g. `buildchroot-target` as many
> > unrelated packaged could be installed there which would all get
> > pulled into the initrd (if they install hooks/scripts).
> >
> > This also means, with this new approach, the integrator has maximum
> > control over the contents of the initramfs.
> >
> > - There are no needs to change the initramfs generation process in any
> > way, the debian tooling can be used exactly like its meant to.
> >
> > - As most isar-generated images will never regenerate the initramfs
> > from the running system, all initramfs related packages are dead-weight
> > to the image. This is a problem when trying to generate the initramfs
> > from the actual image rootfs.
> >
> > When it is necessary to rebuild the initramfs in a running system,
> > the packages designed for this new class could just be installed into
> > the rootfs, without any changes necessary. This means, any generic
> > initramfs module packages can be used both with the in-rootfs mechanism
> > and initramfs.bbclass.
> >
> > - Because of this complete isolation and independence, implementation
> > of complex logic is much easier: For example dm-verity needs
> > a root-hash that is only available after the rootfs has been cast into
> > a filesystem image. With this new approach, this can be modelled with
> > a simple task dependency.
> >
> > meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 41 insertions(+)
> > create mode 100644 meta/classes/initramfs.bbclass
> >
> > diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
> > new file mode 100644
> > index 000000000000..8af9b4b379a5
> > --- /dev/null
> > +++ b/meta/classes/initramfs.bbclass
> > @@ -0,0 +1,41 @@
> > +# This software is a part of ISAR.
> > +
> > +# Make workdir and stamps machine-specific without changing common PN target
> > +WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > +STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > +STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
> > +
> > +INITRAMFS_INSTALL ?= ""
> > +INITRAMFS_PREINSTALL ?= ""
> > +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
> > +INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
> > +
> > +# Install proper kernel
> > +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
> > +
> > +# Name of the initramfs including distro&machine names
> > +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> > +
> > +DEPENDS += "${INITRAMFS_INSTALL}"
> > +
> > +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> > +ROOTFS_FEATURES = ""
> > +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
> > +
> > +inherit rootfs
> > +
> > +do_generate_initramfs() {
> > + rootfs_do_mounts
> > + rootfs_do_qemu
> > +
> > + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> > + update-initramfs -u -v
> > +
> > + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> > + die "No initramfs was found after generation!"
> > + fi
> > +
> > + rm -rf "${INITRAMFS_IMAGE_FILE}"
> > + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
> > +}
> > +addtask generate_initramfs after do_rootfs before do_build
> >
>
> I think the public would also benefit from a use / test case, i.e. some
> recipe that inherits this and generates an own initramfs with
> extensions. For merging this, that will be mandatory anyway.
Makes sense. What do you think would be a good and upstream-viable
example for this? I can't think of anything trivial _and_ generic that
would still be a sensible use-case - the whole reason for this bbclass is
cases where the a custom initramfs is needed, after all ...
One idea would be to get the remaining dm-verity recipes upstream as well.
This would definitely be quite a bit of work as the ones I have right now
are not entirely generic yet ... Though you mentioned that you're
interested in making them available at some point anyway, so maybe this is
the way to go?
Otherwise (or in addition), I could add a dummy recipe that e.g. just
prints something during boot to meta-isar, to show how it works ...
--
Harald
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] classes: Add initramfs class
2020-09-22 10:34 ` Harald Seiler
@ 2020-09-22 11:04 ` Jan Kiszka
0 siblings, 0 replies; 19+ messages in thread
From: Jan Kiszka @ 2020-09-22 11:04 UTC (permalink / raw)
To: Harald Seiler, isar-users; +Cc: Quirin Gylstorff
On 22.09.20 12:34, Harald Seiler wrote:
> On Mon, 2020-09-21 at 21:25 +0200, Jan Kiszka wrote:
>> On 21.09.20 12:42, Harald Seiler wrote:
>>> Add a new "image" class for generating a custom initramfs. It works
>>> like this: A new minimal debian rootfs is bootstrapped and all
>>> dependency packages for the new initramfs are installed. Then, an
>>> initramfs is generated from this rootfs and deployed like usual.
>>>
>>> This new initramfs.bbclass "image" class should be pulled in by an
>>> "initramfs image" recipe. Said recipe then specifies all dependencies
>>> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
>>> are analogous to the respective IMAGE_* variables).
>>>
>>> initramfs.bbclass intentionally does _not_ expose a mechanism to change
>>> /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
>>> Changes to their settings are better done via packages that deploy
>>> conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
>>> fragment files to /usr/share/initramfs-tools/modules.d/.
>>>
>>> Signed-off-by: Harald Seiler <hws@denx.de>
>>> ---
>>>
>>> Notes:
>>> I had this idea while searching for a way to build an initramfs that
>>> uses dm-verity to assert integrity of the rootfs. To me, this feels
>>> like a much cleaner solution than anything else I tried and I'm happy to
>>> report that, using this approach, I got everything working nicely in the
>>> original project.
>>>
>>> In my opinion, this design has a number of advantages over the previous
>>> solutions we have seen so far:
>>>
>>> - It does not suffer any kind of initramfs pollution, caused by
>>> packages installed into a rootfs. This is a big problem when trying
>>> to generated an initramfs from e.g. `buildchroot-target` as many
>>> unrelated packaged could be installed there which would all get
>>> pulled into the initrd (if they install hooks/scripts).
>>>
>>> This also means, with this new approach, the integrator has maximum
>>> control over the contents of the initramfs.
>>>
>>> - There are no needs to change the initramfs generation process in any
>>> way, the debian tooling can be used exactly like its meant to.
>>>
>>> - As most isar-generated images will never regenerate the initramfs
>>> from the running system, all initramfs related packages are dead-weight
>>> to the image. This is a problem when trying to generate the initramfs
>>> from the actual image rootfs.
>>>
>>> When it is necessary to rebuild the initramfs in a running system,
>>> the packages designed for this new class could just be installed into
>>> the rootfs, without any changes necessary. This means, any generic
>>> initramfs module packages can be used both with the in-rootfs mechanism
>>> and initramfs.bbclass.
>>>
>>> - Because of this complete isolation and independence, implementation
>>> of complex logic is much easier: For example dm-verity needs
>>> a root-hash that is only available after the rootfs has been cast into
>>> a filesystem image. With this new approach, this can be modelled with
>>> a simple task dependency.
>>>
>>> meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
>>> 1 file changed, 41 insertions(+)
>>> create mode 100644 meta/classes/initramfs.bbclass
>>>
>>> diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
>>> new file mode 100644
>>> index 000000000000..8af9b4b379a5
>>> --- /dev/null
>>> +++ b/meta/classes/initramfs.bbclass
>>> @@ -0,0 +1,41 @@
>>> +# This software is a part of ISAR.
>>> +
>>> +# Make workdir and stamps machine-specific without changing common PN target
>>> +WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
>>> +STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
>>> +STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
>>> +
>>> +INITRAMFS_INSTALL ?= ""
>>> +INITRAMFS_PREINSTALL ?= ""
>>> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
>>> +INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
>>> +
>>> +# Install proper kernel
>>> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
>>> +
>>> +# Name of the initramfs including distro&machine names
>>> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
>>> +
>>> +DEPENDS += "${INITRAMFS_INSTALL}"
>>> +
>>> +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
>>> +ROOTFS_FEATURES = ""
>>> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
>>> +
>>> +inherit rootfs
>>> +
>>> +do_generate_initramfs() {
>>> + rootfs_do_mounts
>>> + rootfs_do_qemu
>>> +
>>> + sudo -E chroot "${INITRAMFS_ROOTFS}" \
>>> + update-initramfs -u -v
>>> +
>>> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
>>> + die "No initramfs was found after generation!"
>>> + fi
>>> +
>>> + rm -rf "${INITRAMFS_IMAGE_FILE}"
>>> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
>>> +}
>>> +addtask generate_initramfs after do_rootfs before do_build
>>>
>>
>> I think the public would also benefit from a use / test case, i.e. some
>> recipe that inherits this and generates an own initramfs with
>> extensions. For merging this, that will be mandatory anyway.
>
> Makes sense. What do you think would be a good and upstream-viable
> example for this? I can't think of anything trivial _and_ generic that
> would still be a sensible use-case - the whole reason for this bbclass is
> cases where the a custom initramfs is needed, after all ...
>
> One idea would be to get the remaining dm-verity recipes upstream as well.
> This would definitely be quite a bit of work as the ones I have right now
> are not entirely generic yet ... Though you mentioned that you're
> interested in making them available at some point anyway, so maybe this is
> the way to go?
>
> Otherwise (or in addition), I could add a dummy recipe that e.g. just
> prints something during boot to meta-isar, to show how it works ...
>
That would have been exactly my suggestion as well. Can still be
replaced later on when we upstream things like dm-verity generation.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] classes: Add initramfs class
2020-09-21 19:25 ` Jan Kiszka
2020-09-22 10:34 ` Harald Seiler
@ 2020-09-22 12:10 ` Gylstorff Quirin
2020-09-22 12:18 ` Harald Seiler
1 sibling, 1 reply; 19+ messages in thread
From: Gylstorff Quirin @ 2020-09-22 12:10 UTC (permalink / raw)
To: Jan Kiszka, Harald Seiler, isar-users
On 9/21/20 9:25 PM, Jan Kiszka wrote:
> On 21.09.20 12:42, Harald Seiler wrote:
>> Add a new "image" class for generating a custom initramfs. It works
>> like this: A new minimal debian rootfs is bootstrapped and all
>> dependency packages for the new initramfs are installed. Then, an
>> initramfs is generated from this rootfs and deployed like usual.
>>
>> This new initramfs.bbclass "image" class should be pulled in by an
>> "initramfs image" recipe. Said recipe then specifies all dependencies
>> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
>> are analogous to the respective IMAGE_* variables).
>>
>> initramfs.bbclass intentionally does _not_ expose a mechanism to change
>> /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
>> Changes to their settings are better done via packages that deploy
>> conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
>> fragment files to /usr/share/initramfs-tools/modules.d/.
>>
>> Signed-off-by: Harald Seiler <hws@denx.de>
>> ---
>>
>> Notes:
>> I had this idea while searching for a way to build an initramfs that
>> uses dm-verity to assert integrity of the rootfs. To me, this feels
>> like a much cleaner solution than anything else I tried and I'm
>> happy to
>> report that, using this approach, I got everything working nicely
>> in the
>> original project.
>> In my opinion, this design has a number of advantages over the
>> previous
>> solutions we have seen so far:
>> - It does not suffer any kind of initramfs pollution, caused by
>> packages installed into a rootfs. This is a big problem when
>> trying
>> to generated an initramfs from e.g. `buildchroot-target` as many
>> unrelated packaged could be installed there which would all get
>> pulled into the initrd (if they install hooks/scripts).
>> This also means, with this new approach, the integrator has
>> maximum
>> control over the contents of the initramfs.
>> - There are no needs to change the initramfs generation process
>> in any
>> way, the debian tooling can be used exactly like its meant to.
>> - As most isar-generated images will never regenerate the initramfs
>> from the running system, all initramfs related packages are
>> dead-weight
>> to the image. This is a problem when trying to generate the
>> initramfs
>> from the actual image rootfs.
>> When it is necessary to rebuild the initramfs in a running
>> system,
>> the packages designed for this new class could just be
>> installed into
>> the rootfs, without any changes necessary. This means, any
>> generic
>> initramfs module packages can be used both with the in-rootfs
>> mechanism
>> and initramfs.bbclass.
>> - Because of this complete isolation and independence,
>> implementation
>> of complex logic is much easier: For example dm-verity needs
>> a root-hash that is only available after the rootfs has been
>> cast into
>> a filesystem image. With this new approach, this can be
>> modelled with
>> a simple task dependency.
>>
>> meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>> create mode 100644 meta/classes/initramfs.bbclass
>>
>> diff --git a/meta/classes/initramfs.bbclass
>> b/meta/classes/initramfs.bbclass
>> new file mode 100644
>> index 000000000000..8af9b4b379a5
>> --- /dev/null
>> +++ b/meta/classes/initramfs.bbclass
>> @@ -0,0 +1,41 @@
>> +# This software is a part of ISAR.
>> +
>> +# Make workdir and stamps machine-specific without changing common PN
>> target
>> +WORKDIR =
>> "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
>> +STAMP =
>> "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
>> +STAMPCLEAN =
>> "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
>> +
>> +INITRAMFS_INSTALL ?= ""
>> +INITRAMFS_PREINSTALL ?= ""
>> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
>> +INITRAMFS_IMAGE_FILE =
>> "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
>> +
>> +# Install proper kernel
>> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME",
>> True)) if d.getVar("KERNEL_NAME", True) else ""}"
>> +
>> +# Name of the initramfs including distro&machine names
>> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
>> +
>> +DEPENDS += "${INITRAMFS_INSTALL}"
>> +
>> +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
>> +ROOTFS_FEATURES = ""
>> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL}
>> ${INITRAMFS_INSTALL}"
>> +
>> +inherit rootfs
>> +
>> +do_generate_initramfs() {
>> + rootfs_do_mounts
>> + rootfs_do_qemu
>> +
>> + sudo -E chroot "${INITRAMFS_ROOTFS}" \
>> + update-initramfs -u -v
>> +
>> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
>> + die "No initramfs was found after generation!"
>> + fi
>> +
>> + rm -rf "${INITRAMFS_IMAGE_FILE}"
>> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
>> +}
>> +addtask generate_initramfs after do_rootfs before do_build
>>
>
> I think the public would also benefit from a use / test case, i.e. some
> recipe that inherits this and generates an own initramfs with
> extensions. For merging this, that will be mandatory anyway.
>
> Quirin, what is your impression of this approach?
>
> Jan
>
From the first look of it, looks good to me.
Did you test what happens if you try to install a custom kernel module?
--
Quirin
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH] classes: Add initramfs class
2020-09-22 12:10 ` Gylstorff Quirin
@ 2020-09-22 12:18 ` Harald Seiler
0 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2020-09-22 12:18 UTC (permalink / raw)
To: Gylstorff Quirin, Jan Kiszka, isar-users
Hi,
On Tue, 2020-09-22 at 14:10 +0200, Gylstorff Quirin wrote:
>
> On 9/21/20 9:25 PM, Jan Kiszka wrote:
> > On 21.09.20 12:42, Harald Seiler wrote:
> > > Add a new "image" class for generating a custom initramfs. It works
> > > like this: A new minimal debian rootfs is bootstrapped and all
> > > dependency packages for the new initramfs are installed. Then, an
> > > initramfs is generated from this rootfs and deployed like usual.
> > >
> > > This new initramfs.bbclass "image" class should be pulled in by an
> > > "initramfs image" recipe. Said recipe then specifies all dependencies
> > > of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> > > are analogous to the respective IMAGE_* variables).
> > >
> > > initramfs.bbclass intentionally does _not_ expose a mechanism to change
> > > /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
> > > Changes to their settings are better done via packages that deploy
> > > conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
> > > fragment files to /usr/share/initramfs-tools/modules.d/.
> > >
> > > Signed-off-by: Harald Seiler <hws@denx.de>
> > > ---
> > >
> > > Notes:
> > > I had this idea while searching for a way to build an initramfs that
> > > uses dm-verity to assert integrity of the rootfs. To me, this feels
> > > like a much cleaner solution than anything else I tried and I'm
> > > happy to
> > > report that, using this approach, I got everything working nicely
> > > in the
> > > original project.
> > > In my opinion, this design has a number of advantages over the
> > > previous
> > > solutions we have seen so far:
> > > - It does not suffer any kind of initramfs pollution, caused by
> > > packages installed into a rootfs. This is a big problem when
> > > trying
> > > to generated an initramfs from e.g. `buildchroot-target` as many
> > > unrelated packaged could be installed there which would all get
> > > pulled into the initrd (if they install hooks/scripts).
> > > This also means, with this new approach, the integrator has
> > > maximum
> > > control over the contents of the initramfs.
> > > - There are no needs to change the initramfs generation process
> > > in any
> > > way, the debian tooling can be used exactly like its meant to.
> > > - As most isar-generated images will never regenerate the initramfs
> > > from the running system, all initramfs related packages are
> > > dead-weight
> > > to the image. This is a problem when trying to generate the
> > > initramfs
> > > from the actual image rootfs.
> > > When it is necessary to rebuild the initramfs in a running
> > > system,
> > > the packages designed for this new class could just be
> > > installed into
> > > the rootfs, without any changes necessary. This means, any
> > > generic
> > > initramfs module packages can be used both with the in-rootfs
> > > mechanism
> > > and initramfs.bbclass.
> > > - Because of this complete isolation and independence,
> > > implementation
> > > of complex logic is much easier: For example dm-verity needs
> > > a root-hash that is only available after the rootfs has been
> > > cast into
> > > a filesystem image. With this new approach, this can be
> > > modelled with
> > > a simple task dependency.
> > >
> > > meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
> > > 1 file changed, 41 insertions(+)
> > > create mode 100644 meta/classes/initramfs.bbclass
> > >
> > > diff --git a/meta/classes/initramfs.bbclass
> > > b/meta/classes/initramfs.bbclass
> > > new file mode 100644
> > > index 000000000000..8af9b4b379a5
> > > --- /dev/null
> > > +++ b/meta/classes/initramfs.bbclass
> > > @@ -0,0 +1,41 @@
> > > +# This software is a part of ISAR.
> > > +
> > > +# Make workdir and stamps machine-specific without changing common PN
> > > target
> > > +WORKDIR =
> > > "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > > +STAMP =
> > > "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > > +STAMPCLEAN =
> > > "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
> > > +
> > > +INITRAMFS_INSTALL ?= ""
> > > +INITRAMFS_PREINSTALL ?= ""
> > > +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
> > > +INITRAMFS_IMAGE_FILE =
> > > "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
> > > +
> > > +# Install proper kernel
> > > +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME",
> > > True)) if d.getVar("KERNEL_NAME", True) else ""}"
> > > +
> > > +# Name of the initramfs including distro&machine names
> > > +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> > > +
> > > +DEPENDS += "${INITRAMFS_INSTALL}"
> > > +
> > > +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> > > +ROOTFS_FEATURES = ""
> > > +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL}
> > > ${INITRAMFS_INSTALL}"
> > > +
> > > +inherit rootfs
> > > +
> > > +do_generate_initramfs() {
> > > + rootfs_do_mounts
> > > + rootfs_do_qemu
> > > +
> > > + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> > > + update-initramfs -u -v
> > > +
> > > + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> > > + die "No initramfs was found after generation!"
> > > + fi
> > > +
> > > + rm -rf "${INITRAMFS_IMAGE_FILE}"
> > > + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
> > > +}
> > > +addtask generate_initramfs after do_rootfs before do_build
> > >
> >
> > I think the public would also benefit from a use / test case, i.e. some
> > recipe that inherits this and generates an own initramfs with
> > extensions. For merging this, that will be mandatory anyway.
> >
> > Quirin, what is your impression of this approach?
> >
> > Jan
> >
>
> From the first look of it, looks good to me.
>
> Did you test what happens if you try to install a custom kernel module?
You'll need to add the package for the custom module to INITRAMFS_INSTALL
or INITRAMFS_PREINSTALL as well of course. If you do that, I don't see
a reason why it shouldn't work (that would be a bug) but I did not test
this so far.
--
Harald
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 1/3] classes: Add initramfs class
2020-09-21 10:42 [RFC PATCH] classes: Add initramfs class Harald Seiler
2020-09-21 19:25 ` Jan Kiszka
@ 2020-09-23 16:20 ` Harald Seiler
2020-09-25 13:16 ` Henning Schild
2020-09-23 16:20 ` [PATCH v2 2/3] Add example initramfs module recipe Harald Seiler
2020-09-23 16:20 ` [PATCH v2 3/3] Add custom isar-initramfs example Harald Seiler
3 siblings, 1 reply; 19+ messages in thread
From: Harald Seiler @ 2020-09-23 16:20 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler
Add a new "image" class for generating a custom initramfs. It works
like this: A new minimal debian rootfs is bootstrapped and all
dependency packages for the new initramfs are installed. Then, an
initramfs is generated from this rootfs and deployed like usual.
This new initramfs.bbclass "image" class should be pulled in by an
"initramfs image" recipe. Said recipe then specifies all dependencies
of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
are analogous to the respective IMAGE_* variables).
initramfs.bbclass intentionally does _not_ expose a mechanism to change
/etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
Changes to their settings are better done via packages that deploy
conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
fragment files to /usr/share/initramfs-tools/modules.d/.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
I had this idea while searching for a way to build an initramfs that
uses dm-verity to assert integrity of the rootfs. To me, this feels
like a much cleaner solution than anything else I tried and I'm happy to
report that, using this approach, I got everything working nicely in the
original project.
In my opinion, this design has a number of advantages over the previous
solutions we have seen so far:
- It does not suffer any kind of initramfs pollution, caused by
packages installed into a rootfs. This is a big problem when trying
to generated an initramfs from e.g. `buildchroot-target` as many
unrelated packaged could be installed there which would all get
pulled into the initrd (if they install hooks/scripts).
This also means, with this new approach, the integrator has maximum
control over the contents of the initramfs.
- There are no needs to change the initramfs generation process in any
way, the debian tooling can be used exactly like its meant to.
- As most isar-generated images will never regenerate the initramfs
from the running system, all initramfs related packages are dead-weight
to the image. This is a problem when trying to generate the initramfs
from the actual image rootfs.
When it is necessary to rebuild the initramfs in a running system,
the packages designed for this new class could just be installed into
the rootfs, without any changes necessary. This means, any generic
initramfs module packages can be used both with the in-rootfs mechanism
and initramfs.bbclass.
- Because of this complete isolation and independence, implementation
of complex logic is much easier: For example dm-verity needs
a root-hash that is only available after the rootfs has been cast into
a filesystem image. With this new approach, this can be modelled with
a simple task dependency.
Changes in v2:
- None (just added examples in new patches)
meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 meta/classes/initramfs.bbclass
diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
new file mode 100644
index 000000000000..8af9b4b379a5
--- /dev/null
+++ b/meta/classes/initramfs.bbclass
@@ -0,0 +1,41 @@
+# This software is a part of ISAR.
+
+# Make workdir and stamps machine-specific without changing common PN target
+WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
+
+INITRAMFS_INSTALL ?= ""
+INITRAMFS_PREINSTALL ?= ""
+INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
+INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
+
+# Install proper kernel
+INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
+
+# Name of the initramfs including distro&machine names
+INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
+
+DEPENDS += "${INITRAMFS_INSTALL}"
+
+ROOTFSDIR = "${INITRAMFS_ROOTFS}"
+ROOTFS_FEATURES = ""
+ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
+
+inherit rootfs
+
+do_generate_initramfs() {
+ rootfs_do_mounts
+ rootfs_do_qemu
+
+ sudo -E chroot "${INITRAMFS_ROOTFS}" \
+ update-initramfs -u -v
+
+ if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
+ die "No initramfs was found after generation!"
+ fi
+
+ rm -rf "${INITRAMFS_IMAGE_FILE}"
+ cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
+}
+addtask generate_initramfs after do_rootfs before do_build
--
2.26.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 2/3] Add example initramfs module recipe
2020-09-21 10:42 [RFC PATCH] classes: Add initramfs class Harald Seiler
2020-09-21 19:25 ` Jan Kiszka
2020-09-23 16:20 ` [PATCH v2 1/3] " Harald Seiler
@ 2020-09-23 16:20 ` Harald Seiler
2020-09-23 16:20 ` [PATCH v2 3/3] Add custom isar-initramfs example Harald Seiler
3 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2020-09-23 16:20 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler
Add the initramfs-example recipe/package which demonstrates how to write
initramfs modules. It demonstrates how to add hook scripts, boot scripts,
and conf-hooks.
Signed-off-by: Harald Seiler <hws@denx.de>
---
.../initramfs-example/files/example.conf-hook | 7 ++++
.../initramfs-example/files/example.hook | 19 +++++++++
.../initramfs-example/files/example.script | 21 ++++++++++
.../initramfs-example/initramfs-example.bb | 40 +++++++++++++++++++
4 files changed, 87 insertions(+)
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.hook
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.script
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook b/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
new file mode 100644
index 000000000000..2a3cf7a84040
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
@@ -0,0 +1,7 @@
+# Example conf-hook.
+#
+# See "CONFIGURATION HOOK SCRIPTS" in initramfs-tools(7) for details.
+
+# Example: Use busybox instead of klibc-utils. The package must also add
+# `busybox` as a dependency when this is set.
+BUSYBOX=y
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.hook b/meta-isar/recipes-initramfs/initramfs-example/files/example.hook
new file mode 100644
index 000000000000..0d84e7a97efd
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.hook
@@ -0,0 +1,19 @@
+#!/bin/sh
+# Example hook script.
+#
+# See "HOOK SCRIPTS" in initramfs-tools(7) for details.
+
+PREREQ=""
+prereqs()
+{
+ echo "$PREREQ"
+}
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+# Begin real processing below this line
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.script b/meta-isar/recipes-initramfs/initramfs-example/files/example.script
new file mode 100644
index 000000000000..784fad9c99bb
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.script
@@ -0,0 +1,21 @@
+#!/bin/sh
+# Example boot script.
+#
+# See "BOOT SCRIPTS" in initramfs-tools(7) for details.
+
+PREREQ=""
+prereqs()
+{
+ echo "$PREREQ"
+}
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /scripts/functions
+# Begin real processing below this line
+
+log_success_msg "Hello from ISAR!"
diff --git a/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb b/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
new file mode 100644
index 000000000000..c336dda92b5d
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
@@ -0,0 +1,40 @@
+# Example of a recipe containing an initramfs module. Packages like this can be
+# used with initramfs.bbclass or installed directly into a rootfs, depending on
+# the usecase.
+#
+# This software is a part of ISAR.
+
+DESCRIPTION = "Sample initramfs module for ISAR"
+MAINTAINER = "Your name here <you@domain.com>"
+DEBIAN_DEPENDS = "initramfs-tools"
+
+# If the conf-hook enables BUSYBOX=y, busybox is needed:
+DEBIAN_DEPENDS .= ", busybox"
+
+SRC_URI = " \
+ file://example.conf-hook \
+ file://example.hook \
+ file://example.script \
+ "
+
+inherit dpkg-raw
+
+do_install[cleandirs] += " \
+ ${D}/usr/share/initramfs-tools/conf-hooks.d \
+ ${D}/usr/share/initramfs-tools/hooks \
+ ${D}/usr/share/initramfs-tools/scripts/local-top \
+ "
+do_install() {
+ # See "CONFIGURATION HOOK SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.conf-hook" \
+ "${D}/usr/share/initramfs-tools/conf-hooks.d/isar-example"
+
+ # See "HOOK SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.hook" \
+ "${D}/usr/share/initramfs-tools/hooks/isar-example"
+
+ # Note that there are other places where a boot script might be deployed to,
+ # apart from local-top. See "BOOT SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.script" \
+ "${D}/usr/share/initramfs-tools/scripts/local-top/example.script"
+}
--
2.26.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v2 3/3] Add custom isar-initramfs example
2020-09-21 10:42 [RFC PATCH] classes: Add initramfs class Harald Seiler
` (2 preceding siblings ...)
2020-09-23 16:20 ` [PATCH v2 2/3] Add example initramfs module recipe Harald Seiler
@ 2020-09-23 16:20 ` Harald Seiler
2020-09-25 9:13 ` Jan Kiszka
3 siblings, 1 reply; 19+ messages in thread
From: Harald Seiler @ 2020-09-23 16:20 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler
isar-initramfs is a custom initramfs which additionally has the
initramfs-example module installed.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
Maybe this initramfs should be tested in CI somewhere? I'm unsure what
makes sense, and how to "force" this custom initramfs into a CI target.
.../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb
diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
new file mode 100644
index 000000000000..aaa0350aab20
--- /dev/null
+++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
@@ -0,0 +1,18 @@
+# Example of a custom initramfs image recipe. The image will be deployed to
+#
+# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img
+#
+# This software is a part of ISAR.
+
+inherit initramfs
+
+# Debian packages that should be installed into the system for building the
+# initramfs. E.g. the cryptsetup package which contains initramfs scripts for
+# decrypting a root filesystem.
+INITRAMFS_PREINSTALL += " \
+ "
+
+# Recipes that should be installed into the initramfs build rootfs.
+INITRAMFS_INSTALL += " \
+ initramfs-example \
+ "
--
2.26.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 3/3] Add custom isar-initramfs example
2020-09-23 16:20 ` [PATCH v2 3/3] Add custom isar-initramfs example Harald Seiler
@ 2020-09-25 9:13 ` Jan Kiszka
2020-09-25 11:28 ` Harald Seiler
0 siblings, 1 reply; 19+ messages in thread
From: Jan Kiszka @ 2020-09-25 9:13 UTC (permalink / raw)
To: Harald Seiler, isar-users
On 23.09.20 18:20, Harald Seiler wrote:
> isar-initramfs is a custom initramfs which additionally has the
> initramfs-example module installed.
>
> Signed-off-by: Harald Seiler <hws@denx.de>
> ---
>
> Notes:
> Maybe this initramfs should be tested in CI somewhere? I'm unsure what
> makes sense, and how to "force" this custom initramfs into a CI target.
>
> .../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
> create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb
>
> diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
> new file mode 100644
> index 000000000000..aaa0350aab20
> --- /dev/null
> +++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
> @@ -0,0 +1,18 @@
> +# Example of a custom initramfs image recipe. The image will be deployed to
> +#
> +# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img
> +#
> +# This software is a part of ISAR.
> +
> +inherit initramfs
> +
> +# Debian packages that should be installed into the system for building the
> +# initramfs. E.g. the cryptsetup package which contains initramfs scripts for
> +# decrypting a root filesystem.
> +INITRAMFS_PREINSTALL += " \
> + "
> +
> +# Recipes that should be installed into the initramfs build rootfs.
> +INITRAMFS_INSTALL += " \
> + initramfs-example \
> + "
>
If this recipe is not pulled somewhere, it's dead. Some test-only
dependencies we had to local.conf in scripts/ci_build.sh. Or you add it
to meta-isar/conf/local.conf.sample.
If added, will it simply replace the default initramfs? Or is more needed?
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 3/3] Add custom isar-initramfs example
2020-09-25 9:13 ` Jan Kiszka
@ 2020-09-25 11:28 ` Harald Seiler
2020-10-13 15:11 ` Jan Kiszka
0 siblings, 1 reply; 19+ messages in thread
From: Harald Seiler @ 2020-09-25 11:28 UTC (permalink / raw)
To: Jan Kiszka, isar-users
On Fri, 2020-09-25 at 11:13 +0200, Jan Kiszka wrote:
> On 23.09.20 18:20, Harald Seiler wrote:
> > isar-initramfs is a custom initramfs which additionally has the
> > initramfs-example module installed.
> >
> > Signed-off-by: Harald Seiler <hws@denx.de>
> > ---
> >
> > Notes:
> > Maybe this initramfs should be tested in CI somewhere? I'm unsure what
> > makes sense, and how to "force" this custom initramfs into a CI target.
> >
> > .../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb
> >
> > diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
> > new file mode 100644
> > index 000000000000..aaa0350aab20
> > --- /dev/null
> > +++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
> > @@ -0,0 +1,18 @@
> > +# Example of a custom initramfs image recipe. The image will be deployed to
> > +#
> > +# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img
> > +#
> > +# This software is a part of ISAR.
> > +
> > +inherit initramfs
> > +
> > +# Debian packages that should be installed into the system for building the
> > +# initramfs. E.g. the cryptsetup package which contains initramfs scripts for
> > +# decrypting a root filesystem.
> > +INITRAMFS_PREINSTALL += " \
> > + "
> > +
> > +# Recipes that should be installed into the initramfs build rootfs.
> > +INITRAMFS_INSTALL += " \
> > + initramfs-example \
> > + "
> >
>
> If this recipe is not pulled somewhere, it's dead.
Right, that's why I was asking where to put it.
> Some test-only dependencies we had to local.conf in scripts/ci_build.sh.
> Or you add it to meta-isar/conf/local.conf.sample.
>
> If added, will it simply replace the default initramfs? Or is more needed?
Well, there really isn't such a thing as the default initramfs right now.
`image.bbclass` deploys its own initramfs (the one debian installed to
/boot) to `${IMAGE_FULLNAME}-initrd.img` which further tasks could then
reference when building e.g. a fitImage or it could be added to
IMAGE_BOOT_FILES for WIC.
Similarly, the new `initramfs.bbclass` deploys the final artifact to
`${INITRAMFS_FULLNAME}.initrd.img`. What happens after that is entirely
up to the integrator. After all, this image-class is meant for cases
where customization beyond the abilities of the current in-rootfs
initramfs are needed. As an example, a fitImage recipe could use this
like
INITRAMFS_RECIPE = "isar-initramfs"
INITRD_IMG = "${PP_DEPLOY}/${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img"
do_fit_image[depends] += "${INITRAMFS_RECIPE}:do_build"
---
Now, for CI if we want to include this custom initramfs, we'd need to
either modify some image recipe to pull it in as shown above or build it
separately and then start qemu with
-initrd build/tmp/deploy/images/qemuamd64/isar-initramfs-debian-buster-qemuamd64.initrd.img
somewhere. But I'm not sure if that's easily integrated into the current
setup?
IMO the next best thing would be to just build test it. Would adding
mc:qemuamd64-buster:isar-initramfs
to TARGETS_SET in ci_build.sh work?
--
Harald
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 1/3] classes: Add initramfs class
2020-09-23 16:20 ` [PATCH v2 1/3] " Harald Seiler
@ 2020-09-25 13:16 ` Henning Schild
2020-10-06 12:24 ` Harald Seiler
0 siblings, 1 reply; 19+ messages in thread
From: Henning Schild @ 2020-09-25 13:16 UTC (permalink / raw)
To: Harald Seiler; +Cc: isar-users
To me this sounds like a "buildchroot" specifically for the initramfs.
And the target would be to keep the stuff we need only in the initramfs
out of the "final" rootfs.
More inline.
On Wed, 23 Sep 2020 18:20:44 +0200
Harald Seiler <hws@denx.de> wrote:
> Add a new "image" class for generating a custom initramfs. It works
> like this: A new minimal debian rootfs is bootstrapped and all
> dependency packages for the new initramfs are installed. Then, an
> initramfs is generated from this rootfs and deployed like usual.
>
> This new initramfs.bbclass "image" class should be pulled in by an
> "initramfs image" recipe. Said recipe then specifies all dependencies
> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> are analogous to the respective IMAGE_* variables).
>
> initramfs.bbclass intentionally does _not_ expose a mechanism to
> change /etc/initramfs-tools/initramfs.conf and
> /etc/initramfs-tools/modules. Changes to their settings are better
> done via packages that deploy conf-hooks to
> /usr/share/initramfs-tools/conf-hooks.d/ and module fragment files to
> /usr/share/initramfs-tools/modules.d/.
>
> Signed-off-by: Harald Seiler <hws@denx.de>
> ---
>
> Notes:
> I had this idea while searching for a way to build an initramfs
> that uses dm-verity to assert integrity of the rootfs. To me, this
> feels like a much cleaner solution than anything else I tried and I'm
> happy to report that, using this approach, I got everything working
> nicely in the original project.
>
> In my opinion, this design has a number of advantages over the
> previous solutions we have seen so far:
>
> - It does not suffer any kind of initramfs pollution, caused by
> packages installed into a rootfs. This is a big problem when
> trying to generated an initramfs from e.g. `buildchroot-target` as
> many unrelated packaged could be installed there which would all get
> pulled into the initrd (if they install hooks/scripts).
I was about to ask why not just use that chroot ... got it.
> This also means, with this new approach, the integrator has
> maximum control over the contents of the initramfs.
And maximum responsibilty. Using an initrd that was not generated from
the "final" rootfs probably violates some assumptions or can at least
be seen as highly unusual. Not sure that is or could become a problem.
> - There are no needs to change the initramfs generation process
> in any way, the debian tooling can be used exactly like its meant to.
>
> - As most isar-generated images will never regenerate the
> initramfs from the running system, all initramfs related packages are
> dead-weight to the image. This is a problem when trying to generate
> the initramfs from the actual image rootfs.
Yes dead-weight, but is it heavy? In terms of disk-space we are
probably talking about really not much, if you compare to what
applications will pull in. But i do not know. I guess lvm, mdadm,
cryptsetup and friends could really add up ... but wic does not have
that anyways ;)
> When it is necessary to rebuild the initramfs in a running
> system, the packages designed for this new class could just be
> installed into the rootfs, without any changes necessary. This
> means, any generic initramfs module packages can be used both with
> the in-rootfs mechanism and initramfs.bbclass.
>
> - Because of this complete isolation and independence,
> implementation of complex logic is much easier: For example
> dm-verity needs a root-hash that is only available after the rootfs
> has been cast into a filesystem image. With this new approach, this
> can be modelled with a simple task dependency.
I guess one can pass that hash to the initrd with an argument from the
kernel command line. So you probably pass it into your wks, or whatever
imager controls the cmdline.
How much does the generation of the initrd impose on the "real" rootfs,
in terms of "dead" packages? And how polluted can an initrd become when
generated from a rootfs that "contains too much"? Maybe you have
numbers for your layer giving a perspective on the gain.
Generating the initramfs not from the rootfs means that the manifest
will not mention all packages shipped in the image, which could cause
legal issues when overlooked. Adding the manifests might result in
too much clearing effort, because not all that is in the
initramfs-buildchroot will be in the initramfs.
Henning
> Changes in v2:
> - None (just added examples in new patches)
>
> meta/classes/initramfs.bbclass | 41
> ++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
> create mode 100644 meta/classes/initramfs.bbclass
>
> diff --git a/meta/classes/initramfs.bbclass
> b/meta/classes/initramfs.bbclass new file mode 100644
> index 000000000000..8af9b4b379a5
> --- /dev/null
> +++ b/meta/classes/initramfs.bbclass
> @@ -0,0 +1,41 @@
> +# This software is a part of ISAR.
> +
> +# Make workdir and stamps machine-specific without changing common
> PN target +WORKDIR =
> "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMP =
> "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMPCLEAN =
> "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*" +
> +INITRAMFS_INSTALL ?= "" +INITRAMFS_PREINSTALL ?= ""
> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs" +INITRAMFS_IMAGE_FILE =
> "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img" +
> +# Install proper kernel
> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME",
> True)) if d.getVar("KERNEL_NAME", True) else ""}" +
> +# Name of the initramfs including distro&machine names
> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> +
> +DEPENDS += "${INITRAMFS_INSTALL}"
> +
> +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> +ROOTFS_FEATURES = ""
> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL}
> ${INITRAMFS_INSTALL}" +
> +inherit rootfs
> +
> +do_generate_initramfs() {
> + rootfs_do_mounts
> + rootfs_do_qemu
> +
> + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> + update-initramfs -u -v
> +
> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> + die "No initramfs was found after generation!"
> + fi
> +
> + rm -rf "${INITRAMFS_IMAGE_FILE}"
> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
> +}
> +addtask generate_initramfs after do_rootfs before do_build
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 1/3] classes: Add initramfs class
2020-09-25 13:16 ` Henning Schild
@ 2020-10-06 12:24 ` Harald Seiler
0 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2020-10-06 12:24 UTC (permalink / raw)
To: Henning Schild; +Cc: isar-users
Hi,
On Fri, 2020-09-25 at 15:16 +0200, Henning Schild wrote:
> To me this sounds like a "buildchroot" specifically for the initramfs.
That's pretty much what it is. With the difference to the other
buildchroots that it is not shared when building multiple initramfs images
so each one has its own rootfs.
> And the target would be to keep the stuff we need only in the initramfs
> out of the "final" rootfs.
This is a nice side-effect but not the main reason I propose this. Just
to make it clear: I do _not_ want this to be a replacement for the current
way of building the initramfs from the image rootfs. This new bbclass is
meant for situations where in-image generation falls short or is otherwise
inappropriate. A few examples:
- As already mentioned, it makes dm-verity setups _much_ easier and a lot
cleaner because it avoids the dependency cycle that other approaches
have.
- This could be used to generate a completely custom initramfs-based
rescue system.
> More inline.
>
> On Wed, 23 Sep 2020 18:20:44 +0200
> Harald Seiler <hws@denx.de> wrote:
>
> > Add a new "image" class for generating a custom initramfs. It works
> > like this: A new minimal debian rootfs is bootstrapped and all
> > dependency packages for the new initramfs are installed. Then, an
> > initramfs is generated from this rootfs and deployed like usual.
> >
> > This new initramfs.bbclass "image" class should be pulled in by an
> > "initramfs image" recipe. Said recipe then specifies all dependencies
> > of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> > are analogous to the respective IMAGE_* variables).
> >
> > initramfs.bbclass intentionally does _not_ expose a mechanism to
> > change /etc/initramfs-tools/initramfs.conf and
> > /etc/initramfs-tools/modules. Changes to their settings are better
> > done via packages that deploy conf-hooks to
> > /usr/share/initramfs-tools/conf-hooks.d/ and module fragment files to
> > /usr/share/initramfs-tools/modules.d/.
> >
> > Signed-off-by: Harald Seiler <hws@denx.de>
> > ---
> >
> > Notes:
> > I had this idea while searching for a way to build an initramfs
> > that uses dm-verity to assert integrity of the rootfs. To me, this
> > feels like a much cleaner solution than anything else I tried and I'm
> > happy to report that, using this approach, I got everything working
> > nicely in the original project.
> >
> > In my opinion, this design has a number of advantages over the
> > previous solutions we have seen so far:
> >
> > - It does not suffer any kind of initramfs pollution, caused by
> > packages installed into a rootfs. This is a big problem when
> > trying to generated an initramfs from e.g. `buildchroot-target` as
> > many unrelated packaged could be installed there which would all get
> > pulled into the initrd (if they install hooks/scripts).
>
> I was about to ask why not just use that chroot ... got it.
>
> > This also means, with this new approach, the integrator has
> > maximum control over the contents of the initramfs.
>
> And maximum responsibilty. Using an initrd that was not generated from
> the "final" rootfs probably violates some assumptions or can at least
> be seen as highly unusual. Not sure that is or could become a problem.
The vanilla initramfs from debian does not suffer any problems, as long as
you make sure the correct kernel modules are included. This should
usually just work(tm) because initramfs.bbclass does the exact same thing
as image.bbclass:
> > +# Install proper kernel
> > +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME",
With upstream initramfs modules, care has to be taken, of course. Let's
look at cryptroot from cryptsetup as an example: This module needs
a correct /etc/crypttab in the initramfs-chroot to properly unlock the
root filesystem. For any other partitions, crypttab needs to be in the
actual image rootfs.
You could now either have two separate crypttabs, one with just the rootfs
in initramfs-chroot and one for the rest in the actual image. Or, what
I'd find the cleaner solution: A config-package containing /etc/crypttab
that is deployed to both the image and the initramfs-chroot.
That said, I do not see why one would want the custom initramfs for this
scenario ... The in-image version will work just fine.
> > - There are no needs to change the initramfs generation process
> > in any way, the debian tooling can be used exactly like its meant to.
> >
> > - As most isar-generated images will never regenerate the
> > initramfs from the running system, all initramfs related packages are
> > dead-weight to the image. This is a problem when trying to generate
> > the initramfs from the actual image rootfs.
>
> Yes dead-weight, but is it heavy? In terms of disk-space we are
> probably talking about really not much, if you compare to what
> applications will pull in. But i do not know. I guess lvm, mdadm,
> cryptsetup and friends could really add up ... but wic does not have
> that anyways ;)
I don't think it would amount to much. If you're really short on space,
it could matter (as you said, one could pull any dm tooling out of the
rootfs), but apart from that I don't think it is that relevant.
> > When it is necessary to rebuild the initramfs in a running
> > system, the packages designed for this new class could just be
> > installed into the rootfs, without any changes necessary. This
> > means, any generic initramfs module packages can be used both with
> > the in-rootfs mechanism and initramfs.bbclass.
> >
> > - Because of this complete isolation and independence,
> > implementation of complex logic is much easier: For example
> > dm-verity needs a root-hash that is only available after the rootfs
> > has been cast into a filesystem image. With this new approach, this
> > can be modelled with a simple task dependency.
>
> I guess one can pass that hash to the initrd with an argument from the
> kernel command line. So you probably pass it into your wks, or whatever
> imager controls the cmdline.
I don't see this working without creating a dependency cycle somewhere ...
I did try to explore alternative solutions but it all ended up requiring
ugly hacks at some point or another.
> How much does the generation of the initrd impose on the "real" rootfs,
> in terms of "dead" packages? And how polluted can an initrd become when
> generated from a rootfs that "contains too much"? Maybe you have
> numbers for your layer giving a perspective on the gain.
The main motivation for me was a clean dm-verity setup so I do not have
numbers on this aspect. I don't expect it to be much though.
> Generating the initramfs not from the rootfs means that the manifest
> will not mention all packages shipped in the image, which could cause
> legal issues when overlooked. Adding the manifests might result in
> too much clearing effort, because not all that is in the
> initramfs-buildchroot will be in the initramfs.
Well you won't install anything into the initramfs-chroot that won't in
some form or another leave a trace in the initramfs so I'd say merging the
manifests does make sense here.
--
Harald
> Henning
>
> > Changes in v2:
> > - None (just added examples in new patches)
> >
> > meta/classes/initramfs.bbclass | 41
> > ++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+)
> > create mode 100644 meta/classes/initramfs.bbclass
> >
> > diff --git a/meta/classes/initramfs.bbclass
> > b/meta/classes/initramfs.bbclass new file mode 100644
> > index 000000000000..8af9b4b379a5
> > --- /dev/null
> > +++ b/meta/classes/initramfs.bbclass
> > @@ -0,0 +1,41 @@
> > +# This software is a part of ISAR.
> > +
> > +# Make workdir and stamps machine-specific without changing common
> > PN target +WORKDIR =
> > "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > +STAMP =
> > "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> > +STAMPCLEAN =
> > "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*" +
> > +INITRAMFS_INSTALL ?= "" +INITRAMFS_PREINSTALL ?= ""
> > +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs" +INITRAMFS_IMAGE_FILE =
> > "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img" +
> > +# Install proper kernel
> > +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME",
> > True)) if d.getVar("KERNEL_NAME", True) else ""}" +
> > +# Name of the initramfs including distro&machine names
> > +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> > +
> > +DEPENDS += "${INITRAMFS_INSTALL}"
> > +
> > +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> > +ROOTFS_FEATURES = ""
> > +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL}
> > ${INITRAMFS_INSTALL}" +
> > +inherit rootfs
> > +
> > +do_generate_initramfs() {
> > + rootfs_do_mounts
> > + rootfs_do_qemu
> > +
> > + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> > + update-initramfs -u -v
> > +
> > + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> > + die "No initramfs was found after generation!"
> > + fi
> > +
> > + rm -rf "${INITRAMFS_IMAGE_FILE}"
> > + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
> > +}
> > +addtask generate_initramfs after do_rootfs before do_build
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 3/3] Add custom isar-initramfs example
2020-09-25 11:28 ` Harald Seiler
@ 2020-10-13 15:11 ` Jan Kiszka
2021-01-14 10:11 ` [PATCH v3 1/3] classes: Add initramfs class Harald Seiler
0 siblings, 1 reply; 19+ messages in thread
From: Jan Kiszka @ 2020-10-13 15:11 UTC (permalink / raw)
To: Harald Seiler, isar-users
On 25.09.20 13:28, Harald Seiler wrote:
> On Fri, 2020-09-25 at 11:13 +0200, Jan Kiszka wrote:
>> On 23.09.20 18:20, Harald Seiler wrote:
>>> isar-initramfs is a custom initramfs which additionally has the
>>> initramfs-example module installed.
>>>
>>> Signed-off-by: Harald Seiler <hws@denx.de>
>>> ---
>>>
>>> Notes:
>>> Maybe this initramfs should be tested in CI somewhere? I'm unsure what
>>> makes sense, and how to "force" this custom initramfs into a CI target.
>>>
>>> .../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>> create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb
>>>
>>> diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
>>> new file mode 100644
>>> index 000000000000..aaa0350aab20
>>> --- /dev/null
>>> +++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
>>> @@ -0,0 +1,18 @@
>>> +# Example of a custom initramfs image recipe. The image will be deployed to
>>> +#
>>> +# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img
>>> +#
>>> +# This software is a part of ISAR.
>>> +
>>> +inherit initramfs
>>> +
>>> +# Debian packages that should be installed into the system for building the
>>> +# initramfs. E.g. the cryptsetup package which contains initramfs scripts for
>>> +# decrypting a root filesystem.
>>> +INITRAMFS_PREINSTALL += " \
>>> + "
>>> +
>>> +# Recipes that should be installed into the initramfs build rootfs.
>>> +INITRAMFS_INSTALL += " \
>>> + initramfs-example \
>>> + "
>>>
>>
>> If this recipe is not pulled somewhere, it's dead.
>
> Right, that's why I was asking where to put it.
>
>> Some test-only dependencies we had to local.conf in scripts/ci_build.sh.
>> Or you add it to meta-isar/conf/local.conf.sample.
>>
>> If added, will it simply replace the default initramfs? Or is more needed?
>
> Well, there really isn't such a thing as the default initramfs right now.
> `image.bbclass` deploys its own initramfs (the one debian installed to
> /boot) to `${IMAGE_FULLNAME}-initrd.img` which further tasks could then
> reference when building e.g. a fitImage or it could be added to
> IMAGE_BOOT_FILES for WIC.
>
> Similarly, the new `initramfs.bbclass` deploys the final artifact to
> `${INITRAMFS_FULLNAME}.initrd.img`. What happens after that is entirely
> up to the integrator. After all, this image-class is meant for cases
> where customization beyond the abilities of the current in-rootfs
> initramfs are needed. As an example, a fitImage recipe could use this
> like
>
> INITRAMFS_RECIPE = "isar-initramfs"
>
> INITRD_IMG = "${PP_DEPLOY}/${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}.initrd.img"
> do_fit_image[depends] += "${INITRAMFS_RECIPE}:do_build"
>
> ---
>
> Now, for CI if we want to include this custom initramfs, we'd need to
> either modify some image recipe to pull it in as shown above or build it
> separately and then start qemu with
>
> -initrd build/tmp/deploy/images/qemuamd64/isar-initramfs-debian-buster-qemuamd64.initrd.img
>
> somewhere. But I'm not sure if that's easily integrated into the current
> setup?
>
> IMO the next best thing would be to just build test it. Would adding
>
> mc:qemuamd64-buster:isar-initramfs
>
> to TARGETS_SET in ci_build.sh work?
>
We already have fit/ubi example. Could that be expanded better to stress
this? Otherwise, I'm find with your suggestion above.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v3 1/3] classes: Add initramfs class
2020-10-13 15:11 ` Jan Kiszka
@ 2021-01-14 10:11 ` Harald Seiler
2021-01-14 10:11 ` [PATCH v3 2/3] Add example initramfs module recipe Harald Seiler
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Harald Seiler @ 2021-01-14 10:11 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler, Jan Kiszka
Add a new "image" class for generating a custom initramfs. It works
like this: A new minimal debian rootfs is bootstrapped and all
dependency packages for the new initramfs are installed. Then, an
initramfs is generated from this rootfs and deployed like usual.
This new initramfs.bbclass "image" class should be pulled in by an
"initramfs image" recipe. Said recipe then specifies all dependencies
of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
are analogous to the respective IMAGE_* variables).
initramfs.bbclass intentionally does _not_ expose a mechanism to change
/etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
Changes to their settings are better done via packages that deploy
conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
fragment files to /usr/share/initramfs-tools/modules.d/.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
I had this idea while searching for a way to build an initramfs that
uses dm-verity to assert integrity of the rootfs. To me, this feels
like a much cleaner solution than anything else I tried and I'm happy to
report that, using this approach, I got everything working nicely in the
original project.
In my opinion, this design has a number of advantages over the previous
solutions we have seen so far:
- It does not suffer any kind of initramfs pollution, caused by
packages installed into a rootfs. This is a big problem when trying
to generated an initramfs from e.g. `buildchroot-target` as many
unrelated packaged could be installed there which would all get
pulled into the initrd (if they install hooks/scripts).
This also means, with this new approach, the integrator has maximum
control over the contents of the initramfs.
- There are no needs to change the initramfs generation process in any
way, the debian tooling can be used exactly like its meant to.
- As most isar-generated images will never regenerate the initramfs
from the running system, all initramfs related packages are dead-weight
to the image. This is a problem when trying to generate the initramfs
from the actual image rootfs.
When it is necessary to rebuild the initramfs in a running system,
the packages designed for this new class could just be installed into
the rootfs, without any changes necessary. This means, any generic
initramfs module packages can be used both with the in-rootfs mechanism
and initramfs.bbclass.
- Because of this complete isolation and independence, implementation
of complex logic is much easier: For example dm-verity needs
a root-hash that is only available after the rootfs has been cast into
a filesystem image. With this new approach, this can be modelled with
a simple task dependency.
Changes in v2:
- None (just added examples in new patches)
Changes in v3:
- None
meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 meta/classes/initramfs.bbclass
diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
new file mode 100644
index 000000000000..8af9b4b379a5
--- /dev/null
+++ b/meta/classes/initramfs.bbclass
@@ -0,0 +1,41 @@
+# This software is a part of ISAR.
+
+# Make workdir and stamps machine-specific without changing common PN target
+WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
+STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
+
+INITRAMFS_INSTALL ?= ""
+INITRAMFS_PREINSTALL ?= ""
+INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
+INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
+
+# Install proper kernel
+INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
+
+# Name of the initramfs including distro&machine names
+INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
+
+DEPENDS += "${INITRAMFS_INSTALL}"
+
+ROOTFSDIR = "${INITRAMFS_ROOTFS}"
+ROOTFS_FEATURES = ""
+ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
+
+inherit rootfs
+
+do_generate_initramfs() {
+ rootfs_do_mounts
+ rootfs_do_qemu
+
+ sudo -E chroot "${INITRAMFS_ROOTFS}" \
+ update-initramfs -u -v
+
+ if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
+ die "No initramfs was found after generation!"
+ fi
+
+ rm -rf "${INITRAMFS_IMAGE_FILE}"
+ cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
+}
+addtask generate_initramfs after do_rootfs before do_build
--
2.29.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v3 2/3] Add example initramfs module recipe
2021-01-14 10:11 ` [PATCH v3 1/3] classes: Add initramfs class Harald Seiler
@ 2021-01-14 10:11 ` Harald Seiler
2021-01-14 10:11 ` [PATCH v3 3/3] Add custom isar-initramfs example Harald Seiler
2021-01-18 9:11 ` [PATCH v3 1/3] classes: Add initramfs class florian.bezdeka
2 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2021-01-14 10:11 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler, Jan Kiszka
Add the initramfs-example recipe/package which demonstrates how to write
initramfs modules. It demonstrates how to add hook scripts, boot scripts,
and conf-hooks.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
Changes in v3:
- None
.../initramfs-example/files/example.conf-hook | 7 ++++
.../initramfs-example/files/example.hook | 19 +++++++++
.../initramfs-example/files/example.script | 21 ++++++++++
.../initramfs-example/initramfs-example.bb | 40 +++++++++++++++++++
4 files changed, 87 insertions(+)
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.hook
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/files/example.script
create mode 100644 meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook b/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
new file mode 100644
index 000000000000..2a3cf7a84040
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.conf-hook
@@ -0,0 +1,7 @@
+# Example conf-hook.
+#
+# See "CONFIGURATION HOOK SCRIPTS" in initramfs-tools(7) for details.
+
+# Example: Use busybox instead of klibc-utils. The package must also add
+# `busybox` as a dependency when this is set.
+BUSYBOX=y
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.hook b/meta-isar/recipes-initramfs/initramfs-example/files/example.hook
new file mode 100644
index 000000000000..0d84e7a97efd
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.hook
@@ -0,0 +1,19 @@
+#!/bin/sh
+# Example hook script.
+#
+# See "HOOK SCRIPTS" in initramfs-tools(7) for details.
+
+PREREQ=""
+prereqs()
+{
+ echo "$PREREQ"
+}
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /usr/share/initramfs-tools/hook-functions
+# Begin real processing below this line
diff --git a/meta-isar/recipes-initramfs/initramfs-example/files/example.script b/meta-isar/recipes-initramfs/initramfs-example/files/example.script
new file mode 100644
index 000000000000..784fad9c99bb
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/files/example.script
@@ -0,0 +1,21 @@
+#!/bin/sh
+# Example boot script.
+#
+# See "BOOT SCRIPTS" in initramfs-tools(7) for details.
+
+PREREQ=""
+prereqs()
+{
+ echo "$PREREQ"
+}
+case $1 in
+prereqs)
+ prereqs
+ exit 0
+ ;;
+esac
+
+. /scripts/functions
+# Begin real processing below this line
+
+log_success_msg "Hello from ISAR!"
diff --git a/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb b/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
new file mode 100644
index 000000000000..c336dda92b5d
--- /dev/null
+++ b/meta-isar/recipes-initramfs/initramfs-example/initramfs-example.bb
@@ -0,0 +1,40 @@
+# Example of a recipe containing an initramfs module. Packages like this can be
+# used with initramfs.bbclass or installed directly into a rootfs, depending on
+# the usecase.
+#
+# This software is a part of ISAR.
+
+DESCRIPTION = "Sample initramfs module for ISAR"
+MAINTAINER = "Your name here <you@domain.com>"
+DEBIAN_DEPENDS = "initramfs-tools"
+
+# If the conf-hook enables BUSYBOX=y, busybox is needed:
+DEBIAN_DEPENDS .= ", busybox"
+
+SRC_URI = " \
+ file://example.conf-hook \
+ file://example.hook \
+ file://example.script \
+ "
+
+inherit dpkg-raw
+
+do_install[cleandirs] += " \
+ ${D}/usr/share/initramfs-tools/conf-hooks.d \
+ ${D}/usr/share/initramfs-tools/hooks \
+ ${D}/usr/share/initramfs-tools/scripts/local-top \
+ "
+do_install() {
+ # See "CONFIGURATION HOOK SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.conf-hook" \
+ "${D}/usr/share/initramfs-tools/conf-hooks.d/isar-example"
+
+ # See "HOOK SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.hook" \
+ "${D}/usr/share/initramfs-tools/hooks/isar-example"
+
+ # Note that there are other places where a boot script might be deployed to,
+ # apart from local-top. See "BOOT SCRIPTS" in initramfs-tools(7) for details.
+ install "${WORKDIR}/example.script" \
+ "${D}/usr/share/initramfs-tools/scripts/local-top/example.script"
+}
--
2.29.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH v3 3/3] Add custom isar-initramfs example
2021-01-14 10:11 ` [PATCH v3 1/3] classes: Add initramfs class Harald Seiler
2021-01-14 10:11 ` [PATCH v3 2/3] Add example initramfs module recipe Harald Seiler
@ 2021-01-14 10:11 ` Harald Seiler
2021-01-18 9:11 ` [PATCH v3 1/3] classes: Add initramfs class florian.bezdeka
2 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2021-01-14 10:11 UTC (permalink / raw)
To: isar-users; +Cc: Harald Seiler, Jan Kiszka
isar-initramfs is a custom initramfs which additionally has the
initramfs-example module installed. It is also built as part of
the CI.
Signed-off-by: Harald Seiler <hws@denx.de>
---
Notes:
Changes in v3:
- Add this target to ci_build.sh for CI inclusion.
.../recipes-initramfs/images/isar-initramfs.bb | 18 ++++++++++++++++++
scripts/ci_build.sh | 1 +
2 files changed, 19 insertions(+)
create mode 100644 meta-isar/recipes-initramfs/images/isar-initramfs.bb
diff --git a/meta-isar/recipes-initramfs/images/isar-initramfs.bb b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
new file mode 100644
index 000000000000..aaa0350aab20
--- /dev/null
+++ b/meta-isar/recipes-initramfs/images/isar-initramfs.bb
@@ -0,0 +1,18 @@
+# Example of a custom initramfs image recipe. The image will be deployed to
+#
+# build/tmp/deploy/images/${MACHINE}/isar-initramfs-${DISTRO}-${MACHINE}.initrd.img
+#
+# This software is a part of ISAR.
+
+inherit initramfs
+
+# Debian packages that should be installed into the system for building the
+# initramfs. E.g. the cryptsetup package which contains initramfs scripts for
+# decrypting a root filesystem.
+INITRAMFS_PREINSTALL += " \
+ "
+
+# Recipes that should be installed into the initramfs build rootfs.
+INITRAMFS_INSTALL += " \
+ initramfs-example \
+ "
diff --git a/scripts/ci_build.sh b/scripts/ci_build.sh
index f4c33a37247e..f6fc5e54f7d3 100755
--- a/scripts/ci_build.sh
+++ b/scripts/ci_build.sh
@@ -28,6 +28,7 @@ TARGETS_SET="\
mc:qemuamd64-stretch:isar-image-base \
mc:qemuamd64-buster:isar-image-base \
mc:qemuamd64-buster-tgz:isar-image-base \
+ mc:qemuamd64-buster:isar-initramfs \
mc:qemumipsel-stretch:isar-image-base \
mc:qemumipsel-buster:isar-image-base \
mc:nand-ubi-demo-buster:isar-image-ubi \
--
2.29.2
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/3] classes: Add initramfs class
2021-01-14 10:11 ` [PATCH v3 1/3] classes: Add initramfs class Harald Seiler
2021-01-14 10:11 ` [PATCH v3 2/3] Add example initramfs module recipe Harald Seiler
2021-01-14 10:11 ` [PATCH v3 3/3] Add custom isar-initramfs example Harald Seiler
@ 2021-01-18 9:11 ` florian.bezdeka
2021-01-18 10:00 ` Harald Seiler
2 siblings, 1 reply; 19+ messages in thread
From: florian.bezdeka @ 2021-01-18 9:11 UTC (permalink / raw)
To: isar-users
On Thu, 2021-01-14 at 11:11 +0100, Harald Seiler wrote:
> Add a new "image" class for generating a custom initramfs. It works
> like this: A new minimal debian rootfs is bootstrapped and all
> dependency packages for the new initramfs are installed. Then, an
> initramfs is generated from this rootfs and deployed like usual.
>
> This new initramfs.bbclass "image" class should be pulled in by an
> "initramfs image" recipe. Said recipe then specifies all dependencies
> of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> are analogous to the respective IMAGE_* variables).
>
> initramfs.bbclass intentionally does _not_ expose a mechanism to change
> /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
> Changes to their settings are better done via packages that deploy
> conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
> fragment files to /usr/share/initramfs-tools/modules.d/.
>
> Signed-off-by: Harald Seiler <hws@denx.de>
> ---
>
> Notes:
> I had this idea while searching for a way to build an initramfs that
> uses dm-verity to assert integrity of the rootfs. To me, this feels
> like a much cleaner solution than anything else I tried and I'm happy to
> report that, using this approach, I got everything working nicely in the
> original project.
>
>
>
>
> In my opinion, this design has a number of advantages over the previous
> solutions we have seen so far:
>
>
>
>
> - It does not suffer any kind of initramfs pollution, caused by
> packages installed into a rootfs. This is a big problem when trying
> to generated an initramfs from e.g. `buildchroot-target` as many
> unrelated packaged could be installed there which would all get
> pulled into the initrd (if they install hooks/scripts).
>
>
>
>
> This also means, with this new approach, the integrator has maximum
> control over the contents of the initramfs.
>
>
>
>
> - There are no needs to change the initramfs generation process in any
> way, the debian tooling can be used exactly like its meant to.
>
>
>
>
> - As most isar-generated images will never regenerate the initramfs
> from the running system, all initramfs related packages are dead-weight
> to the image. This is a problem when trying to generate the initramfs
> from the actual image rootfs.
>
>
>
>
> When it is necessary to rebuild the initramfs in a running system,
> the packages designed for this new class could just be installed into
> the rootfs, without any changes necessary. This means, any generic
> initramfs module packages can be used both with the in-rootfs mechanism
> and initramfs.bbclass.
>
>
>
>
> - Because of this complete isolation and independence, implementation
> of complex logic is much easier: For example dm-verity needs
> a root-hash that is only available after the rootfs has been cast into
> a filesystem image. With this new approach, this can be modelled with
> a simple task dependency.
>
>
>
>
> Changes in v2:
> - None (just added examples in new patches)
>
>
>
>
> Changes in v3:
> - None
>
> meta/classes/initramfs.bbclass | 41 ++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 meta/classes/initramfs.bbclass
>
> diff --git a/meta/classes/initramfs.bbclass b/meta/classes/initramfs.bbclass
> new file mode 100644
> index 000000000000..8af9b4b379a5
> --- /dev/null
> +++ b/meta/classes/initramfs.bbclass
> @@ -0,0 +1,41 @@
> +# This software is a part of ISAR.
> +
> +# Make workdir and stamps machine-specific without changing common PN target
> +WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMP = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/${PV}-${PR}"
> +STAMPCLEAN = "${STAMPS_DIR}/${DISTRO}-${DISTRO_ARCH}/${PN}-${MACHINE}/*-*"
> +
> +INITRAMFS_INSTALL ?= ""
> +INITRAMFS_PREINSTALL ?= ""
> +INITRAMFS_ROOTFS ?= "${WORKDIR}/rootfs"
> +INITRAMFS_IMAGE_FILE = "${DEPLOY_DIR_IMAGE}/${INITRAMFS_FULLNAME}.initrd.img"
> +
> +# Install proper kernel
> +INITRAMFS_INSTALL += "${@ ("linux-image-" + d.getVar("KERNEL_NAME", True)) if d.getVar("KERNEL_NAME", True) else ""}"
> +
> +# Name of the initramfs including distro&machine names
> +INITRAMFS_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
> +
> +DEPENDS += "${INITRAMFS_INSTALL}"
> +
> +ROOTFSDIR = "${INITRAMFS_ROOTFS}"
> +ROOTFS_FEATURES = ""
> +ROOTFS_PACKAGES = "initramfs-tools ${INITRAMFS_PREINSTALL} ${INITRAMFS_INSTALL}"
> +
> +inherit rootfs
> +
> +do_generate_initramfs() {
> + rootfs_do_mounts
> + rootfs_do_qemu
> +
> + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> + update-initramfs -u -v
> +
> + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> + die "No initramfs was found after generation!"
> + fi
> +
> + rm -rf "${INITRAMFS_IMAGE_FILE}"
> + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
${INITRAMFS_IMAGE_FILE} references ${DEPLOY_DIR_IMAGE}, which may not
exist yet. So I guess we should add something like
do_generate_initramfs[dirs] = "${DEPLOY_DIR_IMAGE}"
otherwise you have fix the dependency with some kind of "intermediate
task" in the recipe using this class.
> +}
> +addtask generate_initramfs after do_rootfs before do_build
> --
> 2.29.2
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/3] classes: Add initramfs class
2021-01-18 9:11 ` [PATCH v3 1/3] classes: Add initramfs class florian.bezdeka
@ 2021-01-18 10:00 ` Harald Seiler
0 siblings, 0 replies; 19+ messages in thread
From: Harald Seiler @ 2021-01-18 10:00 UTC (permalink / raw)
To: florian.bezdeka, isar-users
Hi Florian,
On Mon, 2021-01-18 at 09:11 +0000, florian.bezdeka@siemens.com wrote:
> On Thu, 2021-01-14 at 11:11 +0100, Harald Seiler wrote:
> > Add a new "image" class for generating a custom initramfs. It works
> > like this: A new minimal debian rootfs is bootstrapped and all
> > dependency packages for the new initramfs are installed. Then, an
> > initramfs is generated from this rootfs and deployed like usual.
> >
> > This new initramfs.bbclass "image" class should be pulled in by an
> > "initramfs image" recipe. Said recipe then specifies all dependencies
> > of the initramfs via INITRAMFS_INSTALL and INITRAMFS_PREINSTALL (which
> > are analogous to the respective IMAGE_* variables).
> >
> > initramfs.bbclass intentionally does _not_ expose a mechanism to change
> > /etc/initramfs-tools/initramfs.conf and /etc/initramfs-tools/modules.
> > Changes to their settings are better done via packages that deploy
> > conf-hooks to /usr/share/initramfs-tools/conf-hooks.d/ and module
> > fragment files to /usr/share/initramfs-tools/modules.d/.
> >
> > Signed-off-by: Harald Seiler <hws@denx.de>
> > ---
> >
[...]
> > +
> > +do_generate_initramfs() {
> > + rootfs_do_mounts
> > + rootfs_do_qemu
> > +
> > + sudo -E chroot "${INITRAMFS_ROOTFS}" \
> > + update-initramfs -u -v
> > +
> > + if [ ! -e "${INITRAMFS_ROOTFS}/initrd.img" ]; then
> > + die "No initramfs was found after generation!"
> > + fi
> > +
> > + rm -rf "${INITRAMFS_IMAGE_FILE}"
> > + cp "${INITRAMFS_ROOTFS}/initrd.img" "${INITRAMFS_IMAGE_FILE}"
>
> ${INITRAMFS_IMAGE_FILE} references ${DEPLOY_DIR_IMAGE}, which may not
> exist yet. So I guess we should add something like
>
> do_generate_initramfs[dirs] = "${DEPLOY_DIR_IMAGE}"
>
> otherwise you have fix the dependency with some kind of "intermediate
> task" in the recipe using this class.
Yeah, I actually did this exact change in a downstream version of the
recipe but somehow forgot to add it here ... Will fix!
Harald
> > +}
> > +addtask generate_initramfs after do_rootfs before do_build
> > --
> > 2.29.2
> >
>
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-62 Fax: +49-8142-66989-80 Email: hws@denx.de
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-01-18 10:00 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-21 10:42 [RFC PATCH] classes: Add initramfs class Harald Seiler
2020-09-21 19:25 ` Jan Kiszka
2020-09-22 10:34 ` Harald Seiler
2020-09-22 11:04 ` Jan Kiszka
2020-09-22 12:10 ` Gylstorff Quirin
2020-09-22 12:18 ` Harald Seiler
2020-09-23 16:20 ` [PATCH v2 1/3] " Harald Seiler
2020-09-25 13:16 ` Henning Schild
2020-10-06 12:24 ` Harald Seiler
2020-09-23 16:20 ` [PATCH v2 2/3] Add example initramfs module recipe Harald Seiler
2020-09-23 16:20 ` [PATCH v2 3/3] Add custom isar-initramfs example Harald Seiler
2020-09-25 9:13 ` Jan Kiszka
2020-09-25 11:28 ` Harald Seiler
2020-10-13 15:11 ` Jan Kiszka
2021-01-14 10:11 ` [PATCH v3 1/3] classes: Add initramfs class Harald Seiler
2021-01-14 10:11 ` [PATCH v3 2/3] Add example initramfs module recipe Harald Seiler
2021-01-14 10:11 ` [PATCH v3 3/3] Add custom isar-initramfs example Harald Seiler
2021-01-18 9:11 ` [PATCH v3 1/3] classes: Add initramfs class florian.bezdeka
2021-01-18 10:00 ` Harald Seiler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox