I have seen a couple other reports of mender-growfs-data errors, but the output in my case is different, so I figured I would report it here, and get some input on how to move forward.
Yocto Warrior
Mender Client 2.2.0 runtime: go1.12.9
Hardware based on BBB reference
Output at kernel start is similar to or the same as previous reports, i.e.
[FAILED] Failed to start Mender ser…e to grow data partition size.
Note, ^ This does not delay boot.
journalctl -xe -u mender-grow-data.service
-- Logs begin at Sun 2020-08-23 19:45:30Pm-՝�����Ң�Қ������ѥٕ���պ2Ղ2�
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-pa�j����ɵ����ѵ��ͥ镵"�х�����m������rյ��Ɂz��履����́2�Ɂ���́"�ͭ�J́��с������rj����*��$�&HLN��5:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: There is nothing wrong with that, but this is larger than 1024,
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: and could in certain setups cause problems with:
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: 1) software that runs at boot time (e.g., old versions of LILO)
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: 2) booting and partitioning software from other OSs
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: (e.g., DOS FDISK, OS/2 FDISK)
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: Command (m for help): The partition table has been altered.
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: Calling ioctl() to re-read partition table
Aug 23 19:45:30 redaptive-0c1c57f50f6a mender-client-resize-data-part[87]: fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
Aug 23 19:45:30 redaptive-0c1c57f50f6a systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mmender-grow-data.service: Main process exited, code=exited, status=1/FAILURE[[0m
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: [https://lists.freedesktop.org/mailman/listinfo/systemd-devel](https://slack-redir.net/link?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fsystemd-devel)
--
-- An ExecStart= process belonging to unit mender-grow-data.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Aug 23 19:45:30 redaptive-0c1c57f50f6a systemd[1]: [[0;1;39m[[0;1;31m[[0;1;39mmender-grow-data.service: Failed with result 'exit-code'.[[0m
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: [https://lists.freedesktop.org/mailman/listinfo/systemd-devel](https://slack-redir.net/link?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fsystemd-devel)
--
-- The unit mender-grow-data.service has entered the 'failed' state with result 'exit-code'.
Aug 23 19:45:30 redaptive-0c1c57f50f6a systemd[1]: [[0;1;31m[[0;1;39m[[0;1;31mFailed to start Mender service to grow data partition size.[[0m
-- Subject: A start job for unit mender-grow-data.service has failed
-- Defined-By: systemd
-- Support: [https://lists.freedesktop.org/mailman/listinfo/systemd-devel](https://slack-redir.net/link?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fsystemd-devel)
--
-- A start job for unit mender-grow-data.service has finished with a failure.
--
-- The job identifier is 35 and the job result is failed.
It looks like /usr/bin/mender-client-resize-data-part is exiting on
echo “w” | fdisk ${MENDER_STORAGE_DEVICE}
i.e.
echo “w” | fdisk /dev/mmcblk1
The number of cylinders for this disk is set to 58368.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
- software that runs at boot time (e.g., old versions of LILO)
- booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy
We dont currently need to grow /data, but if this behavior presents a risk, we will need to scramble to issue a hotfix, as this image has a scheduled kit-drop this Tuesday.
This seems to be benign, but its mucking about with fdisk and parted so I wanted to check and see if its safe to leave it be in this weeks manufacturing run, and disable the feature in future releases.
THNX!
SLR-