Hi there,

after I had to hard-reset my laptop because of this bug, it won't boot any more. It fails with
local-tmpfiles: fatal: crashed!
Other than that, I cannot see any suspicious messages during boot.

Do you have any ideas what goes wrong there or how I can get more information about the failure?

Thanks!
thededem
chroot to the installation, edit /etc/66/init.conf change verbosity to 4 reboot
go to tty12 (Ctl-Sh-F12) log in as user, copy /run/66/log/0/current to a permanent partition so you can copy it later.

After this:

You can also edit the boot module - BUT do it after you have gotten the -v4 current log.
# 66-env -t boot -e nano boot@ _____ (name of your module)
TMPFILE=!yes
change it to !no
# 66-enable -t boot -F boot@ ____ (module name)
reboot

But it is important that the problem is solved, this is an emergency solution

I have a weird installation on a vm (even though I have i915 gfx vm should not be affected and I am not using 5.12) but I don't use this for anything other than experimentation. Now that you are saying it I'll take a closer look.

Maybe due to the crash and improper shutdown something is left behind that 66 can't clean up and write in place of the file written before. So it is important we gather such data so Eric can fix this behavior. If he can't reproduce it he can't fix it.
Do you have postgresql installed?

The end of my log looks like this:
2021-05-18 19:15:21.168906673  _d /run/faillock 0755 root root 0 
2021-05-18 19:15:21.173893813  _d /run/pgbouncer 755 pgbouncer pgbouncer 0 
2021-05-18 19:15:21.178350433  _d /var/lib/postgres/data 700 postgres postgres 0 
2021-05-18 19:15:21.182484693  _h /var/lib/postgres/data - 0 0 0 +C
2021-05-18 19:15:21.183775935  chattr: Operation not supported while setting flags on /var/lib/postgres/data
2021-05-18 19:15:21.184346765  _z /var/log/pgbouncer 750 pgbouncer pgbouncer 0 
2021-05-18 19:15:21.185164332  _d /run/php-fpm 755 root root 0 
2021-05-18 19:15:21.190202752  _d /var/lib/postgres/data 700 postgres postgres 0 
2021-05-18 19:15:21.193853703  _h /var/lib/postgres/data - 0 0 0 
2021-05-18 19:15:21.194495216  _d /var/lib/rpcbind 0700 rpc rpc 0 
2021-05-18 19:15:21.199253517  _D /run/samba 0755 0 0 0 
2021-05-18 19:15:21.204249324  _d /var/lib/sddm 0755 sddm sddm 0 
2021-05-18 19:15:21.208331370  _d /var/empty 0755 root root 0 
2021-05-18 19:15:21.212557971  _d /run/sudo 0711 root root 0 
2021-05-18 19:15:21.217145254  _D /run/sudo/ts 0700 root root 0 
2021-05-18 19:15:21.222157939  _D /run/svnserve 0700 root root 0 
2021-05-18 19:15:21.227088499  _d /var/lib/tor 0700 tor tor 0 
2021-05-18 19:15:21.231374004  local-tmpfiles: fatal: crashed!
2021-05-18 19:15:21.231905065  s6-rc: warning: unable to start service local-tmpfiles: command exited 111
2021-05-18 19:15:21.232029136  66-dbctl(src/lib66/ssexec_dbctl.c: ssexec_dbctl(): 349): fatal: unable to start services selection
2021-05-18 19:15:21.233336149  rc.init: fatal: please see the log at /run/66/log/0/current
Thanks, I was able to sort this out.

Looking at /run/66/log/0/current, I found the following entries:
2021-05-18 18:45:00.781932371 tmpfiles: ignoring invalid entry on line 3 of `/usr/lib/tmpfiles.d/tpm2-tss-fapi.conf'
2021-05-18 18:45:00.782392066 _d /run/tpm2-tss/eventlog 2775 tss tss 0
2021-05-18 18:45:00.790141307 tmpfiles: ignoring invalid entry on line 5 of `/usr/lib/tmpfiles.d/tpm2-tss-fapi.conf'
2021-05-18 18:45:00.791758971 local-tmpfiles: fatal: crashed!
The file belongs to the tpm2-tss package. I commented the invalid lines out and now the laptop is working again.

So I guess this had nothing to do with the hard-reset, but with an update of the tpm2-tss package, that changed the configuration file (I also remember that I had this problem before and fixed it the same way ... I guess then I was clever enough to remember tty12 is available at that point in the boot process).
I am glad you figured it out, and it seems that my bug is on rights set by the postgresql pkg. I had this frankenstein installation where I tried to install ALL obarun pkgs, except for very few that conflict (like openntpd ntpd, or xorg and xorg rootless) and I was expecting some weird things to happen.

Should boot fail because of such a thing though, I am not sure. In some cases I can understand warnings of things to be brought to attention before logging in but not a failure. On the other hand if tmp filesystems are not mounted correctly more errors can occur during run-time, and I'm not sure if someone running a DM will ever see those without a failure.

tty12 is our friend, if we learn to use it right.
Thanks for the report guys. I don't have the time right now to handle this. I hope to have the time this week-end.
5 days later
A new version of the boot-66serv package is available at observice-testing repo. This version avoid to crash the boot sequence if the tmpfiles program crash and warn the user if something went wrong.

Test it and tell me.
a month later
I had the same problems due to tpm2-tss-fapi.conf's a+ directives which tmpfiles.sh doesn't handle. I made the following patch to add that functionality:
@ @ -149,6 +149,18 @ @ createpipe() {
     dryrun_or_real chmod $mode "$path"
 }

+_a() {
+    # Set/Add POSIX ACLs (access control lists)
+    local path=$1 mode=$2 uid=$3 gid=$4 age=$5 arg=$6 add=$7
+    if [ -e "$path" ]; then
+        if [ "$add" = 1 ]; then
+            setfacl --modify=$arg $path
+        else
+            setfacl --set=$arg $path
+        fi
+    fi
+}
+
 _b() {
     # Create a block device node if it doesn't exist yet
     local path=$1 mode=$2 uid=$3 gid=$4 age=$5 arg=$6
@ @ -527,7 +539,7 @ @ for FILE in $tmpfiles_d ; do

         # whine about invalid entries
         case $cmd in
-            f|F|w|d|D|v|p|L|c|C|b|x|X|r|R|z|Z|q|Q|h|H) ;;
+            f|F|w|d|D|v|p|L|c|C|b|x|X|r|R|z|Z|q|Q|h|H|a) ;;
             *) warninvalid ; continue ;;
         esac

@ @ -551,7 +563,8 @ @ for FILE in $tmpfiles_d ; do

         if [ $FORCE -gt 0 ]; then
             case $cmd in
-                p|L|c|b) [ -f "$path" ] && dryrun_or_real rm -f "$path"
+                p|L|c|b) [ -f "$path" ] && dryrun_or_real rm -f "$path" ;;
+                a) set -- "$@ " "$FORCE" ;;
             esac
         fi
I haven't found this functionality in the other tmpfiles.sh implementations on the net, so I'm not sure whether we would deviate from them? Either way, feel free to integrate/modify if you think it's useful...
Many thanks for this stormc. Yes, this is interesting to put this functionality at the tmpfiles.sh.

Powered by Obarun