vscodium in tinycore, from chroot to docker

[nick65go]

@vinnie: To run Tinycore in a chroot is a (relatively) tough nut to crack (even for you).
IMHO you may want to run TC in a chroot for IMPORTANT reasons, like:
1. You boot with a linux on 64 bits (kernel /drivers and programs on 64 bits) but you want also to run programs from TC_x86 (on 32 bits) -> so different arhitecture simultaneously.

2. You boot from a linux (Alpine?) on 64 bits (with programs linked against musl libc) and want also to run programs from TC_64 (on 64 bits, with programs linked against gnu libc)) -> so same arhitecture (64 bits) but diferent dependencies (lib*.so.*).

3. same as pct.2, but all on 32 bits, same different libc bases.

Time is money, learning is time consuming, you should start with / from end goal in mind (what you want to achive and at what optimum cost?). My recomandation for TIME limit restrictions: use qemu and run whatever TC (32 or 64 bits) inside a virtual machine. It is simpler and faster. Provides better isolation betwen the host linux and the guest linux.

If hardware resources are low, just use TC on 32 bits. If there are plenty of hardware resources, then just use TC on 64 bits. I did not see many programs existing in TC_32 but missing from TC_64, or viceversa.

About "i don't think I can avoid to install xorg on the chroot machine if I want to use graphic applications. Am I wrong?" --> Sorry, you are wrong! (Is anybody voting against me here?)
A X server (Xorg, Xvesa) will receive calls from all programs (even from arbitrary locations on the same machine, like from chroot folders). Do you remember that chroot is about just path/folders but for the same /dev (devices, keyboard, screen)?

To learn, forget (temporary) about lazy commnads like tce-load -i *.tcz. Get your hands dirty, and copy /past in proper locations a small graphical program and ALL its libraries. Why don't you try with a simple graphic program like "tc FLTK editor" in chroot to see that? see all "editor" depencecies (with ldd `which editor`) , put them in proper locations (/lib). Good luck.

[curaga]

Unpacking tczs or copying a live system both come with their own issues. There are no ready instructions for what you want to do, sorry.

[vinnie]

@nick65go

@vinnie: To run Tinycore in a chroot is a (relatively) tough nut to crack (even for you).

 

IMHO you may want to run TC in a chroot for IMPORTANT reasons, like:
...
2. You boot from a linux (Alpine?) on 64 bits (with programs linked against musl libc) and want also to run programs from TC_64 (on 64 bits, with programs linked against gnu libc)) -> so same arhitecture (64 bits) but diferent dependencies (lib*.so.*).
...

This second, precisely I want to start vs codium that works great on tinycore

Time is money, learning is time consuming, you should start with / from end goal in mind (what you want to achive and at what optimum cost?). My recomandation for TIME limit restrictions: use qemu and run whatever TC (32 or 64 bits) inside a virtual machine. It is simpler and faster. Provides better isolation betwen the host linux and the guest linux.

If hardware resources are low, just use TC on 32 bits. If there are plenty of hardware resources, then just use TC on 64 bits. I did not see many programs existing in TC_32 but missing from TC_64, or viceversa.

i don't like the qemu option, my pc's are always modest in hardware specs and in this case the increased isolation would not be very important

Sorry, you are wrong! (Is anybody voting against me here?)
A X server (Xorg, Xvesa) will receive calls from all programs (even from arbitrary locations on the same machine, like from chroot folders). Do you remember that chroot is about just path/folders but for the same /dev (devices, keyboard, screen)?

To learn, forget (temporary) about lazy commnads like tce-load -i *.tcz. Get your hands dirty, and copy /past in proper locations a small graphical program and ALL its libraries. Why don't you try with a simple graphic program like "tc FLTK editor" in chroot to see that? see all "editor" depencecies (with ldd `which editor`) , put them in proper locations (/lib). Good luck.

Actually this is good news, so I'm going to try it out even though I don't know if that would actually help me accomplish my goal.

[vinnie]

@curaga

Unpacking tczs or copying a live system both come with their own issues. There are no ready instructions for what you want to do, sorry.

I'm trying to collect the information I find related, although for me this amounts to groping in the dark:

• For copy the entire fs: http://forum.tinycorelinux.net/index.php/topic,13392.msg74199.html#msg74199
• Info about manual decompress tcz: http://forum.tinycorelinux.net/index.php/topic,17969.msg108765.html#msg108765
• someone who claims to have succeeded, unfortunately is a no longer active user: http://forum.tinycorelinux.net/index.php/topic,14649.msg83293.html#msg83293
• patched tce-load ?  https://github.com/tatsushid/docker-tinycore/blob/master/11.0/x86_64/src/tce-load.patch
• other infos that I don't know if they are useful http://forum.tinycorelinux.net/index.php?topic=15591.0  http://forum.tinycorelinux.net/index.php?topic=6246.0

What are your thoughts on trying this with docker? I would have preferred chroot because docker seems to me too much work, but at the end from what i know docker uses the host kernel as the chroot so if this github user was able to run tinycore on docker the workaround should be the same? what do you think curaga? this user has provided containers up to version 11, so in case i should see if with all the information he documented i can update it to 12.

[vinnie]

Only 20 hour ago someone updated docker to tinycore12, I will try also this way with my usual style

[curaga]

IMO docker is an additional complication, but you can try if it works for you.

[vinnie]

And that's exactly why I wanted to try to run the chroot, even though I had already run vscodium on a docker container (based on void), because I felt like I wasn't adding extra layers of boilerplate.
The problem is that if I don't know where I have to intervene to make tinycore work in chroot, the altenative was to see if someone had already succeeded on docker, since there is a hub specifically for images.
And actually...


(click to enlarge)

work!

This is the first test with tinycore, I used the program wily in the repository because it has few dependencies, it works without xorg installed on the container (as nick65go said being fully right).
Now i'll try to make a complete procedure, if everything goes well i'll post it here, if in the meantime someone can tell me what is to change to make chroot go would be helpful (because i don't see docker necessary in my case).
As I said in the docker I passed it seems that the only change is made on the tce-load, if docker is no different from a chroot, the same patch should work on chroot too, or not?

[grandma]

I have booted TC in WIndows using QEMU and
booted Windows in TC using QEMU.

In most cases if I recall things were easiest when I built a bootable ISO for QEMU to digest.

In all cases all video / graphics worked. In some cases if I got lucky I had network access.

In some cases I could even write to a folder and access - read - the data from the main host.

HOWEVER writing to the folder from the main host doesn't work because the emulated operating system has it's own fat tables and the host OS isn't updating that so you can corrupt the emulated session pretty quickly.

I also used QEMU to boot an emulated WINDOWS distro - something I forget - but it ran pretty well using TC as the host. I forget the brand/distro.

Its really all about getting the QEMU boot command just right - start simple and add devices as things work.

[vinnie]

@grandma
Thanks for the advice but really I don't wanto to emulate a machine, vscodium is already very slow on its own.
To getthe QEMU boot command, someone suggested me to try the virt-manager interface, I've never tried it but as soon as I'll need qemu I'll do it immediately.

for docker:
I managed to get vscodium running on docker with tinycore but there are two problems.
The first is that currently it works only with version 1.57.1, I tried with 1.58.0 and 1.58.1 but they do not start.
But on tinycore normally booted on my machine they start so there must be an extra dependencies request (I have to make a test in which I add dependencies a little at a time, I already did to find Xlibs dependency).
The second problem is the CMD instruction in the Dockerfile that doesn't start codium, but entering the shell of the container (as shown at the beginning of the Dockerfile with the run command example) and then starting "codium", it works.

In the use instead there are other problems, I didn't find a logical way to access from the container to the host so that the files are always mutually accessible at every startup (I didn't explore well, I think it's a matter of user and group).

if anyone has an idea...the finish line is really close

[vinnie]

https://stackoverflow.com/questions/68383822/docker-cant-run-vscodium

[vinnie]

https://github.com/microsoft/vscode/issues/128706 and https://github.com/docker/for-linux/issues/1268
, yes I repeated all the tests with vscode instead of vscodium to make the report eligible.
I was reporting it on vscodium's github but they were asking to check if there wasn't the same bug on vscode too, so they would almost certainly send me back to do this test and I anticipated.

Actually i feel defeated because i don't know anymore what other tests to do, i don't think i'll get any answer neither on stackoverflow nor on github.
My problem is a little bit related to tinycore, a little bit related to vscode and a little bit related to docker so I don't think that anyone will be able to help me to solve it not being able to take charge of the whole problem.

[nick65go]

@vinnie: you deviated (and complicated yourself) far too much versus the initial goal. I believe on this path nobody will help you further. you talk about alien words (for me) like vscode, vscodium, docker, void. In a forum with "expertise" on tiny core mostly.

The topic is now: run TC (64 bits) in chroot of a linux distro, like Alpine (64 bits).
You can NOT run TC (64 bits) on Alpine (on 32 bits), even if you have a 64 bits CPU.
TC is basically = kernel + core (root.gz + modules.gz) + *.tcz
Chroot is basically just a starting folder into which you extract the root64.gz You do not need the kernel, neither its modules.gz
So now you have an ash shell. And now you just need the Applications.(like dillo.tcz).

Your problem (and mine in the beginning) is that simple commands like "tce-load -iw dillo.tcz" will not work!
Because tce-load is just a script ( few simple commands, plus calling other scripts, and those scripts calling other scripts etc). And all these little auxiliary scripts (subroutines) are spread allover in chroot.

The main problem here is they/scripts assumed few TC specific rules: you are not user root, and you have few variable already defined, and you have some symbolic-links already defined. (curaga ponted you to one of them, like /etc/sysconfig/tce). But what the hell you basically accomplish in the end with tce-load script? it is just downloading a *.tcz file + its dependencies from a sever, then extract its content in few PRE-DEFINED folders like /usr/local/{bin, lib).

So you hacked/ understand and modified few scripts (not only one!) in TC, just to run some programs that TC provides?Because you did not find THAT program (ex: dillo) in the main (Alpine?) distribution?And you almost DOUBLED all the libraries in memory?? because in main Apline (musl libc) you need to load them (ex:libcrypt.so.1 compiled against muls libc) to run Apline, but then you load again similar library (ex: libcrypt.so.2 compiled against gnu libc) asked for by your program (dillo?).These are fake example, but you understand the drill, do you?

Summary:With limited resources you are advised AGAINST using CHROOT for big/demanding programs: Firefox, LibreOffice.  You can play in your dust/sand box (chroot) with puppies only.
Have a nice day.

[vinnie]

@vinnie: you deviated (and complicated yourself) far too much versus the initial goal. I believe on this path nobody will help you further. you talk about alien words (for me) like vscode, vscodium, docker, void. In a forum with "expertise" on tiny core mostly.

This is true but I went from wanting to chroot (which partially worked) to trying docker (which is still sort of a chroot after all) because I couldn't continue on the same path (due to the specifics of tinycore).

The topic is now: run TC (64 bits) in chroot of a linux distro, like Alpine (64 bits).
You can NOT run TC (64 bits) on Alpine (on 32 bits), even if you have a 64 bits CPU.

ok but i am trying to use both alpine and tinycore in 64bit

...
The main problem here is they/scripts assumed few TC specific rules: you are not user root, and you have few variable already defined, and you have some symbolic-links already defined. (curaga ponted you to one of them, like /etc/sysconfig/tce). But what the hell you basically accomplish in the end with tce-load script? it is just downloading a *.tcz file + its dependencies from a sever, then extract its content in few PRE-DEFINED folders like /usr/local/{bin, lib).

it's exact, but in fact one of my hypothesis had been to unzip the packages by hand, but I was told to me that it wouldn't work

So you hacked/ understand and modified few scripts (not only one!) in TC, just to run some programs that TC provides?Because you did not find THAT program (ex: dillo) in the main (Alpine?) distribution?And you almost DOUBLED all the libraries in memory?? because in main Apline (musl libc) you need to load them (ex:libcrypt.so.1 compiled against muls libc) to run Apline, but then you load again similar library (ex: libcrypt.so.2 compiled against gnu libc) asked for by your program (dillo?).These are fake example, but you understand the drill, do you?

Unfortunately I have not found a way to start the program I need in Alpine.
On alpine vscodium worked with archlinux chroot, flatpack (but with some features I didn't like), a version od docker with void and stop...
Appimage doesn't work, i tried with alpine's gcompat libraries but nothing, i tried with sgerrand's glibc on github but nothing, i tried codeserver installing it in different ways but there were some problems...
In the end I thought to chroot tinycore since it was a distro that I already knew a little bit (and actually it has been recommended to me even if who did it didn't know that I already was a tinycore user), and then since there were some problems I fell back on docker that now works but I have to fix some things.
I can understand that from your point of view I have not been focused only on one thing but it is also true that I tried all in search of a solution and that I was forced to change when when I got stuck with a specific solution attempt.

Summary:With limited resources you are advised AGAINST using CHROOT for big/demanding programs: Firefox, LibreOffice.  You can play in your dust/sand box (chroot) with puppies only.
Have a nice day.

I don't agree with this, I don't think there is a more efficient method than chroot outside of running the program on the same host pc os.
It's true, there is the overhead of some libraries started in a duplicate way, but don't forget that shared libraries are also an advantage used mainly in the linux world but the other operating systems (windows, mac) have always done the opposite.
Yes my pc is not very powerful, anyway it can start firefox and vscodium on docker without too many problems.
Good night

[vinnie]

Ok, I finished the docker image, all working:
1 starts itself without having to enter the interactive shell
2 it also starts later versions of vscodium
3 tinycore inside seems to work (you must remember to use -wic when you install things because the tce-load has been modded)
4 you can connect the home in the container with a dir in the host system to keep the settings of the editor and any files (you can also commit as an alternative and keep everything inside the container)

Moral of the story:
saving the image with "docker save" you get a tar of 426mb, the unzipped vscodium directory alone occupies 285, it remains that tinycore alone with all requested dependency occupies 141mb (including python3.8 and tk8.6). And you know what the surprise is? If you compress the tar in tar.gz it becomes an archive of 150mb in total

I attach the docker file including some quick explanations. In the future it is possible that I decide to make things even better documented.

@admins: if you want to change the topic title to "vscodium in tinycore, from chroot to docker" maybe the whole discussion could seem more coherent.

[Rich]

Hi vinnie

... change the topic title to "vscodium in tinycore, from chroot to docker" ...

Done.