Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

2020-12-08 Thread Josh Jones
Amazing, that has taught me something very useful!

shutdown-log.txt attached and error is visible!

Josh

On Sun, 2020-12-06 at 21:36 +0100, Michael Biebl wrote:
> Am Sonntag, den 06.12.2020, 19:28 +0100 schrieb Michael Biebl:
> > Am 06.12.20 um 17:04 schrieb Josh Jones:
> > > It is the root filesystem which is failing to be remounted read-
> > > only -
> > > this is a simple setup with only one filesystem for the whole
> > > system.
> > > 
> > > It seems to be happening right at the very very end of the
> > > shutdown
> > > sequence - I have attached a picture of the error; quality is
> > > poor
> > > because I had to capture it from video footage. Is there any way
> > > to
> > > even have anything saved to disk so late in the sequence?
> > 
> > With the shutdown hook described in README.Debian and 
> > https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
> > (install the hook as /lib/systemd/system-shutdown/debug.sh without
> > the 
> > /usr prefix) you can gather logs right until the end
> > 
> > 
> 
> Copy the attached script to /lib/systemd/system-shutdown/, make it
> executable with chmod +x, then add 
> systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
> to the kernel command line and after the reboot, attach the file
> /shutdown-log.txt to this bug report.
> 
> Michael
[0.00] Linux version 4.19.0-13-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-13-amd64 
root=UUID=7900bc19-0f2b-463a-b20c-fca3956fd844 ro quiet splash nomodeset
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
[0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
[0.00] BIOS-e820: [mem 0x40005000-0xc8c37fff] usable
[0.00] BIOS-e820: [mem 0xc8c38000-0xc97d1fff] reserved
[0.00] BIOS-e820: [mem 0xc97d2000-0xc985efff] usable
[0.00] BIOS-e820: [mem 0xc985f000-0xc98f] ACPI NVS
[0.00] BIOS-e820: [mem 0xc990-0xca0a2fff] reserved
[0.00] BIOS-e820: [mem 0xca0a3000-0xca15cfff] type 20
[0.00] BIOS-e820: [mem 0xca15d000-0xca15dfff] usable
[0.00] BIOS-e820: [mem 0xca15e000-0xca1a0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xca1a1000-0xcabecfff] usable
[0.00] BIOS-e820: [mem 0xcabed000-0xcaff1fff] reserved
[0.00] BIOS-e820: [mem 0xcaff2000-0xcaff] usable
[0.00] BIOS-e820: [mem 0xcb80-0xcf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI=0xc98f  ACPI 2.0=0xc98f  SMBIOS=0xf04c0  
MPS=0xfd560 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.7 present.
[0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme6, 
BIOS P2.80 07/01/2013
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3400.112 MHz processor
[0.001358] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.001359] e820: remove [mem 0x000a-0x000f] usable
[0.001366] last_pfn = 0x42f600 max_arch_pfn = 0x4
[0.001369] MTRR default type: uncachable
[0.00137

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

2020-12-01 Thread Josh Jones
No worries - I will send you the debug journal at the next package update - or 
if I have time tomorrow I will try to install outdated versions of the packages 
last updated to force it to happen. Whatever is happening is pretty consistent 
for me by the looks of it.

I have just enabled persistent logging.

Josh

On 1 December 2020 22:46:47 GMT+00:00, Michael Biebl  wrote:
>Control: tags -1 unreproducible
>
>Am 01.12.20 um 18:02 schrieb Josh Jones:
>> Sorry which log do you mean by debug journal log? Apologies for my
>> ignorance.
>> 
>> (Incidentally this problem has occured on two out of three offline
>> updates in recent days)
>
>So, I tried this in a test VM.
>The offline update went just fine (see attached journal.txt), so I
>can't 
>reproduce the issue locally and we will need at the very least at 
>journal log.
>
>Michael


Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

2020-12-01 Thread Josh Jones
Sorry which log do you mean by debug journal log? Apologies for my
ignorance.

(Incidentally this problem has occured on two out of three offline
updates in recent days)

On Sun, 2020-11-29 at 19:45 +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> Am 29.11.20 um 19:23 schrieb Josh:
> > Package: systemd
> > Version: 241-7~deb10u4
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > On two recent clean installations of Buster, I am noticing that
> > choosing to
> > install package updates through gnome-software, and therefore the
> > systemd
> > offline update system, results in the root filesystem not being
> > unmounted
> > properly once packages are installed and therefore gives an fsck
> > error on
> > reboot:
> > 
> > Failed to remount '/' read-only; Device or resource busy
> > 
> > Followed by journal recovery on reboot.
> > 
> > I haven't noticed any serious problems subsequently but it seems
> > like asking
> > for trouble for the filesystem to not be cleanly unmounted right
> > after packages
> > are updated. I have seen this on two machines, neither using 3rd
> > party repos
> > etc.
> 
> Can you please provide a (debug) journal log from such an offline
> update.
> 
> Michael