Debian Bug report logs - #788050
systemd-fsck : Check disks at each reboot

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Ludovic Lebègue <ludovic@lebegue.org>

To: Debian submit Bugs <submit@bugs.debian.org>

Subject: systemd-fsck : Check disks at each reboot

Date: Mon, 08 Jun 2015 08:01:40 +0200

[Message part 1 (text/plain, inline)]

Package: systemd
Version: 220-4
Severity: important

Dear maintainer.

For a few days now each time the computer boots it forces a file system
check on two of my disks.

Here is the relevant journalctl entry :

Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
as /devices/platform/i8042/serio1/input/input8
Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... fsck.ext4
for device /dev/sdb1 exited with signal 13.
Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
8.
Jun 08 07:50:50 leonardo systemd-fsck[459]: Ignoring error.
Jun 08 07:50:50 leonardo systemd[1]: Started File System Check
on /dev/disk/by-uuid/553ea986-223e-4391-89be-c9da0c2fa197.
Jun 08 07:50:50 leonardo systemd[1]: Mounting /home...
Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): warning: maximal mount
count reached, running e2fsck is recommended
Jun 08 07:50:50 leonardo systemd[1]: Mounted /home.
Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): mounted filesystem with
ordered data mode. Opts: (null)
Jun 08 07:51:32 leonardo systemd-fsck[460]: fsck: Warning... fsck.ext4
for device /dev/sdc1 exited with signal 13.
Jun 08 07:51:32 leonardo systemd-fsck[460]: fsck failed with error code
8.
Jun 08 07:51:32 leonardo systemd-fsck[460]: Ignoring error.
Jun 08 07:51:32 leonardo systemd[1]: Started File System Check
on /dev/disk/by-uuid/63556323-3f4f-471e-a052-ea0e3e53d3ea.
Jun 08 07:51:32 leonardo systemd[1]: Mounting /backup...
Jun 08 07:51:32 leonardo kernel: EXT4-fs (sdc1): warning: maximal mount
count reached, running e2fsck is recommended
Jun 08 07:51:32 leonardo kernel: EXT4-fs (sdc1): mounted filesystem with
ordered data mode. Opts: (null)
Jun 08 07:51:32 leonardo systemd[1]: Mounted /backup.

Regards 

Ludovic Lebègue

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.113+nmu3
ii  libacl1         2.2.52-2
ii  libapparmor1    2.9.2-3
ii  libaudit1       1:2.4-1+b1
ii  libblkid1       2.26.2-6
ii  libc6           2.19-18
ii  libcap2         1:2.24-8
ii  libcap2-bin     1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20     1.6.3-2
ii  libkmod2        20-1
ii  liblzma5        5.1.1alpha+20120614-2+b3
ii  libmount1       2.26.2-6
ii  libpam0g        1.1.8-3.1
ii  libselinux1     2.3-2
ii  libsystemd0     220-4
ii  mount           2.26.2-6
ii  sysv-rc         2.88dsf-59.2
ii  udev            220-4
ii  util-linux      2.26.2-6

Versions of packages systemd recommends:
ii  dbus            1.8.18-1
ii  libpam-systemd  220-4

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- no debconf information

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ludovic Lebègue <ludovic@lebegue.org>, 788050@bugs.debian.org

Cc: e2fsprogs@packages.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Mon, 08 Jun 2015 10:26:25 +0200

[Message part 1 (text/plain, inline)]

Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue:

> For a few days now each time the computer boots it forces a file system
> check on two of my disks.
> 
> Here is the relevant journalctl entry :
> 
> Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
> as /devices/platform/i8042/serio1/input/input8
> Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... fsck.ext4
> for device /dev/sdb1 exited with signal 13.
> Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
> 8.
> Jun 08 07:50:50 leonardo systemd-fsck[459]: Ignoring error.
> Jun 08 07:50:50 leonardo systemd[1]: Started File System Check
> on /dev/disk/by-uuid/553ea986-223e-4391-89be-c9da0c2fa197.
> Jun 08 07:50:50 leonardo systemd[1]: Mounting /home...
> Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): warning: maximal mount
> count reached, running e2fsck is recommended
> Jun 08 07:50:50 leonardo systemd[1]: Mounted /home.
> Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): mounted filesystem with
> ordered data mode. Opts: (null)
> Jun 08 07:51:32 leonardo systemd-fsck[460]: fsck: Warning... fsck.ext4
> for device /dev/sdc1 exited with signal 13.

Afaics, the underlying problem is, that fsck fails to fix the problems.
So it's rerun on each boot.

What odd though, return code 13 is the sum of

1      Filesystem errors corrected
4      Filesystem errors left uncorrected
8      Operational error

So, fsck at the same time says the errors were corrected, on the other
side it says they weren't.
Am I interpreting the return codes correctly?

CCed the e2fsprogs maintainers for input.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #15 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Ludovic Lebègue <ludovic@lebegue.org>, 788050@bugs.debian.org

Cc: e2fsprogs@packages.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Mon, 08 Jun 2015 10:48:49 +0200

[Message part 1 (text/plain, inline)]

Am 08.06.2015 um 10:26 schrieb Michael Biebl:
> Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue:
> 
>> For a few days now each time the computer boots it forces a file system
>> check on two of my disks.
>>
>> Here is the relevant journalctl entry :
>>
>> Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
>> as /devices/platform/i8042/serio1/input/input8
>> Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... fsck.ext4
>> for device /dev/sdb1 exited with signal 13.
>> Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
>> 8.

[..]

> Afaics, the underlying problem is, that fsck fails to fix the problems.
> So it's rerun on each boot.
> 
> What odd though, return code 13 is the sum of
> 
> 1      Filesystem errors corrected
> 4      Filesystem errors left uncorrected
> 8      Operational error
> 
> So, fsck at the same time says the errors were corrected, on the other
> side it says they weren't.
> Am I interpreting the return codes correctly?
> 
> CCed the e2fsprogs maintainers for input.

Sorry, somehow I completely overlooked the "signal" string.
So signal 13 means SIGPIPE, pitti suspects a communication error between
fsck -C   <-> systemd-fsck and the actual return code is 8, i.e.
Operational error.

He also points out, that systemd ignores any return codes from fsck
other then 2 and 6.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Ludovic Lebègue <ludovic@lebegue.org>

To: Michael Biebl <biebl@debian.org>

Cc: 788050@bugs.debian.org, e2fsprogs@packages.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Thu, 11 Jun 2015 08:03:46 +0200

[Message part 1 (text/plain, inline)]

Hi 

A workaround is to boot in maintenance mode.
The disks are then correctly checked and next normal boot is ok

Regards

Ludovic


On Mon, 2015-06-08 at 10:26 +0200, Michael Biebl wrote:
> Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue:
> 
> > For a few days now each time the computer boots it forces a file system
> > check on two of my disks.
> > 
> > Here is the relevant journalctl entry :
> > 
> > Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
> > as /devices/platform/i8042/serio1/input/input8
> > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... fsck.ext4
> > for device /dev/sdb1 exited with signal 13.
> > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with error code
> > 8.
> > Jun 08 07:50:50 leonardo systemd-fsck[459]: Ignoring error.
> > Jun 08 07:50:50 leonardo systemd[1]: Started File System Check
> > on /dev/disk/by-uuid/553ea986-223e-4391-89be-c9da0c2fa197.
> > Jun 08 07:50:50 leonardo systemd[1]: Mounting /home...
> > Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): warning: maximal mount
> > count reached, running e2fsck is recommended
> > Jun 08 07:50:50 leonardo systemd[1]: Mounted /home.
> > Jun 08 07:50:50 leonardo kernel: EXT4-fs (sdb1): mounted filesystem with
> > ordered data mode. Opts: (null)
> > Jun 08 07:51:32 leonardo systemd-fsck[460]: fsck: Warning... fsck.ext4
> > for device /dev/sdc1 exited with signal 13.
> 
> Afaics, the underlying problem is, that fsck fails to fix the problems.
> So it's rerun on each boot.
> 
> What odd though, return code 13 is the sum of
> 
> 1      Filesystem errors corrected
> 4      Filesystem errors left uncorrected
> 8      Operational error
> 
> So, fsck at the same time says the errors were corrected, on the other
> side it says they weren't.
> Am I interpreting the return codes correctly?
> 
> CCed the e2fsprogs maintainers for input.
> 

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Paul Menzel <pm.debian@googlemail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org, Ludovic Lebègue <ludovic@lebegue.org>

Cc: e2fsprogs@packages.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 05 Jul 2015 15:28:31 +0200

[Message part 1 (text/plain, inline)]

Dear Debian folks,


Am Montag, den 08.06.2015, 10:48 +0200 schrieb Michael Biebl:
> Am 08.06.2015 um 10:26 schrieb Michael Biebl:
> > Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue:
> > 
> > > For a few days now each time the computer boots it forces a file 
> > > system
> > > check on two of my disks.
> > > 
> > > Here is the relevant journalctl entry :
> > > 
> > > Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
> > > as /devices/platform/i8042/serio1/input/input8
> > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... 
> > > fsck.ext4
> > > for device /dev/sdb1 exited with signal 13.
> > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with 
> > > error code
> > > 8.
> 
> […]
> 
> > Afaics, the underlying problem is, that fsck fails to fix the 
> > problems.
> > So it's rerun on each boot.
> > 
> > What odd though, return code 13 is the sum of
> > 
> > 1      Filesystem errors corrected
> > 4      Filesystem errors left uncorrected
> > 8      Operational error
> > 
> > So, fsck at the same time says the errors were corrected, on the 
> > other
> > side it says they weren't.
> > Am I interpreting the return codes correctly?
> > 
> > CCed the e2fsprogs maintainers for input.
> 
> Sorry, somehow I completely overlooked the "signal" string.
> So signal 13 means SIGPIPE, pitti suspects a communication error 
> between fsck -C   <-> systemd-fsck and the actual return code is 8, 
> i.e. Operational error.
> 
> He also points out, that systemd ignores any return codes from fsck
> other then 2 and 6.

I am still experiencing this error in Debian Sid/unstable. Could the
cause be pinpointed? Please tell me, if you need more debug information
from an affected system.


Thanks,

Paul

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Paul Menzel <pm.debian@googlemail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org, Ludovic Lebègue <ludovic@lebegue.org>

Cc: e2fsprogs@packages.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Thu, 09 Jul 2015 08:46:19 +0200

[Message part 1 (text/plain, inline)]

Dear Debian folks,


Am Sonntag, den 05.07.2015, 15:28 +0200 schrieb Paul Menzel:

> Am Montag, den 08.06.2015, 10:48 +0200 schrieb Michael Biebl:
> > Am 08.06.2015 um 10:26 schrieb Michael Biebl:
> > > Am 08.06.2015 um 08:01 schrieb Ludovic Lebègue:
> > > 
> > > > For a few days now each time the computer boots it forces a 
> > > > file 
> > > > system
> > > > check on two of my disks.
> > > > 
> > > > Here is the relevant journalctl entry :
> > > > 
> > > > Jun 08 07:48:19 leonardo kernel: input: PS/2 Generic Mouse
> > > > as /devices/platform/i8042/serio1/input/input8
> > > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck: Warning... 
> > > > fsck.ext4
> > > > for device /dev/sdb1 exited with signal 13.
> > > > Jun 08 07:50:50 leonardo systemd-fsck[459]: fsck failed with 
> > > > error code
> > > > 8.
> > 
> > […]
> > 
> > > Afaics, the underlying problem is, that fsck fails to fix the 
> > > problems.
> > > So it's rerun on each boot.
> > > 
> > > What odd though, return code 13 is the sum of
> > > 
> > > 1      Filesystem errors corrected
> > > 4      Filesystem errors left uncorrected
> > > 8      Operational error
> > > 
> > > So, fsck at the same time says the errors were corrected, on the 
> > > other side it says they weren't.
> > > Am I interpreting the return codes correctly?
> > > 
> > > CCed the e2fsprogs maintainers for input.
> > 
> > Sorry, somehow I completely overlooked the "signal" string.
> > So signal 13 means SIGPIPE, pitti suspects a communication error 
> > between fsck -C   <-> systemd-fsck and the actual return code is 8, 
> > 
> > i.e. Operational error.
> > 
> > He also points out, that systemd ignores any return codes from fsck
> > other then 2 and 6.
> 
> I am still experiencing this error in Debian Sid/unstable. Could the
> cause be pinpointed? Please tell me, if you need more debug 
> information from an affected system.

Just another observation, that during the fsck run, there is that
systemd time-out message for a unit shown after a while.


Thanks,

Paul

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Simon Dreher <simon.dreher@gmx.net>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 26 Jul 2015 23:03:11 +0200

Hi,

>>>>> For a few days now each time the computer boots it forces a 
>>>>> file system check on two of my disks.
>>>>> 
>>>>> [...]
>> 
>> I am still experiencing this error in Debian Sid/unstable. Could
>> the cause be pinpointed? Please tell me, if you need more debug 
>> information from an affected system.
> 
> Just another observation, that during the fsck run, there is that 
> systemd time-out message for a unit shown after a while.

Since one of my latest system upgrade on, I also get fsck runs every
system boot.
dumpe2fs -h /dev/sda7
tells me

[...]
Filesystem state:         clean
[...]
Last mount time:          Sun Jul 26 21:02:29 2015
Last write time:          Sun Jul 26 21:02:29 2015
Mount count:              46
Maximum mount count:      30
Last checked:             Sat Jun  6 21:18:06 2015
[...]

i.e. it seems that the check doesn't finish. Maybe with a timeout -
which is really bad, as file system checks may take quite a while.

Simon

Message #40 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Fri, 14 Aug 2015 10:13:25 +0200

Dear maintainer,

I also think there is is a timeout problem.
I Use lvm2 with md software raid based on ext3.
Systemd file system checks at boot-up on small partitions finish 
successfull on big partitions end with error 13.
Manual executed file system check on these big partitions end 
successfull and on the next boot-ups no errors appear until new fsck is 
triggered by reaching boot count limit.

Message #45 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Allen Webb <vertago1@gmail.com>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Wed, 23 Sep 2015 11:08:57 -0500

On Fri, 14 Aug 2015 10:13:25 +0200 Axel Ludszuweit 
<axel.ludszuweit@htp-tel.de> wrote:
> Dear maintainer,
>
> I also think there is is a timeout problem.
> I Use lvm2 with md software raid based on ext3.
> Systemd file system checks at boot-up on small partitions finish
> successfull on big partitions end with error 13.
> Manual executed file system check on these big partitions end
> successfull and on the next boot-ups no errors appear until new fsck is
> triggered by reaching boot count limit.
>
>
>
>

I am running into this same issue downstream testing ubuntu 15.10. My 
small partitions check fine, but one that takes a lot longer to check is 
always fails the check during startup. I thought the problem might be 
related to either dm-raid or a timeout, but if other people are having 
the problem it is probably a timeout or race condition between other 
services. When I run a manual fsck.ext4, I have no issues at all so it 
seems to be an integration problem with systemd.

Message #50 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Allen Webb <vertago1@gmail.com>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Wed, 23 Sep 2015 19:33:03 +0200

[Message part 1 (text/plain, inline)]

Am 23.09.2015 um 18:08 schrieb Allen Webb:
> On Fri, 14 Aug 2015 10:13:25 +0200 Axel Ludszuweit 
> <axel.ludszuweit@htp-tel.de> wrote:
>  > Dear maintainer,
>  >
>  > I also think there is is a timeout problem.
>  > I Use lvm2 with md software raid based on ext3.
>  > Systemd file system checks at boot-up on small partitions finish
>  > successfull on big partitions end with error 13.
>  > Manual executed file system check on these big partitions end
>  > successfull and on the next boot-ups no errors appear until new fsck is
>  > triggered by reaching boot count limit.
>  >
>  >
>  >
>  >
> 
> I am running into this same issue downstream testing ubuntu 15.10. My 
> small partitions check fine, but one that takes a lot longer to check is 
> always fails the check during startup. I thought the problem might be 
> related to either dm-raid or a timeout, but if other people are having 
> the problem it is probably a timeout or race condition between other 
> services. When I run a manual fsck.ext4, I have no issues at all so it 
> seems to be an integration problem with systemd.

We suspect that this is related to systemd-fsckd, a Debian/Ubuntu
addition to provide fsck progress feedback for plymouth.

If you boot without "splash" on the kernel command line, does it make a
difference?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #55 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

To: 788050@bugs.debian.org

Date: Wed, 23 Sep 2015 20:40:58 +0200

Dear maintainer,


Konsole output

axel@kruemel:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.1.0-2-amd64 root=/dev/mapper/OS_1-root ro
axel@kruemel:~$

Therefore I think, that I am not using the splash option.

Plymouth is not installed.
Maybe the fstab is helpful:


Konsole output
axel@kruemel:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc                     /proc           proc       defaults 
               0  0
/dev/mapper/OS_1-root    /               ext3        errors=remount-ro 
     0  1
/dev/md0                 /boot           ext3        defaults 
              0  2
/dev/mapper/data_1-home  /files1         ext3        defaults 
              0  2
/dev/mapper/data_2-files /files2         ext3        defaults 
              0  2
/dev/mapper/data_1-files /home           ext3        defaults 
              0  2
/dev/mapper/OS_1-opt     /opt            ext3        defaults 
              0  2
/dev/mapper/OS_1-tmp     /tmp            ext3        defaults 
              0  2
/dev/mapper/OS_1-usr     /usr            ext3        defaults 
              0  2
/dev/mapper/OS_1-var     /var            ext3        defaults 
              0  2
/dev/mapper/data_1-swap  none            swap        sw 
                    0  0
/dev/scd0                /media/cdrom0   udf,iso9660 user,noauto 
           0  0
/dev/fd0                 /media/floppy0  auto        rw,user,noauto 
        0  0
## usbfs is the USBUSERS group in fstab file:
# none                     /proc/bus/usb   usbfs 
      devgid=126,devmode=664 0 0

Message #60 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Allen Webb <vertago1@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Thu, 24 Sep 2015 10:23:34 -0500

I edited the /etc/default/grub file, removed splash from 
"GRUB_CMDLINE_LINUX_DEFAULT" and ran update-grub2. To force the fsck I used:
sudo tune2fs -C 30 <device>
and had to reboot twice. I saw the fsck progress, but it still stopped 
at the same time and gave an operation error / sigpipe.

On 09/23/2015 12:33 PM, Michael Biebl wrote:
> Am 23.09.2015 um 18:08 schrieb Allen Webb:
>> On Fri, 14 Aug 2015 10:13:25 +0200 Axel Ludszuweit
>> <axel.ludszuweit@htp-tel.de> wrote:
>>   > Dear maintainer,
>>   >
>>   > I also think there is is a timeout problem.
>>   > I Use lvm2 with md software raid based on ext3.
>>   > Systemd file system checks at boot-up on small partitions finish
>>   > successfull on big partitions end with error 13.
>>   > Manual executed file system check on these big partitions end
>>   > successfull and on the next boot-ups no errors appear until new fsck is
>>   > triggered by reaching boot count limit.
>>   >
>>   >
>>   >
>>   >
>>
>> I am running into this same issue downstream testing ubuntu 15.10. My
>> small partitions check fine, but one that takes a lot longer to check is
>> always fails the check during startup. I thought the problem might be
>> related to either dm-raid or a timeout, but if other people are having
>> the problem it is probably a timeout or race condition between other
>> services. When I run a manual fsck.ext4, I have no issues at all so it
>> seems to be an integration problem with systemd.
> We suspect that this is related to systemd-fsckd, a Debian/Ubuntu
> addition to provide fsck progress feedback for plymouth.
>
> If you boot without "splash" on the kernel command line, does it make a
> difference?
>
>

Message #65 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Allen Webb <vertago1@gmail.com>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Thu, 24 Sep 2015 12:23:16 -0500

I can confirm that this fix works on my system.

On 09/24/2015 11:32 AM, Michael Biebl wrote:
> Am 24.09.2015 um 17:46 schrieb hannu.tmp@pp.inet.fi:
>> This works for me:
>>
>> copy /lib/systemd/system/systemd-fsckd.service to /etc/systemd/system
>>
>> edit /etc/systemd/system/systemd-fsckd.service, add TimeoutStartSec under [Service]
>>
>> [Service]
>> TimeoutStartSec=60min
> Hm, good point. We should probably disable the Timeout completely like
> in systemd-fsck-root.service and systemd-fsck@.service by setting
>
>
> TimeoutStartSec=0
>
> The default is 90s, and an fsck for a large disk can certainly take
> longer for ext3.
>
>

Message #70 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Balau <balau@users.sourceforge.net>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Wed, 14 Oct 2015 21:37:13 +0200

[Message part 1 (text/plain, inline)]

This was not enough on my system, fsck exited with signal 13 after 60s
anyway. This worked for me:

# systemctl mask systemd-fsckd.service systemd-fsckd.socket

At next boot, fsck ran for some minutes and then completed successfully.
Note that `systemctl disable` did not work because these units are static.
I don't have plymouth installed, I don't know if that's relevant.

systemd version 226-4

On Thu, 24 Sep 2015 12:23:16 -0500 Allen Webb <vertago1@gmail.com> wrote:
> I can confirm that this fix works on my system.
>
> On 09/24/2015 11:32 AM, Michael Biebl wrote:
> > Am 24.09.2015 um 17:46 schrieb hannu.tmp@pp.inet.fi:
> >> This works for me:
> >>
> >> copy /lib/systemd/system/systemd-fsckd.service to /etc/systemd/system
> >>
> >> edit /etc/systemd/system/systemd-fsckd.service, add TimeoutStartSec
under [Service]
> >>
> >> [Service]
> >> TimeoutStartSec=60min
> > Hm, good point. We should probably disable the Timeout completely like
> > in systemd-fsck-root.service and systemd-fsck@.service by setting
> >
> >
> > TimeoutStartSec=0
> >
> > The default is 90s, and an fsck for a large disk can certainly take
> > longer for ext3.

[Message part 2 (text/html, inline)]

Message #75 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

To: 788050@bugs.debian.org

Subject: systemd-fsck : Check disks at each reboot

Date: Fri, 23 Oct 2015 13:36:04 +0200

[Message part 1 (text/plain, inline)]

Dear maintainer,

according to the suggestion from message #65 I have increased the 
timeout to 30min.
But fsck still ends with error 13 checking big partitions. Manually fsck 
ends succeesfully.
It seems to be the same behaviour described in message #70.


<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788050#65>

[Message part 2 (text/html, inline)]

Message #80 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <Manuel.Bilderbeek@gmail.com>

To: Debian Bug Tracking System <788050@bugs.debian.org>

Subject: Re: systemd-fsck : Check disks at each reboot

Date: Sun, 15 Nov 2015 09:51:19 +0100

[Message part 1 (text/plain, inline)]

Package: systemd
Version: 227-3
Followup-For: Bug #788050

Dear Maintainer,

I'm also hit by this bug. Especially in combination with #804910 (see there),
this is really annoying.

I saw some workaround and suggestions, but is there already a direction of a
solution of this issue?

On my system, fsck'ing the 500GB HDD takes about 20 minutes. It's now aborted
after 9 and a half minutes, see #804910.

IMHO, you can't sensibly define a timeout for an fsck. I think it's better to
just 'trust' on it to be completed at some point (either with error or
success), because introducing a timeout seems to cause more issues than relying
on an exit. You can't ever guess what the timeout value should be. Who knows
what kinds of partitions people use...

So, can you please change the package such that the timeouts of fsck's are
disabled by default?

Thanks.

-- Package-specific info:

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser         3.113+nmu3
ii  libacl1         2.2.52-2
ii  libapparmor1    2.10-2+b1
ii  libaudit1       1:2.4.4-4
ii  libblkid1       2.27.1-1
ii  libc6           2.19-22
ii  libcap2         1:2.24-12
ii  libcap2-bin     1:2.24-12
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20     1.6.4-3
ii  libkmod2        21-1
ii  liblzma5        5.1.1alpha+20120614-2.1
ii  libmount1       2.27.1-1
ii  libpam0g        1.1.8-3.1
ii  libseccomp2     2.2.3-2
ii  libselinux1     2.3-2+b1
ii  libsystemd0     227-3
ii  mount           2.27.1-1
ii  sysv-rc         2.88dsf-59.2
ii  util-linux      2.27.1-1

Versions of packages systemd recommends:
ii  dbus            1.10.2-1
ii  libpam-systemd  227-3

Versions of packages systemd suggests:
pn  systemd-container  <none>
pn  systemd-ui         <none>

Versions of packages systemd is related to:
ii  udev  227-2

-- no debconf information

[systemd-delta.txt (text/plain, attachment)]

[systemd-analyze-dump.txt (text/plain, attachment)]

[dsh-enabled.txt (text/plain, attachment)]

[fstab (text/plain, attachment)]

Message #85 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Manuel Bilderbeek <Manuel.Bilderbeek@gmail.com>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 15 Nov 2015 10:06:53 +0100

[Message part 1 (text/plain, inline)]

Am 15.11.2015 um 09:51 schrieb Manuel Bilderbeek:
> Package: systemd
> Version: 227-3
> Followup-For: Bug #788050
> 
> Dear Maintainer,
> 
> I'm also hit by this bug. Especially in combination with #804910 (see there),
> this is really annoying.
> 
> I saw some workaround and suggestions, but is there already a direction of a
> solution of this issue?

I'm afraid not. Not being able to reproduce this issue (on my side)
makes this harder.

> On my system, fsck'ing the 500GB HDD takes about 20 minutes. It's now aborted
> after 9 and a half minutes, see #804910.
> 
> IMHO, you can't sensibly define a timeout for an fsck. I think it's better to
> just 'trust' on it to be completed at some point (either with error or
> success), because introducing a timeout seems to cause more issues than relying
> on an exit. You can't ever guess what the timeout value should be. Who knows
> what kinds of partitions people use...
> 
> So, can you please change the package such that the timeouts of fsck's are
> disabled by default?

I think the timeout in systemd-fsckd was a red herring.
For some other reason systemd-fsckd seems to kill the running fsck
process and we haven't figured out yet when and why.

Can you reproduce the issue reliably?

I tried it with an external USB 3TB hard drive, in a VM with a huge
interna ext3 disk. In both cases the fsck process took longer then the
default 3min default timeout and completed successfully.

So I guess we haven't found the real culprit yet.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #90 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 15 Nov 2015 10:49:47 +0100

Hi,

On 15-11-15 10:06, Michael Biebl wrote:
> I'm afraid not. Not being able to reproduce this issue (on my side)
> makes this harder.

> Can you reproduce the issue reliably?

So far it happened all 3 boots since the boot count became high enough 
to do an fsck. So I guess the answer is yes. Each boot I have to look 
for 10 minutes at an empty screen :P

> So I guess we haven't found the real culprit yet.

If there's anything I can do to help, let me know. Testing is easy 
enough, at least, it seems.

-- 
Kind regards,

Manuel

Message #95 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

To: 788050@bugs.debian.org

Subject: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 15 Nov 2015 11:04:19 +0100

Dear Maintainer,

I have converted my ext3 filesystem to ext4 to reduce time needed by fsck.
But the behaviour is still unchanged, fsck of big partition fails.

-- 
Axel Ludszuweit
In der Horst 28E
D-30900 Wedemark
Telefon: +49 (0) 5130 373093
Mobil:   +49 (0) 170 2736589

Message #100 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 29 Nov 2015 00:12:14 +0100

Hi again,

On 15-11-15 10:06, Michael Biebl wrote:
>> I saw some workaround and suggestions, but is there already a direction of a
>> solution of this issue?
>
> I'm afraid not. Not being able to reproduce this issue (on my side)
> makes this harder.
>
> Can you reproduce the issue reliably?

As I wrote before, I get this issue *each and every time* I boot my 
system at the moment. So, I'm having a 9.5 minute delay every time I 
start up my PC. (Which is daily.)

This is getting quite annoying, but the plus side is: as I can 100% 
reliably reproduce the issue, I am very much wanting to help you to 
investigate it.

But you need to tell me what I need to do to help you with this issue. 
Which output of which commands do you need? Which tests could we do?

How can I help?

If there's really nothing I can do (and you're sure about that!), I'd 
rather get rid of this long boot delay... I bought an SSD to be able to 
boot quickly and that joy is now totally destroyed! ;-)

-- 
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Message #105 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 29 Nov 2015 01:28:53 +0100

[Message part 1 (text/plain, inline)]

Am 29.11.2015 um 00:12 schrieb Manuel Bilderbeek:
> How can I help?

Describe your setup in as much detail as possible. LVM, RAID, fstab etc.

Can you reproduce the issue with arbitrary mounts?
Can you reproduce the issue with a minimal setup? On a different system?
Do you have any hints how we can reproduce it?
Does the problem go away if you use "systemctl mask
systemd-fsckd.service systemd-fsckd.socket"
Does journalctl -u systemd-fsckd.service produce anything interesting?

Can you boot with systemd.debug-shell on the kernel command line, and
then switch to tty9 while the fsck is running and attach strace to the
fsckd and fsck process?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #110 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 29 Nov 2015 14:29:01 +0100

On 29-11-15 01:28, Michael Biebl wrote:
> Am 29.11.2015 um 00:12 schrieb Manuel Bilderbeek:
>> How can I help?
>
> Describe your setup in as much detail as possible. LVM, RAID, fstab etc.

No RAID, no LVM. I've got a HDD and an SSD. I'm now booting from the SSD.

$ 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>
# / was on /dev/sdg1 during installation
UUID=8efc387d-cdc0-496d-8f3c-03cc7f4ac8a5 /               ext4 
errors=remount-ro,noatime 0       1
# swap was on /dev/sdg5 during installation
UUID=0a3f3e1b-1141-4033-b619-ec2f6d62b452 none            swap    sw 
          0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/sr1        /media/cdrom1   udf,iso9660 user,noauto     0       0
/dev/sda1       /media/olddisk1 ext4    ro,noatime   0       2
/dev/sda6       /media/olddisk6 ext4    rw,noatime   0       2
/media/olddisk6/manuel/Music       /home/manuel/Music none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/Pictures       /home/manuel/Pictures none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/photos      /home/manuel/photos none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/Documents      /home/manuel/Documents none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/Videos      /home/manuel/Videos none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/msx-soft      /home/manuel/msx-soft none 
defaults,bind,rw   0       0
/media/olddisk6/manuel/docs      /home/manuel/docs none 
defaults,bind,rw   0       0

As you can see I'm bind-mounting some dirs from my HDD (which is 
olddisk6) into my homedir.

> Can you reproduce the issue with arbitrary mounts?

Um, not sure, how do I test that exactly?

> Can you reproduce the issue with a minimal setup? On a different system?

I don't have another system to test with. I don't know how to go to a 
'minimal setup'.

> Do you have any hints how we can reproduce it?

I didn't do anything special for it, as I said, just dist-upgrading 
daily. But this was one of the first times the fsck was due for that 
disk after the reinstall on the SSD, I guess.

> Does the problem go away if you use "systemctl mask
> systemd-fsckd.service systemd-fsckd.socket"

I'll report about that later. But first tell me: what does this do and 
how can I undo it if necessary?

> Does journalctl -u systemd-fsckd.service produce anything interesting?

$ sudo journalctl -u systemd-fsckd.service
-- Logs begin at zo 2015-11-29 11:11:00 CET, end at zo 2015-11-29 
14:27:42 CET. --
nov 29 11:11:00 sonata systemd[1]: Started File System Check Daemon to 
report status.

> Can you boot with systemd.debug-shell on the kernel command line, and
> then switch to tty9 while the fsck is running and attach strace to the
> fsckd and fsck process?

I'll try that next reboot.

-- 
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Message #115 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Bruno Schneider <boschneider@gmail.com>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Mon, 30 Nov 2015 10:32:53 -0200

I also have this problem. I have no LVM, no RAID, no graphical boot,
just a plain old disk partition.

The "mount count" has passed "maximum mount count", systemd runs fsck
but it never finishes, it gets interrupted by SIGPIPE. It all starts
again next boot.

Output from cat /proc/cmdline is:
BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64
root=UUID=491b60dd-2eb2-428e-880d-8e411009938d ro quiet

Output of

    $ sudo journalctl -u systemd-fsckd.service

is not useful, just like message #110.

Like him, I will test the command

   systemctl mask systemd-fsckd.service systemd-fsckd.socket

once I understand it. Please explain that.

-- 
Bruno Schneider

Message #120 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Tue, 1 Dec 2015 21:52:01 +0100

Hi,

On 29-11-15 01:28, Michael Biebl wrote:
> Can you boot with systemd.debug-shell on the kernel command line, and
> then switch to tty9 while the fsck is running and attach strace to the
> fsckd and fsck process?

I want to try this, but for some reason, grub always boots, even if I 
keep SHIFT pressed... This used to work at some point, but now I can't 
edit the command line anymore :( Ah, I see, it's bug #768299... so many 
things stopping to work lately :(

I changed timout to 1, so I should be able to test it next reboot again.

Can you respond to my questions, please?

-- 
Kind regards,

Manuel

Message #125 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Manuel Bilderbeek <manuel.bilderbeek@gmail.com>

To: Michael Biebl <biebl@debian.org>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Tue, 1 Dec 2015 23:23:52 +0100

Hi,

On 29-11-15 01:28, Michael Biebl wrote:
> Does the problem go away if you use "systemctl mask
> systemd-fsckd.service systemd-fsckd.socket"

Yes, it does. Using this I got to see the following while booting, which 
wasn't visible before:

A start job is running... for sda1 (1min23 / no limit)
(alternating between sda1 and sda6).

Apparently, after 20 minutes this was done:

$ systemd-analyze blame
   20min 15.763s systemd-fsck@dev-sda1.service
   20min 15.088s systemd-fsck@dev-sda6.service

And it really finished:

$ sudo tune2fs -l /dev/sda6
tune2fs 1.42.13 (17-May-2015)
[.... cutting out irrelevant parts ...]
Filesystem volume name:   <none>
Filesystem UUID:          98fcb0eb-44f7-4aae-8fef-0eabeab3ef6a
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Filesystem created:       Fri Jun 20 20:29:56 2008
Last mount time:          Tue Dec  1 23:13:30 2015
Last write time:          Tue Dec  1 23:13:30 2015
Mount count:              1
Maximum mount count:      120
Last checked:             Tue Dec  1 22:53:15 2015
Check interval:           15552000 (6 months)
Next check after:         Sun May 29 23:53:15 2016

and:

$ sudo tune2fs -l /dev/sda1
tune2fs 1.42.13 (17-May-2015)
[.... cutting out irrelevant parts ...]
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          12635a70-3def-4b39-bc78-1ee0ad29a2d2
Filesystem created:       Fri Jun 20 20:29:39 2008
Last mount time:          Tue Jun  9 20:56:46 2015
Last write time:          Tue Dec  1 23:13:30 2015
Mount count:              0
Maximum mount count:      80
Last checked:             Fri Nov  6 18:40:06 2015
Check interval:           15552000 (6 months)
Next check after:         Wed May  4 19:40:06 2016

So, apparently the problem is in systemd-fsck?

-- 
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Message #130 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

To: 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Sun, 20 Dec 2015 17:25:32 +0100

Hi,

On Tue, 1 Dec 2015 23:23:52 +0100 Manuel Bilderbeek 
<manuel.bilderbeek@gmail.com> wrote:
> Hi,
>
> On 29-11-15 01:28, Michael Biebl wrote:
> > Does the problem go away if you use "systemctl mask
> > systemd-fsckd.service systemd-fsckd.socket"
>
> Yes, it does. Using this I got to see the following while booting, which
> wasn't visible before:
>

This solutions works on my computer but systemctl -b says


- Dez 20 17:18:55 kruemel systemd[1]: systemd-fsckd.socket: Cannot add 
dependency job, ignoring: Unit systemd-fsckd.socket is masked.

several times

Message #135 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Sander Smeenk <ssmeenk@freshdot.net>

To: 788050@bugs.debian.org

Subject: systemd-fsck : Check disks at each reboot

Date: Sun, 5 Jun 2016 11:02:47 +0200

Hi,

Discovered this bug while researching trouble i'm having with systemd
boot and (forced) fscks. All that has been said in this bug, i'm seeing
the same. Since this bug was last updated december 20th 2015, i'm
wondering what the state of this is atm.

I'm running Ubuntu 16.04 though, systemd 229-4ubuntu6.

I have a huge filesystem (20T, 12T used) that experiences errors from
time to time. I've set the max-mount-count for this fs to 1, it has pass
flag '2' in fstab, so when i reboot it always checks the FS. I've set
'fsck.repair=yes' on the kernel cmdline so it should fix errors found.

All that was said in this bug-thread applies to me. During root-fs check
i see fsck output, during non-root-fs check i see an obfuscation message
showing a percentage. After a while it switches to 'A startup task for
... is running', a few moments later it stops and mounts the filesystem
with errors.

TimeoutSec is already set to 0 on relevant services on my system:

| # grep Timeout *fsck*
| systemd-fsck-root.service:TimeoutSec=0
| systemd-fsck@.service:TimeoutSec=0

I can also reproduce this issue at will.

Any progress on this?

-Sndr.
-- 
| Hey.. I'm done talkin'. Now check out my pretty!
| 4096R/20CC6CD2 - 6D40 1A20 B9AA 87D4 84C7  FBD6 F3A9 9442 20CC 6CD2

Message #140 received at 788050@bugs.debian.org (full text, mbox, reply):

From: "Aubrey Stark-Toller" <aubrey@deepearth.uk>

To: 788050@bugs.debian.org

Subject: systemd-fsck : Check disks at each reboot

Date: Wed, 20 Jul 2016 14:01:24 +0100

I think I just ran into this problem.

systemd-fsck seemed to be choking on a ~1.8T LVM volume with an ext3
filesytem - the volume's group is on an encrypted primary partion on a
HDD. I'm running stretch.

Before attempting to remedy the problem:
* systemd-fsck tried to run on the volume ever boot,
* "systemd-analyze blame" told me systemd-fsck runs for ~4 min on the
  volume, which is not long enough to complete a check (I know from past
  checks),
* "journalctl -u" systemd-fsckd.service told me nothing interesting,
* tune2fs said the volume has not been checked since 15 Mar 2016, which
  supports the theory systemd-fsck is not completing.
* systemd-fsck completes for all other volumes and disks (which are
  considerably smaller), so I'd guess it's a timeout issue.

Before the 15 Mar 2016 everything worked fine, so this must have been
caused by an update since then. Unfortunately I can't pin down a more
precise start date, but I do have dpkg logs going back to the 15th so
might be able to glean something from that.

Setting TimeoutStartSec in /etc/systemd/system/systemd-fsckd.service to
0
and 480min did nothing.

fsck ran fine while booting after running
"systemctl mask > systemd-fsckd.service systemd-fsckd.socket"; tune2fs
reported the volume had been checked and "systemd-analyze blame" gave a 
sane run time for systemd-fsck.


- Aubrey Stark-Toller

Message #145 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Thomas Numberger <thomas.numberger@web.de>

To: 788050@bugs.debian.org

Subject: Re: systemd-fsck : Check disks at each reboot

Date: Fri, 12 Aug 2016 08:06:37 +0200

Have the same problem since upgrading from ubuntu 14.04 to 16.04.

HDD 600 GB ext3 partition

systemd-fsck is checking approx. 1 minute (approx 15% checked), then
systemd-fsck is aborted and a line appears saying:

[***] A startup task for ... is running

What does this "A startup task for ... is running" mean? - What
startup task is called "..." ???

Is it possible that there exist older init scripts / startup scripts /
(Ubuntu) upstart scripts which start as fast and want to access the
checked partition that they kill the systemd-fsck?

Thomas Numberger

Message #150 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michal Schmidt <mschmidt@redhat.com>

To: 788050@bugs.debian.org

Subject: Re: systemd-fsck : Check disks at each reboot

Date: Wed, 7 Sep 2016 18:31:12 +0200

systemd-fsckd's event loop terminates if nothing happens for 30 seconds
(IDLE_TIME_SECONDS). Usually fsck writes progress updates more frequently
than that, but the interval is not guaranteed. So systemd-fsckd may exit
by itself while fsck is busy working. When this happens, fsck will
receive SIGPIPE as soon as it tries to write the next progress update.

It is possible to reproduce this using the dm-delay DM target for
a block device.

The bug is specific to Debian/Ubuntu, because systemd-fsckd is not
present in upstream.

Michal

Message #155 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Michal Schmidt <mschmidt@redhat.com>, 788050@bugs.debian.org

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Fri, 9 Sep 2016 23:44:20 +0200

[Message part 1 (text/plain, inline)]

Thanks for the hint, Michal.

Seems like someone else already came to the same conclusion:
https://gist.github.com/ebautistabar/82811d492231700ab2471dd9048502b7

Am 07.09.2016 um 18:31 schrieb Michal Schmidt:
> systemd-fsckd's event loop terminates if nothing happens for 30 seconds
> (IDLE_TIME_SECONDS). Usually fsck writes progress updates more frequently
> than that, but the interval is not guaranteed. So systemd-fsckd may exit
> by itself while fsck is busy working. When this happens, fsck will
> receive SIGPIPE as soon as it tries to write the next progress update.
> 
> It is possible to reproduce this using the dm-delay DM target for
> a block device.

That sounds interesting. Can you give some more details how to use and
setup dm-delay? I have a possible fix in mind and would like to test
that with dm-delay.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #160 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 788050@bugs.debian.org, Aubrey Stark-Toller <aubrey@deepearth.uk>, Sander Smeenk <ssmeenk@freshdot.net>, Axel Ludszuweit <axel.ludszuweit@htp-tel.de>, Michal Schmidt <mschmidt@redhat.com>

Cc: tytso@mit.edu

Subject: Re: systemd-fsck : Check disks at each reboot

Date: Sat, 10 Sep 2016 15:16:10 +0200

[Message part 1 (text/plain, inline)]

On Wed, 7 Sep 2016 18:31:12 +0200 Michal Schmidt <mschmidt@redhat.com>
wrote:
> systemd-fsckd's event loop terminates if nothing happens for 30 seconds
> (IDLE_TIME_SECONDS). Usually fsck writes progress updates more frequently
> than that, but the interval is not guaranteed. So systemd-fsckd may exit
> by itself while fsck is busy working. When this happens, fsck will
> receive SIGPIPE as soon as it tries to write the next progress update.
> 
> It is possible to reproduce this using the dm-delay DM target for
> a block device.
> 
> The bug is specific to Debian/Ubuntu, because systemd-fsckd is not
> present in upstream.

So, with Michal's hint I've setup a really slow dm-delayed device. Then
I ran a systemd-fsck@ check on that device.

systemd-fsckd does indeed exit before the fsck process has finished,
*but* I don't get a failing fsck because of that.

So I wonder if there were some changes in either util-linux or e2fsprogs
which handle SIGPIPE differently now in fsck.
Maybe tytso has some insight here.

For anyone who was able to reproduce the issue, which versions of
util-linux and e2fsprogs do you have installed which show this problem?
Can you still reproduce it on an up-to-date stretch system?

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #165 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <email@michaelbiebl.de>

To: 788050@bugs.debian.org, Aubrey Stark-Toller <aubrey@deepearth.uk>, Sander Smeenk <ssmeenk@freshdot.net>, Axel Ludszuweit <axel.ludszuweit@htp-tel.de>

Subject: Re: systemd-fsck : Check disks at each reboot

Date: Sat, 10 Sep 2016 17:31:42 +0200

[Message part 1 (text/plain, inline)]

Am 10.09.2016 um 15:16 schrieb Michael Biebl:
> On Wed, 7 Sep 2016 18:31:12 +0200 Michal Schmidt <mschmidt@redhat.com>
> wrote:
>> systemd-fsckd's event loop terminates if nothing happens for 30 seconds
>> (IDLE_TIME_SECONDS). Usually fsck writes progress updates more frequently
>> than that, but the interval is not guaranteed. So systemd-fsckd may exit
>> by itself while fsck is busy working. When this happens, fsck will
>> receive SIGPIPE as soon as it tries to write the next progress update.
>>
>> It is possible to reproduce this using the dm-delay DM target for
>> a block device.
>>
>> The bug is specific to Debian/Ubuntu, because systemd-fsckd is not
>> present in upstream.
> 
> So, with Michal's hint I've setup a really slow dm-delayed device. Then
> I ran a systemd-fsck@ check on that device.
> 
> systemd-fsckd does indeed exit before the fsck process has finished,
> *but* I don't get a failing fsck because of that.
> 
> So I wonder if there were some changes in either util-linux or e2fsprogs
> which handle SIGPIPE differently now in fsck.
> Maybe tytso has some insight here.
> 
> For anyone who was able to reproduce the issue, which versions of
> util-linux and e2fsprogs do you have installed which show this problem?
> Can you still reproduce it on an up-to-date stretch system?


Nvm, I was actually to reproduce the problem and have a patch ready.
Anyone want to give it a try?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #170 received at 788050@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 788050@bugs.debian.org

Cc: Michal Schmidt <mschmidt@redhat.com>, Ludovic Lebègue <ludovic@lebegue.org>, Paul Menzel <pm.debian@googlemail.com>, Axel Ludszuweit <axel.ludszuweit@htp-tel.de>, Allen Webb <vertago1@gmail.com>, Manuel Bilderbeek <Manuel.Bilderbeek@gmail.com>, Bruno Schneider <boschneider@gmail.com>

Subject: Re: Bug#788050: systemd-fsck : Check disks at each reboot

Date: Thu, 15 Sep 2016 00:18:46 +0200

[Message part 1 (text/plain, inline)]

Control: tags -1 + pending

Am 07.09.2016 um 18:31 schrieb Michal Schmidt:
> systemd-fsckd's event loop terminates if nothing happens for 30 seconds
> (IDLE_TIME_SECONDS). Usually fsck writes progress updates more frequently
> than that, but the interval is not guaranteed. So systemd-fsckd may exit
> by itself while fsck is busy working. When this happens, fsck will
> receive SIGPIPE as soon as it tries to write the next progress update.
> 
> It is possible to reproduce this using the dm-delay DM target for
> a block device.
> 
> The bug is specific to Debian/Ubuntu, because systemd-fsckd is not
> present in upstream.

Thanks again for your input, Michal.

I've committed a fix to our git repository.
It should be included in the next upload.
If someone want's to test the fix earlier, the commit is available at [1].

Regards,
Michael



[1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=be10d228ff45b5fd73737845d1bae8c14b5dc4ae

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #177 received at 788050-close@bugs.debian.org (full text, mbox, reply):

From: Martin Pitt <mpitt@debian.org>

To: 788050-close@bugs.debian.org

Subject: Bug#788050: fixed in systemd 231-7

Date: Tue, 20 Sep 2016 16:45:46 +0000

Source: systemd
Source-Version: 231-7

We believe that the bug you reported is fixed in the latest version of
systemd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 788050@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin Pitt <mpitt@debian.org> (supplier of updated systemd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 20 Sep 2016 15:03:06 +0200
Source: systemd
Binary: systemd systemd-sysv systemd-container systemd-journal-remote systemd-coredump libpam-systemd libnss-myhostname libnss-mymachines libnss-resolve libsystemd0 libsystemd-dev udev libudev1 libudev-dev udev-udeb libudev1-udeb
Architecture: source amd64
Version: 231-7
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>
Changed-By: Martin Pitt <mpitt@debian.org>
Description:
 libnss-myhostname - nss module providing fallback resolution for the current hostname
 libnss-mymachines - nss module to resolve hostnames for local container instances
 libnss-resolve - nss module to resolve names via systemd-resolved
 libpam-systemd - system and service manager - PAM module
 libsystemd-dev - systemd utility library - development files
 libsystemd0 - systemd utility library
 libudev-dev - libudev development files
 libudev1   - libudev shared library
 libudev1-udeb - libudev shared library (udeb)
 systemd    - system and service manager
 systemd-container - systemd container/nspawn tools
 systemd-coredump - tools for storing and retrieving coredumps
 systemd-journal-remote - tools for sending and receiving remote journal logs
 systemd-sysv - system and service manager - SysV links
 udev       - /dev/ and hotplug management daemon
 udev-udeb  - /dev/ and hotplug management daemon (udeb)
Closes: 788050 837759
Changes:
 systemd (231-7) unstable; urgency=medium
 .
   [ Michael Biebl ]
   * fsckd: Do not exit on idle timeout if there are still clients connected
     (Closes: #788050, LP: #1547844)
 .
   [ Martin Pitt ]
   * 73-usb-net-by-mac.rules: Split kernel command line import line.
     Reportedly this makes the rule actually work on some platforms. Thanks Alp
     Toker! (LP: #1593379)
   * debian/tests/boot-smoke: Only run 5 iterations
   * systemd.postinst: Drop obsolete setcap call for systemd-detect-virt.
     Drop corresponding libcap2-bin dependency.
   * debian/tests/systemd-fsckd: Robustify check for "unit was running"
     (LP: #1624406)
   * debian/extra/set-cpufreq: Use powersave with intel_pstate.
     This is what we did on xenial, and apparently powersave is still actually
     better than performance. Thanks to Doug Smythies for the measurements!
     (LP: #1579278)
   * Ubuntu: Move ondemand.service from static to runtime enablement.
     This makes it easier to keep performance, by disabling ondemand.service.
     Side issue in LP: #1579278
   * Revert "networkd: remove route if carrier is lost"
     This causes networkd to drop addresses from unmanaged interfaces in some
     cases. (Closes: #837759)
   * debian/tests/storage: Avoid stderr output of stopping systemd-cryptsetup@.service
   * libnss-*.prerm: Remove possible [key=value] options from NSS modules as well.
     (LP: #1625584)
Checksums-Sha1:
 adba3c8dbe82a7416dbd773233f07d2acfb5d13c 4443 systemd_231-7.dsc
 ae40eee5c14e2ec3f205ec0c90acae0ace0e020c 140600 systemd_231-7.debian.tar.xz
 c5a3d37ae2d98d28b848a96397b58d83e562044d 87248 libnss-myhostname-dbgsym_231-7_amd64.deb
 b56d3515090dbf94d189596982bd055462819070 94738 libnss-myhostname_231-7_amd64.deb
 fc6b241c19210bc30ac798589e9a539124c78c4b 430976 libnss-mymachines-dbgsym_231-7_amd64.deb
 a21e9c6c0dc4c6e54d84eb5238ac8b27421009ad 176006 libnss-mymachines_231-7_amd64.deb
 6f2273fe465e8ca6e1da40af647afe85ce5ccdf7 425658 libnss-resolve-dbgsym_231-7_amd64.deb
 e5fd4b7e9f4d110cec794e02bf3b732b42bd4ee7 175394 libnss-resolve_231-7_amd64.deb
 8325aa505a3ef3b29c1da0513363f6ac0e269962 419136 libpam-systemd-dbgsym_231-7_amd64.deb
 21c1f5c5e01e8c967339588c22d6c2c0134e8221 176930 libpam-systemd_231-7_amd64.deb
 59e49762e22c99cc34d3d0d53701e0f2879d36fe 224858 libsystemd-dev_231-7_amd64.deb
 41f1d7cc725c21ab716bea16c99f02ba8640bcbe 659234 libsystemd0-dbgsym_231-7_amd64.deb
 887c46a76e42d88a8282ccc5facf3fa36999fd93 268376 libsystemd0_231-7_amd64.deb
 4ab145a79aa881a188420dd135274e9e4b611e97 510316 libudev-dev-dbgsym_231-7_amd64.deb
 2d8aa6acb6d8e8330ff684739ca4cffa493b2130 249578 libudev-dev_231-7_amd64.deb
 dd5463dd7d92ab8566cb3dc067885bf02d18824b 157186 libudev1-dbgsym_231-7_amd64.deb
 8d4c5dd87c948d892bcafdd47ce67dfcc8235b4d 48324 libudev1-udeb_231-7_amd64.udeb
 725ed901e97f65de8254dc5a5ddcd1a8cff8b5fb 114144 libudev1_231-7_amd64.deb
 d69b3a14f34673029c281ce6cf797b545b7aca81 471678 systemd-container-dbgsym_231-7_amd64.deb
 7d28f8a9a600e8ee88ee5ea91e93f08523cea4f6 274506 systemd-container_231-7_amd64.deb
 bb12899fb06f2cd09e644c4514b79ce8289f5878 66738 systemd-coredump-dbgsym_231-7_amd64.deb
 2447e049ad735d9feb4a7d5ad6cd46425981f3e8 98128 systemd-coredump_231-7_amd64.deb
 aef9136580945eed351843942b2615dad5be2c7b 5758618 systemd-dbgsym_231-7_amd64.deb
 bf92863701e64eb6b357362cf9e10cbbd7d0659c 110038 systemd-journal-remote-dbgsym_231-7_amd64.deb
 f200bcafb6f89f682ebec8a57192f1a1f2927ecc 117402 systemd-journal-remote_231-7_amd64.deb
 b5fe55acbcaabc16af7f814cadbefecf2337bbac 70948 systemd-sysv_231-7_amd64.deb
 01bd5f0d961cc9e32e28f3e23601acdc8846fa66 2364264 systemd_231-7_amd64.deb
 745059ddfd32f6b76934e2082bc566c931236f18 1311886 udev-dbgsym_231-7_amd64.deb
 1d39bb6caff2dda1797e663f97e6a54a647919b1 272588 udev-udeb_231-7_amd64.udeb
 609bb9bdfa95973df8f3763230110deccd78eb0b 1079270 udev_231-7_amd64.deb
Checksums-Sha256:
 07e3648b6505a9d9cbcabf7565d1240d72f8de8eb407b8def2e5976782f509b1 4443 systemd_231-7.dsc
 c540c392ac83bc6378490b5441d766a2b46aa7e27d04fffe7a77a8d5d1364bb4 140600 systemd_231-7.debian.tar.xz
 52b26777210cf26f3b6579bf227c97d06cc99fadad894d555187ed2a9b9ebc65 87248 libnss-myhostname-dbgsym_231-7_amd64.deb
 486e310dc4eb020b46519dab1cf5dabe4a14e551cf88412de3c22dd53a49e13e 94738 libnss-myhostname_231-7_amd64.deb
 c0d912e2eb25da4a8bf5c0e998eb726c768473863374794ce1eb006b768fe16c 430976 libnss-mymachines-dbgsym_231-7_amd64.deb
 086b18e53977e0f98d6cac0a1d761003c2b1d8cf87d550892e4f7c4b3f2bd693 176006 libnss-mymachines_231-7_amd64.deb
 6a3d34fe4cb3a730a5f836482700d60ec82e6c75de107901a10c2e09eff1d739 425658 libnss-resolve-dbgsym_231-7_amd64.deb
 1f2139cfa7bddfd0365dfc29fb034a15bd3ee38c41a24244a23aba78d878447e 175394 libnss-resolve_231-7_amd64.deb
 48c7f3af7f48d65255f3d97eb4b685dc39426d2ec5bb621883840d34d0cf8c62 419136 libpam-systemd-dbgsym_231-7_amd64.deb
 a3c07868fd8d44e90de0a6c6b79058011c6f27e406259f681708871951da726f 176930 libpam-systemd_231-7_amd64.deb
 b664bfe4c5edc5bc8c72ee6818d363acec237deb61e7c888e6561b2721b6c2d2 224858 libsystemd-dev_231-7_amd64.deb
 15c4261c6ddadc430489f03eab464ced5374d66e8a09de72514bc4635d90bd53 659234 libsystemd0-dbgsym_231-7_amd64.deb
 9ad84f611778730ddb9072640b1514a6571732dce12b9c778f54661293d2ed07 268376 libsystemd0_231-7_amd64.deb
 95aff5ce5a621fc18aeb728a21bd2f8c926c29981911b8d1ac149a7e78dae867 510316 libudev-dev-dbgsym_231-7_amd64.deb
 659ef824f1611188deaeb19ce804557f5340253d6512efe02a0c9d92e549a44c 249578 libudev-dev_231-7_amd64.deb
 a3d9677173f61f32410c5693af167ab7d88a6a0db253f8cfac57c30125e1e0b9 157186 libudev1-dbgsym_231-7_amd64.deb
 7839e218686be53fdc63a177119c1c986ee6563c5da2f9d5e3df8f7cf1ba29b5 48324 libudev1-udeb_231-7_amd64.udeb
 8ddfd105f96632de8e76600a3ec897acb743cdd76ef5577805e56882bf1588ac 114144 libudev1_231-7_amd64.deb
 412db6cea9bbf01a915d28b4746950c98eb3e045cd452b5af3df3c368bac64f2 471678 systemd-container-dbgsym_231-7_amd64.deb
 e670b491cc7288fa0ddd303594d156d63ee584606226ab238bc3be0cd00a5d29 274506 systemd-container_231-7_amd64.deb
 883d087151eebd367691ae361dc97a59c8b9f03711c4d3a657764af8b2b1cebb 66738 systemd-coredump-dbgsym_231-7_amd64.deb
 eab671ac8039df8aa800db7a0687d5e0f470e68b22e4ab52192aaa1a129e6a60 98128 systemd-coredump_231-7_amd64.deb
 dd4f339558d11801c37ffd8390cb694ace7c5c618b0c044d5616a913b7ae4762 5758618 systemd-dbgsym_231-7_amd64.deb
 4e99e3a70ac687b410afb49e737c0cf92d1a7710d5fc04b4a536d091d5da5d88 110038 systemd-journal-remote-dbgsym_231-7_amd64.deb
 68b43e13f674220ee87484d47c6d95cff567b4f7d79eb17ee7b446849a01cebf 117402 systemd-journal-remote_231-7_amd64.deb
 1c800b4e353e09a5fdedb36b965d0fb38d768bb19034d5b56a55a5f581ab8da8 70948 systemd-sysv_231-7_amd64.deb
 91e8fbf83639f7ea60162e7b99980b21b311dadf1823c07ea762bfc9204227d6 2364264 systemd_231-7_amd64.deb
 da06de39e446344d0e12a9e684a36f4c771ab808a4c4732b5675c7b9575148a1 1311886 udev-dbgsym_231-7_amd64.deb
 f1ae3b0d9c0eee0c2ec23d4725a3f8cd7515fb3aef8b6da4b93de8873ba988d0 272588 udev-udeb_231-7_amd64.udeb
 bf6c12fc46c34cd1ab735d69dbd7f57a180d96a2d06843763ff95a1a3050954b 1079270 udev_231-7_amd64.deb
Files:
 38deb05af6ba19ff48c7b004305891c1 4443 admin optional systemd_231-7.dsc
 997e4e1968609c3f6bbdee48bb9068f0 140600 admin optional systemd_231-7.debian.tar.xz
 a16ebad89a4b6996bba4673c0a7b1cc3 87248 debug extra libnss-myhostname-dbgsym_231-7_amd64.deb
 f727457c5c4de1e69079b7d620074ad2 94738 admin extra libnss-myhostname_231-7_amd64.deb
 90af84c37e94e9a38e062a9f43ece236 430976 debug extra libnss-mymachines-dbgsym_231-7_amd64.deb
 9c0e7d3b4ac1d2278b3d4ef34a4d1422 176006 admin extra libnss-mymachines_231-7_amd64.deb
 2efb14cbb59d5764b425b4cc768675ce 425658 debug extra libnss-resolve-dbgsym_231-7_amd64.deb
 5c83296a329274e8b8e5045a501fc5f1 175394 admin extra libnss-resolve_231-7_amd64.deb
 bb6312cbce2024070c92e21851f94bcb 419136 debug extra libpam-systemd-dbgsym_231-7_amd64.deb
 2cae0ba70fdb92943e4f54ba5c65b243 176930 admin optional libpam-systemd_231-7_amd64.deb
 f874d4535e5e09ffa72ba686c2616d2c 224858 libdevel optional libsystemd-dev_231-7_amd64.deb
 2c4cd09d7fb9b078fe1b18c8b17d4b42 659234 debug extra libsystemd0-dbgsym_231-7_amd64.deb
 7eab1e3b88ade336f5abb1811bb3c0e3 268376 libs optional libsystemd0_231-7_amd64.deb
 fac0fa5888bdd3e5968dc2ead6a7b717 510316 debug extra libudev-dev-dbgsym_231-7_amd64.deb
 40c0478aa5b60acbe3f4610ebdf11d4d 249578 libdevel optional libudev-dev_231-7_amd64.deb
 b19ea3b834fc7ff73f78f808baa5bbbb 157186 debug extra libudev1-dbgsym_231-7_amd64.deb
 2dcefa8d6fd511cba7ac42e82a8d75c3 48324 debian-installer optional libudev1-udeb_231-7_amd64.udeb
 8c23e62fb6ae0e0b2290e74ce7425f19 114144 libs important libudev1_231-7_amd64.deb
 319ebe48c8fbdebb402315abd1bc7e57 471678 debug extra systemd-container-dbgsym_231-7_amd64.deb
 8ca16b0df6d103237923dd3a7a8718a1 274506 admin optional systemd-container_231-7_amd64.deb
 e496eab0604aa285857fb5e092c82f14 66738 debug extra systemd-coredump-dbgsym_231-7_amd64.deb
 35152b0fed614a640361574f1865c95e 98128 admin optional systemd-coredump_231-7_amd64.deb
 e3ccadf1ec7059e7eb28dedbe17ec830 5758618 debug extra systemd-dbgsym_231-7_amd64.deb
 5946b6d9442f60f34ad1749525c54505 110038 debug extra systemd-journal-remote-dbgsym_231-7_amd64.deb
 0f11fbbf921f161538b459f1331effdd 117402 admin optional systemd-journal-remote_231-7_amd64.deb
 a4d574f3cc369d004ec786eff50194c9 70948 admin important systemd-sysv_231-7_amd64.deb
 0a978faa747a9913c20c94716bf4236d 2364264 admin important systemd_231-7_amd64.deb
 f6f2a89262b71ed7b6ba51feeb86f279 1311886 debug extra udev-dbgsym_231-7_amd64.deb
 fc05e0b97bd09df8b9714a8f31e4898d 272588 debian-installer optional udev-udeb_231-7_amd64.udeb
 0ab84fe67ff84d5fa4a84bc5ece405fb 1079270 admin important udev_231-7_amd64.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJX4UPxAAoJENFO8V2v4RNH6skQAKoNs/kSmoJdiKIJ1KrgUFyX
2JoIy6kM4Z5DK71tGQC9VMdTVYWEYHbOzAglHSFbaRJ0tivLmqRpaIl3E3c8XbAV
qoR4GL9rD3txQ7M/d0GPC1v6J9IW3wssAND3wlyJLTKdjIzLJv6OVrk951ILWU9+
EZTUjfy4qZ9LzcaAsr3rkegyxXRc13V8NJeknuC9BLMvnaq2ErMV2X3oIw1ydmb5
hfwwkRnSRJufR+prmI4nn47f1IAwnNYIURC1sfs0YhKYVnkCiy4azgG3u9BmC/yH
3ZuZeZ+MH7JyXwH2zPLM3zw5Prj3yFEkq9W9KpdMhNU/ALsSzz1/UxNZGflcsjSB
jA+/P7yM7eHVkFEeAOaSvn92vEwPiSx3tgXmhJagyPzETlTixdmm8VHPA4bFkEux
utR+9kigU70XaJ5jt3IaFAea6Pmrgbw5JwopzbxU0/V7wNjRiKaDwZadVwekVml+
ACCFBRj8ZugPMwIpp62zJMmS3BU0UGgQiJaDW5eVr9hJefNIV0vNMhNYE+xnWPEQ
sMZI3CA+BeC22ntqVUfx1yGi4WnlZPLkCFkWHkBUzuwvSDveuQvpC03apc/o4dCP
ccSlcBku5Nfq8leELOfn2ZcZWvJhzAMPxKGagyyi99TIQqYjcGy/571fgkyXJaay
BoEHudAnfEGkmcZO9t8D
=d8aG
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.