users

users@lists.genode.org

2285 discussions

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

Build in Ubuntu container.
by Shlomo Pongratz 06 Apr '20

06 Apr '20

Hi, Since I've failed building on FC31 I've set a Ubuntu 18.04 container and tried to build there. It seems that I need to configure the terminal since after the error message it just stuck, see below. Did anyone tried to build inside a container but run outside of it? Best regards, S.P. root@359c5dcd6675:/genode/build/x86_64# make KERNEL=linux BOARD=linux run/demo including /genode/tool/run/power_on/linux including /genode/tool/run/log/linux including /genode/tool/run/boot_dir/linux including /genode/repos/os/run/demo.run building targets: app/status_bar test/nitpicker spawn make app/status_bar test/nitpicker make[1]: Entering directory '/genode/build/x86_64' checking library dependencies... Library ldso-startup Library ld Library base Program app/status_bar/status_bar Program test/nitpicker/testnit make[1]: Leaving directory '/genode/build/x86_64' genode build completed checking configuration syntax CHECK init spawn ./core Genode sculpt-20.02-70-g46fa8197a 17592186044415 MiB RAM and 8997 caps assigned to init [init] Warning: scout assigned caps (10000) exceed available caps (6628) Error opening terminal: unknown. Warning: blocking canceled in entrypoint constructor [init -> drivers] child "fb_sdl" exited with exit value 0

1 0

Error while building.
by Shlomo Pongratz 06 Apr '20

06 Apr '20

Hi, According to the an earlier error message from: make KERNEL=linux BOARD=linux run/demo I ran the following command (with all verbose on): /home/shlomo/development/all_git/genode.git/genode/tool/depot/create VERBOSE= VERBOSE_D IR= VERBOSE_MK= genodelabs/pkg/x86_64/drivers_interactive-linux genodelabs/bin/x86_64/base-linux genodelabs/bin/x86_64 /demo genodelabs/bin/x86_64/global_keys_handler genodelabs/bin/x86_64/init genodelabs/bin/x86_64/nit_focus genodelabs/ bin/x86_64/nitpicker genodelabs/bin/x86_64/report_rom genodelabs/bin/x86_64/rom_filter CROSS_DEV_PREFIX=/usr/local/gen ode/tool/19.05/bin/genode-x86- And I got this error message: /usr/local/genode/tool/19.05/bin/genode-x86-strip -o fb_sdl.stripped fb_sdl /usr/local/genode/tool/19.05/bin/genode-x86-strip:fb_sdl[.gnu.build.attributes]: bad GNU build attribute notes: first note not version note: bad value I'm building of FC31. Any Idea?

2 2

Interesting idea to ask
by Lonnie Cumberland 02 Apr '20

02 Apr '20

Hi All, Hope that everyone is well and safe from the COVID-19 virus these days. I have been watching Genode, Muen, and especially NOVA for a number of years and I have an idea that I would like to get your opinion/comments on regarding its potential as well as if it has a beneficial point to it. I would like to take and build up a system based on the MuenSK with NOVA, and Bhyve while also possibly adding the Sculpt OS GUI into the mix for a nice basis for a hypervisor. I was thinking that the layers could be (bottom to top) 1. MuenSK ---- Provides Separation Kernel for real hardware configuration 2. NOVA Hypervisor ---- Provides virtualization of the real hardware provided by the SK 3. Bhyve --- Provides the VMM for each instance given by NOVA Of course, there are other things to be included but this is just the base that I am working towards. Do you see an advantage to something like this? About the only close Virtualizing Separation Kernel that I have come across is the LynxSecure Separation Kernel Hypervisor ( https://www.lynx.com/products/lynxsecure-separation-kernel-hypervisor) but I would like to build an open sourced version. Any thoughts, suggestions, or comments? Cheers, Lonnie

2 2

Hack'n'Hike 2020 cancelled!
by Martin Stein 02 Apr '20

02 Apr '20

Hi Genodians, I hope you are doing all well? Due to the current situation with COVID-19 in Germany and other countries around the world, we have decided to __cancel the Hack'n'Hike 2020__. It is quite unlikely that things will get back to normal until 8th of May and we'd like to prevent uncertainty about the event. Please also note that we're __not__ planning to provide an alternative date this year, so, next Hack'n'Hike will probably be held in April/May 2021. Best regards and stay healthy! Martin

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users