SliTaz Forum
You are not logged in.
Hi Filou,
From what I can have encountered with my build, many issues in booting are related to the native unix commands versus those provided by busybox.
Many of the scripts require busybox syntax...
If you understand Italian we can understand each other much better.
Offline
Hi gibor,
I'm afraid I could do with German, English and French (although I doubt the latter would be enough for technical issues) and on an even lower level with Spanish, but my Italian stops directly after:
"Scusi, e libero questo tavolo" ... that won't be enough ... ;-)
As I suspected busybox, too, I first recompiled util-linux to be sure to have working tools and then continued with busybox.
But the Slitaz busybox recipe is very detailed and complicated so I first compiled busybox directly inside LFS again which didn't do the trick yet.
I guess I will have to iteratively try to cook busybox in my lfs wok, leaving out uclibc and a cross toolchain as well as musl-libc for the time being...
That will be a harder one, I guess ...
Thank you for the will to support; if you like, you could provide your experience in Italian anyway, maybe I am able to figure out the essence by interpolating between French, Spanish and "Dr. Google" (which would be StartPage to be true...)
Offline
@Filou,
The boot issue is fixed for me by copying the required library files to /lib64......I don't know why /lib and /usr/lib isn't being searched.
When this is done, it boots cleanly and /etc/init.d/rcS is run as it should be. There are also errors in /var/log/messages that I'm looking into.
Offline
@roadie:
Brilliant! Thanks a lot!
I updated the rootfs in my webspace, boots fine again for me.
Next, I will try to finish the "first level run" through the wok and then dig deeper into what fails in the wok up to now...
Offline
@Filou
I speak both Italian and English fluently and would be glad to aid you if you need detailed/technical translations or explanations, either by email or other mediums.
Offline
@sofia-m: Thank you so much for your friendly offer.
In fact, gibor has set up a working x86-64 bit environment using LFS which seems to be "SliTaz"-like or even based on SliTaz scripts (I don't know any details). (as desrribed in https://forum.slitaz.org/topic/slitaz-and-build-from-scratch-lfs-10 )
It would be very interesting to learn from his experiences, if there have been any special problems when creating especially the graphical packages (like X, openbox, lxde, ...)
For now, I am on the verge of building a working Slitaz-only wok to boot into...
Next steps then will to build a 5.x kernel and hopefully the subpackages.
@shann: since you were the one to switch over the whole Slitaz-universe to new server-structure: could you help in finding a place to host the x86_64 packages I created up to now in order to be able to offer a real repository?
Offline
Hi shann,
good to hear! Merci beaucoup en avance!
Offline
Thanks to shann's support, I was now able to set up a working repository which should make life easier for everybody who would like to play around and test the recent packages of x86_64 SliTaz built with my LFS "bridging-wok".
You will find the a rootfs/initrd that should be bootable with any 64 bit kernel fitting your machine on
https://people.slitaz.org/~filou/rootfs/
I will add a version with a pre-installed wok soon.
Booting this rootfs is staightforward, I use a customized kernel and the following grub4dos entries:
[c]title Slitaz from Scratch (SFS)
root (hd0,0)
kernel /Slitaz/bzImage locale=de_DE kmap=de-latin1
initrd /SFS/rootfs64.gz /Slitaz/ovl_modules.gz[/c]
(ovl_modules being the kernel modules relating to the bzImage in a packed cpio archive).
The x86_64 packages are to be found in https://people.slitaz.org/~filou/cooking64/ which is set up as a repository ready to be refreshed an pulled from. I edited /var/lib/tazpkg/mirror in the provided rootfs so that the already accustomed tazpkg recharge / get-install routines apply.
In addition to that I followed shann's example and set up a wok ready to be cloned from github:
[c]git clone https://github.com/F1lou/SliTaz64_wok.git[/c]
which should provide for the necessary receipts to be able to foolow my example in cooking packages yourself.
But beware, many of the receipts are broken yet and I'll try to refine them step-by-step as well as the rootfs images...
Offline
We are at -={1.762}=- x86_64 tazpkgs now, still growing...
Still have to do some debugging on the SliTaz-x86_64-wok rootfs but will use easter to finish and upload.
The full number of packages is available via https://people.slitaz.org/~filou/cooking64/ , though I will have to update the repository database manually.
@ Tank users: Could it be that the busybox tar on Slitaz Tank is broken? The script to update the repository database uses tar to build the bundle.tar.lzma but any tar compression seems to result in a short read ....
Offline
So tonight I busted the 2.000 tazpkg frontier ...!
After a harder struggle with a dependency loop between Mesa and XOrg-Server, I managed to build the necessary packages to start up the first GUI this afternoon (using IceWM and without any interaction possibilities, because at that time I had not compiled the packages for keyboard, mice etc...).
We have 2.088 packages at https://people.slitaz.org/~filou/cooking64/ now and you are kindly invited to play around with them.
I will try to update the packages database tomorrow, so that the repository will become directly usable again...
Cheers!
Offline
Seems like with the switch to the graphical desktops things come to a somewhat grinding halt.
Some of the packages don't compile well with gcc 10.2 which complains about many deprecated functions or even errors. The logical solution is to switch to the latest respective version of the package to be compiled.
Here comes the challenge... many packages nowadays take the step from autoconf/automake/autogen or cmake to meson/ninja. While the first tools often use libtools to compile, the latter ones do not.
So it's not just a switch to the latest version, since libtool produces libtool archives (<program>.la) which contain information about the package dependencies, referring to one another. So switching to meson means tearing a hole in the libtool archive collection...
So now I had to realize, that the LFS authors had a very good reason for their compilation order laid out.
For everything to be consistent, I will have to take another sweep through the packages following LFS' order and to evade the gaps in the remaining libtool archives...
[EDIT]:
Seems that (of course) I was not the first one to stumble here... and the smart guys at LFS already provided a solution in form of a script that cleans up the .la files...
So... let's go again...
Offline
Ciao, nel mio caso rimuovere i files *.la ha rotto il compilatore gcc... comunque se posso aiutarti fammi un esempio pratico di un pacchetto che fallisce la compilazione. Magari se ho fortuna trovo la patch giusta ;-)
Hi, in my case removing the *.la files broke the gcc compiler... anyway if I can help you give me a practical example of a package that fails to compile. Maybe if i'm lucky i can find the right patch ;-)
Offline
Hi gibor,
thank you for your offer, but the script presented by BLFS already helped me out:
http://www.linuxfromscratch.org/blfs/view/stable/introduction/la-files.html
:-)
Offline
Meglio così. Parlavo di questo passo della guida LFS che rompe gcc.
Best. I was talking about this step in the LFS guide that breaks gcc.
http://linuxfromscratch.org/lfs/view/stable/chapter07/stripping.html
Offline
At last I managed to setup a (seemingly) working combination of a working rootfs-wok (x86_64) and respository...
I posted this as a 80 MB file on https://people.slitaz.org/~filou/rootfs/
The repository https://people.slitaz.org/~filou/cooking64/ is already configured in /var/lib/tazpkg mirror.
All you have to do to start cooking yourself is:
1.) download the tar.xz file
2.) unpack with [c]tar xz <file>[/c]
3.) call the included [c]chroot.sh[/c] file as root
4.) cd /home/slitaz
5.) call [c]get-wok.sh[/c] which will pull the latest version of my customized receipts
6.) start your first cook with [c]cook <package>[/c]
Happy cooking and enjoy your meal !!!
(Happy to hear feedback...)
In the meantime, I will gradually try to set all packages to the latest published versions ...
Offline
Hi Filou, report first test
Busybox require chmod 4755
the double folder run not correctly. One folder and make a symlink to point same folder
My choice is:
rm /run
ln -s /var/run /run
----------------------------------------------------
launch chroot:
tazpkg recharge...
tazpkg -gi xorg-server
xorg-base-fonts-1.2- 100% |********************************| 60780 0:00:00 ETA
Installation of package "xorg-base-fonts"
================================================================================
X window base/minimal fonts from the Xorg project.
--------------------------------------------------------------------------------
Copying package... [ Fatto ]
Extracting package... [ Fatto ]
Remember modified packages... [ Fatto ]
Installing package... [ Fatto ]
Removing all tmp files... [ Fatto ]
Execute post-install commands... /usr/bin/fc-cache: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
c-cache: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
[ Errore ]
Missing package "linux-drm"
================================================================================
1 missing package to install.
Unable to find package "linux-drm" in the mirrored packages list.
Unable to find package "get-linux-drm" in the mirrored packages list.
root@slitaz:/# Xorg
Xorg: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory
tazpkg search libpng
Search result for "libpng"
================================================================================
Installed packages
--------------------------------------------------------------------------------
libpng 1.6.37 x-window
================================================================================
1 installed package found for "libpng"
Available packages
--------------------------------------------------------------------------------
libpng 1.6.37-x86_64 x-window
libpng+apng 1.6.37-x86_64 x-window
libpng+apng-dev 1.6.37-x86_64 development
libpng-dev 1.6.37-x86_64 development
================================================================================
4 available packages found for "libpng"
…..........................................................................................................................
root@slitaz:/# tazpkg remove xorg-server
Remove package "xorg-server" (1.20.10)? (y/N) y
Uninstallation of package "xorg-server" cancelled
end of first report.
Offline
Hi gibor,
thank you so far. I will adjust /run and /var/run (this was not by intent, maybe during setup of Linux From Scratch?) and the rights for busybox binary (same...).
I stumbled over the same reference to libpng12, I made the mistake to update to the latest version without recompiling all the packages that I had already cooked with libpng12... I will have to correct that step by step.
I'd be grateful, if any user would report back so that I can identify the necessary packages...
The same applies to glib-dev and libgio-dev that I just updated, because the pkconfig files had been copied to /usr/lib64 instead of /usr/lib, where the system is looking for...
I will try to improve that again and again!
Offline
I don't really know all the dependencies of libpng. According to the guides it is included in
LSB Desktop:Alsa, ATK, Cairo, Desktop-file-utils, Freetype, Fontconfig,
Gdk-pixbuf, Glib2, GTK+2, Icon-naming-utils, Libjpeg-turbo,
Libpng, Libtiff, Libxml2, MesaLib, Pango, Xdg-utils, Xorg
in practice as a reference of the BLFS guide could be all packages that follow the compilation of libpng
http://www.linuxfromscratch.org/blfs/view/10.1/general/libpng.html
Offline
I just updated the published rootfs (I also added meson and its deps py3k, ...), which is now 94MB again.
Your suggestions concerning busybox and /run - /var/run are included.
I am about to write a shellscript that checks all my already produced tazpkg for wrong pkgconfig location (in /usr/lib64) as well as for links to orphaned libraries (as for libpng12)...
The BLFS guide order sadly is no real help I'm afraid, since BLFS (other than LFS) itself suggests only to compile needed packages and therefore does not really have a clear compilation order... (see the first paragraph of http://www.linuxfromscratch.org/blfs/view/stable/introduction/welcome.html or http://www.linuxfromscratch.org/blfs/view/stable/introduction/welcome.html ). As described, the user will probably come to a needed package, jump back to compile dependencies and forth again...
But I hope, my script will help me in identifying any flaws and the user community will hopefully discover the others...
Thank you so far and let's keep on running... (I will!)
[EDIT]: after some staggering around, I decided that you are probably absolutely right.
I started anew,re-cooking every package as the newest version, beginning in the LFS documentation and continuing through BLFS again.
I will publish the new packages via the repository step by step, hoping to eliminate all residuing old dependencies...
Offline
However, if started in live mode the behavior of the shell is not normal ... in case of a missing command can not make assumptions?!?!
strong suspicion there is the paw of tazpanel and company!
Offline
> strong suspicion there is the paw of tazpanel and company!
... indeed. TazPanel and /usr/libexec/tazpkg are a total mess and so are numerous other bits and pieces in 5.0. Deliberate obfuscation of what is supposed to be free and open ... I think "malicious" is the word for this kind of behavior. And then there was of course the DoS attack on SliTaz servers in the summer of 2019, the one-sided and unannounced fork of the entire distro to Github ... etc. etc.
I think, Shann has a point when he suggests to base the new build on SliTaz 4.0.
Offline
I propose not to be mislead by the image I published: my intent is not to have a full running distro yet but to have a SliTaz-based wok being able to build all the necessary x86_64 packages.
For exactly this purpose I tweaked and bent (!) some of the scripts that are NOT meant to be the base of a new distro!
As soon as we have all (necessary) packages available, we should be able to use the SliTaz scripts to rebuild a working system. If this should be based on SliTaz 4.0 or 5.0 I can not judge yet, because I did not hava a comparing look at the differences.
All I know is that I have very long and good experiences with SliTaz 5.0 32 bit and would like to make a switch to recent glibc, tools, kernel and x86_64...
Maybe it was a good way to go if you worked on the script framework and I concentrate on providing the x86_64 packages?
Offline
For what it may serve the comment above I made it mostly to question the message of the shell
Xorg: error while loading shared libraries: libpng12.so.0: cannot open shared object
the doubt is... corrupted shell => possible corrupted message
Another thing: in spite of numerous tests I've done to narrow down my build, under 1Gb with filemanger graphics and lxpanel I can't get down!!! So we are far from the classic 32bit filesystems of slitaz (150Mb). At this point I think that the idea of slitaz in 64bit version is to be considered to all intents and purposes a distro only for ordinary installation.
IMHO!
Per quello che può servire il commento sopra l'ho fatto sopratutto per mettere in dubbio il messaggio della shell
Xorg: error while loading shared libraries: libpng12.so.0: cannot open shared object
il dubbio è... shell corrotta => possibile messaggio corrotto!
Altra cosa: nonostante numerose prove che ho fatto per restringere la mia build, sotto il 1 Gb con grafica filemanger ed lxpanel non riesco a scendere!!! Per cui siamo ben lontani dai filesystem a 32bit classici di slitaz (150Mb). A questo punto credo che l'idea di slitaz in versione a 64bit sia da considerare a tutti gli effetti una distro solo per installazione ordinaria.
IMHO!
Offline
I confirm the message of libpng. But this derives from the fact that I compiled XOrg packages (and needed dependencies) using the package versions included in pankso's wok during the first run.
Since I experienced problems between gcc10.2 and some of the packages, I switched to newest versions one by one.
This lead to my mistake that I compiled some packages with libpng1.2 and sometimes later others with libpng1.6. So if libpng-xx.tazpkg is updated, the earlier versions don't find the expected dependency anymore. This is no error of the slitaz scripts but my mistake.
This is why I started a new run, compiling the packages again from start along the Linux-From-Scratch (LFS) - Beyond-Linux-From-Scratch (BLFS) order, hoping to prevent this from happening again...
As far as I can see up to now, the resulting packages are roughly in the same order of magnitude as the x32 packages. Therefore I hope to achieve a x86_64 system maybe 50% bigger than the 32bit variant.
Any "normal" distribution (knowing well that there are other "tiny" Linux Versions than SliTaz) I know comes down by at least ~1GB of size, while slitaz 32bit runs with a "installed" system of ~170MB. To my understanding, this is a result of the strict modularity, where single libraries are extracted from fullblown packages, leading to some 100 kB of size where a full package (used by other distros) would be in the MB region (correct me if I'm wrong...).
So: no surprise that a LFS system is well beyond 1GB but that does not (yet) destroy my hopes for a relatively small x86_64 SliTaz...
Offline
[ Generated in 0.019 seconds, 8 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]