Public bug reported:
[Impact]
* Currently the initramfs-tools autopkgtest fails for at least AMD64, with the
following signature:
"mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device /dev/loop0p1
does not exist."
* The reason for that is the test trying immediately to use that
partition on the loop device, but kernel may not have a partition re-
read ioctl issued, so the test may fail as observing a nonexistent
partition.
* The fix proposed here is just to manually run "partprobe" before using
the new to-be-discovered loop partition in the net autopkgtest.
[Test Case]
* Build initramfs-tools in PPA and observe the failure in AMD64 - the signature
of the failure is as discussed in the Impact section above.
[Regression Potential]
* Extremely low potential, we are just introducing a partition re-read/probe
operation during autopkgtest phase, in order to keep the partition table of
loop devices consistent before the test uses it.
* The only potential issue I see with that is if for some reason we don't have
partprobe in the autopkgtest environment, but that shouldn't happen since
parted package is on ubuntu-standard.
* Notice that this test is not executed in Debian CI given that CI has
no support for VMs, and this test requires that.
** Affects: initramfs-tools (Ubuntu)
Importance: Undecided
Assignee: Guilherme G. Piccoli (gpiccoli)
Status: In Progress
** Tags: seg
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675
Title:
Autopkgtest failure on latest version of initramfs-tools - lack of
partprobe
Status in initramfs-tools package in Ubuntu:
In Progress
Bug description:
[Impact]
* Currently the initramfs-tools autopkgtest fails for at least AMD64, with
the following signature:
"mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device
/dev/loop0p1 does not exist."
* The reason for that is the test trying immediately to use that
partition on the loop device, but kernel may not have a partition re-
read ioctl issued, so the test may fail as observing a nonexistent
partition.
* The fix proposed here is just to manually run "partprobe" before
using the new to-be-discovered loop partition in the net autopkgtest.
[Test Case]
* Build initramfs-tools in PPA and observe the failure in AMD64 - the
signature of the failure is as discussed in the Impact section above.
[Regression Potential]
* Extremely low potential, we are just introducing a partition re-read/probe
operation during autopkgtest phase, in order to keep the partition table of
loop devices consistent before the test uses it.
* The only potential issue I see with that is if for some reason we don't
have partprobe in the autopkgtest environment, but that shouldn't happen since
parted package is on ubuntu-standard.
* Notice that this test is not executed in Debian CI given that CI has
no support for VMs, and this test requires that.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
