Hello,

I wanted to warn those of you using the Raspberry Pi or other aarch64
Devuan ASCII installs.

The defaults on the linux kernel flags have the options
rootflags=noload. This has the effect of disabling ext4 filesystem
journaling, checksumming, and all other safeguards.

In addition to that the root filesystem's parameters are set to always
disable filesystem checks.

To be clear, all filesystem safeguards have been turned off AND all
filesystem sanity checking has been disabled. This will inevitably lead
to major filesystem corruption and data loss as has happened to me.

There is more. The vfat partition that stores the system's blobs,
kernel, hardware configuration, and boot partition is not able to be
checked because the userspace tools required for doing so are missing
from the default install.

If
you have ever wondered why your RPIs have stopped working properly this
is probably why.

I have also developed a recovery process.

First you will need to remove the insane kernel flag from your cmd
line. edit /boot/cmdline.txt with a text editor and remove the section
'rootflags=noload'. It is between rootwait and net.ifnames=0.

Next your going to install some utilities.
apt install dosfstools debsums

the dosfstools package contains the fsck.vfat utility. The debsums
utility will allow us to detect some corrupted and missing system files
later ounce we get the system into a more consistent state.

Now that we have removed the insane kernelflag you will want to edit
your /etc/fstab to look like this:
/dev/mmcblk0p1    /boot         vfat   defaults                  0    2
/dev/mmcblk0p2  /       ext4
rw,data=ordered,relatime,block_validity,delalloc,journal_checksum,barrier,user_xattr,acl
0 1

This will enable the proper filesystem safeguards for the Pi's finicky
power connector and purpose as a development device that may get
powered on and off at any time. The 5 volt rail is also poorly designed
which without a specially offset power supply, can drop more than 0.45
volts from the input and bring the SoC out of spec as it only has a
tolerance of +/- 0.25V. This is due to the highly resistive
self-resetting fuse on the 5V power input.

Next we will want to properly adjust the root filesystem's parameters.

tune2fs -C 1 /dev/mmcblk0p2    # Check filesystem on every
boot/mount
tune2fs -i 1m /dev/mmcblk0p2    # Check filesystem
monthly
tune2fs -e panic /dev/mmcblk0p2    # trigger kernel panic on fatal
disk error

If you would rather not check the filesystem on every bootup you can
omit the tune2fs -C line. However keep in mind that this only takes
about 2 seconds to check an ext4 filesystem of 64GB on a aarch64
cpu @200Mhz. Filesystem checking time is really a thing of the past and
only a problem with ext3 filesystem not ext4 thanks to ext4 features
like uninit_bg,extent, and other improvements.

next, create a new text file at /etc/sysctl.d/local.conf containing:

# Reboot on kpanic after 10 seconds
kernel.panic = 10


now, use the following command:

touch /forcefsck
reboot

This will reboot your Pi and check all filesystems. Ounce your Pi
comes back up it may come up in a degraded state as mine did. Some
system files may be missing such as /etc/hostname. Simply re-recreate
those. Now will will want to run debsums -c. This will check all
installed packages for corrupted/missing files. It should tell you what
packages these are from. If not you can use dpkg to query for them.

Ounce you have determined which packages are corrupted you can
reinstall them from the repositories with like like so. In this example
Vim, eudev, and tzdata had missing and corrupted files on my pi.

apt-get install --reinstall eudev vim-common tzdata

It's a good idea to run debsums -c one more time to make sure you got
everything. Ounce you've reinstalled all your corrupted packages reboot
again and watch your bootup process for any more errors you may need to
resolve by hand. If not double check all your mounts for insane
parameters using the 'mount' command. If everything looks perfect you
should be safe from now on.

I am currently studying how the Raspberry Pi Devuan image is made so
that I may supply patches to fix this by default for the next
point release or hotfix. Till then this manual procedure should
suffice. My guess is that RPI support was just copy-pasted from rasbian
without a whole lot of checking.