users April 2020

users@lists.genode.org

17 participants
24 discussions

depot_query: segmentation in _query_blueprint?
by Roman Iten 14 Apr '20

14 Apr '20

Dear Genodians I'm lost and would appreciate some inspiration on how to further debug a problem in a scenario that is similar to `run/depot_query`. My scenario seems to work fine on x86_64 but on 32-bit ARM (base-linux) the `depot_query` component segfaults. Well, it doesn't always segfault but it seems to depend either on the `depot.tar` or the `deploy.config` or both. However, the `deploy.config` and `depot.tar` don't need to change much: only the depot user or the package version may vary. The segfault occurs in `Depot_query::Main::_query_blueprint(...)` when accessing the `node` parameter that has been instantiated by the class `File_content` when calling the lambda. I also need to mention that the segfault reproducibly occurs at the same "to be deployed" runtime (pkg/chroot) - at least for a given `depot.tar` / `deploy.config`. Other, much larger runtime files (~9k) have been processed successfully prior that in `pkg/chroot`. I'm aware that this is a rather vague description and therefore tried to provide a modified the `run/depot_query.run` so it uses my `deploy.config` and `depot.tar`. But no luck, I can't reproduce the problem this way... Has anyone an idea what could possibly lead to a "corrupt" instance of `Xml_node`? Or how to test hypotheses like a stack overflow, ...? Thanks, Roman

3 6

Running sculpt in qemu with networking
by Shlomo Pongratz 13 Apr '20

13 Apr '20

Hi, In the documentation there are instruction to run sculpt in qemu e.g. qemu-system-x86_64 -display sdl -cpu core2duo -machine q35 \ -m 1024 -drive format=raw,file=sculpt-20.02.img However there are no instruction for choosing the right network model for qemu. Is choosing e1000 is a good choice? What is the best practice? Best regards, S.P.

2 1

Adding a components script to Sculpt on Build?
by Lonnie Cumberland 13 Apr '20

13 Apr '20

Hi All, Really getting more into Genode Sculpt now but am still having the problem with the menu items being off the screen in nitpicker, I think that it is, when walking through the VirtualBox sequence from the "Sculpt Operating System 20.02" which references me to : " Use GNU/Linux inside a virtual machine on top of Sculpt There is a ready-to-use package for downloading Debian for the use inside a vir- tual machine along with the ability to use VirtualBox guest additions: https://genodians.org/jws/2019-07-08-download_debian-guest-additions-reload… For configuring and starting the virtual machine, you may find the following guide useful: https://genodians.org/m-stein/2019-03-07-vm-with-sculpt-ce-preview " I am particularly interested in starting up VirtualBox to see how that works but with the "off screen" problem persistent to select the options needed for "vm-with-sculpt-ce-preview" directions, I started to wonder if it might be possible to have some type of "script" that I could add in during the img/iso builds for Sculpt that would automatically select and add in all of the components needed so that I could just boot up this new modified img/iso and have the VirtualBox frontend GUI started up by default? Any ideas on how something like this could be done in Sculpt? On that note, does Genode have plans to update to the latest VirtualBox 6.1.4 (I think that it is now) in the near future? Cheers and have a great weekend, Lonnie

2 3

A question on kernels
by Lonnie Cumberland 11 Apr '20

11 Apr '20

Hi All, I am reading up on Genode with a focus towards Sculpt which I have been able to build and run. Nice work, by the way, to the developers (Norman and team) !!! In my reading on the different kernels, it seems as though Genode can run by itself without a specific kernel, unless I read that wrong. With that in mind, I am wondering if Genode is compiling in the kernel and other components from a Unikernel or LibOS perhaps which could be the case, I guess. If this is true, then how would Sculpt be built without a kernel in place if you were to choose bare metal? Just some jumbled thoughts still as I am still trying to get the full picture for everything. Cheers and have a good weekend, Lonnie

2 3

Scrolling up options in Sculpt in Qemu
by Lonnie Cumberland 09 Apr '20

09 Apr '20

Morning All, I am slowly working through the Sculpt 20.02 documentation and have now figured out how to handle using Qemu after being able to compile up the Sculpt img which is actually easier to use than creating an iso and then running it in virtualbox. With that in mind, I have been able to get partly through the way for installing VirtualBox inside of Sculpt by following the instructions: https://genodians.org/m-stein/2019-03-07-vm-with-sculpt-ce-preview (The Sculpt documentation references using the above link for starting up virtualbox) But it seems that I need to be able to scroll to see some options off the Sculpt screen in Qemu [image: image.png] at the bottom so that I can see the other options. The standard scrolling does not seem to work here and any advice would be greatly appreciated. Making progress each day and I am starting to get a feel for things. Sculpt is much better than I initially thought as I like the fine-grained control. Cheers and have a great day, Lonnie

2 2

Virtualbox seems to crash in Sculpt
by Lonnie Cumberland 09 Apr '20

09 Apr '20

Hi All, I think that I have been able to make some progress on my attempts to get virtualbox started up underSculpt by following the directions: https://genodians.org/m-stein/2019-03-07-vm-with-sculpt-ce-preview Now I get what appears as a crash when I tell it to add the component. [image: image.png] I found it a bit easier to use Qemu (kvm) instead of VirtualBox on my Debian Host. The Qemu (kvm) invocation on my Debian system is: $kvm -smp 2 -cpu core2duo -machine q35 -m 10096 -drive format=raw,file=genode/build/x86_64/var/run/sculpt.img -netdev user,id=vlan0 -net nic,model=e1000,netdev=vlan0 I had to up the RAM to about 10GB as it seemed that in an earlier attempt while viewing the Sculpt log that virtualbox needed 8GB and at least now, it does not crash out due to lack of RAM which is a small step forward. Any ideas? Cheers Lonnie

1 0

Sculpt build process error
by Lonnie Cumberland 08 Apr '20

08 Apr '20

Hi All, While just getting started with Genode, I wanted to follow the Sculpt build process from the Sculpt-20-02.pdf in Section 5 as the objective is to create a sculpt iso. For that, I kept the "image/iso" in the "build/x86_64/etc/build.conf" to see if that would work. I am running everything in a freshly built Ubuntu 18.04 docker container with the Genode Toolchain installed. Everything was going well until I tried: make -C build/x86_64 run/sculpt KERNEL=nova BOARD=pc in which case it gives me an error: ---------------------------------------------- root@9b145a6d1be6:~/project/genode# ./tool/create_builddir x86_64 Successfully created build directory at /root/project/genode/build/x86_64. Please adjust /root/project/genode/build/x86_64/etc/build.conf according to your needs. root@9b145a6d1be6:~/project/genode# mc root@9b145a6d1be6:~/project/genode# ./tool/ports/prepare_port grub2 grub2 download https://github.com/alex-ab/g2fg.git grub2 git Cloning into 'boot'... grub2 update boot grub2 generate grub2.hash root@9b145a6d1be6:~/project/genode# make -C build/x86_64 run/sculpt KERNEL=nova BOARD=pc make: Entering directory '/root/project/genode/build/x86_64' /bin/bash: /root/project/genode/tool/run/run: /usr/bin/expect: bad interpreter: No such file or directory Makefile:323: recipe for target 'run/sculpt' failed make: *** [run/sculpt] Error 126 make: Leaving directory '/root/project/genode/build/x86_64' root@9b145a6d1be6:~/project/genode# ---------------------------------------------- Any ideas what I probably missed in my approach? Cheers, Lonnie

2 4

Genode and Virtualbox updates?
by Lonnie Cumberland 08 Apr '20

08 Apr '20

Greetings All, Hope that everyone is staying safe. Now that I have started to dig heavily back into NOVA from taking a hiatus from a number of projects, I also wanted to get ramped back up with digging into the latest Genode as well. In the past, my basic goals were to have NOVA (hypervisor) with a single instance Virtualbox (VMM), and Genode as the GUI and to provide the glue to bring it all together. Now I want to reinvestigate all of this to see what might be achievable, but looking at the Genode Sculpt OS, it kinda seems like a bit of overkill for what I wanted. In the past, NOVA (demo 0.3) had some night little features that just booted up extremely fast and allowed you to start up some simple VM's under the NUL framework using the Vancouver VMM. I thought that was very nice but also thought that if I could figure out how to get a Genode GUI on something like that and perhaps utilize the ported version of VirtualBox as a single instance VMM that was stable and fast then I could use that as my basis instead. Of course, I also investigated Muen and its possible inclusion in this scheme but now with some good input from Norman, I think that it is better not to have Muen included. So then, now I am wondering what the simplest setup would be to have just NOVA, VirtualBox and Genode (for the GUI and some drivers like audio, video, etc. for VBox) in an extremely small footprint. Also, I am wondering how much more advanced VirtualBox has become on Genode since when I last looked at it there was really no way that it could realistically be used for any type of real usage, but I am sure that has changed since then. Anyway, I would like to get any thoughts or suggestions that the wonderful people on the Genode mailing list might like to offer as I am still interested in building out this ultra-small hypervisor project. Cheers and stay safe, my friends. Lonnie

3 4

cached_fs_rom on base-linux
by Pirmin Duss 07 Apr '20

07 Apr '20

Hello Genodians I have a scenario on base-linux in which a `fs_rom` component serves multiple clients by providing the same file as ROM session. The file can be rather large. So I noticed that `fs_rom` loads the file into RAM for each session separately. This lead very fast to `resource requests`. I remembered that there is the `cached_fs_rom`, that is designed to handle exactly this scenario and reduce the amount of resources required. When I replaced `fs_rom` with `cached_fs_rom` in my scenario `cached_fs_rom` terminated with: ``` [init -> fs_rom] Error: Region_map_mmap::attach: attaching w/o local addr not supported [init -> fs_rom] Error: Uncaught exception of type 'Genode::Region_map::Region_conflict' [init -> fs_rom] Warning: abort called - thread: ep ``` After this I looked to see, if there is a test for `cached_fs_rom`. The only test except the usage by `sculpt_manager` was in the `test-read_only_rom` for `depot_autopilot`. When I ran this on different platforms, it succeeded on all including base-linux. Looking at the test I discovered that the success condition for the test is a that the timeout is triggered. On all other platforms `test-read_only_rom` crashes and on base-linux `cached_fs_rom` crashes. My question now is : - should cached_fs_rom theoretically work on base-linux, or is there an inherent restriction that prevents this? Best regards, Pirmin

2 1

Building 64 bits nova.
by Shlomo Pongratz 07 Apr '20

07 Apr '20

Hi, In the webpage https://genode.org/documentation/platforms/nova the instructions are as follows; ./tool/ports/prepare_port nova ./tool/ports/prepare_port x86emu <genode-dir>/tool/create_builddir nova_x86_32 BUILD_DIR=<build-dir> Now since both x86emu and Nova supports x86_64 I wonder is just replacing to nove_x86_64 will do the magic? Best regards, S.P.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users April 2020