[Touch-packages] [Bug 1831747] [NEW] fixrtc hook requires e2fsprogs package, but that is not a dependency
Public bug reported: Package "initramfs-tools-core" provides "/usr/share/initramfs- tools/hooks/fixrtc" which runs during the update or regeneration of the initramfs and requires the file "/sbin/dumpe2fs" (available from "e2fsprogs") to be present, otherwise it fails and aborts the whole process, leading e.g. to an inconsistent package system. The problem/cause seems to be that "initramfs-tools-core" package has no direct or indirect hard dependency on "e2fsprogs". I believe either the package dependency should be added, or the fixrtc hook script should be rewritten so that it just outputs a warning instead of aborting with a failure if missing "dumpe2fs" is not a critical problem. This issue seems to affect at least Ubuntu 16.04 and 18.04. It has been brought to my attention at https://askubuntu.com/q/1148791/367990 ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New -- 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/1831747 Title: fixrtc hook requires e2fsprogs package, but that is not a dependency Status in initramfs-tools package in Ubuntu: New Bug description: Package "initramfs-tools-core" provides "/usr/share/initramfs- tools/hooks/fixrtc" which runs during the update or regeneration of the initramfs and requires the file "/sbin/dumpe2fs" (available from "e2fsprogs") to be present, otherwise it fails and aborts the whole process, leading e.g. to an inconsistent package system. The problem/cause seems to be that "initramfs-tools-core" package has no direct or indirect hard dependency on "e2fsprogs". I believe either the package dependency should be added, or the fixrtc hook script should be rewritten so that it just outputs a warning instead of aborting with a failure if missing "dumpe2fs" is not a critical problem. This issue seems to affect at least Ubuntu 16.04 and 18.04. It has been brought to my attention at https://askubuntu.com/q/1148791/367990 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831747/+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 1689825] Re: gnome-keyring not unlocked on boot
It might have changed in the newer releases of Ubuntu, but on 16.04 (Unity desktop) `dbus-user-session` is NOT installed by default and NOT a dependency of any standard packages. I myself got it as dependency of Anbox. Now that this is gone, the only remaining thing that points to this package is `dbus`, but as a suggestion. Suggestions are optional dependencies that do not automatically get installed unless you explicitly command `apt` to do so. Also if you would remove something which another (meta-)package recommends or suggests (not hard dependencies), that wouldn't uninstall this other package. And even if so, in case of the desktop meta-packages like `ubuntu-desktop` it would not make a difference anyway, as these don't have a function other than initially installing all stuff. No harm in them being removed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1689825 Title: gnome-keyring not unlocked on boot Status in D-Bus: New Status in chromium-browser package in Ubuntu: Invalid Status in flatpak package in Ubuntu: Confirmed Status in gdm package in Ubuntu: Confirmed Status in gnome-keyring package in Ubuntu: Confirmed Status in libgnome-keyring package in Ubuntu: Confirmed Status in lightdm package in Ubuntu: Confirmed Bug description: 1) Release: 16.04.2 2) gnome-keyring: 3.18.3-0ubuntu2 3) Login. gnome-keyring unlocks "login" features including for google chrome 4) gnome-keyring is not unlocked, chrome takes 2 minutes to open and with no secure password features(sync) functioning. For the past couple days, chrome on Ubuntu 16.04 takes a REALLY long time (maybe 2 minutes) to start. Once chrome is started, I am not able to sync and any secure password features are broken. I found out this is due to gnome-keyring not being unlocked at login. There's also no way to unlock the "login" portion of the keyring from the running daemon by default. I have to kill the gnome-keyring process and start without "--login" as a parameter. Then the "login" section shows up which I'm able to unlock. From there chrome starts up instantly but asks the following: Enter password to unlock your login keyring The login keyring did not get unlocked when you logged into your computer After that, all of it's sync and secure features are functional. Starting google-chrome-stable from a command line at boot without running the above workaround shows the following error messages: Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [4364:4393:0510/100407.740292:ERROR:token_service_table.cc(130)] Failed to decrypt token for service AccountId-108842767310111573264 [4364:4445:0510/100407.740292:ERROR:gcm_store_impl.cc(929)] Failed to restore security token. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: gnome-keyring 3.18.3-0ubuntu2 ProcVersionSignature: Ubuntu 4.8.0-52.55~16.04.1-generic 4.8.17 Uname: Linux 4.8.0-52-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: GNOME-Flashback:Unity Date: Wed May 10 09:43:37 2017 SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1689825/+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 1689825] Re: gnome-keyring not unlocked on boot
Seems to me like `dbus-user-session` was the real culprit causing all the trouble. I got it installed with anbox and that is when the problem started. I got my keyring daemon to correctly start, the Login keyring to unlock automatically while still being encrypted with my account password again this way: - Purge `dbus-user-session`, e.g. by running `sudo apt purge dbus-user-session` - Revert files in `/etc/pam.d` back to their original state. I had commented out a line in `/etc/pam.d/lightdm` to work around the `gnome-keyring-daemon` not starting in the correct mode issue. - Set my account password on the Login keyring again (using seahorse). I had removed the password and left the keyring unprotected to avoid being asked for the password each session. - Set my user account password to something completely different and then back to my normal password using the `passwd` command. Before doing this, it seemed like the Login keyring and account password weren't yet synced correctly despite being equal. When I rebooted before the `passwd`, it still asked for the keyring password to be entered manually. - Reboot. On my next login, it asked for the Login keyring password to be entered manually one last time, but offered a checkbox to enable unlocking that keyring automatically on boot, which I checked. After this procedure, my system seems to be as good as new again. Running 16.04 with vanilla Unity desktop and lightdm btw. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1689825 Title: gnome-keyring not unlocked on boot Status in D-Bus: New Status in chromium-browser package in Ubuntu: Invalid Status in flatpak package in Ubuntu: Confirmed Status in gdm package in Ubuntu: Confirmed Status in gnome-keyring package in Ubuntu: Confirmed Status in libgnome-keyring package in Ubuntu: Confirmed Status in lightdm package in Ubuntu: Confirmed Bug description: 1) Release: 16.04.2 2) gnome-keyring: 3.18.3-0ubuntu2 3) Login. gnome-keyring unlocks "login" features including for google chrome 4) gnome-keyring is not unlocked, chrome takes 2 minutes to open and with no secure password features(sync) functioning. For the past couple days, chrome on Ubuntu 16.04 takes a REALLY long time (maybe 2 minutes) to start. Once chrome is started, I am not able to sync and any secure password features are broken. I found out this is due to gnome-keyring not being unlocked at login. There's also no way to unlock the "login" portion of the keyring from the running daemon by default. I have to kill the gnome-keyring process and start without "--login" as a parameter. Then the "login" section shows up which I'm able to unlock. From there chrome starts up instantly but asks the following: Enter password to unlock your login keyring The login keyring did not get unlocked when you logged into your computer After that, all of it's sync and secure features are functional. Starting google-chrome-stable from a command line at boot without running the above workaround shows the following error messages: Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [4364:4393:0510/100407.740292:ERROR:token_service_table.cc(130)] Failed to decrypt token for service AccountId-108842767310111573264 [4364:4445:0510/100407.740292:ERROR:gcm_store_impl.cc(929)] Failed to restore security token. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: gnome-keyring 3.18.3-0ubuntu2 ProcVersionSignature: Ubuntu 4.8.0-52.55~16.04.1-generic 4.8.17 Uname: Linux 4.8.0-52-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 CurrentDesktop: GNOME-Flashback:Unity Date: Wed May 10 09:43:37 2017 SourcePackage: gnome-keyring UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/dbus/+bug/1689825/+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 1609469] [NEW] Battery reported as "discharging" when 100% charged although on AC power
Public bug reported: I'm on an Acer Aspire E5-773G which is currently connected to AC power and has its battery fully charged. Nevertheless, `upower` reports the battery status as "discharging" and also the standard Unity power indicator shows the normal full-battery icon (not charging) and a percentage of 100%. ANd what is even more strange is that the battery's "energy-full" value suddenly is bigger than "energy-full-design" although it used to slowly decrease during the last months and was a few percent below last time I checked. This is the `upower --dump` output: Device: /org/freedesktop/UPower/devices/line_power_ADP1 native-path: ADP1 power supply: yes updated: Mi 03 Aug 2016 13:04:03 CEST (14551 seconds ago) has history: no has statistics: no line-power warning-level: none online: yes icon-name: 'ac-adapter-symbolic' Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: SANYO model:AL15A32 serial: 41547 power supply: yes updated: Mi 03 Aug 2016 17:06:34 CEST (0 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: discharging warning-level: none energy: 34,9872 Wh energy-empty:0 Wh energy-full: 37,0444 Wh energy-full-design: 37 Wh energy-rate: 10,3452 W voltage: 17,321 V time to empty: 3,4 hours percentage: 100% capacity:100% technology: lithium-ion icon-name: 'battery-full-symbolic' Device: /org/freedesktop/UPower/devices/DisplayDevice power supply: yes updated: Mi 03 Aug 2016 17:02:03 CEST (271 seconds ago) has history: no has statistics: no battery present: yes state: discharging warning-level: none energy: 34,9872 Wh energy-full: 37,0444 Wh energy-rate: 10,3452 W time to empty: 3,4 hours percentage: 100% icon-name: 'battery-full-symbolic' Daemon: daemon-version: 0.99.4 on-battery: no lid-is-closed: no lid-is-present: yes critical-action: PowerOff ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: upower 0.99.4-2ubuntu0.3 ProcVersionSignature: Ubuntu 4.4.0-31.50-generic 4.4.13 Uname: Linux 4.4.0-31-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CurrentDesktop: Unity Date: Wed Aug 3 17:35:20 2016 InstallationDate: Installed on 2016-05-04 (90 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: upower UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: upower (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upower in Ubuntu. https://bugs.launchpad.net/bugs/1609469 Title: Battery reported as "discharging" when 100% charged although on AC power Status in upower package in Ubuntu: New Bug description: I'm on an Acer Aspire E5-773G which is currently connected to AC power and has its battery fully charged. Nevertheless, `upower` reports the battery status as "discharging" and also the standard Unity power indicator shows the normal full-battery icon (not charging) and a percentage of 100%. ANd what is even more strange is that the battery's "energy-full" value suddenly is bigger than "energy-full-design" although it used to slowly decrease during the last months and was a few percent below last time I checked. This is the `upower --dump` output: Device: /org/freedesktop/UPower/devices/line_power_ADP1 native-path: ADP1 power supply: yes updated: Mi 03 Aug 2016 13:04:03 CEST (14551 seconds ago) has history: no has statistics: no line-power warning-level: none online: yes icon-name: 'ac-adapter-symbolic' Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: BAT0 vendor: SANYO model:AL15A32 serial: 41547 power supply: yes updated: Mi 03 Aug 2016 17:06:34 CEST (0 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable:yes state: discharging warning-level: none energy: 34,9872 Wh energy-empty:0 Wh energy-full:
[Touch-packages] [Bug 1536930] Re: package rsync 3.1.1-3ubuntu0.15.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
I have a similar error, but the `insserv` line that gets repeated almost infinitely looks like this here: insserv: Starting fruhod depends on ondemand and therefore on system facility `$all' which can not be true! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1536930 Title: package rsync 3.1.1-3ubuntu0.15.10.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Status in rsync package in Ubuntu: Confirmed Bug description: Настраивается пакет rsync (3.1.1-3ubuntu0.15.10.1) … insserv: warning: script 'K07smfpd' missing LSB tags and overrides insserv: warning: script 'smfpd' missing LSB tags and overrides insserv: There is a loop at service rc.local if started insserv: There is a loop between service rc.local and urandom if started insserv: loop involving service urandom at depth 4 insserv: loop involving service hwclock at depth 3 insserv: There is a loop between service smfpd and udev if started insserv: loop involving service udev at depth 1 insserv: loop involving service networking at depth 6 insserv: loop involving service mountdevsubfs at depth 3 insserv: loop involving service mountkernfs at depth 1 insserv: There is a loop at service smfpd if started insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility `$all' which can not be true! insserv: Starting smfpd depends on rc.local and therefore on system facility
