Public bug reported:
1) # lsb_release -rd
No LSB modules are available.
Description:Ubuntu 24.04 LTS
Release:24.04
2) # apt-cache policy lxc-dev
lxc-dev:
Installed: 1:5.0.3-2ubuntu7
Candidate: 1:5.0.3-2ubuntu7
Version table:
*** 1:5.0.3-2ubuntu7 500
500 http://archive.u
I'm not sure exactly how the liblxc.a static lib was dropped, but the
attached debdiff resolves this by not removing all .a files (an extra
find|rm is around a comment about removing all .la files) and then
adding the file to lxc-dev.install
This produces a lxc-dev deb which includes the static l
dpkg --contents on lxc-dev_5.0.3-2ubuntu7_amd64.deb
** Attachment added: "output from dpkg --contents on
lxc-dev_5.0.3-2ubuntu7_amd64.deb"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814926/+files/lxc-dev_5.0.3-2ubuntu7_amd64.deb.contents
--
You received this bug
** Patch added: "Diff of dpkg --contents file column only between 7 and 8"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814925/+files/file-list.diff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed t
dpkg --contents lxc-dev_5.0.3-2ubuntu8_amd64.deb output
** Attachment added: "dpkg --contents lxc-dev_5.0.3-2ubuntu8_amd64.deb output"
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/2080069/+attachment/5814927/+files/lxc-dev_5.0.3-2ubuntu8_amd64.deb.contents
--
You received this bug noti
I generated the smaller diff with:
$ diff -u <(awk '{print $6}' lxc-dev_5.0.3-2ubuntu7_amd64.deb.contents )
<(awk '{print $6}' lxc-dev_5.0.3-2ubuntu8_amd64.deb.contents) > file-
list.diff
so one can just see which files were added/removed vs the date/timestamp
change on files that are in both ar
Public bug reported:
1) # lsb_release -rd
Description:Ubuntu 20.04.5 LTS
Release:20.04
2) # apt-cache policy systemd
systemd:
Installed: 245.4-4ubuntu3.19
Candidate: 245.4-4ubuntu3.19
Version table:
*** 245.4-4ubuntu3.19 500
500 http://azure.archive.ubuntu.com/ubuntu
Public bug reported:
1) # lsb_release -rd
Description:Ubuntu 20.04.5 LTS
Release:20.04
2) # apt-cache policy systemd
systemd:
Installed: 245.4-4ubuntu3.19
Candidate: 245.4-4ubuntu3.19
Version table:
*** 245.4-4ubuntu3.19 500
500 http://archive.ubuntu.com/ubuntu focal-
To reproduce what happens on physical systems I create two VMs with nics
in the same bridge on the host. Booting the first VM up and allowing
the network config to apply, and then when booting the second VM up
layer, as it applies the IPv6 address to the interface in the bridge,
the kernel detects
# Create a bridge and add two ports
$ sudo ip link add name atx-fabric0 type bridge
$ sudo ip link set up dev atx-fabric0
$ sudo ip tuntap add atx-fabric0i1p1 user $USER group $USER
$ sudo ip tuntap add atx-fabric0i2p1 user $USER group $USER
# create two focal VM images from focal daily server
$
** Attachment added: "netplan config for vm1"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+attachment/5637220/+files/50-v4-v6-fail-vm1.yaml
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubun
** Attachment added: "netplan config for vm2"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2000325/+attachment/5637221/+files/50-v4-v6-fail-vm2.yaml
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubun
There are two scenarios: Applying to VM the first time, on subsequent
boots.
On first boot without the updated netplan config, when you first add it
root@ubuntu:/home/ubuntu# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:
root@ubuntu:/home/ubuntu# networkctl status eth2-2 --no-pager
● 2: eth2-2
Link File: /run/systemd/network/10-netplan-eth2-2.link
Network File: /run/systemd/network/10-netplan-eth2-2.network
Type:
** Also affects: systemd (Ubuntu Focal)
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/2000325
Title:
ipv6 duplicate address pr
** Also affects: systemd (Ubuntu Focal)
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/2000170
Title:
bond interface down: devi
It seems there are some limitations to what systemd will do with
IPv6BytesMTU.
1) if LinkLocalAddressing is not disabled, it will clobber any
IPv6BytesMTU value set.
[Network]
LinkLocalAddressing=ipv6
Address=10.10.10.10/24
IPv6MTUBytes=1470
This results in: /proc/sys/net/ipv6/conf//mtu having a
On Mon, Nov 26, 2018 at 11:11 PM Jay Vosburgh
<1671...@bugs.launchpad.net> wrote:
>
> Regarding #2 from comment #19:
>
> As the defined range for the ipv6.mtu is from IPV6_MIN_MTU to the
> device's MTU, and the existing API returns an error if the ipv6.mtu is
> out of range, I think it's reasonable
On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov
wrote:
> Using systemd 237-3ubuntu10.10
>
> Using:
> [Match]
> Name=ens3
> [Network]
> DHCP=ipv4
> IPv6MTUBytes=1600
> [Link]
> MTUBytes=1800
> [DHCP]
> UseMTU=no
> RouteMetric=100
>
Do you put this in the same .network file or .link file?
--
On Tue, Dec 4, 2018 at 9:31 AM Ryan Harper
wrote:
>
>
> On Tue, Dec 4, 2018 at 6:31 AM Dimitri John Ledkov
> wrote:
>
>> Using systemd 237-3ubuntu10.10
>>
>> Using:
>> [Match]
>> Name=ens3
>> [Network]
>> DHCP=ipv4
>> IPv6
Looks like this issue, I think:
https://github.com/systemd/systemd/issues/12490
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubunt
** Changed in: netplan
Status: Incomplete => Invalid
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which
@Dan/Chad I suggest we skip-by this bug number on the eoan vlan test
case;
--
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/1846232
Title:
vmtests: test_ip_output failing i
This can be reproduced in an LXD Eoan container:
lxc launch ubuntu-daily:eoan e1
lxc exec e1
cat > /etc/netplan/50-cloud-init.yaml << EOF
network:
version: 2
ethernets:
eth0:
dhcp4: false
mtu: 1500
vlans:
eth0.2667:
id: 2667
This looks to be related to networkd:
https://github.com/systemd/systemd/pull/12574/commits
Which is automatically added 4 bytes to base interface MTU, even though
we're explicitly setting mtu to 1500 on base interface and vlan.
** Also affects: systemd (Ubuntu)
Importance: Undecided
I cannot verify this is working on bionic with ipv6 static addresses.
root@ubuntu:~# lsb_release -rd
Description:Ubuntu 18.04.3 LTS
Release:18.04
root@ubuntu:~# cat /etc/cloud/build.info
build_name: server
serial: 20191021
root@ubuntu:~# uname -a
Linux ubuntu 4.15.0-66-generic #75-Ubu
The original netplan yaml I was testing was simpler, but also failed so
I tried to see if additional settings would make a difference, but it
did not.
network:
version: 2
ethernets:
interface0:
dhcp4: true
match:
macaddress: '52:54:00:12:34:0
In the Eoan version of systemd, I can see in the logs these messages:
Oct 24 18:52:32.753746 ubuntu systemd-networkd[1167]: Setting
'/proc/sys/net/ipv6/conf/interface1/proxy_ndp' to '0'
Oct 24 18:52:32.753848 ubuntu systemd-networkd[1167]: Setting
'/proc/sys/net/ipv6/conf/interface1/use_tempaddr
I did some more testing today. I upgraded systemd and netplan.io to
disco level, rebooted and tested the MTU settings; disco packages fail
as well. I then upgraded to eoan systemd/netplan.io rebooted and the
MTU settings are correct.
--
You received this bug notification because you are a memb
On Fri, Oct 25, 2019 at 1:31 PM Dan Streetman
wrote:
> I looked at this for a few minutes, and it seems strange that it works
> at all (at boot) since networkd sets the ipv6 mtu before bringing the
> link up, but the kernel resets the ipv6 mtu to the device mtu on link
> up. I must be missing so
@Balint, after further testing, here's where things are:
-
On LXD Containers
-
On Bionic
1) First boot: neither interface mtu, nor ipv6 mtu is applied.
2) Restarting systemd-networkd: neither interface nor ipv6-mtu is applied
3) netplan apply: interface mtu
@Dan,
Ill try the ppa and report back.
cloud-init is not doing anything special here, we render the config and call
netplan generate.
If we take cloud-init out of the picture, and just have a file in /etc/netplan
it will still fail due to the udev issue you specify. Shouldn't netplan itself
ha
Testing with @ddstreet's systemd ppa, I can confirm that bionic, disco
and eoan correctly set MTU on first boot, no systemd-restart needed.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launch
On trusty; this complains but works.
ubuntu@ubuntu:~$ dpkg --list | grep util-linux
ii util-linux 2.20.1-5.1ubuntu20.9
amd64Miscellaneous system utilities
ubuntu@ubuntu:~$ cat /proc/partitions
major minor #blocks name
2530
A couple of comments on the suggested path:
> Imho the sequency of commands should be:
> * take flock on the device, to neutralise udev
+1 on this approach. Do you know if the flock will block
systemd's inotify write watch on the block device which triggers
udevd? This is the typical race we se
> it will prevent udevd from running the rules against it. Thus
effectively the event will be fired and done, but nothing actually
executed for it.
Interesting, I suspect this is the race we see. The events emitted but
no actions taken (ie we didn't get our by-partuuid symlink created.
> I someh
@ddstreet
Yes, settle does not help.
Re-triggering udevadm trigger --action=add /sys/class/block/sda
Would re-run all of them after the partition change has occurred, which
is what I'm currently suggesting as a heavy-handed workaround.
I would like to understand *why* the udevd/kernel pair exhi
On Thu, Nov 7, 2019 at 1:30 PM Dan Streetman
wrote:
> > Yes, settle does not help.
>
> Well, I didn't suggest just to settle ;-)
>
Sorry; long bug thread.
> > I'm currently suggesting as a heavy-handed workaround.
>
> I don't really see why you think this is heavy-handed, but I must be
> missi
On Thu, Nov 7, 2019 at 11:30 AM Dimitri John Ledkov
wrote:
> > 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
On Thu, Nov 7, 2019 at 2:41 PM Dan Streetman
wrote:
> > Issuing a second
> > trigger will repeat this.
> > IMO, that's a non-zero amount of time that slows the boot down, so I'd
> like
> > to avoid that.
>
> systemd-udev-trigger.serivce retriggers *everything* at boot (except in
>
an unprivileged
Hi, I don't believe this is a cloud-init bug. Cloud-init wrote the two
certificate files requested.
2018-05-02 08:55:00,913 - stages.py[DEBUG]: Running module ca-certs () with
frequency once-per-instance
2018-05-02 08:55:00,914 - handlers.py[DEBUG]: start:
init-network/config-ca-certs: running
I'm marking the cloud-init task invalid; I don't believe cloud-init did
anything wrong; but please set the task back to New if you have new
information showing that cloud-init didn't do something quite right.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notifi
Public bug reported:
Installing into a chroot without /run mounted, grub's os-prober calls
into lvs for details and it waits a very long time. I believe this is
fixed upstream:
https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=3ebce8dbd2d9afc031e0737f8feed796ec7a8df9
1. Eoan
2. lvm2 2.03.
The sequence is:
exec growpart
exec sgdisk --info # read-only
exec sgdisk --pretend # read-only
exec sgdisk --backup # read-only copy
# modification of disk starts
exec sgdisk --move-second-header \
--delete=PART \
--new=PART \
--typecode --pa
On Fri, Aug 23, 2019 at 10:00 AM Dan Streetman
wrote:
> > Dan had put a udevadm settle in this spot like so
> >
> > def get_size(filename)
> >util.subp(['udevadm', 'settle'])
> >os.open()
>
> if you know you've just changed (e.g.) /dev/sda, possibly its kernel-
> generated udev events
On Fri, Aug 23, 2019 at 10:21 AM Dan Watkins
wrote:
> Looking at the comment timestamps, Dan probably didn't see my comment,
> but to reiterate: all the events we expect to be processed _are_
> processed, the issue is that when they are processed they don't always
> end up with the correct partit
On Mon, Aug 26, 2019 at 4:05 AM Tobias Koch <1834...@bugs.launchpad.net>
wrote:
> > (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
I launched a bionic image on serverstack, updated the netplan.io to
proposed, modified the network config to set ipv6-mtu to 6000 and
rebooted.
root@b-test-ipv6-mtu:~# apt-cache policy netplan.io
netplan.io:
Installed: 0.98-0ubuntu1~18.04.1
Candidate: 0.98-0ubuntu1~18.04.1
Version table:
*
I tested with your single-file approach and that also fails. Note that
bionic now has systemd 237, so maybe something is missing (or regressed)
?
$ apt-cache policy systemd
systemd:
Installed: 237-3ubuntu10.26
Candidate: 237-3ubuntu10.26
Version table:
*** 237-3ubuntu10.26 500
500
err, on Eoan, I used ipv6-mtu 6000.
--
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/1671951
Title:
networkd should allow configuring IPV6 MTU
Status in cloud-init package
See comment #20; ipv6 mtu is 1280 -> DEVICE_MTU.
I'm testing something in the middle now.
On Eoan with:
network:
version: 2
ethernets:
ens3:
addresses: [10.5.0.16/16]
gateway4: 10.5.0.1
dhcp4: false
match:
macaddres
This is still around. Scott wrote up a script to handle cleaning this
up.
https://gist.github.com/smoser/2c78cf54a1e22b6f05270bd3fead8a5c
--
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.
https://github.com/lxc/lxd/issues/4656
** Bug watch added: LXD bug tracker #4656
https://github.com/lxc/lxd/issues/4656
--
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/1779156
** Summary changed:
- vmtests: test_ip_output failing in vlan tests on eoan
+ networkd pads interface MTU by 4 bytes for vlan even when told not to
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bu
Public bug reported:
1.
root@ubuntu:/home/ubuntu# cat /etc/cloud/build.info
build_name: server
serial: 20200106
root@ubuntu:/home/ubuntu# lsb_release -rd
Description:Ubuntu Focal Fossa (development branch)
Release:20.04
2.
root@ubuntu:/home/ubuntu# apt-cache policy systemd
systemd:
** Tags added: rls-ff-incoming
--
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/1859858
Title:
udev has truncated ID_SERIAL value for scsi disk
Status in systemd package i
I disagree that SLAAC is something that we should by default block reaching
network-online.target.
In general we cannot know in advance whether or not another system in the same
subnet is providing Router Advertisements to other instances.
If one instance in my VPC is running radvd, ec2 has n
I don't think not blocking for RAs during boot as a decision that
prefers ipv4 over ipv6. networkd is just doing something else by
default that the kernel doesn't do today, or historically; *and* there
is no toggle for the blocking; only do you want RAs or not *and* if you
say you don't want RAs i
I've given this a test in LXD on my system which triggers the RA stall;
after upgrading it does not wait for an RA before marking the interface
configured and also confirmed that it does not regress the case where
there are existing RA's on the network; those are still received. Note
that we see e
Are you providing network config to cloud-init? Otherwise, cloud-init
is going to generate a fallback network config like your original, dhcp
on one of the interfaces.
If you want to persist network changes, you need to add them to a
separate netplan yaml config, or provide an updated network-con
On Wed, May 9, 2018 at 9:13 AM, Daniel Axtens
wrote:
> Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and
> I've never seen it regenerated.
Ah, right, it doesn't regenerate unless you change instance-ids.
>
> I also don't see anything in /run/netplan or /run/systemd/netw
Investigating, it appears that the interfaces are getting renamed by
udev in the initramfs, which pushes their name_assign_type value to 4,
and udev refuses to rename an interface if the name_assign_type value is
4.
So, I can make this scenario work if I do:
4. sudo update-initramfs -u
5. reboot
On Fri, May 11, 2018 at 3:25 AM, Daniel Axtens
wrote:
> Ryan, I can't get that to work on my systems. What is it that update-
> initramfs is supposed to change? I don't see any files in my initramfs
> that are generated or read by netplan. Neither do I see netplan itself
> in the initramfs!
The .
I'm just verifying that on my end; note that the 99-default.link is
going to be sufficient to trigger a rename from eth0 to ens3; which
then prevents any rename once we mount root.
Here's the trigger:
% /usr/share/initramfs-tools/hooks/udev
# copy .link files containing interface naming definiti
-link.rules
bin/readlink
On Fri, May 11, 2018 at 9:35 AM, Ryan Harper wrote:
> I'm just verifying that on my end; note that the 99-default.link is
> going to be sufficient to trigger a rename from eth0 to ens3; which
> then prevents any rename once we mount root.
>
> Here's the
On Fri, May 11, 2018 at 10:18 AM, Daniel Axtens
wrote:
> Right. Yes, I can replicate that, thanks heaps!
Great!
>
> So to summarise, you can make the rename take effect on boot if you:
> 1) copy the files from /run/systemd/network -> /etc/systemd/network
> 2) then update-initramfs -u
>
> This
Can you provide the journalctl -b output for the boot that does this
rename? Is the reproduce the same, can you provide your steps and
I'll replicate.
Xenial does not enable netplan by default so we have a different path
there at least.
On Mon, May 14, 2018 at 9:58 PM, Daniel Axtens
wrote:
> T
Note, that uvt-kvm is going to use cloud-init; how are you making
sure that cloud-init isn't doing the rename itself?
Xenial by default doesn't use netplan; it still uses eni; the network
configuration generation in cloud-init using eni
does create a 70-persistent-net.rules file that handles rena
We really only want to be allowed to rename interfaces that have requested it.
This means other interfaces which do not have a set-name directive
will have the kernel name.
On Thu, May 24, 2018 at 6:56 AM, Mike Jonkmans
<1770...@bugs.launchpad.net> wrote:
> Things seem to work when i change the Na
That's not the final conclusion; the issue is still being discussed
upstream; in particular as to why only the interface name cannot be
modified at runtime by .link files.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to system
On Fri, May 25, 2018 at 8:48 AM, Mathieu Trudel-Lapierre
wrote:
> My recommended course of action for cosmic:
>
> - drop udevadm (net_setup_link) call from cloud-init
This will still be needed in the case that we have a network config with names.
Cloud-init runs after udev coldplug, so any .link
On Fri, May 25, 2018 at 9:09 AM, Mathieu Trudel-Lapierre
wrote:
> I'm not completely sure where the code lives in cloud-init; it looks a
> bit like what's in:
>
> cloudinit/net/netplan.py
>
> But the code does read as though it should not be running 'udevadm test-
> builtin net_setup_link'. Howeve
"This is why I added
cloud-init to affected packages -- cloud-init should not be second-
guessing the network layer and attempting to do renames / to run"
There is no second guessing. In the case where we have no network
config, there is no renaming; we accept whatever name is given.
If the conf
It would be nice for both nplan and networkd to accept a tri-state:
accept-ra: [off|on|kernel]
I think that would make it clear rather than an unset value to indicate
that it's controlled by the kernel.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packag
After some discussion, it appears that networkd is kinda of making a
boolean (on|off) for IPV6 RA, when it's really a tri-state
(on|off|kernel).
Upstream networkd indicates there is a tri-state; like so:
Enable or disable IPv6 Router Advertisement (RA) reception support for
the interface. Takes a
** Also affects: tar (Ubuntu)
Importance: Undecided
Status: New
--
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/bugs/1757565
Title:
btrfs and tar sparse truncate archives
v4.14-rc1: BAD
ubuntu@ubuntu:~$ uname -r
4.14.0-041400rc1-generic
ubuntu@ubuntu:~$ sudo bash
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /proc/mounts
/dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/
v4.15.7: GOOD
root@ubuntu:~# uname -r
4.15.7-041507-generic
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /proc/mounts
/dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir
-p /mnt/tmp; cp -
On Thu, Mar 22, 2018 at 2:56 PM, Joseph Salisbury
wrote:
> @Scott, will that upstream commit make it so the kernel fix we are
> looking for is not required?
This is a curtin workaround; we're not using the sparse flag when invoking tar;
However, the bug/issue remains between tar and btrfs.
Outsi
v4.15 Final: GOOD
root@ubuntu:~# uname -r
4.15.0-041500-generic
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /proc/mounts
/dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir
-p /mnt/tmp;
v4.15-rc6: GOOD
root@ubuntu:~# uname -r
4.15.0-041500rc6-generic
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /proc/mounts
/dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5sum /usr/bin/python3.6; mkdir
-p /mnt/tmp;
This looks promising and landed in -rc2:
Btrfs: fix reported number of inode blocks after buffered append writes
https://www.spinics.net/lists/linux-btrfs/msg71274.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tar in U
Yeah, rc2 was fine.
--
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/bugs/1757565
Title:
btrfs and tar sparse truncate archives
Status in linux package in Ubuntu:
Triaged
Status i
Test kernel: GOOD
root@ubuntu:~# cat /proc/version_signature
Ubuntu 4.13.0-37.42~lp1757565-generic 4.13.13
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /proc/mounts
/dev/sda /mnt btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0
root@ubuntu:~# SPARSE="-S"; rm -rf /mnt/tmp; md5s
As per cloud-init networking disabled. Please reopen task if you find
cloud-init is in the picture here.
** Changed in: cloud-init (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdo
The kernel value is equivalent to not writing it out, yes; I thought
it'd be better to be explicit in the config.
W.r.t disabling by default; no plans to do so at this point but as it is
now, all Artful and Bionic images will block for 10 seconds, unless an
RA comes in sooner. So ideally we stop
Guys, I'm no longer suggesting that we disable RA here. After our
discussion I updated this bug
to indicate that we really want some way to *leave* RA alone.
At this point that means netplan needs to *NOT* emit AcceptRA values
into the .network configuration
files by default (as it does now), but
Verified artful-proposed.
root@ubuntu:~# cat /etc/cloud/build.info
build_name: server
serial: 20180404
root@ubuntu:~# uname -a
Linux ubuntu 4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018
x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# mount /dev/sda /mnt
root@ubuntu:~# grep sda /pr
I'm seeing this on Artful as well, in Azure cloud.
** Also affects: glibc (Ubuntu Artful)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Artful)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Artful)
Importance: Undecided
Status
ubuntu@foufoune:~$ lsb_release -rd
Description:Ubuntu 17.10
Release:17.10
ubuntu@foufoune:~$ apt-cache policy systemd
systemd:
Installed: 234-2ubuntu12.3
Candidate: 234-2ubuntu12.3
Version table:
*** 234-2ubuntu12.3 500
500 http://azure.archive.ubuntu.com/ubuntu artful-up
The MP has been moved to a github PR:
https://github.com/CanonicalLtd/netplan/pull/19
--
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/1732002
Title:
cloud images in lxc ge
Public bug reported:
1.
$ lsb_release -rd
Description:Ubuntu Bionic Beaver (development branch)
Release:18.04
2.
$ apt-cache policy systemd
systemd:
Installed: 237-3ubuntu8
Candidate: 237-3ubuntu8
Version table:
*** 237-3ubuntu8 500
500 http://archive.ubuntu.com/ubuntu
In your netplan example config, keyword 'optional' means that systemd-
networkd won't wait until this interface is up before declaring to
systemd that the network is online. THis means dnsmasq is starting
before the vlan0 interface is created.
If you remove the optional value that should ensure i
https://netplan.io/faq#example-for-an-ifupdown-legacy-hook-for-post-
uppost-down-states
You can use a networkd-dispatcherd to hook on vlan0 becoming routeable
and then start/restart the dnsmasq service;
On Fri, Jun 15, 2018 at 12:36 PM, Hadmut Danisch wrote:
> So it is not possible to have an i
I see, interesting. The dnsmasq.service does not wait for
network-online.target;
This appears to be a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1531184
In addition to the netplan config to ensure it waits for your bridge
to come up, you need to delay dnsmasq.service u
On Tue, Jun 19, 2018 at 9:41 AM Hadmut Danisch wrote:
>
> dnsmasq _after_ networking?
>
> Isn't it part of networking and should be running and ready for other
> services depending on networking?
Yes, but it's complicated; see below.
>
>
> (my guess is that Ubuntu has never defined the targets v
I've just seen that upstream systemd v239 claims to support IPV6MtuBytes
https://lwn.net/Articles/758128/
* networkd's .network files now support a new IPv6MTUBytes= option for
setting the MTU used by IPv6 explicitly as well as a new MTUBytes=
option in the [Route] section to configure the MTU t
I suspect because in bionic/artful we're missing resolvconf package, that the
systemd-resolved service ends up starting later in boot. The
systemd-resolved-update-resolveconf.{service,path} require /sbin/resolvconf to
run; this service had a path-based trigger that would get hooked whenever DH
We will still need something that helps ensure systemd-resolved runs we
reach network-online.target; and I suspect (though I've not validated
yet) that we really want systemd-resolved to be running prior to
systemd-networkd such that systemd-networkd can relay DNS configuration
info retrieved from
This bug was filed to address *port* priority, not the bridge priority.
As mentioned, systemd (networkd) lacks a per-port priority setting;
it should mirror path-cost which takes an interface and value, then the
interfaces have a [Bridge] section which has the value.
--
You received this bug not
1 - 100 of 321 matches
Mail list logo
