This would fix LP: #1918955.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1923232
Title:
SRU of LXC 4.0.6 to focal (upstream bugfix release)
Status in lxc package in Ubuntu
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
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1918955
Title:
SRU network: fix LXC_NET_NONE cleanup
Status in
** 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
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
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
Touch seeded packages, which is subscribed to
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
Touch seeded packag
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
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.la
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
** 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
The easiest thing to do would be to just ship a keyring that had the
obsolete public signing keys. Then the consumer could hard code
that 'precise' was signed with keys A, B, C. and work stuff out like
that.
Alternatively possibly we might want to deliver some distro-info like
data.
ubuntu-rele
Quite a pleasent surprise I found today.
$ lxc launch ubuntu-daily:devel devel1
$ sleep 20
$ lxc exec devel1 systemctl status | grep State
State: running
$ lxc exec devel1 -- sh -c 'cat /etc/cloud/build.info; lsb_release -sc'
build_name: server
serial: 20190531
eoan
$ lxc exec devel1 -- sys
Public bug reported:
$ lxc launch ubuntu-daily:eoan devel1
$ sleep 10 # wait for boot
$ lxc exec devel1 /bin/bash
root@devel1:~# cat /proc/uptime
183.00 173.00
root@devel1:~# cat /etc/cloud/build.info
build_name: server
serial: 20190531
root@devel1:~# lsb_release -sc
eoan
root@devel1:~# journalc
Filed issue with lxcfs at
https://github.com/lxc/lxcfs/issues/285
** Bug watch added: LXCFS bug tracker #285
https://github.com/lxc/lxcfs/issues/285
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
http
best. fix. ever.
working after a reboot.
$ snap list lxd
Name Version RevTracking Publisher Notes
lxd 3.18 12211 stablecanonical✓ -
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://
I really think you are all *way* over thinking this.
a. growpart made a change to the partition table (using sfdisk)
b. growpart called partx --update --nr 3 /dev/sda
c. growpart exited
With a and b growpart created udev events. If you create udev events,
you really need to wait for those event
> > So that means we have this sequence of events:
> > a.) growpart change partition table
> > b.) growpart call partx
> > c.) udev created and events being processed
> That is not true. whilst sfdisk is deleting, creating, finishing
> partition table (a) and partx is called (b), udev events ar
** Also affects: cloud-utils
Importance: Undecided
Status: 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
If there is a race, or a need to wait, it almost certainly is in cloud-
utils (growpart). If you use growpart to grow a partition, the result
should be that that is done, and it is ready. The caller should not
expect that they have to know additional information (to call 'udevadm
settle') or shou
> If someone manually installs Ubuntu Desktop / Server using an installer,
> one should not be installing or using cloud-init as clearly, it will never
> complete without a correct metadata source present. And when it fails to
> complete, it re-attempts to reprovision the machine on every boot.
I'
Ugh.
the merge proposal at
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/342214
put a build-depends on isc-dhcp-client
not a runtime depends.
i've opened bug 1766714 to address.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packag
@Christian,
Well, the intended goal is that ubuntu-server == cloud-image.
we did fairly significant work to get as close as we are.
Currently cloud-image [1] differs from ubuntu-server [2] only by
presense of cloud-init and openssh-server.
The goal was to ultimately drop those also, and cloud-ini
An upstream commit landed for this bug.
To view that commit see the following URL:
https://git.launchpad.net/curtin/commit/?id=bd40234f
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tar in Ubuntu.
https://bugs.launchpad.net
Joseph,
Thanks for providing the link to the mailing list post. That is very
helpful.
On Fri, Mar 23, 2018 at 4:15 PM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:
> SRU request submitted:
> https://lists.ubuntu.com/archives/kernel-team/2018-March/090976.html
>
> --
> You received
** Description changed:
- cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary dhcp
ip addresses.
- it currently does not identify a dependency on it.
+ cloud-init uses isc-dhcp-client (through 'dhclient') to obtain temporary
+ dhcp ip addresses. It currently does not identi
Related bug 1759307
--
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/1633643
Title:
unnecessary dependency upon isc-dhcp-client
Status in initramfs-tools package in
An upstream commit landed for this bug.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=5b9dc4bc
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bu
You don't think that at least warrants a Suggests ?
On Wed, Mar 28, 2018 at 2:49 AM, Steve Langasek <
steve.langa...@canonical.com> wrote:
> I don't think this belongs as a dependency of initramfs-tools. The
> initramfs-tools package won't fail to create an initramfs if dhclient is
> absent, it
"Packages that care about networking support in the initramfs should instead
take care themselves to depend on isc-dhcp-client."
Reworded:
Packages that care about should take care to depend on
themselves.
Generally that's not how things work, and results in maintenance
elsewhere. Now *thos
root@b3:~# systemctl --no-pager | grep failed
● sys-kernel-config.mount loaded failed failedKernel
Configuration File System
● systemd-hostnamed.serviceloaded failed failedHostname
Service
● syste
Public bug reported:
# ubuntu-bug systemd
*** Collecting problem information
The collected information can be sent to the developers to improve the
application. This might take a few minutes.
.ERROR: hook /usr/share/apport/package-hooks/systemd.py crashed:
Traceback (most recent call las
An upstream commit landed for this bug.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=c6dff581
** Changed in: cloud-init
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seede
This was a stock lxc launch.
$ lxc launch ubuntu-daily:bionic b4
$ lxc exec b4 /bin/bash
root@b4:~# cat /etc/cloud/build.info
build_name: server
serial: 20180411
root@b4:~# ubuntu-bug systemd
*** Collecting problem information
The collected information can be sent to the developers to improve
** Description changed:
ubuntu-server has a hard dependency on open-iscsi, which means there is
a daemon running (iscsid), and the package cannot be removed. All
unnecessary daemons are a cause of concern when auditing a system.
Propose moving this to "Recommends" instead, which current
Public bug reported:
ubuntu-bug is now producing links that do not work.
using 'ubuntu-bug' in xenial produces links that look like:
https://bugs.launchpad.net/ubuntu/+source/apport/+filebug/0f274d36-64f2-11e8-b34a-002481e7f48a?
but the cosmic version produces links like:
https://bugs.launchp
I think this was user-error... I think the serial console was just messing with
me.
I'll re-open if I see it again.
** Changed in: apport (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed t
** Description changed:
Ping is not longer setuid root and I have to ping as root:
[~]$ ping kubuntu.org
ping: icmp open socket: Operation not permitted
[~]$ sudo ping kubuntu.org
PING kubuntu.org (91.189.94.156) 56(84) bytes of data.
64 bytes from vostok.canonical.com (91.189.94.15
** Description changed:
With trusty, /bin/ping relies on having extended attributes and kernel
capabilities to gain the cap_net_raw+p capability. This allows removing
the suid bit.
However, the tarball cloud images do not preserve the extended
attributes, and thus /bin/ping does not w
Just a comment...
'apt' indicates that its cli is unstable and should not be relied upon by
scripts.
So fixing this general problem in 'apt' (and not apt-get) means you fix it
possibly for humans who are typing things, but all non-human package
installations needlessly have to 'apt-get update'.
This bug is believed to be fixed in cloud-init in version 18.3. 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 membe
Public bug reported:
Some recent events have made keyservers less reliable than they were
previously:
https://bitbucket.org/skskeyserver/sks-keyserver/issues/57
https://bitbucket.org/skskeyserver/sks-keyserver/issues/60
We have seen a greatly increased failure rate of retreiving keys
I saw this "in the wild" with /var/log/cloud-init.log showing:
2018-07-09 15:20:22,666 - util.py[DEBUG]: Running command
['add-apt-repository', 'cloud-archive:ocata'] with allowed return codes [0]
(shell=False, capture=True)
2018-07-09 15:20:24,907 - cc_apt_configure.py[ERROR]: add-apt-repositor
Another fail log at
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/open-iscsi/20171114_192057_17bf1@/log.gz
Basically if you look at bionic failures
http://autopkgtest.ubuntu.com/packages/o/open-iscsi/bionic/amd64
if i
This issue is discussed in a document at
https://docs.google.com/document/d/14xH2Q3VH_7ArXzRPhqogfACeOI0rmEinm_Q98imNWlc/
Its all about "transition" of networking information from the initramfs
environment which is configured by the kernel command line over to the
"real root".
The Ubuntu founda
It looks like:
x-systemd.device-timeout=
might be useful
https://www.freedesktop.org/software/systemd/man/systemd.mount.html
we'd have to update the /etc/fstab entry in 'patch-image' of the open-
iscsi test, but we could do that and just bump it to 6m or something.
As some evidence, that this mi
Is there a way to bump that 1m30s timeout from the kernel command line?
Even image modification would be ok, as we're already modifying the
image to insert the deb.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in U
Note that this failure could just be due to slowness at this point.
The open-iscsi tests that are running are running in nested qemu with kvm
disabled. So it is quite slow to boot.
We seem to be getting usually around 40 seconds for that to arrive. My
statement is based on
messages like:
[
Well, I tried updating /etc/fstab
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+ref/fix/get-journal-publish-artifacts
but that doesnt help. It still fails and goes on after 90 seconds. I
verified this by just changing the LABEL= to a different string that
would
Bummer.
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/o/open-iscsi/20171122_204418_8ac74@/log.gz
shows
[ 43.793658] systemd[1]: media-root\x2dro.mount: Found ordering cycle on
-.mount/start
[ 43.801914] systemd[1]: me
$ wget http://cloud-images.ubuntu.com/artful/20171122/artful-server-
cloudimg-amd64.img
## set up dns locally for 'qemu-host' to the default ip for user networking.
$ grep qemu-host /etc/hosts
10.0.2.2 qemu-host
$ cat data/user-data
#cloud-config
password: passw0rd
chpasswd: { expire: False }
ssh
Heres some more info that is from failed system using bionic.
$ sudo journalctl -o short-monotonic --no-pager | pastebinit
http://paste.ubuntu.com/26035621/
$ sudo base64
/run/log/journal/7ba07d79c32c4103aefee168e433d847/system@e9ae467d022046f0a034147c78254ae9-0001-00055ebdb4f0260b.jo
I think the primary issue is that cloud-init.service is depending on using the
network fully.
cloud-init.service runs:
After=networking.service
After=systemd-networkd-wait-online.service
Before=network-online.target
But systemd-resolved.service runs
After=systemd-networkd.service network.t
zesty does not show this problem. neither does xenial. I reflected that
in the status.
$ sudo journalctl -b -o short-monotonic | pastebinit
http://paste.ubuntu.com/26035779/
$ sudo journalctl -o short-precise | pastebinit
http://paste.ubuntu.com/26035774/
Nov 24 17:49:25.193028 ubuntu systemd[1]:
that ordering cycle is if we add 'After=systemd-resolved.service' to
cloud-init.service.
--
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/1734167
Title:
DNS doesn't work in
zesty does not show this problem. neither does xenial. I reflected that
in the status.
** Changed in: cloud-init (Ubuntu Artful)
Status: New => Confirmed
** Changed in: cloud-init (Ubuntu Artful)
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu Artful)
Importance: M
To be clear, the suggestion that xnox made causes a ordering cycle.
** Changed in: systemd (Ubuntu Bionic)
Assignee: (unassigned) => Canonical Foundations Team
(canonical-foundations)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
I've verified that this is reproducible within lxc, and then filed a bug i
saw (bug 1734939) as a result.
Heres a trivial reproduce:
## just showing content of the url.
$ curl --silent https://hastebin.com/raw/coladicuva
#!/bin/sh
cat /proc/uptime | tee /run/user-script-uptime
$ name=btest
$ lxc
** Description changed:
I use no-cloud to test the kernel in CI (I am maintainer of the bcache
subsystem), and have been running it successfully under 16.04 cloud
images from qemu, using a qemu command that includes:
-smbios "type=1,serial=ds=nocloud-
net;s=https://raw.githubuserconte
Public bug reported:
=== Begin SRU Template ===
[Impact]
Booting a kernel/initramfs with 'rooturl=http://...' for trusty
or xenial requires also adding 'rc-initrd-dns' or 'cloud-config-url='
to the kernel command line in order to get the fix provided by bug
1711760.
If a user boots with 'rooturl=
** Also affects: initramfs-tools (Ubuntu Zesty)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: initramfs-tools (
** Attachment added: "test script"
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1735225/+attachment/5016294/+files/test-lp1714308.sh
** Also affects: resolvconf (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: resolvconf (Ubuntu Xenial)
Importance:
** Description changed:
=== Begin SRU Template ===
[Impact]
Without this fix applied, dns settings provided to the dhcp response
in the initramfs are not reflected in the "real root".
Thus dns resolution does not work. Of most interest was the MAAS use
case of the 'root=http://<>/sq
Public bug reported:
I'm on softlayer in an official Ubuntu image and 'mount' exits
success even when it fails.
$ cat /etc/cloud/build.info
build_name: server
serial: 20171116
$ cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults,relatime 0 0
# Added by Cloud Image build pr
I didn't notice initially but just did. The entry in /etc/fstab is
bogus, containing a LABEL=METADATA but the disk here is LABEL=config-v2.
That is clearly broken, but 'mount' should not exit success.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages
blkid output was above. and as I said in my first comment the entry in
/etc/fstab is wrong.
there is no LABEL=METADATA device. So 'mount' *should* fail, but I would have
expected it to exit non-zero.
I noticed just now that '/etc/fstab' has 'nofail' for that line. I
removed that, and it fails
Robie, Brian,
I went ahead and did the reproduce in the test and selected '2' in the
multi-select. Heres the full console log. My responses can be seen there alsol.
$ for release in xenial artful; do
> ref=$release-proposed;
> echo "$release START --";
> lxc-
Full disclosure, As you can see, I ran with artful and xenial (just
copied and pasted text from above). I didn't run with zesty.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs
** Changed in: apport (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: apport (Ubuntu Zesty)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.l
This is marked fix-released in cloud-initramfs-tools, but in reality that is
not a useful fix anymore.
The fix was added to cloud-initramfs-dyn-netconf which is not used in xenial
and later.
The fix really should go into mkinitramfs-tools proper.
--
You received this bug notification because y
** Also affects: resolvconf (Ubuntu Zesty)
Importance: Undecided
Status: New
** Changed in: resolvconf (Ubuntu Zesty)
Status: New => Triaged
** Changed in: resolvconf (Ubuntu Zesty)
Importance: Undecided => Medium
--
You received this bug notification because you are a membe
Public bug reported:
zfs support exists in Ubuntu kernels for 16.04 and later, but the
default initramfs build does not include this module.
Other common filesystems are included.
As a small piece of information:
$ du -hs /lib/modules/4.13.0-17-generic/kernel/zfs/
3.2M/lib/modules/4.13.0-17-
As a work around you can specifically add the zfs module (if its in your
kernel) with:
$ cat /etc/initramfs-tools/hooks/zfs
#!/bin/sh
. /usr/share/initramfs-tools/hook-functions
manual_add_modules zfs
$ update-initramfs -u -k all
--
You received this bug notification because you are a member o
Adding this to maas-images would look like this:
http://paste.ubuntu.com/26165463/
but we'd avoid that as if zfs is officially supported, then it might as
well be in the default initramfs.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is s
** Summary changed:
- mount can exit (success) when it fails
+ mount can exit 0 (success) when it fails
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to util-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1736556
Title:
m
** Also affects: maas-images
Importance: Undecided
Status: New
--
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/1737592
Title:
no zfs module in initramfs
** Changed in: maas-images
Status: New => Confirmed
** Changed in: maas-images
Importance: Undecided => Medium
** Changed in: initramfs-tools (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
This bug is believed to be fixed in cloud-init in 1705804. 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
I've verified zesty with the script that is attached.
Output is shown here.
** Attachment added: "verification log of zesty"
https://bugs.launchpad.net/maas/+bug/1711760/+attachment/5023065/+files/zesty.log
** Tags removed: verification-needed verification-needed-zesty
** Tags added: verific
This bug is believed to be fixed in curtin 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: curtin
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touc
Dimitri,
What is the fix that you put in? I assume it was to systemd ?
--
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/1734167
Title:
DNS doesn't work in no-cloud as laun
** Tags removed: verification-donezesty
** Tags added: verification-done-zesty
** Tags removed: verification-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1711760
** Changed in: maas-images
Status: Confirmed => Fix Committed
--
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/1737592
Title:
no zfs module in initramfs
Stat
Well, I went looking to verify this. We got builds out of artful and
xenial today (20180109).
$ usquery maas3-daily --max=1 ftype=boot-initrd arch=amd64 subarch~ga- \
kpackage~generic \
--output-format='%(release)s %(version_name)s %(path)s %(item_url)s' |
while read rel ver path url; do \
** Description changed:
1. $ lsb_release -rd
Description: Ubuntu 17.10
Release: 17.10
2. $ apt-cache policy linux-image-`uname -r`
linux-image-4.13.0-16-generic:
- Installed: 4.13.0-16.19
- Candidate: 4.13.0-16.19
- Version table:
- *** 4.13.0-16.19 500
- 500 http
Public bug reported:
adduser and deluser are now printing to stderr 'sent invalidate(passwd)' and
'sent invalidate(group)'.
These are confusing at best and new in bionic.
See below. They do not seem harmful, but not wonderful.
smoser@ubuntu1:~$ sudo adduser guest
Adding user `guest' ...
sent in
Based on Brian's comment, marking wont-fix.
Not the end of the world, just less than ideal.
** Changed in: apport (Ubuntu Xenial)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport
Public bug reported:
I (smoser) removed cloud-initramfs-dyn-netconf from ubuntu-server meta
package. That package provides functionality needed by MAAS and cause bug
1748875. Under that bug we re-added cloud-initramfs-dyn-netconf to the
initramfs that MAAS publishes.
We subsequently saw failure
Hi,
cloud-init has never updated resolv.conf directly.
/etc/resolv.conf in 16.04 is managed via resolvconf through
/etc/network/interfaces.
/etc/resolv.conf in 18.04 is managed via systemd-resolve (netplan ->
systemd-networkd -> systemd-resolve).
Can you provide the content of:
systemd-resol
MAAS is sending a "global" nameserver, and a ethernet device on a bridge.
cloud-init is rendering that nameserver onto the ethernet device rather
than on the bridge or as a "global" entry.
$ cat my.yaml
network:
config: [
{"id": "enp0s25", "type": "physical", "name": "enp0s25",
"mac_addr
Marked as 'fix-committed' as I pushed to the seed branch.
I need to wait for some server side things to happen before I can upload
ubuntu-meta,
but any ubuntu-meta > 1.411 should have this fix.
** Changed in: ubuntu-meta (Ubuntu)
Status: New => Fix Committed
** Changed in: ubuntu-meta
It seems to me that each of maas, cloud-init and netplan could do better
here.
a.) maas declares 'global' nameserver/dns info.
this is kind of silly in that such a thing doesn't really exist.
maas has the information necessary to declare the nameserver on the
device with the address that has a rou
Getting this fixed in cloud-init is tricky.
In ifupdown (/etc/network/interfaces) world, we just took the "global dns"
entries and put them on the loopback device (lo). Since that device would
always be brought up, and never really brought down, it served its purpose.
That is what Ryan tried ab
cloud-images 20180222 do *not* have cloud-initramfs-dyn-netconf or ubuntu-meta
at 1.411.
That is expected as it just wasnt fixed at the time of the build.
Anything newer than 20180222 should have this fixed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded p
** Tags removed: xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to adduser in Ubuntu.
https://bugs.launchpad.net/bugs/1750031
Title:
scary/unexpected output in adduser and deluser
Status in adduser package in Ubuntu:
This bug was reproduced on a xenial Azure cloud image
$ cat /etc/cloud/build.info
build_name: server
serial: 20180222
I cannot reproduce it locally in a container.
** Tags added: xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is su
I've also tried a bionic azure image
$ cat /etc/cloud/build.info
build_name: server
serial: 20180222
It did not reproduce there.
So as far as I can tell it shows itself only on Azure 16.04 images.
** Also affects: cloud-images
Importance: Undecided
Status: New
** Changed in: cloud-i
I had hoped that simply disconnect/reconnect of the interface would
work, but that did not improve things. (nmcli device disconnect enp0s25
; nmcli device connect enp0s25)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to system
Public bug reported:
After reboot, dns was broken.
I've attached systemd-resolve --status output.
In order to file the bug I just modified /etc/resolv.conf to put the dns
server in directly.
Other information, it seems like it just will only look for dns under my
search domains from the dhcp ser
** Summary changed:
- transient boot fail with overlayroot
+ transient boot fail with overlayroot [open-iscsi dep8 tests]
** Attachment added: "bionic failure log 2.0.874-5ubuntu2
qemu/1:2.11+dfsg-1ubuntu2"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1732028/+attachment/5063
** Description changed:
After reboot, dns was broken.
+ This is a very simple Network Manager managed interface that has dhcp.
+
+ $ nmcli device show enp0s25 | pastebinit
+ http://paste.ubuntu.com/p/sMVTdrMBxJ/
+
+
I've attached systemd-resolve --status output.
In order to file the b
I agree with reverting change in bionic, and that xenial still needs
some fix.
I recreated your failure in xenial and agree with your change there.
I used this job as it actually tries to write to the private tmp.
If I change 'ExecStart' below to be just '/bin/true' like in your job,
it does not
1 - 100 of 562 matches
Mail list logo
