TorizonCore builder fails when isolating changes

Hi

I am trying to isolate changes made to an Apalis iMX8 with TorizonCore builder to create a new Torizon image. Those changes are two services that I added.

When I try to isolate them, I get this error:

tomas@tomas-pc:~/tcb$ torizoncore-builder isolate --remote-host 192.168.0.220 --remote-username torizon --remote-password 1234 --changes-directory changes --force
An unexpected Exception occured. Please provide the following stack trace to
the Toradex TorizonCore support team:


Traceback (most recent call last):
  File "/builder/torizoncore-builder", line 204, in <module>
    mainargs.func(mainargs)
  File "/builder/tcbuilder/cli/isolate.py", line 64, in isolate_subcommand
    common.set_output_ownership(changes_dir)
  File "/builder/tcbuilder/backend/common.py", line 537, in set_output_ownership
    apply_workdir_ownership(os.path.join(rootdir, filename),
  File "/builder/tcbuilder/backend/common.py", line 502, in apply_workdir_ownership
    file_uid, file_gid = get_file_ownership(filename)
  File "/builder/tcbuilder/backend/common.py", line 516, in get_file_ownership
    stat = os.stat(filename)
FileNotFoundError: [Errno 2] No such file or directory: '/workdir/changes/usr/etc/systemd/system/multi-user.target.wants/run-microelect-app.service'

These are the contents of /etc/systemd/system/multi-user.target.wants in Torizon:

imx8:/etc/systemd/system/multi-user.target.wants$ ls
ModemManager.service    aktualizr.service     docker.service     iptables.service             ostree-pending-reboot.path  rngd.service     run-microelect-app.service  systemd-resolved.service  usermount.service
NetworkManager.service  avahi-daemon.service  ip6tables.service  ostree-finalize-staged.path  remote-fs.target            rpcbind.service  systemd-networkd.service    usb-update.service

I am running torizoncore-builder in the same working directory as where I ran tcb-env-setup.sh.
I don’t know what I am doing wrong here.

Thank you,
Tomás

Greetings @tomas.ayi,

Based off the error it seems it’s not having issues with isolating the file from the device but rather the copy of this file that is in your changes directory.

So you used the --changes-directory flag which saves the isolated changes to the directory specified rather than the tool’s internal storage. According to the error it can’t find the file in this /changes directory that you specified.

What is the content of your /changes directory after the error occurs? Furthermore does this error still occur if you omit --changes-directory?

Best Regards,
Jeremias

Hi @jeremias.tx,

The contents of /changes are:

tomas@tomas-pc:~/tcb$ find changes/
changes/
changes/usr
changes/usr/etc
changes/usr/etc/udev
changes/usr/etc/udev/rules.d
changes/usr/etc/udev/rules.d/98-usb-update.rules
changes/usr/etc/.tcattr
changes/usr/etc/NetworkManager
changes/usr/etc/NetworkManager/system-connections
changes/usr/etc/NetworkManager/system-connections/gsm.nmconnection
changes/usr/etc/NetworkManager/system-connections/TTT.nmconnection
changes/usr/etc/shadow
changes/usr/etc/fstab
changes/usr/etc/systemd
changes/usr/etc/systemd/system
changes/usr/etc/systemd/system/run-microelect-app.service
changes/usr/etc/systemd/system/docker.service.d
changes/usr/etc/systemd/system/docker.service.d/override.conf
changes/usr/etc/systemd/system/usb-update.service
changes/usr/etc/systemd/system/multi-user.target.wants
changes/usr/etc/systemd/system/multi-user.target.wants/run-microelect-app.service
changes/usr/etc/systemd/system/multi-user.target.wants/usb-update.service
changes/usr/etc/systemd/system/multi-user.target.wants/.wh.docker-compose.service
changes/usr/etc/gshadow
changes/usr/etc/sudoers.d
changes/usr/etc/sudoers.d/50-torizon
changes/usr/etc/group

There you can see that run-microelect-app.service is located at /usr/etc/systemd/system/. The one at /usr/etc/systemd/system/multi-user.target.wants is a symlink to the former.

tomas@tomas-pc:~/tcb/changes/usr/etc/systemd/system$ ls -la
total 24
drwxr-xr-x 4 tomas tomas 4096 ago  4 21:04 .
drwxr-xr-x 3 tomas tomas 4096 ago  4 21:04 ..
drwxr-xr-x 2 tomas tomas 4096 jun 29 02:18 docker.service.d
drwxr-xr-x 2 tomas tomas 4096 ago  4 21:04 multi-user.target.wants
-rw-r--r-- 1 tomas tomas  224 jun 24 01:21 run-microelect-app.service
-rw-r--r-- 1 tomas tomas  164 jul 15 15:49 usb-update.service
tomas@tomas-pc:~/tcb/changes/usr/etc/systemd/system/multi-user.target.wants$ ls -la
total 8
drwxr-xr-x 2 tomas tomas 4096 ago  4 21:04 .
drwxr-xr-x 4 tomas tomas 4096 ago  4 21:04 ..
lrwxrwxrwx 1 root  root    46 jun 24 02:44 run-microelect-app.service -> /etc/systemd/system/run-microelect-app.service
lrwxrwxrwx 1 root  root    38 jul 15 11:27 usb-update.service -> /etc/systemd/system/usb-update.service
-rw-r--r-- 1 tomas tomas    0 ago  4 21:04 .wh.docker-compose.service

Anyways, I tried without --changes-directory and it worked fine. I tried it at first time but had some error I couldn’t remember now, but I think it’s because I called torizoncore-builder from outside of my tcb folder.

I’m sorry for wasting your time, and thank you for your help.

Best regards,
Tomás

Oh I don’t think you wasted my time at all. In fact I think you found a bug involving the usage of --changes-directory and symlinks.

When --changes-directory is specified we perform some file operations in order to get the permissions/ownership of the files correct to match the user that is running torizoncore-builder. However I suspect what is happening here is that we try to perform file operations on the symlink which of course don’t work since it’s not an actual file. This in turn causes the somewhat misleading “file not found” error.

So thank you for reporting this. I’ll go ahead and report this bug for investigation and fixing.

Best Regards,
Jeremias

Well, that makes me feel better then!

Thank you

Regards,
Tomás

No problem, and just for your information I was able to make an internal bug report to get this investigated. In the meantime please refrain from using --changes-directory if possible.

Best Regards,
Jeremias

1 Like