Hello Phillip,

Just as a quick follow up, I was able to put fiasco in the assets path, but also had to copy some configs over from the examples in src after which I could run some of them to run, but not many as they were missing some other files as well.

I am particularly interested in running framebuffer examples with the uvmm and multiple VM's active at once on x64 if at all possible.  Some other microhypervisor examples with graphics would also be very interesting to see run as well.

Thanks again and have a great day, Lonnie

On 11/5/2024 3:22 PM, Lonnie Cumberland wrote:

Hello Phillip,

Thanks for getting back to me on these and I have been able to confirm that the  .elf32 bit versions do run in qemu which is a good step forward and the .efi (x64) version do not at this time as you mentioned.

regarding the "make qemu" I am able to bring up the list, but when I select one (actually all of them behave like this), I get an error:

---

Could not find   'fiasco'

within paths

/home/lonnie/build-amd64/assets   /home/lonnie/build-amd64/bin/amd64_gen/l4f   /home/lonnie/build-amd64/bin/amd64_gen/plain   /home/lonnie/build-amd64/lib/amd64_gen/std/l4f   /home/lonnie/build-amd64/lib/amd64_gen/std/plain make[1]: *** [Makefile:693: qemu] Error 1 make[1]: Leaving directory '/home/lonnie/l4' make: *** [Makefile:6: do-all-make-goals] Error 2

---

My fresh setup is via ham and as per the steps "https://github.com/kernkonzept/manifest/wiki/BUILDING"

I put ham in my ~/bin/ham and then added it to the PATH so that it is able to be used.

On a side question regarding ham, I did try to create a "~/l4re" directory and then did the ham init from within there thinking that it might put all of the L4Re related directories under that initial sub-directory, but it did not and put them under my base home directory.  Is there some cli switch or flag that I can use to have ham put everything in the l4re sub-directory and build in there instead. This is not critical, but mostly just to keep all of the l4re stuff together and in one sub-directory for good housekeeping, I guess?

Thanks again and have a great day, Lonie

On 11/5/2024 7:40 AM, Philipp Eppelt wrote:

...

Hi Lonnie,

welcome to the L4Re learning curve. :-)

Indeed, there seems to be a problem with .efi images. Thanks for letting us know.

I can boot the .elf32 image though:     l4image -i l4re_vm-basic-pci.elf32 launch

It behaves like shown in the screencast: https://l4re.org/cast-vm-basic-pci-qemu-x86.html

Since you already have the github version, you can run the examples from the l4re build directory. `make qemu` executed in your l4re build directory should show a list of example entries to run. These examples are the same as the prebuild images.

Cheers, Philipp

Am 03.11.24 um 21:52 schrieb Lonnie Cumberland:

...

Hello All,

I hope that your day is going well. Recently, I have decided to explore L4Re as a microhypervisor and capabilities as a possible minimalist component-based microkernel OS.

I have just set up Ubuntu 23.10 (x64) in an Intel NUC13 and would am reviewing as much documentation as I can find as well as am building the core L4Re according to the Github Wiki just to see how the process goes.

https://github.com/kernkonzept/manifest/wiki/BUILDING

As I am in the learning curve at the moment, I also would like to build some examples such as the "Screenshots" (https://l4re.org/screens.html) and demos from the Pre-Built section (https://l4re.org/download/snapshots/pre-built-images/amd64/). I did try to follow the direction on the pre-built sections and grabbed the "l4image" and all of the AMD64 EFI files to try and test, but when I launch them they just seem to hang and do nothing.  I do have qemu (x64) installed as well, but still nothing seems to boot.

What I would like to ask the mailinglist members is where can I get the source code to the "screenshots" examples as well as the AMD64 "pre-built" examples noted above so that I cam do a fresh compile to see them in action?

Any help would be greatly appreciated.

Thanks in advance and have a great day, Lonnie

---

l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de

_______________________________________________ l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de

Hello Philipp,

Thanks for the information on the paths and ham. I am now working through things to try and get a better feel on the general process as it is not yet clear to me but getting better each day, with the guidance that you have provided me.

Probably like most people, I am generally always initially interested in seeing as many different examples run when initially exploring software packages as it gives me an idea as to the capabilities as well as how it all might be used towards the projects that I am working on now.

With that in mind, I will explore the "make qemu" examples to see what it takes to get them to run.  I am particularity interested in GUI applications and things that might use framebuffers which is why I am very interested in the "screenshot" on the L4Re website and maybe even replicating some of them even though those are a bit old now.

I would really like to see some microhypervisor examples that perhaps use framebuffers as well, if that is possible, and to maybe even run something in qemu first, after which then maybe to boot up a Live ISO on some real hardware to see it work there as well since my project is towards a very lightweight microhypervisor which will allow you to Hot-Key between VM consoles that have GUI's running perhaps.I am thinking that maybe a PoC that can auto-start 1 VM (with GUI) and then dynamically be able to start more, after which to be able to toggle between each VM GUI console with a hotkey. Maybe also be able to use a hotkey to terminate and destroy a VM am as well, or something along these lines.  My key goals are to have it run Live (RAMDISK based) and keeping the core microhypervisor footprint as small as possible.

Until then, I will just continue to explore L4Re more since I truly think that it is what I have been seeking for a number of years now, for this project effort to finally get going.

Best Regards and have a great evening, my friend. Lonnie

On 11/6/2024 12:29 PM, Philipp Eppelt wrote:

Hi Lonnie,

it works with copying stuff to the assets directory, because the assets directory path is in the MODULE_SEARCH_PATH aka the list of paths printed in the error output.

You can configure the MODULE_SEARCH_PATH and also the QEMU command line via the conf/Makeconf.boot file. Have a look at https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot and https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot

So to get fiasco automatically picked up you need to specify something like

MODULE_SEARCH_PATH += /path/to/fiasco/build/dir

(e.g. line 26 in https://github.com/kernkonzept/mk/blob/master/conf/Makeconf.boot.example)

The same applies to directories that contain binaries not found. Just add the directory paths in the same way to the MODULE_SEARCH_PATH separated by a colon.

The list `make qemu` shows is generated from the entries in l4/conf/modules.list, so make sure to have all folders containing the mentioned files in the MODULE_SEARCH_PATH. (Yes, these paths should be in the MODULE_SEARCH_PATH from the start, I'll see that this gets more beginner friendly.)

Regarding ham: Yes, you can use any directory to check out into and there is no relation to the location of the ham binary. I myself have the same ~/bin/ham file which links to ~/code/ham/ham and my folder for the checkout is ~/code/l4/public.

ham init -u ... generated a ~/code/l4/public/.ham and ham sync generated ~/code/l4/public/{fiasco,l4} folders.

However, note that `ham init` uses the _current directory_ to place the .ham directory into. `ham sync` than places the files in parallel to the .ham directory.

Cheers, Philipp

Am 05.11.24 um 21:41 schrieb Lonnie Cumberland:

...

Hello Phillip,

Just as a quick follow up, I was able to put fiasco in the assets path, but also had to copy some configs over from the examples in src after which I could run some of them to run, but not many as they were missing some other files as well.

I am particularly interested in running framebuffer examples with the uvmm and multiple VM's active at once on x64 if at all possible.  Some other microhypervisor examples with graphics would also be very interesting to see run as well.

Thanks again and have a great day, Lonnie

On 11/5/2024 3:22 PM, Lonnie Cumberland wrote:

...

Hello Phillip,

Thanks for getting back to me on these and I have been able to confirm that the  .elf32 bit versions do run in qemu which is a good step forward and the .efi (x64) version do not at this time as you mentioned.

regarding the "make qemu" I am able to bring up the list, but when I select one (actually all of them behave like this), I get an error:

---

Could not find   'fiasco'

within paths

/home/lonnie/build-amd64/assets   /home/lonnie/build-amd64/bin/amd64_gen/l4f   /home/lonnie/build-amd64/bin/amd64_gen/plain   /home/lonnie/build-amd64/lib/amd64_gen/std/l4f   /home/lonnie/build-amd64/lib/amd64_gen/std/plain make[1]: *** [Makefile:693: qemu] Error 1 make[1]: Leaving directory '/home/lonnie/l4' make: *** [Makefile:6: do-all-make-goals] Error 2

---

My fresh setup is via ham and as per the steps "https://github.com/kernkonzept/manifest/wiki/BUILDING"

I put ham in my ~/bin/ham and then added it to the PATH so that it is able to be used.

On a side question regarding ham, I did try to create a "~/l4re" directory and then did the ham init from within there thinking that it might put all of the L4Re related directories under that initial sub-directory, but it did not and put them under my base home directory.  Is there some cli switch or flag that I can use to have ham put everything in the l4re sub-directory and build in there instead. This is not critical, but mostly just to keep all of the l4re stuff together and in one sub-directory for good housekeeping, I guess?

Thanks again and have a great day, Lonie

On 11/5/2024 7:40 AM, Philipp Eppelt wrote:

...

Hi Lonnie,

welcome to the L4Re learning curve. :-)

Indeed, there seems to be a problem with .efi images. Thanks for letting us know.

I can boot the .elf32 image though:     l4image -i l4re_vm-basic-pci.elf32 launch

It behaves like shown in the screencast: https://l4re.org/cast-vm-basic-pci-qemu-x86.html

Since you already have the github version, you can run the examples from the l4re build directory. `make qemu` executed in your l4re build directory should show a list of example entries to run. These examples are the same as the prebuild images.

Cheers, Philipp

Am 03.11.24 um 21:52 schrieb Lonnie Cumberland:

...

Hello All,

I hope that your day is going well. Recently, I have decided to explore L4Re as a microhypervisor and capabilities as a possible minimalist component-based microkernel OS.

I have just set up Ubuntu 23.10 (x64) in an Intel NUC13 and would am reviewing as much documentation as I can find as well as am building the core L4Re according to the Github Wiki just to see how the process goes.

https://github.com/kernkonzept/manifest/wiki/BUILDING

As I am in the learning curve at the moment, I also would like to build some examples such as the "Screenshots" (https://l4re.org/screens.html) and demos from the Pre-Built section (https://l4re.org/download/snapshots/pre-built-images/amd64/). I did try to follow the direction on the pre-built sections and grabbed the "l4image" and all of the AMD64 EFI files to try and test, but when I launch them they just seem to hang and do nothing.  I do have qemu (x64) installed as well, but still nothing seems to boot.

What I would like to ask the mailinglist members is where can I get the source code to the "screenshots" examples as well as the AMD64 "pre-built" examples noted above so that I cam do a fresh compile to see them in action?

Any help would be greatly appreciated.

Thanks in advance and have a great day, Lonnie

---

l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de

_______________________________________________ l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de

Hello Philipp,

Hope that your weekend is going well.

I grabbed the latest snapshot and did a complete build of things. So far, I have been able to also run the hello* and framebuffer examples from the "make qemu" but the VM-multi and VM-multi-p2p as well as the L4liux examples seem to boot up but then crash out in the VM's although I think that the "cons" is still running.

For my project PoC effort, I think that booting up something like the VM-multi-p2p along with the framebuffer modules might be a good start if I can get it to work.  Once that is working then maybe the goal would be to create a new module of something like FreeRDP or similar that will be running as the main GUI and connect to a web-browser running in a VM that will get serviced by another VM for the web-desktop.

I guess that this approach could be reduced by one step if a VM could run a small Linux version with a web browser directly and serve it up to the console.

Other capabilities might be to have the cons console multiplexer be able to actively switch VM's in a graphics mode in much the same way as having multiple QEMU instances in graphic mode for that VM, as an idea.

Anyway, have a great weekend, Lonnie

On 11/7/2024 4:20 AM, Philipp Eppelt wrote:

Hi Lonnie,

Am 06.11.24 um 23:02 schrieb Lonnie Cumberland:

...

Hello Philipp,

Thanks for the information on the paths and ham. I am now working through things to try and get a better feel on the general process as it is not yet clear to me but getting better each day, with the guidance that you have provided me.

Probably like most people, I am generally always initially interested in seeing as many different examples run when initially exploring software packages as it gives me an idea as to the capabilities as well as how it all might be used towards the projects that I am working on now.

With that in mind, I will explore the "make qemu" examples to see what it takes to get them to run.  I am particularity interested in GUI applications and things that might use framebuffers which is why I am very interested in the "screenshot" on the L4Re website and maybe even replicating some of them even though those are a bit old now.

Examples with GUI are the framebuffer-example and L4Linux-mag. mag is a framebuffer multiplexer. mag is not on github, but it is part of the 2024.08-snapshot at https://l4re.org/download/snapshots/. In the snapshot its at src/l4/pkg/mag. I haven't worked with mag, so I can't tell more about it.

You might be able to just copy the pkg/mag directory to the sources acquired from github, but bear in mind that the github release is a development state and these might not fit together anymore (but I just see one commit on top since August, I'm optimistic).

Unfortunately, I can't tell you more about these screenshots. I don't know from which setups they were created.

...

I would really like to see some microhypervisor examples that perhaps use framebuffers as well, if that is possible, and to maybe even run something in qemu first, after which then maybe to boot up a Live ISO on some real hardware to see it work there as well since my project is towards a very lightweight microhypervisor which will allow you to Hot-Key between VM consoles that have GUI's running perhaps.I am thinking that maybe a PoC that can auto-start 1 VM (with GUI) and then dynamically be able to start more, after which to be able to toggle between each VM GUI console with a hotkey. Maybe also be able to use a hotkey to terminate and destroy a VM am as well, or something along these lines.  My key goals are to have it run Live (RAMDISK based) and keeping the core microhypervisor footprint as small as possible.

That's a very nice project. It comes with a learning curve and has its coding challenges. :-)

Cheers, Philipp

...

Until then, I will just continue to explore L4Re more since I truly think that it is what I have been seeking for a number of years now, for this project effort to finally get going. > Best Regards and have a great evening, my friend. Lonnie

On 11/6/2024 12:29 PM, Philipp Eppelt wrote:

...

Hi Lonnie,

it works with copying stuff to the assets directory, because the assets directory path is in the MODULE_SEARCH_PATH aka the list of paths printed in the error output.

You can configure the MODULE_SEARCH_PATH and also the QEMU command line via the conf/Makeconf.boot file. Have a look at https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot

and https://github.com/kernkonzept/manifest/wiki/LinuxVM#creating-makeconfboot

So to get fiasco automatically picked up you need to specify something like

MODULE_SEARCH_PATH += /path/to/fiasco/build/dir

(e.g. line 26 in https://github.com/kernkonzept/mk/blob/master/conf/Makeconf.boot.example)

The same applies to directories that contain binaries not found. Just add the directory paths in the same way to the MODULE_SEARCH_PATH separated by a colon.

The list `make qemu` shows is generated from the entries in l4/conf/modules.list, so make sure to have all folders containing the mentioned files in the MODULE_SEARCH_PATH. (Yes, these paths should be in the MODULE_SEARCH_PATH from the start, I'll see that this gets more beginner friendly.)

Regarding ham: Yes, you can use any directory to check out into and there is no relation to the location of the ham binary. I myself have the same ~/bin/ham file which links to ~/code/ham/ham and my folder for the checkout is ~/code/l4/public.

ham init -u ... generated a ~/code/l4/public/.ham and ham sync generated ~/code/l4/public/{fiasco,l4} folders.

However, note that `ham init` uses the _current directory_ to place the .ham directory into. `ham sync` than places the files in parallel to the .ham directory.

Cheers, Philipp

Am 05.11.24 um 21:41 schrieb Lonnie Cumberland:

...

Hello Phillip,

Just as a quick follow up, I was able to put fiasco in the assets path, but also had to copy some configs over from the examples in src after which I could run some of them to run, but not many as they were missing some other files as well.

I am particularly interested in running framebuffer examples with the uvmm and multiple VM's active at once on x64 if at all possible.  Some other microhypervisor examples with graphics would also be very interesting to see run as well.

Thanks again and have a great day, Lonnie

On 11/5/2024 3:22 PM, Lonnie Cumberland wrote:

...

Hello Phillip,

Thanks for getting back to me on these and I have been able to confirm that the  .elf32 bit versions do run in qemu which is a good step forward and the .efi (x64) version do not at this time as you mentioned.

regarding the "make qemu" I am able to bring up the list, but when I select one (actually all of them behave like this), I get an error:

---

Could not find   'fiasco'

within paths

/home/lonnie/build-amd64/assets   /home/lonnie/build-amd64/bin/amd64_gen/l4f   /home/lonnie/build-amd64/bin/amd64_gen/plain   /home/lonnie/build-amd64/lib/amd64_gen/std/l4f   /home/lonnie/build-amd64/lib/amd64_gen/std/plain make[1]: *** [Makefile:693: qemu] Error 1 make[1]: Leaving directory '/home/lonnie/l4' make: *** [Makefile:6: do-all-make-goals] Error 2

---

My fresh setup is via ham and as per the steps "https://github.com/kernkonzept/manifest/wiki/BUILDING"

I put ham in my ~/bin/ham and then added it to the PATH so that it is able to be used.

On a side question regarding ham, I did try to create a "~/l4re" directory and then did the ham init from within there thinking that it might put all of the L4Re related directories under that initial sub-directory, but it did not and put them under my base home directory.  Is there some cli switch or flag that I can use to have ham put everything in the l4re sub-directory and build in there instead. This is not critical, but mostly just to keep all of the l4re stuff together and in one sub-directory for good housekeeping, I guess?

Thanks again and have a great day, Lonie

On 11/5/2024 7:40 AM, Philipp Eppelt wrote:

...

Hi Lonnie,

welcome to the L4Re learning curve. :-)

Indeed, there seems to be a problem with .efi images. Thanks for letting us know.

I can boot the .elf32 image though:     l4image -i l4re_vm-basic-pci.elf32 launch

It behaves like shown in the screencast: https://l4re.org/cast-vm-basic-pci-qemu-x86.html

Since you already have the github version, you can run the examples from the l4re build directory. `make qemu` executed in your l4re build directory should show a list of example entries to run. These examples are the same as the prebuild images.

Cheers, Philipp

Am 03.11.24 um 21:52 schrieb Lonnie Cumberland: > Hello All, > > I hope that your day is going well. > Recently, I have decided to explore L4Re as a microhypervisor > and capabilities as a possible minimalist component-based > microkernel OS. > > I have just set up Ubuntu 23.10 (x64) in an Intel NUC13 and > would am reviewing as much documentation as I can find as well > as am building the core L4Re according to the Github Wiki just > to see how the process goes. > > https://github.com/kernkonzept/manifest/wiki/BUILDING > > As I am in the learning curve at the moment, I also would like > to build some examples such as the "Screenshots" > (https://l4re.org/screens.html) and demos from the Pre-Built > section > (https://l4re.org/download/snapshots/pre-built-images/amd64/). I > did try to follow the direction on the pre-built sections and > grabbed the "l4image" and all of the AMD64 EFI files to try and > test, but when I launch them they just seem to hang and do > nothing.  I do have qemu (x64) installed as well, but still > nothing seems to boot. > > What I would like to ask the mailinglist members is where can I > get the source code to the "screenshots" examples as well as the > AMD64 "pre-built" examples noted above so that I cam do a fresh > compile to see them in action? > > Any help would be greatly appreciated. > > Thanks in advance and have a great day, > Lonnie > > _______________________________________________ > l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de > To unsubscribe send an email to > l4-hackers-leave@os.inf.tu-dresden.de

_______________________________________________ l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de