Hi Tom,
On Tue, 24 Jan 2023 at 12:02, Tom Rini <tr...@konsulko.com> wrote:
>
> On Tue, Jan 24, 2023 at 11:55:32AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 24 Jan 2023 at 11:28, Tom Rini <tr...@konsulko.com> wrote:
> > >
> > > On Tue, Jan 24, 2023 at 11:15:15AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 24 Jan 2023 at 08:49, Tom Rini <tr...@konsulko.com> wrote:
> > > > >
> > > > > On Tue, Jan 24, 2023 at 03:56:00AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 23 Jan 2023 at 18:39, Tom Rini <tr...@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Jan 17, 2023 at 10:47:22AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > At present this test sets up a partition table on mmc1. But
> > > > > > > > this is used
> > > > > > > > by the bootstd tests, so it is not possible to run those after
> > > > > > > > this test
> > > > > > > > has run, without restarting the Python test harness.
> > > > > > > >
> > > > > > > > This is inconvenient when running tests repeatedly with 'ut
> > > > > > > > dm'. Move the
> > > > > > > > test to use mmc2, which is not used by anything.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org>
> > > > > > >
> > > > > > > When I run tests like this:
> > > > > > > TEST="not sleep and not event_dump and not bootmgr and not
> > > > > > > extension"
> > > > > > > ./tools/buildman/buildman -o /tmp/sandbox -P --board sandbox
> > > > > > > ./test/py/test.py --bd $ARGS --build-dir /tmp/sandbox -k "$TEST"
> > > > > > > -ra
> > > > > > > I get:
> > > > > > > ========================================== FAILURES
> > > > > > > ===========================================
> > > > > > > _________________________________ test_ut[ut_dm_dm_test_part]
> > > > > > > _________________________________
> > > > > > > test/py/tests/test_ut.py:341: in test_ut
> > > > > > > assert output.endswith('Failures: 0')
> > > > > > > E assert False
> > > > > > > E + where False = <built-in method endswith of str object at
> > > > > > > 0x2776470>('Failures: 0')
> > > > > > > E + where <built-in method endswith of str object at
> > > > > > > 0x2776470> = 'Test: dm_test_part: part.c\r\r\n** No device
> > > > > > > specified **\r\r\nCouldn\'t find partition mmc <NULL>\r\r\n** No
> > > > > > > device ...: 0 == do_test(uts, 2, "1:2", 0): Expected 0x0 (0), got
> > > > > > > 0x1 (1)\r\r\nTest dm_test_part failed 4 times\r\r\nFailures:
> > > > > > > 4'.endswith
> > > > > > > ------------------------------------ Captured stdout call
> > > > > > > -------------------------------------
> > > > > > > => ut dm dm_test_part
> > > > > > > Test: dm_test_part: part.c
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc <NULL>
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No partition table - mmc 0 **
> > > > > > > Couldn't find partition mmc 0
> > > > > > > Could not find "test1" partition
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > Couldn't find partition mmc #test1
> > > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > > Couldn't find partition mmc 1:0
> > > > > > > ** Invalid partition 2 **
> > > > > > > Couldn't find partition mmc 1:2
> > > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > > &mmc_dev_desc, &part_info, whole): Expected 0x2 (2), got
> > > > > > > 0xfffffffe (-2)
> > > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2",
> > > > > > > 0): Expected 0x0 (0), got 0x1 (1)
> > > > > > > Test: dm_test_part: part.c (flat tree)
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc <NULL>
> > > > > > > ** No device specified **
> > > > > > > Couldn't find partition mmc
> > > > > > > ** No partition table - mmc 0 **
> > > > > > > Couldn't find partition mmc 0
> > > > > > > Could not find "test1" partition
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > ** Bad device specification mmc #test1 **
> > > > > > > Couldn't find partition mmc #test1
> > > > > > > ** Bad partition specification mmc 1:0 **
> > > > > > > Couldn't find partition mmc 1:0
> > > > > > > ** Invalid partition 2 **
> > > > > > > Couldn't find partition mmc 1:2
> > > > > > > test/dm/part.c:20, do_test(): expected ==
> > > > > > > part_get_info_by_dev_and_name_or_num("mmc", part_str,
> > > > > > > &mmc_dev_desc, &part_info, whole): Expected 0x2 (2), got
> > > > > > > 0xfffffffe (-2)
> > > > > > > test/dm/part.c:82, dm_test_part(): 0 == do_test(uts, 2, "1:2",
> > > > > > > 0): Expected 0x0 (0), got 0x1 (1)
> > > > > > > Test dm_test_part failed 4 times
> > > > > > > Failures: 4
> > > > > > > =>
> > > > > >
> > > > > > Oh dear. I believe this is an ordering problem. These two patches
> > > > > > need
> > > > > > to be applied together because the first one changes mmc1.img and
> > > > > > the
> > > > > > second one relies on that change:
> > > > > >
> > > > > > part: Add a function to find the first bootable partition
> > > > > > dm: part: Update test to use mmc2
> > > > > >
> > > > > > I have them quite far apart in the series.
> > > > > >
> > > > > > I can merge them into one commit, perhaps?
> > > > > >
> > > > > > >
> > > > > > > And further tests down the series also fail / introduce failures,
> > > > > > > but
> > > > > > > this is the first one, and why I thought v2 had more problems.
> > > > > >
> > > > > > For some reason I'm not seeing this, but it could be another
> > > > > > ordering
> > > > > > thing. I don't see failures on CI but it only tests the whole.
> > > > > >
> > > > > > Let me know what you'd like me to do. I don't currently have a way
> > > > > > to
> > > > > > run tests on every commit, so my testing there is a bit random. I
> > > > > > normally just build-test the series and then check with CI.
> > > > >
> > > > > Well, your ordering comment is interesting. I bisect'd down to this
> > > > > patch being a problem because with the full series applied I see:
> > > > > ========================================== FAILURES
> > > > > ===========================================
> > > > > ___________________________________ test_ut_dm_init_bootstd
> > > > > ___________________________________
> > > > > test/py/tests/test_ut.py:320: in test_ut_dm_init_bootstd
> > > > > setup_bootflow_image(u_boot_console)
> > > > > test/py/tests/test_ut.py:226: in setup_bootflow_image
> > > > > fname, mnt = setup_image(cons, mmc_dev, 0xc, second_part=True)
> > > > > test/py/tests/test_ut.py:45: in setup_image
> > > > > u_boot_utils.run_and_log(cons, 'sudo sfdisk %s' % fname,
> > > > > test/py/u_boot_utils.py:180: in run_and_log
> > > > > output = runner.run(cmd, ignore_errors=ignore_errors, stdin=stdin)
> > > > > test/py/multiplexed_log.py:182: in run
> > > > > raise exception
> > > > > E ValueError: Exit code: 1
> > > > > ------------------------------------ Captured stdout call
> > > > > -------------------------------------
> > > > > +qemu-img create /home/trini/work/u-boot/u-boot/mmc1.img 20M
> > > > > Formatting '/home/trini/work/u-boot/u-boot/mmc1.img', fmt=raw
> > > > > size=20971520
> > > > > +sudo sfdisk /home/trini/work/u-boot/u-boot/mmc1.img
> > > > > Checking that no-one is using this disk right now ... OK
> > > > >
> > > > > Disk /home/trini/work/u-boot/u-boot/mmc1.img: 20 MiB, 20971520 bytes,
> > > > > 40960 sectors
> > > > > Units: sectors of 1 * 512 = 512 bytes
> > > > > Sector size (logical/physical): 512 bytes / 512 bytes
> > > > > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > > > >
> > > > > >>> Created a new DOS disklabel with disk identifier 0xab7e7834.
> > > > > /home/trini/work/u-boot/u-boot/mmc1.img1: Created a new partition 1
> > > > > of type 'W95 FAT32 (LBA)' and of size 18 MiB.
> > > > > /home/trini/work/u-boot/u-boot/mmc1.img2: All space for primary
> > > > > partitions is in use.
> > > >
> > > > I see this on my Ubuntu 20.04 machine but it doesn't happen on 22.04.
> > > > Is it a bug in sfdisk? What version are you using?
> > > >
> > > > Works: 2.37.2-4ubuntu3
> > > > Fails: 2.34-0.1ubuntu9.3
> > > >
> > > > Do you see this in CI at all?
> > >
> > > Ah, so that's the fun part of this then. Yes, CI is fine since it's on
> > > 22.04, but my workstation is on 20.04, and so fails. Doing a quick try
> > > and running sandbox tests in Docker on my workstation does have the
> > > series passing. So, the series is fine, but I need to adjust my local
> > > flow a little bit now.
> >
> > OK ta.
> >
> > Yes I actually only found that out when I tried it on another machine
> > this morning. It was a surprise, but a bit of fiddling made me suspect
> > it is a bug, e.g. that it doesn't allow partitions as small as 2MB?
>
> One of the first hits I see on the error message is
> https://github.com/util-linux/util-linux/issues/851 which leads me to
> think yes, there's an sfdisk bug, and it's been fixed. So the reasonable
> paths forward here are that we just note that CI uses Ubuntu 22.02 and
> any failures based on host tool problems are up to users to deal with, I
> think. Since I let my workstation lag behind LTS upgrades for just a
> little bit, I'll just do the upgrade I was going to do in April, to
> 22.02.x, now'ish.
Oh great, thanks for that link.
OK, I will do the same.
Regards,
Simon
