Update Logs


I am writing software for the Raspberry Pi family of devices. See github.com/ferguman/fopd. I’ve been developing the infrastructure necessary to use mender for OTA. I’m using a state script Download_Leave to replace the /etc/hosts and /etc/hostname files of newly downloaded images with copies that are stored on the local device. I’m doing this so that if one changes the hostname of their fopd device to something like kitten123 or terminator9 then they presumably want the new hostname to survive Mender updates.

My question is: Is there a way to confirm after a successful update that my state script actually ran and did not produce any error messages? I tested it and it appeared to work but I always like to see a log entry or some other positive evidence. Here is my script:


# This script is a modification of the file found at:
# https://github.com/ferguman/fopd_mender_post_process/blob/master/state_scripts/Download_Leave_01

# Mount the new Linux file system
current=$(/sbin/fw_printenv mender_boot_part | awk -F = '{ print $2 }')

if [ $current = "2" ]; then
elif [ $current = "3" ]; then
    echo "Unexpected current root: $current" >&2
    exit 1

mount $newroot /mnt

if [ $? -ne 0 ]; then
    echo "Failed to mount $newroot" >&2
    exit 1

sleep 2

# Copy host and hostname files from /data to new Linux filesystem
cp /data/etc/hostname /mnt/etc/hostname
cp /data/etc/hosts /mnt/etc/hosts

# unmount the new Linux filesystem
umount $newroot



Hi @ferguman, the stderror logs from your script should appear in the Mender logs which you can view with “journalctl -u mender”. In case of an error in the update, these will be transferred back to the server. In the case of a successful update they are not transferred. We have discussed some mechanism to provide data back to the server but nothing concrete yet.


Yes, I don’t know how to look at systemd logs on an unmounted Linux filesystem. I think the info I want to see is in the old Linux file system (i.e. not the current one). I will have to research this. Don’t know much about systemd.

You can also look at old deployment logs in /var/lib/mender/deployments*.log, even those that were never sent to the server.

Very helpful. I pasted below what I found in a file named /var/lib/mender/deployments.001.[UUID].log on the old partition after a successful update and reboot. I see that the Mender system did call my state script.

Thanks to all

{"level":"info","message":"wrote 6081740800/6081740800 bytes of update to device /dev/mmcblk0p3","timestamp":"2019-08-28T20:54:16-05:00"}
{"level":"debug","message":"status reported, response 204 No Content","timestamp":"2019-08-28T20:54:18-05:00"}
{"level":"info","message":"State transition: update-store [Download_Enter] -\u003e update-after-store [Download_Leave]","timestamp":"2019-08-28T20:54:19-05:00"}
{"level":"info","message":"State transition: update-after-store [Download_Leave] -\u003e update-install [ArtifactInstall]","timestamp":"2019-08-28T20:54:19-05:00"}
{"level":"debug","message":"statescript: timeout for executing scripts is not defined; using default of 1h0m0s seconds","timestamp":"2019-08-28T20:54:20-05:00"}
{"level":"debug","message":"start executing script: Download_Leave_01","timestamp":"2019-08-28T20:54:20-05:00"}
{"level":"debug","message":"status reported, response 204 No Content","timestamp":"2019-08-28T20:54:20-05:00"}
{"level":"debug","message":"status reported, response 204 No Content","timestamp":"2019-08-28T20:54:25-05:00"}
{"level":"debug","message":"statescript: timeout for executing scripts is not defined; using default of 1h0m0s seconds","timestamp":"2019-08-28T20:54:25-05:00"}
{"level":"debug","message":"status reported, response 204 No Content","timestamp":"2019-08-28T20:54:25-05:00"}
{"level":"debug","message":"Inactive partition: /dev/mmcblk0p3","timestamp":"2019-08-28T20:54:25-05:00"}
{"level":"debug","message":"Marking inactive partition (/dev/mmcblk0p3) as the new boot candidate.","timestamp":"2019-08-28T20:54:25-05:00"}