Multiply-claimed blocks due to timesyncd privatetmp after power down

[agk...@gmail.com]

I have lost 4 BBB after simple power down. Debian 8, 4.1.30-ti-r69. Serial console output now reveals:

rootfs contains a file system with errors, check forced.

rootfs:                                                                         Duplicate or bad block in use!

rootfs: Multiply-claimed block(s) in inode 6104: 9960

rootfs: Multiply-claimed block(s) in inode 6106: 9961

rootfs: Multiply-claimed block(s) in inode 6107: 9960

rootfs: Multiply-claimed block(s) in inode 6174: 9961

rootfs: (There are 4 inodes containing multiply-claimed blocks.)

rootfs: File /var/tmp/systemd-private-deb6f9c85d7340c6a91d98a33d4b7943-systemd-timesyncd.service-WrsUyR (inode #6104, mod time Sat May 21 22:31:30 2016)

  has 1 multiply-claimed block(s), shared with 1 file(s):

rootfs:         /var/tmp/systemd-private-acdd2033bf68467fac7dccdc8c4f2114-systemd-timesyncd.service-IU4CO0 (inode #6107, mod time Sat May 21 22:31:30 2016)

rootfs:

rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

        (i.e., without -a or -p options)

fsck exited with status code 4

This output is the same on all 4 devices (with somewhat different folder names, of course).

What could be the reason for this happening?

Is there anything known about systemd resp. timesyncd creating a problem on shutdown with privatetemp=True? 

Where can timesyncd be set to privatetemp=False? Does that create other problems?

[Robert Nelson]

On Thu, Oct 18, 2018 at 2:08 PM <agk...@gmail.com> wrote:
>
> I have lost 4 BBB after simple power down. Debian 8, 4.1.30-ti-r69. Serial console output now reveals:
>
> rootfs contains a file system with errors, check forced.
> rootfs: Duplicate or bad block in use!
> rootfs: Multiply-claimed block(s) in inode 6104: 9960
> rootfs: Multiply-claimed block(s) in inode 6106: 9961
> rootfs: Multiply-claimed block(s) in inode 6107: 9960
> rootfs: Multiply-claimed block(s) in inode 6174: 9961
> rootfs: (There are 4 inodes containing multiply-claimed blocks.)
>
> rootfs: File /var/tmp/systemd-private-deb6f9c85d7340c6a91d98a33d4b7943-systemd-timesyncd.service-WrsUyR (inode #6104, mod time Sat May 21 22:31:30 2016)
> has 1 multiply-claimed block(s), shared with 1 file(s):
> rootfs: /var/tmp/systemd-private-acdd2033bf68467fac7dccdc8c4f2114-systemd-timesyncd.service-IU4CO0 (inode #6107, mod time Sat May 21 22:31:30 2016)
> rootfs:
>
> rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
> (i.e., without -a or -p options)
> fsck exited with status code 4
>
> This output is the same on all 4 devices (with somewhat different folder names, of course).
> What could be the reason for this happening?

File System corruption... Did you do a proper shutdown, what command
did you issue? (I don't remember if 4.1.30-ti-r69 even knew how to
properly shut things down..)

Your system is easy to fix:

fsck.ext4 /dev/mmcblk0p1 or whatever you have..

> Is there anything known about systemd resp. timesyncd creating a problem on shutdown with privatetemp=True?
> Where can timesyncd be set to privatetemp=False? Does that create other problems?

That's just noise.. Fix the real problem first, in-proper shutdown..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[agk...@gmail.com]

I know how to recover the file system but I do not want to happen it again as manual intervention is required every time and this is not desired. 

Is it that you are saying that the system is not designed to survive a sudden unlisted power loss?

If 4 devices display exactly the same process (systemd/timesyncd)  that had corrupted the file system I would not consider this as noise, but some sort of regular event.

Brgds

Andy

[Robert Nelson]

On Thu, Oct 18, 2018 at 2:49 PM <agk...@gmail.com> wrote:
>
> I know how to recover the file system but I do not want to happen it again as manual intervention is required every time and this is not desired.
>
> Is it that you are saying that the system is not designed to survive a sudden unlisted power loss?

Correct, the "system" as shipped is not designed for "sudden unlisted
power loss"..

> If 4 devices display exactly the same process (systemd/timesyncd) that had corrupted the file system I would not consider this as noise, but some sort of regular event.

It's noise, it's one of the first process's started, as it's
responsible to figure out the a better clock time then blank..


Back to the issue, if you want the system to survive "sudden unlisted
power loss", YOU need to configure it for that situation.

One recent tool, that works well with systems using "systemd" is
overlayroot, all current images (https://beagleboard.org/latest-images
Debian 9.5 2018-10-07) have this available, you just have to open
/boot/uEnv.txt and enable it at the bottom and reboot.

Prior to that ^ image (and systemd) you had to split the main
partition into two partition, a read only and a read write section..
aka read only root, but with systemd based systems this was hard to
implement properly..