© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Thanks! TL;DR: the partx call didn't change much.
On the failing instance, this is when the partx call happens:
2019-07-29 12:09:25,391 - util.py[DEBUG]: Running command ['partx', '--update', '/dev/sda']
Looking in the journal at that timestamp, I see (lines omitted and/or edited for brevity):
2019-07-
2019-07-
2019-07-
2019-07-
2019-07-
These remove/add lines for sda14 are consistent with what I saw when just running `partx` by hand in an instance.
Looking at the passing instance, there is one noticeable difference: the sda14 remove/add KERNEL events are emitted to the log _before_ any of the UDEV events from the resizing are emitted. This means that:
* On the failing instance, we see the first resizing KERNEL event (sda) emitted at 12:09:25.347818 and the sda1 UDEV event emitted at 12:09:25.372478; .025s.
* On the passing instance, we see the first resizing KERNEL event (sda) emitted at 12:14:21.925924 and the sda1 UDEV event emitted at 12:14:22.002377; .076s.
(And, once again, we see that the order in which udev processes those events goes sda15, sda14, sda1.)