> This bug is still present in Ubuntu Jammy 22.04 LTS, I tested this
today. How can I reopen this bug?
just open a new bug. show the versions you're using and output of failure.
it'd be helpful if you referenced this bug.
--
You received this bug notification because you are a member of Ubuntu
** Also affects: cloud-init (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066066
Title:
cloud-init startup failure with Python 3.9.5, Ubun
Public bug reported:
Running ykman-gui on 22.04 currently shows the following. ykman works
fine.
NameError: name 'yubikey' is not defined
)
qml: qrc:/qml/YubiKey.qml:208: TypeError: Cannot read property 'success' of
undefined
"PyOtherSide error: Traceback (most recent call last):\n\n File \"\
Public bug reported:
I'm not sure if this is incorrect behavior in schroot or incorrect
assumption in sbuild-launchpad-chroot.
I have a system where I was not able to use union, so the focal-amd64
config that was built by sbuild-launchpad-chroot looks like below. When
attempting to build from it
** Summary changed:
- swtmp fails in focal with apparor
+ swtpm fails in focal with apparor
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1859506
Title:
swtpm fails in focal with apparor
To manage
@Noah,
cloud-init isn't doing anything wrong. Its working as designed.
'growroot', which is provided by cloud-initramfs-tools (upstream [1],
package [2]) also didn't do anything wrong. It's sole purpose in the
initramfs is to do what it is doing.
I'm not sure what code creates the image you've p
> I thought cloud-initramfs-growroot was solely used with old kernels that
> can't resize mounted
> filesystems but I could be wrong. Wondering though why we install that
> package all of a sudden.
that is another option, to remove cloud-initramfs-growroot from the
image/initrd.
The problem wit
@Noah,
The image you pointed at there has the package 'cloud-initramfs-growroot'
in its initramfs. cloud-initramfs-growroot is going to run growpart on the
root filesystem during the initramfs unless one of the following files
exists on the root filesystem:
/var/lib/cloud/instance/root-grown
** Also affects: sbuild-launchpad-chroot (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: sbuild-launchpad-chroot (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Public bug reported:
Nothing is checking exit code of tar when the downloaded tarball is
extracted.
Tar could fail for many reasons including permission or
filesystem full.
If tar failed, sbuild-launchpad-chroot would just continue on.
The user would likely fail in a less obvious way later on.
@Eli,
I can recreate your problem, but it looks to me like a bug in ksh. ksh
complains that 'local can only be used in a function, when as shown
below it *is* being used in a function.'
My suggestion is to file a bug with ksh2020.
root@focal1:~# ksh -c 'foo() { local a=1; echo $?; }; foo'
ksh:
Public bug reported:
When building some software (https://github.com/puzzleos/uefi-dev)
I ran into a problem/bug in efitools 'sign-efi-sig-list'.
The end result in my case was that an attempt to update the PK variable
in uefi (ovmf files from 20.04 with qemu from 20.04) resulted in an
exit code o
Marking this fix-released in focal as bug 1923232 was released to focal.
So this should be fixed in '1:4.0.6-0ubuntu1~20.04.1'.
** Changed in: lxc (Ubuntu Focal)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subs
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.
https://b
lxc auto package tests show green for 4.0.6-0ubuntu1 other than i386,
which failed previously.
* amd64:
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/amd64/l/lxc/20210525_040935_c4b64@/log.gz
* arm64:
https://autopkgtest.ubuntu.com/results/autopkgtest-focal/focal/arm64/l/lxc/2
** Description changed:
Hi. I'm using 20.04, and I need a fix for
https://github.com/lxc/lxc/pull/3589
I think my only options to get that via packaging are
a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
b.) build my own.
I don't love either of those opti
Just fwi, this is in 4.0.6 which is up for SRU in LP: #1923232.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1918955
Title:
SRU network: fix LXC_NET_NONE cleanup
To manage notifications about this
This would fix LP: #1918955.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1923232
Title:
SRU of LXC 4.0.6 to focal (upstream bugfix release)
To manage notifications about this bug go to:
https://b
** Description changed:
Hi. I'm using 20.04, and I need a fix for
https://github.com/lxc/lxc/pull/3589
- I think my only options to get that via packaging are
- a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
- b.) build my own.
+ I think my only options to get that
Public bug reported:
Hi. I'm using 20.04, and I need a fix for
https://github.com/lxc/lxc/pull/3589
I think my only options to get that via packaging are
a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master
b.) build my own.
I don't love either of those options.
Can we pleas
For reference, ubuntu-devel post about '-o APT::Update::Error-Mode=any'
at https://lists.ubuntu.com/archives/ubuntu-devel/2021-February/041374.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1693900
** Description changed:
I've created a 'network-config' file with Terraform's yamldecode() function
that contains (btw. I've tried with the version being a Number w/o quotes and
as well as a String as shown here):
---
"network":
- "ethernets":
- "eth0":
- "gateway4": "192.168.1
The change made here seems to be having fallout at
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1906187
** Description changed:
== Short summary ==
- In lxd containers launched by juju,
+ In lxd containers launched by juju,
/var/lib/cloud/seed/nocloud-net/network-config has:
-
There are a slew of bugs and apparently random fallout of /dev/console not
working.
In my opinion, its really *not* helpful to just ignore that 'write' to stdout
fails. Ignoring errors is never really a solution. In this case, cloud-init
may have specifically opened /dev/console. But in othe
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Committed
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Assignee: (unassigned) => Markus Schade (lp-markusschade)
--
You rec
@Markus,
Can you please provide a link to documentation showing that?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about thi
I set back to 'New', Pengpeng's comment does make sense.
cloudinit/net/sysconfig.py's render_network_state calls _render_dns.
_render_dns then will load the existing file if it is present.
So the end result is that if we have a "stale" version of
/etc/resolv.conf on the system, then the dns serve
** Description changed:
=== Begin SRU Template ===
[Impact]
The 16.10 kernel dropped a legacy kernel module alias that allowed usage of
the 'overlay' filesystem via name 'overlayfs'. This broke overlayroot as
it explicitly tried to to use 'overlayfs' by name in loading of modules and
https://github.com/canonical/cloud-init/pull/568
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/158
Title:
document manual_cache_clean better
To manage notifications about this bug go to:
https:
** Description changed:
LP: #1885527 raised (not for the first time) a general failure of cloud-init's
documentation to cover 'manual_cache_clean'. In fact, this configuration
value not referenced at all in readthedocs, but only in
- doc/examples/cloud-config.txt
-
https://github.com/can
** Changed in: cloud-init (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1893064
Title:
sru cloud-init (20.2-45 to 20.3-0) Xenial, Bionic, and Focal
To ma
See bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-
tools/+bug/1864571
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1892879
Title:
python-ubuntutools package is empty.
To manage notifica
I'm pretty sure this change caused bug 1892879 also.
basically, the python-ubuntudevtools package is empty.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864571
Title:
SRU ubuntu-dev-tools
To mana
Public bug reported:
The python-ubuntutools package is empty.
root@b1:~# dpkg -L python-ubuntutools
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python-ubuntutools
/usr/share/doc/python-ubuntutools/NEWS.Debian.gz
/usr/share/doc/python-ubuntutools/changelog.gz
/usr/share/doc/python-ubuntutools
Verification log of focal.
Note 2 things:
a.) recent update to the test script
b.) if you look closely at the log you'll see '91smoser-schroot-setup' output.
That is from https://gist.github.com/smoser/14df5f0cd621e10d2282d7c90345e322
It should not affect the verification of this bug.
** Attach
** Attachment added: "updated test - adds user, not root to sbuild"
https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+attachment/5402546/+files/test-sbuild-launchpad-chroot
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872163
Title:
focal chroots broken due to change in sources.list
To
I'm going to mark this fix-released.
The general bug as described in the description is that cloud-init can't
correctly apply networking for all interfaces.
cloud-init local applies networking configuration to the system, and
should apply before the system brings networking up. Thus appearing to
[ubuntu/groovy-proposed] cloud-initramfs-tools 0.47ubuntu1 (Accepted)
^ landed Ryan's fix (comment #38 mp 389422)
** Merge proposal linked:
https://code.launchpad.net/~raharper/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/389422
--
You received this bug notification because you a
@Rod
I wouldn't bother until you see an image with serial greater than 20200813.
If it doesn't have cloud-initramfs-tools > 0.45ubuntu1, its not going
to work with groovy.
then test that and complain with logs if its not working.
On Fri, Aug 14, 2020 at 1:15 PM Rod Smith <1890...@bugs.launchpad.
t; Fix Released
** Changed in: cloud-initramfs-tools (Ubuntu)
Assignee: (unassigned) => Scott Moser (smoser)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890803
Title:
Groovy amd6
@Eric, William,
I think you're taking a very narrow view on this when a more thoughtful
review is needed.
Ubuntu should identify a general policy on 'client <-> server' version
backwards and forwards compatibility guarantees. That policy should be
implemented here. The fact this particular clie
@Eric,
Well... We'd only be carring the change for 20.04. I would not suggest to
carry it for 20.10 or beyond. As my change is right now I dont' think I would
accept it for upstream. It should be sufficient for a stable release though.
I really suspect that if upstream cared about python < 3.
@all,
Please review a MP at
https://code.launchpad.net/~smoser/ubuntu/+source/sshuttle/+git/sshuttle/+merge/388062
that will fix this for focal -> trusty and keep focal -> focal working.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Lukasz
sshuttle does not require itself to be installed on the server. Rather
it "pushes" itself from the client to the server. So the code that
executes on client is the same as that on the server.
Maybe the table below will help:
client | server | comment
trusty | focal | broken due to py3
** Merge proposal linked:
https://code.launchpad.net/~smoser/ubuntu/+source/sshuttle/+git/sshuttle/+merge/388062
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1873368
Title:
ssshuttle server fai
I opened bug 158 to request better documentation on this feature.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regenerating ssh-keys
To manage notifications about thi
Public bug reported:
LP: #1885527 raised (not for the first time) a general failure of cloud-init's
documentation to cover 'manual_cache_clean'. In fact, this configuration
value not referenced at all in readthedocs, but only in
doc/examples/cloud-config.txt
https://github.com/canonical/cloud-
@Daniel,
> One convenience we could potentially provide: if cloud-init had a way
> for image creators to express "when next launched, cloud-init should
> treat that instance ID as immutable and permanent" (in a way that could
> be undone on subsequent boots, if a user wants to "unfreeze" an instan
@William,
The fix here does break python < 3.5 (as advertised in the
debian/patches/ patch). It is mostly trivial to make this change in a
backwards compatible way, so we should probably do that.
I wonder what the official policy is on breaking this "client"s
interaction with an ubuntu release ve
** Changed in: cloud-utils (Ubuntu)
Assignee: Scott Moser (smoser) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1491148
Title:
growpart doesn't work with mdraid dev
** Changed in: cloud-utils (Ubuntu)
Status: In Progress => Confirmed
** Changed in: cloud-utils (Ubuntu Eoan)
Status: In Progress => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bu
@Felipe,
Two things I think should be changed in your debdiff:
a.) version should be 0.78.5-1ubuntu0.1 instead of 0.78.5-1ubuntu1 per
https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging .
I'm not certain on that though.
b.) the referenced commit (9c873579) is not the co
@slashd,
Are you suggesting your 'A' (version 1.0.2) for focal? Unless there are
other reasons than this bug, that feels like not the right path for SRU.
So that means 'B' is the path forward for focal. So I might suggest
just doing 'B' for groovy now (adding ubuntu delta). That would then
all
@Valery,
Some cloud platforms provide the instance id via some non-network
channel (dmi data is common). In those cases, cloud-init will check
cached value versus the locally-available instance-id before looking for
a network available datasource.
So, if Hetzner provides that information in some
"AGAIN: Why is cloud-init still manipulating the machine *after*
initialization and first boot?"
Because cloud-init thinks it is a "first boot". A supported use case for
cloud-init is:
* boot instance on cloud
* ssh in
* install some packages, prep this instance
* stop instance
* snapshot d
after replying with collected logs, please set the status back to 'new'.
thanks for taking the time to file a bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885527
Title:
cloud-init regeneratin
Hi, please attach the output of 'cloud-init collect-logs' when run on a
system that demonstrates the problem.
cloud-init uses the "instance-id" from the metadata service to indicate
a new instance. Some things run once per instance, some things run once
per boot.
** Changed in: cloud-init (Ubu
this worked for me to set all profiles as I wanted in 20.04
$ val='@ms "-,:.;/?%&#_=+@~·"'
$ profids=$(dconf list /org/gnome/terminal/legacy/profiles:/ | grep -v ^list$)
$ for profid in $profids; do dconf write
/org/gnome/terminal/legacy/profiles:/${profid%/}/word-char-exceptions "$val";
done
-
@Guilherme,
Simply returning non-error (0) in one function in the initramfs isn't going to
solve the problem. Anything that is checking the return value of a write() to
its stdout will fail.
That could be a shell 'echo', it could be a C write().
In order to take that path completion, you'd hav
@stgraber,
The bug subject says "Huge and slow". Shame on me to make 1 bug for 2 issues.
But wrt "is this fixed", groovy images are still dramatically bigger *and*
slower to boot than bionic images.
a.) Huge. Still looks much bigger, 'Huge' can obviously be argued.
346M for current groovy daily
@Anh Vo,
Thanks for looking at this.
It almost seemed too perfect for me to believe the pre-provisioning
stuff kicked in, and that there were exactly zero journal entries in
almost 9 days.
I would think it'd be nice for cloud-init to clearly state "pre-
provisioned system waited X seconds" or so
In my head there are a few possibilities here:
a.) azure correctly guessed that I was going to launch an instance and
"pre-provisioned" it a week before I did it. this seems unlikely to me for a
number of reasons, but I could be convinced that if this happened, everything
is working as designed.
Public bug reported:
I launched a new instance on azure and noticed that it had 'uptime' of 8 days.
Debugging a bit with Odd_Bloke in #cloud-init, it certainly seems that it is
around the time when timesync ran:
$ journalctl -o short-monotonic -u systemd-timesyncd.service
--no-pager
-- Logs be
** Description changed:
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No
** Description changed:
+ - Begin SRU info -
+ [Impact]
+ Users of sbuild-launchpad-chroot cannot use chroots created with
+ sbuild-launchpad-chroot with a build-release of focal or groovy.
+ An attempt to do so fails during 'apt-get update' as the
+ /etc/apt/sources.list file that is cr
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876139
Title:
Groovy cloud-images failing during growpart
To manage notifications about
@wgh,
My experience is that it is unfortunately not that simple.
It may have worked for you.
At the point in which it starts to fail, it repeatedly will fail.
But up until some point, writes to stdout work fine. I believe this is because
there is a buffer and it only begins failing when it has f
** Also affects: sbuild-launchpad-chroot (Ubuntu Groovy)
Importance: Undecided
Status: Confirmed
** Also affects: sbuild-launchpad-chroot (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: sbuild-launchpad-chroot (Ubuntu Bionic)
Importance: Undecided
S
** Merge proposal linked:
https://code.launchpad.net/~smoser/ubuntu/+source/sbuild-launchpad-chroot/+git/sbuild-launchpad-chroot/+merge/383600
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872163
The real fix here is kernel improvement (or bug fix if you want to
consider current kernel behavior a bug). Anything else is just going to
push around the failure.
That is what was determined in 2013, and its probably still true how.
https://bugs.launchpad.net/ubuntu/+source/cloud-initramfs-to
** Changed in: cloud-utils
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/1876139
Title:
Groovy cloud-images failing during growpart
To manage notifications
https://code.launchpad.net/~smoser/cloud-utils/+git/cloud-utils/+merge/383431
Merge proposal to upstream cloud-utils ^
** Also affects: cloud-utils
Importance: Undecided
Status: New
** Changed in: cloud-utils
Status: New => Confirmed
** Changed in: cloud-utils
Importance: Un
I realize this is probably just seen as noise. But I think its
important that everyone here understand.
Growpart supports using either fdisk or gdisk. But I have recently
considered deleting the gdisk support.
I'm curious why fdisk is seen as "an old package". fdisk/sfdisk supports
GPT partition
independent of how sfdisk gets into a cloud-image, cloud-utils should identify
its dependency.
Something like https://paste.ubuntu.com/p/Fzwkm2PgqF/
** Also affects: cloud-utils (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member
@Markus,
Please open a bug against cloud-initramfs-growroot and reference it here (and
reference this bug there).
Please also provide a full console log.
fwiw, generally speaking cloud-initramfs-growroot has not been necessary
since at least 14.04, quite possibly even beefore.
--
You received
I hit this today, and filed bug 1873917 before dupe'ing it to this.
I'd think that the main pain points are
a.) using overlay in a container that is backed by zfs via lxd
b.) using overlay when using zfs root
(https://didrocks.fr/2019/10/11/ubuntu-zfs-support-in-19.10-zfs-on-root/)
I attached a r
*** This bug is a duplicate of bug 1718761 ***
https://bugs.launchpad.net/bugs/1718761
** This bug has been marked a duplicate of bug 1718761
It's not possible to use OverlayFS (mount -t overlay) to stack directories
on a ZFS volume
--
You received this bug notification because you are a
Public bug reported:
zfs cannot be used as a filesystem for an overlay mount's 'upperdir' or
'workdir' arguement.
If you have zfs root, or are inside an lxd that uses zfs then you'll not
be able to use overlay mounts without working around this bug.
It can be worked around by using a tmpfs.
$
(updated from the comment)
A workaround patch changing 90apt-sources.
** Patch added: "fix/workaround"
https://bugs.launchpad.net/ubuntu/+source/sbuild-launchpad-chroot/+bug/1872163/+attachment/5356285/+files/fix-1872163.diff
--
You received this bug notification because you are a member of
Here is *a* fix/workaround that I'd expect to work for existing releases
and focal
$ diff -u /etc/schroot/setup.d/90apt-sources.dist
/etc/schroot/setup.d/90apt-sources
--- /etc/schroot/setup.d/90apt-sources.dist 2020-04-17 14:26:50.510749407
-0400
+++ /etc/schroot/setup.d/90apt-sources 2020
*** This bug is a duplicate of bug 1872163 ***
https://bugs.launchpad.net/bugs/1872163
Public bug reported:
the file '/etc/schroot/setup.d/90apt-sources' attempts to enable
'APT_POCKETS' (release, security, updates, proposed). It attempts to
change the existing /etc/apt/sources.list.
source
In case it wasn't clear above... I don't personally believe that
specifying "renderer" should be required or even allowed. Its a hack.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1870346
Title:
W
In my opinion, the provider of network configuration to an instance
(image) should not have to "know" that the image uses networkd,
NetworkManager, ifupdown, wikid They just declare "make the
networking like this".
The operating system inside implements API. Anything else just cannot
work.
It seems really like this is Recommends.
Its not a hard depends.
On Mon, Mar 9, 2020 at 2:55 PM Ryan Harper <1866...@bugs.launchpad.net> wrote:
>
> In particular, user passed in cloud-config for augmenting ssh
> configuration in the guest (setting user ssh keys) however, it was
> unknown that the
@Mohammed, Thank you for your help. I dont think we need anything
else from you.
Scott
On Mon, Mar 23, 2020 at 2:10 PM Mohammed Sameer B
<1868...@bugs.launchpad.net> wrote:
>
> @Scott,
>
> So shall I consider the issue fixed or still some troubleshooting needs
> to be done?
>
>
> Thanks
>
> --
>
@Mohammed,
I was hoping for /var/lib/cloud contents *before* running 'cloud-init clean'.
The other logs look fine.
@Other cloud-init devs,
I'd like someone else to hazard a guess at what went on here.
The general issue is:
* very old cloud-init (0.7.9) booted on azure
* migrated to ec2, still
It really seem slike you still have /var/lib/waagent around.
See lines in your log like:
2020-03-21 07:36:37,988 - stages.py[DEBUG]: restored from checked
cache:ataSourceAzure [seed=/var/lib/waagent]
For reference, could youp lease attach:
tar -C /var/lib/ -cvf var-lib-cloud.tar.gz cloud/
Th
@Mohammed,
the cloud-init.log clearly shows cloud-init still using the Azure datasource
due to the presense of /var/lib/waagent
I would suggest removing that directory.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.lau
I'd suggest making the changes, and inserting a ssh key that you have
access to into root.
Then reboot and see what happens. You should then be able to log in
and debug a bit, run 'cloud-init collect-logs' and post here.
On Fri, Mar 20, 2020 at 10:20 AM Mohammed Sameer B
<1868...@bugs.launchpad.n
@Mohammed,
If you are using an EBS root, then you can detach the volume and attach
to another instance and then collect logs from it.
I might suggest that you make a snapshot, then change the volume to and
add an ssh key to root's ssh keys and then re-attach that volume to the
original instance a
@Mohammed, I would do a 'rm -Rf /var/lib/waagent' before migrating
future images. And I'd suggest that you can probably just 'touch
/var/lib/cloud/instance/warnings/.skip'. But your system is in a wierd
state.
@Cloud-init devs,
What happened here was:
a.) instance booted on Azure
b.) instanc
Hi Mohammed,
Please attach the output of 'cloud-init collect-logs' and then set this back to
New.
Thanks.
** Changed in: cloud-init (Ubuntu)
Status: New => Incomplete
** Tags added: dsid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
I bumped into this yesterday on bionic.
The commit 1e04bb71da3ed829 [1] reports to fix it.
[1]
https://github.com/lxc/lxc/commit/1e04bb71da3ed829761ae8c729c3d021a6a709df
Hopefully there will be a 3.0.x update to bionic at some point.
** Also affects: lxc (Ubuntu Focal)
Importance: Medium
It'd also be sane to just *not* depend on sshd.
cloud-init doesn't really depend on sshd to my knowledge, but probably does
throw some warnings or not function perfectly if its not there.
nothing about cloud-init should require sshd though. it'd be good to run
without it.
--
You received this b
** Changed in: ssh-import-id
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864107
Title:
ssh-import-id broken on Focal
To manage notifications about th
** Changed in: ssh-import-id
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1864107
Title:
ssh-import-id broken on Focal
To manage notifications about this bug go
** Changed in: ssh-import-id
Status: New => Confirmed
** Changed in: ssh-import-id
Assignee: (unassigned) => Dave Jones (waveform)
** Changed in: ssh-import-id
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
this seemed to "just work" for me.
http://paste.ubuntu.com/p/93dWDPZfZT/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1834875
Title:
cloud-init growpart race with udev
To manage notifications abou
a.) I gave the wrong link. ugh. It should have been:
https://code.launchpad.net/~smoser/cloud-initramfs-tools/+git/cloud-initramfs-tools/+merge/379774
b.) the fixed link to 'a' probably makes more sense now. But basically
you need a newer cloud-initramfs-tools to adjust for the fact that
growp
1 - 100 of 8709 matches
Mail list logo
