The rollback state of this module doesn’t seem to be working correctly. This line “[[ -f $prev_files_tar ]]” always fails. This is a bash command not a shell command and since the dir-overlay module is using “#!/bin/sh” instead of “#!/bin/bash”, it does not work. Maybe it works on some machines, but I’m pretty sure this a built in bash command. Also, even when the rollback does execute, it copies all the backed up files to the root of the overlay and not where they were copied from, since all the files are copied to the tmp directory and tarred up without their original location. At least that’s what happened when I tried the rollback feature, unless I’m doing something wrong?
Regarding the second problem you mention, this was recently fixed by @texierp.
Regarding the first issue, you are probably right that it is bashism. Please feel free to fix 
1 Like
@texierp and @mirzak That gets the files where they need to go, but after it rolls back my root directory permission gets set to 700 and all the directories in the overlay get owned by root. So, I can’t even get into it unless I use the serial port. Any ideas why it would set the root directory permissions to 700? Or how to keep the current directory permisisons I tried using the -p flag on tar, but stil can’t get it to work…
@speeltronics, indeed you’re right.
I’ve made a fix, can you try ?
There is also a fix for the bashism:
Let me know if it is good for you 
@texierp, feel free to submit a PR for " module/dir-overlay: fix bashism in rollback state"
A comment on " module/dir-overlay: make sure permissions are preserved after a rollback", this change only fixes the permission of the root directory but not the underlying files.
What I suggest that we do is for the dir-overlay generator and installer to “preserve” owner ship and permissions of all files (it does not do this today but I think it should). Getting around the problem of DEST_DIR changing permissions is not possible in a “generic” way. The “workaround” is to make sure that OVERLAY_TREE permissions are the same as DEST_DIR on target, because this where how these permissions are transferred and that is why I want the module to “preserve” properties in the module and then it is up to the user to set them.
Then the example of generating sample files would look something like this,
# The permissions must match DEST_DIR on the target rootfs
sudo install -d -m 755 -g root -o root rootfs_overlay
# Create directory structure
sudo install -d -m 755 -g root -o root rootfs_overlay/etc
sudo install -d -m 755 -g root -o root rootfs_overlay/usr/bin
sudo install -d -m 755 -g root -o root rootfs_overlay/usr/share/app
# Create sample files
sudo touch rootfs_overlay/etc/app.conf
sudo touch rootfs_overlay/usr/bin/app
sudo touch rootfs_overlay/usr/share/app/data.txt
# You would typically chmod above files to have the appropriate mode in a production environment
I have a patch prepared for this, but I need to some more testing.
I will do.
Sure, but during my quick test, it seems the problem only appears for the root directory (to be confirmed 
)
Thanks @mirzak for the feedback and the suggestion, I’m going to test it and investigate more.
This is what I was thinking (still testing needed),
@mirzak sure, but on my target
root@nitrogen8m:~# cp --parents
cp: unrecognized option '--parents'
that’s why I used tar in fact.
Ah makes sense, it is probably not present in a busybox cp. I will revert that part
Indeed you’re right
Confirmed that it only appears for the root directory for the install. The other directories follow the permissions and owners of what is set in for the overlay directory and if the overlay directory is not set to root it will also change the owner of the root directory. The permissions file does the trick for the root permissions. Thanks!
1 Like
This does work for the roll back using these changes with “cp --archive --parents {dest_dir}/{file} ${backup_dir}”. I could not get it to work correctly using the line “tar cf - $dest_dir/$file | (cd $backup_dir/ && tar xf -)”, it would change my user’s home directory to be owned by root on the roll back.
One thing I did notice is if one of the files is set to 700 and owned by root then I had to call the generator as sudo and put the mender-artifact in the /sbin directory if I generated it as a user other than root.
@speeltronics, great, thanks for reporting back.
We have pushed a couple of code changes and update the post with new instructions when creating the input directory.
Please give it a try now, and make sure to update both generator and module to get the latest changes.
1 Like