> (Odds are that whatever causes it to be recreated later in boot would be
> blocked by cloud-init waiting.)
But that's not happening. The instance does boot normally, the only
service degraded is cloud-init and there is no significant delay either.
So conversely, if I put a loop into cloud-init
I may be missing the point, but the symlink in question is eventually
recreated, does that tell us anything? This here
> Dan had put a udevadm settle in this spot like so
>
> def get_size(filename)
>util.subp(['udevadm', 'settle'])
>os.open()
looks to me like the event queue should
** Changed in: cloud-init
Status: Invalid => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1834875
Title:
cloud-init growpart race with udev
Status in
@daniel-thewatkins, I'm not convinced that this bug is invalid for
cloud-init. After reading through all of this again, I still don't
understand, what guarantee there is that when `udevadm settle` is
called, all relevant events have already been queued.
Copying udevadm over, and with that
When I say unorthodox, I mean I copied the binary ;) So that should
narrow it down quite a bit. Unless there is more funniness involved.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Oh, good observation, Dan. Yes, it was happening on Cosmic and later.
But I cannot say when it started. Now in a moment of despair I tried
something very unorthodox: I copied udevadm from Bionic to the Eoan
image and ran the tests again. Look and behold, all pass.
** No longer affects:
Public bug reported:
AFFECTED RELEASE:
Bionic
PACKAGE VERSION:
debconf - 1.5.66
DESCRIPTION:
When upgrading the kernel on a recent Bionic minimal image, the user is
prompted to resolve a conflict in the file /boot/grub/menu.lst.
The minimal images do not have dialog/whiptail installed, so
7 matches
Mail list logo
