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:
#!/bin/sh
# 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
newroot=/dev/mmcblk0p3
elif [ $current = "3" ]; then
newroot=/dev/mmcblk0p2
else
echo "Unexpected current root: $current" >&2
exit 1
fi
mount $newroot /mnt
if [ $? -ne 0 ]; then
echo "Failed to mount $newroot" >&2
exit 1
fi
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.
thanks,
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.
Joe
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
Joe
{"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"}
@ferguman Hi, even i am looking for same thing like sending logs to server back. Do you have any luck with this or any new idea for sending logs back to server.
You shouldn’t need to access the old partition. Deployment logs should always be available in the persistent partition @ /data/mender/, /var/lib/mender/ should just be a symlink.
Hi,
Sorry no. To tell you the truth I’m looking for an alternative to Mender because they charge for their hosted service. I either want to host my own cloud update system or get access to a free one. I’m willing to pay if my business scales up but right now I’m only hosting a handful of test systems so it’s not worth it. The Mender folks are great, it’s just that my unique situation doesn’t seem to fit their business model.
Hi @ferguman while we do charge for our hosted plans, you can run the open source Mender server your self. Have you looked at that option? Alternatively, our Mender Enterprise plan comes 12-month free for up to 10 devices. Let me know if I can help you with this. We definitely want to keep you as a Mender user if we can.