Installing Silverblue 40 and Bluefin-DX side by side as multiboot - discoveries

General
1

I have been exploring ways to integrate Distrobox containers with vscode for the past week.
There are some things that work and few others that are not fully reproducible.
That drastically depends on how you installed vscode: if as a layered package, or as a flatpak.

By default, Bluefin includes vscode as a layered-package but the methods available to integrate vscode with distroboxes and podman containers do not consistently work. This is ideally how a good integration should work:

  • DevContainers vscode extension is used to connect to distrobox or podman containers
  • DevContainers should be able to show the running containers, created by Distrobox or podman
  • After selecting a running container, vscode should install VS Code Server in the container
  • vscode subsequently connects to the container and logs in as the ${USER}, not root, at the container to pass the permissions to write and access the files on the project.
  • vscode once connected to the container offers you to install extensions on the container or on the host
  • the connection between the host and the container is persistent until the user disconnects. The experience pretty much similar to DevContainers and CodeSpaces.

One of the things I first did was to research all the methods available for integrating vscode with distrobox containers. The literature is limited and the solutions do not converge to one. Even the scripts provided by distrobox to integrate to vscode work only in flatpak-vscode but do not on layered-vscode. So far, I have not been able to make one work consistently. This is complicated by the fact, that if you make podman work, Docker will not be recognized by vscode anymore.

The next thing I tried was to rebase to Fedora Silverblue 40 and look closer where the underlying issue was. Unfortunately, rebasing to another OS is not fully isolated because of

  • (i) changes made to /etc;
  • (ii) modifications to the user configuration files;
  • (iii) kernel arguments are not isolated, they act on any rebased operating system, which forces you to install layered dependencies, such as GPU support packages;
  • (iv) the lack of isolation of a rebased OS makes difficult to form benchmarks between two operating system versions. In my case, Bluefin-DX 39 vs Fedora Silverblue 39. Meaning, you change a gear in OS #1, and it affects OS #2 that was just being rebased.

So far, that is the background of my exploration.

Which leaves you only with the alternative of installing the two operating systems, Silverblue and derivative Bluefin, as multiboot, side by side, in the same disk.

I have successfully installed both, side by side, taking care of installing the /boot/EFI in different partitions. For instance, the /boot/efi for Silverblue lives in partition 5, while the /boot/efi for Bluefin-DX lives in partition 14. This further improves the isolation between the OSes.

Finally, I understood why the guys at Fedora Silverblue do not recommend this type of installation in only one disk. It is because in the UEFI menu both operating systems will show up as Fedora. Not Silverblue or Bluefin; both are labeled as Fedora. The only thing differentiating them is the order at which they appear in the UEFI menu options. With two physical disks it would be clearer because UEFI shows the boot manager along with the brand and serial number of the disk. The order in UEFI is given by the partition number on which /boot/EFI is installed. In my case, again, Silverblue 40 will show first, and Bluefin last. Boot #2 is dedicated to Windows 11, boot #3 to Ubuntu 22.04. My UEFI has room for five boot managers.

So far the experiment is going well. I have practically reproduced Bluefin in Silverblue 40, and proceeding to test the integration of vscode with distrobox and podman containers. This time in totally isolated operating systems. It’s been a good exercise at reverse engineering Bluefin-DX. :cry:

1 Like
2

First Discovery

flatpak-vscode and Docker

Initial Conditions

  • Fresh Fedora Silverblue 40 with minimal layer-installed packages. Boots independently of Bluefin-DX on its own boot manager in UEFI; in other words, Silverblue-40 is not rebased but physically installed on a disk. Docker installed manually as a layered package. vscode installed as a flatpak application.
  • Fresh Bluefin-DX with default layer-installed packages. Boots with its independent boot manager. Docker found installed as a layered package. vscode installed as a layered package by default.
  • Both Silverblue-40 and Bluefin-DX do not enable or start the Docker service by default. Left to the user.
  • Both Silverblue-40 and Bluefin-DX do not add the current user to the docker group. Left to the user to do it manually, or via ujust command in Bluefin only.
  • In both cases, the extension Docker by Microsoft is added to vscode to test connectivity
  • flatpak-spawn is a flatpak package that could be required to insert in shell scripts to access Docker and Podman containers. These scripts replace direct calls to the docker and podman binaries. In both OSes, Silverblue-40 and Bluefin-DX, flatpak-spawn must be manually layered-installed.
  • Two user login profiles will be used for testing. One user to be tested after the first has been successfully passed the tests.

Conventions

  • layered-vscode: The Microsoft Code application is installed as a layered package.
  • flatpak-vscode: VS Code is installed as a flatpak application only; not overriding a layered vscode

Challenges

  • In a fresh Fedora Silverblue 40 installation, flatpak-vscode will not show any Docker containers. It will throw two errors: (i) Cannot connect to Docker daemon, Is Docker daemon running; and (ii) /var/run/docker:sock permission denied. Both can be fixed but it is harder than layered-vscode
  • In a fresh Bluefin-DX installation, vscode is layered as a package by default. There is one error “Is the docker daemon running”, which is fixed by enabling and starting the Docker service from the command line.
  • flatpak-vscode runs one instance at a time while layered-vscode runs many.

Objective

  • Come up with a reproducible procedure to make either, layered-vscode or flatpak-vscode, configured to recognize Docker from inside vscode to be able to create Docker containers, and DevContainers.

Findings

  1. flatpak-vscode is tricky to get it configured to run and connect to Docker container. Harder than layered-vscode.
  2. Eventually, after two fixes, flatpak-vscode will connect to Docker containers via the Microsoft Docker Extension, but still not able to execute Dockerfiles from the terminal. Work in progress.
  3. For repeatable results, exit and start vscode after any change in Settings.
  4. For repeatable results, reboot the OS after a change on flatpak settings, change in permissions, adding groups or users, or enabling and starting services
  5. vscode settings.json will only run valid commands only if supplied the absolute path. $USER, ${USER}, ~/ will not be valid

Results

  1. flatpak-vscode shows Docker containers via the MS Docker Extension. Three fixes needed. One script docker.sh required. Modification of settings.json to add the option "docker.dockerPath": "/home/username/.local/bin/docker.sh"
  2. flatpak-vscode able to execute Docker commands from the terminal. One fix needed. Required modification of the JSON settings user file to make bash or zsh the default terminals under terminal.integrated.defaultProfile.linux, and run host-spawn instead of bash under the terminal.integrated.profiles.linux.bash.path, or `terminal.integrated.profiles.linux.zsh.path.
  3. Integrated terminal in flatpak-vscode now is able to run Docker commands. Tested with two docker projects under two different user login profiles.

References

Second Discovery

flatpak-vscode + Docker + Podman

Still work in progress. Updates coming.

1 Like