[PATCH] expand-on-first-boot: Add support for devicemapper
10 views
Skip to first unread message
Jan Kiszka
Apr 21, 2022, 1:10:49 PM4/21/22
to isar-users, Christian Storm
From: Jan Kiszka <jan.k...@siemens.com>
When the rootfs is inside a devicemapper volume, e.g. dm-verity, the
script so far fails to identify the boot device. This adds at least
basic support for that case (single level, single slave). Once there is
a good example for more complex setups, this could be taken into account
as well.
Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---
.../expand-on-first-boot/files/expand-last-partition.sh | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
index 7175dfd3..bb371e9f 100755
--- a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
+++ b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
@@ -10,8 +10,13 @@
set -e
ROOT_DEV="$(findmnt / -o source -n)"
-BOOT_DEV="$(echo "${ROOT_DEV}" | sed 's/p\?[0-9]*$//')"
+ROOT_DEV_NAME=${ROOT_DEV##*/}
+ROOT_DEV_SLAVE=$(ls -d /sys/block/${ROOT_DEV_NAME}/slaves/* 2>/dev/null | head -1)
+if [ -n ${ROOT_DEV_SLAVE} ]; then
+ ROOT_DEV=/dev/${ROOT_DEV_SLAVE##*/}
+fi
+BOOT_DEV="$(echo "${ROOT_DEV}" | sed 's/p\?[0-9]*$//')"
if [ "${ROOT_DEV}" = "${BOOT_DEV}" ]; then
echo "Boot device equals root device - no partitioning found" >&2
exit 1
--
2.34.1
When the rootfs is inside a devicemapper volume, e.g. dm-verity, the
script so far fails to identify the boot device. This adds at least
basic support for that case (single level, single slave). Once there is
a good example for more complex setups, this could be taken into account
as well.
Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
---
.../expand-on-first-boot/files/expand-last-partition.sh | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
index 7175dfd3..bb371e9f 100755
--- a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
+++ b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
@@ -10,8 +10,13 @@
set -e
ROOT_DEV="$(findmnt / -o source -n)"
-BOOT_DEV="$(echo "${ROOT_DEV}" | sed 's/p\?[0-9]*$//')"
+ROOT_DEV_NAME=${ROOT_DEV##*/}
+ROOT_DEV_SLAVE=$(ls -d /sys/block/${ROOT_DEV_NAME}/slaves/* 2>/dev/null | head -1)
+if [ -n ${ROOT_DEV_SLAVE} ]; then
+ ROOT_DEV=/dev/${ROOT_DEV_SLAVE##*/}
+fi
+BOOT_DEV="$(echo "${ROOT_DEV}" | sed 's/p\?[0-9]*$//')"
if [ "${ROOT_DEV}" = "${BOOT_DEV}" ]; then
echo "Boot device equals root device - no partitioning found" >&2
exit 1
--
2.34.1
Henning Schild
Apr 21, 2022, 1:43:53 PM4/21/22
to Jan Kiszka, isar-users, Christian Storm
I learned yesterday about systemd-repart
https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
We should look at this and how mkosi puts/uses it for debian.
Not a review, just a generic remark that there might be more powerful
and ready to use tools out there. At some point i will play with this
and see if it can replace expand-on-first-boot, i bet we will soon hear
the first btrfs stories ... and maybe luks.
I know people do that with isar and their own funny scripting which can
not be found upstream.
Am Thu, 21 Apr 2022 19:10:44 +0200
schrieb Jan Kiszka <jan.k...@siemens.com>:
Please add a wks and switch at least one CI target. In case wic can not
generate that dm-verity ... NACK, or provide the wic plugin as well.
Henning
https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
We should look at this and how mkosi puts/uses it for debian.
Not a review, just a generic remark that there might be more powerful
and ready to use tools out there. At some point i will play with this
and see if it can replace expand-on-first-boot, i bet we will soon hear
the first btrfs stories ... and maybe luks.
I know people do that with isar and their own funny scripting which can
not be found upstream.
Am Thu, 21 Apr 2022 19:10:44 +0200
schrieb Jan Kiszka <jan.k...@siemens.com>:
generate that dm-verity ... NACK, or provide the wic plugin as well.
Henning
Jan Kiszka
Apr 21, 2022, 2:49:30 PM4/21/22
to Henning Schild, isar-users, Christian Storm
On 21.04.22 19:43, Henning Schild wrote:
> I learned yesterday about systemd-repart
> https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
>
> We should look at this and how mkosi puts/uses it for debian.
>
+ systemd-growfs, yes, these are possibly alternative building blocks
> I learned yesterday about systemd-repart
> https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
>
> We should look at this and how mkosi puts/uses it for debian.
>
for such a service. Quickly scanned mkosi but couldn't find the require
glue yet, unfortunately.
> Not a review, just a generic remark that there might be more powerful
> and ready to use tools out there. At some point i will play with this
> and see if it can replace expand-on-first-boot, i bet we will soon hear
> the first btrfs stories ... and maybe luks.
>
> I know people do that with isar and their own funny scripting which can
> not be found upstream.
first. A script or a cascade of dependent and accordingly configured
services will remain, though.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Henning Schild
Apr 21, 2022, 3:05:24 PM4/21/22
to Jan Kiszka, isar-users, Christian Storm
Am Thu, 21 Apr 2022 19:43:47 +0200
schrieb Henning Schild <henning...@siemens.com>:
> I learned yesterday about systemd-repart
> https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
This currently needs >= bookworm to even start playing with systemd >=
250.1-2
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976959
So maybe a little too early for isar, but still something we could look
into.
systemd-growfs is also available in older versions, but that just deals
with the filesystem, not with the partition table.
Henning
schrieb Henning Schild <henning...@siemens.com>:
> I learned yesterday about systemd-repart
> https://www.freedesktop.org/software/systemd/man/systemd-repart.service.html
250.1-2
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976959
So maybe a little too early for isar, but still something we could look
into.
systemd-growfs is also available in older versions, but that just deals
with the filesystem, not with the partition table.
Henning
Tobias Schaffner
Apr 22, 2022, 2:28:42 AM4/22/22
to Henning Schild, Jan Kiszka, isar-users, Christian Storm
Switching to systemd-repart would also fix a rare race condition.
Expand-on-first-boot can cause systemd to not be able to mount its mount
units if it makes the kernel reload the partition table in a bad moment.
Tobias
On 4/21/22 21:05, Henning Schild wrote:
> Am Thu, 21 Apr 2022 19:43:47 +0200
> schrieb Henning Schild <henning...@siemens.com>:
>
>> I learned yesterday about systemd-repart
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freedesktop.org%2Fsoftware%2Fsystemd%2Fman%2Fsystemd-repart.service.html&data=05%7C01%7Ctobias.schaffner%40siemens.com%7C045ffc25cea442b91a7808da23c9e432%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637861648059484524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qlzBS8YjhJBvZE7LnofOlT6uE76Nrsu45xZ25E9ocj4%3D&reserved=0
Expand-on-first-boot can cause systemd to not be able to mount its mount
units if it makes the kernel reload the partition table in a bad moment.
Tobias
On 4/21/22 21:05, Henning Schild wrote:
> Am Thu, 21 Apr 2022 19:43:47 +0200
> schrieb Henning Schild <henning...@siemens.com>:
>
>> I learned yesterday about systemd-repart
>
> This currently needs >= bookworm to even start playing with systemd >=
> 250.1-2
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D976959&data=05%7C01%7Ctobias.schaffner%40siemens.com%7C045ffc25cea442b91a7808da23c9e432%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637861648059484524%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Zlq1hF7%2BbE5FS3gayX6jhaVzykvJNrwc1lhITORUZ%2BU%3D&reserved=0
> This currently needs >= bookworm to even start playing with systemd >=
> 250.1-2
>
Henning Schild
Apr 22, 2022, 3:21:11 AM4/22/22
to Tobias Schaffner, Jan Kiszka, isar-users, Christian Storm
Am Fri, 22 Apr 2022 08:28:22 +0200
schrieb Tobias Schaffner <tobias.s...@siemens.com>:
> Switching to systemd-repart would also fix a rare race condition.
> Expand-on-first-boot can cause systemd to not be able to mount its
> mount units if it makes the kernel reload the partition table in a
> bad moment.
I do not think we will be able to replace expand-on-first-boot entirely
with systemd-repart. Having distros which do not support that yet and
potentially having images without systemd even.
So if there is such a race a fix for it would be highly appreciated.
Could be a matter of unit dependencies.
In fact i will look into adding a test for expansion to CI.
Can be done with qemu-img resize or maybe a wic spacer and installing
"expand-on-first-boot".
Henning
schrieb Tobias Schaffner <tobias.s...@siemens.com>:
> Switching to systemd-repart would also fix a rare race condition.
> Expand-on-first-boot can cause systemd to not be able to mount its
> mount units if it makes the kernel reload the partition table in a
> bad moment.
with systemd-repart. Having distros which do not support that yet and
potentially having images without systemd even.
So if there is such a race a fix for it would be highly appreciated.
Could be a matter of unit dependencies.
In fact i will look into adding a test for expansion to CI.
Can be done with qemu-img resize or maybe a wic spacer and installing
"expand-on-first-boot".
Henning
Jan Kiszka
Apr 22, 2022, 5:08:07 AM4/22/22
to Tobias Schaffner, Henning Schild, isar-users, Christian Storm
On 22.04.22 08:28, Tobias Schaffner wrote:
> Switching to systemd-repart would also fix a rare race condition.
> Expand-on-first-boot can cause systemd to not be able to mount its mount
> units if it makes the kernel reload the partition table in a bad moment.
>
That is to be proven, but it would be valuable to check. I just "lost"
> Switching to systemd-repart would also fix a rare race condition.
> Expand-on-first-boot can cause systemd to not be able to mount its mount
> units if it makes the kernel reload the partition table in a bad moment.
>
my reproduction case on the IOT2050 by dropping the pattern that
triggered it. If you still have it, please check that!
Jan
PS: Avoid top-posing on mailing lists ;)
Anton Mikanovich
May 14, 2022, 10:05:44 AM5/14/22
to Jan Kiszka, isar-users, Christian Storm
21.04.2022 20:10, Jan Kiszka wrote:
> From: Jan Kiszka <jan.k...@siemens.com>
>
> When the rootfs is inside a devicemapper volume, e.g. dm-verity, the
> script so far fails to identify the boot device. This adds at least
> basic support for that case (single level, single slave). Once there is
> a good example for more complex setups, this could be taken into account
> as well.
>
> Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
Applied to next, thanks.
> From: Jan Kiszka <jan.k...@siemens.com>
>
> When the rootfs is inside a devicemapper volume, e.g. dm-verity, the
> script so far fails to identify the boot device. This adds at least
> basic support for that case (single level, single slave). Once there is
> a good example for more complex setups, this could be taken into account
> as well.
>
> Signed-off-by: Jan Kiszka <jan.k...@siemens.com>
Moessbauer, Felix
May 19, 2022, 7:51:04 AM5/19/22
to jan.k...@siemens.com, christi...@siemens.com, isar-users, Anton Mikanovich
$> mount | grep sda
/dev/sda2 on / type ext4 (rw,relatime)
/dev/sda1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
With this layout, the service fails with the following error:
Boot device equals root device - no partitioning found
@Jan: It looks like the check of the device slaves is not sane.
Could you please have a second look and try to fix it?
It also makes me wonder why the CI did not find it.
Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to isar-users+...@googlegroups.com.
> To view this discussion on the web visit
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.g
> oogle.com%2Fd%2Fmsgid%2Fisar-users%2Fa016bb05-21c1-e179-68cc-
> f1d96311e210%2540ilbers.de&data=05%7C01%7Cfelix.moessbauer%40sie
> mens.com%7Ce400a882e3df426ed81508da35b2d6e4%7C38ae3bcd95794fd4ad
> dab42e1495d55a%7C1%7C0%7C637881340185739960%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C2000%7C%7C%7C&sdata=SKokXmDUdxOGDDRMs4pn4VUu4bv
> WO5iDgl%2BwBWT2lsI%3D&reserved=0.
Henning Schild
May 19, 2022, 8:23:15 AM5/19/22
to Moessbauer, Felix, jan.k...@siemens.com, christi...@siemens.com, isar-users, Anton Mikanovich, Schmidl, Tobias
Am Thu, 19 May 2022 11:51:01 +0000
schrieb "Moessbauer, Felix" <felix.mo...@siemens.com>:
I think expand is not covered in any of our CI configs. We currently
have Tobias working on systemd growfs and repart, and might see more
testing coming with his patches. Hopefully including also a "qemu-img
convert resize" to see it grow and possibly check that it really did.
Henning
schrieb "Moessbauer, Felix" <felix.mo...@siemens.com>:
have Tobias working on systemd growfs and repart, and might see more
testing coming with his patches. Hopefully including also a "qemu-img
convert resize" to see it grow and possibly check that it really did.
Henning
Reply all
Reply to author
Forward
0 new messages