Commit 8148e5b8 authored by Ondřej Míchal's avatar Ondřej Míchal
Browse files

Edited Note

parent 1e43aaa3
image: monachus/hugo
- hugo
- public
- master
[submodule "themes/hello-friend-ng"]
path = themes/hello-friend-ng
url =
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
baseURL = ""
title = "Harry's Bag End"
theme = "hello-friend-ng"
# Setup Disqus
disqusShortname = "harrymichal"
# Default language settings
DefaultContentLanguage = "en"
languageCode = "en-us"
# Syntax highlighting settings
PygmentsCodeFences = true
PygmentsStyle = "monokai"
buildDrafts = false
buildFuture = false
enableRobotsTXT = true
enableEmoji = true
disableRSS = false
disableSitemap = true
enableGitInfo = true
pluralizeListTitles = false
# Front-facing data (usually time/date, usually for posts)
date = ["date", "publishDate", "lastmod"]
lastmod = [":git", "lastmod", "date", "publishDate"]
publishDate = ["publishDate", "date"]
expiryDate = ["expiryDate"]
tag = "tags"
category = "categories"
posts = "/posts/:year/:title/"
name = "Ondřej Míchal"
email = ""
dateform = "Jan 2, 2006"
dateformShort = "Jan 2"
dateformNum = "02/01/2006"
dateformNumTime = "02/01/2006 15:04 -0700"
showReadingTime = true
# Set disableReadOtherPosts to true in order to hide the links to other posts.
disableReadOtherPosts = false
# Metadata mostly used in document's head
description = "Nice and comfy spot in the middle of the Shire"
keywords = "homepage, blog, linux, gnome, GNOME, Ondřej Míchal, Red Hat"
images = [""]
# Prefix of git-related links (resp. commits)
gitUrl = ""
# Directory name of your blog content (default is `content/posts`)
contentTypeName = "posts"
# Default theme "light" or "dark"
defaultTheme = "dark"
# Social icons
name = "email"
url = ""
name = "github"
url = ""
name = "gitlab"
url = ""
name = "twitter"
url = ""
name = "linkedin"
url = ""
# Language specific settings
title = "Harry's Bag End"
subtitle = "A silent comfy spot in the middle of the Shire"
homeSubtitle = "A comfy nerdy spot in the middle of the Shire"
copyright = "CC BY-SA"
readOtherPosts = "The pantry has some other good stuff"
logoText = "Harry's Bag End"
logoHomeLink = "/"
logoCursorDisabled = true
# Set menu entries
identifier = "blog"
name = "Pantry"
url = "/posts"
identifier = "about"
name = "Who's the hobbit"
url = "/about"
title = "Harryho Dno Pytle"
subtitle = "Tiché a útulné místo uprostřed Kraje"
homeSubtitle = "Tiché a útulné místo uprostřed Kraje"
copyright = "CC BY-SA"
readOtherPosts = "Ve spíži je toho ještě hromada"
logoText = "Harryho Dno Pytle"
logoHomeLink = "/cz/"
logoCursorDisabled = true
# Set menu entries
identifier = "blog"
name = "Blog-špajz"
url = "/posts"
identifier = "about"
name = "Něco o mě"
url = "/about"
title: "Nejsem hobit"
date: 24/02/2020
draft: false
Bohužel nejsem hobit, no. Ale minimálně jsem pohodlný jako oni. Jmenuji se
Ondřej Míchal a aktuálně studuji obor Informační Technologie na [FIT VUT](
Brno. V současné době pracuju jako stážista v [Red Hatu]( v Desktop týmu.
Takže pravidelně přicházím do styku s projekty jako [Fedora](
nebo [GNOME](
Takže asi je vidět, že jsem programátor, ale kromě toho jsem taky muzikant,
fanoušek mangy & anime a tak trochu gamer (hlavně RPGčka). Když poslouchám
muziku, tak je to něco z tohohle: jazz, rock, funk, house, lo-fi, klasika.
A taky mám rád Tolkiena. Fakt hodně :).
PS: Na internetu se objevuju buď jako "Marty" nebo "HarryMichal".
title: Well.. I'm not really a hobbit
draft: false
modified: 2021-05-30T20:47:06+02:00
Yeah, I'm not a hobbit.. but despite the fact I like my own comfort as hobbits do! My name is
Ondřej Míchal and I'm a computer science student at [FIT VUT Brno](
I work as an intern in the Desktop Team at [Red Hat]( where I mainly co-maintain [Toolbox](
I'm a supporter of open source software and in my spare time I contribute to projects like [Fedora]( or [GNOME](
I love J.R.R.Tolkien.
On the internet you may know me under nicks "Marty", "MartyHarry" or "HarryMichal".
title: "Ahoj Světe"
date: 2020-02-24T11:17:48+01:00
draft: false
Ahoj Světe! Tohle je můj první příspěvek na nové stránce.
## O čem to tady je
No... Tohle je můj domov. Tady si můžu v klidu a míru nacpat do dýmky Starého
Tobyho, dát si nohy na stůl a v konverzovat o bratranci z pátého kolene z
matčiny strany...
**Fajn, teď trochu vážně.**
Tohle má být něco jako moje portfolio a blog. Příspěvky budou asi převážně
technické. Něco o práci, něco o mých projektech a tak..
Uvidíme se U Zeleného draka :)!
title: "Hello World"
date: 2020-02-24T11:17:48+01:00
draft: false
Hello World! This is my first blog post on my new site.
## What's this place about
Well... this is my home. Here I can smoke Old Toby in my pipe, put my feet
on the table and chat my distant cousine from my mother side...
**Ok, now a bit more seriously.**
This is supposed to be my portfolio and a blog. The posts here will be
mostly technical related to my work or projects I'm currently working on.
See you at the Green Dragon's :)!
title: "Where's Toolbox? - 0.0.9x update"
date: 2020-07-03T14:41:12+02:00
tags: ["toolbox", "fedora", "silverblue", "OSS"]
draft: false
Shortly after the move of [Toolbox]( to the [containers]( organization on GitHub I started working on rewriting Toolbox from Shell to Go (one of goals of my Internship at the Desktop Team at Red Hat). To quickly sum up the reasons for the rewrite:
- Shell is Shell. It is good for small scripts and quick prototyping but that's it. There is no good way to parse JSON (and data overall), have better control over logging or handle errors. The list could go on.
- The "containers world" uses Go. If we want to get their help we need to come to them. Some examples are: [Podman](, [Docker](, [Skopeo](, [Buildah]( or [Kubernetes](
You may ask: "Why didn't you use Python? It's used a lot in Fedora". The answer is: "We can't really." We want Toolbox to be used in Fedora CoreOS which doesn't ship Python. More information about Fedora CoreOS not shipping Python can be found [here](
## What has changed?
In terms of functionality not much. Toolbox should behave more-or-less the same as it did before. Most changes are either purely visual, minor or under-the-hood.
**Support for Podman V2**
Developers of Podman never sleep and V2 is an evidence of the fact. Check out their [blog post]( about the V2 update.
Major updates of software quick often introduce different behaviour and also bugs. Podman V2 was no exception to this rule and some bugs had to be fixed on the part of Podman but in few cases Go version of Toolbox had to be adjusted to work with Podman V2.
> Shell Toolbox (<=v0.0.18) should be compatible with Podman V2 (but expect some changes in formats in some places; e.g., `toolbox list`).
**Deprecation of toolbox containers created with Toolbox 0.0.9 and older**
Toolbox containers created with v0.0.9 or older did not use command `toolbox init-container` as their entry-point.
**Deprecation of the reset command**
Toolbox 0.0.16 added a `reset` command for resetting Podman in case of fatal problems. Podman 1.7.0 added a `system reset` command, so Toolbox's `reset` should no longer be needed.
The command itself can still be used but you'll see a deprecation message.
**Specifying names of containers**
When using commands `enter` and `create` you most of the time need to specify which container you want to use. This has been done using the `--container | -c` option. This is not the way Podman behaves, though. With this update the option was made into an argument of these two commands.
The change does not apply to the `run` command as it's usage is a bit more sophisticated than the previous two.
Here are examples of how to use the commands now:
*Creating a named container*
[user@hostname]$ toolbox create my-container
Created container: my-container
Enter with: toolbox enter my-container
*Entering a named container*
[user@hostname]$ toolbox enter my-container
**Add handling of error when PWD does not exist in a container**
Toolbox used to fail silently if you tried to enter a toolbox with: `toolbox enter`. Thank you [
José Miguel Parrella]( for reporting and fixing the issue!
**Aborting container creation**
Shell Toolbox has a problem with interruption of commands that use "spinner" to indicate that work is being done. This was especially noticeable when creating containers (pulling of images). This issue should be gone now.
**Fix duplication of entries when listing toolbox containers**
Due to the way listing of containers in the Shell Toolbox was done there were sometimes cases where a containers with dots in their names (e.g., `my.container`) were showed multiple times. This should occur no more.
Starting now, Toolbox finally has a `--version` option that shows... the version number.
It may look like this:
[user@hostname]$ toolbox --version
toolbox version 0.0.91
Shell Toolbox used a simple `--verbose` option to toggle verbose logging and a `--very-verbose` toggle to also show the verbose log of Podman. These two options were replaced by two new options: `--log-level` that accepts a string specifying the level of logging ("trace", "debug", "info", "warn", "error", "fatal") and `--log-podman` that exposes logs of Podman on the level that is specified by `--log-level`.
The old options (`--verbose` and `--very-verbose` + their abbreviations `-v` and `-vv`) are kept for backwards compatibility but they are marked as deprecated and in the future they will be dropped completely.
## What's (maybe) coming next?
A large number of issues was reported over the past few months. Most of these issues were left unanswered. With Toolbox being rewritten it should be easier to solve those issues.
Toolbox container set the HOSTNAME variable to `toolbox` but there is no easy to tell what kind of toolbox it is. There are several proposed solutions for this problem. We just need to choose.
We use `flatpak-session-helper` for tracking key system files but it has one problem. It relies on session-bus which is only available with running session. This is a problem when Toolbox is ran with `sudo` or as root. This'll probably require us to write a monitoring tool that does the same as `flatpak-session-helper`but works even with root. *This is a blocker for Toolbox to work in Fedora CoreOS.*
Toolbox has no nice way of telling the user what exactly went wrong when a container couldn't be initialized (it just exits with `failed to start container xxx`). Watching the initialization, reporting back and even providing some help would be very helpful for both us and the users.
> The data need for this can be found in the output of `podman logs <name-of-container>`.
We currently only support our own images for creating containers. Long story short: It would be nice if Toolbox was capable of using even different images. I already saw several examples of how people are trying to solve this problem.
## Where can I get the update?
Check out the [release section]( of Toolbox's GitHub repo.
### Fedora
Toolbox v0.0.92 is already [available]( in Rawhide. If you already have Toolbox installed, just update. If you don't, install it with `dnf install toolbox`.
Toolbox v0.0.92 is also [available]( in *testing* repository of Fedora 32. We encourage you to help us test that release before we push it to stable (and then push it to Fedora 31). To report the issues either use Toolbox's [bug tracker]( or report it in the update ticket in Bodhi and give it negative karma.
### Arch Linux
Toolbox is [packaged]( by the community in Arch Linux and the rewritten version should already be available. Just type `pacman -S toolbox`
### Other distros
I'm not aware of any other distro having Toolbox packaged. If you're interested, we'd very much welcome the possibility of you packaging Toolbox for other distros.
For now you can build Toolbox from source (instructions for doing so can be found in a [PR]( with an update for the projects README).
## Summary
I want to thank all users of Toolbox for reporting bugs and trying to come up with solutions for them. I know this release took a long time but we tried to ensure the quality of the code was as high as possible and we'll continue with this still on our minds.
Also I thank [Debarshi Ray]( who's a great colleague and even greater friend who kept answering patiently all my questions, reviewing my patches and reworking my bad commits :P.
The full list of changes in 0.0.9x can be found in the [changelog]( in the project [repository](
When the 0.0.9x releases are considered stable enough, we'll probably mark a 0.1 release or maybe even 1.0. We'll see.
In case you experience a bug, report it in Toolbox's [bug tracker](
\ No newline at end of file
title: "A little collection of 'How to do X with Toolbox on Fedora Silverblue'"
date: 2020-05-02T10:14:12+02:00
tags: ["toolbox", "fedora", "silverblue", "OSS"]
draft: false
During the past few months I saw several questions (and sometimes even answers to them) about "How to do X with Toolbox?". Some of them have answers, some of them don't. Point is, that these questions have been asked in many places over the internet and it's very hard to look them up.
This article aims to aggregate some of those questions/answers (+ some of my own) and I'll use it as a base for updating the [documentation of Toolbox]( I'll keep updating this post with more QAs as time goes.
> If you have a question about "How to do X with Toolbox" and it's not covered in this post or on the wiki, let me know in the comment section.
With this I want to encourage you, if you have anything that might be worth sharing with the rest of the community, to contribute to the documentation. It's very easy!
To update the docs, you can just go to the page of the documentation you want to change/update. In the upper right corner is a link "Edit this Page" that leads to a GitHub [repository]( You can start making changes immediately in the text field that you'll get after clicking the link. When you are done, you simply give the update a name and in the description you can describe why the changes were made (if the change is simple/self explaining, then you don't have to write a description).
There's also a [documentation entry]( on how to start contributing to Fedora's documentation
> For those who're interested, the software powering Fedora's documentation is [Antora](
## How to stop a toolbox?
There is no urgent need for stopping toolboxes. Their memory overhead is very small (about 280Kib while not in interactive session). But if you want to stop them, just run:
// To stop a single toolbox
$ podman stop <name-of-the-toolbox>
// To stop all containers
$ podman stop -a
// To stop the latest container
$ podman stop -l
You can check, whether they're still running with `toolbox list` (their 'Status' should say "Exited (143) xxx ago" or with `podman ps` (if a container is running, it is on the list).
## How to run a program on the host from a toolbox?
**Inspired by:**
While inside of toolbox user can not by default execute programs available only on the host. Thankfully there is a very handy utility, made by folks working on [Flatpak](, called `flatpak-spawn` (link to repo [here](
Long-story-short.. `flatpak-spawn` uses [D-Bus]( under the hood to execute commands from a container (or a flatpak) on the host (requires the use of the `--host` option.
You can use `flatpak-spawn` in several different ways:
### Simply running flatpak-spawn`
If you have an urgent need to launch an executable on the host from a container, you can simply type:
$ flatpak-spawn --host vim
And the host's `vim` will appear in front of you (considering it *is* installed *heh*)
### Using an alias
Previous option is not very practical if you need to do the launching more than once. Solution for that is creating an alias.
It is your choice if you want it permanent or temporary. If just
temporary, simply type:
$ alias vim="flatpak-spawn --host vim"
If you want it to be permanent, add the same line to your .bashrc (or different configuration file if you don't use `bash`).
### Creating a shim binary
While making aliases is fine, having an actual file that you can point to and run is more practical (apps ran in a toolbox can use this).
> Toolbox itself currently does not offer an automatic way of creating shim binaries. The issues is being tracked here:
Until Toolbox introduces an official way of handling this situation, it is possible to create these shims manually.
This can be done by either creating a base script and create symbolic links pointing at it or just create scripts for every app you need. The approach with linking is easier to accomplish but the second approach gives you the option to add some special options for your wrappers.
Here's an example of how the base script can look (commission of [Dusty Mabe]( - source [here](
$ cat /usr/local/bin/host-runner
executable=$(basename $0)
set -x
exec flatpak-spawn --host $executable "$@"
The `host-runner` script is placed in `/usr/local/bin` so that it does not interfere with packages installed *in* a toolbox but also with packages installed/layered on the host (tldr; `/usr/local/bin` is exclusive for toolbox).
> You'll need to create the `host-runner` file as root (or with `sudo`).
Here's an example how you can create a link for `vim`:
$ sudo ln -s /usr/local/bin/host-runner /usr/local/bin/vim
> Creating the link also has to be run as root (or with `sudo`).
- cannot use `sudo`
- `+ exec flatpak-spawn --host vim` is printed in `stderr` after executing (resp. before executing the `flatpak-spawn` sequence)
If you have an idea how to update the script, share it, please!
## How to handle toolbox environment in .bashrc?
**Inspired by:**
On Fedora Silverblue it's quite common that you add an alias to your .bashrc (like `alias vim="flatpak run org.vim.Vim"`). This might cause problems if you install an app you aliased to your toolbox container.
The error could look like this:
/var/lib/flatpak/exports/bin/org.vim.Vim: line 2: /usr/bin/flatpak: No such file or directory
To prevent this from happening, you can make use of `/run/.containerenv` and `/run/.toolboxenv`. `.containerenv` is created by Podman/Docker and `.toolboxenv` is created by Toolbox in containers. So if `/run/.toolboxenv` exists, you are in a toolbox.
To make use of it you can update your `.bashrc` (or it's section) to look like this:
if ! [ -f /run/.containerenv ] || ! [ -f /run/.toolboxenv ]; then
# this IS NOT executed in any container
alias vim="flatpak run org.vim.Vim"
if [ -f /run/.containerenv ] && [ -f /run/.toolboxenv ]; then
# this IS executed ONLY in a toolbox
alias vim="flatpak-spawn --host vim"
## How to ssh into a toolbox from VS Code?
**Inspired by:**
Until VS Code lands [full support]( for [Podman]( alongside Docker ('[Remote - containers](' extension), ssh-ing into a toolbox is the closest to the final experience.
NOTE: Looks like support for Podman will come to VS Code [soon](!!
Here's an excellent [blog post]( written by [Juraj Fiala]( where he covers all the steps to setup a openssh server *in* a toolbox and connect to it from VSCode using the '[Remote - SSH]' extension.
## How to get toolbox's name from within a toolbox?
**Inspired by:**
There isn't currently a reliable to get toolbox's name from within it.
One thing you can do is run:
$ flatpak-spawn --host podman ps --format "{{ .Names }}"
which will show names of *all* currently running containers. But this has the problem with showing more than one container.
## How to increase allowed file system watchers in a toolbox?
**Inspired by:**
Increasing the number of allowed file system watchers has to be done on the host. Toolboxes will inherit this setting.
## How do I create a toolbox with its own home directory?
**Inspired by:**
There is currently no official way to create a toolbox with a different home folder than the current user's. But there are at least two temporary solutions that you can use (both were inspired by [yilkalargaw](
### Override `HOME` environmental variable
It is possible to create a toolbox with a different home folder by overriding the `HOME` variable. The catch is that it causes both Toolbox and Podman operate in that environment. That'll cause Podman to start downloading the required image again.
Also interacting with the toolbox requires you to override the `HOME` variable every time. So setting and alias is highly encouraged.
Workflow could look like this (considering `/home/user/Projects/example` is an existing directory):
$ HOME=/home/user/Projects/example toolbox create -y example
$ alias toolbox-example="HOME=/home/user/Projects/example"
$ toolbox-example toolbox enter example
[user@toolbox] $
### Use direnv
[direnv]( is a tool for loading/unloading environment variable depending on the directory you're in. This requires you to first install and setup `direnv` and then write a `.envrc` file that suits your needs.
## How to create a .desktop file for a program in a toolbox?
**Inspired by:**
Toolbox does not offer a way to create a .desktop file for an app in a toolbox.
The main difference between a "normal" .desktop file and a toolbox one is the `Exec` entry. To execute an app in toolbox you need to prepend `toolbox run <container> <executable>`.
Example (toolbox with the app is called 'desktop-apps'):
// Before
// After
Exec=toolbox run desktop-apps simple-scan
## How do I set a default shell in a toolbox?
**Inspired by:**
Toolbox mirrors the shell used in a toolbox with the one used on the host. So if you use `/bin/bash` then that's what willb be used in a toolbox. You can change this by overriding the `SHELL` environmental variable.
Example (open a toolbox with `/bin/sh` shell):
$ SHELL=/bin/sh toolbox enter
## How do I create a rootful toolbox?
**Inspired by:**