[Touch-packages] [Bug 1888726] Re: systemd-udevd regression: some renamed network interfaces stuck in "pending" state

2020-09-09 Thread Ryan Harper
@Dan Just ran into this issue in curtin's vmtest for network_vlan on groovy. I can confirm that if the netplan config includes the driver match on the physical interfaces, then the vlans come up just fine. I was thinking that netplan could inject the driver of the underlying device into the

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-07-21 Thread Ryan Harper
@Rafael It's in both places: https://github.com/koverstreet/bcache-tools/pull/1 I can update the PR there as well; though I don't think upstream cares as Kent's working on bcachefs instead of bcache AFAICT. > I see that you are trying to come up with something nor relying in the kernel fix (to

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-07-21 Thread Ryan Harper
@Rafael For bcache-tools changes, bcache-export-cached-uuid needs the full path to bcache-super-show, as PATH is not exported when running from udev. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu.

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-07-02 Thread Ryan Harper
@ddstreet I'm not sure where upstream is going just yet. For Ubuntu; I think 1) Adjusting the bcache-tools patch to use the full path to bcache- super-show should change; 2) If we fix (1) then I think we can drop the systemd patch from a bug fixing perspective; on the openSUSE image I did

Re: [Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-06-30 Thread Ryan Harper
On Tue, Jun 30, 2020 at 6:35 AM Balint Reczey <1861...@bugs.launchpad.net> wrote: > @raharper I've forwarded the systemd fix for you with minimal tidying of > the commit message https://github.com/systemd/systemd/pull/16317 Thanks! > > -- > You received this bug notification because you are

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-22 Thread Ryan Harper
systemd debdiff with a fix to skip creating /dev/disk/by-uuid for bcache backing, caching devices. ** Patch added: "lp1861941-skip-bcache-links.debdiff" https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1861941/+attachment/5375730/+files/lp1861941-skip-bcache-links.debdiff -- You

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-22 Thread Ryan Harper
Updated test to be a bit more resilient. ** Attachment added: "test-bcache-byuuid-links-fixed.sh" https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375723/+files/test-bcache-byuuid-links-fixed.sh -- You received this bug notification because you are a member

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-22 Thread Ryan Harper
Tarball of a source package with a fix for this issue: bcache-tools_1.0.8.orig.tar.gz bcache-tools_1.0.8-4ubuntu1_amd64.build bcache-tools_1.0.8-4ubuntu1_amd64.buildinfo bcache-tools_1.0.8-4ubuntu1_amd64.changes bcache-tools_1.0.8-4ubuntu1_amd64.deb bcache-tools_1.0.8-4ubuntu1.debian.tar.xz

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-22 Thread Ryan Harper
debdiff of the changes ** Attachment added: "bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1" https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941/+attachment/5375722/+files/bcache-tools-debdiff-1.0.8-4_to_1.0.8-4ubuntu1 -- You received this bug notification because you are a

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-22 Thread Ryan Harper
OK. I've reviewed the kernel code, and there are no unexpected changes w.r.t the CACHED_UUID change event. So I don't think we will need any kernel changes which is good. With the small change to the 60-persistent-storage.rules to not attempt to create a /dev/disk/by-uuid symlink for the

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-21 Thread Ryan Harper
@Balint I do not thing the fix you're released is correct, can you upload a new version without the scripts? Also, we should fix make-bcache -B to ensure that cset.uuid is not initialized; that may be why the kernel thinks it should emit the CACHED_UUID if the suerpblock of the device has a

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-21 Thread Ryan Harper
Digging deeper and walking through this in a focal vm, I'm seeing some strange things. Starting with a clean disk, and just creating the backing device like so: make-bcache -B /dev/vdb We see /dev/bcache0 get created with vdb as the backing device. Now, after this, I see: /dev/bcache/by-uuid/

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-20 Thread Ryan Harper
That doesn't explain why they show up sometimes, but not all of the time. There are 3 devices in play here. * The backing device, let's say /dev/vda; this is where we want to store the data. * The caching device, let's say /dev/vdb; this holds the cache. * The bcache device; this only appears

[Touch-packages] [Bug 1861941] Re: bcache by-uuid links disappear after mounting bcache0

2020-05-20 Thread Ryan Harper
I guess I don't understand why we see this in focal. The two events in Colin's trace always happen on any Ubuntu kernel. We should see if we can get another udev trace on bionic that captures both CHANGE events, one will be from the bcache driver itself, and one is from the block layer. THe

[Touch-packages] [Bug 1878752] Re: vgcreate fails on /dev/disk/by-dname block devices

2020-05-18 Thread Ryan Harper
I would very much agree with xnox (it's a duplicate) (and Dan, nothing for curtin to do); curtin generated dname rules rely upon pointing to a /dev/bcache/by- uuid/* symlink which is currently broken per https://bugs.launchpad.net/ubuntu/+source/linux-signed/+bug/1861941 which at this time points

[Touch-packages] [Bug 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper

2020-04-29 Thread Ryan Harper
Probert PR to drop --mknodes: https://github.com/canonical/probert/pull/88 Curtin MP to drop --mknodes https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/383141 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed

[Touch-packages] [Bug 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper

2020-04-28 Thread Ryan Harper
I don't think this is the right fix. We need to test that it doesn't prevent vgscan from finding and creating /dev/vg/lv device files outside of of multipath. The real fix involves: 1) omitting the call to vgmknodes if there are no volume groups present 2) if vgnodes are present,

[Touch-packages] [Bug 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper

2020-04-28 Thread Ryan Harper
This patch configures the dm_task to use the DM_UDEV_DISABLE_LIBRARY_FALLBACK udev flag to prevent calls to dm_mknodes() from using the library fallback code. Another possible fix would be to obtain a different return code from vgscan.c where it does not detect any VGs and then calls the mknode

[Touch-packages] [Bug 1874501] Re: vgscan --mknodes creates block device multipath nodes in /dev/mapper

2020-04-28 Thread Ryan Harper
Note, the whitespace damage in the patch is not needed, just my text client cleaning up trailing whitespace. With this patch applied, vgscan --mknodes no longer creates block devices in /dev/mapper root@ubuntu:/dev/mapper# ls -al total 0 drwxr-xr-x 2 root root 120 Apr 28 16:31 . drwxr-xr-x

[Touch-packages] [Bug 1867029] Re: Package ifupdown breaks network configuration by cloud-init

2020-03-11 Thread Ryan Harper
** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Tags added: uec-images -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1867029 Title:

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-25 Thread Ryan Harper
On Tue, Feb 25, 2020 at 2:35 PM Scott Moser wrote: > this seemed to "just work" for me. > http://paste.ubuntu.com/p/93dWDPZfZT/ Ah, I didn't check that there was an existing ubuntu/devel branch. Sorry. I've pushed a MR here:

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-25 Thread Ryan Harper
** Patch added: "debdiff showing the changes to upload to fix the bug." https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5330894/+files/cloud-utils_0.31-6_to_0.31-7.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-25 Thread Ryan Harper
** Attachment added: "tarball of source package to upload" https://bugs.launchpad.net/cloud-init/+bug/1834875/+attachment/5330895/+files/cloud-utils_0.31-7-gd99b2d76-source.tar.xz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-25 Thread Ryan Harper
@Scott, cloud-utils isn't quite new-upstream-snapshot out of the box; the debian dir does not contain the changelog; however, I think I've got this sorted out. I've a MP I can put up; but it only will show the add of the changelog file. I'll attach a debdiff and a source package. -- You

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-14 Thread Ryan Harper
Here's the upstream changes to growpart I'm suggesting: https://code.launchpad.net/~raharper/cloud-utils/+git/cloud- utils/+merge/379177 I've also proposed on modifications to cloud-init's cc_growpart as a further method to aid debugging if this hit as well as some mitigation around the race.

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Ryan Harper
** Changed in: curtin (Ubuntu Focal) Status: Triaged => In Progress ** Changed in: curtin (Ubuntu Focal) Assignee: (unassigned) => Ryan Harper (raharper) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Ryan Harper
** Merge proposal linked: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/379024 -- 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/1862846 Title: Crash

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Ryan Harper
@Alberto > I thought the installer would work similarly to what the desktop installer > does with btrfs, where it creates subvolumes for / and /home in the root > partition (as @ and @home). > > On my desktop, when I upgrade I just move @ out of the way (by renaming it) > and the installer

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Ryan Harper
@Lee Thanks for tracking down the util-linux bug. Since this is broken in 2.34 (eoan/focal); I'm thinking we should use sysfs to find the parent via device name walking; Given a kname (nvme0n1p1) of the target partition # look up sysfs path from kname % realpath /sys/class/block/nvme0n1p1

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

2020-02-12 Thread Ryan Harper
** Also affects: util-linux (Ubuntu) Importance: Undecided Status: New ** Tags added: rls-ff-incoming ** Also affects: util-linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: curtin (Ubuntu Focal) Importance: High Status: Triaged ** Also

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-10 Thread Ryan Harper
Yes, this is my read on the issue as well. The trigger is related to the inotify watch that systemd-udevd puts on the disk. Something that might help that we could try per xnox's comment around use of flock. if growpart were to flock /dev/sda (we need to sort out what flags are needed to

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2020-02-07 Thread Ryan Harper
Verified Eoan systemd 242-7ubuntu3.7 correctly sets IPv6 MTU Verified Bionic systemd 237-3ubuntu10.39 correctly sets IPv6 MTU ** Attachment added: "curtin vmtest logs for ipv6 mtu verification"

[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to

2020-02-07 Thread Ryan Harper
Verified VLANs on Eoan using systemd 242-7ubuntu3.7 from -proposed correctly set the MTU to 1500 when specified in the netplan config. ** Attachment added: "curtin vmtest logs for vlan mtu verification"

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2020-02-06 Thread Ryan Harper
Cloud-init service starts and will run growpart, etc Feb 06 00:37:26 ubuntu systemd[1]: Starting Initial cloud-init job (pre-networking)... Feb 06 00:37:37 test-xrdpdnvfctsofyygmzan systemd[1]: Starting Initial cloud-init job (metadata service crawler)... Something has modified sdb1

[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to

2020-02-05 Thread Ryan Harper
Eoan vmtests for vlan MTU checks now pass: (neipa) vlan-mtu % egrep "242-7ubuntu3.3" output/EoanTestNetworkVlan/logs/install-serial.log [ 131.271209] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libnss-systemd amd64 242-7ubuntu3.3 [126 kB] [ 131.281683]

[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to

2020-02-05 Thread Ryan Harper
** Attachment added: "curtin vmtest logs for vlan mtu issue" https://bugs.launchpad.net/curtin/+bug/1846232/+attachment/5325684/+files/bug-1846232-curtin-vmtest-verification.tar.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2020-02-05 Thread Ryan Harper
Curtin vmtest verification for bionic using systemd from -proposed has run successfully. (neipa) ipv6_mtu % egrep "237-3ubuntu10.34" output/BionicTestNetworkMtu/logs/install-serial.log [ 126.923480] cloud-init[1176]: Get:10 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2020-02-05 Thread Ryan Harper
Curtin vmtest verification for eoan using systemd from -proposed has run successfully. (neipa) ipv6_mtu % egrep "242-7ubuntu3.3" output/EoanTestNetworkMtu/logs/install-serial.log [ 136.520219] cloud-init[765]: Get:12 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 libnss-systemd

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2020-02-05 Thread Ryan Harper
** Attachment added: "curtin vmtest logs for ipv6 mtu verification" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/5325665/+files/bug-1671951-curtin-vmtest-verification.tar.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded

[Touch-packages] [Bug 1859858] Re: udev has truncated ID_SERIAL value for scsi disk

2020-01-16 Thread Ryan Harper
** 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

[Touch-packages] [Bug 1859858] [NEW] udev has truncated ID_SERIAL value for scsi disk

2020-01-15 Thread Ryan Harper
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

[Touch-packages] [Bug 1846232] Re: networkd pads interface MTU by 4 bytes for vlan even when told not to

2019-11-15 Thread Ryan Harper
** 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.

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Ryan Harper
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,

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Ryan Harper
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 >

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Ryan Harper
@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

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-07 Thread Ryan Harper
> 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

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-11-06 Thread Ryan Harper
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

[Touch-packages] [Bug 1851438] Re: cloud-init disk_setup fails to partition disk for Ubuntu18

2019-11-05 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-11-01 Thread Ryan Harper
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.

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-30 Thread Ryan Harper
@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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-28 Thread Ryan Harper
@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

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-25 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-24 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-24 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-23 Thread Ryan Harper
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:

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-10-23 Thread Ryan Harper
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

[Touch-packages] [Bug 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan

2019-10-01 Thread Ryan Harper
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

[Touch-packages] [Bug 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan

2019-10-01 Thread Ryan Harper
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

[Touch-packages] [Bug 1846232] Re: vmtests: test_ip_output failing in vlan tests on eoan

2019-10-01 Thread Ryan Harper
@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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Ryan Harper
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:

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-28 Thread Ryan Harper
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:

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-08-26 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-08-23 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-08-23 Thread Ryan Harper
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

[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev

2019-08-23 Thread Ryan Harper
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

[Touch-packages] [Bug 1838653] [NEW] lvs blocks a long time when /run is not mounted

2019-08-01 Thread Ryan Harper
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

[Touch-packages] [Bug 1768468] Re: error in ca_certs module

2019-07-19 Thread Ryan Harper
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

[Touch-packages] [Bug 1768468] Re: error in ca_certs module

2019-07-19 Thread Ryan Harper
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:

[Touch-packages] [Bug 1831787] Re: Bogus routes after DHCP lease change

2019-06-06 Thread Ryan Harper
** 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,

[Touch-packages] [Bug 1831787] Re: Bogus routes after DHCP lease change

2019-06-05 Thread Ryan Harper
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

[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-02-21 Thread Ryan Harper
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.

[Touch-packages] [Bug 1779156] Re: lxc 'delete' fails to destroy ZFS filesystem 'dataset is busy'

2019-02-05 Thread Ryan Harper
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.

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-12-04 Thread Ryan Harper
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 >> I

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-12-04 Thread Ryan Harper
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? --

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-11-27 Thread Ryan Harper
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

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-11-26 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-09-28 Thread Ryan Harper
This may now be a cloud-init bug if the support is there since this is a network-config v1 -> cloud-init renders netplan. On Fri, Sep 28, 2018 at 9:12 AM Scott Moser wrote: > > Hm... > > Our tests show that this is not fixed in cosmic or bionic. > >

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-09-28 Thread Ryan Harper
Actually there needs to be changes to netplan to emit the correct IPV6BytesMtu setting to networkd; and then cloud-init can emit the correct netplan yaml for that. This feature is on the netplan roadmap here: https://trello.com/c/nIjLIRSG/6-support-ipv6-mtu-bytes-configuration ** Also

[Touch-packages] [Bug 1789758] [NEW] bluetooth headphones a2dp profile does not function after suspend

2018-08-29 Thread Ryan Harper
Public bug reported: 1) lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 2) $ apt-cache policy bluez bluez: Installed: 5.48-0ubuntu3.1 Candidate: 5.48-0ubuntu3.1 Version table: *** 5.48-0ubuntu3.1 500 500 http://us.archive.ubuntu.com/ubuntu

Re: [Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-08-29 Thread Ryan Harper
On Wed, Aug 29, 2018 at 8:41 AM Dimitri John Ledkov wrote: > > Do we need this in bionic? Yes > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1671951 > > Title: > networkd should allow configuring IPV6 MTU > > To

[Touch-packages] [Bug 1671951] Re: networkd should allow configuring IPV6 MTU

2018-06-25 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

2018-06-19 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

2018-06-19 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

2018-06-15 Thread Ryan Harper
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

[Touch-packages] [Bug 1777094] Re: dnsmasq started too early, not getting all interfaces

2018-06-15 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-25 Thread Ryan Harper
"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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-25 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-25 Thread Ryan Harper
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

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-24 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-24 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-15 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-15 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-11 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-11 Thread Ryan Harper
-link.rules bin/readlink On Fri, May 11, 2018 at 9:35 AM, Ryan Harper <ryan.har...@canonical.com> 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 r

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-11 Thread Ryan Harper
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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-11 Thread Ryan Harper
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

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

2018-05-09 Thread Ryan Harper
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

  1   2   3   4   >