Mender-data-grow on dunfell

General Discussions
1

Hi,

I’ve enable mender-grow-data feature but it seems it’s not working like should. From log:

Jan 26 10:30:48 device systemd[1]: Requested transaction contradicts existing jobs: Transaction for data.mount/stop is d
estructive (mender-systemd-growfs-data.service has 'start' job queued, but 'stop' is included in transaction).
Jan 26 10:30:48 device systemd[1]: data.mount: Failed to enqueue stop job, ignoring: Transaction for data.mount/stop is 
destructive (mender-systemd-growfs-data.service has 'start' job queued, but 'stop' is included in transaction).
Jan 26 10:30:49 device systemd[1]: Starting Mender service to grow data partition size...
Jan 26 10:30:49 device systemd[1]: mender-grow-data.service: Main process exited, code=exited, status=1/FAILURE
Jan 26 10:30:49 device systemd[1]: mender-grow-data.service: Failed with result 'exit-code'.
Jan 26 10:30:49 device systemd[1]: Failed to start Mender service to grow data partition size.
Jan 26 10:30:49 device systemd-growfs[246]: Failed to open "/dev/block/179:4": No such file or directory
Jan 26 10:30:49 device systemd[1]: mender-systemd-growfs-data.service: Main process exited, code=exited, status=1/FAILUR
E
Jan 26 10:30:49 device systemd[1]: mender-systemd-growfs-data.service: Failed with result 'exit-code'.

Is this know problem or? My target is orangepi-zero. Thanks.

2

does /dev/block/179:4 exist when you login to the device?

3

Yes. When inspected logs for those grow sevices one was stopped because data was already mounted. It’s weird as dependency is clearly there.

4

hmmm, i guess in your position I would start using some kinda systemd debugging tools to try and find out what is adding data.mount/stop to the growfs systemd transaction queue as why would there be a stop transaction request on data partition mounting on boot up? Could it be some option in your /etc/fstab causing an issue, as I believe the data.mount systemd service is auto-generated from fstab?