[Touch-packages] [Bug 1621507] Re: initramfs-tools configure_networking() fails to dhcp ipv6 addresses
Mathieu, Okay, just finished testing with xenial-proposed, no issues found. Things are working as expected for my use-case (with no adjustments on my end), so at least for the corners that my particular use-cases covers, this proposed package seems regression free. I tested PXE booting into a "diskless" read-only Ubuntu server environment (using syslinux as the bootloader). Tested in both BIOS and UEFI mode. Sorry it took me a bit to do this follow-up testing! Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1621507 Title: initramfs-tools configure_networking() fails to dhcp ipv6 addresses Status in MAAS: Fix Committed Status in initramfs-tools package in Ubuntu: Fix Released Status in isc-dhcp package in Ubuntu: Fix Released Status in klibc package in Ubuntu: Won't Fix Status in open-iscsi package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: Fix Committed Status in isc-dhcp source package in Xenial: Fix Committed Status in klibc source package in Xenial: Won't Fix Status in open-iscsi source package in Xenial: Fix Committed Status in initramfs-tools source package in Yakkety: Fix Committed Status in isc-dhcp source package in Yakkety: Fix Committed Status in klibc source package in Yakkety: Won't Fix Status in open-iscsi source package in Yakkety: Fix Committed Status in klibc package in Debian: New Bug description: initramfs' configure_networking function uses ipconfig to configure the network. ipconfig does not support dhcpv6. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627164 Related bugs: * bug 1229458: grub2 needed changes * bug 1621615: network not configured when ipv6 netbooted into cloud-init * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6) Bugs related to uploads for this specific SRU: cloud-init: bug 1460715: different fix unrelated to this SRU bug 1639930: ip6= on kernel command line bug 1642679: different fix unrelated to this SRU bug 1644043: different fix unrelated to this SRU ifupdown: bug 1629972: networking.service takes down lo on stop initramfs-tools: bug 1621507: no IPv6 DHCP support in early boot bug 1628306: regression-update (failure when ip="") bug 1631474: regression-update (failure when ip=:eth0:dhcp) isc-dhcp: bug 1621507: no IPv6 DHCP support in early boot bug 1633479: dhclient does not wait for IPv6 DAD open-iscsi: bug 1621507: no IPv6 DHCP support in early boot [Impact] It is not possible to netboot Ubuntu with a network-based root filesystem in an ipv6-only environment. Anyone wanting to netboot in an ipv6-only environment is affected. [Stable Fix] These uploads add "ip6=" to the command line syntax to configure ipv6 using the defacto isc-dhcp-client. IPv4 configuration (and "ip=" syntax) remain unchanged. Valid format for the ip6= command line option is: ip6=none (or ip6=off or ip6=) -- do not configure ipv6 ip6=DEVICE -- run IPv6 dhclient on device DEVICE. [Test Case] See Bug 1229458. Configure radvd, dhcpd, and tftpd for your ipv6-only netbooting world. Pass the boot process an ipv6 address to talk to, and see it fail to configure the network. [Regression Potential] 1) This increases the uncompressed initramfs size by approximately 500KB, since isc-dhcp-client is added, but klibc is still needed for some other things, and is therefore present. On systems with a very small /boot partition, this could result in failure to upgrade the initramfs. 2) In at least some cases, DHCP network configuration shifts from klibc's ipconfig to isc-dhcp-client's dhclient. This should be of minimal risk, as isc-dhcp-client is in very very widespread use. In the event of a regression, network boot would fail, but the prior kernel should still be bootable. [Tests for verification] Whoever checks the last one off, please mark verification done. MAAS test cases: X / Y [+]/[ ] MAAS on IPv6-only network [+]/[ ] MAAS on IPv4-only network [+]/[ ] MAAS booting IPv4 on dual-stack network (with and without dhcp6) [+]/[ ] MAAS booting IPv6 on dual-stack network (with and without dhcp4) Non-MAAS test cases: X / Y [+]/[+] ip="" and ip6 not present [+]/[+] ip=:eth0:dhcp and ip6 not present [+]/[+] d-i install with iSCSI remote root should complete normally [+]/[+] Validate normal boot without remote root [+]/[+] Booting an iSCSI remote root via IPv4 (using ip=) [+]/[+] Booting an iSCSI remote root via IPv6 (using ip6=) [+]/[+] Booting an iSCSI remote root via IPv4 (no ip=, d-i use case) [+]/[+] Booting an iSCSI remote root with BOOTIF specified (BOOTIF=mac of booting device)52-54-00-53-5d-24 [+]/[+] Booting an iSCSI remote root on mixed network with no options (IPv4 should be used only) To
[Touch-packages] [Bug 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Mathieu, I tested your PPA package with Xenial: with no config changes on my end, it's working as expected from my use case. Thanks! -- 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/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: Fix Released Status in initramfs-tools source package in Yakkety: Fix Committed Status in initramfs-tools source package in Zesty: In Progress Bug description: [Impact] * initramfs-tools SRUs introduced regressions in ip= syntax, which cause unexpected behavior [Test Case] * Create a machine that boots using an nfsroot. * Use ip=:eth0:dhcp on the kernel command line. To set up networking. * Discover that the device never comes up because, networking is not configured correctly. [Regression Potential] Should be back to original behavior before ipv6 support was introduced in the past 2 or 3 SRUs. [Other Info] * There are a number of other issues in this code base that are not solved by this fix. - The ?*:?*:?*:?*: use case falls through to the default case, and likely breaks there. As such static assignment via ip= appears broken - * The networking configuration does not strictly follow the kernel documentation as described https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This should be fixed. This bug is a regression of changes made under bug 1628306. Original Bug Description Follows== initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Okay, tested 0.122ubuntu8.5 from xenial-proposed, and it fixes the issue
for my use-case.
But I'm not changing verification-needed to verification-done yet as I
don't know if it fixes the use case of the original reporter.
@scotte - can you please confirm whether this fixes things for you?
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in initramfs-tools source package in Xenial:
Fix Committed
Status in initramfs-tools source package in Yakkety:
Fix Committed
Status in initramfs-tools source package in z-series:
Fix Committed
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
configured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal. This is common on
machines that use nfsroot or otherwise pxe boot.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
- The ?*:?*:?*:?*: use case falls through to the default case, and likely
breaks there. As such static assignment via ip= appears broken
-
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
This bug is a regression of changes made under bug 1628306.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1632767] Re: yakkety: desktop ISO fails to reboot after install: Failed deactivating swap
@jbicha hmm, I didn't experience this with the final Ubuntu desktop 16.10 ISOs... what was your experience with the final 16.10 Ubuntu GNOME ISOs? But I also don't think this is happening with perfect determinism either. -- 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/1632767 Title: yakkety: desktop ISO fails to reboot after install: Failed deactivating swap Status in systemd package in Ubuntu: New Bug description: The 20161012.1 yakkety desktop ISO fails to reboot after the install completes (see attached screenshot). Tested on QEMU in BIOS and UEFI mode, which is where the screenshot is from. Same thing is seemingly happening on hardware (reboot hangs), although I don't see this particular debugging output on hardware. The systemd related logging might be a red herring... I'm not sure this is actually a systemd bug, just that it seems the correct starting point. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1632767/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Oh, and to be clear, I have no problem with this change in Yakkety. It's
just starting to feel a bit too invasive in my opinion for Xenial.
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in initramfs-tools source package in Xenial:
Fix Committed
Status in initramfs-tools source package in Yakkety:
Fix Committed
Status in initramfs-tools source package in z-series:
Fix Committed
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
configured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal. This is common on
machines that use nfsroot or otherwise pxe boot.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
- The ?*:?*:?*:?*: use case falls through to the default case, and likely
breaks there. As such static assignment via ip= appears broken
-
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
This bug is a regression of changes made under bug 1628306.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
@martin - I tested the proposed package, and it's workable, but there
are behavior changes still compared to prior to when this regression was
introduced (in particular, the boot is a lot slower when there are
mulitple NICs but only one will be configured, even when I use
"ip=:eth0:dhcp").
@scott - I think I agree with you. Considering this is an SRU for the
LTS, I'd prefer that as little behavior change be introduced as
possible.
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
Fix Committed
Status in initramfs-tools source package in Xenial:
Fix Committed
Status in initramfs-tools source package in Yakkety:
Fix Committed
Status in initramfs-tools source package in z-series:
Fix Committed
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
configured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal. This is common on
machines that use nfsroot or otherwise pxe boot.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
- The ?*:?*:?*:?*: use case falls through to the default case, and likely
breaks there. As such static assignment via ip= appears broken
-
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
This bug is a regression of changes made under bug 1628306.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
Attaching a tarbal of everything i have in /var/log, not sure it's
useful (not my "ephemeral" environment is read-only with /var/log on a
tmpfs, so it's mostly empty).
Also here's my exact /proc/cmdline from within the booted ephemeral
environment:
BOOT_IMAGE=vmlinuz-4.4.0-42-generic initrd=initrd.img-4.4.0-42-generic
root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro
nomodeset net.ifnames=0 BOOTIF=01-80-fa-5b-36-f5-86
** Attachment added: "log.tgz"
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+attachment/4760012/+files/log.tgz
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
In Progress
Status in initramfs-tools source package in Xenial:
Confirmed
Status in initramfs-tools source package in Yakkety:
In Progress
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
configured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal. This is common on
machines that use nfsroot or otherwise pxe boot.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
- The ?*:?*:?*:?*: use case falls through to the default case, and likely
breaks there. As such static assignment via ip= appears broken
-
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
@chiluk - I tested the latest package in your PPA, but something seems
slightly wonky for my use case.
Networking seems to come up correctly, but it takes longer than it
should and I see warnings like this repeated several times:
ip: ether "dev" is duplicate, or "permanent" is garbage
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
In Progress
Status in initramfs-tools source package in Xenial:
Confirmed
Status in initramfs-tools source package in Yakkety:
In Progress
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
configured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal. This is common on
machines that use nfsroot or otherwise pxe boot.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
- The ?*:?*:?*:?*: use case falls through to the default case, and likely
breaks there. As such static assignment via ip= appears broken
-
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1632767] [NEW] yakkety: desktop ISO fails to reboot after install: Failed deactivating swap
Public bug reported: The 20161012.1 yakkety desktop ISO fails to reboot after the install completes (see attached screenshot). Tested on QEMU in BIOS and UEFI mode, which is where the screenshot is from. Same thing is seemingly happening on hardware (reboot hangs), although I don't see this particular debugging output on hardware. The systemd related logging might be a red haring... I'm not sure this is actually a systemd bug, just that it seems the correct starting point. Thanks! ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: yakkety ** Attachment added: "Screenshot from 2016-10-12 06-14-05.png" https://bugs.launchpad.net/bugs/1632767/+attachment/4759958/+files/Screenshot%20from%202016-10-12%2006-14-05.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/1632767 Title: yakkety: desktop ISO fails to reboot after install: Failed deactivating swap Status in systemd package in Ubuntu: New Bug description: The 20161012.1 yakkety desktop ISO fails to reboot after the install completes (see attached screenshot). Tested on QEMU in BIOS and UEFI mode, which is where the screenshot is from. Same thing is seemingly happening on hardware (reboot hangs), although I don't see this particular debugging output on hardware. The systemd related logging might be a red haring... I'm not sure this is actually a systemd bug, just that it seems the correct starting point. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1632767/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
@chiluk - the package in your PPA fixes it from my use case, thanks!
--
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/1631474
Title:
No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot
option
Status in initramfs-tools package in Ubuntu:
In Progress
Status in initramfs-tools source package in Xenial:
Confirmed
Bug description:
[Impact]
* 0.122ubuntu8.3 of initramfs-tools no longer correctly processed
ip=dhcp or ip=:eth0:dhcp
* Regression-updates
* The fix better parses the ip= command line argument.
[Test Case]
* Create a machine that boots using an nfsroot.
* Use ip=:eth0:dhcp on the kernel command line. To set up
networking.
* Discover that the device never comes up because, networking is not
conifgured correctly.
[Regression Potential]
* Regressions potential is limited to machines using
ip={""|*|on|any|dhcp} on the kernel command line. As this is
already broken regression potential is minimal.
[Other Info]
* There are a number of other issues in this code base that are not solved
by this fix.
* The networking configuration does not strictly follow the kernel
documentation as described
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt . This
should be fixed.
Original Bug Description Follows==
initramfs-tools 0.122ubuntu8.3 introduced a serious regression where
networking is not initialized when the boot option "ip=dhcp" is
provided. We are seeing this problem in AWS, but cannot confirm if
this issue is specific to AWS or will occur with different hardware or
in different environments.
Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results
in networking being configured.
The issue does not occur with 0.122ubuntu8.2 or previous versions when
"ip=dhcp" is set.
AWS has no console so debugging is not a trivial task. I do have a
console log with some output, and will update this bug shortly with
it.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1631474] Re: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option
As asked by chiluk on IRC, here's my PXE boot configuration (well, representative one anyway, the exact kernel version will obviously change): DEFAULT ubuntu LABEL ubuntu LINUX vmlinuz-4.4.0-36-generic APPEND initrd=initrd.img-4.4.0-36-generic root=/dev/nfs nfsroot=10.17.76.1:/var/lib/tribble/ephemeral ip=dhcp ro nomodeset net.ifnames=0 IPAPPEND 2 -- 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/1631474 Title: No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Xenial: New Bug description: initramfs-tools 0.122ubuntu8.3 introduced a serious regression where networking is not initialized when the boot option "ip=dhcp" is provided. We are seeing this problem in AWS, but cannot confirm if this issue is specific to AWS or will occur with different hardware or in different environments. Removing "ip=dhcp" from the boot options with 0.122ubuntu8.3 results in networking being configured. The issue does not occur with 0.122ubuntu8.2 or previous versions when "ip=dhcp" is set. AWS has no console so debugging is not a trivial task. I do have a console log with some output, and will update this bug shortly with it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474/+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 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
I'm back to testing u-s-d started under systemd, and I found some serious wackiness observing `sudo journalctl -f` when I use the brigtness up/down hotkeys. The attached "wacky-journalctl.txt" file has the output of `sudo journalctl -f` during which I used the brightness hotkeys *twice*, and you'll see a slew interesting things happening *each* time I press a hot key. For example, this is a small excerpt of what I'm seeing for every hotkey press: Oct 06 10:44:50 jason-Gazelle-Professional systemd[1]: Created slice User Slice of root. Oct 06 10:44:50 jason-Gazelle-Professional systemd[1]: Starting User Manager for UID 0... Oct 06 10:44:50 jason-Gazelle-Professional systemd[1]: Started Session 1 of user root. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: pam_unix(systemd-user:session): session opened for user root by (uid=0) Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Reached target Paths. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Starting D-Bus User Message Bus Socket. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Reached target Timers. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Listening on D-Bus User Message Bus Socket. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Reached target Sockets. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Reached target Basic System. Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Starting Run Click user-level hooks... Oct 06 10:44:50 jason-Gazelle-Professional systemd[4805]: Started D-Bus User Message Bus. Oct 06 10:44:50 jason-Gazelle-Professional dbus-daemon[4839]: Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' ** Attachment added: "wacky-journalctl.txt" https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4756139/+files/wacky-journalctl.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
`sudo forkstat -D 4` when u-s-d is started under systemd and I press the brightness up hotkey. ** Attachment added: "with-systemd.txt" https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4756099/+files/with-systemd.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to policykit-1 in Ubuntu. https://bugs.launchpad.net/bugs/1626651 Title: brightness keys are handled slower in Yakkety than Xenial Status in policykit-1 package in Ubuntu: Triaged Status in unity-settings-daemon package in Ubuntu: Triaged Bug description: I've noticed on Lenovo X220 and X230 laptops that pressing brightness keys on Yakkety seems less responsive and slower than Xenial. I ran forkstat on Xenial and just observed udev being forked off: Xenial: $ sudo forkstat Time Event PID Info Duration Process 17:37:35 fork273 parent /lib/systemd/systemd-udevd 17:37:35 fork 1977 child /lib/systemd/systemd-udevd 17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd Whereas on Yakkety, there is far more activity: Time Event PID Info Duration Process 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2645 child update-notifier 16:35:34 exec 2645 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 exit 26452560.221 /usr/bin/python3 /usr/share/apport/apport-checkreports 16:35:34 fork 2626 parent update-notifier 16:35:34 fork 2646 child update-notifier 16:35:34 exec 2646 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:34 exit 26462560.188 /usr/bin/python3 /usr/share/apport/apport-checkreports --system 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2647 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2647 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2647 00.008 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2648 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2648 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2648 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2649 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2649 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 exit 2649 00.007 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2650 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2650 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 exit 2650 00.006 /usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness 16:35:36 fork 1576 parent /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 fork 2651 child /usr/lib/unity-settings-daemon/unity-settings-daemon 16:35:36 exec 2651 pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2652 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2651 parent pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 clone 2653 thread pkexec /usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250 16:35:36 fork 1 parent /sbin/init splash 16:35:36 fork 2654 child /sbin/init splash Time Event PID Info Duration Process 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2655 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2656 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2657 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent /lib/systemd/systemd-udevd 16:35:36 fork 2658 child /lib/systemd/systemd-udevd 16:35:36 fork233 parent
[Touch-packages] [Bug 1626651] Re: brightness keys are handled slower in Yakkety than Xenial
Okay, an interesting hint is that this problem seems to be fixed if
u-s-d is started under the Upstart user session instead of the systemd
user session.
If anyone wants to try this, just comment out these three lines in
/etc/X11/Xsession.d/00upstart:
if [ "${1#*.target}" != "$1" ]; then
export
XDG_CONFIG_DIRS="/usr/share/upstart/systemd-session:$XDG_CONFIG_DIRS"
fi
I'm attaching the result of me starting u-s-d under Upstart, running
`sudo forkstat -D 4`, and then pressing the brightness up key.
(I'll attach the same from under systemd next comment.)
>From talking to Martin Pitt on IRC, sounds like switching u-s-d back to
being started by Upstart might not be viable, but hopefully this at
least helps narrow the search.
** Attachment added: "with-upstart.txt"
https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1626651/+attachment/4756098/+files/with-upstart.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to policykit-1 in Ubuntu.
https://bugs.launchpad.net/bugs/1626651
Title:
brightness keys are handled slower in Yakkety than Xenial
Status in policykit-1 package in Ubuntu:
Triaged
Status in unity-settings-daemon package in Ubuntu:
Triaged
Bug description:
I've noticed on Lenovo X220 and X230 laptops that pressing brightness
keys on Yakkety seems less responsive and slower than Xenial. I ran
forkstat on Xenial and just observed udev being forked off:
Xenial:
$ sudo forkstat
Time Event PID Info Duration Process
17:37:35 fork273 parent /lib/systemd/systemd-udevd
17:37:35 fork 1977 child /lib/systemd/systemd-udevd
17:37:35 exit 1977 00.008 /lib/systemd/systemd-udevd
Whereas on Yakkety, there is far more activity:
Time Event PID Info Duration Process
16:35:34 fork 2626 parent update-notifier
16:35:34 fork 2645 child update-notifier
16:35:34 exec 2645 /usr/bin/python3
/usr/share/apport/apport-checkreports
16:35:34 exit 26452560.221 /usr/bin/python3
/usr/share/apport/apport-checkreports
16:35:34 fork 2626 parent update-notifier
16:35:34 fork 2646 child update-notifier
16:35:34 exec 2646 /usr/bin/python3
/usr/share/apport/apport-checkreports --system
16:35:34 exit 26462560.188 /usr/bin/python3
/usr/share/apport/apport-checkreports --system
16:35:36 fork 1576 parent
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 fork 2647 child
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 exec 2647
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness
16:35:36 exit 2647 00.008
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness
16:35:36 fork 1576 parent
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 fork 2648 child
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 exec 2648
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness
16:35:36 exit 2648 00.006
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness
16:35:36 fork 1576 parent
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 fork 2649 child
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 exec 2649
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness
16:35:36 exit 2649 00.007
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-brightness
16:35:36 fork 1576 parent
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 fork 2650 child
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 exec 2650
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness
16:35:36 exit 2650 00.006
/usr/lib/unity-settings-daemon/usd-backlight-helper --get-max-brightness
16:35:36 fork 1576 parent
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 fork 2651 child
/usr/lib/unity-settings-daemon/unity-settings-daemon
16:35:36 exec 2651 pkexec
/usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250
16:35:36 clone 2651 parent pkexec
/usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250
16:35:36 clone 2652 thread pkexec
/usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250
16:35:36 clone 2651 parent pkexec
/usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250
16:35:36 clone 2653 thread pkexec
/usr/lib/unity-settings-daemon/usd-backlight-helper --set-brightness 2250
16:35:36 fork 1 parent /sbin/init splash
16:35:36 fork 2654
[Touch-packages] [Bug 1598770] Re: Unity in low-graphics mode has animations and unneeded redraws
@Marco: thanks for the FYI! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nux in Ubuntu. https://bugs.launchpad.net/bugs/1598770 Title: Unity in low-graphics mode has animations and unneeded redraws Status in compiz package in Ubuntu: Fix Released Status in nux package in Ubuntu: Fix Released Status in unity package in Ubuntu: Fix Released Status in unity-control-center package in Ubuntu: Fix Released Status in compiz source package in Xenial: Fix Committed Status in nux source package in Xenial: Fix Committed Status in unity source package in Xenial: Fix Committed Status in unity-control-center source package in Xenial: Fix Committed Bug description: [Impact] When unity is in Low graphics mode (because of software rendering) there are still window animations and fade effects which we should get rid of. [Test case] This should apply naturally to a (virtual-)machine with no hardware acceleration or There are multiple ways to force low-gfx mode: 1) Add an upstart job such as: cat << EOF > ~/.config/upstart/lowgfx.conf start on starting unity7 pre-start script #initctl set-env --global UNITY_LOW_GFX_MODE=1 initctl set-env --global LIBGL_ALWAYS_SOFTWARE=1 end script EOF 2) Run unity with: COMPIZ_CONFIG_PROFILE=ubuntu-lowgfx On login unity should use opaque views (dash, switcher, launcher, shortcut-dialogs) with no fading and reduced effects. Windows should also use smaller shadows. [Regression potential] Some settings from unity-control-center couldn't be applied to normal profile. Low graphics mode might be used as normal one. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1598770/+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 1598770] Re: Unity in low-graphics mode has animations and unneeded redraws
Here's another screenshot that shows the SegvAnalysis. In my testing thus far, this failure (assuming it's related to this unity/nux change) only seems to happen when trying to install under qemu. I tried -vga qxl, -vga std, and -vga virtio... none of them yield a working installation. Compiz always fails to start. ** Attachment added: "Screenshot from 2016-07-13 10-56-41.png" https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1598770/+attachment/4700300/+files/Screenshot%20from%202016-07-13%2010-56-41.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nux in Ubuntu. https://bugs.launchpad.net/bugs/1598770 Title: Unity in low-graphics mode has animations and unneeded redraws Status in compiz package in Ubuntu: Fix Released Status in nux package in Ubuntu: Fix Released Status in unity package in Ubuntu: Fix Released Status in unity-control-center package in Ubuntu: Fix Released Status in compiz source package in Xenial: Fix Committed Status in nux source package in Xenial: Fix Committed Status in unity source package in Xenial: Fix Committed Status in unity-control-center source package in Xenial: Fix Committed Bug description: [Impact] When unity is in Low graphics mode (because of software rendering) there are still window animations and fade effects which we should get rid of. [Test case] This should apply naturally to a (virtual-)machine with no hardware acceleration or There are multiple ways to force low-gfx mode: 1) Add an upstart job such as: cat << EOF > ~/.config/upstart/lowgfx.conf start on starting unity7 pre-start script #initctl set-env --global UNITY_LOW_GFX_MODE=1 initctl set-env --global LIBGL_ALWAYS_SOFTWARE=1 end script EOF 2) Run unity with: COMPIZ_CONFIG_PROFILE=ubuntu-lowgfx On login unity should use opaque views (dash, switcher, launcher, shortcut-dialogs) with no fading and reduced effects. Windows should also use smaller shadows. [Regression potential] Some settings from unity-control-center couldn't be applied to normal profile. Low graphics mode might be used as normal one. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1598770/+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 1598770] Re: Unity in low-graphics mode has animations and unneeded redraws
Possibly as a result of this change, unity/compiz is failing to start when trying to install from the latest 16.04.1 daily ISO under qemu (xenial-desktop-amd64.iso 20160713, sha1sum c9b1ad9b1044c4e68684395daa3f85e016491c3a). I attached a screenshot as I couldn't file a bug from within the qemu VM (apport doesn't seem able to launch firefox). ** Attachment added: "Screenshot from 2016-07-13 10-36-40.png" https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1598770/+attachment/4700286/+files/Screenshot%20from%202016-07-13%2010-36-40.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nux in Ubuntu. https://bugs.launchpad.net/bugs/1598770 Title: Unity in low-graphics mode has animations and unneeded redraws Status in compiz package in Ubuntu: Fix Released Status in nux package in Ubuntu: Fix Released Status in unity package in Ubuntu: Fix Released Status in unity-control-center package in Ubuntu: Fix Released Status in compiz source package in Xenial: Fix Committed Status in nux source package in Xenial: Fix Committed Status in unity source package in Xenial: Fix Committed Status in unity-control-center source package in Xenial: Fix Committed Bug description: [Impact] When unity is in Low graphics mode (because of software rendering) there are still window animations and fade effects which we should get rid of. [Test case] This should apply naturally to a (virtual-)machine with no hardware acceleration or There are multiple ways to force low-gfx mode: 1) Add an upstart job such as: cat << EOF > ~/.config/upstart/lowgfx.conf start on starting unity7 pre-start script #initctl set-env --global UNITY_LOW_GFX_MODE=1 initctl set-env --global LIBGL_ALWAYS_SOFTWARE=1 end script EOF 2) Run unity with: COMPIZ_CONFIG_PROFILE=ubuntu-lowgfx On login unity should use opaque views (dash, switcher, launcher, shortcut-dialogs) with no fading and reduced effects. Windows should also use smaller shadows. [Regression potential] Some settings from unity-control-center couldn't be applied to normal profile. Low graphics mode might be used as normal one. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1598770/+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 1597876] Re: installing/upgrading packages containing systemd services results in prompt for cryptoswap passphrase [xenial]
Also attaching a screenshot, just so folks don't think I'm making this
up :P
** Attachment added: "screenshot.png"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876/+attachment/4692953/+files/screenshot.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/1597876
Title:
installing/upgrading packages containing systemd services results in
prompt for cryptoswap passphrase [xenial]
Status in systemd package in Ubuntu:
New
Bug description:
This is an extremely odd bug that requires a very specific scenario to
reproduce:
1) You need to be using an ecryptfs-style cryptoswap partition (as
would be setup when you choose "Encrypt my home directory" during the
installation)
2) The underlying physical swap partition used for the cryptoswap
needs to be on a GPT partitioned drive
3) The GUID specific bit 63 ("no auto mounting") must *not* be set on
the underlying physical swap partition
In this scenario, installing/upgrading/reinstalling seemingly *any*
package with a systemd service will result in the user getting *twice*
prompted for a passphrase to unlock their cryptoswap partition. If
upgrades are performed using the graphical Software Updater, the user
wont be aware of this issue unless they've expanded the details,
resulting in the Software Updater hanging indefinitely.
For example, if you have the needed setup, you can easily reproduce
this bug with:
sudo apt-get install --reinstall whoopsie
After which you'll encounter something like this:
(Reading database ... 177827 files and directories currently installed.)
Preparing to unpack .../whoopsie_0.2.52.1_amd64.deb ...
Please enter passphrase for disk primary (cryptswap1) on none!
Unpacking whoopsie (0.2.52.1) over (0.2.52) ...
Preparing to unpack .../libwhoopsie0_0.2.52.1_amd64.deb ...
Unpacking libwhoopsie0:amd64 (0.2.52.1) over (0.2.52) ...
Processing triggers for systemd (229-4ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Setting up libwhoopsie0:amd64 (0.2.52.1) ...
Setting up whoopsie (0.2.52.1) ...
Please enter passphrase for disk primary (cryptswap1) on none!
Processing triggers for libc-bin (2.23-0ubuntu3) ...
(You can just hit enter each time the "Please enter passphrase for..."
prompt comes up.)
For some background: in modern systemd times, ecryptfs-style
cryptoswaps are broken when the underlying physical GPT swap partition
does not have bit 63 set:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282
During the boot the user is erroneously prompted for a passpharase to
unlock the cryptoswap (you can hit enter for an empty passphrase, or
enter any passphrase you want... either way, nothing seems to actually
be done with it). After the boot completes, the underlying physical
swap partition will be mounted normally (ie, you wont actually be
using encrypted swap... so a false sense of security, which is of
course concerning).
Although lp:1447282 has been fixed for the most common hardware
configurations, it's still possible for users to encounter this
problem in the real-word: ecryptfs-setup-swap currently fails to set
bit 63 when the physical GPT swap partition is on an NVMe or MMC
drive:
https://bugs.launchpad.net/ecryptfs/+bug/1597154
So one way to reproduce this is to install Ubuntu 16.04 onto an NVMe
drive and choose "Encrypt my home directory" during the installation.
To make debugging this easier without requiring an NVMe drive (and
especially so it's easier to debug in a UEFI VM), I'm attaching a
script that will unset bit 63 on the underlying GPT swap partitions
used by any ecryptfs-style cryptoswaps that are present.
If you run my script:
sudo python3 unset-bit-63.py
And then reboot, you should now be able to reproduce this bug.
Even though fixing lp:1597154 will mean users shouldn't encounter
(during normal real-world usage) this strange behavior when
installing/upgrading/reinstalling packages that contain systemd
services, I have a strong hunch that the fact this can happen at all
indicates something is quite wonky in either systemd itself or in the
Debian/Ubuntu specific systemd trigger handling.
Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876/+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 1597876] [NEW] installing/upgrading packages containing systemd services results in prompt for cryptoswap passphrase [xenial]
Public bug reported:
This is an extremely odd bug that requires a very specific scenario to
reproduce:
1) You need to be using an ecryptfs-style cryptoswap partition (as would
be setup when you choose "Encrypt my home directory" during the
installation)
2) The underlying physical swap partition used for the cryptoswap needs
to be on a GPT partitioned drive
3) The GUID specific bit 63 ("no auto mounting") must *not* be set on
the underlying physical swap partition
In this scenario, installing/upgrading/reinstalling seemingly *any*
package with a systemd service will result in the user getting *twice*
prompted for a passphrase to unlock their cryptoswap partition. If
upgrades are performed using the graphical Software Updater, the user
wont be aware of this issue unless they've expanded the details,
resulting in the Software Updater hanging indefinitely.
For example, if you have the needed setup, you can easily reproduce this
bug with:
sudo apt-get install --reinstall whoopsie
After which you'll encounter something like this:
(Reading database ... 177827 files and directories currently installed.)
Preparing to unpack .../whoopsie_0.2.52.1_amd64.deb ...
Please enter passphrase for disk primary (cryptswap1) on none!
Unpacking whoopsie (0.2.52.1) over (0.2.52) ...
Preparing to unpack .../libwhoopsie0_0.2.52.1_amd64.deb ...
Unpacking libwhoopsie0:amd64 (0.2.52.1) over (0.2.52) ...
Processing triggers for systemd (229-4ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Setting up libwhoopsie0:amd64 (0.2.52.1) ...
Setting up whoopsie (0.2.52.1) ...
Please enter passphrase for disk primary (cryptswap1) on none!
Processing triggers for libc-bin (2.23-0ubuntu3) ...
(You can just hit enter each time the "Please enter passphrase for..."
prompt comes up.)
For some background: in modern systemd times, ecryptfs-style cryptoswaps
are broken when the underlying physical GPT swap partition does not have
bit 63 set:
https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282
During the boot the user is erroneously prompted for a passpharase to
unlock the cryptoswap (you can hit enter for an empty passphrase, or
enter any passphrase you want... either way, nothing seems to actually
be done with it). After the boot completes, the underlying physical swap
partition will be mounted normally (ie, you wont actually be using
encrypted swap... so a false sense of security, which is of course
concerning).
Although lp:1447282 has been fixed for the most common hardware
configurations, it's still possible for users to encounter this problem
in the real-word: ecryptfs-setup-swap currently fails to set bit 63 when
the physical GPT swap partition is on an NVMe or MMC drive:
https://bugs.launchpad.net/ecryptfs/+bug/1597154
So one way to reproduce this is to install Ubuntu 16.04 onto an NVMe
drive and choose "Encrypt my home directory" during the installation.
To make debugging this easier without requiring an NVMe drive (and
especially so it's easier to debug in a UEFI VM), I'm attaching a script
that will unset bit 63 on the underlying GPT swap partitions used by any
ecryptfs-style cryptoswaps that are present.
If you run my script:
sudo python3 unset-bit-63.py
And then reboot, you should now be able to reproduce this bug.
Even though fixing lp:1597154 will mean users shouldn't encounter
(during normal real-world usage) this strange behavior when
installing/upgrading/reinstalling packages that contain systemd
services, I have a strong hunch that the fact this can happen at all
indicates something is quite wonky in either systemd itself or in the
Debian/Ubuntu specific systemd trigger handling.
Thanks!
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Attachment added: "unset-bit-63.py"
https://bugs.launchpad.net/bugs/1597876/+attachment/4692952/+files/unset-bit-63.py
--
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/1597876
Title:
installing/upgrading packages containing systemd services results in
prompt for cryptoswap passphrase [xenial]
Status in systemd package in Ubuntu:
New
Bug description:
This is an extremely odd bug that requires a very specific scenario to
reproduce:
1) You need to be using an ecryptfs-style cryptoswap partition (as
would be setup when you choose "Encrypt my home directory" during the
installation)
2) The underlying physical swap partition used for the cryptoswap
needs to be on a GPT partitioned drive
3) The GUID specific bit 63 ("no auto mounting") must *not* be set on
the underlying physical swap partition
In this scenario, installing/upgrading/reinstalling seemingly *any*
package with a systemd service will result in the user getting *twice*
prompted for a passphrase to
[Touch-packages] [Bug 1564156] Re: xenial: invalid opcode when using llvmpipe
On a whim, I just checked in on this with the 20160601 Xenial daily amd64 ISO (sha1sum e07c8b4df1fc71a487fafb309bd318041a65774f), and everything works great: http://cdimages.ubuntu.com/xenial/daily-live/pending/ So seems things are on track for this not being a problem in the 16.04.1 release. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Released Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" ** Note: "Download updates while installing Ubuntu" doesn't currently seem to be working. If after installing 16.04 on effected Skylake hardware you find that Unity/Compiz is broken, switch to a VT with Control+Alt+F1, login, and then run: sudo apt-get update sudo apt-get dist-upgrade You should see the `libllvm3.8` package get updated. After a reboot, Unity/Compiz should be working. == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
Okay, seems that "Download updates while installing" has no effect with the Ubiquity version on the 16.04 ISOs. I filed a bug against Ubiquity for this, would appreciate if someone could confirm my findings: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1580232 -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" ** Note: "Download updates while installing Ubuntu" doesn't currently seem to be working. If after installing 16.04 on effected Skylake hardware you find that Unity/Compiz is broken, switch to a VT with Control+Alt+F1, login, and then run: sudo apt-get update sudo apt-get dist-upgrade You should see the `libllvm3.8` package get updated. After a reboot, Unity/Compiz should be working. == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1576726] Re: [SRU]network-manager
@seb128... I'll try to get some better debug info soon. Interestingly, it only seem to happen with Intel 7260 WiFi cards (and not, for example, with Intel 8260 WiFi cards). So I'm not sure whether what we're seeing is actually a problem with network-manager. I'm now kinda thinking it's more likely a kernel issue, especially as other's haven't seen this problem. Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1576726 Title: [SRU]network-manager Status in network-manager package in Ubuntu: Fix Released Status in network-manager-applet package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager-applet source package in Xenial: Fix Committed Status in network-manager-openconnect source package in Xenial: Confirmed Bug description: [Impact] Xenial was released with upstream beta2 version of network-manager to keep in time for the release schedule, and upstream stable release has been made so it's time to update to it. [Testcase] After upgrading the package, user should still be able to connect to networks like Ethernet, Wi-Fi and VPNs. [Regression Potential] Potential of causing regression is relatively small because there is not big changes made during beta2 -> stable process. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1576726/+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 1576726] Re: [SRU]network-manager
With this proposed package, System76 is seeing network-manager crash upon the first resume from suspend. Anyone else experiencing this? I'll be looking into this more today. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1576726 Title: [SRU]network-manager Status in network-manager package in Ubuntu: Fix Committed Status in network-manager-applet package in Ubuntu: Fix Released Status in network-manager-openconnect package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Fix Committed Status in network-manager-applet source package in Xenial: Fix Committed Status in network-manager-openconnect source package in Xenial: Confirmed Bug description: [Impact] Xenial was released with upstream beta2 version of network-manager to keep in time for the release schedule, and upstream stable release has been made so it's time to update to it. [Testcase] After upgrading the package, user should still be able to connect to networks like Ethernet, Wi-Fi and VPNs. [Regression Potential] Potential of causing regression is relatively small because there is not big changes made during beta2 -> stable process. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1576726/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
** Description changed: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" + ** Note: "Download updates while installing Ubuntu" doesn't currently + seem to be working. If after installing 16.04 on effected Skylake + hardware you find that Unity/Compiz is broken, switch to a VT with + Control+Alt+F1, login, and then run: + + sudo apt-get update + sudo apt-get dist-upgrade + + You should see the `libllvm3.8` package get updated. After a reboot, + Unity/Compiz should be working. + == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" ** Note: "Download updates while installing Ubuntu" doesn't currently seem to be working. If after installing 16.04 on effected Skylake hardware you find that Unity/Compiz is broken, switch to a VT with Control+Alt+F1, login, and then run: sudo apt-get update sudo apt-get dist-upgrade You should see the `libllvm3.8` package get updated. After a reboot, Unity/Compiz should be working. == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
Hmm, I just tried this on Skylake hardware, and "Download updates while installing" isn't doing the trick. Could be that "Download updates while installing" is broken on the 16.04 ISOs, or this could be a result of the phased updates done by the Ubuntu Software Updater and related components that use the same code paths. So after installing Ubuntu 16.04, Unity/Compiz was broken. I had to switch to a VT with Control+Alt+F1, login, and then run: sudo apt-get update sudo apt-get dist-upgrade Which gave me the updated libllvm3.8 package. Then after a reboot, everything is shiny and working. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" ** Note: "Download updates while installing Ubuntu" doesn't currently seem to be working. If after installing 16.04 on effected Skylake hardware you find that Unity/Compiz is broken, switch to a VT with Control+Alt+F1, login, and then run: sudo apt-get update sudo apt-get dist-upgrade You should see the `libllvm3.8` package get updated. After a reboot, Unity/Compiz should be working. == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
** Description changed: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" == In detail == - The Ubuntu 16.04 desktop ISOs includes libllvm3.8 1:3.8-2ubuntu1, which + The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" == In detail == The Ubuntu 16.04 desktop ISOs include libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
Abhinav, Sounds like you're encountering a different bug, or perhaps your ISO file is corrupted. Have you verified the checksum of your download? -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" == In detail == The Ubuntu 16.04 desktop ISOs includes libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
** Description changed: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" - ** Note the above work-around wont work till - llvm-toolchain-3.8 1:3.8-2ubuntu3 lands in xenial-updates (it's currently only in xenial-proposed). FIXME: update description once this happens. - == In detail == The Ubuntu 16.04 desktop ISOs includes libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it - onto the 16.04 release ISO. It will be included on the 16.04.1 ISO. + onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. ** Changed in: system76 Status: Fix Committed => Fix Released -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: Fix Committed Status in System76: Fix Released Status in Release Notes for Ubuntu: Fix Released Status in llvm-toolchain-3.8 package in Ubuntu: Fix Released Status in mesa package in Ubuntu: Confirmed Status in llvm-toolchain-3.8 source package in Xenial: Fix Released Status in mesa source package in Xenial: Confirmed Bug description: [Description updated to reflect state of 16.04 release ISO] == In summary == If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or possibly other GPUs that likewise require use of the llvmpipe opengl software fallback), a work-around is needed to install Ubuntu 16.04 desktop. To work-around this, you'll need to: 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu without installing") 2) Check "Download updates while installing Ubuntu" == In detail == The Ubuntu 16.04 desktop ISOs includes libllvm3.8 1:3.8-2ubuntu1, which has a bug that results in invalid JIT code generation when using the mesa llvmpipe opengl software fallback on Skylake CPUs. When you encounter this bug, Unity/Compiz will fail to start, and you'll see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 libllvm3.8 1:3.8-2ubuntu3 fixes this issue, but the fix did not make it onto the 16.04 release ISOs. It will be included on the 16.04.1 ISOs. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
** Description changed: - Currently it's impossible to install from xenial-desktop-amd64.iso on a - wide range of hardware with Nvidia GPUs. + [Description updated to reflect state of 16.04 release ISO] - The problem is invalid opcode(s) when using llvmpipe (the software - opengl fallback, used when using Unity with the Nouveau driver). The - result is that compiz crashes over and over; Upstart will continue to - restart compiz till it gives up. To confirm whether this bug is - happening, switch to a VT and check dmesg, in which you'll see something - like: + == In summary == + + If you have an Intel Skylake (6th gen) CPU and an NVIDIA GPU (or + possibly other GPUs that likewise require use of the llvmpipe opengl + software fallback), a work-around is needed to install Ubuntu 16.04 + desktop. + + To work-around this, you'll need to: + + 1) Choose "Install Ubuntu" in the pre-boot menu (rather than "Try Ubuntu + without installing") + + 2) Check "Download updates while installing Ubuntu" + + ** Note the above work-around wont work till + llvm-toolchain-3.8 1:3.8-2ubuntu3 lands in xenial-updates (it's currently only in xenial-proposed). FIXME: update description once this happens. + + == In detail == + + The Ubuntu 16.04 desktop ISOs includes libllvm3.8 1:3.8-2ubuntu1, which + has a bug that results in invalid JIT code generation when using the + mesa llvmpipe opengl software fallback on Skylake CPUs. + + When you encounter this bug, Unity/Compiz will fail to start, and you'll + see something like this in dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 - A workable solution seems to be to re-build mesa against llvm-3.6-dev, - libclang-3.6-dev (rather that 3.8). This would get us a working Xenial - ISO for the effected hardware. Post 16.04 release, this could be - revisited, and mesa in Xenial could possibly switch back to llvm 3.8 - once this issue is resolved. - - I have mesa test packages built against llvm 3.6 here: - - https://launchpad.net/~jderose/+archive/ubuntu/mesa/+packages - - I couldn't test the installation without a re-spun ISO, but I did - confirm that after updating to the mesa packages in my PPA, I could - again use Unity. So I'm pretty sure this will fix installing from the - ISO as well. - - My hunch is that llvm 3.8 is generating invalid code during its JIT - compilation for llvmpipe, but it could also be the result of memory - corruption. Either way, building mesa against llvm 3.6 seems to be quick - the fix. - - Note this is a regression from 14.04.4 and 15.10, both of which install - fine on the hardware effected by this bug. - - For concrete examples of System76 hardware effected by this: - - 1) All Skylake laptops with 970m, 980m, and 980gtx GPUs - - 2) All Skylake and Haswell-E desktops with 970gtx and 980gtx GPUs - (although strangely, things seem to work with when you connect to a - monitor over HDMI, but always fails when connecting to a monitor over - DisplayPort) - - Note that none of the above failed tested scenarios are using Optimus: - all are using discrete GPU configurations. - - In my testing thus far on the effected hardware, the install always - fails if you choose "Try Ubuntu without installing". The install usually - seems to work when you choose "Install Ubuntu", but even this 2nd - scenario sometimes fails (and when it does, you'll see the same "trap - invalid opcode" bits in dmesg). - - Also note that so far I've only tested amd64, haven't tested i386. - - I suspect there is some deeper weirdness here, but at this point - System76 is just trying to make sure we have a Xenial ISO from which - customers can re-install Ubuntu. - - Old description - === - Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. - - For example, from dmesg: - - [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 - [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 - [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 - - This definitely effects hardware we've tested with NVIDIA 970m and 980m - GPUs (when using the nouveau driver), and probably effects others as - well. - - Although strangely, with some NVIDIA 900 series hardware we're not - seeing this bug when using the nouveau driver. This will be investigated - further. - - In the current state, it's not possible to install Xenial on effected - hardware using recent daily desktop amd64 ISOs. - - Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in - Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from - ppa:canonical-x/x-staging. (The later test was done with the System76 - imaging system using an image with ppa:canonical-x/x-staging and - nvidia-361 pre-installed, then removing nvidia-361 and
[Touch-packages] [Bug 1564156] Re: xenial: invalid opcode when using llvmpipe
Just confirmed on Skylake hardware that llvm-toolchain-3.8 from proposed fixes this issue on Skylake hardware using llvmpipe. Thanks! ** Changed in: system76 Status: Triaged => Fix Committed ** Tags removed: verification-needed ** Tags added: verification-done -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: New Status in System76: Fix Committed Status in llvm-toolchain-3.8 package in Ubuntu: Fix Committed Status in mesa package in Ubuntu: New Status in llvm-toolchain-3.8 source package in Xenial: Fix Committed Status in mesa source package in Xenial: New Bug description: Currently it's impossible to install from xenial-desktop-amd64.iso on a wide range of hardware with Nvidia GPUs. The problem is invalid opcode(s) when using llvmpipe (the software opengl fallback, used when using Unity with the Nouveau driver). The result is that compiz crashes over and over; Upstart will continue to restart compiz till it gives up. To confirm whether this bug is happening, switch to a VT and check dmesg, in which you'll see something like: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 A workable solution seems to be to re-build mesa against llvm-3.6-dev, libclang-3.6-dev (rather that 3.8). This would get us a working Xenial ISO for the effected hardware. Post 16.04 release, this could be revisited, and mesa in Xenial could possibly switch back to llvm 3.8 once this issue is resolved. I have mesa test packages built against llvm 3.6 here: https://launchpad.net/~jderose/+archive/ubuntu/mesa/+packages I couldn't test the installation without a re-spun ISO, but I did confirm that after updating to the mesa packages in my PPA, I could again use Unity. So I'm pretty sure this will fix installing from the ISO as well. My hunch is that llvm 3.8 is generating invalid code during its JIT compilation for llvmpipe, but it could also be the result of memory corruption. Either way, building mesa against llvm 3.6 seems to be quick the fix. Note this is a regression from 14.04.4 and 15.10, both of which install fine on the hardware effected by this bug. For concrete examples of System76 hardware effected by this: 1) All Skylake laptops with 970m, 980m, and 980gtx GPUs 2) All Skylake and Haswell-E desktops with 970gtx and 980gtx GPUs (although strangely, things seem to work with when you connect to a monitor over HDMI, but always fails when connecting to a monitor over DisplayPort) Note that none of the above failed tested scenarios are using Optimus: all are using discrete GPU configurations. In my testing thus far on the effected hardware, the install always fails if you choose "Try Ubuntu without installing". The install usually seems to work when you choose "Install Ubuntu", but even this 2nd scenario sometimes fails (and when it does, you'll see the same "trap invalid opcode" bits in dmesg). Also note that so far I've only tested amd64, haven't tested i386. I suspect there is some deeper weirdness here, but at this point System76 is just trying to make sure we have a Xenial ISO from which customers can re-install Ubuntu. Old description === Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm
[Touch-packages] [Bug 1564156] Re: xenial: invalid opcode when using llvmpipe
After further investigating, it seems this bug doesn't effect Haswell-E after all, sorry about the confusion. Will continue to report back as we learn more. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: New Status in System76: Triaged Status in llvm-toolchain-3.8 package in Ubuntu: In Progress Status in mesa package in Ubuntu: New Bug description: Currently it's impossible to install from xenial-desktop-amd64.iso on a wide range of hardware with Nvidia GPUs. The problem is invalid opcode(s) when using llvmpipe (the software opengl fallback, used when using Unity with the Nouveau driver). The result is that compiz crashes over and over; Upstart will continue to restart compiz till it gives up. To confirm whether this bug is happening, switch to a VT and check dmesg, in which you'll see something like: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 A workable solution seems to be to re-build mesa against llvm-3.6-dev, libclang-3.6-dev (rather that 3.8). This would get us a working Xenial ISO for the effected hardware. Post 16.04 release, this could be revisited, and mesa in Xenial could possibly switch back to llvm 3.8 once this issue is resolved. I have mesa test packages built against llvm 3.6 here: https://launchpad.net/~jderose/+archive/ubuntu/mesa/+packages I couldn't test the installation without a re-spun ISO, but I did confirm that after updating to the mesa packages in my PPA, I could again use Unity. So I'm pretty sure this will fix installing from the ISO as well. My hunch is that llvm 3.8 is generating invalid code during its JIT compilation for llvmpipe, but it could also be the result of memory corruption. Either way, building mesa against llvm 3.6 seems to be quick the fix. Note this is a regression from 14.04.4 and 15.10, both of which install fine on the hardware effected by this bug. For concrete examples of System76 hardware effected by this: 1) All Skylake laptops with 970m, 980m, and 980gtx GPUs 2) All Skylake and Haswell-E desktops with 970gtx and 980gtx GPUs (although strangely, things seem to work with when you connect to a monitor over HDMI, but always fails when connecting to a monitor over DisplayPort) Note that none of the above failed tested scenarios are using Optimus: all are using discrete GPU configurations. In my testing thus far on the effected hardware, the install always fails if you choose "Try Ubuntu without installing". The install usually seems to work when you choose "Install Ubuntu", but even this 2nd scenario sometimes fails (and when it does, you'll see the same "trap invalid opcode" bits in dmesg). Also note that so far I've only tested amd64, haven't tested i386. I suspect there is some deeper weirdness here, but at this point System76 is just trying to make sure we have a Xenial ISO from which customers can re-install Ubuntu. Old description === Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm not sure the underling bug is in compiz, but I'm filing it against compiz anyway because that's where the dmesg output is pointing me. Other likely culprits include nux, mesa, maybe even llvm, and probably others I'm not thinking of
[Touch-packages] [Bug 1564156] Re: xenial: invalid opcode when using llvmpipe
I can confirm that tjaalton's above test packages fix the problem on a Skylake laptop with an i7-6700 CPU and an Nvidia 970m GPU when using the nouveau driver. I installed libllvm3.8_3.8-2ubuntu1.1_amd64.deb from a VT then rebooted, and now I have working Unity again. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in OEM Priority Project: New Status in System76: Triaged Status in llvm-toolchain-3.8 package in Ubuntu: In Progress Status in mesa package in Ubuntu: New Bug description: Currently it's impossible to install from xenial-desktop-amd64.iso on a wide range of hardware with Nvidia GPUs. The problem is invalid opcode(s) when using llvmpipe (the software opengl fallback, used when using Unity with the Nouveau driver). The result is that compiz crashes over and over; Upstart will continue to restart compiz till it gives up. To confirm whether this bug is happening, switch to a VT and check dmesg, in which you'll see something like: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 A workable solution seems to be to re-build mesa against llvm-3.6-dev, libclang-3.6-dev (rather that 3.8). This would get us a working Xenial ISO for the effected hardware. Post 16.04 release, this could be revisited, and mesa in Xenial could possibly switch back to llvm 3.8 once this issue is resolved. I have mesa test packages built against llvm 3.6 here: https://launchpad.net/~jderose/+archive/ubuntu/mesa/+packages I couldn't test the installation without a re-spun ISO, but I did confirm that after updating to the mesa packages in my PPA, I could again use Unity. So I'm pretty sure this will fix installing from the ISO as well. My hunch is that llvm 3.8 is generating invalid code during its JIT compilation for llvmpipe, but it could also be the result of memory corruption. Either way, building mesa against llvm 3.6 seems to be quick the fix. Note this is a regression from 14.04.4 and 15.10, both of which install fine on the hardware effected by this bug. For concrete examples of System76 hardware effected by this: 1) All Skylake laptops with 970m, 980m, and 980gtx GPUs 2) All Skylake and Haswell-E desktops with 970gtx and 980gtx GPUs (although strangely, things seem to work with when you connect to a monitor over HDMI, but always fails when connecting to a monitor over DisplayPort) Note that none of the above failed tested scenarios are using Optimus: all are using discrete GPU configurations. In my testing thus far on the effected hardware, the install always fails if you choose "Try Ubuntu without installing". The install usually seems to work when you choose "Install Ubuntu", but even this 2nd scenario sometimes fails (and when it does, you'll see the same "trap invalid opcode" bits in dmesg). Also note that so far I've only tested amd64, haven't tested i386. I suspect there is some deeper weirdness here, but at this point System76 is just trying to make sure we have a Xenial ISO from which customers can re-install Ubuntu. Old description === Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm not sure the underling bug is in compiz, but I'm filing it against compiz anyway because that's where the dmesg output is
[Touch-packages] [Bug 1564156] Re: xenial: invalid opcode when using llvmpipe
So there seems to be a curious pattern with this bug (which might provide an important hint): on desktop systems with 970 GTX or 980 GTX cards, this bug always seems to happen when connected to a monitor over DisplayPort, but does *not* seem to happen when connected to a monitor over HDMI. We'll investigate this more carefully as soon as there's a new Xenial daily build available (with the 4.4.0-18-generic kernel). -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in System76: Triaged Status in mesa package in Ubuntu: New Bug description: Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm not sure the underling bug is in compiz, but I'm filing it against compiz anyway because that's where the dmesg output is pointing me. Other likely culprits include nux, mesa, maybe even llvm, and probably others I'm not thinking of :) Also, I'm positive llvmpipe is being used when this invalid opcode is trapped because I added this to /etc/X11/Xsession.d/50_check_unity_support: /usr/lib/nux/unity_support_test -p > /tmp/compiz-debug.log That way I could figure out what renderer was being used from a VT (as the X session is darn near unusable in this state). To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1564156/+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 1564156] Re: xenial: invalid opcode when using llvmpipe
Oh, and another bit of information: our laptops all use embedded Display Port for their connection to the internal screen, and in this case, this bug always manifests. So at least in our testing so far, both eDP and DP seem to be effected. -- 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/1564156 Title: xenial: invalid opcode when using llvmpipe Status in System76: Triaged Status in mesa package in Ubuntu: New Bug description: Currently Unity on Xenial is unusable when the llvmpipe software fallback is used, at least on certain hardware. For example, from dmesg: [ 2092.557913] traps: compiz[10155] trap invalid opcode ip:7efc940030d4 sp:7ffccd914ea0 error:0 [ 2093.109485] traps: compiz[10192] trap invalid opcode ip:7f38ac01a0d4 sp:7ffe5ed737e0 error:0 [ 2093.718863] traps: compiz[10212] trap invalid opcode ip:7fe6900010d4 sp:7ffd55804020 error:0 This definitely effects hardware we've tested with NVIDIA 970m and 980m GPUs (when using the nouveau driver), and probably effects others as well. Although strangely, with some NVIDIA 900 series hardware we're not seeing this bug when using the nouveau driver. This will be investigated further. In the current state, it's not possible to install Xenial on effected hardware using recent daily desktop amd64 ISOs. Note this problem exists both when run against mesa 11.1.2-1ubuntu2 in Xenial proper, and when run against mesa 11.2.0~rc4-1ubuntu0.1 from ppa:canonical-x/x-staging. (The later test was done with the System76 imaging system using an image with ppa:canonical-x/x-staging and nvidia-361 pre-installed, then removing nvidia-361 and rebooting). I'm kinda shooting in the dark here, but I did my best to rule out the kernel as a variable: (1) I built and installed the 4.4.0-16 kernel on 15.10, rebooted, and had no problems. (2) On Xenial I tried the 4.5 and 4.6rc1 mainline builds, but they don't fix the problem. I'm not sure the underling bug is in compiz, but I'm filing it against compiz anyway because that's where the dmesg output is pointing me. Other likely culprits include nux, mesa, maybe even llvm, and probably others I'm not thinking of :) Also, I'm positive llvmpipe is being used when this invalid opcode is trapped because I added this to /etc/X11/Xsession.d/50_check_unity_support: /usr/lib/nux/unity_support_test -p > /tmp/compiz-debug.log That way I could figure out what renderer was being used from a VT (as the X session is darn near unusable in this state). To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1564156/+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 1554099] Re: Changing what action for security updates unusable
Yup, I can also confirm that it seems fixed in the 20160323 daily ISO. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1554099 Title: Changing what action for security updates unusable Status in software-properties package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Invalid Status in software-properties source package in Xenial: Fix Released Status in unattended-upgrades source package in Xenial: Invalid Bug description: Open software-properties. Important security updates is not enabled on install. Secondly - it is not possible to change the action to take with security updates even if it is enabled (note: I enabled security updates, reloaded cache and restarted software-properties before trying to change the action) eg - the Display Immediately/Download automatically/Download and install automatically ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: software-properties-gtk 0.96.18 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Mar 7 15:35:24 2016 InstallationDate: Installed on 2016-03-07 (0 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307) PackageArchitecture: all SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1554099/+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 1554099] Re: Changing what action for security updates unusable
Yup, I can also confirm that it seems fixed in the 20160323 daily ISO (tested yesterday). Will test today's shortly. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1554099 Title: Changing what action for security updates unusable Status in software-properties package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Invalid Status in software-properties source package in Xenial: Fix Released Status in unattended-upgrades source package in Xenial: Invalid Bug description: Open software-properties. Important security updates is not enabled on install. Secondly - it is not possible to change the action to take with security updates even if it is enabled (note: I enabled security updates, reloaded cache and restarted software-properties before trying to change the action) eg - the Display Immediately/Download automatically/Download and install automatically ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: software-properties-gtk 0.96.18 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Mar 7 15:35:24 2016 InstallationDate: Installed on 2016-03-07 (0 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307) PackageArchitecture: all SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1554099/+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 1554099] Re: Changing what action for security updates unusable
I'm still seeing this bug on a fresh install from today's daily ISO (20160321, sha1sum 4773a2328eb4470761e1c37174d5d3cad5b6219d). But I'm no longer seeing it on my upgraded existing install from a few months back. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1554099 Title: Changing what action for security updates unusable Status in software-properties package in Ubuntu: Fix Released Status in unattended-upgrades package in Ubuntu: Invalid Status in software-properties source package in Xenial: Fix Released Status in unattended-upgrades source package in Xenial: Invalid Bug description: Open software-properties. Important security updates is not enabled on install. Secondly - it is not possible to change the action to take with security updates even if it is enabled (note: I enabled security updates, reloaded cache and restarted software-properties before trying to change the action) eg - the Display Immediately/Download automatically/Download and install automatically ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: software-properties-gtk 0.96.18 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Mar 7 15:35:24 2016 InstallationDate: Installed on 2016-03-07 (0 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307) PackageArchitecture: all SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1554099/+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 1554099] Re: Changing what action for security updates unusable
Same is happening with latest Ubuntu (Unity) Xenial daily ISO (sha1sum 8e06dd499bfe357ebbad44c827d8428d70baacf4). I attached a screenshot of the same problem under Unity. This bug has been around for a few weeks or so, although I'm not exactly sure when it was introduced. ** Attachment added: "Screenshot from 2016-03-07 14-34-51.png" https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1554099/+attachment/4591889/+files/Screenshot%20from%202016-03-07%2014-34-51.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1554099 Title: Changing what action for security updates unusable Status in software-properties package in Ubuntu: Confirmed Bug description: Open software-properties. Important security updates is not enabled on install. Secondly - it is not possible to change the action to take with security updates even if it is enabled (note: I enabled security updates, reloaded cache and restarted software-properties before trying to change the action) eg - the Display Immediately/Download automatically/Download and install automatically ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: software-properties-gtk 0.96.18 ProcVersionSignature: Ubuntu 4.4.0-10.25-generic 4.4.3 Uname: Linux 4.4.0-10-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 CurrentDesktop: XFCE Date: Mon Mar 7 15:35:24 2016 InstallationDate: Installed on 2016-03-07 (0 days ago) InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160307) PackageArchitecture: all SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1554099/+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 1085766] Re: /var/log/upstart/ureadahead.log contains garbage
This problem seems to exist currently on both 15.10 and Xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ureadahead in Ubuntu. https://bugs.launchpad.net/bugs/1085766 Title: /var/log/upstart/ureadahead.log contains garbage Status in linux package in Ubuntu: Fix Released Status in ureadahead package in Ubuntu: Fix Released Bug description: After an upgrade to Raring (as of today) from Quantal I'm seeing tons of these in /var/log/upstart/ureadahead.log: Counted 8 CPUs ureadahead: ��&a��w: Ignored relative path ureadahead: : Ignored relative path ureadahead: �=%���n�T9: Ignored relative path ureadahead: �=%v9T9: Ignored relative path ureadahead: �=%���U�Ek�: Ignored relative path ureadahead: �=%���`�a: Ignored relative path (the boot was wonderfully fast - not sure if that's because ureadahead was working well or if it's because it didn't do anything). Dave ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: ureadahead 0.100.0-12build1 ProcVersionSignature: Ubuntu 3.7.0-4.12-generic 3.7.0-rc7 Uname: Linux 3.7.0-4-generic x86_64 ApportVersion: 2.6.3-0ubuntu2 Architecture: amd64 Date: Mon Dec 3 02:06:14 2012 InstallationDate: Installed on 2012-07-17 (138 days ago) InstallationMedia: Kubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120717) MarkForUpload: True ProcEnviron: LANGUAGE=en_GB:en TERM=xterm PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: ureadahead UpgradeStatus: Upgraded to raring on 2012-12-02 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1085766/+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 953875] Re: Encrypted swap no longer mounted at bootup
I get the impression this is known and expected, but this problem still
exists in the latest 14.04.4 daily ISOs (which have proposed enabled).
--
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/953875
Title:
Encrypted swap no longer mounted at bootup
Status in eCryptfs:
Fix Released
Status in systemd:
Fix Released
Status in ecryptfs-utils package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in ubiquity package in Ubuntu:
Fix Released
Status in ecryptfs-utils source package in Trusty:
Triaged
Status in ubiquity source package in Trusty:
Triaged
Status in ecryptfs-utils source package in Vivid:
Fix Released
Status in systemd source package in Vivid:
Fix Released
Status in ubiquity source package in Vivid:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
SUMMARY
===
During installation with "encrypt my home folder" mode, a broken
/etc/crypttab gets created which defines a non-existing swap device (usually
"cryptswap1") with a UUID. This will also be put into /etc/fstab. As after
installation the UUID does not exist, such systems don't have any actual swap.
UPGRADE FIX
===
An upgrade to Ubuntu 15.04 ("vivid") will detect and comment out these broken
swap devices from /etc/fstab and /etc/crypttab. If you actually want to use
those, do these steps:
- Find the swap device that was meant to be used in "sudo fdisk -l" (it
should say "Linux swap" in the last column), remember the device name
(something like "/dev/sda5")
- Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=)
- Run "sudo mkswap -U 1234... /dev/sda5", replacing "1234" with the above
UUID, and /dev/sda5 with the device name from step 1.
- Edit /etc/crypttab to append ",offset=1024" in the fourth (last) column of
the cryptswap1 line; ensure that there is *no space* between the
"cipher=aes-cbc-essiv:sha256" and the appended option. If there is a leading
"#" in the file, remove that too.
- If there is a leading "#" in /etc/fstab in the line starting with
/dev/mapper/cryptswap1 line, remove that.
- Run "sudo update-initramfs -u".
ORIGINAL REPORT
===
Clean install of 12.04 and with encrypted home for my user. Did all
updates and now the bootup hangs waiting for swap to become available
and it never seems to ever finish. The 200GB SSD below is my boot
drive and root filesystem.
alan@mesh:~$ sudo swapon -a
[sudo] password for alan:
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory
alan@mesh:~$ grep swap /etc/fstab
# swap was on /dev/sdg5 during installation
#UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw
0 0
/dev/mapper/cryptswap1 none swap sw 0 0
alan@mesh:~$ sudo fdisk -l
Disk /dev/sda: 115.0 GB, 115033153536 bytes
255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ba2ed
Device Boot Start End Blocks Id System
/dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT
/dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT
Disk /dev/sdb: 200.0 GB, 200049647616 bytes
255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf0fa0806
Device Boot Start End Blocks Id System
/dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT
/dev/sdb2 374722558 390721535 79994895 Extended
/dev/sdb3 * 349304832 37472051112707840 83 Linux
/dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris
Partition table entries are not in disk order
ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: libecryptfs0 96-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Tue Mar 13 09:56:56 2012
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64
(20120215)
ProcEnviron:
LANGUAGE=en_GB:en
TERM=xterm
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: ecryptfs-utils
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/953875/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe :
[Touch-packages] [Bug 1508697] Re: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id
Oops, sorry for the confusion, haven't been sleeping enough lately :P I meant to refer to lp:1508766 which I filed about systemd not creating /etc/machine-id if it's missing: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766 Now that /var/lib/dbus/machine-id is a symlink to /etc/machine-id (on Wily desktop), lp:1508766 has consequences for dbus in that it can no longer itself create the machine-id if "missing". Or at least dbus wont (and arguably it shouldn't... seems to me systemd should be doing this). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine- id Status in dbus package in Ubuntu: Triaged Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+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 1508697] Re: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id
Which I guess raises another question... when booting with sysvinit or Upstart, what should dbus do when /var/lib/dbus/machine-id is a symlink to /etc/machine-id and the latter doesn't exist? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine- id Status in dbus package in Ubuntu: Triaged Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+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 1508766] Re: /etc/machine-id not created if missing
Simon, Also, I just tested with an empty /etc/machine-id file... in this case, systemd does correctly create a write a random machine-id. Which kinda makes me wonder if systemd is erroneously concluding the rootfs is mounted read-write when the /etc/machine-id file is missing altogether. -- 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/1508766 Title: /etc/machine-id not created if missing Status in systemd package in Ubuntu: New Bug description: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read- write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus- uidgen if the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Oct 21 19:57:58 2015 JournalErrors: No journal files were found. -- No entries -- MachineType: System76, Inc. Gazelle Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=424ed0f3-306d-4302-b58c-6b1e7adb7c74 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/16/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: Gazelle Professional dmi.board.vendor: System76, Inc. dmi.board.version: gazp7 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A: dmi.product.name: Gazelle Professional dmi.product.version: gazp7 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766/+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 1508766] Re: /etc/machine-id not created if missing
Simon, I've never really dug into initramfs-tools enough to know for sure, but my guess has always been that the rootfs got remounted based on what's in /etc/fstab, which as far as I know is handled by systemd. But perhaps the initramfs remounts the rootfs read-write, and then it is remounted a 3rd time based on what's in /etc/fstab? (Which could technically be read-only if the ro option was specific in fstab). As far as our imaging system... yes, we have a golden image tarball which we unpack after we create and mount the needed partitions. But I already had work-arounds in our imaging system before I filed these bugs, needed because we started shipping Ubuntu 15.10 the day it was released :) Thanks! -- 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/1508766 Title: /etc/machine-id not created if missing Status in systemd package in Ubuntu: New Bug description: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read- write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus- uidgen if the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Oct 21 19:57:58 2015 JournalErrors: No journal files were found. -- No entries -- MachineType: System76, Inc. Gazelle Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=424ed0f3-306d-4302-b58c-6b1e7adb7c74 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/16/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: Gazelle Professional dmi.board.vendor: System76, Inc. dmi.board.version: gazp7 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A: dmi.product.name: Gazelle Professional dmi.product.version: gazp7 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766/+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 1508697] Re: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server
@seb128: yes. The two are related in that when /var/lib/dbus/machine-id is a symlink, the act of starting the system dbus instance can't (or wont, I guess) generate a machine-id (as the path in question is there, just the symlink target is missing). And because of lp:1508697, systemd doesn't inself create /etc/machine-id when missing, which it should. This is an obscure issue in the end, but it's caused problems with the System76 imaging system. I've put a lot of effort into making sure things that should be unique between machines, things that are unique when you do a manual Ubuntu install, are actually unique when we image a system. I used to just delete /var/lib/dbus/machine-id when building our golden image tarballs and let dbus generate the machine-id with dbus- uuid upon first boot. Now I have to generate /etc/machine-id during imaging, before we boot into the installed OS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server Status in dbus package in Ubuntu: New Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+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 1508697] [NEW] Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server
Public bug reported: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! ** Affects: dbus (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server Status in dbus package in Ubuntu: New Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+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 1508697] Re: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server
Side note: when /var/lib/dbus/machine-id is a symlink to /etc/machine- id, a related issue issue is that systemd fails to create the later when missing: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dbus in Ubuntu. https://bugs.launchpad.net/bugs/1508697 Title: Wily: /var/lib/dbus/machine-id is symlink on desktop, file on server Status in dbus package in Ubuntu: New Bug description: If you do a Wily desktop install, /var/lib/dbus/machine-id is a symlink to /etc/machine-id. If you do a Wily server install, /var/lib/dbus/machine-id is a file containing the same value as /etc/machine-id. Minor issue, but still a weird inconsistency between Ubuntu desktop and server. Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+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 1508766] [NEW] /etc/machine-id not created if missing
Public bug reported: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read-write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus-uidgen if the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Oct 21 19:57:58 2015 JournalErrors: No journal files were found. -- No entries -- MachineType: System76, Inc. Gazelle Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=424ed0f3-306d-4302-b58c-6b1e7adb7c74 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/16/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: Gazelle Professional dmi.board.vendor: System76, Inc. dmi.board.version: gazp7 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A: dmi.product.name: Gazelle Professional dmi.product.version: gazp7 dmi.sys.vendor: System76, Inc. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug wily -- 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/1508766 Title: /etc/machine-id not created if missing Status in systemd package in Ubuntu: New Bug description: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read- write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus- uidgen if the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Oct 21 19:57:58 2015 JournalErrors: No journal files were found. -- No entries --
[Touch-packages] [Bug 1508766] Re: /etc/machine-id not created if missing
** Description changed: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read-write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus-uidgen if - the file was missing, but on Wily it wont. + the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Oct 21 19:57:58 2015 JournalErrors: - No journal files were found. - -- No entries -- + No journal files were found. + -- No entries -- MachineType: System76, Inc. Gazelle Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-16-generic root=UUID=424ed0f3-306d-4302-b58c-6b1e7adb7c74 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/16/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: Gazelle Professional dmi.board.vendor: System76, Inc. dmi.board.version: gazp7 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: No Enclosure dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd05/16/2012:svnSystem76,Inc.:pnGazelleProfessional:pvrgazp7:rvnSystem76,Inc.:rnGazelleProfessional:rvrgazp7:cvnNoEnclosure:ct9:cvrN/A: dmi.product.name: Gazelle Professional dmi.product.version: gazp7 dmi.sys.vendor: System76, Inc. -- 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/1508766 Title: /etc/machine-id not created if missing Status in systemd package in Ubuntu: New Bug description: If /etc/machine-id is missing at boot, systemd does not create it. I came across lp:1387090 in which Martin Pitt mentions that it should be created if missing, but is unsure why this doesn't work. I'm likewise unsure why it doesn't work, but this bit from dmesg makes me think it *might* be because systemd is trying to do so while the rootfs is still mounted read-only, before it gets remounted read- write: [ 19.240451] systemd[1]: System cannot boot: Missing /etc/machine-id and /etc is mounted read-only. [ 19.240464] systemd[1]: Booting up is supported only when: [ 19.240466] systemd[1]: 1) /etc/machine-id exists and is populated. [ 19.240467] systemd[1]: 2) /etc/machine-id exists and is empty. [ 19.240468] systemd[1]: 3) /etc/machine-id is missing and /etc is writable. A missing /etc/machine-id file has broad consequences for the boot process. As one example, the Journal Service doesn't get started. This problem appears to have greater impact now that on Wily (desktop) /var/lib/dbus/machine-id is a symlink to /etc/machine-id. Previously the system dbus instance would generate the machine-id with dbus- uidgen if the file was missing, but on Wily desktop it wont. Note that on Wily server /var/lib/dbus/machine-id is a regular file, is not a symlink to /etc/machine-id. I filed lp:1508697 about this separate issue as it seems strange for this to be different between Wily desktop and server. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: systemd 225-1ubuntu9 ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3 Uname: Linux 4.2.0-16-generic x86_64 ApportVersion: 2.19.1-0ubuntu3 Architecture: amd64 CurrentDesktop:
[Touch-packages] [Bug 1484279] Re: [FFe] Mesa 11.0.0
Likewise, I've been doing extensive testing with mesa 11 from the x-staging PPA on Haswell, Broadwell, and Skylake hardware, haven't hit any issues. Timo, when do you expect mesa 11 to at least hit wily-proposed? I'll admit it makes me a bit nervous that mesa 11 isn't in wily proper yet :D -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1496163] Re: i915 firmware is not copied to initrd
Andy: oops, didn't refresh the page and see your latest comments before I posted the above, please ignore. I just tested the initramfs-tools package in your PPA, confirmed it works: 1) No more error in dmesg about skl_dmc not being loaded 2) `lsinitramfs -l` shows both the "skl_dmc_ver1.bin" symlink and the "skl_dmc_ver1_21.bin firmware file -- 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/1496163 Title: i915 firmware is not copied to initrd Status in Linux: Confirmed Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Trusty: New Status in initramfs-tools source package in Vivid: New Status in initramfs-tools source package in Wily: In Progress Bug description: On Skylake, the skl_dmc firmware is failing to load. From dmesg: [0.728803] i915 :00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2 [0.728817] [drm:i915_firmware_load_error_print [i915]] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0) This means the GPU can't enter its lowest available power states, plus many display hotplugging scenarios (that only the skl_dmc firmware can handle) are broken. On a whim I tried some other firmware versions: 1) pointed the skl_dmc_ver1.bin symlink to skl_dmc_ver1_18.bin (instead of skl_dmc_ver1_19.bin) 2) downloaded the latest (skl_dmc_ver1_21.bin) and pointed the skl_dmc_ver1.bin symlink to it But neither corrected the situation. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: linux-image-4.2.0-10-generic 4.2.0-10.11 ProcVersionSignature: Ubuntu 4.2.0-10.11-generic 4.2.0 Uname: Linux 4.2.0-10-generic x86_64 ApportVersion: 2.18.1-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oem1251 F pulseaudio CurrentDesktop: Unity Date: Tue Sep 15 16:21:24 2015 HibernationDevice: RESUME=UUID=637df075-0afa-420f-a3ca-342be8bf297f IwConfig: enp4s0no wireless extensions. lono wireless extensions. Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:0833 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse Bus 001 Device 004: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: System manufacturer System Product Name ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-10-generic root=UUID=f967534a-9cc3-4d1a-a7f3-72d28959e3c6 ro i915.verbose_state_checks=1 quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.2.0-10-generic N/A linux-backports-modules-4.2.0-10-generic N/A linux-firmware1.147 RfKill: SourcePackage: linux UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/19/2015 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0403 dmi.board.asset.tag: Default string dmi.board.name: Z170-P D3 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0403:bd08/19/2015:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ170-PD3:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1496163/+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 1496163] Re: i915 firmware is not copied to initrd
Andy, I spotted the problem: Line 120 in /usr/share/initramfs-tools/hook-functions: cp -a "$firmware" "$target_dir" `cp -a` copies the symlink itself rather than the target it points to, so we end up with a broken symlink in initramfs and no actual firmware file. The fix that comes to mind for me is: cp -aL "$firmware" "$target_dir" But I'm not sure if that would have consequences elsewhere. Are symlinks utilized anywhere in the initramfs? -- 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/1496163 Title: i915 firmware is not copied to initrd Status in Linux: Confirmed Status in initramfs-tools package in Ubuntu: In Progress Status in initramfs-tools source package in Trusty: New Status in initramfs-tools source package in Vivid: New Status in initramfs-tools source package in Wily: In Progress Bug description: On Skylake, the skl_dmc firmware is failing to load. From dmesg: [0.728803] i915 :00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2 [0.728817] [drm:i915_firmware_load_error_print [i915]] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0) This means the GPU can't enter its lowest available power states, plus many display hotplugging scenarios (that only the skl_dmc firmware can handle) are broken. On a whim I tried some other firmware versions: 1) pointed the skl_dmc_ver1.bin symlink to skl_dmc_ver1_18.bin (instead of skl_dmc_ver1_19.bin) 2) downloaded the latest (skl_dmc_ver1_21.bin) and pointed the skl_dmc_ver1.bin symlink to it But neither corrected the situation. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: linux-image-4.2.0-10-generic 4.2.0-10.11 ProcVersionSignature: Ubuntu 4.2.0-10.11-generic 4.2.0 Uname: Linux 4.2.0-10-generic x86_64 ApportVersion: 2.18.1-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oem1251 F pulseaudio CurrentDesktop: Unity Date: Tue Sep 15 16:21:24 2015 HibernationDevice: RESUME=UUID=637df075-0afa-420f-a3ca-342be8bf297f IwConfig: enp4s0no wireless extensions. lono wireless extensions. Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:0833 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse Bus 001 Device 004: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: System manufacturer System Product Name ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-10-generic root=UUID=f967534a-9cc3-4d1a-a7f3-72d28959e3c6 ro i915.verbose_state_checks=1 quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.2.0-10-generic N/A linux-backports-modules-4.2.0-10-generic N/A linux-firmware1.147 RfKill: SourcePackage: linux UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/19/2015 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0403 dmi.board.asset.tag: Default string dmi.board.name: Z170-P D3 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0403:bd08/19/2015:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ170-PD3:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1496163/+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 1496163] Re: i915 firmware is not copied to initrd
Timo, I didn't realize that this module is being loaded during the initrd phase before the rootfs is mounted. Mystery solved, I think :D Thanks! -- 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/1496163 Title: i915 firmware is not copied to initrd Status in Linux: Confirmed Status in initramfs-tools package in Ubuntu: Triaged Status in initramfs-tools source package in Trusty: New Status in initramfs-tools source package in Vivid: New Status in initramfs-tools source package in Wily: Triaged Bug description: On Skylake, the skl_dmc firmware is failing to load. From dmesg: [0.728803] i915 :00:02.0: Direct firmware load for i915/skl_dmc_ver1.bin failed with error -2 [0.728817] [drm:i915_firmware_load_error_print [i915]] *ERROR* failed to load firmware i915/skl_dmc_ver1.bin (0) This means the GPU can't enter its lowest available power states, plus many display hotplugging scenarios (that only the skl_dmc firmware can handle) are broken. On a whim I tried some other firmware versions: 1) pointed the skl_dmc_ver1.bin symlink to skl_dmc_ver1_18.bin (instead of skl_dmc_ver1_19.bin) 2) downloaded the latest (skl_dmc_ver1_21.bin) and pointed the skl_dmc_ver1.bin symlink to it But neither corrected the situation. Thanks! ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: linux-image-4.2.0-10-generic 4.2.0-10.11 ProcVersionSignature: Ubuntu 4.2.0-10.11-generic 4.2.0 Uname: Linux 4.2.0-10-generic x86_64 ApportVersion: 2.18.1-0ubuntu1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oem1251 F pulseaudio CurrentDesktop: Unity Date: Tue Sep 15 16:21:24 2015 HibernationDevice: RESUME=UUID=637df075-0afa-420f-a3ca-342be8bf297f IwConfig: enp4s0no wireless extensions. lono wireless extensions. Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 04f2:0833 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse Bus 001 Device 004: ID 058f:6364 Alcor Micro Corp. AU6477 Card Reader Controller Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: System manufacturer System Product Name ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-10-generic root=UUID=f967534a-9cc3-4d1a-a7f3-72d28959e3c6 ro i915.verbose_state_checks=1 quiet splash vt.handoff=7 RelatedPackageVersions: linux-restricted-modules-4.2.0-10-generic N/A linux-backports-modules-4.2.0-10-generic N/A linux-firmware1.147 RfKill: SourcePackage: linux UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/19/2015 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0403 dmi.board.asset.tag: Default string dmi.board.name: Z170-P D3 dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0403:bd08/19/2015:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ170-PD3:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.name: System Product Name dmi.product.version: System Version dmi.sys.vendor: System manufacturer To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1496163/+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 1436330] Re: Network Manager doesn't set metric for local networks any more, causing connection issues
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1436330 Title: Network Manager doesn't set metric for local networks any more, causing connection issues Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Vivid: Fix Committed Bug description: [Impact] NM changed its method of setting routes on systems, and no longer attaches a metric value specific to the type of device being used. These values were used to prioritize connections, so that for example, when connected to both wired and wireless at the same time, wired can be used in priority over wireless without incurring packet loss. Currently, when connected to both wired and wireless are connected to the same subnet, the user may notice connectivity issues since packets are sent in a round-robin fashion over all default routes on the same subnet with the same metric. [Test Case] 1- Connect to a wireless network. 2- Connect to the same network over Ethernet both connections should come up on the same subnet. 3- Make sure there is no packet loss, and that there are specific metric values for each default route, as displayed by 'ip route'. [Regression Potential] Since handling default routes properly involves correcting the behavior for all device types, VPN behavior may change to pick up the default routes in all cases, over a wired connection. It's also possible that a connection pick up the default route when it is not meant to. --- With Vivid, having two connections to the same network subnet is unstable due to missing metrics for local networks. Example: Being connected to 192.168.1.0/24 via both wired and wireless will cause connectivity issues as sent packets hop between the two interfaces. It used to be that this wasn't an issue. I would go between work and home and plug in and my machine would automatically connect to wireless and it would use the lower metric ethernet interface for all communications, while the wlan interface would remain connected but unused. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: KDE Date: Wed Mar 25 09:17:27 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-01-25 (58 days ago) InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-03-17 (8 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1436330/+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 1436330] Re: Network Manager doesn't set metric for local networks any more, causing connection issues
Fix seems solid. `route -n` with up-to-date Vivid: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.17.76.1 0.0.0.0 UG1024 00 eth0 10.17.75.0 0.0.0.0 255.255.255.0 U 0 00 wlan0 10.17.76.0 0.0.0.0 255.255.255.0 U 0 00 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 eth0 `route -n` after enabling proposed, updating packages, and rebooting: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.17.76.1 0.0.0.0 UG10000 eth0 10.17.75.0 0.0.0.0 255.255.255.0 U 40000 wlan0 10.17.76.0 0.0.0.0 255.255.255.0 U 10000 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 eth0 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1436330 Title: Network Manager doesn't set metric for local networks any more, causing connection issues Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Vivid: Fix Committed Bug description: [Impact] NM changed its method of setting routes on systems, and no longer attaches a metric value specific to the type of device being used. These values were used to prioritize connections, so that for example, when connected to both wired and wireless at the same time, wired can be used in priority over wireless without incurring packet loss. Currently, when connected to both wired and wireless are connected to the same subnet, the user may notice connectivity issues since packets are sent in a round-robin fashion over all default routes on the same subnet with the same metric. [Test Case] 1- Connect to a wireless network. 2- Connect to the same network over Ethernet both connections should come up on the same subnet. 3- Make sure there is no packet loss, and that there are specific metric values for each default route, as displayed by 'ip route'. [Regression Potential] Since handling default routes properly involves correcting the behavior for all device types, VPN behavior may change to pick up the default routes in all cases, over a wired connection. It's also possible that a connection pick up the default route when it is not meant to. --- With Vivid, having two connections to the same network subnet is unstable due to missing metrics for local networks. Example: Being connected to 192.168.1.0/24 via both wired and wireless will cause connectivity issues as sent packets hop between the two interfaces. It used to be that this wasn't an issue. I would go between work and home and plug in and my machine would automatically connect to wireless and it would use the lower metric ethernet interface for all communications, while the wlan interface would remain connected but unused. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: KDE Date: Wed Mar 25 09:17:27 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-01-25 (58 days ago) InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-03-17 (8 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1436330/+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 1484279] Re: [FFe] Mesa 11.0.0
Quick question: mesa11 depends on libllvm3.7, but libllvm3.7 is still in universe. Is there a plan to promote libllvm3.7 to main? -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: ### WIP ### Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works - ubuntu builds pending llvm-toolchain-3.7 working in wily and move to main [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1484279] Re: [FFe] Mesa 11.0.0
Oops, never mind... I see that libllvm3.7 being in main is mentioned in the summary, sorry for the noise! -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: ### WIP ### Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works - ubuntu builds pending llvm-toolchain-3.7 working in wily and move to main [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1436330] Re: Network Manager doesn't set metric for local networks any more, causing connection issues
Karl, FYI, network-manager should ignore any interfaces defined in /etc/network/interfaces. Which is not to say this bug isn't frustrating, just that you should be able to manually configure things as you wish without removing network- manager :D -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1436330 Title: Network Manager doesn't set metric for local networks any more, causing connection issues Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Vivid: Triaged Bug description: [Impact] NM changed its method of setting routes on systems, and no longer attaches a metric value specific to the type of device being used. These values were used to prioritize connections, so that for example, when connected to both wired and wireless at the same time, wired can be used in priority over wireless without incurring packet loss. Currently, when connected to both wired and wireless are connected to the same subnet, the user may notice connectivity issues since packets are sent in a round-robin fashion over all default routes on the same subnet with the same metric. [Test Case] 1- Connect to a wireless network. 2- Connect to the same network over Ethernet both connections should come up on the same subnet. 3- Make sure there is no packet loss, and that there are specific metric values for each default route, as displayed by 'ip route'. [Regression Potential] Since handling default routes properly involves correcting the behavior for all device types, VPN behavior may change to pick up the default routes in all cases, over a wired connection. It's also possible that a connection pick up the default route when it is not meant to. --- With Vivid, having two connections to the same network subnet is unstable due to missing metrics for local networks. Example: Being connected to 192.168.1.0/24 via both wired and wireless will cause connectivity issues as sent packets hop between the two interfaces. It used to be that this wasn't an issue. I would go between work and home and plug in and my machine would automatically connect to wireless and it would use the lower metric ethernet interface for all communications, while the wlan interface would remain connected but unused. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: KDE Date: Wed Mar 25 09:17:27 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-01-25 (58 days ago) InstallationMedia: Kubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-03-17 (8 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1436330/+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 1484279] Re: [FFe] Mesa 11.0.0
Timo, Awesome, thanks for the quick fix! I'll test it under qemu as soon as the builds are finished. Thanks! -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: ### WIP ### Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works - ubuntu builds pending llvm-toolchain-3.7 working in wily and move to main [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1484279] Re: [FFe] Mesa 11.0.0
Timo, 11.0.0~rc2-1ubuntu1~ppa2 seems shiny with Unity under qemu. Thanks! -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: ### WIP ### Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works - ubuntu builds pending llvm-toolchain-3.7 working in wily and move to main [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1484279] Re: [FFe] Mesa 11.0.0
I've started testing the mesa 11 rc2 packages here: https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging One issue I've hit is that with mesa 11 rc2 installed, Unity will no longer run under qemu (note I'm testing with an amd64 VM, Wily host and Wily guest). Attaching the full unit7.log file, but my hunch is the key failure from the log is: Compiz (opengl) - Fatal: glXQueryExtensionsString is NULL for screen 0 Thanks! ** Attachment added: "unity7.log" https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+attachment/4456917/+files/unity7.log -- 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/1484279 Title: [FFe] Mesa 11.0.0 Status in mesa package in Ubuntu: Confirmed Bug description: ### WIP ### Mesa 11.0.0 will be released as follows: August 21st 2015 - Feature freeze/Release candidate 1 August 28th 2015 - Release candidate 2 September 04th 2015 - Release candidate 3 September 11th 2015 - Release candidate 4/Mesa 11.0.0 so even rc1 will miss feature freeze, which is why this bug exists. [Changes] Wily has 10.6.3 (in proposed as of now), biggest new features compared to it are: - support for new 'amdgpu' driver (to be merged) - support for OpenGL 4.2 in core mesa - VMware OpenGL 3.3 support . . [Packaging status] - snapshots pushed to debian git - packaging updated when necessary - builds & works - ubuntu builds pending llvm-toolchain-3.7 working in wily and move to main [Plan for testing] - a snapshot will be uploaded to debian-experimental and canonical-x/x-staging ppa, call-for-testing sent once it's available - piglit runs on most common hw (intel, radeon, nouveau) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1484279/+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 1479524] Re: Totem Crashes at launch from missing libwayland-egl
+1 on getting this properly fixed in the mesa Depends, but at least fixing it in the ISO manifest is a huge step forward. Thanks! -- 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/1479524 Title: Totem Crashes at launch from missing libwayland-egl Status in System76: New Status in livecd-rootfs package in Ubuntu: Invalid Status in mesa package in Ubuntu: New Status in mesa-lts-vivid package in Ubuntu: Invalid Status in livecd-rootfs source package in Trusty: New Status in mesa source package in Trusty: Invalid Status in mesa-lts-vivid source package in Trusty: Confirmed Status in livecd-rootfs source package in Vivid: Invalid Status in mesa source package in Vivid: New Status in mesa-lts-vivid source package in Vivid: Invalid Status in livecd-rootfs source package in Wily: Invalid Status in mesa source package in Wily: New Status in mesa-lts-vivid source package in Wily: Invalid Bug description: When trying to open a video file from Ubuntu 14.04.3 Daily Image (2015-07-29), it will not open. If totem is manually run from the terminal, this error occurs: totem: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory Using Ubuntu 14.04.3 LTS (Daily Image from: 2015-07-29) 64-bit Totem version: 3.10.1-1ubuntu4 ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: totem 3.10.1-1ubuntu4 ProcVersionSignature: Ubuntu 3.19.0-25.26~14.04.1-generic 3.19.8-ckt2 Uname: Linux 3.19.0-25-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.11 Architecture: amd64 CurrentDesktop: Unity Date: Wed Jul 29 15:11:30 2015 InstallationDate: Installed on 2015-07-29 (0 days ago) InstallationMedia: Ubuntu 14.04.3 LTS Trusty Tahr - Beta amd64 (20150729) SourcePackage: totem UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1479524/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
As with 14.10, this problem isn't happening with Ubuntu MATE 15.04. Haven't tried the other flavors yet, but I'm guessing that again this is only happening with Ubuntu/Unity. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
FYI, this bug wasn't initially present on the final 15.04 release, but has since raised it's ugly head again on 15.04. Not sure what has changed, but from my previous experience, my bet is still on `unity-greeter`, even though I'm not sure how exactly it's causing it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1436330] Re: Network Manager doesn't set metric for local networks any more, causing connection issues
For what it's worth, network-manager 0.9.10.0-4ubuntu15.2 seems to fix the problem for me. `route -n` with *ubuntu15.1 with both WiFi and Ethernet connections: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.17.75.1 0.0.0.0 UG1024 00 eth0 10.17.75.0 0.0.0.0 255.255.255.0 U 0 00 wlan0 10.17.75.0 0.0.0.0 255.255.255.0 U 0 00 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlan0 And with *ubuntu15.2: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.17.75.1 0.0.0.0 UG10000 eth0 0.0.0.0 10.17.75.1 0.0.0.0 UG40000 wlan0 10.17.75.0 0.0.0.0 255.255.255.0 U 0 00 wlan0 10.17.75.0 0.0.0.0 255.255.255.0 U 0 00 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 wlan0 And in both cases for me /etc/resolve.conf has always been: nameserver 127.0.1.1 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1436330 Title: Network Manager doesn't set metric for local networks any more, causing connection issues Status in NetworkManager: Fix Released Status in network-manager package in Ubuntu: Fix Released Status in network-manager source package in Vivid: Fix Committed Bug description: [Impact] NM changed its method of setting routes on systems, and no longer attaches a metric value specific to the type of device being used. These values were used to prioritize connections, so that for example, when connected to both wired and wireless at the same time, wired can be used in priority over wireless without incurring packet loss. Currently, when connected to both wired and wireless are connected to the same subnet, the user may notice connectivity issues since packets are sent in a round-robin fashion over all default routes on the same subnet with the same metric. [Test Case] 1- Connect to a wireless network. 2- Connect to the same network over Ethernet both connections should come up on the same subnet. 3- Make sure there is no packet loss, and that there are specific metric values for each default route, as displayed by 'ip route'. [Regression Potential] Since handling default routes properly involves correcting the behavior for all device types, VPN behavior may change to pick up the default routes in all cases, over a wired connection. It's also possible that a connection pick up the default route when it is not meant to. --- With Vivid, having two connections to the same network subnet is unstable due to missing metrics for local networks. Example: Being connected to 192.168.1.0/24 via both wired and wireless will cause connectivity issues as sent packets hop between the two interfaces. It used to be that this wasn't an issue. I would go between work and home and plug in and my machine would automatically connect to wireless and it would use the lower metric ethernet interface for all communications, while the wlan interface would remain connected but unused. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.16.2-0ubuntu4 Architecture: amd64 CurrentDesktop: KDE Date: Wed Mar 25 09:17:27 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2015-01-25 (58 days ago) InstallationMedia: Kubuntu 14.10 Utopic Unicorn - Release amd64 (20141022.1) SourcePackage: network-manager UpgradeStatus: Upgraded to vivid on 2015-03-17 (8 days ago) nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1436330/+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 1450652] [NEW] 15.04: no route when connected to both WiFi and Ethernet
Public bug reported: Steps to reproduce === 1) Enable both a WiFi connection and plug into Ethernet 2) Test your network connectivity or run `route` Expected results = NetworkManager should prefer the wired connection over the WiFi connection, and `route` should return something like this: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 10.17.75.1 0.0.0.0 UG1024 00 wlan0 10.17.75.0 * 255.255.255.0 U 0 00 wlan0 link-local * 255.255.0.0 U 1000 00 wlan0 (To get the above results on Vivid, I had to unplug my Ethernet.) Actual results === `route` will produce no results and your connectivity will be broken Work-arounds === As soon as you disable either the WiFi or unplug from Ethernet, you will again have a route and your network connectivity will work. This is a regression from Trusty and Utopic. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu15.1 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Thu Apr 30 16:00:09 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.75.1 dev wlan0 proto static metric 1024 10.17.75.0/24 dev wlan0 proto kernel scope link src 10.17.75.247 169.254.0.0/16 dev wlan0 scope link metric 1000 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAMEUUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH ACTIVE DEVICE STATE ACTIVE-PATH Wired connection 1 4ff8582e-2864-4729-877e-52b037de1ee8 802-3-ethernet 1430431120 Thu 30 Apr 2015 03:58:40 PM MDT yes no /org/freedesktop/NetworkManager/Settings/1 no -- -- -- system76_5g 74de1f59-702b-4d15-9803-82b281989bed 802-11-wireless 1430431008 Thu 30 Apr 2015 03:56:48 PM MDT yes no /org/freedesktop/NetworkManager/Settings/0 yes wlan0 activated /org/freedesktop/NetworkManager/ActiveConnection/1 nmcli-dev: DEVICE TYPE STATEDBUS-PATH CONNECTION CON-UUID CON-PATH wlan0 wifi connected/org/freedesktop/NetworkManager/Devices/2 system76_5g 74de1f59-702b-4d15-9803-82b281989bed /org/freedesktop/NetworkManager/ActiveConnection/1 eth0ethernet unavailable /org/freedesktop/NetworkManager/Devices/1 -- ---- lo loopback unmanaged/org/freedesktop/NetworkManager/Devices/0 -- ---- nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug vivid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1450652 Title: 15.04: no route when connected to both WiFi and Ethernet Status in network-manager package in Ubuntu: New Bug description: Steps to reproduce === 1) Enable both a WiFi connection and plug into Ethernet 2) Test your network connectivity or run `route` Expected results = NetworkManager should prefer the wired connection over the WiFi connection, and `route` should return something like this: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default 10.17.75.1 0.0.0.0 UG1024 00 wlan0 10.17.75.0 * 255.255.255.0 U 0 00 wlan0 link-local * 255.255.0.0 U 1000 00 wlan0 (To get the above results on Vivid, I had to unplug my Ethernet.) Actual results === `route` will produce no results and your connectivity will be broken Work-arounds === As soon as you disable either the WiFi or unplug from Ethernet, you will again have a route and your network connectivity will work. This is a regression from Trusty and Utopic. ProblemType: Bug DistroRelease:
[Touch-packages] [Bug 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
Martin, Another interesting tidbit is that this pre-lightdm passphrase prompt isn't actually doing anything... you can enter a blank passphrase or the wrong passphrase, and it will still happily proceed to lightdm. Here's the output you asked for: $ systemctl --all | grep -i swap dev-mapper-cryptswap1.device loadedinactive dead start dev-mapper-cryptswap1.device systemd-cryptsetup@cryptswap1.service loadedactivating start start Cryptography Setup for cryptswap1 dev-disk-by\x2did-ata\x2dCrucial_CT120M500SSD3_14260C6F95F9\x2dpart3.swap loadedactive active /dev/disk/by-id/ata-Crucial_CT120M500SSD3_14260C6F95F9-part3 dev-disk-by\x2did-wwn\x2d0x10806682451855888394x\x2dpart3.swap loadedactive active /dev/disk/by-id/wwn-0x10806682451855888394x-part3 dev-disk-by\x2dpartlabel-primary.swap loadedactive active /dev/disk/by-partlabel/primary dev-disk-by\x2dpartuuid-54ce1181\x2d8e2b\x2d456d\x2db679\x2d6a22d25fd361.swap loadedactive active /dev/disk/by-partuuid/54ce1181-8e2b-456d-b679-6a22d25fd361 dev-disk-by\x2duuid-92a5e233\x2dc249\x2d42df\x2d8425\x2d3d6e8ac3af41.swap loadedactive active /dev/disk/by-uuid/92a5e233-c249-42df-8425-3d6e8ac3af41 dev-mapper-cryptswap1.swap loadedinactive dead start /dev/mapper/cryptswap1 dev-sda3.swap loadedactive active Swap Partition swap.target loadedinactive deadSwap $ find /run/systemd/generator* | grep -i swap /run/systemd/generator/dev-mapper-cryptswap1.device.d /run/systemd/generator/dev-mapper-cryptswap1.device.d/90-device-timeout.conf /run/systemd/generator/dev-mapper-cryptswap1.device.requires /run/systemd/generator/dev-mapper-cryptswap1.device.requires/systemd-cryptsetup@cryptswap1.service /run/systemd/generator/cryptsetup.target.requires/systemd-cryptsetup@cryptswap1.service /run/systemd/generator/dev-disk-by\x2duuid-92a5e233\x2dc249\x2d42df\x2d8425\x2d3d6e8ac3af41.device.wants/systemd-cryptsetup@cryptswap1.service /run/systemd/generator/systemd-cryptsetup@cryptswap1.service /run/systemd/generator/swap.target.requires /run/systemd/generator/swap.target.requires/dev-mapper-cryptswap1.swap /run/systemd/generator/dev-mapper-cryptswap1.swap /run/systemd/generator.late/swap.target.wants /run/systemd/generator.late/swap.target.wants/dev-sda3.swap /run/systemd/generator.late/dev-sda3.swap -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional
[Touch-packages] [Bug 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
One more interesting tidbit: it seems that when booting with systemd, it's never enabling encrypted swap, it's just enabling normal swap using the underlying physical swap partition. After booting with systemd: $ sudo swapon --summary FilenameTypeSizeUsedPriority /dev/sda3 partition 4194300 0 -1 After booting with Upstart on the same install: $ sudo swapon --summary FilenameTypeSizeUsedPriority /dev/mapper/cryptswap1 partition 4193788 0 -1 -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
I attached a tarball will everything from generator.late/, just in case any other files are useful. ** Attachment added: generator.late.tgz https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+attachment/4382428/+files/generator.late.tgz -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
Also attached a tarball with everything from generator/ ** Attachment added: generator.tgz https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+attachment/4382430/+files/generator.tgz -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
Yesterday I didn't have access to a UEFI system or a 2TiB drive to test with... but I just did a normal install on a UEFI system, and I'm experiencing this same bug. As before, booting with init=/sbin/upstart fixes it. I just wanted to rule out this being a problem introduced by the System76 imaging system :) -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecrptfs)
Info from fstab, crypttab, and journalctl: $cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # /dev/sda2 UUID=e6c5aea5-d57c-410d-abce-66e96175e946 / ext4 noatime,errors=remount-ro 0 1 # /dev/sda3 #UUID=8fcddb3d-a96d-4230-9844-cf08107d73f0 none swap sw 0 0 $ cat /etc/crypttab cryptswap1 UUID=8fcddb3d-a96d-4230-9844-cf08107d73f0 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 $ journalctl | grep -i swap Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Activating swap Swap Partition... Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Activated swap Swap Partition. Apr 22 11:34:38 jason-Kudu-Professional kernel: Adding 4194300k swap on /dev/sda3. Priority:-1 extents:1 across:4194300k SSFS Apr 22 11:34:38 jason-Kudu-Professional systemd[1]: Starting Cryptography Setup for cryptswap1... Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: systemd-cryptsetup@cryptswap1.service: main process exited, code=exited, status=1/FAILURE Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Failed to start Cryptography Setup for cryptswap1. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for dev-mapper-cryptswap1.device. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for /dev/mapper/cryptswap1. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Dependency failed for Swap. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job swap.target/start failed with result 'dependency'. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job dev-mapper-cryptswap1.swap/start failed with result 'dependency'. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Job dev-mapper-cryptswap1.device/start failed with result 'dependency'. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Unit systemd-cryptsetup@cryptswap1.service entered failed state. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: systemd-cryptsetup@cryptswap1.service failed. Apr 22 11:38:31 jason-Kudu-Professional systemd[1]: Starting Cryptography Setup for cryptswap1... -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag
[Touch-packages] [Bug 1447282] [NEW] Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
Public bug reported: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug ecryptfs systemd-boot vivid ** Attachment added: IMG_7979_01.jpg https://bugs.launchpad.net/bugs/1447282/+attachment/4381692/+files/IMG_7979_01.jpg -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional
[Touch-packages] [Bug 953875] Re: Encrypted swap no longer mounted at bootup
As far as I can tell, lp:1447282 is a different bug, but it would be helpful to have input from the other ecryptfs users who are following this bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282 -- 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/953875 Title: Encrypted swap no longer mounted at bootup Status in eCryptfs: Fix Released Status in systemd: Fix Released Status in ecryptfs-utils package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in ubiquity package in Ubuntu: Fix Released Status in ecryptfs-utils source package in Vivid: Fix Released Status in systemd source package in Vivid: Fix Released Status in ubiquity source package in Vivid: Fix Released Status in systemd package in Debian: Fix Released Bug description: SUMMARY === During installation with encrypt my home folder mode, a broken /etc/crypttab gets created which defines a non-existing swap device (usually cryptswap1) with a UUID. This will also be put into /etc/fstab. As after installation the UUID does not exist, such systems don't have any actual swap. UPGRADE FIX === An upgrade to Ubuntu 15.04 (vivid) will detect and comment out these broken swap devices from /etc/fstab and /etc/crypttab. If you actually want to use those, do these steps: - Find the swap device that was meant to be used in sudo fdisk -l (it should say Linux swap in the last column), remember the device name (something like /dev/sda5) - Find the UUID in /etc/crypttab (the long alphanumeric ID after UUID=) - Run sudo mkswap -U 1234... /dev/sda5, replacing 1234 with the above UUID, and /dev/sda5 with the device name from step 1. - Edit /etc/crypttab to append ,offset=1024 in the fourth (last) column of the cryptswap1 line; ensure that there is *no space* between the cipher=aes-cbc-essiv:sha256 and the appended option. If there is a leading # in the file, remove that too. - If there is a leading # in /etc/fstab in the line starting with /dev/mapper/cryptswap1 line, remove that. - Run sudo update-initramfs -u. ORIGINAL REPORT === Clean install of 12.04 and with encrypted home for my user. Did all updates and now the bootup hangs waiting for swap to become available and it never seems to ever finish. The 200GB SSD below is my boot drive and root filesystem. alan@mesh:~$ sudo swapon -a [sudo] password for alan: swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory alan@mesh:~$ grep swap /etc/fstab # swap was on /dev/sdg5 during installation #UUID=22d3f7f0-f715-4582-81ba-dcbd4cdd1495 noneswapsw 0 0 /dev/mapper/cryptswap1 none swap sw 0 0 alan@mesh:~$ sudo fdisk -l Disk /dev/sda: 115.0 GB, 115033153536 bytes 255 heads, 63 sectors/track, 13985 cylinders, total 224674128 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ba2ed Device Boot Start End Blocks Id System /dev/sda1 *2048 206847 1024007 HPFS/NTFS/exFAT /dev/sda2 206848 224671743 1122324487 HPFS/NTFS/exFAT Disk /dev/sdb: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xf0fa0806 Device Boot Start End Blocks Id System /dev/sdb12048 349304831 1746513927 HPFS/NTFS/exFAT /dev/sdb2 374722558 390721535 79994895 Extended /dev/sdb3 * 349304832 37472051112707840 83 Linux /dev/sdb5 374722560 390721535 7999488 82 Linux swap / Solaris Partition table entries are not in disk order ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: libecryptfs0 96-0ubuntu2 ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9 Uname: Linux 3.2.0-18-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 Date: Tue Mar 13 09:56:56 2012 EcryptfsInUse: Yes InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Alpha amd64 (20120215) ProcEnviron: LANGUAGE=en_GB:en TERM=xterm LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: ecryptfs-utils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ecryptfs/+bug/953875/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
** Summary changed: - Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecrptfs) + Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1447282] Re: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs)
Oops, when I copy+pasted my fstab earlier, I accidentally left out the final line, but the cryptswap1 line is actually there. This is from a different install, so the UUIDs are different. Also, I forgot that Martin Pitt asked me to include the output from blkid: $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # /dev/sda2 UUID=fa390f66-d7ad-4ed2-903d-481e2b3c27f6 / ext4 noatime,errors=remount-ro 0 1 # /dev/sda3 #UUID=230f371f-75b2-4264-ab46-9ff792f692a2 none swap sw 0 0 /dev/mapper/cryptswap1 none swap sw 0 0 $ cat /etc/crypttab cryptswap1 UUID=230f371f-75b2-4264-ab46-9ff792f692a2 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64 $ sudo blkid /dev/sda1 /dev/sda1: PARTLABEL=primary PARTUUID=8de16314-f8a2-44f5-8e30-926810f9fd45 $ sudo blkid /dev/sda2 /dev/sda2: LABEL=Ubuntu UUID=fa390f66-d7ad-4ed2-903d-481e2b3c27f6 TYPE=ext4 PARTLABEL=primary PARTUUID=3424f5de-bef2-4c54-b0ca-21c4ef701d0c $ sudo blkid /dev/sda3 /dev/sda3: UUID=230f371f-75b2-4264-ab46-9ff792f692a2 TYPE=swap PARTLABEL=primary PARTUUID=b82baf7e-c2eb-4b42-aea6-145947e8ee0b -- 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/1447282 Title: Prompted for cryptoswap passphrase when using GPT partitioning + encrypted home directory (ecryptfs) Status in systemd package in Ubuntu: New Bug description: I'm still sorting out the details and eliminating variables, but as far as I can tell: Steps to reproduce === 1) Install Ubuntu using GPT partitioning for the OS drive[*] 2) Choose require my password to login, and check encrypt my home directory Expected behavior === No special user interaction should be required to initialized the crytposwap other than normally logging in Actual behavior Prior to lightdm coming up, you will be prompted to enter your passphrase to unlock the cryptoswap, similar to how you would be prompted to unlock the OS drive when using full disk encryption (see attached photo). When lightdm comes up, you have to enter your password/passphrase again to login. Work-arounds === 1) This only seems to happen when using GTP partitioning, not MBR... so use MBR if you can 2) Even with GTP partitioning, booting with init=/sbin/upstart seems to reliably fix the problem, so it certainly seems systemd related Notes = * As far as I can tell, there isn't a way to force Ubiquity to create a GPT partition table when the OS drive is 2TB, but it will automatically use GPT partitioning when the OS drive is = 2TB. My particular test was done using the System76 imaging server, which by default uses GPT partitioning even when the OS drive is 2TB. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: systemd 219-7ubuntu3 ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3 Uname: Linux 3.19.0-15-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 22 11:40:29 2015 EcryptfsInUse: Yes MachineType: System76, Inc. Kudu Professional ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.19.0-15-generic root=UUID=e6c5aea5-d57c-410d-abce-66e96175e946 ro quiet splash vt.handoff=7 SourcePackage: systemd UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev' UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1.03.03RS76 dmi.board.asset.tag: Tag 12345 dmi.board.name: Kudu Professional dmi.board.vendor: System76, Inc. dmi.board.version: kudp1 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: System76, Inc. dmi.chassis.version: kudp1 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.03.03RS76:bd01/15/2014:svnSystem76,Inc.:pnKuduProfessional:pvrkudp1:rvnSystem76,Inc.:rnKuduProfessional:rvrkudp1:cvnSystem76,Inc.:ct9:cvrkudp1: dmi.product.name: Kudu Professional dmi.product.version: kudp1 dmi.sys.vendor: System76, Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1447282/+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 1429938] Re: reboot does not return under systemd
Except that previously this wasn't racy behavior in practice. I have automation tooling that has executed tens of thousands of reboot and shutdown commands over SSH in this way with perfect consistency over the last two years. The moment the switchover to systemd happened in Vivid, this tooling broken. I get that my assumptions weren't robust and that I have to change my tools to accommodate systemd (which I already did). But communicating this change is courteous and helpful, very Ubuntu if you will. And this isn't something that needs to be prominent. It just effects people working with servers, VMs, etc, not everyday desktop users. -- 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/1429938 Title: reboot does not return under systemd Status in systemd package in Ubuntu: Invalid Bug description: If you send a shutdown or reboot command over SSH to a Trusty or Utopic host, the command will consistently finish successfully prior to the SSH connection being closed, meaning your SSH client will exit with a return-code of zero: For example: $ ssh root@myhost shutdown -h now $ echo $? 0 Or $ ssh root@myhost reboot $ echo $? 0 However, on Vivid now that the switch-over to systemd has happened, running the same consistently results in the abrupt closure of the SSH connection prior to the command finishing, meaning your SSH client will exit with a return-code of 255: $ ssh root@my_vivid_host shutdown -h now Connection to localhost closed by remote host. $ echo $? 255 Although in retrospect is was a bit naive for me to rely on this (actually quite fragile) behavior, it had at least been consistent in Ubuntu for some time (back to at least Raring from my personal experience, but likely back even farther). This isn't technically a systemd bug, but I still think it's something worth mentioning in the release notes as I bet I'm not the only person who built some clever hacks around the previous behavior :P To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938/+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 1429938] Re: reboot does not return under systemd
** Description changed: - On Trusty and Utopic, when you run `apt-get remove openssh-server` over - an SSH connection, your existing SSH connection remains open, so it's - possible to run additional commands afterward. + If you send a shutdown or reboot command over SSH to a Trusty or Utopic + host, the command will consistently finish successfully prior to the SSH + connection being closed, meaning your SSH client will exit with a + return-code of zero: - However, on Vivid now that the switch to systemd has been made, `apt- - get remove openssh-server` closes the existing SSH connection - immediately, causing your SSH client to exit with a non-zero status. I - have a hunch there's a lot of automation tooling out there that relies - on the old behavior. + For example: - For what it's worth, this change breaks the internal image mastering - tools that System76 uses. Prior to exporting an image tarball, I spin up - a golden VM with qemu, rysnc a script to it, and then execute this - script over SSH. + $ ssh root@myhost shutdown -h now + $ echo $? + 0 - The important step is that I need to remove openssh-server prior to - shutting down the VM, so these scripts always end with something like - this: + Or - apt-get -y purge openssh-server ssh-import-id - apt-get -y autoremove - shutdown -h now + $ ssh root@myhost reboot + $ echo $? + 0 - As far as I can tell, this behavior change will likewise be a problem - when running `do-release-upgrade` on a remote server over SSH. Or more - generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it - seems this would be a problem whenever the openssh-server package - happens to be updated. + However, on Vivid now that the switch-over to systemd has happened, + running the same consistently results in the abrupt closure of the SSH + connection prior to the command finishing, meaning your SSH client will + exit with a return-code of 255: + + $ ssh root@my_vivid_host shutdown -h now + Connection to localhost closed by remote host. + $ echo $? + 255 + + Although in retrospect is was a bit naive for me to rely on this + (actually quite fragile) behavior, it had at least been consistent in + Ubuntu for some time (back to at least Raring from my personal + experience, but likely back even farther). + + This isn't technically a systemd bug, but I still think it's something + worth mentioning in the release notes as I bet I'm not the only person + who built some clever hacks around the previous behavior :P -- 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/1429938 Title: reboot does not return under systemd Status in systemd package in Ubuntu: Invalid Bug description: If you send a shutdown or reboot command over SSH to a Trusty or Utopic host, the command will consistently finish successfully prior to the SSH connection being closed, meaning your SSH client will exit with a return-code of zero: For example: $ ssh root@myhost shutdown -h now $ echo $? 0 Or $ ssh root@myhost reboot $ echo $? 0 However, on Vivid now that the switch-over to systemd has happened, running the same consistently results in the abrupt closure of the SSH connection prior to the command finishing, meaning your SSH client will exit with a return-code of 255: $ ssh root@my_vivid_host shutdown -h now Connection to localhost closed by remote host. $ echo $? 255 Although in retrospect is was a bit naive for me to rely on this (actually quite fragile) behavior, it had at least been consistent in Ubuntu for some time (back to at least Raring from my personal experience, but likely back even farther). This isn't technically a systemd bug, but I still think it's something worth mentioning in the release notes as I bet I'm not the only person who built some clever hacks around the previous behavior :P To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938/+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 1429938] Re: reboot does not return under systemd
I reworked the description as my original assessment was quite off. But after more thought, I think this behavior change is something that really needs mentioning in the Vivid releases notes. After all, the perceived correct behavior of a system strongly tends toward what the actual behavior has been historically. Yet one of these kids is clearly not like the other :D -- 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/1429938 Title: reboot does not return under systemd Status in systemd package in Ubuntu: Invalid Bug description: If you send a shutdown or reboot command over SSH to a Trusty or Utopic host, the command will consistently finish successfully prior to the SSH connection being closed, meaning your SSH client will exit with a return-code of zero: For example: $ ssh root@myhost shutdown -h now $ echo $? 0 Or $ ssh root@myhost reboot $ echo $? 0 However, on Vivid now that the switch-over to systemd has happened, running the same consistently results in the abrupt closure of the SSH connection prior to the command finishing, meaning your SSH client will exit with a return-code of 255: $ ssh root@my_vivid_host shutdown -h now Connection to localhost closed by remote host. $ echo $? 255 Although in retrospect is was a bit naive for me to rely on this (actually quite fragile) behavior, it had at least been consistent in Ubuntu for some time (back to at least Raring from my personal experience, but likely back even farther). This isn't technically a systemd bug, but I still think it's something worth mentioning in the release notes as I bet I'm not the only person who built some clever hacks around the previous behavior :P To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938/+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 1429938] Re: stopping ssh.service closes existing ssh connections
So interestingly, this isn't happening when I just type these commands into an SSH session. But if you create a script like this in say /tmp/test.sh: #!/bin/bash apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now And then execute this through an ssh call like this: $ ssh root@whatever /tmp/test.sh I get the disconnection problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: stopping ssh.service closes existing ssh connections Status in openssh package in Ubuntu: Incomplete Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1429938] Re: reboot does not return under systemd
Martin, Okay, much thanks! -- 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/1429938 Title: reboot does not return under systemd Status in systemd package in Ubuntu: Invalid Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938/+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 1429938] Re: stopping ssh.service closes existing ssh connections
Hmm, now I'm thinking this has nothing to do with openssh-server. I think the problem is actually that when I run this over SSH: # shutdown -h now My ssh client exists with status 255... whereas running the same thing prior to the flip-over to systemd would exit with status 0. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: stopping ssh.service closes existing ssh connections Status in openssh package in Ubuntu: Incomplete Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1429938] Re: stopping ssh.service closes existing ssh connections
Also, on Vivid there will be this error: Connection to localhost closed by remote host. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: stopping ssh.service closes existing ssh connections Status in openssh package in Ubuntu: Incomplete Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1429938] Re: stopping ssh.service closes existing ssh connections
Okay, here's a simple way to reproduce: $ ssh root@whatever shutdown -h now $ echo $? On Vivid, the exist status from the ssh client will be 255. On Trusty and Utopic it will be 0. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: stopping ssh.service closes existing ssh connections Status in openssh package in Ubuntu: Incomplete Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1429938] Re: stopping ssh.service closes existing ssh connections
Same problem when running `reboot`, which I'd say is even more important for automation. Port 2204 is forwarding to a qemu VM running Utopic, port 2207 is running Vivid: jderose@jgd-kudp1:~$ ssh root@localhost -p 2204 reboot jderose@jgd-kudp1:~$ echo $? 0 jderose@jgd-kudp1:~$ ssh root@localhost -p 2207 reboot Connection to localhost closed by remote host. jderose@jgd-kudp1:~$ echo $? 255 jderose@jgd-kudp1:~$ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: stopping ssh.service closes existing ssh connections Status in openssh package in Ubuntu: Incomplete Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1427654] Re: FFE: switch system init to systemd [not touch] in 15.04
Being able to run a script like this over SSH: apt-get -y remove openssh-server shutdown -h now Can be extremely useful in automation tooling, but the switch to systemd breaks this: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to init-system-helpers in Ubuntu. https://bugs.launchpad.net/bugs/1427654 Title: FFE: switch system init to systemd [not touch] in 15.04 Status in init-system-helpers package in Ubuntu: Fix Released Status in ubuntu-meta package in Ubuntu: Fix Released Status in init-system-helpers source package in Vivid: Fix Released Status in ubuntu-meta source package in Vivid: Fix Released Bug description: As per https://blueprints.launchpad.net/ubuntu/+spec/core-1411 -systemd-migration we aimed for switching the system (not session) init from upstart to systemd this cycle. As this was by and large a 1.2 man show, this took a little longer. One of the remaining blockers for switching the default was to fix NFS (bug 1312976) which is now ready to be uploaded. There is also juju (bug 1409639, landed upstream now) and maas (bug 1423613, scheduled), but for those we can work around missing systemd support by installing upstart on instances. We are a few days past feature freeze now, bug Steve and I discussed last week, and we still want to aim for switching the default in vivid. To be clear, this will affect Ubuntu desktop/server/cloud and the flavours like Kubuntu, but *NOT* ubuntu-touch. Migration to systemd is blocked on touch (too old kernels, some unported jobs), and was not scheduled for vivid. For that we need to ensure to keep upstart on Touch (there is a work item on the spec). I know from at least Kubuntu and Ubuntu GNOME that they are pushing for switching to systemd. We should get an ack from the others (Lubuntu/Xubuntu/MATE) before doing the switch; but quite a lot of vivid users are running systemd already, and I believe we shook out the worst bugs now. So if/once the release team generally agrees, these are the things which need to happen before switching: * Signoff/test from remaining flavours (MATE, Xubuntu, Lubuntu) - DONE * Land NFS (bug 1312976) - DONE * Ensure Touch keeps upstart (bug 1428026) - DONE Operationally, the switch is merely to change s/upstart/systemd-sysv/ in the seeds, i. e. flip the dependency in ubuntu-minimal. I did that in https://launchpad.net/~pitti/+archive/ubuntu/systemd, fixed ureadahead, and verified that upgrades from trusty and utopic cleanly upgrade to vivid+PPA with removing upstart and installing systemd- sysv. Around that time I will send a mail to ubuntu-devel-announce@ to warn about the impending switch, and give some pointers how to boot with upstart (from grub menu or reinstalling upstart), how to debug boot/shutdown issues, etc. Contingency plan: This will trigger wider testing, and most certainly uncover more integration issues. I'll try to keep up with them, but if we get to a point where we find that there are too many/too serious regressions, we can flip the seed back to upstart and get back to the situation today. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1427654/+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 1429938] [NEW] systemd changes behavior of apt-get remove openssh-server
Public bug reported: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. ** Affects: openssh (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: systemd-boot vivid ** Tags added: systemd vivid ** Tags removed: systemd ** Tags added: systemd-boot -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: systemd changes behavior of apt-get remove openssh-server Status in openssh package in Ubuntu: Confirmed Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1429938] Re: systemd changes behavior of apt-get remove openssh-server
Also, just to clarify, this is definitely a change (or in my mind regression) introduced by systemd. Yesterday, the System76 image master tool worked fine and dandy with an up-to-date Vivid VM, as it has throughout the rest of the previous Vivid dev cycle. Today things broke. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1429938 Title: systemd changes behavior of apt-get remove openssh-server Status in openssh package in Ubuntu: Confirmed Bug description: On Trusty and Utopic, when you run `apt-get remove openssh-server` over an SSH connection, your existing SSH connection remains open, so it's possible to run additional commands afterward. However, on Vivid now that the switch to systemd has been made, `apt- get remove openssh-server` closes the existing SSH connection immediately, causing your SSH client to exit with a non-zero status. I have a hunch there's a lot of automation tooling out there that relies on the old behavior. For what it's worth, this change breaks the internal image mastering tools that System76 uses. Prior to exporting an image tarball, I spin up a golden VM with qemu, rysnc a script to it, and then execute this script over SSH. The important step is that I need to remove openssh-server prior to shutting down the VM, so these scripts always end with something like this: apt-get -y purge openssh-server ssh-import-id apt-get -y autoremove shutdown -h now As far as I can tell, this behavior change will likewise be a problem when running `do-release-upgrade` on a remote server over SSH. Or more generally, anytime you run apt-get upgrade/dist-upgrade via SSH, it seems this would be a problem whenever the openssh-server package happens to be updated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1429938/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Okay, on vivid, unity-greeter 15.04.2-0ubuntu1 re-introduces this bug. I have a vivid image that was up-to-date as of Fri 5 Dec. In this snapshot, with applying any updates, I can connect to protected WiFi just fine. However, today something landing from proposed re-introduced this bug, and I noticed that unity-greeter was among the updates. So I re-imaged and then upgraded only unity-greeter: sudo apt-get update sudo apt-get install unity-greeter After a reboot, the password dialog wont show when I try to connect to protected WiFi (same symptom as Utopic). Interestingly enough, unity-greeter was one of the many things I tried back-porting and it didn't fix this on Utopic, although now I can't recall whether I did that back-port in isolation or whether there were other backports I was testing at the same time. Ah, also note that unity-greeter 15.04.2-0ubuntu1 does *not* break WiFi on Intel GPU systems. This is still only a problem on systems with Nvidia GPUs running the proprietary nvidia driver (might effect the nouveau driver too, not sure either way on that one). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Another possible hint: some in this set of packages currently in vivid proposed breaks the WiFi password dialog: Calculating upgrade... Done The following NEW packages will be installed: libisl13 The following packages will be upgraded: apport apport-gtk btrfs-tools fontconfig fontconfig-config gir1.2-timezonemap-1.0 gnome-system-monitor libc-bin libc-dev-bin libc6 libc6-dbg libc6-dev libc6-i386 libcloog-isl4 libdb5.3 libfontconfig1 libjasper1 libqt5qml5 libqt5quick5 libtbb2 libtimezonemap-data libtimezonemap1 multiarch-support python3-apport python3-problem-report qml-module-qtquick-localstorage qml-module-qtquick-window2 qml-module-qtquick2 qtdeclarative5-localstorage-plugin qtdeclarative5-qtquick2-plugin syslinux syslinux-common 32 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 21.4 MB of archives. After this operation, 2,157 kB of additional disk space will be used. As none of these packages seem directly related, but libc is being updated, I'm wondering if the issue is a ABI mismatch in a codepath only being triggered on Utopic Unity systems (as I also noticed that network- manager seemingly wasn't rebuilt at any time during Utopic). So my next test is a no-change rebuild of network-manager for Utopic... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Er, I mean an ABI mismatched in policykit-1, not network-manager -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
To eliminate more variables, I just tried xubuntu 14.10 (with nvidia-343 from ppa:system76-dev/stable)... and I can connect to password-protected WiFi just fine. As Xubuntu and Ubuntu are using most of the same lower-level stack, this kinda suggests the problem is fairly high-level, potentially even Unity specific. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
More variables eliminated: this bug does *not* occur on: - Ubuntu GNOME 14.10 - Ubuntu MATE 14.10 - Kubuntu 14.10 - Xubuntu 14.10 (as mentioned above) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Still no solution, but I've at least (hopefully) eliminated some more variables. As I know this problem doesn't currently exist on Vivid, I tried back- porting `network-manager` and `network-manager-applet` from Vivid, but no luck... same problem still exists. And on the off chance that this is kernel-related, I also tried the 3.16 kernel on Trusty... but connecting to WiFi still works fine, so it doesn't seem to have anything to do with the kernel version. However, I have noticed some differences in the Dbus processes running an a system with Nvidia hardware vs a system with an Intel GPU, so I'm further investigating that today... Also, I'm not that familiar with network-manager, so if you have any advice for how I could get you better debugging information, please let me know! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Hmm, after more careful investigation, I think my hunch about differences in the DBus related process was a dead end. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Also tried back-porting `policykit-1` (which needed a back-port of `glib2.0` and `gobject-introspection`)... still no luck. But at this point, the delta between Utopic and Vivid is still pretty small, so I feel this is a promising avenue, at least as far as shot- gunning goes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
You'd think it wouldn't be related to the nvidia driver... but it definitely is. At System76, we've frequently encountered scattered problems like this. The nvidia proprietary effects the boot sequence enough (for example, no kms) that it frequently exposes subtle problems in the overall structure of the upstart jobs, usually related to timing issues. My hunch is some upstart job actually should depend on an event that it doesn't, but without the nvidia proprietary driver installed, this job works correctly by chance because this event will usually have already happened. This might not be a network-manager problem, but that's where the symptom is occurring. My current hunch is this might be related to nvidia-persistenced being started via udev in Utopic, vs Upstart in Trusty and older. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in “network-manager” package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Oh, and a little more detail on why I'm certain this is related to the nvidia proprietary driver... Part of our QA process after we image a system (before it's shipped to the customer) is to test WiFi. Since we started shipping Utopic, we've had 0% failure on systems with Intel graphics. On hardware with an nvidia GPU (for which we always pre-install the proprietary driver), we've had 100% failure when the system has an SSD for the OS drive. When the OS is on an HDD, it often works, but sometimes there are failures there too. You can work around this by going into Edit connections and entering your password for the wifi there. But the proper password dialog fails to pop-up when you just click on the wifi name in the indicator. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in “network-manager” package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
Okay, think I just found a lead in /var/log/upstart/lightdm.log: /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf Failed to get D-Bus connection /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file /etc/modprobe.d is not a file update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in “network-manager” package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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 1388130] Re: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
BTW, it was the Failed to get D-Bus connection bit above that seems problematic. Also, looking in syslog, there are some interesting tidbits: Nov 21 13:17:45 system76-pc NetworkManager[977]: info (wlan0): device state change: config - need-auth (reason 'none') [50 60 0] Nov 21 13:17:45 system76-pc NetworkManager[977]: info Activation (wlan0) Stage 2 of 5 (Device Configure) complete. Nov 21 13:17:45 system76-pc NetworkManager[977]: warn No agents were available for this request. Nov 21 13:17:45 system76-pc NetworkManager[977]: info (wlan0): device state change: need-auth - failed (reason 'no-secrets') [60 120 7] No agents were available for this request... is the agent in a separate process, something you'd connect to through dbus? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1388130 Title: Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD Status in System76: Triaged Status in “network-manager” package in Ubuntu: Confirmed Bug description: For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD. Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine. The failure message is: Connection activation failed. (1) Creation of object for path '/org/freedesktop/NetworkManager/ActiveConnection/2' failed in libnm-glib See the attached screenshot. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: network-manager 0.9.8.8-0ubuntu28 ProcVersionSignature: Ubuntu 3.16.0-24.32-generic 3.16.4 Uname: Linux 3.16.0-24-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Fri Oct 31 08:58:25 2014 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback IpRoute: default via 10.17.76.1 dev eth0 proto static 10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) nmcli-con: NAME UUID TYPE TIMESTAMPTIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH system76_5g d7cafbd5-f1ef-422d-9ed4-4b3a9095b234 802-11-wireless 0never yes no /org/freedesktop/NetworkManager/Settings/1 Wired connection 1c52af28c-07c5-4140-bf2c-3f0d236a05fc 802-3-ethernet1414767492 Fri 31 Oct 2014 08:58:12 AM MDTyes no /org/freedesktop/NetworkManager/Settings/0 nmcli-dev: DEVICE TYPE STATE DBUS-PATH wlan0 802-11-wireless disconnected /org/freedesktop/NetworkManager/Devices/1 eth0 802-3-ethernetconnected /org/freedesktop/NetworkManager/Devices/0 nmcli-nm: RUNNING VERSIONSTATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running 0.9.8.8connected enabled enabled enabledenabled disabled To manage notifications about this bug go to: https://bugs.launchpad.net/system76/+bug/1388130/+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
