, once netplan has support for this syntax (which is almost
identical to path-cost)
Then cloud-init.net.netplan renderer will need an update to support
generating netplan yaml with
the correct structure.
On Wed, Nov 29, 2017 at 9:52 AM, Ryan Harper <1668...@bugs.launchpad.net>
wrote:
>
So, /dev/bcache/by-uuid is not getting created.
That's the same kernel bug I filed.
And, if they were, I think they'd get moved properly.
init-bottom/udev script does the following:
# Stop udevd, we'll miss a few events while we run init, but we catch up
udevadm control --exit
# move the /dev
pfs to the rootfs; fall back to util-linux mount that does
# not understand -o move
mount -n -o move /dev ${rootmnt}/dev || mount -n --move /dev ${rootmnt}/dev
Let's see if that helps resolve the "missing" symlinks.
On Thu, Nov 30, 2017 at 10:27 AM, Ryan Harper
wrote:
> So
** Bug watch added: Debian Bug tracker #844775
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844775
--
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/1729145
Title:
/d
It looks like there is some ordering issues:
This is a grep through /run/udev/links ; these are checked by udev-dev
# find . -name 'b250*'
./\x2fdisk\x2fby-uuid\x2f0a270acb-56b8-4498-8bad-b3bb149fe869/b250:1
./\x2fdisk\x2fby-uuid\x2f92b0868d-7e56-4956-8e55-2c90ebee4a72/b250:0
./\x2fbcache\x2fby-u
id/ and dname
will point to that, which abstracts away whether it points to bcache0, 1 ,
or N.
/dev/disk/by-dname/foo -> ../../../bcache/by-uuid/ ->
../../bcacheN
On Thu, Nov 30, 2017 at 7:16 PM, Ryan Harper
wrote:
> It looks like there is some ordering issues:
>
> This is a gre
Untested patch. Hoping to convey the change that's needed.
- decouple emitting a cached_dev CHANGE uevent which includes dev.uuid and
dev.label
from bch_cached_dev_run() which only happens when a bcacheX device is bound
to the
actual backing block device (bcache0 -> vdb)
- update bch_c
Hi Joseph,
Sorry, I didn't give that a compile either; I just wanted to show what the
change could look like;
Let me see if I can get that to at least compile.
On Mon, Dec 4, 2017 at 11:18 AM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:
> It looks like env[] was declared in bch_ca
Looks like those two kfree's in dev_run can be dropped since that was an
exit after kmalloc'ing env entries which are now only done in
bch_cached_dev_emit_change()
which is only called by dev_run after it knows that the device is not
yet running.
On Mon, Dec 4, 2017 at 11:35 AM, R
Revised patch, should fix error with kfree on env
** Patch added: "bcache_always_emit_backing_dev_change_uevent_v2.diff"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1729145/+attachment/5018329/+files/bcache_always_emit_backing_dev_change_uevent_v2.diff
--
You received this bug notif
Can you attach:
blkid output
ls -al /dev/disk/by-label
/proc/mounts
Testing locally on Xenial, and mount always says something isn't found.
% tail -n1 /etc/fstab
LABEL=METADATA /mnt vfatdefaults, 0 0
(foudres) ~ % sudo mount -l - /mnt
mount: can't find LABEL=METADATA
strace of
Thanks! I'll give it a try today.
On Tue, Dec 5, 2017 at 3:43 PM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:
> I built an Artful test kernel with the path provided by Ryan. The test
> kernel can be downloaded from:
>
> http://kernel.ubuntu.com/~jsalisbury/lp1729145/
>
> Can those
333685 -> ../../bcache2
├── 57e009b1-6bf4-42ea-abe0-334b10941a0b -> ../../bcache0
├── 7ce7dc32-7da9-42a8-899a-5d21ed7ea714 -> ../../bcache3
└── 92d882d8-38cd-4537-847b-6f9c40ba67b4 -> ../../bcache1
2 directories, 6 files
On Tue, Dec 5, 2017 at 4:00 PM, Ryan Harper
wrote:
> Th
Thanks for doing the cleanup; Patch looks good and I approve.
Signed-off-by: Ryan Harper
On Tue, Dec 5, 2017 at 4:59 PM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:
> In the final patch we submit for SRU, it will also include your Signed-
> off-by, I just forgot to a
Here's the Zesty test; all looks good.
ubuntu@ubuntu:~$ cat /etc/cloud/build.info
build_name: server
serial: 20171207
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.10.0-40-generic #44~lp1729145 SMP Wed Dec 6 16:21:45 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$ tree /dev/bcache
/dev/bcache
Tested the xenial update. I had one boot where the links didn't get
created, but I cannot recreate that issue now.
On Thu, Dec 7, 2017 at 9:56 AM, Ryan Harper
wrote:
> Here's the Zesty test; all looks good.
>
> ubuntu@ubuntu:~$ cat /etc/cloud/build.info
> build_name: ser
Confirmed bionic works as expected.
I suspect you can send that upstream with my SoB faster than I can.
Definitely interested in seeing if they'll take something like that.
On Thu, Dec 7, 2017 at 1:21 PM, Joseph Salisbury <
joseph.salisb...@canonical.com> wrote:
> Thanks for testing and the patc
On Tue, Dec 12, 2017 at 5:52 AM, Dimitri John Ledkov wrote:
> Once the kernel is fixed, are there any changes that are required to
> systemd/udev?
>
No changes needed.
>
> ** Changed in: systemd (Ubuntu Bionic)
>Status: New => Incomplete
>
> --
> You received this bug notification beca
Testing a zfsroot deploy without zfs present, curtin will trigger an
install of the full linux-image-generic package during the install deps
check.
This produces this output:
[7.696444] cloud-init[1214]: Cloud-init v. 17.1 running 'modules:config' at
Thu, 21 Dec 2017 21:39:54 +. Up 6.72
** Also affects: systemd (Ubuntu)
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/1749722
Title:
NTP: take into account systemd-
Some further looking at the systemd side, Bionic no longer carries the
override conf (disable-with-time-daemon.conf) in favor of updating each
client's systemd unit to use:
Conflicts=systemd-timesyncd.service
Conflicts will ensure that the target service is stopped if the current
unit is started.
On Mon, Feb 19, 2018 at 9:33 AM, Dimitri John Ledkov wrote:
> I think cloud-init is the oracle of information of which ntp daemon to
> use, and which ntp servers to use. Thus on bionic+ cloud-init, when
> configuring ntp, should also "disable systemd-timesyncd" if some
> alternative NTP server is
I gave the "loopback" trick a go like so:
root@b1:~# cat /etc/systemd/network/10-netplan-lo.network
[Match]
Name=lo
[Network]
Address=127.0.0.1
DNS=10.90.90.1
Domains=maaslab maas
root@b1:~# networkctl status --all
● 1: lo
Link File: n/a
Network File: /etc/systemd/network/10-netplan-l
I've got a branch which would have cloud-init disable accept-ra unless
cloud-init has an explicit ipv6 configuration (static or dhcp6). This
only affects the solicitation effort, ipv6 link-local is of course,
unaffected as is explicit ipv6 configuration. I believe LXD is in a
position to know if
** Merge proposal linked:
https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438
--
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/1749722
Title:
NT
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 man
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 bionic-updates/ma
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 affects:
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.
>
> https://jenkins.ubuntu.com/server/job/curtin-vm
** Changed in: curtin
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lvm2 in Ubuntu.
https://bugs.launchpad.net/bugs/1573982
Title:
LVM boot problem - volumes not activated after upgrade to
Likely related, but in Artful systemd-networkd is setting the hostname
and has a 10 second timeout:
# systemctl status --no-pager -l systemd-networkd
● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled;
vendor preset: enabled)
A
I can confirm that if I set PrivateNetwork=no that hostnamed runs and boot
is magically 10 seconds faster.
On Thu, Nov 9, 2017 at 1:46 PM, Stéphane Graber
wrote:
> Someone with systemd knowledge should check what PrivateNetwork actually
> does. The name implies it's unsharing a new network names
Currently looking at updatin lxc package to have lxc-net run After
=network-online.target which should ensure that ifup on auto interfaces
has run, meaning ethX interfaces will have obtained and IP and at that
point then lxc-net can check if something is squating on 10.0.3.X
network and switch to a
https://lists.linuxcontainers.org/pipermail/lxc-
devel/2015-October/012630.html
--
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/1510619
Title:
Wily: add machine fails using kvm
Public bug reported:
1. % lsb_release -rd
Description:Ubuntu Wily Werewolf (development branch)
Release:15.10
2. % apt-cache policy bsdtar
bsdtar:
Installed: 3.1.2-11build1
Candidate: 3.1.2-11build1
Version table:
*** 3.1.2-11build1 0
500 http://us.archive.ubuntu.com/u
Public bug reported:
1. $ lsb_release -rd
Description:Ubuntu 14.04.2 LTS
Release:14.04
2. $ apt-cache policy lvm2
lvm2:
Installed: 2.02.98-6ubuntu2
Candidate: 2.02.98-6ubuntu2
Version table:
*** 2.02.98-6ubuntu2 0
500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64
I've attempted to reproduce this issue but I've not been able to at this
point with stock 14.04 rsync versions between two 14.04 (up-to-date)
systems. It may be highly dependent on the actual data; if you can
reproduce this with something publicly available (like a large iso
catted together multip
Public bug reported:
1. % lsb_release -rd
Description:Ubuntu Wily Werewolf (development branch)
Release:15.10
2. % apt-cache policy lxc
lxc:
Installed: 1.1.2-0ubuntu3
Candidate: 1.1.2-0ubuntu3
Version table:
*** 1.1.2-0ubuntu3 0
500 http://us.archive.ubuntu.com/ubuntu/
Public bug reported:
1) # lsb_release -rd
Description:Ubuntu Artful Aardvark (development branch)
Release:17.10
2) # apt-cache policy systemd
systemd:
Installed: 234-2ubuntu10
Candidate: 234-2ubuntu10
Version table:
*** 234-2ubuntu10 500
500 http://archive.ubuntu.com/ub
It turns out that if STP is enabled, then one cannot disable the forward
delay, and a value < 2 is not compatible with STP.
If I set stp: false in netplan, then we get:
# cat /run/systemd/network/10-netplan-br0.netdev
[NetDev]
Name=br0
Kind=bridge
[Bridge]
AgeingTimeSec=250
Priority=22
ForwardD
** Branch linked: lp:~raharper/curtin/trunk.vmtest-remove-bug-timers
--
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 M
I re-ran the recreate on a daily artful image, updated cloud-init in the
image to use the udevadm trigger as before and noticed that it still
fails to apply the MTU to the second interface.
Taking the suggestion of including a udevadm control reload, I further
modified the image to add that reload
And what about /etc/netplan/*.yaml
and /run/systemd/network/*
If you can attach the journal binary file, we can query the state
independently from you
tar up /run/log/journal/
Thanks
On Tue, Jun 13, 2017 at 11:33 AM, Stefan Bader
wrote:
> #> ifquery --list
> lo
>
> #> ip link show
> 1: lo:
This is annoying:
% journalctl -D var/log/journal -o short-precise Journal file
var/log/journal/1fe5c5ed88c14c81bd52acb9f96f3a18/system.journal uses an
unsupported feature, ignoring file.
-- No entries --
Why can't xenial systemd journalctl read an artful one? That seems like a
terrible idea w.r
It looks a lot like this issue:
https://github.com/systemd/systemd/issues/1645
Where DHCP works, it has an ip and can sync time and other items, but the
wait service isn't happy.
On Wed, Jun 14, 2017 at 10:46 AM, Steve Langasek <
steve.langa...@canonical.com> wrote:
> The journal shows, two min
What does your networkctl status eth0 show?
On Wed, Jun 14, 2017 at 11:34 AM, Ryan Harper
wrote:
> It looks a lot like this issue:
>
> https://github.com/systemd/systemd/issues/1645
>
> Where DHCP works, it has an ip and can sync time and other items, but the
> wait service i
This is a known issue w.r.t waiting for IPV6 LL, on Xenial KVM, qemu -net
user does not provide IPV6 LL response (yakkety and newer do), so there's a
delay; it does sound like the IPV6 LL timeout is longer than it used to be
as I've seen a 5 to 10 second delay in VMs launched on KVM on xenial, but
I just tested the zesty-proposed version and it works as expected.
% lxc launch ubuntu-daily:zesty z1
Creating z1
Starting z1
# confirm current version of systemd
% lxc exec z1 -- apt-cache policy systemd
systemd:
Installed: 232-19
Candidate: 232-19
Version table:
*** 232-19 500
onf(8)
DefaultDependencies=no
-Before=networking.service
+Before=network-pre.target
+Wants=network-pre.target
** Changed in: resolvconf (Ubuntu)
Status: Confirmed => Invalid
** Changed in: resolvconf (Ubuntu)
Assignee: Ryan Harper (raharper) => (unassigned)
--
You receiv
@Mercury
Hi, please note that the change I've made is *only* against the
resolvconf task; as you say and document the issue (and potential fix)
is against dnsmasq; ergo there is no need for a resolvconf patch/change.
You mention:
"and resolvconf was not properly tracking how interfaces were add
Something isn't working here. I also typo'd the test-case, in
particular, the change to the cloud-init.service unit didn't specify
'systemd-networkd-wait-online.service', the sed command missed the 'd'
in networkd.
When I fix that, I find that systemd-networkd-resolvconf-update.service
does NOT r
systemd-networkd-resolvconf-update.service uses default dependencies
which will only run after sysinit.target, however cloud-init.service
needs to run before sysinit.target; systemd apparently dropped running
the service due to the inconsistent order. Adding a
DefaultDependencies=no to systemd-net
On Tue, Mar 7, 2017 at 6:27 AM, Dimitri John Ledkov
wrote:
> Should one not restart systemd-networkd after writing out .link et.al.
> units?
>
systemd-networkd only deals with .netdev and .network files; .link files
are handled by udev
This occurs during boot, before systemd-networkd starts.
On Tue, Mar 7, 2017 at 9:41 AM, Dimitri John Ledkov
wrote:
> On 7 March 2017 at 14:37, Ryan Harper <1669...@bugs.launchpad.net> wrote:
> > On Tue, Mar 7, 2017 at 6:27 AM, Dimitri John Ledkov <
> launch...@surgut.co.uk>
> > wrote:
> >
> >> Should one n
On Wed, Mar 8, 2017 at 5:03 AM, Dimitri John Ledkov
wrote:
> I wonder if following should be done (in netplan code that does the re-
> trigger, or outside after .link files modified):
>
> $ sync
> $ udevadm control --reload
> $ udevadm trigger --verbose --subsystem-match=net --action=add
>
> This
@racb
I verified systemd 229-4ubuntu17 with both ifupdown and networkd
configuration.
The specific packages and features is somewhat complicated due to
the different scenarios and change in networking behavior in yakkety+
I've attached a chart with details. Also viewable here:
http://paste.ubu
Details about different release vs. network backend requirements
** Attachment added: "lp1649931-release-network-matrix.txt"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1649931/+attachment/4833940/+files/lp1649931-release-network-matrix.txt
--
You received this bug notification be
Here's the journal from a boot which fails.
** Attachment added: "netplan-udev-fail-journal.tgz"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+attachment/4834860/+files/netplan-udev-fail-journal.tgz
--
You received this bug notification because you are a member of Ubuntu
To
Script to generate a zesty cloud-image that can recreate the issue.
** Attachment added: "01-netplan-udev-recreate.sh"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+attachment/4834861/+files/01-netplan-udev-recreate.sh
--
You received this bug notification because you are a
Script which launches the image created with the previous script to
recreate issue.
** Attachment added: "02-netplan-udev-launch.sh"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1669564/+attachment/4834862/+files/02-netplan-udev-launch.sh
--
You received this bug notification becau
I've attached the requested journal. I've also attached two scripts
which can be used to recreate the issue for further investigation.
** Changed in: systemd (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
Public bug reported:
1) Zesty
2) systemd-232-19
3) I need to configure the IPV6 MTU for tunneling by adding an
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6
static address in the [Network] section
4) networkd does not parse or read the value and does not apply this
** Patch added: "ipv6_mtu.debdiff"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1671951/+attachment/4835554/+files/ipv6_mtu.debdiff
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.
I've a build of this fix here:
https://launchpad.net/~raharper/+archive/ubuntu/cloud-init-dev
(systemd=232-19ubuntu3~fixbuild1)
I've tested this minimally in a Zesty VM and it's successfully applies
an IPV6MTU in addition to the device mtu (if that's also included).
--
You received this bug not
Public bug reported:
1) Xenial, Yakkety and Zesty; (Xenial is affected if you're using networkd and
resolved, but it's not the default)
2) 229-4ubuntu16, 231-9ubuntu3, 232-18ubuntu1 respectively to (1)
3) DNS resolution should be available once systemd has reached
'network-online.target' state
I've moved the systemd-resolved issue for unit ordering out of this
bug/SRU into a new one so we can finish out this SRU and handle this
last change to systemd-resolved separately.
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1673860
--
You received this bug notification because you ar
Working it now, sorry for the delay
On Thu, Mar 23, 2017 at 1:07 PM, Brian Murray wrote:
> Missing SRU information regarding Impact, Test Case, Regression
> Potential.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/16
** Description changed:
+ === Begin SRU Template ===
+ [Impact]
+
+ For releases using systemd-resolved (yakkety and zesty); the unit
+ configuration does not require that the service be active before
+ allowing systemd to reach 'network-online.target' which is a special
+ target used to allow ot
This also needs some discussion w.r.t how to handle IPV6-only devices;
namely if you want to set the IPV6 MTU to something higher than the
underlying device's current setting then the device MTU would need to be
raised as well. That needs to be implemented and added to the patch.
--
You received
Revisting this on an artful image, and nothing besides the driver replug
(what netplan apply does) appears to work to process .link files.
Something changed I suspect in systemd w.r.t the builtin-test
setup_net_link path which would process .link files.
--
You received this bug notification beca
** Patch added: "xenial-dns-before-online-target-lp1649931-v2.debdiff"
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1649931/+attachment/4812597/+files/xenial-dns-before-online-target-lp1649931-v2.debdiff
--
You received this bug notification because you are a member of Ubuntu
Tou
Public bug reported:
ubuntu@ubuntu:~$ lsb_release -rd
Description:Ubuntu Zesty Zapus (development branch)
Release:17.04
ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.9.0-15-generic #16-Ubuntu SMP Fri Jan 20 15:28:49 UTC 2017
ppc64le ppc64le ppc64le GNU/Linux
ubuntu@ubuntu:~$ apt-cache pol
** Description changed:
Currently resolvconf and systemd-networkd don't ensure DNS has been
configured before allowing network-online.target to be reached.
This was discussed in https://launchpad.net/bugs/1636912 however it was
not a regression since there aren't any users of networkd +
I've verified the SRU test with the package in Xenial proposed. I've
also updated an UbuntuCore16 image with uses networkd and cloud-init to
validate that early networking which requires dns for resolving urls
works.
** Tags removed: verification-needed
** Tags added: verification-done
--
You
Public bug reported:
1. root@ubuntu:/run/systemd/network# lsb_release -rd
Description:Ubuntu Zesty Zapus (development branch)
Release:17.04
2. root@ubuntu:/run/systemd/network# apt-cache policy systemd
systemd:
Installed: 232-18ubuntu1
Candidate: 232-18ubuntu1
Version table:
**
Public bug reported:
root@ubuntu:~# lsb_release -rd
Description:Ubuntu Zesty Zapus (development branch)
Release:17.04
root@ubuntu:~# apt-cache policy udev
udev:
Installed: 232-18ubuntu1
Candidate: 232-18ubuntu1
Version table:
*** 232-18ubuntu1 500
500 http://archive.ubun
** Description changed:
- root@ubuntu:~# lsb_release -rd
+ 1. root@ubuntu:~# lsb_release -rd
Description:Ubuntu Zesty Zapus (development branch)
Release:17.04
- root@ubuntu:~# apt-cache policy udev
+
+ 2. root@ubuntu:~# apt-cache policy udev
udev:
- Installed: 232-18ubuntu1
-
** Description changed:
Currently resolvconf and systemd-networkd don't ensure DNS has been
configured before allowing network-online.target to be reached.
This was discussed in https://launchpad.net/bugs/1636912 however it was
not a regression since there aren't any users of networkd +
For yakkety resolvconf update; I've updated the SRU test-case to
include a more general netplan config for bringing up ethernet devices;
the previous version only worked on lxd (or instances with devices named
eth0).
With the above change; it looks like yakkety/zesty (due to running
systemd-resol
On Tue, May 2, 2017 at 3:05 AM, Dimitri John Ledkov
wrote:
> Looking at the journal files from the netplan-udev that fail, I see that
> links are already renamed, before cloud-init renders things:
>
> Mar 09 17:51:12 ubuntu kernel: virtio_net virtio0 ens3: renamed from eth0
> Mar 09 17:51:12 ubun
On Tue, May 2, 2017 at 8:54 AM, Dimitri John Ledkov
wrote:
> Ideally, the following should happen:
> * boot
> * Created link configuration context
>
> * Check if link configuration needs reloading -> appears in the debug logs
> * New MTU is successfully applied
>
Let me put in the cloud-init se
On Mon, May 8, 2017 at 9:06 AM, Dimitri John Ledkov
wrote:
> I thought we have systemd hotplugging as well, can we not generate
>
I'm not sure what this means
> depedencies that ifup@bond0.5.service Wants= and After=
> ifup@bond0.service? and prevent all of these locks?
>
Wants= and AFter= ar
On Tue, May 9, 2017 at 10:32 AM, Dimitri John Ledkov wrote:
> Maybe this is easier to read.
>
> root@xnox-iad-nr5:~# journalctl -o short-monotonic -u ifup@bond0.service
> -- Logs begin at Tue 2017-05-09 10:57:18 UTC, end at Tue 2017-05-09
> 15:22:34 UTC. --
> [6.740201] xnox-iad-nr5 systemd[1
On Tue, May 9, 2017 at 11:23 AM, Steve Langasek <
steve.langa...@canonical.com> wrote:
> Hi Ryan,
>
> On Tue, May 09, 2017 at 02:20:17PM -, Dimitri John Ledkov wrote:
>
> > it does create the yaml and call generate, but it's not
> > sufficient to create the symlink IIRC due to the code in net
On Wed, May 17, 2017 at 1:14 PM, Dimitri John Ledkov wrote:
> I'm very naive, so please bear with me if this is a silly question. As
> far as I can tell the existing MTU setting in networkd will apply to
> both ipv4 and ipv6 simultaniously. Are you arguing that you want
> specific control of MTU
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 su
@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 testi
@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.
https://
@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
@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 match
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 1
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
p
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, device_mapp
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
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 orde
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
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/
@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 cset.
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 backing
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 m
101 - 200 of 321 matches
Mail list logo
