# Migrating user info through artifact scripts **URL:** \ **Category:** General Discussions\ **Created:** [August 2, 2024, 3:12pm UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073 "2024-08-02T15:12:56Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![hellozee](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/hellozee/32/2089_2.png) [@hellozee](https://hub.mender.io/u/hellozee)\ **Post date:** [August 2, 2024, 3:12pm UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/1 "2024-08-02T15:12:57Z")
We have a script to migrate the user information which is similar to [this](https://github.com/mendersoftware/mender/blob/master/examples/state-scripts/retain-ssh-keys/Download_Leave_01) which works fine. But then we don’t want to migrate user info on data partition updates. So an approach would be to put the script inside the artifact. So we put the script inside ArtifactInstall\_Enter\_10 (also tried with Install\_Leave), which works sometimes and sometimes doesn’t. When it doesn’t work, it complains that the /mnt/etc doesn’t exist, and upon further putting in a `ls -al` into the new root, we got something like this, ```auto total 8 drwxr-xr-x 19 root root 4096 Aug 2 13:10 . drwxr-xr-x 19 root root 4096 Aug 2 13:10 .. lost+found ? ? ? ? ? bin d????????? ? ? ? ? ? boot d????????? ? ? ? ? ? data d????????? ? ? ? ? ? dev d????????? ? ? ? ? ? etc d????????? ? ? ? ? ? home lost+found ? ? ? ? ? lib lost+found ? ? ? ? ? lib64 d????????? ? ? ? ? ? lost+found d????????? ? ? ? ? ? media d????????? ? ? ? ? ? mnt d????????? ? ? ? ? ? opt d????????? ? ? ? ? ? proc d????????? ? ? ? ? ? root d????????? ? ? ? ? ? run lost+found ? ? ? ? ? sbin d????????? ? ? ? ? ? srv d????????? ? ? ? ? ? sys d????????? ? ? ? ? ? tmp d????????? ? ? ? ? ? usr d????????? ? ? ? ? ? var ``` Am I doing something wrong that we are not suppose to do user migration during the install? If I need to do it during Download\_Leave, how can I distinguish between a rootfs update and a data partition update? ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [August 19, 2024, 11:22am UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/2 "2024-08-19T11:22:32Z")
Hi @hellozee, not sure if I can add something enlightening, but some thoughts here. - distinguishing between a full root filesystem update and a data update would usually be done through the Update Module which is being used. - the “sometimes works, sometimes doesn’t” case is not exactly revealing. Have you tried adding debug statements which dump information to a place like `/data/debug_log.txt` or such and looking at it? - a long shot would be that you are migrating users and groups, but not the shadow files? Greets, Josef ---
**Author:** ![hellozee](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/hellozee/32/2089_2.png) [@hellozee](https://hub.mender.io/u/hellozee)\ **Post date:** [August 20, 2024, 7:23am UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/3 "2024-08-20T07:23:07Z")
> [@TheYoctoJester](#): > > distinguishing between a full root filesystem update and a data update would usually be done through the Update Module which is being used. Do we have that info in the download statescripts? We are already using the available rootfs-image for rootfs and the directory update module for the data partition updates. > [@TheYoctoJester](#): > > the “sometimes works, sometimes doesn’t” case is not exactly revealing. Have you tried adding debug statements which dump information to a place like `/data/debug_log.txt` or such and looking at it? Ahh, I missed mentioning that the output I posted is from a `ls -al` I put in the ArtifactInstall\_Enter script, so yes, I tried to log the partition details, artifact details. Upon reboot it is actually fine, but only when the script is running it is a problem, which I am unable to understand why? > [@TheYoctoJester](#): > > a long shot would be that you are migrating users and groups, but not the shadow files? The output I posted, is between mounting the new partition and migrating the users, where we check if the /etc directory exist or not, similar to [this](https://github.com/mendersoftware/mender/blob/master/examples/state-scripts/retain-ssh-keys/Download_Leave_01#L32), where it complains the directory doesn’t exist in the new partition. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [August 20, 2024, 6:50pm UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/4 "2024-08-20T18:50:51Z")
> [@hellozee](#): > > Do we have that info in the download statescripts? We are already using the available rootfs-image for rootfs and the directory update module for the data partition updates. The simplest trick is to take the existing `directory` Update Module, rename it to `data`, and add your logic. If you’re in the specific Update Module script, you obviously know where you are. Concerning artifact generation it just needs a changed type string, and it removes the need for handling the state scripts. > [@hellozee](#): > > Ahh, I missed mentioning that the output I posted is from a `ls -al` I put in the ArtifactInstall\_Enter script, so yes, I tried to log the partition details, artifact details. Upon reboot it is actually fine, but only when the script is running it is a problem, which I am unable to understand why? > [@hellozee](#): > > The output I posted, is between mounting the new partition and migrating the users, where we check if the /etc directory exist or not, similar to [this](https://github.com/mendersoftware/mender/blob/master/examples/state-scripts/retain-ssh-keys/Download_Leave_01#L32), where it complains the directory doesn’t exist in the new partition. My _guess_ would be that there is some effect going on that the system/shell don’t like if the user defining configuration files are touched in a live session, possibly in context of mounts. But that’s really just a guess, no real idea. For the record, I won’t be able to add anything here in the next about two weeks for personal reasons, sorry. Greets, Josef ---
**Author:** ![hellozee](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/hellozee/32/2089_2.png) [@hellozee](https://hub.mender.io/u/hellozee)\ **Post date:** [August 28, 2024, 8:04am UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/5 "2024-08-28T08:04:42Z")
Sorry totally forgot to update the thread. So after sniffing around a bit, with the log files, I realized that since we had udev-extraconf installed, it was also auto mounting the other root partition. And seems like flashing a disk while mounted would mess it up. Looking at the mender-flash source, it avoids writing data if the data it reads is same, which added up, since the only updates which were successful were the ones, we were writing very little. ---
**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\ **Post date:** [September 6, 2024, 11:33am UTC](https://hub.mender.io/t/migrating-user-info-through-artifact-scripts/7073/6 "2024-09-06T11:33:13Z")
@hellozee thanks for reporting back, I’ll mark this as solved then. Greets, Josef