Subscribing ubuntu-release as per FFE policy. This bug affects noble
cloud image release
** Also affects: software-properties (Ubuntu Noble)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
Public bug reported:
[ Impact ]
* It is not possible to upgrade or re-install python-apt using pip from
the git+ssh://git.launchpad.net/ubuntu/+source/python-apt git repo if
already installed and if wheel installed too.
* On initial install it also is assigned version `0.0.0` which is
Thanks all. Marking as "Won't Fix" and marked MP as Rejected.
** Changed in: ubuntu-meta (Ubuntu Noble)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
With only snapd snap preseeded I get boot times very similar to
```
ubuntu@cloudimg:~$ systemd-analyze
Startup finished in 3.757s (kernel) + 12.458s (userspace) = 16.216s
graphical.target reached after 12.061s in userspace.
```
Which shows we are still taking a boot time hit of ~1.5 seconds...
> * boot times w/ and w/o preseeded snaps
Without preseeded snaps:
```
ubuntu@cloudimg:~$ systemd-analyze
Startup finished in 3.609s (kernel) + 11.026s (userspace) = 14.636s
graphical.target reached after 10.642s in userspace.
```
With preseeded snapd and core22 snaps:
```
ubuntu@cloudimg:~$
@vorlon
> Also, statically seeding a particular base snap is bad form, as soon
as lxd upgrades its base you lose your performance benefit and have to
play catch-up in a stable release.
yes I don't like this either. Even if we do change it later to core24
then the expectations people have for
Thank you for the detail sdeziel
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/2051572
Title:
Always preseed core and snapd snap in server seed
Status in
> "other cloud cases that have preseeded snaps" (thinking like ec2 or
oracle that have snapped cloud agent
This isn't something we need to worry about as there will be no change
in this case. If any agent snaps are preseeded then so too will a core
snap and snapd snap.
--
You received this bug
> 15 seconds vs 30 seconds, on a thing that won't affect most cloud
customers
I'll see if I can find the data to back this
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
If we don't preseed a core snap and snapd it feels like we're failing to
prioritise the performance of snaps on server/cloud.
But if we acknowledge that knowing that we are prioritising boot speed
then that's fine and we can add it to the noble release notes.
--
You received this bug
Good points
I'll measure boot speed with and without core snap preseeded and add it
here.
time to initialize any snap was my goal but with lxd as an example as it
is such a popular snap.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
in the server seed @
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
seeds/+git/ubuntu/tree/server#n69
[1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2051346
** Affects: ubuntu-meta (Ubuntu)
Importance: Undecided
Assignee: Philip Roche (philroche)
Status: New
This has been released in Noble version 1.529
** Changed in: ubuntu-meta (Ubuntu)
Status: New => Fix Released
** Also affects: ubuntu-meta (Ubuntu Noble)
Importance: Undecided
Status: Fix Released
** Changed in: ubuntu-meta (Ubuntu Noble)
Assignee: (unassigned) =>
Public bug reported:
With LXD 5.20 there is a license change to AGPL and it has been decided
to no longer seed the snap in Ubuntu 24.04 and later and instead seed
the lxd-installer package instead.
This bug is to track the work of making that change in the server seed @
> a) You state that some policy says that no ports other than 22 should
be open, which policy is that? Does it apply only to cloud images, or is
it an Ubuntu policy in general
This policy is detailed @
https://wiki.ubuntu.com/Security/Features#ports
> Default installations of Ubuntu must have no
> a) You state that some policy says that no ports other than 22 should
be open, which policy is that? Does it apply only to cloud images, or is
it an Ubuntu policy in general?
I will try find the referenced policy.
> b) This is in mantic release at the moment, and switching that option
back to
cloud minimized and non minimized images have now been tested with
6.5.0-9 kernel from -proposed and pass our lxd-start-stop test suite
which was failing and which is the test suite which prompted this whole
thread. +1
--
You received this bug notification because you are a member of Ubuntu
I have also successfully verified that -proposed amd64 kernel
`6.5.0-7-generic` results in successful network configuration when
tested using qemu on an amd64 host with older hardware (ThinkPad T460
with 6th gen intel i5 which is the same hardware which we were able to
reproduce the issue on
@xnox I have successfully verified that -proposed arm64 kernel
`6.5.0-7-generic` results in successful network configuration when
tested using qemu on an amd64 host. See
https://people.canonical.com/~philroche/20231003-mantic-minimal-
proposed-kernel/ for cloud-init logs, some debug output and
I have verified that ntp 1:4.2.8p4+dfsg-3ubuntu5.4 in xenial-proposed
passes the test case outlined in the description above.
* Launch GCE instance
* Enabled proposed
* Upgrade ntp
* Reboot
* Confirm `ntpq -p` returns only one entry
** Tags removed: verification-needed
** Tags added:
** Description changed:
In 1:4.2.8p3+dfsg-1, the default config was changed to
"Use pool instead of server". This needs a corresponding
update to /etc/dhcp/dhclient-exit-hooks.d/ntp, since the
DHCP specified servers now get added to the default pool
config instead of replacing them.
Hi mterry.
RE: test case steps.
This surfaced for me initially while testing on GCE. On GCE NTP servers
are provided via DHCP so the easiest test case is to launch an instance
on GCE without our workaround configured.
One such image is "daily-ubuntu-ntpdebug-1604-xenial-v20170331" in
project
Please find attached patch for this bug. This is the same fix as
upstream (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806676
and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809344)
The patch adds "pool" to the "server" and "peer" list as well as
handling tabs and spaces in the
The issue if a broken set of NTP servers is received and having no
fallback is the case in Yakkety now too though and previously in Xenial
prior to the server/pool changeover in 1:4.2.8p3+dfsg-1.
I agree that ideally there would be a fallback if the received NTP
servers were broken but this bug
Public bug reported:
In 1:4.2.8p3+dfsg-1, the default config was changed to
"Use pool instead of server". This needs a corresponding
update to /etc/dhcp/dhclient-exit-hooks.d/ntp, since the
DHCP specified servers now get added to the default pool
config instead of replacing them.
This affects
This seems to be somewhat related to https://bugs.launchpad.net/cpc-
gce/+bug/1639089 (only affects Xenial).
In summary the "pool" entries in ntp.conf should be commented out by
gce-cloud-config but when ntp.conf transitioned from using "server" to
"pool" gce-cloud-config was not updated.
I will
26 matches
Mail list logo
