[Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
And by the way, I just tested the old setup with your full recommendation, adding the BEFORE= statement and it finally stopped the I/O errors. I can now take the time to transition properly. Thank you! Pedro -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
** Attachment added: "systemd-analyze dot graph" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+attachment/5492912/+files/USRgraph.svg -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
** Attachment added: "Services, hook, and journal after adding AFTER= and REQUIRES=" https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+attachment/5492904/+files/buglog.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
Christian I set this up back when without properly researching systemd.mount, particularly the automatic dependencies. I make half of the changes you recommended (Requires=virt-guest-shutdown.target; After=virt-guest- shutdown.target) and it made no change, the I/O errors still showed up. I'm attaching the custom systemd services and the libvirt hook for your information. But, instead of following in the direction of a custom setup I will transition this to /etc/fstab parent/child mounts (the child mount is a .vhd file on the parent fs that will now be mounted using the loop device instead of nbd) and a simpler libvirt hook with mount/umount functionality. Sorry for making this more complicated than they should have been. Regards Pedro -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
Hi Christian, Thanks for your attention. I replicated the issue and here is the journal log for today. Regards Pedro Serrano On Wed, 2021-04-21 at 11:08 +, Christian Ehrhardt wrote: > Hi Pedro, > > > Wouldn't it be beneficial for all guests to be shutdown before > unmounting all filesystems? > > Yes on first sight that looks like a compelling suggestion. > But i've learned the hard way that usually adding dependencies > eventually breaks more things than it fixes - so let us first try to > understand what to expect and what happened. > > > The ordering at the moment includes: > - libvirt-guests.service > - virt-guest-shutdown.target > - libvirtd.service > > Of these the "big one" is libvirtd.service which has > After=network.target > After=local-fs.target > After=remote-fs.target > And many more which imply further lateness on startup. > > libvirt-guests.service is what shuts down the guests and starts as > After=libvirtd.service > and thereby after all of the above. > > virt-guest-shutdown.target exists to allow people to hook arbitrary > things into this chain in case any thing needs to be done. > Note: In most cases it is better t identify what a local system has > that makes it special and set it up to go down before this. See the > discussion and references from > https://bugzilla.redhat.com/show_bug.cgi?id=1401054 for this. > > On shutdown usually the order of these is reversed - I'd expect that > libvirt-guests.service needs to stop before libvirtd.service stops > (which also is reasonable as it needs to interact with libvirt). > And libvirt.service should need to be passed to leave the > local/remote-FS targets on the way out, but targets might be more > special in this regard. > > Therefore the question becomes - which FS or FS-target was > stopped/cut in your case before libvirt.service was stopped. > Could you maybe share the journal of that boot so that we can try to > dissect what was going down beofore it? > > You can access those with > $ journalctl --list-boots > And then select the right one and redirect it into a file like > $ journalctl -b > logfile > > ** Bug watch added: Red Hat Bugzilla #1401054 > https://bugzilla.redhat.com/show_bug.cgi?id=1401054 > > ** Changed in: libvirt (Ubuntu) > Status: New => Incomplete > ** Attachment added: "ps01ubx-journalctl-2021-04-23-1441.txt" https://bugs.launchpad.net/bugs/1924494/+attachment/5491583/+files/ps01ubx-journalctl-2021-04-23-1441.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1924494] Re: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
Sure can. I'm away but should have access to that laptop tomorrow afternoon. Would it matter if I re-created the conditions and sent you that journal? On Apr 21, 2021, 07:21, at 07:21, "Christian Ehrhardt " <1924...@bugs.launchpad.net> wrote: >Hi Pedro, > >> Wouldn't it be beneficial for all guests to be shutdown before >unmounting all filesystems? > >Yes on first sight that looks like a compelling suggestion. >But i've learned the hard way that usually adding dependencies >eventually breaks more things than it fixes - so let us first try to >understand what to expect and what happened. > > >The ordering at the moment includes: >- libvirt-guests.service >- virt-guest-shutdown.target >- libvirtd.service > >Of these the "big one" is libvirtd.service which has > After=network.target > After=local-fs.target > After=remote-fs.target >And many more which imply further lateness on startup. > >libvirt-guests.service is what shuts down the guests and starts as > After=libvirtd.service >and thereby after all of the above. > >virt-guest-shutdown.target exists to allow people to hook arbitrary >things into this chain in case any thing needs to be done. >Note: In most cases it is better t identify what a local system has >that makes it special and set it up to go down before this. See the >discussion and references from >https://bugzilla.redhat.com/show_bug.cgi?id=1401054 for this. > >On shutdown usually the order of these is reversed - I'd expect that >libvirt-guests.service needs to stop before libvirtd.service stops >(which also is reasonable as it needs to interact with libvirt). >And libvirt.service should need to be passed to leave the >local/remote-FS targets on the way out, but targets might be more >special in this regard. > >Therefore the question becomes - which FS or FS-target was stopped/cut >in your case before libvirt.service was stopped. >Could you maybe share the journal of that boot so that we can try to >dissect what was going down beofore it? > >You can access those with >$ journalctl --list-boots >And then select the right one and redirect it into a file like >$ journalctl -b > logfile > >** Bug watch added: Red Hat Bugzilla #1401054 > https://bugzilla.redhat.com/show_bug.cgi?id=1401054 > >** Changed in: libvirt (Ubuntu) > Status: New => Incomplete > >-- >You received this bug notification because you are subscribed to the >bug >report. >https://bugs.launchpad.net/bugs/1924494 > >Title: > Systemd shutdown order unmounts filesystem used by qemu/kvm guest > before shutting down the guest > >Status in libvirt package in Ubuntu: > Incomplete > >Bug description: > Last night I started a reboot without manually shutting down a > qemu/kvm guest first. After X went down a bunch of I/O errors > associated with a network block device that contains a NTFS filesystem > showed up on the console. I noticed that the umount.target had been > reached but the virt-guest-shutdown.target was still waiting for the > guest to shut down, until it timed out. > > Wouldn't it be beneficial for all guests to be shutdown before > unmounting all filesystems? > > ProblemType: Bug > DistroRelease: Ubuntu 20.10 > Package: systemd 246.6-1ubuntu1.3 > ProcVersionSignature: Ubuntu 5.8.0-49.55-generic 5.8.18 > Uname: Linux 5.8.0-49-generic x86_64 > ApportVersion: 2.20.11-0ubuntu50.5 > Architecture: amd64 > CasperMD5CheckResult: skip > Date: Thu Apr 15 08:35:48 2021 > InstallationDate: Installed on 2021-01-17 (88 days ago) >InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 >(20200731) > MachineType: HP HP ZBook 15u G6 >ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-49-generic >root=UUID=25df7fed-1baf-421e-941e-7f7c280db6e8 ro iommu=pt >intel_iommu=on default_hugepagesz=1G hugepagesz=1G hugepages=6 >pcie_aspm.policy=performance > SourcePackage: systemd > UpgradeStatus: Upgraded to groovy on 2021-04-08 (6 days ago) > dmi.bios.date: 01/08/2021 > dmi.bios.release: 8.1 > dmi.bios.vendor: HP > dmi.bios.version: R70 Ver. 01.08.01 > dmi.board.name: 8549 > dmi.board.vendor: HP > dmi.board.version: KBC Version 52.67.00 > dmi.chassis.type: 10 > dmi.chassis.vendor: HP > dmi.ec.firmware.release: 82.103 >dmi.modalias: >dmi:bvnHP:bvrR70Ver.01.08.01:bd01/08/2021:br8.1:efr82.103:svnHP:pnHPZBook15uG6:pvr:rvnHP:rn8549:rvrKBCVersion52.67.00:cvnHP:ct10:cvr: > dmi.product.family: 103C_5336AN HP ZBook > dmi.product.name: HP ZBook 15u G6 > dmi.product.sku: 9AP56LP#ABA > dmi.sys.vendor: HP > >To manage notifications about this bug go to: >https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1924494/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to:
[Bug 1924494] [NEW] Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest
Public bug reported: Last night I started a reboot without manually shutting down a qemu/kvm guest first. After X went down a bunch of I/O errors associated with a network block device that contains a NTFS filesystem showed up on the console. I noticed that the umount.target had been reached but the virt-guest-shutdown.target was still waiting for the guest to shut down, until it timed out. Wouldn't it be beneficial for all guests to be shutdown before unmounting all filesystems? ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.6-1ubuntu1.3 ProcVersionSignature: Ubuntu 5.8.0-49.55-generic 5.8.18 Uname: Linux 5.8.0-49-generic x86_64 ApportVersion: 2.20.11-0ubuntu50.5 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Apr 15 08:35:48 2021 InstallationDate: Installed on 2021-01-17 (88 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) MachineType: HP HP ZBook 15u G6 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.8.0-49-generic root=UUID=25df7fed-1baf-421e-941e-7f7c280db6e8 ro iommu=pt intel_iommu=on default_hugepagesz=1G hugepagesz=1G hugepages=6 pcie_aspm.policy=performance SourcePackage: systemd UpgradeStatus: Upgraded to groovy on 2021-04-08 (6 days ago) dmi.bios.date: 01/08/2021 dmi.bios.release: 8.1 dmi.bios.vendor: HP dmi.bios.version: R70 Ver. 01.08.01 dmi.board.name: 8549 dmi.board.vendor: HP dmi.board.version: KBC Version 52.67.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 82.103 dmi.modalias: dmi:bvnHP:bvrR70Ver.01.08.01:bd01/08/2021:br8.1:efr82.103:svnHP:pnHPZBook15uG6:pvr:rvnHP:rn8549:rvrKBCVersion52.67.00:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.product.name: HP ZBook 15u G6 dmi.product.sku: 9AP56LP#ABA dmi.sys.vendor: HP ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug groovy -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924494 Title: Systemd shutdown order unmounts filesystem used by qemu/kvm guest before shutting down the guest To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1924494/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1774731] Re: Missing "/sys/module/dummy/parameters/" subdir on dummy module
Same result: echo "dummy" >> /etc/modules echo "options dummy numdummies=4" >> /etc/modprobe.d/dummy-options.conf Reboot... lsmod|grep dummy ; SHOWS THE dummy MODULE LOADED. no dummy devices are created. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1774731 Title: Missing "/sys/module/dummy/parameters/" subdir on dummy module To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774731/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1657837] Re: systemd-networkd can't add a VLAN interface to bridge
And the error messages pertinent to the issue with the VLAN are: = may 01 11:34:31 ps01lnx systemd[1]: Started Network Service. may 01 11:34:31 ps01lnx systemd[1]: systemd-networkd.service: Failed to send unit change signal for systemd-networkd.service: Connection reset by peer may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0lcl1: IPv6 disabled for interface: Success may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0lcl1: Could not append VLANs: Operation not permitted may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0lcl1: Failed to assign VLANs to bridge port: Operation not permitted may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0lcl1: Could not set bridge vlan: Operation not permitted may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p0: IPv6 disabled for interface: Success may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p1: IPv6 disabled for interface: Success may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0lcl1: Configured may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p0: Configured may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p1: Configured = As you can see, the bridge and the two ports (tap devices) were configured. But the bridge VLAN did not receive the intended configuration, and the tap devices failed to be associated with the bridge. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1657837 Title: systemd-networkd can't add a VLAN interface to bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1657837/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1657837] Re: systemd-networkd can't add a VLAN interface to bridge
Nope, it is still a problem in "systemd 231-9ubuntu4 amd64". Actually, it seems like multiple features documented in the Ubuntu Manpages for systemd.network are not functioning. Below are some error messages (journalctl -a -u systemd-networkd), followed by the configuration files. ERROR MESSAGES - START may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p1: MAC configured for tap, ignoring may 01 11:34:31 ps01lnx systemd-networkd[30661]: ovsbr0p0: MAC configured for tap, ignoring may 01 11:34:31 ps01lnx systemd-networkd[30661]: [/etc/systemd/network/7-ovsbr0lcl1.netdev:8] Unknown lvalue 'DefaultPVID' in section 'Bridge' may 01 11:34:31 ps01lnx systemd-networkd[30661]: [/etc/systemd/network/7-ovsbr0lcl1.netdev:10] Unknown lvalue 'STP' in section 'Bridge' may 01 11:34:31 ps01lnx systemd-networkd[30661]: NetDev with invalid Kind configured in /etc/systemd/network/3-vlan1.netdev. Ignoring may 01 11:34:31 ps01lnx systemd-networkd[30661]: [/etc/systemd/network/9-ovsbr0p1.network:9] Unknown lvalue 'bridge' in section 'Network' may 01 11:34:31 ps01lnx systemd-networkd[30661]: [/etc/systemd/network/9-ovsbr0p0.network:9] Unknown lvalue 'bridge' in section 'Network' ERROR MESSAGES - END SYSTEMD CONFIGURATION systemctl enable systemd-networkd === /etc/systemd/network/3-vlan1.netdev === [Netdev] Name=br0vlan1 Kind=vlan [VLAN] Id=1 === /etc/systemd/network/3-vlan1.network === [Match] Name=br0vlan1 [Network] Bridge=ovsbr0lcl1 === /etc/systemd/network/7-ovsbr0lcl1.netdev === [NetDev] Name=ovsbr0lcl1 Kind=bridge MTUBytes=8996 MACAddress=52:54:00:5a:9e:90 [Bridge] DefaultPVID=1 VLANFiltering=true STP=false === /etc/systemd/network/7-ovsbr0p0.netdev === [NetDev] Name=ovsbr0p0 Kind=tap MACAddress=52:54:00:5a:9e:92 === /etc/systemd/network/7-ovsbr0p1.netdev === [NetDev] Name=ovsbr0p1 Kind=tap MACAddress=52:54:00:5a:9e:93 === /etc/systemd/network/8-ovsbr0lcl1.link === [Match] MACAddress=52:54:00:5a:9e:90 OriginalName=ovsbr0lcl1 Driver=bridge [Link] Name=ovsbr0lcl1 Alias=br0lcl1 MACAddressPolicy=persistent MTUBytes=8996 === /etc/systemd/network/8-ovsvbr0p0.link === [Match] OriginalName=ovsbr0p0 MACAddress=52:54:00:5a:9e:92 [Link] MTUBytes=8996 MACAddress=52:54:00:5a:9e:92 === /etc/systemd/network/8-ovsvbr0p1.link === [Match] OriginalName=ovsbr0p1 [Link] MTUBytes=8996 MACAddress=52:54:00:5a:9e:93 === /etc/systemd/network/9-ovsbr0lcl1.network === [Match] Name=ovsbr0lcl1 MACAddress=52:54:00:5a:9e:90 [Link] MACAddress=52:54:00:5a:9e:90 MTUBytes=8996 [Network] DHCP=no Address=192.168.56.1/24 LinkLocalAddressing=no MulticastDNS=false IPv6AcceptRA=false === /etc/systemd/network/9-ovsbr0p0.network === [Match] Name=ovsbr0p0 [Link] MACAddress=52:54:00:5a:9e:92 MTUBytes=8996 [Network] bridge=ovsbr0lcl1 Address=192.168.56.2/24 LinkLocalAddressing=no MulticastDNS=false IPv6AcceptRA=false [BridgeVLAN] VLAN=1 EgressUntagged=1 PVID=1 === /etc/systemd/network/9-ovsbr0p1.network === [Match] Name=ovsbr0p1 [Link] MACAddress=52:54:00:5a:9e:93 MTUBytes=8996 [Network] bridge=ovsbr0lcl1 Address=192.168.56.3/24 LinkLocalAddressing=no MulticastDNS=false IPv6AcceptRA=false [BridgeVLAN] VLAN=1 EgressUntagged=1 PVID=1 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1657837 Title: systemd-networkd can't add a VLAN interface to bridge To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1657837/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1430313] [NEW] package menu 2.1.47ubuntu1 failed to install/upgrade: triggers looping, abandoned
Public bug reported: just doing an apt-get update apt-get dist-upgrade on ubuntu 15.04 ProblemType: Package DistroRelease: Ubuntu 15.04 Package: menu 2.1.47ubuntu1 Uname: Linux 3.19.0-031900-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.16.2-0ubuntu2 Architecture: amd64 Date: Tue Mar 10 08:52:07 2015 DuplicateSignature: package:menu:2.1.47ubuntu1:triggers looping, abandoned ErrorMessage: triggers looping, abandoned InstallationDate: Installed on 2015-01-15 (53 days ago) InstallationMedia: Xubuntu 15.04 Vivid Vervet - Alpha amd64 (20150115) SourcePackage: menu Title: package menu 2.1.47ubuntu1 failed to install/upgrade: triggers looping, abandoned UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: menu (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package vivid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1430313 Title: package menu 2.1.47ubuntu1 failed to install/upgrade: triggers looping, abandoned To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/menu/+bug/1430313/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1378802] [NEW] update-manager Couldn't connect to accessibility bus
Public bug reported: ** (update-manager:7750): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-GxEtj3txBA: Connection refused Always happens when using update-manager.. System originally installed from Trusty media, upgraded to Utopic. Happened in both. Amongst kernels used are: 3.15, 3.16.0.20, 3.17. Same error. Current kernel: Linux ps01lnx 3.17.0-031700-generic #201410060605 SMP Mon Oct 6 10:07:09 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Description:Ubuntu Utopic Unicorn (development branch) Release:14.10 dbus: Installed: 1.8.8-1ubuntu2 Candidate: 1.8.8-1ubuntu2 Version table: *** 1.8.8-1ubuntu2 0 500 http://us.archive.ubuntu.com/ubuntu/ utopic/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: dbus 1.8.8-1ubuntu2 Uname: Linux 3.17.0-031700-generic x86_64 ApportVersion: 2.14.7-0ubuntu5 Architecture: amd64 Date: Wed Oct 8 08:28:33 2014 InstallationDate: Installed on 2014-07-01 (98 days ago) InstallationMedia: Xubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140416.2) SourcePackage: dbus UpgradeStatus: No upgrade log present (probably fresh install) upstart.dbus.log: g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. ** Affects: dbus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1378802 Title: update-manager Couldn't connect to accessibility bus To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1378802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
