Hosting legato on Debian

I have some vanilla amd64 desktop hardware, and I’d like to host Legato on it for development purposes. I’m really not sure where to begin here. I downloaded and built legato for ‘localhost’, but I can’t install the system pack (because “/legato/systems/current/bin/update: No such file or directory”, naturally). It seems I can’t install Legato on my would-be host unless I already have Legato.

Do I have to do a custom kernel build with Yocto, or am I missing something glaringly more obvious than that?

Update: On my host computer, I just logged in as root and ran bin/legs and startlegato. The response I get is:

root@deblegato:/home/dev/workspace/legato# startlegato
Mar 6 11:32:54 : INFO | serviceDirectory[1732]/serviceDirectory_exe T=main | serviceDirectory.c _serviceDirectory_exe_COMPONENT_INIT() 2622 | Service Directory is ready.
Mar 6 11:32:54 : INFO | logCtrlDaemon[1735]/logDaemon T=main | logDaemon.c _logDaemon_COMPONENT_INIT() 2856 | Log daemon ready.
Started.

From my dev account I can successfully build the sample helloWorld application. But when I try to install it:

root@deblegato:/home/dev/hello# update helloWorld.localhost.update localhost
Applying update from file ‘helloWorld.localhost.update’ to device at address ‘localhost’.
root@localhost’s password:
bash: /legato/systems/current/bin/update: No such file or directory
Update failed

Can anyone offer me a clue on how to get unblocked here?

1 Like

I have the same problem.
Have you found a solution for that?

As it is now running Legato on a vanilla Linux is quite hard
You will face quite a lot of issues in trying to do so, as you will need to have all the Legato framework running (daemons like the supervisor, update, …) as root, and since as part of the runtime there are some cases that can trigger a reboot, you would see your PC reboot ‘just like that’, which is not really cool.

Supported workflow is to work with an hardware target.

Experimental workflow is to work with a simulated target called ‘virt’ that is purely software.
We don’t have much documentation on this virtual target, but I could try to write some if you are interested.

If you want to install Legato and run the full framework on a PC that is running a pre-existing Linux distro intended for desktop or servers, the problem is that Legato tries to manage user accounts, cgroups, and SMACK settings. This could potentially interfere with your OS distro for several reasons. Linux isn’t designed to have multiple security modules (LSMs) running at the same time. So, if you have AppArmor or SELinux running, you’ll have to rebuild your kernel to enable SMACK instead, but chances are good that your distro is trying to use one of those other LSMs and will get confused when it becomes unavailable. Also, if your system is configuring cgroups, there’s a potential for a conflict with Legato. (Legato will add and remove user accounts and groups for apps, but it shouldn’t remove any of the users and groups you already have in place, so that part should actually be okay.)

The main parts that are problematic are the Supervisor, the “startLegato” program, and the Update Daemon. If you want to do some testing of Legato programs, you can do that by starting the Service Directory and Log Control Daemon and then you should be able to run programs built with mkexe, mkapp, or mksys with the ‘-t localhost’ option. But, you can’t start and stop whole apps, or create/destroy sandboxes, because the Supervisor implements that part. The Config Tree daemon works, but it tries to use the directory /legato/systems/current/config to store its data, and that probably doesn’t exist on your system. The Watchdog daemon and Update Daemon require APIs provided by the Supervisor, so they won’t work without the Supervisor.

We do use the Service Directory, Log Control Daemon, and Config Tree for automated testing of many features on “localhost”, though, so if that’s all you want to do, that should work just fine.

@CoRfr, I’m definitely very interested in that documentation on the ‘virt’ target. :wink:

I haven’t tried it, but it seems to me that it should be possible to set up your own Linux distro (using the Yocto Project) for a PC, but as @CoRfr said, it’s not going to be easy. You’d need to

  • ensure that your kernel has cgroups and SMACK enabled
  • have at least one writeable file system partition, accessible through /mnt/flash (it doesn’t have to actually be a flash file system, though)
  • mount smackfs at /legato/smack
  • copy build/localhost/system/staging to /legato/systems/current/bin (as root)
  • for each app folder under build/localhost/system/app, (as root)
    • copy the app’s ‘staging’ folder contents to /legato/apps/, where is the app.MD5 value from the info.properties file inside the app’s staging directory.
  • create a file /legato/systems/current/status containing just the word “good”
  • set the security.SMACK64EXEC label of the supervisor

Then, to start it up, just run /legato/systems/current/bin/supervisor (as root).

…But, as I said, I haven’t tried it, so there could be something I missed.

(And, for those who aren’t already watching it, see also: http://forum.legato.io/t/legato-on-generic-linux)

In our case we’re trying to build our own distribution of linux that will include Legato, for use as an embedded OS. To that same end, we also have to build customized OS distributions for desktop development of said embedded OS. So getting Legato working on a nearly-Vanilla distro of Linux definitely helps in a big way.

Oh, I have a question on one of your steps:

set the security.SMACK64EXEC label of the supervisor

Set the label to what? “framework”?

Sorry. Set the supervisor’s label to “admin”. Good guess, though. :slight_smile:

The reason it’s different from the rest of the framework is that the plan is to someday set onlycap to “admin”, so only the Supervisor will be able to change SMACK permissions. onlycap isn’t used yet, though.

You mean that inside apps folder I should have a folder for each app with its name and inside have the content of stating folder. Something like that?
/legato/apps/atClient/
Is that right?

Now what I’m facing is that we have the message “Legato framework is running.”, but I’m not able to install any app.
It just get in a loop when I execute the instapp command.

Also, when I try to install an app or list the apps from my local legato I’m receiving the error below:
EMR | update[7060]/framework T=main | LE_FILENAME le_msg_OpenSessionSync() 2029 | Failed to connect to the Service Directory.

Any idea?

Hi,
is there a (possibly simple) way to port only Config Tree mechanism to Ubuntu Host for development purposes?

I’m also interested in this, has anyone found a way?

I’ve been out of Legato development for the last 9 months or so, but unless it has changed, you should be able to do a “localhost” build of the framework and your apps and then run “startlegato” to bring up the core of the IPC system on your build/development host so you can run app processes. It can be a bit tricky, though, because

  • the user ids are different, so the IPC bindings can sometimes not work as expected (on the target, each app has its own user id, but on the development host, everything runs as $USER).
  • you don’t have the supervisor, so you have to launch the config tree and app processes yourself.

Also, beware that the permissions will be different because cgroups, SMACK, and other permissions and limits are not being configured by the Supervisor when running on your development host.

@CoRfr has a “virt” containerized development target that works more like a real hardware target, but I’m not sure if it’s being maintained.

I wrote some documentation here some time ago: https://github.com/CoRfr/legato-virt

There is not much traction for it but I’m still using it as a tool.
As of now the latest doesn’t work again because Legato is not compatible with the latest kernel that is shipped with Yocto 2.5 (4.14, some recent SMACK dev broke the compatibility again). I am hopeful that it will be fixed for 19.03.

We now have a tool call leaf to manage dev environments. Since it’s allowing us to streamline some of the delivery process, we might be able to add the virtual platform in there without too much overhead.

We are also trying to make some of the system a bit more configurable. We are making paths such as /mnt/legato and /legato configurable for instance (experimental feature and not for SWI platforms, but can be useful as to port the framework to other platforms).