| Message ID | 20240307193409.987235-1-bruce.ashfield@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] linux-yocto: for-test-only: fix parted ptest | expand |
Hi Bruce,
This patch seems to fix the parted ptest problems, but now util-linux
ptest is failing :-(
Also seems to be partition resize related:
AssertionError: Failed ptests:
{'util-linux': ['fdisk:_gpt-resize']}
Steve
On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> From: Bruce Ashfield <bruce.ashfield@gmail.com>
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> ---
> ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +++++++++
> ...-support-partitions-without-scanning.patch | 87 +++++++++++++++++++
> meta/recipes-kernel/linux/linux-yocto_5.15.bb | 4 +
> 3 files changed, 134 insertions(+)
> create mode 100644 meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> create mode 100644 meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
>
> diff --git a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> new file mode 100644
> index 0000000000..cde4f317e9
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> @@ -0,0 +1,43 @@
> +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
> +From: Ming Lei <ming.lei@redhat.com>
> +Date: Tue, 23 Aug 2022 18:38:19 +0800
> +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set
> +
> +Commit b9684a71fca7 ("block, loop: support partitions without scanning")
> +adds GD_SUPPRESS_PART_SCAN for replacing part function of
> +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
> +loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
> +And it causes regression on libblockdev (as called from udisks) which
> +operates with the LO_FLAGS_PARTSCAN.
> +
> +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
> +set.
> +
> +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
> +
> +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
> +Signed-off-by: Ming Lei <ming.lei@redhat.com>
> +Reviewed-by: Christoph Hellwig <hch@lst.de>
> +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming.lei@redhat.com
> +Signed-off-by: Jens Axboe <axboe@kernel.dk>
> +---
> + block/partitions/core.c | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/block/partitions/core.c b/block/partitions/core.c
> +index fc1d70384825..b8112f52d388 100644
> +--- a/block/partitions/core.c
> ++++ b/block/partitions/core.c
> +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
> + if (disk->flags & GENHD_FL_NO_PART)
> + return 0;
> +
> ++ if (test_bit(GD_SUPPRESS_PART_SCAN, &disk->state))
> ++ return 0;
> ++
> + state = check_partition(disk);
> + if (!state)
> + return 0;
> +--
> +2.39.2
> +
> diff --git a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> new file mode 100644
> index 0000000000..9522c2d2cc
> --- /dev/null
> +++ b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> @@ -0,0 +1,87 @@
> +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
> +From: Christoph Hellwig <hch@lst.de>
> +Date: Fri, 27 May 2022 07:58:06 +0200
> +Subject: [PATCH] block, loop: support partitions without scanning
> +
> +Historically we did distinguish between a flag that surpressed partition
> +scanning, and a combinations of the minors variable and another flag if
> +any partitions were supported. This was generally confusing and doesn't
> +make much sense, but some corner case uses of the loop driver actually
> +do want to support manually added partitions on a device that does not
> +actively scan for partitions. To make things worsee the loop driver
> +also wants to dynamically toggle the scanning for partitions on a live
> +gendisk, which makes the disk->flags updates non-atomic.
> +
> +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
> +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
> +in the loop driver.
> +
> +Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1]
> +
> +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
> +Reported-by: Ming Lei <ming.lei@redhat.com>
> +Signed-off-by: Christoph Hellwig <hch@lst.de>
> +Reviewed-by: Ming Lei <ming.lei@redhat.com>
> +Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de
> +Signed-off-by: Jens Axboe <axboe@kernel.dk>
> +Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
> +---
> + drivers/block/loop.c | 8 ++++----
> + include/linux/blkdev.h | 1 +
> + 2 files changed, 5 insertions(+), 4 deletions(-)
> +
> +diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> +index 4769caab9ff9..a76302450c46 100644
> +--- a/drivers/block/loop.c
> ++++ b/drivers/block/loop.c
> +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, fmode_t mode,
> + lo->lo_flags |= LO_FLAGS_PARTSCAN;
> + partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
> + if (partscan)
> +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
> ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
> +
> + /* enable and uncork uevent now that we are done */
> + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
> +@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool release)
> + mutex_lock(&lo->lo_mutex);
> + lo->lo_flags = 0;
> + if (!part_shift)
> +- lo->lo_disk->flags |= GENHD_FL_NO_PART;
> ++ set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
> + lo->lo_state = Lo_unbound;
> + mutex_unlock(&lo->lo_mutex);
> +
> +@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
> +
> + if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) &&
> + !(prev_lo_flags & LO_FLAGS_PARTSCAN)) {
> +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
> ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state);
> + partscan = true;
> + }
> + out_unlock:
> +@@ -2428,7 +2428,7 @@ static int loop_add(int i)
> + * userspace tools. Parameters like this in general should be avoided.
> + */
> + if (!part_shift)
> +- disk->flags |= GENHD_FL_NO_PART;
> ++ set_bit(GD_SUPPRESS_PART_SCAN, &disk->state);
> + disk->flags |= GENHD_FL_EXT_DEVT;
> + atomic_set(&lo->lo_refcnt, 0);
> + mutex_init(&lo->lo_mutex);
> +diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> +index 905844172cfd..15815f1ced9e 100644
> +--- a/include/linux/blkdev.h
> ++++ b/include/linux/blkdev.h
> +@@ -813,6 +813,7 @@ static inline unsigned int blk_queue_depth(struct request_queue *q)
> + */
> + #define BLK_DEFAULT_SG_TIMEOUT (60 * HZ)
> + #define BLK_MIN_SG_TIMEOUT (7 * HZ)
> ++#define GD_SUPPRESS_PART_SCAN 5
> +
> + struct rq_map_data {
> + struct page **pages;
> +--
> +2.39.2
> +
> diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
> index 1c6b3d1112..17d36524f7 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
> @@ -38,6 +38,10 @@ KBRANCH:class-devupstream = "v5.15/base"
> SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
>
> +SRC_URI += "file://0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch"
> +SRC_URI += "file://0001-block-loop-support-partitions-without-scanning.patch"
> +
> +
> LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
> LINUX_VERSION ?= "5.15.149"
>
> --
> 2.39.2
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#196820): https://lists.openembedded.org/g/openembedded-core/message/196820
> Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
Adding Kevin, I'm not going to be able to debug this more for a week or so. The alternate ways to fix it would be to try that ubuntu patch (fixed for our tree), and / or see what else needs to be cherry picked to -stable to fix util-linux. It is likely just a return code difference to userspace when resizing is being done. Kevin: I'm not sure if Wind River is seeing this, but you might want to look into those ptests and see if they pass on your end. Bruce On Thu, Mar 7, 2024 at 6:05 PM Steve Sakoman <steve@sakoman.com> wrote: > > Hi Bruce, > > This patch seems to fix the parted ptest problems, but now util-linux > ptest is failing :-( > > Also seems to be partition resize related: > > AssertionError: Failed ptests: > {'util-linux': ['fdisk:_gpt-resize']} > > Steve > > On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > From: Bruce Ashfield <bruce.ashfield@gmail.com> > > > > Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> > > --- > > ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +++++++++ > > ...-support-partitions-without-scanning.patch | 87 +++++++++++++++++++ > > meta/recipes-kernel/linux/linux-yocto_5.15.bb | 4 + > > 3 files changed, 134 insertions(+) > > create mode 100644 meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch > > create mode 100644 meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch > > > > diff --git a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch > > new file mode 100644 > > index 0000000000..cde4f317e9 > > --- /dev/null > > +++ b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch > > @@ -0,0 +1,43 @@ > > +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001 > > +From: Ming Lei <ming.lei@redhat.com> > > +Date: Tue, 23 Aug 2022 18:38:19 +0800 > > +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set > > + > > +Commit b9684a71fca7 ("block, loop: support partitions without scanning") > > +adds GD_SUPPRESS_PART_SCAN for replacing part function of > > +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since > > +loop doesn't want to add partitions if GENHD_FL_NO_PART was set. > > +And it causes regression on libblockdev (as called from udisks) which > > +operates with the LO_FLAGS_PARTSCAN. > > + > > +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is > > +set. > > + > > +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c] > > + > > +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning") > > +Signed-off-by: Ming Lei <ming.lei@redhat.com> > > +Reviewed-by: Christoph Hellwig <hch@lst.de> > > +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming.lei@redhat.com > > +Signed-off-by: Jens Axboe <axboe@kernel.dk> > > +--- > > + block/partitions/core.c | 3 +++ > > + 1 file changed, 3 insertions(+) > > + > > +diff --git a/block/partitions/core.c b/block/partitions/core.c > > +index fc1d70384825..b8112f52d388 100644 > > +--- a/block/partitions/core.c > > ++++ b/block/partitions/core.c > > +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk) > > + if (disk->flags & GENHD_FL_NO_PART) > > + return 0; > > + > > ++ if (test_bit(GD_SUPPRESS_PART_SCAN, &disk->state)) > > ++ return 0; > > ++ > > + state = check_partition(disk); > > + if (!state) > > + return 0; > > +-- > > +2.39.2 > > + > > diff --git a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch > > new file mode 100644 > > index 0000000000..9522c2d2cc > > --- /dev/null > > +++ b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch > > @@ -0,0 +1,87 @@ > > +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001 > > +From: Christoph Hellwig <hch@lst.de> > > +Date: Fri, 27 May 2022 07:58:06 +0200 > > +Subject: [PATCH] block, loop: support partitions without scanning > > + > > +Historically we did distinguish between a flag that surpressed partition > > +scanning, and a combinations of the minors variable and another flag if > > +any partitions were supported. This was generally confusing and doesn't > > +make much sense, but some corner case uses of the loop driver actually > > +do want to support manually added partitions on a device that does not > > +actively scan for partitions. To make things worsee the loop driver > > +also wants to dynamically toggle the scanning for partitions on a live > > +gendisk, which makes the disk->flags updates non-atomic. > > + > > +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables > > +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART > > +in the loop driver. > > + > > +Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1] > > + > > +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") > > +Reported-by: Ming Lei <ming.lei@redhat.com> > > +Signed-off-by: Christoph Hellwig <hch@lst.de> > > +Reviewed-by: Ming Lei <ming.lei@redhat.com> > > +Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de > > +Signed-off-by: Jens Axboe <axboe@kernel.dk> > > +Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> > > +--- > > + drivers/block/loop.c | 8 ++++---- > > + include/linux/blkdev.h | 1 + > > + 2 files changed, 5 insertions(+), 4 deletions(-) > > + > > +diff --git a/drivers/block/loop.c b/drivers/block/loop.c > > +index 4769caab9ff9..a76302450c46 100644 > > +--- a/drivers/block/loop.c > > ++++ b/drivers/block/loop.c > > +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, > > + lo->lo_flags |= LO_FLAGS_PARTSCAN; > > + partscan = lo->lo_flags & LO_FLAGS_PARTSCAN; > > + if (partscan) > > +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; > > ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); > > + > > + /* enable and uncork uevent now that we are done */ > > + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); > > +@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool release) > > + mutex_lock(&lo->lo_mutex); > > + lo->lo_flags = 0; > > + if (!part_shift) > > +- lo->lo_disk->flags |= GENHD_FL_NO_PART; > > ++ set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); > > + lo->lo_state = Lo_unbound; > > + mutex_unlock(&lo->lo_mutex); > > + > > +@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info) > > + > > + if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) && > > + !(prev_lo_flags & LO_FLAGS_PARTSCAN)) { > > +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; > > ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); > > + partscan = true; > > + } > > + out_unlock: > > +@@ -2428,7 +2428,7 @@ static int loop_add(int i) > > + * userspace tools. Parameters like this in general should be avoided. > > + */ > > + if (!part_shift) > > +- disk->flags |= GENHD_FL_NO_PART; > > ++ set_bit(GD_SUPPRESS_PART_SCAN, &disk->state); > > + disk->flags |= GENHD_FL_EXT_DEVT; > > + atomic_set(&lo->lo_refcnt, 0); > > + mutex_init(&lo->lo_mutex); > > +diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h > > +index 905844172cfd..15815f1ced9e 100644 > > +--- a/include/linux/blkdev.h > > ++++ b/include/linux/blkdev.h > > +@@ -813,6 +813,7 @@ static inline unsigned int blk_queue_depth(struct request_queue *q) > > + */ > > + #define BLK_DEFAULT_SG_TIMEOUT (60 * HZ) > > + #define BLK_MIN_SG_TIMEOUT (7 * HZ) > > ++#define GD_SUPPRESS_PART_SCAN 5 > > + > > + struct rq_map_data { > > + struct page **pages; > > +-- > > +2.39.2 > > + > > diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb b/meta/recipes-kernel/linux/linux-yocto_5.15.bb > > index 1c6b3d1112..17d36524f7 100644 > > --- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb > > +++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb > > @@ -38,6 +38,10 @@ KBRANCH:class-devupstream = "v5.15/base" > > SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \ > > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}" > > > > +SRC_URI += "file://0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch" > > +SRC_URI += "file://0001-block-loop-support-partitions-without-scanning.patch" > > + > > + > > LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" > > LINUX_VERSION ?= "5.15.149" > > > > -- > > 2.39.2 > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196825): https://lists.openembedded.org/g/openembedded-core/message/196825 > Mute This Topic: https://lists.openembedded.org/mt/104794844/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote: > Adding Kevin, > > I'm not going to be able to debug this more for a week or so. > > The alternate ways to fix it would be to try that ubuntu patch (fixed > for our tree), and / or see what else needs > to be cherry picked to -stable to fix util-linux. It is likely just a > return code difference to userspace when > resizing is being done. > > Kevin: I'm not sure if Wind River is seeing this, but you might want to look > into those ptests and see if they pass on your end. A silly question, which branch are these three patches supposed to apply to? I have tried the kirkstone branch, but it seems that they can't apply cleanly. I also tried to manually apply the two kernel patches to the latest linux-yocto/v5.15/standard/base branch, but they also can't be applied cleanly. Am I miss something? On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest does have three failures. Then I have tried the ubuntu kernel patch [1] which is mentioned in the previous discussion about this issue. This patch can apply to the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted failures, and I also don't find util-linux ptest failure after applying this patch. I attached my logs. [1] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1&id=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9 Thanks, Kevin START: ptest-runner 2024-03-08T13:02 BEGIN: /usr/lib/parted/ptest make: Entering directory '/usr/lib/parted/ptest/tests' PASS: help-version.sh PASS: t0000-basic.sh PASS: t0001-tiny.sh PASS: t0010-script-no-ctrl-chars.sh PASS: t0100-print.sh PASS: t0101-print-empty.sh PASS: t0200-gpt.sh PASS: t0201-gpt.sh PASS: t0202-gpt-pmbr.sh PASS: t0203-gpt-tiny-device-abort.sh PASS: t0203-gpt-shortened-device-primary-valid.sh PASS: t0203-gpt-create-on-min-sized-device.sh PASS: t0205-gpt-list-clobbers-pmbr.sh PASS: t0206-gpt-print-with-corrupt-primary-clobbers-pmbr.sh PASS: t0207-IEC-binary-notation.sh PASS: t0208-mkpart-end-in-IEC.sh PASS: t0209-gpt-pmbr_boot.sh t0210-gpt-resized-partition-entry-array.sh: skipped test: this test requires Perl's Digest::CRC module SKIP: t0210-gpt-resized-partition-entry-array.sh t0211-gpt-rewrite-header.sh: skipped test: this test requires Perl's Digest::CRC module SKIP: t0211-gpt-rewrite-header.sh PASS: t0212-gpt-many-partitions.sh PASS: t0213-mkpart-start-negative.sh PASS: t0220-gpt-msftres.sh PASS: t0250-gpt.sh PASS: t0251-gpt-unicode.sh PASS: t0280-gpt-corrupt.sh PASS: t0281-gpt-grow.sh PASS: t0282-gpt-move-backup.sh PASS: t0283-overlap-partitions.sh PASS: t0300-dos-on-gpt.sh PASS: t0301-overwrite-gpt-pmbr.sh PASS: t0350-mac-PT-increases-sector-size.sh PASS: t0400-loop-clobber-infloop.sh PASS: t0500-dup-clobber.sh PASS: t0501-duplicate.sh t1100-busy-label.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1100-busy-label.sh t1101-busy-partition.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1101-busy-partition.sh t1102-loop-label.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1102-loop-label.sh PASS: t1104-remove-and-add-partition.sh : no xfs support : no nilfs2 support : no ntfs support : no hfsplus support : no udf support : no f2fs support PASS: t1700-probe-fs.sh t1701-rescue-fs.sh: skipped test: you lack the scsi_debug kernel module SKIP: t1701-rescue-fs.sh PASS: t2200-dos-label-recog.sh PASS: t2201-pc98-label-recog.sh PASS: t2300-dos-label-extended-bootcode.sh t2310-dos-extended-2-sector-min-offset.sh: skipped test: you lack the scsi_debug kernel module SKIP: t2310-dos-extended-2-sector-min-offset.sh t2320-dos-extended-noclobber.sh: skipped test: you lack the scsi_debug kernel module SKIP: t2320-dos-extended-noclobber.sh PASS: t2400-dos-hfs-partition-type.sh PASS: t2410-dos-udf-partition-type.sh PASS: t2500-probe-corrupt-hfs.sh t3000-resize-fs.sh: skipped test: mkfs.hfs: command not found SKIP: t3000-resize-fs.sh t3200-resize-partition.sh: skipped test: you lack the scsi_debug kernel module SKIP: t3200-resize-partition.sh t3200-type-change.sh: skipped test: you lack the scsi_debug kernel module SKIP: t3200-type-change.sh PASS: t3300-palo-prep.sh PASS: t3310-flags.sh PASS: t3400-whole-disk-FAT-partition.sh PASS: t4000-sun-raid-type.sh PASS: t4001-sun-vtoc.sh t4100-msdos-partition-limits.sh: skipped test: this test requires XFS support SKIP: t4100-msdos-partition-limits.sh t4100-dvh-partition-limits.sh: skipped test: this test requires XFS support SKIP: t4100-dvh-partition-limits.sh PASS: t4100-msdos-starting-sector.sh t4200-partprobe.sh: skipped test: This test requires an erasable device and you have not properly set the $DEVICE_TO_ERASE and $DEVICE_TO_ERASE_SIZE envvars. SKIP: t4200-partprobe.sh PASS: t4300-nilfs2-tiny.sh PASS: t4301-nilfs2-badsb2.sh PASS: t4302-nilfs2-lessbadsb2.sh PASS: t5000-tags.sh t6000-dm.sh: skipped test: no device-mapper support SKIP: t6000-dm.sh t6001-psep.sh: skipped test: no device-mapper support SKIP: t6001-psep.sh t6002-dm-busy.sh: skipped test: no device-mapper support SKIP: t6002-dm-busy.sh t6003-dm-hide.sh: skipped test: no device-mapper support SKIP: t6003-dm-hide.sh t6004-dm-many-partitions.sh: skipped test: no device-mapper support SKIP: t6004-dm-many-partitions.sh t6005-dm-uuid.sh: skipped test: no device-mapper support SKIP: t6005-dm-uuid.sh t6006-dm-512b-sectors.sh: skipped test: you lack the scsi_debug kernel module SKIP: t6006-dm-512b-sectors.sh t6100-mdraid-partitions.sh: skipped test: you lack the scsi_debug kernel module SKIP: t6100-mdraid-partitions.sh PASS: t7000-scripting.sh PASS: t8000-loop.sh PASS: t8001-loop-blkpg.sh t9010-big-sector.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9010-big-sector.sh t9020-alignment.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9020-alignment.sh PASS: t9021-maxima.sh PASS: t9022-one-unit-snap.sh PASS: t9023-value-lt-one.sh t9030-align-check.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9030-align-check.sh t9040-many-partitions.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9040-many-partitions.sh t9041-undetected-in-use-16th-partition.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9041-undetected-in-use-16th-partition.sh t9042-dos-partition-limit.sh: skipped test: you lack the scsi_debug kernel module SKIP: t9042-dos-partition-limit.sh PASS: t9050-partition-table-types.sh ============================================================================ Testsuite summary for GNU parted 3.4 ============================================================================ # TOTAL: 85 # PASS: 57 # SKIP: 28 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ make: Leaving directory '/usr/lib/parted/ptest/tests' DURATION: 11 END: /usr/lib/parted/ptest 2024-03-08T13:02 STOP: ptest-runner TOTAL: 1 FAIL: 0 START: ptest-runner 2024-03-08T13:03 BEGIN: /usr/lib/util-linux/ptest Stopping udevd ./tests/run.sh: line 169: /usr/lib/util-linux/ptest/tests/../meson.conf: No such file or directory -------------------- util-linux regression tests -------------------- For development purpose only. Don't execute on production system! kernel: 5.15.150-yocto-standard+ options: --use-system-commands \ --parsable \ --show-diff \ --srcdir=/usr/lib/util-linux/ptest/tests/.. \ --builddir=/usr/lib/util-linux/ptest/tests/.. PASS: bitops: swap bytes PASS: blkdiscard: offsets SKIP: blkid: DM error (missing in PATH: dmsetup) PASS: blkid: superblocks probing: [01] adaptec-raid PASS: blkid: superblocks probing: [02] bcache-B PASS: blkid: superblocks probing: [03] bcache-C PASS: blkid: superblocks probing: [04] befs PASS: blkid: superblocks probing: [05] bfs PASS: blkid: superblocks probing: [06] bluestore PASS: blkid: superblocks probing: [07] cramfs PASS: blkid: superblocks probing: [08] ddf-raid PASS: blkid: superblocks probing: [09] drbd-v08 PASS: blkid: superblocks probing: [10] drbd-v09 PASS: blkid: superblocks probing: [11] drbdmanage-control-volume PASS: blkid: superblocks probing: [12] erofs PASS: blkid: superblocks probing: [13] exfat PASS: blkid: superblocks probing: [14] ext2 PASS: blkid: superblocks probing: [15] ext3 PASS: blkid: superblocks probing: [16] f2fs PASS: blkid: superblocks probing: [17] fat PASS: blkid: superblocks probing: [18] fat16_noheads PASS: blkid: superblocks probing: [19] fat32_cp850_O_tilde PASS: blkid: superblocks probing: [20] fat32_label_64MB PASS: blkid: superblocks probing: [21] fat32_mkdosfs_label1 PASS: blkid: superblocks probing: [22] fat32_mkdosfs_label1_dosfslabel_NO_NAME PASS: blkid: superblocks probing: [23] fat32_mkdosfs_label1_dosfslabel_empty PASS: blkid: superblocks probing: [24] fat32_mkdosfs_label1_dosfslabel_label2 PASS: blkid: superblocks probing: [25] fat32_mkdosfs_label1_mlabel_NO_NAME PASS: blkid: superblocks probing: [26] fat32_mkdosfs_label1_mlabel_erase PASS: blkid: superblocks probing: [27] fat32_mkdosfs_label1_xp_erase PASS: blkid: superblocks probing: [28] fat32_mkdosfs_label1_xp_label2 PASS: blkid: superblocks probing: [29] fat32_mkdosfs_none PASS: blkid: superblocks probing: [30] fat32_mkdosfs_none_dosfslabel_NO_NAME PASS: blkid: superblocks probing: [31] fat32_mkdosfs_none_dosfslabel_label1 PASS: blkid: superblocks probing: [32] fat32_mkdosfs_none_dosfslabel_label1_xp_label2 PASS: blkid: superblocks probing: [33] fat32_mkdosfs_none_xp_label1 PASS: blkid: superblocks probing: [34] fat32_mkdosfs_none_xp_label1_dosfslabel_label2 PASS: blkid: superblocks probing: [35] fat32_xp_label1 PASS: blkid: superblocks probing: [36] fat32_xp_none PASS: blkid: superblocks probing: [37] fat32_xp_none_dosfslabel_label1 PASS: blkid: superblocks probing: [38] fat32_xp_none_mlabel_label1 PASS: blkid: superblocks probing: [39] gfs2 PASS: blkid: superblocks probing: [40] hfs PASS: blkid: superblocks probing: [41] hfsplus PASS: blkid: superblocks probing: [42] hpfs PASS: blkid: superblocks probing: [43] hpt37x-raid PASS: blkid: superblocks probing: [44] hpt45x-raid PASS: blkid: superblocks probing: [45] iso-different-iso-joliet-label PASS: blkid: superblocks probing: [46] iso-joliet PASS: blkid: superblocks probing: [47] iso-multi-genisoimage-0 PASS: blkid: superblocks probing: [48] iso-multi-genisoimage-174 PASS: blkid: superblocks probing: [49] iso-multi-genisoimage-348 PASS: blkid: superblocks probing: [50] iso-rr-joliet PASS: blkid: superblocks probing: [51] iso-unicode-long-label PASS: blkid: superblocks probing: [52] iso PASS: blkid: superblocks probing: [53] isw-raid PASS: blkid: superblocks probing: [54] jbd PASS: blkid: superblocks probing: [55] jfs PASS: blkid: superblocks probing: [56] jmicron-raid PASS: blkid: superblocks probing: [57] lsi-raid PASS: blkid: superblocks probing: [58] luks1 PASS: blkid: superblocks probing: [59] luks2 PASS: blkid: superblocks probing: [60] lvm2 PASS: blkid: superblocks probing: [61] mdraid PASS: blkid: superblocks probing: [62] minix-BE PASS: blkid: superblocks probing: [63] minix-LE PASS: blkid: superblocks probing: [64] mpool PASS: blkid: superblocks probing: [65] netware PASS: blkid: superblocks probing: [66] nilfs2 PASS: blkid: superblocks probing: [67] ntfs PASS: blkid: superblocks probing: [68] nvidia-raid PASS: blkid: superblocks probing: [69] ocfs2 PASS: blkid: superblocks probing: [70] promise-raid PASS: blkid: superblocks probing: [71] reiser3 PASS: blkid: superblocks probing: [72] reiser4 PASS: blkid: superblocks probing: [73] romfs PASS: blkid: superblocks probing: [74] silicon-raid PASS: blkid: superblocks probing: [75] small-fat32 PASS: blkid: superblocks probing: [76] swap0 PASS: blkid: superblocks probing: [77] swap1 PASS: blkid: superblocks probing: [78] tuxonice PASS: blkid: superblocks probing: [79] ubi PASS: blkid: superblocks probing: [80] ubifs PASS: blkid: superblocks probing: [81] udf-bdr-2.60-nero PASS: blkid: superblocks probing: [82] udf-cd-mkudfiso-20100208 PASS: blkid: superblocks probing: [83] udf-cd-nero-6 PASS: blkid: superblocks probing: [84] udf-hdd-macosx-2.60-4096 PASS: blkid: superblocks probing: [85] udf-hdd-mkudffs-1.0.0-1 PASS: blkid: superblocks probing: [86] udf-hdd-mkudffs-1.0.0-2 PASS: blkid: superblocks probing: [87] udf-hdd-mkudffs-1.3-1 PASS: blkid: superblocks probing: [88] udf-hdd-mkudffs-1.3-2 PASS: blkid: superblocks probing: [89] udf-hdd-mkudffs-1.3-3 PASS: blkid: superblocks probing: [90] udf-hdd-mkudffs-1.3-4 PASS: blkid: superblocks probing: [91] udf-hdd-mkudffs-1.3-5 PASS: blkid: superblocks probing: [92] udf-hdd-mkudffs-1.3-6 PASS: blkid: superblocks probing: [93] udf-hdd-mkudffs-1.3-7 PASS: blkid: superblocks probing: [94] udf-hdd-mkudffs-1.3-8 PASS: blkid: superblocks probing: [95] udf-hdd-mkudffs-2.2 PASS: blkid: superblocks probing: [96] udf-hdd-udfclient-0.7.5 PASS: blkid: superblocks probing: [97] udf-hdd-udfclient-0.7.7 PASS: blkid: superblocks probing: [98] udf-hdd-win7 PASS: blkid: superblocks probing: [99] udf-multi-mkudffs-0 PASS: blkid: superblocks probing: [100] udf-multi-mkudffs-320 PASS: blkid: superblocks probing: [101] udf-multi-mkudffs-640 PASS: blkid: superblocks probing: [102] udf-multi-genisoimage-0 PASS: blkid: superblocks probing: [103] udf-multi-genisoimage-417 PASS: blkid: superblocks probing: [104] udf-multi-genisoimage-834 PASS: blkid: superblocks probing: [105] udf PASS: blkid: superblocks probing: [106] ufs PASS: blkid: superblocks probing: [107] vdo PASS: blkid: superblocks probing: [108] via-raid PASS: blkid: superblocks probing: [109] vmfs PASS: blkid: superblocks probing: [110] vmfs_volume PASS: blkid: superblocks probing: [111] xfs-log PASS: blkid: superblocks probing: [112] xfs-v5 PASS: blkid: superblocks probing: [113] xfs PASS: blkid: superblocks probing: [114] zfs PASS: blkid: superblocks probing: [115] zonefs blkid: superblocks probing ... OK (all 115 sub-tests PASSED) PASS: blkid: partitions probing: [01] atari-primary PASS: blkid: partitions probing: [02] atari-xgm PASS: blkid: partitions probing: [03] bsd PASS: blkid: partitions probing: [04] dos+bsd PASS: blkid: partitions probing: [05] gpt PASS: blkid: partitions probing: [06] sgi PASS: blkid: partitions probing: [07] sun blkid: partitions probing ... OK (all 7 sub-tests PASSED) blkid: MD raid0 (whole-disks) ... KNOWN FAILED (blkid/md-raid0-whole) SKIP: blkid: MD raid1 (last partition) (missing scsi_debug module (dry-run)) blkid: MD raid1 (whole-disks) ... KNOWN FAILED (blkid/md-raid1-whole) SKIP: build-sys: config (optional) PASS: cal: Year 2147483646: [01] 1m-month PASS: cal: Year 2147483646: [02] 1s-month PASS: cal: Year 2147483646: [03] 1mj-month PASS: cal: Year 2147483646: [04] 1sj-month PASS: cal: Year 2147483646: [05] 3m-month PASS: cal: Year 2147483646: [06] 3s-month PASS: cal: Year 2147483646: [07] 3mj-month PASS: cal: Year 2147483646: [08] 3sj-month PASS: cal: Year 2147483646: [09] 1m-year PASS: cal: Year 2147483646: [10] 1s-year PASS: cal: Year 2147483646: [11] 1mj-year PASS: cal: Year 2147483646: [12] 1sj-year PASS: cal: Year 2147483646: [13] 1mw-month PASS: cal: Year 2147483646: [14] 1sw-month PASS: cal: Year 2147483646: [15] 1mjw-month PASS: cal: Year 2147483646: [16] 1sjw-month PASS: cal: Year 2147483646: [17] 3mw-month PASS: cal: Year 2147483646: [18] 3sw-month PASS: cal: Year 2147483646: [19] 3mjw-month PASS: cal: Year 2147483646: [20] 3sjw-month PASS: cal: Year 2147483646: [21] 1mw-year PASS: cal: Year 2147483646: [22] 1sw-year PASS: cal: Year 2147483646: [23] 1mjw-year PASS: cal: Year 2147483646: [24] 1sjw-year cal: Year 2147483646 ... OK (all 24 sub-tests PASSED) PASS: cal: color PASS: cal: color with week numbers PASS: cal: January 1753: [01] m3w PASS: cal: January 1753: [02] 3w cal: January 1753 ... OK (all 2 sub-tests PASSED) PASS: cal: month: [01] 1m PASS: cal: month: [02] 1s PASS: cal: month: [03] 1mj PASS: cal: month: [04] 1sj PASS: cal: month: [05] 1mw PASS: cal: month: [06] 1sw PASS: cal: month: [07] 1mjw PASS: cal: month: [08] 1sjw PASS: cal: month: [09] 3m PASS: cal: month: [10] 3s PASS: cal: month: [11] 3mj PASS: cal: month: [12] 3sj PASS: cal: month: [13] 3mw PASS: cal: month: [14] 3sw PASS: cal: month: [15] 3mjw PASS: cal: month: [16] 3sjw PASS: cal: month: [17] Sn3 PASS: cal: month: [18] Sn21 PASS: cal: month: [19] Sn51 PASS: cal: month: [20] Sn201 cal: month ... OK (all 20 sub-tests PASSED) PASS: cal: September 1752: [01] 1mw-month PASS: cal: September 1752: [02] 1sw-month PASS: cal: September 1752: [03] 1mjw-month PASS: cal: September 1752: [04] 1sjw-month PASS: cal: September 1752: [05] 3mw-month PASS: cal: September 1752: [06] 3sw-month PASS: cal: September 1752: [07] 3mjw-month PASS: cal: September 1752: [08] 3sjw-month PASS: cal: September 1752: [09] 1mw-year PASS: cal: September 1752: [10] 1sw-year PASS: cal: September 1752: [11] 1mjw-year PASS: cal: September 1752: [12] 1sjw-year PASS: cal: September 1752: [13] week-iso PASS: cal: September 1752: [14] 1m-month PASS: cal: September 1752: [15] 1s-month PASS: cal: September 1752: [16] 1mj-month PASS: cal: September 1752: [17] 1sj-month PASS: cal: September 1752: [18] 3m-month PASS: cal: September 1752: [19] 3s-month PASS: cal: September 1752: [20] 3mj-month PASS: cal: September 1752: [21] 3sj-month PASS: cal: September 1752: [22] 1m-year PASS: cal: September 1752: [23] 1s-year PASS: cal: September 1752: [24] 1mj-year PASS: cal: September 1752: [25] 1sj-year cal: September 1752 ... OK (all 25 sub-tests PASSED) PASS: cal: vertical: [01] 1mv PASS: cal: vertical: [02] 1sv PASS: cal: vertical: [03] 1mjv PASS: cal: vertical: [04] 1sjv PASS: cal: vertical: [05] 1mwv PASS: cal: vertical: [06] 1swv PASS: cal: vertical: [07] 1mjwv PASS: cal: vertical: [08] 1sjwv PASS: cal: vertical: [09] 3mv PASS: cal: vertical: [10] 3sv PASS: cal: vertical: [11] 3mjv PASS: cal: vertical: [12] 3sjv PASS: cal: vertical: [13] 3mwv PASS: cal: vertical: [14] 3swv PASS: cal: vertical: [15] 3mjwv PASS: cal: vertical: [16] 3sjwv PASS: cal: vertical: [17] vSn3 PASS: cal: vertical: [18] vSn21 PASS: cal: vertical: [19] vSn51 PASS: cal: vertical: [20] vSn201 cal: vertical ... OK (all 20 sub-tests PASSED) PASS: cal: week number given as argument: [01] 3m-week40 PASS: cal: week number given as argument: [02] 3s-week40 PASS: cal: week number given as argument: [03] 3mj-week40 PASS: cal: week number given as argument: [04] 3sj-week40 PASS: cal: week number given as argument: [05] m-week40 PASS: cal: week number given as argument: [06] s-week40 PASS: cal: week number given as argument: [07] mj-week40 PASS: cal: week number given as argument: [08] sj-week40 PASS: cal: week number given as argument: [09] 3m-week40-color PASS: cal: week number given as argument: [10] 3mj-week40-color PASS: cal: week number given as argument: [11] 1m-week53 PASS: cal: week number given as argument: [12] 1mj-week53 PASS: cal: week number given as argument: [13] 3m-week53-color PASS: cal: week number given as argument: [14] 1m-week53-color PASS: cal: week number given as argument: [15] 1mj-week53-color PASS: cal: week number given as argument: [16] 3s-week54-color PASS: cal: week number given as argument: [17] 3m-week52-color cal: week number given as argument ... OK (all 17 sub-tests PASSED) PASS: cal: week number corner cases: [01] ymw PASS: cal: week number corner cases: [02] ysw PASS: cal: week number corner cases: [03] ymjw PASS: cal: week number corner cases: [04] ysjw PASS: cal: week number corner cases: [05] 3mw PASS: cal: week number corner cases: [06] 3sw PASS: cal: week number corner cases: [07] 3mjw PASS: cal: week number corner cases: [08] 3sjw cal: week number corner cases ... OK (all 8 sub-tests PASSED) PASS: cal: year: [01] ym PASS: cal: year: [02] ys PASS: cal: year: [03] ymj PASS: cal: year: [04] ysj PASS: cal: year: [05] ymw PASS: cal: year: [06] ysw PASS: cal: year: [07] ymjw PASS: cal: year: [08] ysjw cal: year ... OK (all 8 sub-tests PASSED) PASS: col: io effects PASS: col: multibyte input: [01] valid PASS: col: multibyte input: [02] invalid col: multibyte input ... OK (all 2 sub-tests PASSED) PASS: col: newline handling PASS: col: options PASS: colcrt: functional: [01] no-options PASS: colcrt: functional: [02] no-underlining PASS: colcrt: functional: [03] half-lines PASS: colcrt: functional: [04] short-options colcrt: functional ... OK (all 4 sub-tests PASSED) PASS: colcrt: regressions: [01] crash1 PASS: colcrt: regressions: [02] crash2 PASS: colcrt: regressions: [03] hang1 colcrt: regressions ... OK (all 3 sub-tests PASSED) PASS: colrm: basic check PASS: column: columnate: [01] fill-cols-80 PASS: column: columnate: [02] fill-cols-50 PASS: column: columnate: [03] fill-cols-250 PASS: column: columnate: [04] fill-rows-80 PASS: column: columnate: [05] fill-rows-50 PASS: column: columnate: [06] fill-rows-250 column: columnate ... OK (all 6 sub-tests PASSED) PASS: column: invalid multibyte PASS: column: multiple files PASS: column: table: [01] default PASS: column: table: [02] output-separator PASS: column: table: [03] input-separator PASS: column: table: [04] input-separator-space PASS: column: table: [05] empty-lines PASS: column: table: [06] noempty-lines PASS: column: table: [07] long PASS: column: table: [08] hide PASS: column: table: [09] headers PASS: column: table: [10] truncate PASS: column: table: [11] right PASS: column: table: [12] wrap PASS: column: table: [13] order PASS: column: table: [14] tree PASS: column: table: [15] empty-column PASS: column: table: [16] empty-column-at-eol PASS: column: table: [17] empty-column-at-eol2 column: table ... OK (all 17 sub-tests PASSED) SKIP: cramfs: mkfs doubles (mount: /usr/lib/util-linux/ptest/tests/output/cramfs/doubles-mnt: unknown filesystem type 'cramfs'.) PASS: cramfs: fsck bad header: [01] nopad-4K-be PASS: cramfs: fsck bad header: [02] nopad-4K-le PASS: cramfs: fsck bad header: [03] pad-4K-be PASS: cramfs: fsck bad header: [04] pad-4K-le PASS: cramfs: fsck bad header: [05] pad-64K-be PASS: cramfs: fsck bad header: [06] pad-64K-le cramfs: fsck bad header ... OK (all 6 sub-tests PASSED) PASS: cramfs: fsck endianness SKIP: cramfs: mkfs checksums (mount: /usr/lib/util-linux/ptest/tests/output/cramfs/mkfs-mnt: unknown filesystem type 'cramfs'.) PASS: cramfs: mkfs endianness PASS: dmesg: colors PASS: dmesg: levels PASS: dmesg: decode PASS: dmesg: delta PASS: dmesg: facilities PASS: dmesg: indentation SKIP: eject: umount: [01] by-disk (missing scsi_debug module (dry-run)) SKIP: fdisk: align 512/4K (missing scsi_debug module (dry-run)) SKIP: fdisk: align 512/4K +alignment_offset (missing scsi_debug module (dry-run)) SKIP: fdisk: align 512/4K +MD (missing scsi_debug module (dry-run)) PASS: fdisk: align 512/512 SKIP: fdisk: align 512/512 +topology (missing scsi_debug module (dry-run)) PASS: fdisk: nested BSD PASS: fdisk: GPT PASS: fdisk: gpt-resize PASS: fdisk: MBR - id PASS: fdisk: MBR - dos mode PASS: fdisk: MBR - non-dos mode: [01] empty-pt PASS: fdisk: MBR - non-dos mode: [02] 1st-primary PASS: fdisk: MBR - non-dos mode: [03] 1st-active PASS: fdisk: MBR - non-dos mode: [04] 1st-primary-recreate PASS: fdisk: MBR - non-dos mode: [05] 2nd-primary PASS: fdisk: MBR - non-dos mode: [06] extended PASS: fdisk: MBR - non-dos mode: [07] logical PASS: fdisk: MBR - non-dos mode: [08] logical-delete PASS: fdisk: MBR - non-dos mode: [09] logical-recreate PASS: fdisk: MBR - non-dos mode: [10] 1st-primary-delete PASS: fdisk: MBR - non-dos mode: [11] 1nd-primary-delete PASS: fdisk: MBR - non-dos mode: [12] extended-delete PASS: fdisk: MBR - non-dos mode: [13] first-sector-at-end fdisk: MBR - non-dos mode ... OK (all 13 sub-tests PASSED) PASS: fdisk: MBR - sort PASS: fdisk: invalid input tests PASS: fdisk: sunlabel tests PASS: fincore: count file contents in core PASS: findmnt: filter: [01] types PASS: findmnt: filter: [02] types-multi PASS: findmnt: filter: [03] types-neg PASS: findmnt: filter: [04] options PASS: findmnt: filter: [05] options-name PASS: findmnt: filter: [06] options-nameval PASS: findmnt: filter: [07] options-nameval-neg PASS: findmnt: filter: [08] options-nameval-multi PASS: findmnt: filter: [09] options-neg PASS: findmnt: filter: [10] options-no PASS: findmnt: filter: [11] options-no-multi findmnt: filter ... OK (all 11 sub-tests PASSED) PASS: findmnt: outputs: [01] default PASS: findmnt: outputs: [02] kernel PASS: findmnt: outputs: [03] force-tree PASS: findmnt: outputs: [04] submounts PASS: findmnt: outputs: [05] messy-mountinfo findmnt: outputs ... OK (all 5 sub-tests PASSED) PASS: findmnt: target: [01] root PASS: findmnt: target: [02] non-root findmnt: target ... OK (all 2 sub-tests PASSED) PASS: fsck: is mounted SKIP: fuzzers: test_fdisk_script_fuzz (test_fdisk_script_fuzz not found) SKIP: fuzzers: test_last_fuzz (test_last_fuzz not found) SKIP: fuzzers: test_mount_fuzz (test_mount_fuzz not found) PASS: getopt: basic PASS: getopt: options: [01] alternative_option_clash PASS: getopt: options: [02] alternative_option_long PASS: getopt: options: [03] alternative_option_short PASS: getopt: options: [04] invalid_getopt_option PASS: getopt: options: [05] invocation_model_one PASS: getopt: options: [06] invocation_model_three_as_one PASS: getopt: options: [07] invocation_model_two_as_one PASS: getopt: options: [08] invocation_without_parameters PASS: getopt: options: [09] long_option_ambiguous_1 PASS: getopt: options: [10] longopts PASS: getopt: options: [11] name_option_long PASS: getopt: options: [12] name_option_short PASS: getopt: options: [13] quiet_option_long PASS: getopt: options: [14] quiet_option_short PASS: getopt: options: [15] quiet_output_option_long PASS: getopt: options: [16] quiet_output_option_short PASS: getopt: options: [17] same_long_short_options PASS: getopt: options: [18] test_for_enhanced_getopt PASS: getopt: options: [19] unknown_options PASS: getopt: options: [20] unquoted_option_bash PASS: getopt: options: [21] unquoted_option_tcsh PASS: getopt: options: [22] weird_quoting_bash PASS: getopt: options: [23] weird_quoting_tcsh PASS: getopt: options: [24] compatible PASS: getopt: options: [25] sh PASS: getopt: options: [26] csh PASS: getopt: options: [27] no-arguments PASS: getopt: options: [28] posix_correctly PASS: getopt: options: [29] non-option getopt: options ... OK (all 29 sub-tests PASSED) PASS: hardlink: options: [01] orig PASS: hardlink: options: [02] dryrun PASS: hardlink: options: [03] nargs PASS: hardlink: options: [04] regex-escapes PASS: hardlink: options: [05] content hardlink: options ... OK (all 5 sub-tests PASSED) PASS: hexdump: format-strings: [01] empty-format PASS: hexdump: format-strings: [02] 1b_octal PASS: hexdump: format-strings: [03] 1b_char PASS: hexdump: format-strings: [04] canon PASS: hexdump: format-strings: [05] 2b_dec PASS: hexdump: format-strings: [06] 2b_octal PASS: hexdump: format-strings: [07] 2b_hex hexdump: format-strings ... OK (all 7 sub-tests PASSED) PASS: hexdump: highlighting: [01] 1b_octal-1 PASS: hexdump: highlighting: [02] 1b_octal-2 PASS: hexdump: highlighting: [03] 1b_octal-3 PASS: hexdump: highlighting: [04] 1b_octal-4 PASS: hexdump: highlighting: [05] 1b_octal-5 PASS: hexdump: highlighting: [06] 1b_octal-6 PASS: hexdump: highlighting: [07] 1b_octal-7 PASS: hexdump: highlighting: [08] 1b_octal-8 PASS: hexdump: highlighting: [09] 1b_octal-9 PASS: hexdump: highlighting: [10] 1b_char-1 PASS: hexdump: highlighting: [11] 1b_char-2 PASS: hexdump: highlighting: [12] 1b_char-3 PASS: hexdump: highlighting: [13] canon-1 PASS: hexdump: highlighting: [14] canon-2 PASS: hexdump: highlighting: [15] 2b_dec-1 PASS: hexdump: highlighting: [16] 2b_dec-2 PASS: hexdump: highlighting: [17] 2b_dec-3 PASS: hexdump: highlighting: [18] 2b_dec-4 PASS: hexdump: highlighting: [19] 2b_dec-5 PASS: hexdump: highlighting: [20] 2b_dec-6 PASS: hexdump: highlighting: [21] 2b_dec-7 PASS: hexdump: highlighting: [22] 2b_dec-8 PASS: hexdump: highlighting: [23] 4b_dec-1 PASS: hexdump: highlighting: [24] 4b_dec-2 PASS: hexdump: highlighting: [25] 4b_dec-3 PASS: hexdump: highlighting: [26] 4b_dec-4 PASS: hexdump: highlighting: [27] 4b_dec-5 PASS: hexdump: highlighting: [28] 4b_dec-6 PASS: hexdump: highlighting: [29] 4b_dec-7 hexdump: highlighting ... OK (all 29 sub-tests PASSED) SKIP: hwclock: system to hw (missing in PATH: sntp) PASS: ipcs: headers PASS: ipcs: limits overflow PASS: ipcs: basic limits PASS: ipcs: mk-rm-msg PASS: ipcs: mk-rm-sem PASS: ipcs: mk-rm-shm PASS: isosize: print-size: [01] default_output PASS: isosize: print-size: [02] sector_output PASS: isosize: print-size: [03] divisor_output isosize: print-size ... OK (all 3 sub-tests PASSED) PASS: kill: all_processes PASS: kill: name_to_number PASS: kill: options PASS: kill: print_pid PASS: kill: queue SKIP: libfdisk: GPT (test_fdisk_gpt not found) PASS: libfdisk: mkpart: [01] mbr PASS: libfdisk: mkpart: [02] mbr-logic PASS: libfdisk: mkpart: [03] mbr-nopartno PASS: libfdisk: mkpart: [04] gpt libfdisk: mkpart ... OK (all 4 sub-tests PASSED) PASS: libfdisk: mkpart-full: [01] mbr-primary PASS: libfdisk: mkpart-full: [02] mbr-primary-nopartno PASS: libfdisk: mkpart-full: [03] mbr-err-primary PASS: libfdisk: mkpart-full: [04] mbr-err-nospace PASS: libfdisk: mkpart-full: [05] mbr-logical PASS: libfdisk: mkpart-full: [06] mbr-nopartno PASS: libfdisk: mkpart-full: [07] mbr-err-logical PASS: libfdisk: mkpart-full: [08] mbr-space-gap PASS: libfdisk: mkpart-full: [09] gpt PASS: libfdisk: mkpart-full: [10] gpt-nopartno PASS: libfdisk: mkpart-full: [11] gpt-err-overlap PASS: libfdisk: mkpart-full: [12] gpt-partno-gap PASS: libfdisk: mkpart-full: [13] gpt-space-gap libfdisk: mkpart-full ... OK (all 13 sub-tests PASSED) SKIP: libmount: context (test not compiled) SKIP: libmount: context-py (pylibmount not compiled) SKIP: libmount: context (utab) (test not compiled) SKIP: libmount: context-py (utab) (pylibmount not compiled) SKIP: libmount: debugging (test not compiled) SKIP: libmount: lock (optional) PASS: libmount: losetup-loop: [01] file PASS: libmount: losetup-loop: [02] file-o-loop PASS: libmount: losetup-loop: [03] dev-loop PASS: libmount: losetup-loop: [04] o-loop-val PASS: libmount: losetup-loop: [05] reuse PASS: libmount: losetup-loop: [06] conflict PASS: libmount: losetup-loop: [07] o-loop-val-initialized PASS: libmount: losetup-loop: [08] o-loop-val-conflict libmount: losetup-loop ... OK (all 8 sub-tests PASSED) PASS: libmount: loop overlay SKIP: libmount: options string (test not compiled) SKIP: libmount: table diffs (test not compiled) SKIP: libmount: tab files (test not compiled) SKIP: libmount: tab files-py (pylibmount not compiled) SKIP: libmount: tags (test not compiled) SKIP: libmount: tags-py (pylibmount not compiled) SKIP: libmount: tab update (test not compiled) SKIP: libmount: tab update-py (pylibmount not compiled) SKIP: libmount: utils (test not compiled) PASS: libsmartcols: fromfile: [01] tree PASS: libsmartcols: fromfile: [02] tree-json PASS: libsmartcols: fromfile: [03] tree-middle PASS: libsmartcols: fromfile: [04] tree-end PASS: libsmartcols: fromfile: [05] trunc PASS: libsmartcols: fromfile: [06] right PASS: libsmartcols: fromfile: [07] right-maxout PASS: libsmartcols: fromfile: [08] padding-default PASS: libsmartcols: fromfile: [09] padding-maxout PASS: libsmartcols: fromfile: [10] padding-minout PASS: libsmartcols: fromfile: [11] strictwidth PASS: libsmartcols: fromfile: [12] noextremes PASS: libsmartcols: fromfile: [13] hidden PASS: libsmartcols: fromfile: [14] wrap PASS: libsmartcols: fromfile: [15] wrap-tree PASS: libsmartcols: fromfile: [16] wrapnl PASS: libsmartcols: fromfile: [17] wrapnl-tree PASS: libsmartcols: fromfile: [18] raw PASS: libsmartcols: fromfile: [19] export PASS: libsmartcols: fromfile: [20] column-separator libsmartcols: fromfile ... OK (all 20 sub-tests PASSED) PASS: libsmartcols: title PASS: logger: errors: [01] kern_priority PASS: logger: errors: [02] kern_priority_numeric PASS: logger: errors: [03] invalid_prio PASS: logger: errors: [04] rfc5424_exceed_size PASS: logger: errors: [05] id_with_space PASS: logger: errors: [06] tag_with_space PASS: logger: errors: [07] tcp PASS: logger: errors: [08] multi-line PASS: logger: errors: [09] rfc5424_msgid_with_space PASS: logger: errors: [10] invalid_socket PASS: logger: errors: [11] check_socket logger: errors ... OK (all 11 sub-tests PASSED) PASS: logger: formats: [01] rfc3164 PASS: logger: formats: [02] rfc5424_simple PASS: logger: formats: [03] rfc5424_notime PASS: logger: formats: [04] rfc5424_nohost PASS: logger: formats: [05] rfc5424_msgid PASS: logger: formats: [06] octet_counting PASS: logger: formats: [07] priorities PASS: logger: formats: [08] check_socket logger: formats ... OK (all 8 sub-tests PASSED) SKIP: logger: journald (unsupported) PASS: logger: options: [01] simple PASS: logger: options: [02] log_pid PASS: logger: options: [03] log_pid_long PASS: logger: options: [04] log_pid_define PASS: logger: options: [05] log_pid_no_arg PASS: logger: options: [06] input_file_simple PASS: logger: options: [07] input_file_empty_line PASS: logger: options: [08] input_file_skip_empty PASS: logger: options: [09] input_file_prio_prefix PASS: logger: options: [10] check_socket logger: options ... OK (all 10 sub-tests PASSED) PASS: login: islocal PASS: login: defs PASS: look: separator PASS: losetup: losetup: [01] file-show PASS: losetup: losetup: [02] file-offset PASS: losetup: losetup: [03] file-sizelimit PASS: losetup: losetup: [04] file-section losetup: losetup ... OK (all 4 sub-tests PASSED) SKIP: losetup: losetup-blkdev (missing scsi_debug module (dry-run)) SKIP: losetup: losetup-loop (missing scsi_debug module (dry-run)) PASS: lsblk: lsblk: [01] simple-lvm-basic PASS: lsblk: lsblk: [02] simple-lvm-discard PASS: lsblk: lsblk: [03] simple-lvm-rw PASS: lsblk: lsblk: [04] simple-lvm-state PASS: lsblk: lsblk: [05] simple-lvm-topo PASS: lsblk: lsblk: [06] simple-lvm-vendor PASS: lsblk: lsblk: [07] simple-lvm-zone PASS: lsblk: lsblk: [08] simple-nvme-basic PASS: lsblk: lsblk: [09] simple-nvme-discard PASS: lsblk: lsblk: [10] simple-nvme-rw PASS: lsblk: lsblk: [11] simple-nvme-state PASS: lsblk: lsblk: [12] simple-nvme-topo PASS: lsblk: lsblk: [13] simple-nvme-vendor PASS: lsblk: lsblk: [14] simple-nvme-zone lsblk: lsblk ... OK (all 14 sub-tests PASSED) PASS: lscpu: lscpu: [01] armv7 PASS: lscpu: lscpu: [02] ppc-qemu PASS: lscpu: lscpu: [03] ppc64-POWER7-64cpu PASS: lscpu: lscpu: [04] ppc64-POWER7 PASS: lscpu: lscpu: [05] s390-kvm PASS: lscpu: lscpu: [06] s390-lpar-drawer PASS: lscpu: lscpu: [07] s390-lpar PASS: lscpu: lscpu: [08] s390-nested-virt PASS: lscpu: lscpu: [09] s390-zvm PASS: lscpu: lscpu: [10] sparc64 PASS: lscpu: lscpu: [11] vbox-win PASS: lscpu: lscpu: [12] vmware_fpe PASS: lscpu: lscpu: [13] x86_64-64cpu PASS: lscpu: lscpu: [14] x86_64-dell_e4310 PASS: lscpu: lscpu: [15] x86_64-epyc_7451 lscpu: lscpu ... OK (all 15 sub-tests PASSED) PASS: lsmem: lsmem: [01] s390-zvm-6g PASS: lsmem: lsmem: [02] x86_64-16g lsmem: lsmem ... OK (all 2 sub-tests PASSED) PASS: lsns: ownership and hierarchy Error: Unknown device type. SKIP: lsns: NETNSID compare to ip-link (failed to initialize) PASS: lsns: NSFS for ip-netns-add PASS: md5: md5 SKIP: minix: mkfs fsck (missing in PATH: mkfs.minix) SKIP: minix: fsck images (missing in PATH: fsck.minix) SKIP: minix: mkfs mount (missing in PATH: mkfs.minix) PASS: misc: fallocate PASS: misc: flock: [01] non-block PASS: misc: flock: [02] no-fork PASS: misc: flock: [03] shared PASS: misc: flock: [04] exclusive PASS: misc: flock: [05] timeout misc: flock: [06] time-check ... OK (diff 3 sec) misc: flock ... OK (all 6 sub-tests PASSED) PASS: misc: ionice SKIP: misc: line (missing in PATH: line) PASS: misc: mbsencode: [01] safe-ascii PASS: misc: mbsencode: [02] invalid-ascii misc: mbsencode: [03] safe-utf8 ... KNOWN FAILED (misc/mbsencode-safe-utf8) misc: mbsencode: [04] invalid-utf8 ... KNOWN FAILED (misc/mbsencode-invalid-utf8) misc: mbsencode ... KNOWN FAILED (2 from 4 sub-tests) PASS: misc: mcookie PASS: misc: mountpoint: [01] default PASS: misc: mountpoint: [02] nofollow PASS: misc: mountpoint: [03] mutually-exclusive misc: mountpoint ... OK (all 3 sub-tests PASSED) PASS: misc: rev PASS: misc: setarch: [01] options PASS: misc: setarch: [02] uname26 PASS: misc: setarch: [03] uname26-version misc: setarch ... OK (all 3 sub-tests PASSED) PASS: misc: setsid PASS: misc: strtosize PASS: misc: swaplabel PASS: misc: whereis PASS: more: regexp PASS: more: squeeze PASS: mount: by devname PASS: mount: fs lists: [01] one-type PASS: mount: fs lists: [02] more-types PASS: mount: fs lists: [03] more-types-fstab PASS: mount: fs lists: [04] type-pattern PASS: mount: fs lists: [05] type-pattern-neg mount: fs lists ... OK (all 5 sub-tests PASSED) SKIP: mount: all (fstab) (missing scsi_debug module (dry-run)) PASS: mount: broken fstab: [01] mount PASS: mount: broken fstab: [02] mount-all mount: broken fstab ... OK (all 2 sub-tests PASSED) PASS: mount: btrfs (fstab): [01] btrfs PASS: mount: btrfs (fstab): [02] auto mount: btrfs (fstab) ... OK (all 2 sub-tests PASSED) PASS: mount: by devname (fstab) PASS: mount: by devname (fstab label) PASS: mount: by devname (fstab uuid) PASS: mount: by label (fstab) PASS: mount: by label (fstab devname) PASS: mount: by label (fstab uuid) PASS: mount: loop (fstab) PASS: mount: none PASS: mount: by devname (fstab symlink) PASS: mount: by uuid (fstab) PASS: mount: by uuid (fstab devname) PASS: mount: by uuid (fstab label) PASS: mount: by label PASS: mount: move PASS: mount: regular file PASS: mount: remount SKIP: mount: rlimit-fsize (mtab unsupported) PASS: mount: shared-subtree: [01] make-shared PASS: mount: shared-subtree: [02] make-private PASS: mount: shared-subtree: [03] make-unbindable PASS: mount: shared-subtree: [04] bind-shared PASS: mount: shared-subtree: [05] mount-private PASS: mount: shared-subtree: [06] mount-private-ro mount: shared-subtree ... OK (all 6 sub-tests PASSED) PASS: mount: call mount.<type> SKIP: mount: umount-all-targets (missing scsi_debug module (dry-run)) SKIP: mount: umount-recursive (missing scsi_debug module (dry-run)) PASS: mount: by uuid PASS: namei: basic functionality SKIP: partx: partitions probing (missing scsi_debug module (dry-run)) PASS: partx: show images: [01] atari-primary PASS: partx: show images: [02] atari-xgm PASS: partx: show images: [03] bsd PASS: partx: show images: [04] dos+bsd PASS: partx: show images: [05] gpt PASS: partx: show images: [06] sgi PASS: partx: show images: [07] sun partx: show images ... OK (all 7 sub-tests PASSED) SKIP: paths: built-in (optional) PASS: rename: basic check PASS: rename: exit codes PASS: rename: overwrite PASS: rename: subdir check PASS: rename: symlink check PASS: schedutils: chrt: [01] fifo PASS: schedutils: chrt: [02] batch PASS: schedutils: chrt: [03] other PASS: schedutils: chrt: [04] rr PASS: schedutils: chrt: [05] idle chrt: failed to set pid 0's policy: Invalid argument chrt: failed to set pid 0's policy: Invalid argument chrt: failed to set pid 0's policy: Invalid argument schedutils: chrt: [06] deadline ... KNOWN FAILED (schedutils/chrt-deadline) Supported policies: SCHED_OTHER min/max priority : 0/0 SCHED_FIFO min/max priority : 1/99 SCHED_RR min/max priority : 1/99 SCHED_BATCH min/max priority : 0/0 SCHED_IDLE min/max priority : 0/0 SCHED_DEADLINE min/max priority : 0/0 schedutils: chrt ... KNOWN FAILED (1 from 6 sub-tests) PASS: schedutils: chrt-non-user: [01] batch-vs-nice schedutils: chrt-non-user ... OK (all 1 sub-tests PASSED) PASS: schedutils: cpuset PASS: script: buffering race PASS: script: options: [01] append PASS: script: options: [02] force PASS: script: options: [03] quiet PASS: script: options: [04] return PASS: script: options: [05] size script: options ... OK (all 5 sub-tests PASSED) PASS: script: race conditions PASS: script: replay: [01] basic PASS: script: replay: [02] output PASS: script: replay: [03] input PASS: script: replay: [04] live script: replay ... OK (all 4 sub-tests PASSED) SKIP: sfdisk: MBR (missing scsi_debug module (dry-run)) SKIP: sfdisk: script (missing scsi_debug module (dry-run)) SKIP: sfdisk: GPT (missing scsi_debug module (dry-run)) SKIP: sfdisk: movedata (missing scsi_debug module (dry-run)) SKIP: sfdisk: resize (missing scsi_debug module (dry-run)) SKIP: sfdisk: script (missing scsi_debug module (dry-run)) SKIP: sfdisk: wipe (missing scsi_debug module (dry-run)) PASS: sha1: sha1 PASS: swapon: by devname PASS: swapon: fix page size PASS: swapon: fix signature PASS: swapon: by label PASS: swapon: by uuid ul: basic tests ... KNOWN FAILED (ul/basic) ul: ul ... KNOWN FAILED (ul/ul) PASS: utmp: last: [01] nodns utmp: last ... OK (all 1 sub-tests PASSED) PASS: utmp: last ipv6: [01] nodns utmp: last ipv6 ... OK (all 1 sub-tests PASSED) PASS: utmp: circle PASS: utmp: subsecond PASS: utmp: to binary PASS: utmp: IPv6 to binary PASS: utmp: to text PASS: utmp: IPv6 to text PASS: uuid: namespace PASS: uuid: oids PASS: uuid: uuid_parser PASS: uuid: uuidd PASS: uuid: uuidgen PASS: uuid: uuidparse SKIP: wipefs: wipefs (missing scsi_debug module (dry-run)) --------------------------------------------------------------------- All 212 tests PASSED --------------------------------------------------------------------- Starting udev DURATION: 72 END: /usr/lib/util-linux/ptest 2024-03-08T13:04 STOP: ptest-runner TOTAL: 1 FAIL: 0
On Fri, Mar 8, 2024 at 3:35 AM Kevin Hao <haokexin@gmail.com> wrote: > > On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote: > > Adding Kevin, > > > > I'm not going to be able to debug this more for a week or so. > > > > The alternate ways to fix it would be to try that ubuntu patch (fixed > > for our tree), and / or see what else needs > > to be cherry picked to -stable to fix util-linux. It is likely just a > > return code difference to userspace when > > resizing is being done. > > > > Kevin: I'm not sure if Wind River is seeing this, but you might want to look > > into those ptests and see if they pass on your end. > > A silly question, which branch are these three patches supposed to apply to? > I have tried the kirkstone branch, but it seems that they can't apply cleanly. > I also tried to manually apply the two kernel patches to the latest > linux-yocto/v5.15/standard/base branch, but they also can't be applied cleanly. > Am I miss something? No, you haven't missed anything. Bruce was assuming that kirkstone contained patches that he hasn't sent yet. I wasn't able to apply the second two patches either. > On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest > does have three failures. Then I have tried the ubuntu kernel patch [1] which is > mentioned in the previous discussion about this issue. This patch can apply to > the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted > failures, and I also don't find util-linux ptest failure after applying this > patch. I attached my logs. Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I haven't tried that. Do you have a kirkstone patch that I can try on the autobuilder? Thanks! Steve > [1] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1&id=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9 > > Thanks, > Kevin
On Fri, Mar 8, 2024 at 9:21 AM Steve Sakoman <steve@sakoman.com> wrote: > > On Fri, Mar 8, 2024 at 3:35 AM Kevin Hao <haokexin@gmail.com> wrote: > > > > On Thu, Mar 07, 2024 at 06:13:35PM -0500, Bruce Ashfield wrote: > > > Adding Kevin, > > > > > > I'm not going to be able to debug this more for a week or so. > > > > > > The alternate ways to fix it would be to try that ubuntu patch (fixed > > > for our tree), and / or see what else needs > > > to be cherry picked to -stable to fix util-linux. It is likely just a > > > return code difference to userspace when > > > resizing is being done. > > > > > > Kevin: I'm not sure if Wind River is seeing this, but you might want to look > > > into those ptests and see if they pass on your end. > > > > A silly question, which branch are these three patches supposed to apply to? > > I have tried the kirkstone branch, but it seems that they can't apply cleanly. > > I also tried to manually apply the two kernel patches to the latest > > linux-yocto/v5.15/standard/base branch, but they also can't be applied cleanly. > > Am I miss something? > > No, you haven't missed anything. Bruce was assuming that kirkstone > contained patches that he hasn't sent yet. I wasn't able to apply the > second two patches either. Yes, exactly. I did the patches against a different queue than what Steve had in test. > > > On the latest linux-yocto/v5.15/standard/base kernel, the parted ptest > > does have three failures. Then I have tried the ubuntu kernel patch [1] which is > > mentioned in the previous discussion about this issue. This patch can apply to > > the linux-yocto/v5.15/standard/base cleanly and it indeed resolve the parted > > failures, and I also don't find util-linux ptest failure after applying this > > patch. I attached my logs. > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I > haven't tried that. > > Do you have a kirkstone patch that I can try on the autobuilder? > I'd still rather not go the ubuntu patch route. It is my last choice in the options. If this is caused by upstream commits, there should also be upstream commits that fix the issues. I need to identify those commits and document why they aren't appropriate for our 5.15 kernel before I pick up someone's else patch .. since at that point, I have no idea about their logic and other issues it may introduce. Bruce > Thanks! > > Steve > > > [1] https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/commit/?h=master-next--2024.03.04-1&id=c3032b60ff7b3948325b8f2bd688b9a74be3cfb9 > > > > Thanks, > > Kevin > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196851): https://lists.openembedded.org/g/openembedded-core/message/196851 > Mute This Topic: https://lists.openembedded.org/mt/104794844/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote: > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I > > haven't tried that. > > > > Do you have a kirkstone patch that I can try on the autobuilder? > > > > I'd still rather not go the ubuntu patch route. It is my last choice in the > options. > > If this is caused by upstream commits, there should also be upstream > commits that fix the issues. I need to identify those commits and > document why they aren't appropriate for our 5.15 kernel before I pick > up someone's else patch .. since at that point, I have no idea about their > logic and other issues it may introduce. Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and the tweak in order to port to v5.15 also seems pretty reasonable. I generated a patch based on the latest kirkstone branch. Steve, could you give the attachment a try? Thanks, Kevin From dca6a0cec06a1688881d697bd255eff05b474c3e Mon Sep 17 00:00:00 2001 From: Kevin Hao <kexin.hao@windriver.com> Date: Fri, 8 Mar 2024 22:31:26 +0800 Subject: [PATCH] linux-yocto: Don't merge: Fix the parted ptest failues Signed-off-by: Kevin Hao <kexin.hao@windriver.com> --- ...-support-partitions-without-scanning.patch | 104 ++++++++++++++++++ meta/recipes-kernel/linux/linux-yocto_5.15.bb | 3 +- 2 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch diff --git a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch new file mode 100644 index 000000000000..f77b0e9eb00a --- /dev/null +++ b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch @@ -0,0 +1,104 @@ +From 82fad6e9334f1239fe090def17ca947c89fc4308 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig <hch@lst.de> +Date: Fri, 27 May 2022 07:58:06 +0200 +Subject: [PATCH] block, loop: support partitions without scanning + +BugLink: https://bugs.launchpad.net/bugs/2056143 + +Historically we did distinguish between a flag that surpressed partition +scanning, and a combinations of the minors variable and another flag if +any partitions were supported. This was generally confusing and doesn't +make much sense, but some corner case uses of the loop driver actually +do want to support manually added partitions on a device that does not +actively scan for partitions. To make things worsee the loop driver +also wants to dynamically toggle the scanning for partitions on a live +gendisk, which makes the disk->flags updates non-atomic. + +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART +in the loop driver. + +Upstream-Status: Backport [c3032b60ff7b3948325b8f2bd688b9a74be3cfb9] + +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") +Reported-by: Ming Lei <ming.lei@redhat.com> +Signed-off-by: Christoph Hellwig <hch@lst.de> +Reviewed-by: Ming Lei <ming.lei@redhat.com> +Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de +Signed-off-by: Jens Axboe <axboe@kernel.dk> + +(backported from commit b9684a71fca793213378dd410cd11675d973eaa1) +[smb: Flag and test for partition scan in genhd.h instead] +Signed-off-by: Stefan Bader <stefan.bader@canonical.com> +Acked-by: Roxana Nicolescu <roxana.nicolescu@canonical.com> +Acked-by: Manuel Diewald <manuel.diewald@canonical.com> +Signed-off-by: Stefan Bader <stefan.bader@canonical.com> +--- + drivers/block/loop.c | 8 ++++---- + include/linux/genhd.h | 3 +++ + 2 files changed, 7 insertions(+), 4 deletions(-) + +diff --git a/drivers/block/loop.c b/drivers/block/loop.c +index 4769caab9ff9..a76302450c46 100644 +--- a/drivers/block/loop.c ++++ b/drivers/block/loop.c +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, + lo->lo_flags |= LO_FLAGS_PARTSCAN; + partscan = lo->lo_flags & LO_FLAGS_PARTSCAN; + if (partscan) +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + + /* enable and uncork uevent now that we are done */ + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); +@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool release) + mutex_lock(&lo->lo_mutex); + lo->lo_flags = 0; + if (!part_shift) +- lo->lo_disk->flags |= GENHD_FL_NO_PART; ++ set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + lo->lo_state = Lo_unbound; + mutex_unlock(&lo->lo_mutex); + +@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info) + + if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) && + !(prev_lo_flags & LO_FLAGS_PARTSCAN)) { +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + partscan = true; + } + out_unlock: +@@ -2428,7 +2428,7 @@ static int loop_add(int i) + * userspace tools. Parameters like this in general should be avoided. + */ + if (!part_shift) +- disk->flags |= GENHD_FL_NO_PART; ++ set_bit(GD_SUPPRESS_PART_SCAN, &disk->state); + disk->flags |= GENHD_FL_EXT_DEVT; + atomic_set(&lo->lo_refcnt, 0); + mutex_init(&lo->lo_mutex); +diff --git a/include/linux/genhd.h b/include/linux/genhd.h +index 690b7f7996d1..fc69ab1751c2 100644 +--- a/include/linux/genhd.h ++++ b/include/linux/genhd.h +@@ -132,6 +132,7 @@ struct gendisk { + #define GD_READ_ONLY 1 + #define GD_DEAD 2 + #define GD_NATIVE_CAPACITY 3 ++#define GD_SUPPRESS_PART_SCAN 5 + + struct mutex open_mutex; /* open/close mutex */ + unsigned open_partitions; /* number of open partitions */ +@@ -185,6 +186,8 @@ static inline int disk_max_parts(struct gendisk *disk) + + static inline bool disk_part_scan_enabled(struct gendisk *disk) + { ++ if (test_bit(GD_SUPPRESS_PART_SCAN, &disk->state)) ++ return 0; + return disk_max_parts(disk) > 1 && !(disk->flags & GENHD_FL_NO_PART); + } + +-- +2.44.0 + diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb b/meta/recipes-kernel/linux/linux-yocto_5.15.bb index 9a7c96b4539a..8f63a4954fc4 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb @@ -36,7 +36,8 @@ PN:class-devupstream = "linux-yocto-upstream" KBRANCH:class-devupstream = "v5.15/base" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}" + git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA} \ + file://0001-block-loop-support-partitions-without-scanning.patch" LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" LINUX_VERSION ?= "5.15.148"
On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao <haokexin@gmail.com> wrote: > > On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote: > > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I > > > haven't tried that. > > > > > > Do you have a kirkstone patch that I can try on the autobuilder? > > > > > > > I'd still rather not go the ubuntu patch route. It is my last choice in the > > options. > > > > If this is caused by upstream commits, there should also be upstream > > commits that fix the issues. I need to identify those commits and > > document why they aren't appropriate for our 5.15 kernel before I pick > > up someone's else patch .. since at that point, I have no idea about their > > logic and other issues it may introduce. > > Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and > the tweak in order to port to v5.15 also seems pretty reasonable. I generated > a patch based on the latest kirkstone branch. Steve, could you give the attachment > a try? You can give it a try, but I won't merge it as-is. I'll just go ahead and do it myself, since I won't be ignored on the format that I'm looking for in this change. Cheers, Bruce > > Thanks, > Kevin
On Fri, Mar 8, 2024 at 5:05 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao <haokexin@gmail.com> wrote: > > > > On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote: > > > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I > > > > haven't tried that. > > > > > > > > Do you have a kirkstone patch that I can try on the autobuilder? > > > > > > > > > > I'd still rather not go the ubuntu patch route. It is my last choice in the > > > options. > > > > > > If this is caused by upstream commits, there should also be upstream > > > commits that fix the issues. I need to identify those commits and > > > document why they aren't appropriate for our 5.15 kernel before I pick > > > up someone's else patch .. since at that point, I have no idea about their > > > logic and other issues it may introduce. > > > > Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and > > the tweak in order to port to v5.15 also seems pretty reasonable. I generated > > a patch based on the latest kirkstone branch. Steve, could you give the attachment > > a try? > > You can give it a try, but I won't merge it as-is. > > I'll just go ahead and do it myself, since I won't be ignored on the format > that I'm looking for in this change. We wouldn't even think of ignoring you!! I did fire up a test of Kevin's patch: https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 Let's see what happens. Steve > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196854): https://lists.openembedded.org/g/openembedded-core/message/196854 > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> wrote: > > On Fri, Mar 8, 2024 at 5:05 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Fri, Mar 8, 2024 at 9:59 AM Kevin Hao <haokexin@gmail.com> wrote: > > > > > > On Fri, Mar 08, 2024 at 09:41:14AM -0500, Bruce Ashfield wrote: > > > > > Hmmm . . . Bruce said that the ubuntu patch didn't apply for him, so I > > > > > haven't tried that. > > > > > > > > > > Do you have a kirkstone patch that I can try on the autobuilder? > > > > > > > > > > > > > I'd still rather not go the ubuntu patch route. It is my last choice in the > > > > options. > > > > > > > > If this is caused by upstream commits, there should also be upstream > > > > commits that fix the issues. I need to identify those commits and > > > > document why they aren't appropriate for our 5.15 kernel before I pick > > > > up someone's else patch .. since at that point, I have no idea about their > > > > logic and other issues it may introduce. > > > > > > Agreed. But that patch is indeed a backport of upstream commit b9684a71fca7 and > > > the tweak in order to port to v5.15 also seems pretty reasonable. I generated > > > a patch based on the latest kirkstone branch. Steve, could you give the attachment > > > a try? > > > > You can give it a try, but I won't merge it as-is. > > > > I'll just go ahead and do it myself, since I won't be ignored on the format > > that I'm looking for in this change. > > We wouldn't even think of ignoring you!! > > I did fire up a test of Kevin's patch: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > Let's see what happens. I can confirm that this patch fixes the parted ptest issues and does not trigger any other ptest issues. However since there is a kirkstone release build scheduled for next Tuesday, the current plan of record is to revert the previous linux-yocto 5.15 version bump series for the release build. I will then wait for a patch from Bruce that fixes the problem before reapplying it post release. I apologize to all for not catching this prior to merging the version bump series :-( Steve > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196855): https://lists.openembedded.org/g/openembedded-core/message/196855 > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > wrote: > > > > I did fire up a test of Kevin's patch: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > Let's see what happens. > > I can confirm that this patch fixes the parted ptest issues and does > not trigger any other ptest issues. > > However since there is a kirkstone release build scheduled for next > Tuesday, the current plan of record is to revert the previous > linux-yocto 5.15 version bump series for the release build. > > I will then wait for a patch from Bruce that fixes the problem before > reapplying it post release. If it takes a few more days it may be better to slip that release (when QA are likely testing M3 anyway) in order to resolve this rather than reverting a load of things we'll only then end up reapplying. Cheers, Richard
On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > wrote: > > > > > > I did fire up a test of Kevin's patch: > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > Let's see what happens. > > > > I can confirm that this patch fixes the parted ptest issues and does > > not trigger any other ptest issues. > > > > However since there is a kirkstone release build scheduled for next > > Tuesday, the current plan of record is to revert the previous > > linux-yocto 5.15 version bump series for the release build. > > > > I will then wait for a patch from Bruce that fixes the problem before > > reapplying it post release. > > If it takes a few more days it may be better to slip that release (when > QA are likely testing M3 anyway) in order to resolve this rather than > reverting a load of things we'll only then end up reapplying. > I'll be working on it over the weekend, along with some other kernel items that I didn't get to as I worked on this today and some meta-virt things. Bruce > Cheers, > > Richard > >
On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via lists.openembedded.org <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > > wrote: > > > > > > > > I did fire up a test of Kevin's patch: > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > > > Let's see what happens. > > > > > > I can confirm that this patch fixes the parted ptest issues and does > > > not trigger any other ptest issues. > > > > > > However since there is a kirkstone release build scheduled for next > > > Tuesday, the current plan of record is to revert the previous > > > linux-yocto 5.15 version bump series for the release build. > > > > > > I will then wait for a patch from Bruce that fixes the problem before > > > reapplying it post release. > > > > If it takes a few more days it may be better to slip that release (when > > QA are likely testing M3 anyway) in order to resolve this rather than > > reverting a load of things we'll only then end up reapplying. > > > > I'll be working on it over the weekend, along with some other kernel > items that I didn't get to as I worked on this today and some meta-virt > things. Steve: Here's my latest queue: https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone It passed the parted and util-linux ptests locally. Bruce > > Bruce > > > Cheers, > > > > Richard > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196866): https://lists.openembedded.org/g/openembedded-core/message/196866 > Mute This Topic: https://lists.openembedded.org/mt/104794844/1050810 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [bruce.ashfield@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via > lists.openembedded.org > <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > > > wrote: > > > > > > > > > > I did fire up a test of Kevin's patch: > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > > > > > Let's see what happens. > > > > > > > > I can confirm that this patch fixes the parted ptest issues and does > > > > not trigger any other ptest issues. > > > > > > > > However since there is a kirkstone release build scheduled for next > > > > Tuesday, the current plan of record is to revert the previous > > > > linux-yocto 5.15 version bump series for the release build. > > > > > > > > I will then wait for a patch from Bruce that fixes the problem before > > > > reapplying it post release. > > > > > > If it takes a few more days it may be better to slip that release (when > > > QA are likely testing M3 anyway) in order to resolve this rather than > > > reverting a load of things we'll only then end up reapplying. > > > > > > > I'll be working on it over the weekend, along with some other kernel > > items that I didn't get to as I worked on this today and some meta-virt > > things. > > Steve: Here's my latest queue: > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone > > It passed the parted and util-linux ptests locally. Thanks Bruce! I'll grab the patches and run an a-full on the autobuilder. Steve > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196907): https://lists.openembedded.org/g/openembedded-core/message/196907 > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> wrote: > > On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via > > lists.openembedded.org > > <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > > > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > > > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > > > > wrote: > > > > > > > > > > > > I did fire up a test of Kevin's patch: > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > > > > > > > Let's see what happens. > > > > > > > > > > I can confirm that this patch fixes the parted ptest issues and does > > > > > not trigger any other ptest issues. > > > > > > > > > > However since there is a kirkstone release build scheduled for next > > > > > Tuesday, the current plan of record is to revert the previous > > > > > linux-yocto 5.15 version bump series for the release build. > > > > > > > > > > I will then wait for a patch from Bruce that fixes the problem before > > > > > reapplying it post release. > > > > > > > > If it takes a few more days it may be better to slip that release (when > > > > QA are likely testing M3 anyway) in order to resolve this rather than > > > > reverting a load of things we'll only then end up reapplying. > > > > > > > > > > I'll be working on it over the weekend, along with some other kernel > > > items that I didn't get to as I worked on this today and some meta-virt > > > things. > > > > Steve: Here's my latest queue: > > > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone > > > > It passed the parted and util-linux ptests locally. > > Thanks Bruce! > > I'll grab the patches and run an a-full on the autobuilder. The a-full results are here: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6666 The ptest runs came back all green, but there were failures in all of the hw-ref tests that use older versions of 5.15 since the patch added with SRC_URI += in your final commit doesn't apply to those older kernel versions. For example, beaglebone: https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors Steve > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > > > > -- > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > thee at its end > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#196908): https://lists.openembedded.org/g/openembedded-core/message/196908 > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Mon, Mar 11, 2024 at 9:51 AM Steve Sakoman <steve@sakoman.com> wrote: > > On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > wrote: > > > > On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via > > > lists.openembedded.org > > > <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > > > > > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie > > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > > > > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > > > > > wrote: > > > > > > > > > > > > > > I did fire up a test of Kevin's patch: > > > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > > > > > > > > > Let's see what happens. > > > > > > > > > > > > I can confirm that this patch fixes the parted ptest issues and does > > > > > > not trigger any other ptest issues. > > > > > > > > > > > > However since there is a kirkstone release build scheduled for next > > > > > > Tuesday, the current plan of record is to revert the previous > > > > > > linux-yocto 5.15 version bump series for the release build. > > > > > > > > > > > > I will then wait for a patch from Bruce that fixes the problem before > > > > > > reapplying it post release. > > > > > > > > > > If it takes a few more days it may be better to slip that release (when > > > > > QA are likely testing M3 anyway) in order to resolve this rather than > > > > > reverting a load of things we'll only then end up reapplying. > > > > > > > > > > > > > I'll be working on it over the weekend, along with some other kernel > > > > items that I didn't get to as I worked on this today and some meta-virt > > > > things. > > > > > > Steve: Here's my latest queue: > > > > > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone > > > > > > It passed the parted and util-linux ptests locally. > > > > Thanks Bruce! > > > > I'll grab the patches and run an a-full on the autobuilder. > > The a-full results are here: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6666 > > The ptest runs came back all green, but there were failures in all of > the hw-ref tests that use older versions of 5.15 since the patch added > with SRC_URI += in your final commit doesn't apply to those older > kernel versions. > Yah, that's fine. We'd never merge the patch like I put it in the queue. I'll actually merge those changes into the linux-yocto tree and send SRCREV updates. I just wanted to make sure that they worked in your tests, like they worked in mine. I can also bump the reference BSPs to pick up the change. Really this is something that -stable should be fixing, but I'm not in a position to propose a fix (it is far from my area of expertise) so I kept the patches with as minor touches as possible so when (if) they fix the issue, I won't have much conflict. I can do those SRCREV bumps shortly and send the entire queue by patches if that works for you. Bruce > For example, beaglebone: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors > > Steve > > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > > thee at its end > > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > > > > > > > > > > -- > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > thee at its end > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > Links: You receive all messages sent to this group. > > View/Reply Online (#196908): https://lists.openembedded.org/g/openembedded-core/message/196908 > > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > > Group Owner: openembedded-core+owner@lists.openembedded.org > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > > -=-=-=-=-=-=-=-=-=-=-=- > >
On Mon, Mar 11, 2024 at 4:01 AM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > On Mon, Mar 11, 2024 at 9:51 AM Steve Sakoman <steve@sakoman.com> wrote: > > > > On Sun, Mar 10, 2024 at 4:25 PM Steve Sakoman via > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > wrote: > > > > > > On Sun, Mar 10, 2024 at 4:10 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote: > > > > > > > > On Fri, Mar 8, 2024 at 10:24 PM Bruce Ashfield via > > > > lists.openembedded.org > > > > <bruce.ashfield=gmail.com@lists.openembedded.org> wrote: > > > > > > > > > > On Fri, Mar 8, 2024 at 6:44 PM Richard Purdie > > > > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > > > > > > > On Fri, 2024-03-08 at 10:42 -0800, Steve Sakoman wrote: > > > > > > > On Fri, Mar 8, 2024 at 5:10 AM Steve Sakoman via > > > > > > > lists.openembedded.org <steve=sakoman.com@lists.openembedded.org> > > > > > > > wrote: > > > > > > > > > > > > > > > > I did fire up a test of Kevin's patch: > > > > > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/6373 > > > > > > > > > > > > > > > > Let's see what happens. > > > > > > > > > > > > > > I can confirm that this patch fixes the parted ptest issues and does > > > > > > > not trigger any other ptest issues. > > > > > > > > > > > > > > However since there is a kirkstone release build scheduled for next > > > > > > > Tuesday, the current plan of record is to revert the previous > > > > > > > linux-yocto 5.15 version bump series for the release build. > > > > > > > > > > > > > > I will then wait for a patch from Bruce that fixes the problem before > > > > > > > reapplying it post release. > > > > > > > > > > > > If it takes a few more days it may be better to slip that release (when > > > > > > QA are likely testing M3 anyway) in order to resolve this rather than > > > > > > reverting a load of things we'll only then end up reapplying. > > > > > > > > > > > > > > > > I'll be working on it over the weekend, along with some other kernel > > > > > items that I didn't get to as I worked on this today and some meta-virt > > > > > things. > > > > > > > > Steve: Here's my latest queue: > > > > > > > > https://git.yoctoproject.org/poky-contrib/log/?h=zedd/kernel-kirkstone > > > > > > > > It passed the parted and util-linux ptests locally. > > > > > > Thanks Bruce! > > > > > > I'll grab the patches and run an a-full on the autobuilder. > > > > The a-full results are here: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6666 > > > > The ptest runs came back all green, but there were failures in all of > > the hw-ref tests that use older versions of 5.15 since the patch added > > with SRC_URI += in your final commit doesn't apply to those older > > kernel versions. > > > > Yah, that's fine. > > We'd never merge the patch like I put it in the queue. > > I'll actually merge those changes into the linux-yocto tree and send > SRCREV updates. I just wanted to make sure that they worked in > your tests, like they worked in mine. > > I can also bump the reference BSPs to pick up the change. > > Really this is something that -stable should be fixing, but I'm not > in a position to propose a fix (it is far from my area of expertise) > so I kept the patches with as minor touches as possible so when > (if) they fix the issue, I won't have much conflict. > > I can do those SRCREV bumps shortly and send the entire queue > by patches if that works for you. That would be perfect. Thanks for the quick response on this, I really appreciate it! Steve > > For example, beaglebone: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/8751/steps/11/logs/errors > > > > Steve > > > > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > > > thee at its end > > > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > - Thou shalt not follow the NULL pointer, for chaos and madness await > > > > thee at its end > > > > - "Use the force Harry" - Gandalf, Star Trek II > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > > > Links: You receive all messages sent to this group. > > > View/Reply Online (#196908): https://lists.openembedded.org/g/openembedded-core/message/196908 > > > Mute This Topic: https://lists.openembedded.org/mt/104794844/3620601 > > > Group Owner: openembedded-core+owner@lists.openembedded.org > > > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [steve@sakoman.com] > > > -=-=-=-=-=-=-=-=-=-=-=- > > > > > > > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II
diff --git a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch new file mode 100644 index 0000000000..cde4f317e9 --- /dev/null +++ b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch @@ -0,0 +1,43 @@ +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001 +From: Ming Lei <ming.lei@redhat.com> +Date: Tue, 23 Aug 2022 18:38:19 +0800 +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set + +Commit b9684a71fca7 ("block, loop: support partitions without scanning") +adds GD_SUPPRESS_PART_SCAN for replacing part function of +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since +loop doesn't want to add partitions if GENHD_FL_NO_PART was set. +And it causes regression on libblockdev (as called from udisks) which +operates with the LO_FLAGS_PARTSCAN. + +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is +set. + +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c] + +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning") +Signed-off-by: Ming Lei <ming.lei@redhat.com> +Reviewed-by: Christoph Hellwig <hch@lst.de> +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming.lei@redhat.com +Signed-off-by: Jens Axboe <axboe@kernel.dk> +--- + block/partitions/core.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/block/partitions/core.c b/block/partitions/core.c +index fc1d70384825..b8112f52d388 100644 +--- a/block/partitions/core.c ++++ b/block/partitions/core.c +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk) + if (disk->flags & GENHD_FL_NO_PART) + return 0; + ++ if (test_bit(GD_SUPPRESS_PART_SCAN, &disk->state)) ++ return 0; ++ + state = check_partition(disk); + if (!state) + return 0; +-- +2.39.2 + diff --git a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch new file mode 100644 index 0000000000..9522c2d2cc --- /dev/null +++ b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch @@ -0,0 +1,87 @@ +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig <hch@lst.de> +Date: Fri, 27 May 2022 07:58:06 +0200 +Subject: [PATCH] block, loop: support partitions without scanning + +Historically we did distinguish between a flag that surpressed partition +scanning, and a combinations of the minors variable and another flag if +any partitions were supported. This was generally confusing and doesn't +make much sense, but some corner case uses of the loop driver actually +do want to support manually added partitions on a device that does not +actively scan for partitions. To make things worsee the loop driver +also wants to dynamically toggle the scanning for partitions on a live +gendisk, which makes the disk->flags updates non-atomic. + +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART +in the loop driver. + +Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1] + +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") +Reported-by: Ming Lei <ming.lei@redhat.com> +Signed-off-by: Christoph Hellwig <hch@lst.de> +Reviewed-by: Ming Lei <ming.lei@redhat.com> +Link: https://lore.kernel.org/r/20220527055806.1972352-1-hch@lst.de +Signed-off-by: Jens Axboe <axboe@kernel.dk> +Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> +--- + drivers/block/loop.c | 8 ++++---- + include/linux/blkdev.h | 1 + + 2 files changed, 5 insertions(+), 4 deletions(-) + +diff --git a/drivers/block/loop.c b/drivers/block/loop.c +index 4769caab9ff9..a76302450c46 100644 +--- a/drivers/block/loop.c ++++ b/drivers/block/loop.c +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, fmode_t mode, + lo->lo_flags |= LO_FLAGS_PARTSCAN; + partscan = lo->lo_flags & LO_FLAGS_PARTSCAN; + if (partscan) +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + + /* enable and uncork uevent now that we are done */ + dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0); +@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool release) + mutex_lock(&lo->lo_mutex); + lo->lo_flags = 0; + if (!part_shift) +- lo->lo_disk->flags |= GENHD_FL_NO_PART; ++ set_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + lo->lo_state = Lo_unbound; + mutex_unlock(&lo->lo_mutex); + +@@ -1598,7 +1598,7 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info) + + if (!err && (lo->lo_flags & LO_FLAGS_PARTSCAN) && + !(prev_lo_flags & LO_FLAGS_PARTSCAN)) { +- lo->lo_disk->flags &= ~GENHD_FL_NO_PART; ++ clear_bit(GD_SUPPRESS_PART_SCAN, &lo->lo_disk->state); + partscan = true; + } + out_unlock: +@@ -2428,7 +2428,7 @@ static int loop_add(int i) + * userspace tools. Parameters like this in general should be avoided. + */ + if (!part_shift) +- disk->flags |= GENHD_FL_NO_PART; ++ set_bit(GD_SUPPRESS_PART_SCAN, &disk->state); + disk->flags |= GENHD_FL_EXT_DEVT; + atomic_set(&lo->lo_refcnt, 0); + mutex_init(&lo->lo_mutex); +diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h +index 905844172cfd..15815f1ced9e 100644 +--- a/include/linux/blkdev.h ++++ b/include/linux/blkdev.h +@@ -813,6 +813,7 @@ static inline unsigned int blk_queue_depth(struct request_queue *q) + */ + #define BLK_DEFAULT_SG_TIMEOUT (60 * HZ) + #define BLK_MIN_SG_TIMEOUT (7 * HZ) ++#define GD_SUPPRESS_PART_SCAN 5 + + struct rq_map_data { + struct page **pages; +-- +2.39.2 + diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb b/meta/recipes-kernel/linux/linux-yocto_5.15.bb index 1c6b3d1112..17d36524f7 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb @@ -38,6 +38,10 @@ KBRANCH:class-devupstream = "v5.15/base" SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}" +SRC_URI += "file://0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch" +SRC_URI += "file://0001-block-loop-support-partitions-without-scanning.patch" + + LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46" LINUX_VERSION ?= "5.15.149"