Norman,
Thanks for the comment. On first pass, it looks like you've diagnosed a failure
correctly.
Please open another bug and add output of 'cloud-init collect-logs'.
thanks.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
2021-06-17 01:37:56,633 - util.py[WARNING]: Failed: growpart /dev/vda 2
2021-06-17 01:37:56,634 - util.py[DEBUG]: Failed: growpart /dev/vda 2
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line
156, in resize
subp.subp(["growpart",
This bug is believed to be fixed in cloud-init in 17.1. If this is still
a problem for you, please make a comment and set the state back to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
** Changed in: cloud-init
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707222
Title:
usage of /tmp during boot is not safe due to systemd-tmpfiles-clean
This bug was fixed in the package cloud-init - 0.7.9-267-g922c3c5c-
0ubuntu1
---
cloud-init (0.7.9-267-g922c3c5c-0ubuntu1) artful; urgency=medium
* New upstream snapshot.
- Ec2: only attempt to operate at local mode on known platforms.
(LP: #1715128)
- Use
** Merge proposal linked:
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/329811
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707222
Title:
usage of /tmp during boot is
Some solutions:
a.) Use systemd PrivateTmp which mounts a filesystem over /tmp the process.
The issue here is that would only solve for systemd boot.
b.) set up our own tmp and use it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Note there is some discussion of this bug in irc and other options at
https://irclogs.ubuntu.com/2017/07/28/%23ubuntu-devel.html#t16:24
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707222
Title:
>From another bug with the same root cause, a failure might look like this:
Apr 12 07:56:33 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command ['mount',
'-o', 'ro,sync', '-t', 'auto', '/dev/sr0', '/tmp/tmpzq70nqyi'] with allowed
return codes [0] (shell=False, capture=True)
Apr 12 07:56:33 ubuntu
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707222
Title:
/tmp is only guaranteed to be in a usable state after sysinit.target
currently. Or more generally, after system is fully up only.
During boot (initramfs, post-initramfs, early boot, post-boot) system
services should use /run, private runtime dir, private tmp dir.
This is not a bug in Ubuntu boot
So Something is definitely cleaning on boot.
Maybe I just misunderstood your statement, but above it seems like you were
saying that only old files named like those would be removed.
Try this:
$ lxc launch ubuntu-daily:artful a1
$ lxc exec a1 -- touch /tmp/foo
$ lxc restart a1
$ lxc exec a1
systemd-tmpfiles-clean is racy, but only cleans things as per
tmpfiles.d/ configs in /run /etc /usr/lib, for things that explicitely
specify to clean themself older than some value.
For /tmp the affected paths are older than 10 days only:
d /tmp/.X11-unix 1777 root root 10d
d /tmp/.ICE-unix 1777
13 matches
Mail list logo
