Skip to content

Commit

Permalink
Merge pull request #424 from stlankes/nemo
Browse files Browse the repository at this point in the history
using Hermit OS instead of RustyHermit
  • Loading branch information
stlankes authored Feb 20, 2025
2 parents d6a634c + 57e077a commit c43fa2a
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 4 deletions.
2 changes: 1 addition & 1 deletion Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ keywords = ["oci", "container", "unikernel"]
categories = ["operating system", "container", "virtualization"]
readme = "README.md"
edition = "2018"
description = "runh is a CLI tool for spawning and running RustyHermit containers."
description = "runh is a CLI tool for spawning and running Hermit OS containers."

[dependencies]
capctl = "0.2"
Expand Down
4 changes: 2 additions & 2 deletions roadmap.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,12 +66,12 @@
RUN apt update
RUN apt install -y --no-install-recommends qemu-system-x86 qemu-system-x86-microvm
```
- For running images that do not contain the RustyHermit-Bootloader, the Hermit environment needs to contain the bootloader binary named `hermit-loader` in the same folder that the application binary will be mounted into. If the image contains the app at `/hermit/app`, the bootloader has to be in `<hermit-env>/hermit/hermit-loader`.
- For running images that do not contain the HermitOS-Bootloader, the Hermit environment needs to contain the bootloader binary named `hermit-loader` in the same folder that the application binary will be mounted into. If the image contains the app at `/hermit/app`, the bootloader has to be in `<hermit-env>/hermit/hermit-loader`.
Code: https://github.com/JTS22/runh/blob/5ea768750af4d0e53f4357ece26dd39e9866f3a0/src/init.rs#L651-L670
# Issues
- Networking
- works rather inconsistent (might be because of RustyHermit network code)
- works rather inconsistent (might be because of HermitOS network code)
- network namespace is not reset when restarting a Kubernetes Pod -> usage of dummy device in network.rs
- when a Hermit-Container runs in a pod, other containers in this pod likely can't access the network
- running two Hermit-Containers in one pod should not be possible
Expand Down
2 changes: 1 addition & 1 deletion src/create.rs
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@ pub fn create_container(
false
};
if is_hermit_container {
info!("Detected RustyHermit executable. Creating container in hermit mode!");
info!("Detected Hermit OS executable. Creating container in hermit mode!");
}

//Setup exec fifo
Expand Down

0 comments on commit c43fa2a

Please sign in to comment.