[Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
That's because what I instructed in #15 makes laptop-mode-tools ineffective to USB hotplug events. Not something that a user would want. As I see from the reports, this is what I think is happening. 1) Users have some combination of usb devices, getting hotplugged upon discovery. 2) Step 1 results in early invocation of LMT. 3) Which further results in file systems getting ro mounted. This step is still erratic and I have no clue what the calling parent is, to this ro mount. For users who've confirmed that #15 in the workaround works. Can you please apply the workaround, successfully boot, then change back the changes to its original, and then hotplug a USB device ? This will trigger the same chain of events, just that they'll be triggered upon full boot. Which should give us some insight into what may actually be behaving erratic. -- 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/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in systemd package in Debian: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23
Re: [Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
Okay. Thanks for the reports. It could very well be the flakiness in usb devices that are causing this problem. Anyways, the best fix for this is to contain usb execution to the runtime module only. Note to self: per module activation was reported to not activating general power savings. Check those before any conclusions s3nt fr0m a $martph0ne, excuse typ0s On 11-Jan-2018 15:56, "Douw Steyn" <1726...@bugs.launchpad.net> wrote: > Works for me too with Ubuntu 17.10 on an Acer Extensa laptop (i5-6200U > SkyLake). Same symptoms but changing 'force' to 'auto' as above results > in successful booting from battery. > > -- > You received this bug notification because you are subscribed to laptop- > mode-tools in Ubuntu. > https://bugs.launchpad.net/bugs/1726930 > > Title: > System fails to start (boot) on battery due to read-only root file- > system > > Status in laptop-mode-tools package in Ubuntu: > Confirmed > Status in systemd package in Ubuntu: > Confirmed > Status in systemd package in Debian: > Fix Released > > Bug description: > This report is to capture the extended diagnostic efforts done on IRC > #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was > upgraded from 17.04 to 17.10 and since fails to complete start-up of > services when powered on battery. > > We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" > workaround in case this was an ACPI DSDT issue. > > This appears to be due to a read-only root file-system. What is not > clear is how the rootfs goes read-only. > > The file-system (sda6, ext4) is fsck-ed successfully in the initrd > according to the /run/initramfs/fsck.log. > > From the start-up logs (with "systemd.log_level=debug") we see the > ext4 driver report a remount operation not once but five times. > > $ grep 'EXT4-fs.*sda6' systemd-debug.log > Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with > ordered data mode. Opts: (null) > Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro > Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > > Those last five appear to be carrying options generated by laptop- > mode-tools. > > User has disabled laptop-mode.service and laptop-mode.timer, and lmt- > poll.service, but the issue remains. > > We see several reports of "read-only file-system": > > $ grep 'Read-only' systemd-debug.log > Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot > open `/boot/grub/grubenv': Read-only file system. > Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' > task: Read-only file system > Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to > /var/log/gpu-manager.log failed (Read-only file system) > Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to > run 'start' task: Read-only file system > Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to > run 'start' task: Read-only file system > Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: > Read-only file system > ... > Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of > "/var/log/cups" - Read-only file system > Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file > "/var/log/cups/access_log" - Read-only file system > Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to > open /var/log/lastlog: Read-only file system > > We also see several problems with systemd's connection to Dbus: > > $ grep 'Transport endpoint' systemd-debug.log > Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for > 773: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send > unit change signal for systemd-logind.service: Transport endpoint is not > connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 156: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit > change signal for lmt-poll.service: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 182: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 95: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit > change signal for polkit.service: Transport endpo
[Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
Thanks for confirming @reckenrode. I'd appreciate if more users confirmed the same. -- 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/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in systemd package in Debian: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change signal for polkit.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send unit change signal for cups-browsed.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 161: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: gdomap.service: Failed to send unit change signal for gdomap.service: Transport endpoint is not connected When the user purged laptop-mode-tools the system starts successfully on battery. The user instal
[Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
This would still be a flaky device or a kernel bug. Because the mentioned laptop-mode-tools version (1.71) brought in forced execution mode, so that it could apply proper power saving values. That's pretty much it. That does not result in read only rootfs because if it logically did, it'd be seen on every machine. BTW, does Ubuntu have the systemd/udevd mount propagation fix included ? -- 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/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in systemd package in Debian: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change signal for polkit.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send unit change signal for cups-browsed.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job re
[Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
Folks... Does changing to following in /lib/udev/rules.d/99-laptop-mode.rules help ? ACTION=="add", SUBSYSTEM=="usb", RUN+="lmt-udev auto" -- 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/1726930 Title: System fails to start (boot) on battery due to read-only root file- system Status in laptop-mode-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in systemd package in Debian: Fix Released Bug description: This report is to capture the extended diagnostic efforts done on IRC #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was upgraded from 17.04 to 17.10 and since fails to complete start-up of services when powered on battery. We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" workaround in case this was an ACPI DSDT issue. This appears to be due to a read-only root file-system. What is not clear is how the rootfs goes read-only. The file-system (sda6, ext4) is fsck-ed successfully in the initrd according to the /run/initramfs/fsck.log. From the start-up logs (with "systemd.log_level=debug") we see the ext4 driver report a remount operation not once but five times. $ grep 'EXT4-fs.*sda6' systemd-debug.log Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: errors=remount-ro,data=ordered,commit=600 Those last five appear to be carrying options generated by laptop- mode-tools. User has disabled laptop-mode.service and laptop-mode.timer, and lmt- poll.service, but the issue remains. We see several reports of "read-only file-system": $ grep 'Read-only' systemd-debug.log Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot open `/boot/grub/grubenv': Read-only file system. Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to /var/log/gpu-manager.log failed (Read-only file system) Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to run 'start' task: Read-only file system Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: Read-only file system ... Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of "/var/log/cups" - Read-only file system Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file "/var/log/cups/access_log" - Read-only file system Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to open /var/log/lastlog: Read-only file system We also see several problems with systemd's connection to Dbus: $ grep 'Transport endpoint' systemd-debug.log Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send unit change signal for systemd-logind.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 156: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit change signal for lmt-poll.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 182: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 95: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit change signal for polkit.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send unit change signal for cups-browsed.service: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for 773: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for 161: Transport endpoint is not connected Oct 23 18:10:46 T450s systemd[1]: gdomap.service: Failed to send unit change signal for gdomap.service: Transport endpoint is not connected When the user purged laptop-mode-tools the sy
Re: [Touch-packages] [Bug 1726930] Re: System fails to start (boot) on battery due to read-only root file-system
This must be an Ubuntu specific problem. I haven't encountered the problem upstream. https://GitHub.com/rickysarraf/laptop-mode-tools s3nt fr0m a $martph0ne, excuse typ0s On 07-Dec-2017 02:36, "timor" <1726...@bugs.launchpad.net> wrote: > Uninstalling laptop-mode-tools helped me, but it's useful package and it > would be nice to get it back. > > -- > You received this bug notification because you are subscribed to laptop- > mode-tools in Ubuntu. > https://bugs.launchpad.net/bugs/1726930 > > Title: > System fails to start (boot) on battery due to read-only root file- > system > > Status in laptop-mode-tools package in Ubuntu: > Confirmed > Status in systemd package in Ubuntu: > Confirmed > Status in systemd package in Debian: > Fix Released > > Bug description: > This report is to capture the extended diagnostic efforts done on IRC > #ubuntu for user maszlo, who has a Lenovo T450 with SSD that was > upgraded from 17.04 to 17.10 and since fails to complete start-up of > services when powered on battery. > > We'd previously applied the "acpi=os=! 'acpi_osi=Windows 2015'" > workaround in case this was an ACPI DSDT issue. > > This appears to be due to a read-only root file-system. What is not > clear is how the rootfs goes read-only. > > The file-system (sda6, ext4) is fsck-ed successfully in the initrd > according to the /run/initramfs/fsck.log. > > From the start-up logs (with "systemd.log_level=debug") we see the > ext4 driver report a remount operation not once but five times. > > $ grep 'EXT4-fs.*sda6' systemd-debug.log > Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): mounted filesystem with > ordered data mode. Opts: (null) > Oct 23 18:10:44 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro > Oct 23 18:10:46 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:47 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:48 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > Oct 23 18:10:49 T450s kernel: EXT4-fs (sda6): re-mounted. Opts: > errors=remount-ro,data=ordered,commit=600 > > Those last five appear to be carrying options generated by laptop- > mode-tools. > > User has disabled laptop-mode.service and laptop-mode.timer, and lmt- > poll.service, but the issue remains. > > We see several reports of "read-only file-system": > > $ grep 'Read-only' systemd-debug.log > Oct 23 18:10:46 T450s grub-common[1792]: grub-editenv: error: cannot > open `/boot/grub/grubenv': Read-only file system. > Oct 23 18:10:46 T450s systemd[1]: colord.service: Failed to run 'start' > task: Read-only file system > Oct 23 18:10:46 T450s gpu-manager[1797]: Warning: writing to > /var/log/gpu-manager.log failed (Read-only file system) > Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to > run 'start' task: Read-only file system > Oct 23 18:10:46 T450s systemd[1]: systemd-resolved.service: Failed to > run 'start' task: Read-only file system > Oct 23 18:10:46 T450s gdm3[1932]: Failed to create LogDir /var/log/gdm3: > Read-only file system > ... > Oct 23 18:11:26 T450s cupsd[1461]: Unable to change ownership of > "/var/log/cups" - Read-only file system > Oct 23 18:11:26 T450s cupsd[1461]: Unable to open log file > "/var/log/cups/access_log" - Read-only file system > Oct 23 18:12:52 T450s login[9248]: pam_lastlog(login:session): unable to > open /var/log/lastlog: Read-only file system > > We also see several problems with systemd's connection to Dbus: > > $ grep 'Transport endpoint' systemd-debug.log > Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for > 773: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: systemd-logind.service: Failed to send > unit change signal for systemd-logind.service: Transport endpoint is not > connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 156: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: lmt-poll.service: Failed to send unit > change signal for lmt-poll.service: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 182: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job remove signal for > 95: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: polkit.service: Failed to send unit > change signal for polkit.service: Transport endpoint is not connected > Oct 23 18:10:46 T450s systemd[1]: cups-browsed.service: Failed to send > unit change signal for cups-browsed.service: Transport endpoint is not > connected > Oct 23 18:10:46 T450s systemd[1]: Failed to send job change signal for > 773: Transport
[Touch-packages] [Bug 1438758] Re: User to root privilege escalation (ab)using the crash forwarding feature of apport
This was fixed in the upload of apport 2.17.3-1 to Debian Experimental ** Changed in: apport (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1438758 Title: User to root privilege escalation (ab)using the crash forwarding feature of apport Status in Apport: Fix Released Status in apport package in Ubuntu: Fix Released Status in apport source package in Trusty: Fix Released Status in apport source package in Utopic: Fix Released Status in apport source package in Vivid: Fix Released Status in apport package in Debian: Fix Released Bug description: Back in Ubuntu 14.04, I introduced an apport feature that will have it forward any crash to another apport running in the task's namespace (in the case where the pid of the task in its namespace isn't equal to that in the host namespace). This feature simply checks for the presence of /usr/share/apport/apport in the task's root directory. If it exists, it will chroot and exec the script. The problem is that as apport is a coredump handler triggered by the kernel, it'll always run as real root, regardless of the crashed task's owner and namespace. This therefore allows an unprivileged user to craft a specific filesystem structure, pivot_root to it, then crash a process inside it, causing apport outside of the namespace to execute a script as real root. By bind-mounting /proc from the host into that namespace, the unprivileged user can then access any file on the host as real root, causing the privilege escalation. An exploit is attached to this bug. It's been confirmed to be runnable as a nobody user on a regular Ubuntu system and to successfully read any file on the host. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1438758/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1399037] [NEW] apt-get can not simulate
On 12/04/2014 06:39 AM, Svivi wrote: > Public bug reported: > > Hi, > > I just noticed that apt can not simulate in Ubuntu 14.04.1. > > sudo apt-get -s dselect-upgrade > E: A(z) „s” parancssori kapcsoló [a következőből: -s] ismeretlen. > > sudo apt-get --dry-run dselect-upgrade > E: --dry-run parancssori kapcsoló értelmezhetetlen > > sudo apt-get --recon dselect-upgrade > E: --recon parancssori kapcsoló értelmezhetetlen > > sudo apt-get --just-print dselect-upgrade > E: --just-print parancssori kapcsoló értelmezhetetlen > > sudo apt-get --just-print dselect-upgrade > E: --just-print parancssori kapcsoló értelmezhetetlen > > sudo apt-get --just-print dselect-upgrade > E: --just-print parancssori kapcsoló értelmezhetetlen > > > The issue occures with at least the following versions of apt: > 1.0.1ubuntu2.4.1, 1.0.1ubuntu2.5 > It works fine on Ubuntu 12.04 with: 0.8.16~exp12ubuntu10.22 What is the version of apt-offline you are using ? Also, I cannot make out the non-english error message. There were issues, that were fixed upstream in version 1.5 of apt-offline. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention." -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1399037 Title: apt-get can not simulate Status in apt package in Ubuntu: Confirmed Bug description: Hi, I just noticed that apt can not simulate in Ubuntu 14.04.1. sudo apt-get -s dselect-upgrade E: A(z) „s” parancssori kapcsoló [a következőből: -s] ismeretlen. sudo apt-get --dry-run dselect-upgrade E: --dry-run parancssori kapcsoló értelmezhetetlen sudo apt-get --recon dselect-upgrade E: --recon parancssori kapcsoló értelmezhetetlen sudo apt-get --just-print dselect-upgrade E: --just-print parancssori kapcsoló értelmezhetetlen sudo apt-get --just-print dselect-upgrade E: --just-print parancssori kapcsoló értelmezhetetlen sudo apt-get --just-print dselect-upgrade E: --just-print parancssori kapcsoló értelmezhetetlen The issue occures with at least the following versions of apt: 1.0.1ubuntu2.4.1, 1.0.1ubuntu2.5 It works fine on Ubuntu 12.04 with: 0.8.16~exp12ubuntu10.22 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1399037/+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
