Building FlatImages from Source with different rootfs & other Questions

[Azathothas]

Creating a discussion instead, since I had too many questions and the Issues would have been spammed.

Hi, I have been reading the deploy.sh script, and after few hrs finally created my own homegrown script.
I had some questions, especially about the _create_elf function

1. My homegrown script kept failing and eventually it turns out I must only include that exact list of binaries:

for binary in bin/{bash,busybox,bwrap,ciopfs,dwarfs_aio,fim_portal,fim_portal_daemon,fim_bwrap_apparmor,janitor,lsof,overlayfs,proot}; do

Or maybe it could have been that I was also including the boot binary too.
Is that list really hardcoded...? Or was it the presence of the boot binary that caused the error: Invalid dwarfs system

2. I wanted to check out if musl was supported, I ran the steam.flatimage (runs perfectly on glibc distros) on alpine, but it didn't launch.
   Is that a known bug....?
   My logs are here: https://paste.ajam.dev/p/MYau2I

[ruanformigoni]

Hello!

1. My homegrown script kept failing and eventually it turns out I must only include that exact list of binaries:

You an increase/decrease the list of binaries, but they need to match the ones in here, in the same order, adjust accordingly:

flatimage/src/boot/boot.cpp

Lines 194 to 211 in 6bc6815

	auto start = std::chrono::high_resolution_clock::now();
	fs::path path_file_dwarfs_aio = path_dir_app_bin / "dwarfs_aio";
	std::ifstream file_binary{path_absolute, std::ios::in | std::ios::binary};
	ethrow_if(not file_binary.is_open(), "Could not open flatimage binary file");
	std::tie(offset_beg, offset_end) = f_write_from_header(path_dir_instance / "fim_boot" , 0);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "bash", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_busybox / "busybox", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "bwrap", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "ciopfs", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_file_dwarfs_aio, offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "fim_portal", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "fim_portal_daemon", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "fim_bwrap_apparmor", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "janitor", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "lsof", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "overlayfs", offset_end);
	std::tie(offset_beg, offset_end) = f_write_from_offset(file_binary, path_dir_app_bin / "proot", offset_end);
	file_binary.close();

---

I wanted to check out if musl was supported, I ran the steam.flatimage (runs perfectly on glibc distros) on alpine, but it didn't launch.
Is that a known bug....?

Steam and gameimage worked fine in MUSL from my testing in alpine. The main system being musl should not matter to the glibc container. It seems that something is wrong with the DISPLAY variables or permissions to the X server, can you try to use xhost + before executing flatimage to see if that fixes it?

[Azathothas]

I figured out what was happening.
I use rdp/vnc for my sessions and that's why it didn't work.
I tried without rdp, and it launches...

Apparently, conty uses xephyr or something to bypass it completely.

[ruanformigoni]

Ah, got it! Maybe it would be interesting to do something like that in here too.

[Azathothas]

Hello, again, over the last few days, I setup a repo to build flatimage baseimages with different rootfs/configurations to experiment with over at: https://github.com/Azathothas/flatimage-base

I am learning a lot but I find the documentation a bit...lacking
This is a good intro https://flatimage.github.io/docs/
But there should also be a more detailed version....

I went through your git history and located the old docs:
https://github.com/ruanformigoni/flatimage/blob/62b035968fc47afc0857e955c6b644a8a4c72c5f/README.md

I hope we can expect these to be added to the main docs..when you have time.
Thanks again for this awesome work, my friends and I have been testing a lot of portable formats and yours has impressed us the most.

[ruanformigoni]

Hello, again, over the last few days, I setup a repo to build flatimage baseimages with different rootfs/configurations to experiment with over at: https://github.com/Azathothas/flatimage-base

Really cool to see other distributions work with flatimage, I have limited to arch and alpine to have one gnu and one musl alternative and to ease effort to maintain more than two distributions.

I am learning a lot but I find the documentation a bit...lacking
This is a good intro https://flatimage.github.io/docs/
But there should also be a more detailed version....

Yes, I need to include more examples in the documentation.

Thanks again for this awesome work, my friends and I have been testing a lot of portable formats and yours has impressed us the most.

No problem, it is really nice to see that this effort was useful for someone else as well. Do you have a discord? I would prefer it since I do not use telegram often.

[Azathothas]

Yes, I repurposed your steam script to use cachyos, and I noticed speed gains in terms of startup and also smaller size of the final image.

If you could include an example to bundle something like distrobox on alpine:

• Would show me how to handle apps that need other apps, for example distrobox needs podman (rootless) to work

And another one, signal-desktop, on arch:

• Would show me how to handle electron apps.

We moved to matrix because file limit is there 100 MB and then we moved to telegram because file limit is 2GB
And for working on portable apps, this was really important since on average, the size usually exceeds 100MB easily...