Hi Guido,
thanks for the very welcome feedback!
After that I had some less luck.
- Some downloads seem to hang. It could either be out of RAM (config),
or a lost packet that is not detected.
The RAM fs grows on demand up to 2 GiB. So I don't think there is a configuration issue as far as the regular pkg downloads are concerned. Intuitively, I'd investigate the networking stack, starting with the driver, and then the NIC router. Btw, when trying to run the 'download_debian' and 'vm' subsystems entirely in the RAM fs, we encountered a cap-resource starvation issue of the RAM fs, which got fixed at the staging branch. But this happened in the middle of the Debian installer.
To investigate the scenario once the downloading got stuck, you may manually tinker with the runtime configuration via the following command:
inspect:> cp /config/managed/runtime /config
Now the runtime is no longer managed by the sculpt manager but by *you* via editing the /config/runtime file. Now you can, for example, force a component to restart by adding a version attribute to its <start> node. E.g.,
<start name="update" version="2" ....>
This will restart the update subsystem (including the TCP/IP stack). At the same time, you can look at various reports, e.g., the /report/runtime/nic_router/state. You should also be able to tweak the verbosity of components like the NIC router on the fly.
I'm using the RAM-disk that gets to 64MB in size. (I remember, but could not reproduce) it going to 128MB
Yes, This works as intended.
- Expanding the GENODE-partition on the USB-stick makes it unbootable.
The system can't find and start Grub anymore. This happened repeatable both with a Kingston 8GB USB2 stick as well as with a Sandisk 32GB USB3 stick.
We discovered the very same issue recently. It should be fixed on our staging branch [1, 2] and the soon-to-be-released image version of Sculpt TC.
[1] https://github.com/genodelabs/genode/commit/479e051c336e3baaa0019ec0d3c4114d... [2] https://github.com/genodelabs/genode/commit/5d0a9c496f56ad143c08b2b2fc9200b8...
I haven't been able to test the virtual machine with debian payload due to the download errors.
Questions:
- is there a way to send the debug log via ethernet?
Right now, the simplest way would be copying the '/report/log' to a USB stick via the inspect window.
- did I miss some configuration settings that made the downloads get stuck?
I am not aware of any.
Norman