Tiny Core Linux
Tiny Core Extensions => TCE Talk => Extension requests => Topic started by: flavien on January 14, 2019, 07:57:54 AM
-
Hello!
It would be great to get TCZs (for TC9 x86) :
*(should contains kernel files)
Maybe help for Guix : https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation (https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation)
I'm a new TC user (just since some days ago), so i'm not sure to produce good TCZ files now.
Sorry for my poor english speaking.
-
Oops. "One thread for extension".
Sorry!
This thread is for guix ;)
-
Isn't guix an os/package management system?
-
Yes, but in user space.
It does not depend of any distribution.
It's like snapd, but as a real package manager, with shared libraries (but multi versions)
Theorically, i can, for example, get full kodi-18-rc with all dependencies installed in the persistant context in 1 or 2 lines in terminal. 8)
-
I will try to make it this month if nobody do it before, because it could be easy with available binaries releases
-
Yes, but in user space.
As is APPS
Theorically, i can, for example, get full kodi-18-rc with all dependencies installed in the persistent context in 1 or 2 lines in terminal. 8)
Like APPS
Seems as if you haven't discovered APPS yet?
-
Never heard about, but not sure it's the same.
Is this "OpenCollaborationServices" ?
If no, what's the difference?
If yes, APPS/OCS seems to be an abstract package management layer, but not a package manager.
It does't install anything, but command the distribution to do it. Right?
Guix is a real package manager, but to install packages and dependencies in user space without writing files out of /home...
-
Flavien, APPS is the Official GUI version of TinyCore extension management, find it on the wbar
From the command-line
tce-ab
tce-load
tce-audit
-
Flavien, I think you'd be smart to read the Core Book. http://tinycorelinux.net/book.html
-
I just forgot the TCE GUI name, as it's just a TCE frontend.
But sure I understand the TCE advantages, that's why i begin to use Tiny Core...
So APPS, alias TCE, can but does not install programs in user space (i mean like '/home'), but in rootfs (usualy in "/" root ramfs). But yes persistence allows keeping programs in user space (by squashfs or backup). Of course.
Guix is "same", but different.
To run GUIX on any distribution, you just have to install the daemon and run it.
I think TCE is perfect to deploy light packages and can offer various elegants "over mounts" strategies.
But for an as big as kodi program, it could be very hard to maintain (various architectures, run dependencies, build dependencies, compilation...)
GUIX packages theorically offer an absolute portability on any distributions.
So imagine you get your light tiny core environemment (like a swiss knife), and over it, you can deploy up to date big packages by using GUIX, then you don't have to maintain millions of TCE packages, as it's for light usage.
Last point:
You decide to update the GUIX part only? It will not affect tiny core.
You decide to update the tiny core part only? It will not affect GUIX installation.
You have two versions of tiny core using a same real home path?
Your GUIX programs could be available on each!
-
I just forgot the TCE GUI name, as it's just a TCE frontend.
But sure I understand the TCE advantages,
No sorry but at present I don’t think you do..
I think TCE is perfect to deploy light packages and can offer various elegants "over mounts" strategies.
But for an as big as kodi program, it could be very hard to maintain (various architectures, run dependencies, build dependencies, compilation...)
Maybe you missed that KODI is already in the repo.. it’s not that large.
GUIX packages theorically offer an absolute portability on any distributions.
So imagine you get your light tiny core environemment (like a swiss knife), and over it, you can deploy up to date big packages by using GUIX, then you don't have to maintain millions of TCE packages, as it's for light usage.
Last point:
You decide to update the GUIX part only? It will not affect tiny core.
You decide to update the tiny core part only? It will not affect GUIX installation.
You have two versions of tiny core using a same real home path?
Your GUIX programs could be available on each!
I hear what you’re selling, but I’m not buying it.. If the book didn’t make it clear I recommend you study the Core Concepts
http://tinycorelinux.net/concepts.html
Then imagine the Tinycore way [emoji2]
Sent from my iPhone using Tapatalk
-
Quote from: flavien on Today at 12:10:42 PM :
... But for an as big as kodi program, it could be very hard to maintain (various architectures, run dependencies, build dependencies, compilation...)
I have not used kodi in TC before and dont know exact defination of *big programs* .
.. But prvs TCE packages like JDK , Xine, Apache, Oracle, MySQL , GIMP, LibreOffice , GNOME , Opera, etc may not be big enough as per recent *big* or *heavy-weight* defination ! :)
-
So, I have a 3D game which is around 10GiB in size which I think qualifies a large. I believe this game is far too large for a Home directory which requires routine backups, is currently stored on a separate partition and communicates with 3D kernel mode drivers when run.
Additionally I run a 3D test program which is approximately 300MiB in size and it has no difficulty being installed from a tc extension archive.
I just can't see how either program would benefit from being adapted to to run from Guix..
-
I will try to make it this month if nobody do it before, because it could be easy with available binaries releases
i did try running the install for the binaries release , and i think it was working after some modification to the script ( wrt user creation ..the program names differ in TC afair , and installing some dependent programs )
i might have the notes some place , and nix and guix are on my ever-growing to do list
tc methods has some advantages over them ( at least nix i have not much used guix), to note a few 0)simplicity ,1) tcz.list of package file's aka provides.db
but also to be fair nix/guix are not "just" a package manager but also a build system ...
( shout out to The ubiquitous lemur of doom! Muhahaha!!! and associated from SCRATCH topic )
.. a build system ... much like some others that can be found in the "Programming & Scripting - Unofficial" section
eg : tc-ext-tools buildscripts , tce-make , and friends
the one advantage imho that nix/guix bring is larger / growing community creating / updating the packages
...also in theory it should be possible to create a tcz package using nix/guix
-
When I say big, i mean big/hard/or long to build and maintain. (Sorry for my poor english.)
@mocore : :D I totaly agree!
..the program names differ in TC afair , and installing some dependent programs
I'm not 100% sure, but theorically guix does not care about.
All is in /gnu/store + /usr/guix + /home/$USER and/or /root folders.
So you should (in theory) never get a clonflict!
When you build for NIX/GUIX, you potentialy build for all linux distributions (+ maybe for the non linux gnu hurd os).
...also in theory it should be possible to create a tcz package using nix/guix
Excelent !
Taking advantage of building guix system, then create tcz packages!
In GUIX isolation terms : /gnu/store and a lot of symlinks, not classic simple linux organisation, of course.
But why not?! ;D
And even if you don't use GUIX to make TCZ, when a package is not now available in TCZ repo (like kodi 18-rc vs kodi 17), you can install and test the RC version from GUIX and wait for stable kodi 18 before trying to eventually get it in a beautiful TCZ light package! (less frequency work needed in making releases for TC contributors to get a full usable and flexible OS!) Isn't great ?!
After dCore, Guix Core ? :P
-
..the program names differ in TC afair , and installing some dependent programs
I'm not 100% sure, but theorically guix does not care about.
this was to run the : https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh on just core.gz + whatever needed depeds for the script !
eg (afaik) groupadd and useradd , in the tc domain have difrent name / and perhaps args .. so those parts of guix-install.sh needed some modification to get the install to finish!
i think i got the install working , before the holidays
---
after the install is done , some method is needed to restore the created folders in the case of guix : /gnu/store and /var/guix
i have modified parts of the nix install ,
and used this on other 'live' non-persistent systems with some success ,
creating a bind mount from /some/other/place to /nix ,
then ruining the mock_install to add some links / files back into user home
-
After dCore, Guix Core ? :P
In a moment of madness i started thinking about (nomad) BSDcore ;)
-
After dCore, Guix Core ? :P
In a moment of madness i started thinking about (nomad) BSDcore ;)
Lol! Why not... Or this :
GNU
HURD Core
Rock'n ROLling Release
8) 8) 8)
I got it run, but i'm face to a big problem. I can't install the first package.
First, instructions to make it "running"
I - MAKE GUIX "RUNNIG"
In a real file system (like /dev/sda mounted on /mnt/sda), extract the GUIX binary tar.
You got /mnt/sda1/gnu and /mnt/sda1/var/guix.
sudo mount /mnt/sda1/gnu /gnu
sudo mount /mnt/sda1/var/guix /var/guix
Then, with attached guix.tcz (just a few folders with some symlinks and a tce.installed script) , run :
tce-load -i guix.tcz
For information, my install script contains :
GUIX_PROFILE="`echo ~root`/.config/guix/current" ;
source $GUIX_PROFILE/etc/profile
addgroup guixbuild
chgrp guixbuild -R /gnu/store
chmod 1775 /gnu/store
builders=10 ;\
for i in `seq 1 $builders` ; do \
adduser -S guixbuild$i guixbuild ;\
adduser guixbuild$i guixbuild ;\
done
~root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild &
guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.info.pub
cd /usr/local/share/info
for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
do ln -s $i ; done
This is okay.........BUT :
II - THE PROBLEM :
When i try "guix package -i hello", i got this error :
guix package: error: build failed: while setting up the build environment: cannot pivot old root directory
Guix use pivot_root, while TC mount rootfs on ram by the "/init" script.
pivot_root needs rootfs to be mounted on a real file system.
BUT, by "chance", TC does not use initramfs, but inird (core.gz), witch IS a real FS.
Next, the /init script mount the RAM content as "/".
Theorically, if the init script
1 ) mount "/" on a real FS
2 ) mount RAM content in a real FS subfolder "/ram0" (for exemple)
3 ) Then first pivot_root to "/ram0"
This could work without breaking the bootstrap rcS. I hope :'(
And make pivot_root available on TC...
If it's possible, it should be integrated optionnally as a custom boot code like this :
realrootfs="/dev/sda1".
If core developpers doesn't want to integrate this, that means Guix Core is finished, or need to fork TC :-\ :'( :'( :'(
But before requests them for adding this great feature ("pivot_root compatibility"), we need to try by ourself, because we must overcome possible future problems.
(After all, maybe it will never work. Maybe.... Noooooo! It will!)
[EDIT] Removed attached extension due to forum policy violation. Rich
-
This could be helpful :
https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html (https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html)
-
Forget my previous post.
Related post : http://forum.tinycorelinux.net/index.php?topic=21089.0 (http://forum.tinycorelinux.net/index.php?topic=21089.0)
Same problem for docker. (but docker provide an environment variable to resolve it)
andyj said :
Part of your problem may be related to what I alluded to in another thread. In a fat distro like Ubuntu, the initial ram disk is compiled into the kernel, then another file system on the hard drive is "pivoted" to so as to become the new root file system. In TCL, the ram disk is loaded as an initrd (initial ram disk), then continues to be the root file system after the boot process is complete. No other file system is pivoted to. If you want to use TCL as your docker OS then you will need to build another file system image to load after the stock core.gz (or modify the supplied core.gz) instead of trying to pivot to another FS. As you say, it works when you don't pivot, which makes sense. Pivoting is for the classic install where all the OS files are on a hard drive.
Is there a pivot_root & ramdisk compatibility trick?
Explanation : https://unix.stackexchange.com/questions/126217/when-would-you-use-pivot-root-over-switch-root (https://unix.stackexchange.com/questions/126217/when-would-you-use-pivot-root-over-switch-root)
It's not exactly the same situation because TCL doesn't use initramfs, but initrd.
https://stackoverflow.com/questions/10603104/the-difference-between-initrd-and-initramfs (https://stackoverflow.com/questions/10603104/the-difference-between-initrd-and-initramfs)
Theorically, there is no problem to use pivot_root because initrd is ramdisk and ramdisk is a file system while initramfs is not. But "/" is mounted as tmpfs, witch is not like ramdisk, a "real" mounted FS, and i think that's the problem.
If there is a way to mount exactly the same, but copying it in the ramdisk initial "real" file system, then we were probably able to use pivot_root instead of switch_root.
We can just draw inspiration from https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html (https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html)
Here, see the /init file content from core.gz ramdisk (https://github.com/tinycorelinux/Core-scripts/blob/master/init (https://github.com/tinycorelinux/Core-scripts/blob/master/init))
#!/bin/sh
mount proc
grep -qw multivt /proc/cmdline && sed -i s/^#tty/tty/ /etc/inittab
if ! grep -qw noembed /proc/cmdline; then
inodes=`grep MemFree /proc/meminfo | awk '{print $2/3}' | cut -d. -f1`
mount / -o remount,size=90%,nr_inodes=$inodes
umount proc
exec /sbin/init
fi
umount proc
if mount -t tmpfs -o size=90% tmpfs /mnt; then
if tar -C / --exclude=mnt -cf - . | tar -C /mnt/ -xf - ; then
mkdir /mnt/mnt
exec /sbin/switch_root mnt /sbin/init
fi
fi
exec /sbin/init
Not sure about how to do the trick without break the bootstrap, and I don't know if there is a performance or a ram space cost.
In the upper slax post link, we can read :
we make a directory /m (or something) and copy the current initramfs filesystem to it. This doubles RAM usage for a while, but don't worry, since the next step we do is to switch root to /m. This does two things. First, it frees all the memory used by initramfs, and second it simply restarts the init process from a mounted filesystem. And as soon as root is mounted, the real startup procedures of LiveKit can be started (mounting union, and so on), and finally pivot_root is now magically available again. Voila!
I don't understand this /init line :
if tar -C / --exclude=mnt -cf - . | tar -C /mnt/ -xf - ; thenIt's probably about core.gz extraction, but we desn't see any file name... :o
Someone?
-
I'm wrong.
https://www.jamescoyle.net/knowledge/951-the-difference-between-a-tmpfs-and-ramfs-ram-disk (https://www.jamescoyle.net/knowledge/951-the-difference-between-a-tmpfs-and-ramfs-ram-disk)
I don't understand why pivot_root doesn't work. Sorry.
-
i made a topic hear http://forum.tinycorelinux.net/index.php/topic,22449.0.html
wrt the tc int root question!
wrt to guix
the mail list has some hints to get to the "root" ;) of the problem with gix
https://lists.gnu.org/archive/html/help-guix/2018-03/msg00104.html
It would be nice to know the error code returned by the pivot_root syscall.
It might point to the reason of the failure.
Most probably you can get that using strace.
Stracing the daemon is possible using strace -fp pid_of_daemon.
-
Thank you mocore :)
I've already tried get output error by strace after installing "util-linux.tcz", but today i don't know yet how it works. ;)
-
It works!!!!! ;D ;D ;D ;D
if ! grep -qw noembed /proc/cmdline; then
means if boot code noembed isn't present then...
But if we have this boot code then :
umount proc <--- already mounted to detect bootcodes
if mount -t tmpfs -o size=90% tmpfs /mnt; then
if tar -C / --exclude=mnt -cf - . | tar -C /mnt/ -xf - ; then
mkdir /mnt/mnt
exec /sbin/switch_root mnt /sbin/init
fi
fi
exec /sbin/init
We got exactly what https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html (https://www.slax.org/blog/18438-initramfs-pivot-root-solution.html) is talking about!
And, from Into the Core book, we can read :
10.32. noembed - use a separate tmpfs
This is an advanced option that changes where in RAM Core is run
from. By default, Core uses the tmpfs setup by the kernel; with this
bootcode, Core will setup a new tmpfs file system, and use that
instead.
Using this bootcode temporarily doubles the RAM use, as both
copies are kept in RAM at once during boot. As an extra copy is
made, it also slows the boot time. It allows GNU df to detect the
free space in /, used by some proprietary software installers.
I deduce that pivot_root just need noembed bootcode!
Then i'have added it, and i test :
guix package -i hello
SUCCESS!!!!! (hello is only installed in the GUIX user part^^)
What we need to test :
- Install some graphicals applications with GUIX and see if it works
- Try to generate conflicts with TC, witch is theorically impossible! (but I'm not a GUIX expert)
YEAH!!! 8)
Welcome to tcGUIX distribution^^
-
After export PATH environement variable to point to the /home/tc/.guix-profile/bin and sbin folder, and run startx, it works. ::)
guix package -i gedit
gedit
For archlinux users, we got a yaourt-like system, but isolated in user space : it's GUIX.
For gentoo user, we got a emerge-like system, but isolated in user space : it's GUIX.
(a full building system on TCL, without conflict)
mocore said :
...also in theory it should be possible to create a tcz package using nix/guix
(sounds like an historical sentence! ;D lol )
If someone (a GUIX advanced user for exemple) know how to transform some guix building result packages to a classic POSIX files hierarchy, to separate building dependencies and runnig dependencies, then we have a nice TCZ building system.
Else, by keeping /gnu + /var/guix + $HOME/.guix-profile hierarchy way, we have a nice "GCZ" building system. (for exemple, we can store these "GCZ" files in a "$TCEDIR/optionnal/guix" sub directory)
But i don't know how! lol^^
-
Another essential thing:
https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/ (https://www.gnu.org/software/guix/blog/2017/creating-bundles-with-guix-pack/)
Recipients of a binary tarball are expected to either extract it in their root file system (yes!) where it will create /gnu and /opt/gnu in this case:
# cd /
# tar xf /path/to/pack.tar.gz
# /opt/gnu/bin/guile --version
guile (GNU Guile) 2.2.0
… or they can chroot into it, possibly relying on user namespaces and thereby avoiding root privileges:
$ mkdir /tmp/pack
$ cd /tmp/pack
$ tar xf /path/to/pack.tar.gz
$ unshare -mrf chroot . /opt/gnu/bin/guile --version
guile (GNU Guile) 2.2.0
The good thing with this is that, because Guix captures the complete dependency graph of packages, the tarball contains everything that’s needed to run Guile and is going to work in exactly the same way on any system that runs the kernel Linux!
(without guix)
-
https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pack.html (https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pack.html)
Yet another option is to produce a SquashFS image with the following command:
guix pack -f squashfs guile emacs geiser
The result is a SquashFS file system image that can either be mounted or directly be used as a file system container image with the Singularity container execution environment, using commands like singularity shell or singularity exec.
-
Next step here : http://forum.tinycorelinux.net/index.php/topic,22455.0.html (http://forum.tinycorelinux.net/index.php/topic,22455.0.html)
-
It works!!!!! ;D ;D ;D ;D
...
YEAH!!! 8)
Welcome to tcGUIX distribution^^
cool!
i missed the attached tcz in http://forum.tinycorelinux.net/index.php/topic,22443.msg140616.html#msg140616
all though it appears to contain broken links ???
$file /tmp/tcloop/guix/usr/local/bin/guix
/tmp/tcloop/guix/usr/local/bin/guix: broken symbolic link to /var/guix/profiles/per-user/root/current-guix/bin/guix
with the exception of
cat /tmp/tcloop/guix/README-GUIX
To see installation script
# cat /usr/local/tce.installed/guix
If all it's OK, you can use GUIX^^
# guix package -i hello
and
cat /usr/local/tce.installed/guix
GUIX_PROFILE="`echo ~root`/.config/guix/current" ;
source $GUIX_PROFILE/etc/profile
addgroup guixbuild
chgrp guixbuild -R /gnu/store
chmod 1775 /gnu/store
builders=10 ;\
for i in `seq 1 $builders` ; do \
adduser -S guixbuild$i guixbuild ;\
adduser guixbuild$i guixbuild ;\
done
~root/.config/guix/current/bin/guix-daemon --build-users-group=guixbuild &
guix archive --authorize < ~root/.config/guix/current/share/guix/ci.guix.info.pub
cd /usr/local/share/info
for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
do ln -s $i ; done
how did you setup guix ?
using modified binary install script ??
i would be happy to test guix
it would be helpful
if could you post more detail of the method ,eg steps or scripts used to get a working setup