[Touch-packages] [Bug 1871451] Re: powerpc segfault on exponential of negative in python

Hi, I tested this on a real ppc64le machine: root@1325f5985861:/# python3 -c "import math; print(math.exp(-1))" 0.36787944117144233 root@1325f5985861:/# uname -a Linux 1325f5985861 5.4.0-21-generic #25+lp1866909v202004031128-Ubuntu SMP Fri Apr 3 18:38:30 UTC 202 ppc64le ppc64le ppc64le

[Touch-packages] [Bug 1818340] Re: systemd-networkd core dumps in bionic-proposed

OK, so with the magic of debug symbols and gdb on Cosmic: (gdb) run ... ens8: Gained IPv6LL Assertion 'link->state == LINK_STATE_SETTING_ADDRESSES' failed at ../src/network/networkd-link.c:803, function link_enter_set_routes(). Aborting. ... (gdb) up #3 0x5566b194 in

[Touch-packages] [Bug 1818340] Re: systemd-networkd core dumps in bionic-proposed

Never mind, I can reproduce on Cosmic. -- 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/1818340 Title: systemd-networkd core dumps in bionic-proposed Status in systemd

[Touch-packages] [Bug 1818340] Re: systemd-networkd core dumps in bionic-proposed

Oof, sorry! It's not clear to me from the bug report and subsequent comments - is it just Bionic that's affected, or is it also Cosmic? -- 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 1812760] Re: networkd: [Route] PreferredSource not working in *.network files

** Tags added: sts -- 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/1812760 Title: networkd: [Route] PreferredSource not working in *.network files Status in systemd

[Touch-packages] [Bug 1812760] [NEW] networkd: [Route] PreferredSource not working in *.network files

from a surprising behaviour to a less surprising behaviour, but it's worth pointing out. ** Affects: systemd (Ubuntu) Importance: Undecided Assignee: Daniel Axtens (daxtens) Status: In Progress ** Changed in: systemd (Ubuntu) Status: Confirmed => In Progress ** Changed

[Touch-packages] [Bug 1794909] Re: Memory corruption in RAR decoder

This is the warc infinite loop test case. Unlike the other files, it's *not* encoded, and I use ./bsdtar -Oxf warcloop.warc to see the looping behaviour. ** Attachment added: "warcloop.warc"

[Touch-packages] [Bug 1794909] Re: Memory corruption in RAR decoder

Here's a test case for the NULL pointer dereference in ACL handling. ** Attachment added: "aclcrasher.txt" https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+attachment/5221005/+files/aclcrasher.txt -- You received this bug notification because you are a member of Ubuntu

[Touch-packages] [Bug 1794909] Re: Memory corruption in RAR decoder

(as with the other test cases, it's in plain text, convert it back with xxd -r aclcrasher.txt aclcrasher) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libarchive in Ubuntu. https://bugs.launchpad.net/bugs/1794909 Title:

[Touch-packages] [Bug 1794909] Re: Memory corruption in RAR decoder

Hi Seth, I've pushed them to https://github.com/libarchive/libarchive/pull/1105 Thanks for walking me through the Ubuntu process. Regards, Daniel ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu

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

Hi, This works on reboot but not so well after the system boots. Say I have the following file: network: version: 2 ethernets: ens7: dhcp4: true match: macaddress: 52:54:00:b4:02:6e set-name: myif1 optional: true

[Touch-packages] [Bug 1746419] Re: bond parameters are not changed by 'netplan apply'

Should it though? That will, for example, terminate any tcpdump processes bound to the bond, it will disrupt currently running connections, etc. Maybe we could do it but we'd want to put it behind a --force option or something, I think. -- You received this bug notification because you are a

[Touch-packages] [Bug 1781652] Re: should be possible to specify static routes on a dhcp-configured interface

This hit me too. I'm not sure how netplan can fix this - it looks like it's generating pretty sensible configuration files. -- 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 1746419] Re: bond parameters are not changed by 'netplan apply'

** Also affects: netplan Importance: Undecided Status: New ** Changed in: netplan Status: New => Confirmed -- 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 1770082] Re: systemd-networkd not renaming devices on boot

** Changed in: netplan Status: Confirmed => Fix Released -- 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/1770082 Title: systemd-networkd not renaming devices on

[Touch-packages] [Bug 1619258] Re: netplan should allow NICs to be disconnected and not stall the boot

Thanks, done. ** Changed in: nplan (Ubuntu) Status: In Progress => Fix Released -- 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/1619258 Title: netplan should allow

[Touch-packages] [Bug 1619258] Re: netplan should allow NICs to be disconnected and not stall the boot

This has been in a released version of netplan.io since 0.32. Are we right to mark this as Fix Released for nplan? It looks like LP: #1664844 has been marked as Fix Released too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed

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

Hi, I'm a bit confused then. This is the netplan config you mentioned: network: version: 2 renderer: networkd ethernets: id0: match: macaddress: 08:00:27:6b:d8:91 set-name: eth_static addresses: [ 1.2.3.4/16 ] gateway4: 5.6.7.8 id1: match:

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

Hi, I have confirmed that the Bionic package works on the cloud service where the bug was originally observed. With this package, the affected migrations now succeed. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

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

Hi, I can verify correct behaviour with renaming, static IPs and DHCP with KVM. I'm about to check some cloud services as well. Nicorac, are you claiming this is a regression or just an incomplete fix? If it's just an incomplete fix, I think we should spin that out into another bug and fix it

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

** Tags removed: verification-failed-bionic ** Tags added: verification-done-bionic -- 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/1770082 Title: systemd-networkd not

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

Hi Łukasz, I couldn't find the package in -proposed, but I was able to download it from the link. I verified that a device was not renamed with 0.32~16.04.5 but was correctly renamed with 0.32~16.04.6, so for Xenial, verification succeeds. Regards, Daniel ** Tags removed:

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

Opened https://github.com/systemd/systemd/issues/9006 ** Bug watch added: github.com/systemd/systemd/issues #9006 https://github.com/systemd/systemd/issues/9006 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in

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

> Note, that uvt-kvm is going to use cloud-init; how are you making > sure that cloud-init isn't doing the rename itself? I instrumented the kernel. I added a call to dump_stack() in the function that does interface renaming: dev_change_name() in net/core/dev.c. That showed that the process that

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

Hi Ryan, [Journal Output] Attached. [Reproducer] uvt-kvm create xenial-test release=xenial arch=amd64 virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/ virsh destroy xenial-test virsh start xenial-test uvt-kvm ssh xenial-test dmesg|grep rename [2.790623] virtio_net

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

This is not a full solution. In Xenial this renaming works even if initramfs has *not* been updated and there is no 70-persistent-net.rules file in the initial ramdisk. I'm still figuring out why this is, but it means that even if my patch were applied, there would be a regression in bionic vs

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

Ok, how does this look? ** Patch added: "link-files-in-run.debdiff" https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139062/+files/link-files-in-run.debdiff -- 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

Right. Yes, I can replicate that, thanks heaps! 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 seems pretty far outside of the way that netplan is supposed to work -

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

Ok, so the bit I'm stuck on is how the link files and the netplan generator are getting pulled into the initramfs then. ubuntu@btest:~$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep

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

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! Mathieu, I thought netplan was supposed to be initramfs friendly by

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

Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and I've never seen it regenerated. I also don't see anything in /run/netplan or /run/systemd/network that has been autogenerated. I haven't touched anything else generated by cloud-init. When would cloud-init regenerate a

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

Both the original cloudy report and my test use a VM. The issue seems to happen for both virtio and emulated e1000 network hardware. What happens differently with a VM? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd

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

** Summary changed: - set-name doesn't work on boot, only with netplan apply + systemd-networkd not renaming devices on boot ** Description changed: === systemd issue === Renaming devices doesn't seem to work. If I disable all other network configuration and create

[Touch-packages] [Bug 1770082] Re: set-name doesn't work on boot, only with netplan apply

** Description changed: + === systemd issue === + + Renaming devices doesn't seem to work. + + If I create /etc/systemd/network/10-network.link with: + + [Match] + MACAddress=52:54:00:c1:c9:bb + + [Link] + Name=myiface3 + + I expect this to cause the device with that MAC address to be named

Re: [Touch-packages] [Bug 1746419] Re: bond parameters are not changed by 'netplan apply'

Right, so netplan should tell networkd to tear down the bond first? On Thu, Feb 15, 2018 at 7:06 AM, Dimitri John Ledkov wrote: > I believe this is systemd intentional to not change bond parameters if > the bond already exists. It is assumed that something else has

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

Hi Marzog, What commit has been committed to Linux? I cannot find it. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1701297 Title: NTP reload failure

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

Tyler - thanks for that. John - this is coming up in some internal support team escalations so I'm going to have a look at the kernel changes myself and will let you know if I find anything. I'd be keen to sync up if you have any leads. Regards, Daniel -- You received this bug notification

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

Hi Tyler, Do you know what the changes between the ga-16.04 and hwe-16.04 kernel are that make apparmor+overlayfs work? I'm worried we might hit this problem elsewhere... Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

** Changed in: xorg (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1691991 Title: Xorg Segmentation fault on Hisilicon D05 board

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, Thanks for that. You are right, this should be split into two kernel issues. I have opened: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1698700 - "pci:" prefix in bus ID https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1698706 - Quirk for vga card and bridge I have

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, I have done more work on the HiSilicon board. I have talked with the SEG team and our conclusion is that the hardware is not compliant with the specification, but that it is appropriate to include a workaround in software. I have developed a patch that adds a workaround or 'quirk' to the

Re: [Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, OK, that sounds reasonable. I will follow up on this. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1691991 Title: Xorg Segmentation fault on

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, I have installed a version of the kernel which ignores the capabilities of the PCI bridge when determining whether a device can be the boot device. With this patched kernel, X starts without needing a config file. This confirms: - that the vga card is not marked as boot device because

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, I have successfully verified that with the patched kernel and the Xorg config, X starts fine. Do you need assistance getting that patch upstream, or is that something HiSilicon/the HWE team can do? Regards, Daniel -- You received this bug notification because you are a member of

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Dann, Ignore that, I didn't realise I needed the -extra package. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1691991 Title: Xorg Segmentation fault

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Dann, I have tried to boot the HiSilicon board with a zesty kernel (and with a patched zesty kernel) and it boots, gets to the following, and then hangs without displaying a prompt: [9.900239] async_tx: api initialized (async) [9.991929] Btrfs loaded, crc32c=crc32c-arm64-hw [

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, I have looked at the PCI setup a bit more closely: the VGA card is behind a PCI bridge which does not advertise the PCI_BRIDGE_CTL_VGA capability, so it is not being picked up by the kernel as the default/boot card. Is there anything special about the bridge or the hardware in this

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

** Changed in: xorg (Ubuntu) Assignee: (unassigned) => Daniel Axtens (daxtens) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1691991 Title: Xorg Segmentation fa

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi, I can get xorg working if I do these 2 things: 1) Edit memory with gdb to add "pci:" to bus id. This is what the kernel patch should do. I will test the patch soon, I am just waiting for the kernel to build. 2) Install this /etc/X11/xorg.conf: Section "ServerFlags" Option

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Dann: thanks, will do that. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1691991 Title: Xorg Segmentation fault on Hisilicon D05 board (arm64) Status in

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi, On further investigation it turns out that one large difference between my x86 system and the arm64 system is they way the vga arbiter is operating in the kernel. This means that the vga card isn't labelled as the "boot vga" card, which affects how it's picked up by X. On the HiSilicon

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Ok, so I think part of the problem is that the kernel hibmc driver needs to use a set_busid function from the drm core. I've simulated this change in the debugger, and it seems to at least prevent the crash. (It doesn't seem to be enough for the server to work, still working on that.) Here's a

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

OK, I have made some progress on this: The busid reported by libdrm on the arm64 system is "0007:a1:00.0" The busid reported by libdrm on a amd64 system is "pci::00:02.0" The "pci:" prefix is missing on arm64. I think this leads to the segfault on arm64 as X tests for the prefix. This

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi Mao, Yes, remote access would be the fastest way to debug this. You can contact me by email - daniel.axt...@canonical.com. Regards, Daniel -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu.

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi, This is what I have figured out so far. For some reason the initial probing done by the modesetting driver fails. This is part of the platform device probing stage. This failure means the device is not claimed by the modesetting driver as a 'regular' screen. Instead it is claimed by the

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

Hi, What happens if you remove the fb driver - uninstall the xserver-xorg- video-fbdev package? Also, I'm not sure what (if any) changes have been made in the kernel version you're running - the 'pearl' version - but are you able to try against a mainline kernel? Regards, Daniel -- You

[Touch-packages] [Bug 1458416] [NEW] JIT unnecessarily disabled on ppc64le

Public bug reported: Ubuntu carries 'no_jit_ppc64el.patch' in the debian/patches directory. As the name suggests, this patch disables JIT on ppc64 little-endian. This used to be necessary because JIT was broken on little endian. However, JIT on ppc64 little endian has been supported in pcre3