[Touch-packages] [Bug 1577885] Re: 120sec delay during shutdown or reboot with still mounted cifs (via Wifi)
Confirmed bug with: Description:Ubuntu 18.04.3 LTS Release:18.04 Codename: bionic Thanks to Rahn Stavar (rahnstavar) to showing us an easy fix. ** Attachment added: "Screenshot_2019-08-26_21-58-36.png" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1577885/+attachment/5284860/+files/Screenshot_2019-08-26_21-58-36.png -- 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/1577885 Title: 120sec delay during shutdown or reboot with still mounted cifs (via Wifi) Status in network-manager package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Using Ubuntu 16.04 Desktop with Unity, used the same approach in 14.04 with no issue. I prepare for mounting with the following entry in /etc/fstab my Synology NAS : //192.168.178.61/data /media/server/server_data cifs users,uid=1000,gid=1000,username=x,passwd=xx,iocharset=utf8,sec=ntlm,noauto,_netdev 0 After login to unity, I mount it with a bash-script (mount -a) which is called from ~/.config/autostart/myMounts.desktop Doing this, and shuting down or rebooting lead into a very delayed shutdown (round about 2 minutes) Pressing ESC Key, showed that the process stops at the command "umount /media/server ..." I have not tested if this also occurs when I am connected via ethernet. I think it is because the (Wifi)Network is already disabled prior all umounts are done. This issue happens even if I type in a shutdown command into a Terminal or if I choose shutdown form the menue, also if I use the power-button. Failure can be avoided if I umount the network-drives manually previouse to reboot. Interim solution was, to create an alias for "shutdown" like "sh /path/to/umount/script.sh && shutdown" in /etc/bash.bashrc.local. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1577885/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf
I'm attaching a patch for dhclient-enter-hooks.d/config. I thought to imitate ipconfig and write all values even if they're empty. For the debian/dhclient-script.* scripts which use chmod/chown parameters that aren't available in busybox, it might be best to just omit them, or use `cp/rm` instead of `chown/mv`. `cp` is supposed to preserve target attributes etc, so it'll work in a real system, even if `busybox cp` doesn't do that. ** Patch added: "isc-dhcp.diff" https://bugs.launchpad.net/netplan/+bug/1840965/+attachment/5284861/+files/isc-dhcp.diff ** No longer affects: netplan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1840965 Title: dhclient initramfs code writes invalid net-eth0.conf Status in initramfs-tools package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Triaged Status in initramfs-tools source package in Eoan: New Status in isc-dhcp source package in Eoan: Triaged Bug description: Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is generated, with unquoted values like the following, which are a shell syntax error: IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3 This file is sourced by initramfs-tools/init in various places, and produces the following message a lot of times: /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found I.e. values should be quoted, and 2 DNS entries should go in IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0. Here is the erroneous file that dhclient-enter-hooks.d/config produces: DEVICE=enp0s3 PROTO=dhcp IPV4PROTO=dhcp IPV4ADDR=10.161.254.38 IPV4NETMASK=255.255.255.0 IPV4BROADCAST=10.161.254.255 IPV4GATEWAY=10.161.254.1 IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4 ROOTSERVER=10.161.254.1 HOSTNAME= DNSDOMAIN= Here is the correct one that ipconfig produces: DEVICE='enp0s3' PROTO='dhcp' IPV4ADDR='10.161.254.38' IPV4BROADCAST='10.161.254.255' IPV4NETMASK='255.255.255.0' IPV4GATEWAY='10.161.254.1' IPV4DNS0='194.63.237.4' IPV4DNS1='194.63.239.164' HOSTNAME='' DNSDOMAIN='' NISDOMAIN='' ROOTSERVER='10.161.254.1' ROOTPATH='' filename='' UPTIME='594' DHCPLEASETIME='25200' DOMAINSEARCH='' I.e. please either fix dhclient-enter-hooks.d/config, or revert the ipconfig => dhclient change. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1840965/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841510] [NEW] LONG delay sometimes 10+ minutes when opening file dialogue
Public bug reported: 1) The release of Ubuntu you are using XCFE 4.12 2) The version of the package you are using affects multiple programs including thunderbird and xed thunderbird: Installed: 1:60.8.0+build1-0ubuntu0.16.04.2 xed: Installed: 1.4.6+sonya gthumb: Installed: 3:3.4.3-1 3) What you expected to happen I expect to be able to open a file or save as within a few seconds. 4) What happened instead When I try to open a file or attach a file or save as it can take over 20 minutes. But the really weird thing is sometimes it is nearly instantaneous. So I am writing this as the problem has worsened - using thunderbird - wanted to attach a file - hung for a few minutes - was able to finally attach it Tried with gthumb (great program) to "save as' clicking on the icon to do so - first image was nearly instantaneous and worked fine - second image - took several minutes (is still hung so cannot say how long!) This works not works is a constant finding! it is almost an alternate use of any file dialogues works fast - works very slow - works fast. Very strange and very annoying Other information: some people report that having network resources not yet mounted caused this: - I have several network disks - some mounted, some not - are all in fstab (some are not turned on at the moment) - some are bookmarked in file managers I tried removing these and still had the issue BUT seems to be a longer delay since adding some network disks to fstab I hope this is the correct information - have not reported a bug before. Really appreciate ubuntu and the help you give. Thank you. ** Affects: gtk+3.0 (Ubuntu) Importance: Undecided Status: New ** Tags: dialogue-box save-as -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1841510 Title: LONG delay sometimes 10+ minutes when opening file dialogue Status in gtk+3.0 package in Ubuntu: New Bug description: 1) The release of Ubuntu you are using XCFE 4.12 2) The version of the package you are using affects multiple programs including thunderbird and xed thunderbird: Installed: 1:60.8.0+build1-0ubuntu0.16.04.2 xed: Installed: 1.4.6+sonya gthumb: Installed: 3:3.4.3-1 3) What you expected to happen I expect to be able to open a file or save as within a few seconds. 4) What happened instead When I try to open a file or attach a file or save as it can take over 20 minutes. But the really weird thing is sometimes it is nearly instantaneous. So I am writing this as the problem has worsened - using thunderbird - wanted to attach a file - hung for a few minutes - was able to finally attach it Tried with gthumb (great program) to "save as' clicking on the icon to do so - first image was nearly instantaneous and worked fine - second image - took several minutes (is still hung so cannot say how long!) This works not works is a constant finding! it is almost an alternate use of any file dialogues works fast - works very slow - works fast. Very strange and very annoying Other information: some people report that having network resources not yet mounted caused this: - I have several network disks - some mounted, some not - are all in fstab (some are not turned on at the moment) - some are bookmarked in file managers I tried removing these and still had the issue BUT seems to be a longer delay since adding some network disks to fstab I hope this is the correct information - have not reported a bug before. Really appreciate ubuntu and the help you give. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1841510/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825470] Re: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC)
[Expired for systemd (Ubuntu Eoan) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu Eoan) Status: Incomplete => Expired -- 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/1825470 Title: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC) Status in systemd package in Ubuntu: Expired Status in systemd source package in Bionic: Expired Status in systemd source package in Cosmic: Expired Status in systemd source package in Disco: Expired Status in systemd source package in Eoan: Expired Bug description: Ubuntu 18.04 Bionic Beaver An issue was reported to systemd-networkd on GitHub - https://github.com/systemd/systemd/issues/11650 - and all the thorough details are there. Using anonymous bridges (ie: not attached to physical NICs) is problematic with systemd-networkd as they get deconfigured as soon as the last attached device disconnects (ie: a LXC container). Static IP configuration must be done again manually. The root cause is that systemd-networkd assumes that every network interface have a carrier signal. There's no notion of carrier signal on anonymous bridges, a case not properly handled by systemd-networkd. The systemd dev team provided a patch to address the issue and it would be nice to be integrated on the Ubuntu package. The PR is here : https://github.com/systemd/systemd/commit/93b4dab57e2e13bd804cbee999241be65a443e2e To get the proper fix, you'll need to combine 2 patches : - The one from the PR above - Another patch [1] which fixes a segfault introduced by the PR. [1] https://github.com/systemd/systemd/pull/11741/commits/a294af6810df3c18909a96b556deadba0e2ab0a9 On my test environment, I rebuild the Ubuntu package with the 2 patches above from "237-3ubuntu10.17" to "237-3ubuntu10.20" and made thorough tests without hiting a single issue so I think we can assume that these 2 patches are safe to use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825470] Re: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC)
[Expired for systemd (Ubuntu Bionic) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu Bionic) Status: Incomplete => Expired -- 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/1825470 Title: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC) Status in systemd package in Ubuntu: Expired Status in systemd source package in Bionic: Expired Status in systemd source package in Cosmic: Expired Status in systemd source package in Disco: Expired Status in systemd source package in Eoan: Expired Bug description: Ubuntu 18.04 Bionic Beaver An issue was reported to systemd-networkd on GitHub - https://github.com/systemd/systemd/issues/11650 - and all the thorough details are there. Using anonymous bridges (ie: not attached to physical NICs) is problematic with systemd-networkd as they get deconfigured as soon as the last attached device disconnects (ie: a LXC container). Static IP configuration must be done again manually. The root cause is that systemd-networkd assumes that every network interface have a carrier signal. There's no notion of carrier signal on anonymous bridges, a case not properly handled by systemd-networkd. The systemd dev team provided a patch to address the issue and it would be nice to be integrated on the Ubuntu package. The PR is here : https://github.com/systemd/systemd/commit/93b4dab57e2e13bd804cbee999241be65a443e2e To get the proper fix, you'll need to combine 2 patches : - The one from the PR above - Another patch [1] which fixes a segfault introduced by the PR. [1] https://github.com/systemd/systemd/pull/11741/commits/a294af6810df3c18909a96b556deadba0e2ab0a9 On my test environment, I rebuild the Ubuntu package with the 2 patches above from "237-3ubuntu10.17" to "237-3ubuntu10.20" and made thorough tests without hiting a single issue so I think we can assume that these 2 patches are safe to use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825470] Re: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC)
[Expired for systemd (Ubuntu Cosmic) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu Cosmic) Status: Incomplete => Expired -- 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/1825470 Title: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC) Status in systemd package in Ubuntu: Expired Status in systemd source package in Bionic: Expired Status in systemd source package in Cosmic: Expired Status in systemd source package in Disco: Expired Status in systemd source package in Eoan: Expired Bug description: Ubuntu 18.04 Bionic Beaver An issue was reported to systemd-networkd on GitHub - https://github.com/systemd/systemd/issues/11650 - and all the thorough details are there. Using anonymous bridges (ie: not attached to physical NICs) is problematic with systemd-networkd as they get deconfigured as soon as the last attached device disconnects (ie: a LXC container). Static IP configuration must be done again manually. The root cause is that systemd-networkd assumes that every network interface have a carrier signal. There's no notion of carrier signal on anonymous bridges, a case not properly handled by systemd-networkd. The systemd dev team provided a patch to address the issue and it would be nice to be integrated on the Ubuntu package. The PR is here : https://github.com/systemd/systemd/commit/93b4dab57e2e13bd804cbee999241be65a443e2e To get the proper fix, you'll need to combine 2 patches : - The one from the PR above - Another patch [1] which fixes a segfault introduced by the PR. [1] https://github.com/systemd/systemd/pull/11741/commits/a294af6810df3c18909a96b556deadba0e2ab0a9 On my test environment, I rebuild the Ubuntu package with the 2 patches above from "237-3ubuntu10.17" to "237-3ubuntu10.20" and made thorough tests without hiting a single issue so I think we can assume that these 2 patches are safe to use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1825470] Re: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC)
[Expired for systemd (Ubuntu Disco) because there has been no activity for 60 days.] ** Changed in: systemd (Ubuntu Disco) Status: Incomplete => Expired -- 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/1825470 Title: systemd-networkd: Deconfigures bridge after last attached interface disconnects (ie: LXC) Status in systemd package in Ubuntu: Expired Status in systemd source package in Bionic: Expired Status in systemd source package in Cosmic: Expired Status in systemd source package in Disco: Expired Status in systemd source package in Eoan: Expired Bug description: Ubuntu 18.04 Bionic Beaver An issue was reported to systemd-networkd on GitHub - https://github.com/systemd/systemd/issues/11650 - and all the thorough details are there. Using anonymous bridges (ie: not attached to physical NICs) is problematic with systemd-networkd as they get deconfigured as soon as the last attached device disconnects (ie: a LXC container). Static IP configuration must be done again manually. The root cause is that systemd-networkd assumes that every network interface have a carrier signal. There's no notion of carrier signal on anonymous bridges, a case not properly handled by systemd-networkd. The systemd dev team provided a patch to address the issue and it would be nice to be integrated on the Ubuntu package. The PR is here : https://github.com/systemd/systemd/commit/93b4dab57e2e13bd804cbee999241be65a443e2e To get the proper fix, you'll need to combine 2 patches : - The one from the PR above - Another patch [1] which fixes a segfault introduced by the PR. [1] https://github.com/systemd/systemd/pull/11741/commits/a294af6810df3c18909a96b556deadba0e2ab0a9 On my test environment, I rebuild the Ubuntu package with the 2 patches above from "237-3ubuntu10.17" to "237-3ubuntu10.20" and made thorough tests without hiting a single issue so I think we can assume that these 2 patches are safe to use. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841420] Re: Xorg freeze
Since your kernel log seems to be full of wifi errors, we should exclude that as a possible cause first... [107430.727853] ath: phy0: Failed to wakeup in 500us [107430.949391] ath: phy0: RX failed to go idle in 10 ms RXSM=0x [107430.961321] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x [107435.591709] ath: phy0: Failed to wakeup in 500us [107435.813152] ath: phy0: RX failed to go idle in 10 ms RXSM=0x [107435.825130] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x [107440.711540] ath: phy0: Failed to wakeup in 500us [107440.933340] ath: phy0: RX failed to go idle in 10 ms RXSM=0x [107440.945388] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x AR_DIAG_SW=0x DMADBG_7=0x Please try disabling wifi and then run this command to ensure the errors are no longer occurring: dmesg -w Once confirmed the wifi errors have stopped, do you still see graphics freezes? ** Package changed: xorg (Ubuntu) => xorg-server (Ubuntu) ** Changed in: xorg-server (Ubuntu) Status: New => Incomplete ** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Incomplete -- 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/1841420 Title: Xorg freeze Status in linux package in Ubuntu: Incomplete Status in xorg-server package in Ubuntu: Incomplete Bug description: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.213:bd06/26/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1841420/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived clusters
The aforementioned link shows there's been work towards a fix in
systemd. Can't say if that suggests what can be done to improve
keepalived, but I've tagged this "server-next" to get it on the Ubuntu
SErver Team's high priority list, as per Robie's earlier comment.
** Tags added: server-next
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived clusters
Status in netplan:
Invalid
Status in keepalived package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
valid_lft forever preferred_lft forever
inet 10.22.11.13/24 scope global secondary eth3
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:feb0:2629/64 scope link
valid_lft forever preferred_lft forever
9: eth2: mtu 1500 qdisc
[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time
This bug was fixed in the package systemd - 240-6ubuntu13 --- systemd (240-6ubuntu13) eoan; urgency=medium * Drop s390x seccomp fix causing regression on s390x Files: - debian/patches/src-shared-seccomp-util.c-Add-mmap-definitions-for-s390.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=da95e1d022e94a4d3ce0b69bd6eb398c95d09f24 -- Balint Reczey Mon, 26 Aug 2019 17:02:54 +0200 ** Changed in: systemd (Ubuntu Eoan) Status: Fix Committed => 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/1668771 Title: [SRU] systemd-resolved negative caching for extended period of time Status in systemd: New Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Impact] * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the result for very long (infinity?). I have to restart systemd- resolved to have the negative caching purged. * After SERVFAIL DNS server issue has been resolved, chromium/firefox still returns DNS error despite host can correctly resolve the name. [Test Case] * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s (See 201d995), however, there are several use cases on which this condition is not acceptable (See #5552 comments) and the only workaround would be to disable cache entirely or flush it , which isn't optimal. * Configure /etc/systemd/resolved.conf as follows: Cache=yes (default) * Restart systemd-resolved (systemctl restart systemd- resolved.service) * Run a host/getent command against a entry that will return SERVFAIL and check the journalctl output to see that the reply gets served from cache. root@systemd-disco:/home/ubuntu# host www.no-record.cl Host www.montemar.cl not found: 2(SERVFAIL) root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 UTC. -- Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for on scope dns on ens3/* now complete with Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet with id 61042 on interface 1/AF_INET. Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 6222. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query packet for id 53580 Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for www.no-record.cl IN A. Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache hit for www.no-record.cl IN A Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < www.no-record.cl IN A> on scope dns on ens3/* now complete with scope dns on ens3/. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP for transaction 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet with id 22382. Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming packet on transaction 22382 (rcode=SERVFAIL). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: SERVFAIL Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative entry for: www.metaklass.org IN A, cache mode set to no-negative Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for on scope dns on ens3/ now complete with from network (unsigned). Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet with id 31060 on interface 1/AF_INET. The following patch https://github.com/systemd/systemd/pull/13047 implements the required changes. [Other Info] Note that systemd in Eoan is being upgraded to upstream 242, so I am not adding this to Eoan now, as I don't want to disturb the merge. If needed after the merge, I'll add to Eoan. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1668771/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes
This bug was fixed in the package systemd - 240-6ubuntu13 --- systemd (240-6ubuntu13) eoan; urgency=medium * Drop s390x seccomp fix causing regression on s390x Files: - debian/patches/src-shared-seccomp-util.c-Add-mmap-definitions-for-s390.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=da95e1d022e94a4d3ce0b69bd6eb398c95d09f24 -- Balint Reczey Mon, 26 Aug 2019 17:02:54 +0200 ** Changed in: systemd (Ubuntu Eoan) Status: Fix Committed => 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/1835581 Title: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Released Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [impact] the systemd networkd dhcp4 client sets the prefsrc for the default route added when a dhcp server provides only the gateway; but if the dhcp server provides classless route(s), those are configured instead, and the prefsrc is not set for those. Normally this is ok, but if the dhcp client system has other address(es) configured on the interface using dhcp, then the src for packets sent through a classless/static route might not be the same as the address provided by the dhcp server. If the gateway/router provided in the dhcp classless/static route(s) only allows traffic from the address provided to the dhcp client, then traffic from the dhcp client may be dropped by the gateway/router. [test case] set up a dhcp server system (e.g. ubuntu with dnsmasq installed and configured) and a dhcp client system. For example on the dhcp server, use this dnsmasq config: interface=ens8 bind-interfaces domain=test,10.10.0.0/24 dhcp-option=42,10.10.0.1 dhcp-range=test,10.10.0.10,10.10.0.100,1h On the dhcp client system, use networkd config such as: $ cat /etc/systemd/network/80-ens8.network [Match] Name=ens8 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 Address=10.10.0.5/24 Reboot the client, or restart networkd, and it should result in: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3580sec preferred_lft 3580sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024 Note that, because networkd completes the static ip configuration before the dhcp reply is returned and processed, the static address is used for the subnet-local routing. But for global routing through the gateway, the dhcp-provided address is used: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000 Now on the server, add a classless route: dhcp-option=121,0.0.0.0/0,10.10.0.1 and restart dnsmasq on the server. Then on the client, reboot. It should now have: $ ip -4 a show ens8 3: ens8: mtu 1500 qdisc fq_codel state UP group default qlen 1000 inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8 valid_lft forever preferred_lft forever inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8 valid_lft 3585sec preferred_lft 3585sec $ ip r default via 10.10.0.1 dev ens8 proto dhcp metric 1024 10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5 Now, the global route will use the static address, not the dhcp- provided address: $ ip r get 1.1.1.1 1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000 If the router, 10.10.0.1, only will forward traffic sent from the dhcp address it provided, 10.10.0.75, then this configuration will result in the client being unable to reach anything through the router, because all its packets will have a source address of 10.10.0.5, which the router would drop/reject. [regression potential] this only affects dhcp routes provided by a dhcp server using the 'static' or 'classless' route dhcp options. Since this behavior is currently the default when a system doesn't add static address(es) to interfaces that also get dhcp addresses, this is likely not a change in behavior for the vast majority of systems. And any systems that do add static address(es) would usually be able to route through a gateway from either the dhcp-provided, or static, address. So the regression potential for this
[Touch-packages] [Bug 1837700] Re: Dell system takes a long time to connect network with external dock
This bug was fixed in the package systemd - 240-6ubuntu13 --- systemd (240-6ubuntu13) eoan; urgency=medium * Drop s390x seccomp fix causing regression on s390x Files: - debian/patches/src-shared-seccomp-util.c-Add-mmap-definitions-for-s390.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=da95e1d022e94a4d3ce0b69bd6eb398c95d09f24 -- Balint Reczey Mon, 26 Aug 2019 17:02:54 +0200 ** Changed in: systemd (Ubuntu Eoan) Status: Fix Committed => 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/1837700 Title: Dell system takes a long time to connect network with external dock Status in HWE Next: New Status in OEM Priority Project: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Released Bug description: update for SRU process: [Impact] 1. On system featured mac passthrough, e.g., Dell/Lenovo laptop, or system occasionally install two USB ethernet with same MAC address, the system will suffer 90 seconds for network interface renaming mechanism before the last USB ethernet interface to activate. [Test Case] 1. Install ubuntu on Dell laptop. 2. Connect the Dell laptop with two Realtek 8153 USB ethernet dongle. Users can observe the last one will take 90 seconds for renaming to rename0. 3. Users can also find that the two USB ethernet have the same MAC address. [Regression Potential] To resolve the issue, drop a debian patch from systemd package. The debian patch is to revert an upstream commit to support 75-persistent-net-generator.rules udev rule. Since the udev rule is deprecated, the regression potential should be relatively low. --- Dell has a feature called MAC addrss passthrough[1] that would force usb ethernet adapters to be assigned with a predefined MAC address stored in BIOS or so. This feature has been landed to mainline kernel in driver r8152[2]. So whenever a r8152 managed device is plugged into Dell devices with MAC addrss passthrough enabled, this driver will set NIC MAC to a predefined one. And some Dell devices have already one built-in r8152 NIC port. On these devices, when a second r8152 NIC is plugged in, a Debian originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev built-in command `net_id` to give a persistent name, and that will be based on MAC address. However, since the system has already initialized the built-in r8152 NIC with that name, renaming the second interface with this name will always fail. While Debian still carries a patch called "Revert-udev-network-device- renaming-immediately-give.patch"[4] that tries to keep support of already deprecated "75-persistent-net-generator.rules" based interface renaming mechanism, this patch also propagated into Ubuntu[5]. This patch will retry renaming with a 90 seconds timeout when the error code is -EEXIST, so the uevent processing will always be blocked in the last ifrename step in the victim system. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules lib/udev/rules.d/50-udev-default.rules lib/udev/rules.d/73-special-net-names.rules lib/udev/rules.d/73-usb-net-by-mac.rules] ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18 Uname: Linux 4.15.0-1043-oem x86_64 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules Date: Wed Jul 24 15:30:59 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90 InstallationDate: Installed on 2019-07-03 (20 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 MachineType: Dell Inc. Latitude 7424 Rugged Extreme ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M vt.handoff=1 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/27/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0Y7FK3 dmi.board.vendor: Dell Inc. dmi.board.version: X03 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias:
[Touch-packages] [Bug 1835809] Re: AMD Ryzen 3000 series fails to boot
This bug was fixed in the package systemd - 240-6ubuntu13 --- systemd (240-6ubuntu13) eoan; urgency=medium * Drop s390x seccomp fix causing regression on s390x Files: - debian/patches/src-shared-seccomp-util.c-Add-mmap-definitions-for-s390.patch https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=da95e1d022e94a4d3ce0b69bd6eb398c95d09f24 -- Balint Reczey Mon, 26 Aug 2019 17:02:54 +0200 ** Changed in: systemd (Ubuntu Eoan) Status: Fix Committed => 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/1835809 Title: AMD Ryzen 3000 series fails to boot Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Impact] * Systems with AMD Ryzen 3000 series CPUs don't boot. [Test Case] * Boot with fixed systemd on an AMD Ryzen 3000 series system. [Regression Potential] * The fix itself is very small, it ignores known to be faulty random values returned by the rdrand instruction and use a different random source. Those values can still be returned by a properly working rdrand implementation in 2 in 2^32 cases on 32 bit arches and in 2 in 2^64 cases on 64 bit arches, but the fallback to the other random source ensures that in those rare occasions a random number can be generated. [Original Bug Text] On the new AMD Ryzen 3000 series CPUs, there is an issue with systemd preventing the boot process from completing. This issue does not affect the older systemd version in 18.04, but affects the 19.04 version. Here is a screenshot showing what happens: https://www.phoronix.net/image.php?id=ryzen-3700x-3900x-linux=amd_zen2_14_show I am currently testing a patch to systemd, derived from this pull request: https://github.com/systemd/systemd/pull/12536 This is a high severity issue, as I do not believe there is no potential workaround without either a firmware update or an ISO respin. I have attached a rebase of the potential patch on the current 19.04 version of systemd for reference. I will provide more details after testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
This bug was fixed in the package iptables - 1.8.3-2ubuntu2 --- iptables (1.8.3-2ubuntu2) eoan; urgency=medium * d/p/lp-1840633-nft-exit-in-case-we-can-t-fetch-current-genid.patch: avoid busy loop if cache can't be created (LP: #1840633) -- Christian Ehrhardt Wed, 21 Aug 2019 14:04:49 +0200 ** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Fix Released Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1759836] Re: systemd-udevd consumes 100% of CPU
Lenovo T510 with 4.18.0-25 is also effected, this strangely almost freezes the GUI, despite that systemd-udevd only occupies one core -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1759836 Title: systemd-udevd consumes 100% of CPU Status in linux: Confirmed Status in The Ubuntu Power Consumption Project: New Status in bluez package in Ubuntu: Invalid Status in linux package in Ubuntu: Incomplete Status in systemd package in Ubuntu: Confirmed Status in bluez package in Debian: Unknown Bug description: The systemd-udevd proccess consumes 100% of a thread everytime, but i'm not noticing any difference in my computer. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu6 ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10 Uname: Linux 4.15.0-13-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.9-0ubuntu2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Mar 29 08:52:54 2018 InstallationDate: Installed on 2018-03-05 (23 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180304) MachineType: Dell Inc. Inspiron N5010 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-13-generic root=UUID=3c29e292-f1ae-45e1-a0ed-a82524278ce1 ro quiet splash vt.handoff=1 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/25/2011 dmi.bios.vendor: Dell Inc. dmi.bios.version: A12 dmi.board.name: 08R0GW dmi.board.vendor: Dell Inc. dmi.board.version: A12 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: A12 dmi.modalias: dmi:bvnDellInc.:bvrA12:bd01/25/2011:svnDellInc.:pnInspironN5010:pvrA12:rvnDellInc.:rn08R0GW:rvrA12:cvnDellInc.:ct8:cvrA12: dmi.product.name: Inspiron N5010 dmi.product.version: A12 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/kernel/+bug/1759836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf
** Changed in: isc-dhcp (Ubuntu) Status: New => Triaged ** Changed in: isc-dhcp (Ubuntu) Importance: Undecided => High ** Also affects: initramfs-tools (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Eoan) Importance: High Status: Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1840965 Title: dhclient initramfs code writes invalid net-eth0.conf Status in netplan: New Status in initramfs-tools package in Ubuntu: New Status in isc-dhcp package in Ubuntu: Triaged Status in initramfs-tools source package in Eoan: New Status in isc-dhcp source package in Eoan: Triaged Bug description: Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is generated, with unquoted values like the following, which are a shell syntax error: IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3 This file is sourced by initramfs-tools/init in various places, and produces the following message a lot of times: /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found I.e. values should be quoted, and 2 DNS entries should go in IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0. Here is the erroneous file that dhclient-enter-hooks.d/config produces: DEVICE=enp0s3 PROTO=dhcp IPV4PROTO=dhcp IPV4ADDR=10.161.254.38 IPV4NETMASK=255.255.255.0 IPV4BROADCAST=10.161.254.255 IPV4GATEWAY=10.161.254.1 IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4 ROOTSERVER=10.161.254.1 HOSTNAME= DNSDOMAIN= Here is the correct one that ipconfig produces: DEVICE='enp0s3' PROTO='dhcp' IPV4ADDR='10.161.254.38' IPV4BROADCAST='10.161.254.255' IPV4NETMASK='255.255.255.0' IPV4GATEWAY='10.161.254.1' IPV4DNS0='194.63.237.4' IPV4DNS1='194.63.239.164' HOSTNAME='' DNSDOMAIN='' NISDOMAIN='' ROOTSERVER='10.161.254.1' ROOTPATH='' filename='' UPTIME='594' DHCPLEASETIME='25200' DOMAINSEARCH='' I.e. please either fix dhclient-enter-hooks.d/config, or revert the ipconfig => dhclient change. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1840965/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
I installed the package available in bionic-proposed as you can see
below:
root@openldap-bionic-sru:~# apt policy slapd
slapd:
Installed: 2.4.45+dfsg-1ubuntu1.4
Candidate: 2.4.45+dfsg-1ubuntu1.4
Version table:
*** 2.4.45+dfsg-1ubuntu1.4 500
500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
100 /var/lib/dpkg/status
2.4.45+dfsg-1ubuntu1.3 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu bionic-security/main amd64
Packages
2.4.45+dfsg-1ubuntu1 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
And after executing the steps presented in the Test case section, the
slapd process did not die:
root@openldap-bionic-sru:~# ps aux | grep slapd
openldap 1029 0.0 4.5 2106104 730124 ? Ssl 18:51 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 1488 0.0 0.0 14852 840 ?S+ 18:52 0:00 grep
--color=auto slapd
root@openldap-bionic-sru:~# ldapsearch -x -h localhost -b dc=example,dc=com
-LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
root@openldap-bionic-sru:~# ps aux | grep slapd
openldap 1029 0.0 4.5 2106104 730124 ? Ssl 18:51 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 1492 0.0 0.0 14852 804 ?S+ 18:52 0:00 grep
--color=auto slapd
The PID of the slapd process is the same. Moreover, there is no sign of
crash in the syslog output nor a crash file in /var/crash:
root@openldap-bionic-sru:~# cat /var/log/syslog | grep filter_free
root@openldap-bionic-sru:~# ls /var/crash/ | grep slapd
** Tags removed: verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370
Title:
slapd segfault on filter parse error
Status in openldap:
Fix Released
Status in openldap package in Ubuntu:
Fix Released
Status in openldap source package in Xenial:
Fix Committed
Status in openldap source package in Bionic:
Fix Committed
Status in openldap source package in Disco:
Fix Committed
Status in openldap package in Debian:
Unknown
Bug description:
[Impact]
Users willing to use the slapd rwm overlay will face a slapd
segmentation fault when trying to rewrite some rules. Backporting this
fix will allow users using stable releases to take advantage of this
feature without crashing slapd. This issue was fixed by upstream not
freeing the rwm overlay filter memory without prior checking.
[Test Case]
In this test case, the rwm overlay will be used and a rule will be
created to deny any search request for uid=root, then the 'ldapsearch'
will be invoked to trigger the failure. It is important to mention
that the 'ldapsearch' command should fail regardless the presence of
the bug in the package, the target here is the slapd crash. To
reproduce this bug one can follow the procedure below in Ubuntu
xenial, bionic or disco:
$ sudo apt-get update
Use debconf to pre-seed slapd questions before install it:
$ debconf-set-selections << EOF
slapd slapd/no_configuration boolean false
slapd slapd/domain string example.com
slapd shared/organization string example.com
slapd slapd/password1 password test
slapd slapd/password2 password test
slapd slapd/backend select MDB
slapd slapd/move_old_database boolean false
EOF
$ sudo apt-get install slapd ldap-utils -y
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
slapd process will die, and /var/crash will have a crash file for
slapd. You can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter
type=28530
-> Expected behavior
In this test case, as mentioned before, the 'ldapsearch' command
should fail but the 'slapd' process should not die. As result, we
don't expect a slapd crash report in /var/crash directory.
[Regression Potential]
Since the fix
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
I installed the package available in disco-proposed as you can see
below:
root@openldap-disco-sru:~# apt policy slapd
slapd:
Installed: 2.4.47+dfsg-3ubuntu2.2
Candidate: 2.4.47+dfsg-3ubuntu2.2
Version table:
*** 2.4.47+dfsg-3ubuntu2.2 500
500 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 Packages
100 /var/lib/dpkg/status
2.4.47+dfsg-3ubuntu2.1 500
500 http://archive.ubuntu.com/ubuntu disco-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu disco-security/main amd64 Packages
2.4.47+dfsg-3ubuntu2 500
500 http://archive.ubuntu.com/ubuntu disco/main amd64 Packages
And after executing the steps presented in the Test case section, the
slapd process did not die:
root@openldap-disco-sru:~# ps aux | grep slapd
openldap 1994 0.0 4.5 2003840 728176 ? Ssl 19:05 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 2453 0.0 0.0 7980 1544 ?S+ 19:06 0:00 grep
--color=auto slapd
root@openldap-disco-sru:~# ldapsearch -x -h localhost -b dc=example,dc=com -LLL
uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
root@openldap-disco-sru:~# ps aux | grep slapd
openldap 1994 0.0 4.5 2003840 728176 ? Ssl 19:05 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 2457 0.0 0.0 7980 684 ?S+ 19:06 0:00 grep
--color=auto slapd
The PID of the slapd process is the same. Moreover, there is no sign of
crash in the syslog output nor a crash file in /var/crash:
root@openldap-disco-sru:~# cat /var/log/syslog | grep filter_free
root@openldap-disco-sru:~# ls /var/crash/ | grep slapd
** Tags removed: verification-needed-disco
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370
Title:
slapd segfault on filter parse error
Status in openldap:
Fix Released
Status in openldap package in Ubuntu:
Fix Released
Status in openldap source package in Xenial:
Fix Committed
Status in openldap source package in Bionic:
Fix Committed
Status in openldap source package in Disco:
Fix Committed
Status in openldap package in Debian:
Unknown
Bug description:
[Impact]
Users willing to use the slapd rwm overlay will face a slapd
segmentation fault when trying to rewrite some rules. Backporting this
fix will allow users using stable releases to take advantage of this
feature without crashing slapd. This issue was fixed by upstream not
freeing the rwm overlay filter memory without prior checking.
[Test Case]
In this test case, the rwm overlay will be used and a rule will be
created to deny any search request for uid=root, then the 'ldapsearch'
will be invoked to trigger the failure. It is important to mention
that the 'ldapsearch' command should fail regardless the presence of
the bug in the package, the target here is the slapd crash. To
reproduce this bug one can follow the procedure below in Ubuntu
xenial, bionic or disco:
$ sudo apt-get update
Use debconf to pre-seed slapd questions before install it:
$ debconf-set-selections << EOF
slapd slapd/no_configuration boolean false
slapd slapd/domain string example.com
slapd shared/organization string example.com
slapd slapd/password1 password test
slapd slapd/password2 password test
slapd slapd/backend select MDB
slapd slapd/move_old_database boolean false
EOF
$ sudo apt-get install slapd ldap-utils -y
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
slapd process will die, and /var/crash will have a crash file for
slapd. You can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter
type=28530
-> Expected behavior
In this test case, as mentioned before, the 'ldapsearch' command
should fail but the 'slapd' process should not die. As result, we
don't expect a slapd crash report in /var/crash directory.
[Regression Potential]
Since the fix is a patch
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
I installed the package available in xenial-proposed as you can see
below:
root@openldap-xenial-sru:~# apt policy slapd
slapd:
Installed: 2.4.42+dfsg-2ubuntu3.7
Candidate: 2.4.42+dfsg-2ubuntu3.7
Version table:
*** 2.4.42+dfsg-2ubuntu3.7 500
500 http://archive.ubuntu.com/ubuntu xenial-proposed/main amd64 Packages
100 /var/lib/dpkg/status
2.4.42+dfsg-2ubuntu3.6 500
500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu xenial-security/main amd64
Packages
2.4.42+dfsg-2ubuntu3 500
500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
And after executing the steps presented in the Test case section, the slapd
process did not die:
root@openldap-xenial-sru:~# ps aux | grep slapd
openldap 2078 0.0 4.5 2094540 730664 ? Ssl 19:02 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 2147 0.0 0.0 14616 904 ?S+ 19:03 0:00 grep
--color=auto slapd
root@openldap-xenial-sru:~# ldapsearch -x -h localhost -b dc=example,dc=com
-LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
root@openldap-xenial-sru:~# ps aux | grep slapd
openldap 2078 0.0 4.5 2094540 730576 ? Ssl 19:02 0:00
/usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F
/etc/ldap/slapd.d
root 2151 0.0 0.0 14616 860 ?S+ 19:03 0:00 grep
--color=auto slapd
The PID of the slapd process is the same. Moreover, there is no sign of crash in
the syslog output nor a crash file in /var/crash:
root@openldap-xenial-sru:~# cat /var/log/syslog | grep filter_free
root@openldap-xenial-sru:~# ls /var/crash/ | grep slapd
** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done-bionic verification-done-disco
verification-done-xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370
Title:
slapd segfault on filter parse error
Status in openldap:
Fix Released
Status in openldap package in Ubuntu:
Fix Released
Status in openldap source package in Xenial:
Fix Committed
Status in openldap source package in Bionic:
Fix Committed
Status in openldap source package in Disco:
Fix Committed
Status in openldap package in Debian:
Unknown
Bug description:
[Impact]
Users willing to use the slapd rwm overlay will face a slapd
segmentation fault when trying to rewrite some rules. Backporting this
fix will allow users using stable releases to take advantage of this
feature without crashing slapd. This issue was fixed by upstream not
freeing the rwm overlay filter memory without prior checking.
[Test Case]
In this test case, the rwm overlay will be used and a rule will be
created to deny any search request for uid=root, then the 'ldapsearch'
will be invoked to trigger the failure. It is important to mention
that the 'ldapsearch' command should fail regardless the presence of
the bug in the package, the target here is the slapd crash. To
reproduce this bug one can follow the procedure below in Ubuntu
xenial, bionic or disco:
$ sudo apt-get update
Use debconf to pre-seed slapd questions before install it:
$ debconf-set-selections << EOF
slapd slapd/no_configuration boolean false
slapd slapd/domain string example.com
slapd shared/organization string example.com
slapd slapd/password1 password test
slapd slapd/password2 password test
slapd slapd/backend select MDB
slapd slapd/move_old_database boolean false
EOF
$ sudo apt-get install slapd ldap-utils -y
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
slapd process will die, and /var/crash will have a crash file for
slapd. You can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter
type=28530
-> Expected behavior
In this test case, as mentioned before, the 'ldapsearch' command
should fail but the 'slapd' process should not die. As
[Touch-packages] [Bug 1837170] Re: Kodi package crash after the update of libdrm-amdgpu1
Using Kodi as reference for the behaviour of VDPAU hw acceleration on the system: The latest version of mesa doesn't work and makes Kodi crash when opening any video. I figured that when I downgrade every package of mesa to version 18.2.8, kodi is now able to run videos, but still without vdpau. The behaviour improved, but without hw acceleration. https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging I meant that when I upgrade mesa with this package, I encounter the same behaviour of the version 18.2.8 I downgraded. Using Oibaf's ppa is the only to get vdpau acceleration working, but the image is too dark, it doesn't have the bells and whistles specifically optimized for Ubuntu. I wrote earlier that I tested disco with success, vdpau runs well and nothing's necessary to add. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837170 Title: Kodi package crash after the update of libdrm-amdgpu1 Status in mesa package in Ubuntu: Incomplete Bug description: Greetings, The last update of libdrm-amdgpu1 caused a bug on Kodi package, making it to crash after loading any video or reproduce a black image. Version: 2.4.97-1ubuntu1~18.04.12019-07-03 15:07:54 UTC libdrm (2.4.97-1ubuntu1~18.04.1) bionic; urgency=medium * Backport to bionic for 18.04.3 HWE stack update. (LP: #1824111) -- Timo Aaltonen Wed, 10 Apr 2019 13:54:06 +0300 Kodi gives this error: #3 0x7f47676c60aa in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7f47676c5dd7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Repeated several times #3 0x7f475ce2c5a6 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 #4 0x7f475ce2c425 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 Team-Kodi stated these errors are in relation to 'Not supported GPU drivers', when Kodi can't find these files. I've found the cause, and a temporary solution: This bug was caused after an update for the latest version of libdrm- amdgpu1 2.4.97-1ubuntu1~18.04.1 So I grabbed the previous version from https://mirror.transip.net/ubuntu/ubuntu/pool/main/libd/libdrm/ installed libdrm-amdgpu1_2.4.95-1~18.04.1_amd64.deb and now Kodi returns. I created a bug report, the problem affects multiple users. https://bugs.launchpad.net/ubuntu/+source/kodi/+bug/1836828 We have a PointRelease coming soon, would we have time to fix this package? Thank you for your assistance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1837170/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840965] Re: netplan initramfs code writes invalid net-eth0.conf
The code that generates the invalid /run/net-enp0s3.conf belongs in the Ubuntu isc-dhcp package, and specifically in debian/initramfs- tools/lib/etc/dhcp/dhclient-enter-hooks.d/config. It got in effect in 18.10 when initramfs-tools in Ubuntu switched to calling dhclient instead of ipconfig. Additionally, dhclient-script calls `chmod --reference=/etc/resolv.conf $new_resolv_conf`, but busybox chmod doesn't support the --reference parameter. I.e. dhclient has numerous issues that need to be fixed, otherwise the ipconfig => dhclient change should be reverted... Thank you. ** Also affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New ** Description changed: - While netbooting, in initramfs-tools/scripts/functions, netplan for some - reason tries to overwrite /run/net-enp0s3.conf that is initially and - correctly generated by ipconfig. - - There, it writes unquoted values like the following, which are a shell syntax error: + Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is generated, with unquoted values like the following, which are a shell syntax error: IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3 - Then, initramfs-tools/init tries to source that in various places, and produces the following message a lot of times: + This file is sourced by initramfs-tools/init in various places, and produces the following message a lot of times: /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found I.e. values should be quoted, and 2 DNS entries should go in IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0. - Here is the erroneous file that netplan produces: + Here is the erroneous file that dhclient-enter-hooks.d/config produces: DEVICE=enp0s3 PROTO=dhcp IPV4PROTO=dhcp IPV4ADDR=10.161.254.38 IPV4NETMASK=255.255.255.0 IPV4BROADCAST=10.161.254.255 IPV4GATEWAY=10.161.254.1 IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4 ROOTSERVER=10.161.254.1 HOSTNAME= DNSDOMAIN= - Here is the correct one that ipconfig initially produces, before getting overwritten: + Here is the correct one that ipconfig produces: DEVICE='enp0s3' PROTO='dhcp' IPV4ADDR='10.161.254.38' IPV4BROADCAST='10.161.254.255' IPV4NETMASK='255.255.255.0' IPV4GATEWAY='10.161.254.1' IPV4DNS0='194.63.237.4' IPV4DNS1='194.63.239.164' HOSTNAME='' DNSDOMAIN='' NISDOMAIN='' ROOTSERVER='10.161.254.1' ROOTPATH='' filename='' UPTIME='594' DHCPLEASETIME='25200' DOMAINSEARCH='' - Thank you. + I.e. please either fix dhclient-enter-hooks.d/config, or revert the + ipconfig => dhclient change. ** Summary changed: - netplan initramfs code writes invalid net-eth0.conf + dhclient initramfs code writes invalid net-eth0.conf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1840965 Title: dhclient initramfs code writes invalid net-eth0.conf Status in netplan: New Status in initramfs-tools package in Ubuntu: New Status in isc-dhcp package in Ubuntu: New Bug description: Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is generated, with unquoted values like the following, which are a shell syntax error: IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3 This file is sourced by initramfs-tools/init in various places, and produces the following message a lot of times: /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found I.e. values should be quoted, and 2 DNS entries should go in IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0. Here is the erroneous file that dhclient-enter-hooks.d/config produces: DEVICE=enp0s3 PROTO=dhcp IPV4PROTO=dhcp IPV4ADDR=10.161.254.38 IPV4NETMASK=255.255.255.0 IPV4BROADCAST=10.161.254.255 IPV4GATEWAY=10.161.254.1 IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4 ROOTSERVER=10.161.254.1 HOSTNAME= DNSDOMAIN= Here is the correct one that ipconfig produces: DEVICE='enp0s3' PROTO='dhcp' IPV4ADDR='10.161.254.38' IPV4BROADCAST='10.161.254.255' IPV4NETMASK='255.255.255.0' IPV4GATEWAY='10.161.254.1' IPV4DNS0='194.63.237.4' IPV4DNS1='194.63.239.164' HOSTNAME='' DNSDOMAIN='' NISDOMAIN='' ROOTSERVER='10.161.254.1' ROOTPATH='' filename='' UPTIME='594' DHCPLEASETIME='25200' DOMAINSEARCH='' I.e. please either fix dhclient-enter-hooks.d/config, or revert the ipconfig => dhclient change. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1840965/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841378] Re: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces
The attachment "nspawn-fix.diff" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.] ** Tags added: patch -- 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/1841378 Title: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces Status in systemd package in Ubuntu: New Bug description: I have machine with the following nspawn file: -- [Network] MACVLAN=laneth0 [Exec] PrivateUsers=false -- if I start it with systemctl start systemd-nspawn@name, all works as expected. If I start manually with systemd-nspawn -M name -b, I seem to correctly get a new network namespace (ip link output in container is correct), but ls /sys/class/net shows the host's interfaces. The difference turns out to be that starting with systemctl uses a default command line which includes --private-network; the MACVLAN= in the config file should imply this, but instead it seems I'm getting "half" a private network, with the namespace correctly set but /sys not. Having a quick poke around, I suspect https://github.com/systemd/systemd/commit/60f1ec13ed059e412c2a2ee4cc3093e2d520673c may have 'accidentally' fixed this - it moves if (arg_private_network) arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; from parse_argv to verify_arguments which is called later. This bug causes netplan to fail as well as it rummages around in /sys/class/net. If the planets ever align appropriately, I will try to come up with a patch to 237 for bionic, but I don't recommend anyone holds their breath.. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.25 Uname: Linux 4.19.13-041913-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 25 17:54:50 2019 InstallationDate: Installed on 2018-03-22 (521 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841378/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841378] Re: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces
The "obvious fix" (attached) does indeed solve the problem - haven't done enough testing as of yet to be sure there are no weird consequences. ** Description changed: I have machine with the following nspawn file: -- [Network] MACVLAN=laneth0 [Exec] PrivateUsers=false -- if I start it with systemctl start systemd-nspawn@name, all works as expected. If I start manually with systemd-nspawn -M name -b, I seem to correctly get a new network namespace (ip link output in container is correct), but ls /sys/class/net shows the host's interfaces. The difference turns out to be that starting with systemctl uses a default command line which includes --private-network; the MACVLAN= in the config file should imply this, but instead it seems I'm getting "half" a private network, with the namespace correctly set but /sys not. Having a quick poke around, I suspect https://github.com/systemd/systemd/commit/60f1ec13ed059e412c2a2ee4cc3093e2d520673c may have 'accidentally' fixed this - it moves -if (arg_private_network) - arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; + if (arg_private_network) + arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; from parse_argv to verify_arguments which is called later. This bug causes netplan to fail as well as it rummages around in /sys/class/net. If the planets ever align appropriately, I will try to come up with a - patch to 237 for bionic, but I don't recommend anyone hold's their + patch to 237 for bionic, but I don't recommend anyone holds their breath.. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.25 Uname: Linux 4.19.13-041913-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 25 17:54:50 2019 InstallationDate: Installed on 2018-03-22 (521 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) ** Patch added: "nspawn-fix.diff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841378/+attachment/5284741/+files/nspawn-fix.diff -- 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/1841378 Title: MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces Status in systemd package in Ubuntu: New Bug description: I have machine with the following nspawn file: -- [Network] MACVLAN=laneth0 [Exec] PrivateUsers=false -- if I start it with systemctl start systemd-nspawn@name, all works as expected. If I start manually with systemd-nspawn -M name -b, I seem to correctly get a new network namespace (ip link output in container is correct), but ls /sys/class/net shows the host's interfaces. The difference turns out to be that starting with systemctl uses a default command line which includes --private-network; the MACVLAN= in the config file should imply this, but instead it seems I'm getting "half" a private network, with the namespace correctly set but /sys not. Having a quick poke around, I suspect https://github.com/systemd/systemd/commit/60f1ec13ed059e412c2a2ee4cc3093e2d520673c may have 'accidentally' fixed this - it moves if (arg_private_network) arg_mount_settings |= MOUNT_APPLY_APIVFS_NETNS; from parse_argv to verify_arguments which is called later. This bug causes netplan to fail as well as it rummages around in /sys/class/net. If the planets ever align appropriately, I will try to come up with a patch to 237 for bionic, but I don't recommend anyone holds their breath.. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd-container 237-3ubuntu10.25 Uname: Linux 4.19.13-041913-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: XFCE Date: Sun Aug 25 17:54:50 2019 InstallationDate: Installed on 2018-03-22 (521 days ago) InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180306.1) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841378/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
If there is a race, or a need to wait, it almost certainly is in cloud- utils (growpart). If you use growpart to grow a partition, the result should be that that is done, and it is ready. The caller should not expect that they have to know additional information (to call 'udevadm settle') or should have to wait some amount of time. -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
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 and there is no significant delay either. > > So conversely, if I put a loop into cloud-init and just waited on the > symlink to appear and if that worked with minimal delay, would that > refute the above? > That's still a workaround for something we don't exactly know why is racing nor why this isn't more widespread. The code in cloud-init and growpart, sgdisk and partx are stable (the code has not changed significantly much in some time). We don't have root cause for the race at this time. When cloud-init invokes growpart the symlink exists, and when growpart returns sometimes it does not. If anything growpart should address the race itself; and at this point, it would have to pickup a workaround as well. Let's at least make sure we understand the actual race before we look further into workarounds. >From what I can see in what growpart is doing, the sgdisk command will clear the partition tables (this involves removing the partition and then re-adding it, which triggers udev. Further, Dan's show that partx --update can also trigger a remove and an add. Looking at the partx update code; *sometimes* it will remove and add, however, if the partition to be updated *exists* then it will instead issue an update IOCTL which only updates the size value in sysfs. https://github.com/karelzak/util- linux/blob/53ae7d60cfeacd4e87bfe6fcc015b58b78ef4555/disk- utils/partx.c#L451 Which makes me think that in the successful path, we're seeing partx --update take the partx_resize_partition path, which submits the resize IOCTL https://github.com/karelzak/util- linux/blob/917f53cf13c36d32c175f80f2074576595830573/include/partx.h#L54 which in linux kernel does: https://elixir.bootlin.com/linux/latest/source/block/ioctl.c#L100 and just updates the size value in sysfs: https://elixir.bootlin.com/linux/latest/source/block/ioctl.c#L146 which AFAICT does not emit any new uevents; Lastly, in either path (partx updates vs partx removes/adds); invoking a udevadm settle after the binary has exited is the reasonable way to ensure that *if* any uevents were created, that they are processed. growpart could add udevadm settle code; so could cloud-init. We actually did that in our first test package and that did not result in ensuring the symlink was present. All of this suggests to me that *something* isn't processing the sequence of uevents in such a way that the once they've all been processed we have the symlink. We must be missing some other bit of information in the failing path where the symlink is eventually recreated (possibly due to some other write or close on the disk on the disk which re-triggers rules). > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1834875 > > Title: > cloud-init growpart race with udev > > To manage notifications about this bug go to: > https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions > -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle
[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
** Also affects: cloud-utils 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in cloud-utils: New Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1838976] Re: package libpng12-0 1.2.50-2+deb8u3 failed to install/upgrade: intentando sobreescribir el compartido `/usr/share/doc/libpng12-0/ANNOUNCE', que es distinto de otras i
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: libpng (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libpng in Ubuntu. https://bugs.launchpad.net/bugs/1838976 Title: package libpng12-0 1.2.50-2+deb8u3 failed to install/upgrade: intentando sobreescribir el compartido `/usr/share/doc/libpng12-0/ANNOUNCE', que es distinto de otras instancias del paquetes libpng12-0:amd64 Status in libpng package in Ubuntu: Confirmed Bug description: No dejo de tener el mismo error siempre que inicio Ubuntu ProblemType: Package DistroRelease: Ubuntu 16.04 Package: libpng12-0 1.2.50-2+deb8u3 ProcVersionSignature: Ubuntu 4.15.0-54.58~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-54-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.19 Architecture: amd64 Date: Fri Aug 2 15:17:29 2019 Dependencies: gcc-6-base 6.0.1-0ubuntu1 libc6 2.23-0ubuntu11 libgcc1 1:6.0.1-0ubuntu1 multiarch-support 2.23-0ubuntu11 zlib1g 1:1.2.8.dfsg-2ubuntu4.1 DpkgHistoryLog: Start-Date: 2019-08-02 15:17:28 Commandline: apt-get -f install Requested-By: clopez (1000) Upgrade: libpng12-0:amd64 (1.2.50-2+deb8u3, 1.2.54-1ubuntu1.1) DpkgTerminalLog: Preparando para desempaquetar .../libpng12-0_1.2.54-1ubuntu1.1_amd64.deb ... Desempaquetando libpng12-0:amd64 (1.2.54-1ubuntu1.1) sobre (1.2.50-2+deb8u3) ... dpkg: error al procesar el archivo /var/cache/apt/archives/libpng12-0_1.2.54-1ubuntu1.1_amd64.deb (--unpack): intentando sobreescribir el compartido `/usr/share/doc/libpng12-0/ANNOUNCE', que es distinto de otras instancias del paquetes libpng12-0:amd64 ErrorMessage: intentando sobreescribir el compartido `/usr/share/doc/libpng12-0/ANNOUNCE', que es distinto de otras instancias del paquetes libpng12-0:amd64 InstallationDate: Installed on 2018-05-09 (452 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.32 SourcePackage: libpng Title: package libpng12-0 1.2.50-2+deb8u3 failed to install/upgrade: intentando sobreescribir el compartido `/usr/share/doc/libpng12-0/ANNOUNCE', que es distinto de otras instancias del paquetes libpng12-0:amd64 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpng/+bug/1838976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841421] Re: Xorg freeze
*** This bug is a duplicate of bug 1841420 *** https://bugs.launchpad.net/bugs/1841420 ** This bug has been marked a duplicate of bug 1841420 Xorg freeze -- 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/1841421 Title: Xorg freeze Status in xorg package in Ubuntu: New Bug description: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.213:bd06/26/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1841421/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841420] [NEW] Xorg freeze
Public bug reported: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.213:bd06/26/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic freeze ubuntu -- 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/1841420 Title: Xorg freeze Status in xorg package in Ubuntu: New Bug description: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias:
[Touch-packages] [Bug 1841421] [NEW] Xorg freeze
Public bug reported: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX550CC.213:bd06/26/2013:svnASUSTeKCOMPUTERINC.:pnX550CC:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX550CC:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.family: X dmi.product.name: X550CC dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.97-1ubuntu1~18.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 19.0.8-0ubuntu0~18.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx 19.0.8-0ubuntu0~18.04.1 version.xserver-xorg-core: xserver-xorg-core 2:1.19.6-1ubuntu4.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:18.0.1-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20171229-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.15-2 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic freeze ubuntu -- 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/1841421 Title: Xorg freeze Status in xorg package in Ubuntu: New Bug description: Constant video freeze ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: xorg 1:7.7+19ubuntu7.1 ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Mon Aug 26 10:17:38 2019 DistUpgraded: Fresh install DistroCodename: bionic DistroVariant: ubuntu DkmsStatus: anbox, 1, 4.15.0-55-generic, x86_64: installed anbox, 1, 4.15.0-58-generic, x86_64: installed ExtraDebuggingInterest: Yes GpuHangFrequency: I don't know GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. 3rd Gen Core processor Graphics Controller [1043:124d] Subsystem: ASUSTeK Computer Inc. GeForce GT 720M [1043:124d] InstallationDate: Installed on 2018-08-20 (370 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) MachineType: ASUSTeK COMPUTER INC. X550CC ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-58-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=1 SourcePackage: xorg Symptom: display Title: Xorg freeze UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/26/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: X550CC.213 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: X550CC dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias:
[Touch-packages] [Bug 1841079] Re: Speech Dispatcher and other non-human users should not be shown on LightdDM login screen and session menus
And Xubuntu too. So I'm stopping my research. I'm ready to test the fixed packages. ** Attachment added: "Xubuntu login screen with SpeechDispatcher user" https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1841079/+attachment/5284644/+files/xubuntu.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1841079 Title: Speech Dispatcher and other non-human users should not be shown on LightdDM login screen and session menus Status in accountsservice package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Download Ubuntu MATE 19.10 alpha ISO - 20190822 2. Install it using Entire-disk erase scenario with default settings 3. Reboot system Expected results: * LightDM shows only just created username Actual results: * LightDM shows two user names, Speech Dispatcher is selected by default Note: problem occurs on VM and on real hardware; Minimal desktop installation is affected too; OEM installation is affected by bug 1840971 . ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: speech-dispatcher 0.9.1-2 ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4 Uname: Linux 5.2.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE Date: Thu Aug 22 19:02:42 2019 InstallationDate: Installed on 2019-08-22 (0 days ago) InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Alpha amd64 (20190822) SourcePackage: speech-dispatcher UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1841079/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841079] Re: Speech Dispatcher and other non-human users should not be shown on LightdDM login screen and session menus
UbuntuStudio task is also affected. ** Attachment added: "UbuntuStudio login screen with SpeechDispatcher user" https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1841079/+attachment/5284643/+files/ubuntustudio.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to accountsservice in Ubuntu. https://bugs.launchpad.net/bugs/1841079 Title: Speech Dispatcher and other non-human users should not be shown on LightdDM login screen and session menus Status in accountsservice package in Ubuntu: Confirmed Bug description: Steps to reproduce: 1. Download Ubuntu MATE 19.10 alpha ISO - 20190822 2. Install it using Entire-disk erase scenario with default settings 3. Reboot system Expected results: * LightDM shows only just created username Actual results: * LightDM shows two user names, Speech Dispatcher is selected by default Note: problem occurs on VM and on real hardware; Minimal desktop installation is affected too; OEM installation is affected by bug 1840971 . ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: speech-dispatcher 0.9.1-2 ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4 Uname: Linux 5.2.0-10-generic x86_64 ApportVersion: 2.20.11-0ubuntu7 Architecture: amd64 CurrentDesktop: MATE Date: Thu Aug 22 19:02:42 2019 InstallationDate: Installed on 2019-08-22 (0 days ago) InstallationMedia: Ubuntu-MATE 19.10 "Eoan Ermine" - Alpha amd64 (20190822) SourcePackage: speech-dispatcher UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1841079/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1834875] Re: cloud-init growpart race with udev
> (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 and there is no significant delay either. So conversely, if I put a loop into cloud-init and just waited on the symlink to appear and if that worked with minimal delay, would that refute the above? -- 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/1834875 Title: cloud-init growpart race with udev Status in cloud-init: Incomplete Status in systemd package in Ubuntu: New Bug description: On Azure, it happens regularly (20-30%), that cloud-init's growpart module fails to extend the partition to full size. Such as in this example: 2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', '--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', '/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True) 2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds 2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: init-network/config-growpart: FAIL: running config-growpart with frequency always 2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed 2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed Traceback (most recent call last): File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in _run_modules freq=freq) File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run results = functor(*args) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 351, in handle func=resize_devices, args=(resizer, devices)) File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in log_time ret = func(*args, **kwargs) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 298, in resize_devices (old, new) = resizer.resize(disk, ptnum, blockdev) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 159, in resize return (before, get_size(partdev)) File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 198, in get_size fd = os.open(filename, os.O_RDONLY) FileNotFoundError: [Errno 2] No such file or directory: '/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3' @rcj suggested this is a race with udev. This seems to only happen on Cosmic and later. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1834875/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837162] Re: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1
*** This bug is a duplicate of bug 1837087 *** https://bugs.launchpad.net/bugs/1837087 ** This bug has been marked a duplicate of bug 1837087 gnome-shell/cinnamon crashed with assertion failure ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837162 Title: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. Status in mesa package in Ubuntu: New Bug description: When I returned to my computer (AMD RX580 graphics, amdgpu) after a while (the screen had entered power saving mode), the gnome-shell process (on XWayland) failed. Unfortunately this crash was not automatically reported by whoopsie / apport and required manual re-submission (bug 1792643). If this was also so for the other (to date only) three reporters, this would explain the low number of reports on errors.ubuntu.com. This is a dupe of bug 1837087 (I'm just filing this here to make some of this more searchable). ProblemType: Crash DistroRelease: Ubuntu 18.04 Package: gnome-shell 3.28.4-0ubuntu18.04.1 ProcVersionSignature: Ubuntu 5.0.0-20.21~18.04.1-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 AssertionMessage: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. CrashCounter: 1 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 18 11:24:17 2019 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell ProcCmdline: /usr/bin/gnome-shell ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash Signal: 6 SourcePackage: gnome-shell StacktraceTop: __assert_fail_base (fmt=0x7f404287a7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=file@entry=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=line@entry=239, function=function@entry=0x7f401e4a8660 "si_emit_guardband") at assert.c:92 __GI___assert_fail (assertion=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=239, function=0x7f401e4a8660 "si_emit_guardband") at assert.c:101 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Title: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip fax libvirt libvirtd lpadmin lxd plugdev sambashare sudo users vboxusers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1837162/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836979] Re: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed”
** Description changed: - [Impact] - Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that asserts are enabled, and drivers are hitting them. - - - [Test case] - test Kodi with va-api on nouveau, for instance - - - [Regression potential] - none really, it just adds a build flag which should've been there - - -- - Buggy as Kodi is, this seems to be a problem specifically with mesa-va- drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to- desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va-drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed, soon. Thanks! ** Changed in: mesa (Ubuntu Bionic) Status: Incomplete => Confirmed ** Changed in: mesa (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1836979 Title: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” Status in mesa package in Ubuntu: New Status in mesa source package in Bionic: Confirmed Bug description: Buggy as Kodi is, this seems to be a problem specifically with mesa- va-drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to-desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va- drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed,
[Touch-packages] [Bug 1841412] [NEW] Build with NDEBUG again
Public bug reported: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that some asserts are enabled, and at least nouveau is affected. [Test case] chech the build log that -DNDEBUG is passed [Regression potential] none really, it just adds a build flag which should've been there ** Affects: mesa (Ubuntu) Importance: Undecided Status: Invalid ** Affects: mesa (Ubuntu Bionic) Importance: Undecided Assignee: Timo Aaltonen (tjaalton) Status: Confirmed ** Also affects: mesa (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: mesa (Ubuntu) Status: New => Invalid ** Changed in: mesa (Ubuntu Bionic) Status: New => Confirmed ** Changed in: mesa (Ubuntu Bionic) Assignee: (unassigned) => Timo Aaltonen (tjaalton) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1841412 Title: Build with NDEBUG again Status in mesa package in Ubuntu: Invalid Status in mesa source package in Bionic: Confirmed Bug description: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that some asserts are enabled, and at least nouveau is affected. [Test case] chech the build log that -DNDEBUG is passed [Regression potential] none really, it just adds a build flag which should've been there To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1841412/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1841052] Comment bridged from LTC Bugzilla
--- Comment From heinz-werner_se...@de.ibm.com 2019-08-26 03:40 EDT--- IBM Bugzilla status -> closed, => gzip 1.10-0ubuntu3 works fine Fix Released with Eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1841052 Title: [19.10 FEAT] gzip compression improvements - addl. patch required Status in Ubuntu on IBM z Systems: Fix Released Status in gzip package in Ubuntu: Fix Released Bug description: Due to fact that LP: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1825350 is alread fix released , this new ticket is opened to fix a configuration problem: dpkg-buildpackage: info: source package gzip dpkg-buildpackage: info: source version 1.10-0ubuntu2 ... configure: WARNING: unrecognized options: --enable-dfltc The configure flag: should be --enable-dfltcc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1841052/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837162] Re: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1
** This bug is no longer a duplicate of bug 1836979 Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” ** Information type changed from Private to Public ** Package changed: gnome-shell (Ubuntu) => mesa (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837162 Title: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. Status in mesa package in Ubuntu: New Bug description: When I returned to my computer (AMD RX580 graphics, amdgpu) after a while (the screen had entered power saving mode), the gnome-shell process (on XWayland) failed. Unfortunately this crash was not automatically reported by whoopsie / apport and required manual re-submission (bug 1792643). If this was also so for the other (to date only) three reporters, this would explain the low number of reports on errors.ubuntu.com. This is a dupe of bug 1837087 (I'm just filing this here to make some of this more searchable). ProblemType: Crash DistroRelease: Ubuntu 18.04 Package: gnome-shell 3.28.4-0ubuntu18.04.1 ProcVersionSignature: Ubuntu 5.0.0-20.21~18.04.1-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 AssertionMessage: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. CrashCounter: 1 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 18 11:24:17 2019 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell ProcCmdline: /usr/bin/gnome-shell ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash Signal: 6 SourcePackage: gnome-shell StacktraceTop: __assert_fail_base (fmt=0x7f404287a7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=file@entry=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=line@entry=239, function=function@entry=0x7f401e4a8660 "si_emit_guardband") at assert.c:92 __GI___assert_fail (assertion=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=239, function=0x7f401e4a8660 "si_emit_guardband") at assert.c:101 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Title: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip fax libvirt libvirtd lpadmin lxd plugdev sambashare sudo users vboxusers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1837162/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837087] Re: gnome-shell/cinnamon crashed with assertion failure ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 &
** This bug is no longer a duplicate of bug 1836979 Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837087 Title: gnome-shell/cinnamon crashed with assertion failure ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. Status in cinnamon package in Ubuntu: Confirmed Status in gnome-shell package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Confirmed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding gnome-shell. This problem was most recently seen with package version 3.28.4-0ubuntu18.04.1, the problem page at https://errors.ubuntu.com/problem/a72ac96e774740ca840ce2bfc8a7bfe99c6d68f3 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cinnamon/+bug/1837087/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837162] [NEW] gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >=
You have been subscribed to a public bug: When I returned to my computer (AMD RX580 graphics, amdgpu) after a while (the screen had entered power saving mode), the gnome-shell process (on XWayland) failed. Unfortunately this crash was not automatically reported by whoopsie / apport and required manual re-submission (bug 1792643). If this was also so for the other (to date only) three reporters, this would explain the low number of reports on errors.ubuntu.com. This is a dupe of bug 1837087 (I'm just filing this here to make some of this more searchable). ProblemType: Crash DistroRelease: Ubuntu 18.04 Package: gnome-shell 3.28.4-0ubuntu18.04.1 ProcVersionSignature: Ubuntu 5.0.0-20.21~18.04.1-generic 5.0.8 Uname: Linux 5.0.0-20-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 AssertionMessage: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. CrashCounter: 1 CurrentDesktop: ubuntu:GNOME Date: Thu Jul 18 11:24:17 2019 DisplayManager: gdm3 ExecutablePath: /usr/bin/gnome-shell ProcCmdline: /usr/bin/gnome-shell ProcEnviron: LANGUAGE=en_US:en PATH=(custom, user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash Signal: 6 SourcePackage: gnome-shell StacktraceTop: __assert_fail_base (fmt=0x7f404287a7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=file@entry=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=line@entry=239, function=function@entry=0x7f401e4a8660 "si_emit_guardband") at assert.c:92 __GI___assert_fail (assertion=0x7f401e48e0a0 "left <= -1 && top <= -1 && right >= 1 && bottom >= 1", file=0x7f401e4a8550 "../src/gallium/drivers/radeonsi/si_state_viewport.c", line=239, function=0x7f401e4a8660 "si_emit_guardband") at assert.c:101 () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Title: gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip fax libvirt libvirtd lpadmin lxd plugdev sambashare sudo users vboxusers ** Affects: mesa (Ubuntu) Importance: Medium Status: New ** Tags: amd64 apport-crash bionic -- gnome-shell assert failure: gnome-shell: ../src/gallium/drivers/radeonsi/si_state_viewport.c:239: si_emit_guardband: Assertion `left <= -1 && top <= -1 && right >= 1 && bottom >= 1' failed. https://bugs.launchpad.net/bugs/1837162 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836979] Re: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed”
then again, this case isn't protected by NDEBUG, so... meh -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1836979 Title: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” Status in mesa package in Ubuntu: Invalid Status in mesa source package in Bionic: Incomplete Bug description: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that asserts are enabled, and drivers are hitting them. [Test case] test Kodi with va-api on nouveau, for instance [Regression potential] none really, it just adds a build flag which should've been there -- Buggy as Kodi is, this seems to be a problem specifically with mesa- va-drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to-desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va- drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed, soon. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1836979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836979] Re: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed”
assertions shouldn't be enabled -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1836979 Title: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” Status in mesa package in Ubuntu: Invalid Status in mesa source package in Bionic: Incomplete Bug description: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that asserts are enabled, and drivers are hitting them. [Test case] test Kodi with va-api on nouveau, for instance [Regression potential] none really, it just adds a build flag which should've been there -- Buggy as Kodi is, this seems to be a problem specifically with mesa- va-drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to-desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va- drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed, soon. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1836979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837170] Re: Kodi package crash after the update of libdrm-amdgpu1
and which ppa did you test with? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837170 Title: Kodi package crash after the update of libdrm-amdgpu1 Status in mesa package in Ubuntu: Incomplete Bug description: Greetings, The last update of libdrm-amdgpu1 caused a bug on Kodi package, making it to crash after loading any video or reproduce a black image. Version: 2.4.97-1ubuntu1~18.04.12019-07-03 15:07:54 UTC libdrm (2.4.97-1ubuntu1~18.04.1) bionic; urgency=medium * Backport to bionic for 18.04.3 HWE stack update. (LP: #1824111) -- Timo Aaltonen Wed, 10 Apr 2019 13:54:06 +0300 Kodi gives this error: #3 0x7f47676c60aa in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7f47676c5dd7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Repeated several times #3 0x7f475ce2c5a6 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 #4 0x7f475ce2c425 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 Team-Kodi stated these errors are in relation to 'Not supported GPU drivers', when Kodi can't find these files. I've found the cause, and a temporary solution: This bug was caused after an update for the latest version of libdrm- amdgpu1 2.4.97-1ubuntu1~18.04.1 So I grabbed the previous version from https://mirror.transip.net/ubuntu/ubuntu/pool/main/libd/libdrm/ installed libdrm-amdgpu1_2.4.95-1~18.04.1_amd64.deb and now Kodi returns. I created a bug report, the problem affects multiple users. https://bugs.launchpad.net/ubuntu/+source/kodi/+bug/1836828 We have a PointRelease coming soon, would we have time to fix this package? Thank you for your assistance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1837170/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1837170] Re: Kodi package crash after the update of libdrm-amdgpu1
what do you mean "downgrade"? I don't see you ever tested 19.04 as I asked? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1837170 Title: Kodi package crash after the update of libdrm-amdgpu1 Status in mesa package in Ubuntu: Incomplete Bug description: Greetings, The last update of libdrm-amdgpu1 caused a bug on Kodi package, making it to crash after loading any video or reproduce a black image. Version: 2.4.97-1ubuntu1~18.04.12019-07-03 15:07:54 UTC libdrm (2.4.97-1ubuntu1~18.04.1) bionic; urgency=medium * Backport to bionic for 18.04.3 HWE stack update. (LP: #1824111) -- Timo Aaltonen Wed, 10 Apr 2019 13:54:06 +0300 Kodi gives this error: #3 0x7f47676c60aa in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so #4 0x7f47676c5dd7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Repeated several times #3 0x7f475ce2c5a6 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 #4 0x7f475ce2c425 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-8.so.1 Team-Kodi stated these errors are in relation to 'Not supported GPU drivers', when Kodi can't find these files. I've found the cause, and a temporary solution: This bug was caused after an update for the latest version of libdrm- amdgpu1 2.4.97-1ubuntu1~18.04.1 So I grabbed the previous version from https://mirror.transip.net/ubuntu/ubuntu/pool/main/libd/libdrm/ installed libdrm-amdgpu1_2.4.95-1~18.04.1_amd64.deb and now Kodi returns. I created a bug report, the problem affects multiple users. https://bugs.launchpad.net/ubuntu/+source/kodi/+bug/1836828 We have a PointRelease coming soon, would we have time to fix this package? Thank you for your assistance. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1837170/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1836979] Re: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed”
Are you sure about those duplicates? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1836979 Title: Kodi crashes with “nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed” Status in mesa package in Ubuntu: Invalid Status in mesa source package in Bionic: Incomplete Bug description: [Impact] Mesa is now built with meson, and it turns out that meson < 0.47.0 (commit 7c4736d27f4c5d7 to be exact) doesn't handle command line options properly which means that -Db_ndebug=true didn't have any effect when mesa is built on bionic. This means that asserts are enabled, and drivers are hitting them. [Test case] test Kodi with va-api on nouveau, for instance [Regression potential] none really, it just adds a build flag which should've been there -- Buggy as Kodi is, this seems to be a problem specifically with mesa- va-drivers. Kodi has worked just fine on my system, as recently as July 6th of this year, but yesterday (July 16) I tried Kodi again: I got a blank screen and a pause for a few moments, followed by an unceremonious crash-to-desktop. This happens every time I start Kodi, now. If I run it through the command-line, I get this: libva info: VA-API version 1.1.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so libva info: Found init function __vaDriverInit_1_1 libva info: va_openDriver() returns 0 kodi-x11: ../src/gallium/drivers/nouveau/nouveau_vp3_video.c:91: nouveau_vp3_video_buffer_create: Assertion `templat->interlaced' failed. Aborted (core dumped) I’ve been using the same version of Kodi (“18.3 Git:20190621-89472b7”, package version 2:18.3+git20190621.1610-final-0bionic, from the Team- XBMC PPA) since its release in June, but in between July 6th and 16th, I did upgrade the Mesa packages, from 18.2.8-0ubuntu0~18.04.2 19.0.2-1ubuntu1.1~18.04.1. If I downgrade the “mesa-va-drivers” package to 18.0.0~rc5-1ubuntu1 (the version in the base, non-updates Bionic repository), however, Kodi works again, without even requiring me to restart my machine. So, this is likely a problem with “mesa-va- drivers”. I tried looking in Xorg.0.log: [ 17185.557] (II) NOUVEAU(0): EDID vendor "SEC", prod id 12620 [ 17185.557] (II) NOUVEAU(0): Printing DDC gathered Modelines: [ 17185.558] (II) NOUVEAU(0): Modeline "1366x768"x0.0 72.33 1366 1414 1446 1526 768 770 775 790 -hsync -vsync (47.4 kHz eP) …that’s all that appears in the log when I try to load Kodi and a crash happens. I’m using Ubuntu MATE 18.04.2 LTS 64-bit on a Compaq Presario CQ60; if you need more information, I’ve attached a hardinfo report, too. I hope this bug can get fixed, soon. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1836979/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
