SliTaz Forum
You are not logged in.
So, I unzipped and extracted the rootfs using xarchiver, but packed it again (after putting in the drivers from ovl_modules, which I unpacked too) using find ./*| cpio > rootfs.cpio, after having changed my working directory. I gzipped it then. But now there's a kernel panic, so it's worse than before. By the way: the overlay doesn't work with grub2, I checked the modules directory after having booted using the unchanged rootfs. It was empty. So, could someone pack the modules into the rootfs, so I can try it?
Offline
Sorry for answering late, been busy this weekend...
Similar to SliTaz 5.0 on the livecd I use a "stack" of images on my own hardware.
For this, I use grub4dos, which works quite well FOR ME.
This way, I can add or even modify any rootfs by loading additional "overlays", that complement or replace already existing files.
On top of a clean and "kernel-less" rootfs I load the kernel-modules. If I change the kernel, all I have to do is change the modules-overlay with it and can stick to the unchanged rootfs. Like this, it's even easy to add components, like printer-drivers, browsers or office applications directly from the boot menu, which are unpacked into ram as desired.
What I uploaded is a kernel built for my Lenove ideapad Z710 i7-4700MQ, which might (or might not) work on other hardware. What I did NOT build yet (!) is a general-use-kernel 5.x designed for the x86_64 rootfs I provided.
I recommend to use any 64bit kernel you know that runs on your hardware.
The kernel panic you experienced could be caused by busybox lzma, that produces a file with a buggy length (this was discussed somewhere in the forum).
I can post two scripts later at home (I'm at the office now) that work for me to build/modify the rootfs and the ovl-files.
Offline
I think I compressed the rootfs using GNU zip program from GNU, not busybox. Also GRUB 2 doesn't seem able to handle overlays. I checked the modules folder both in /lib and /usr/lib.
Offline
In order to have a "proof of advance" I took the latest slitaz64-rolling and extracted the kernel modules. I then added them to my rootfs in order to have a cleanly bootable image.
I packed this into an iso that can be burnt to a CD and booted from, at least in BIOS mode. I didn't test UEFI, although I replaced rootfs.gz in the EFI folder, too (not knowing if this works this way).
This is why the image has a size of ~150MB, because the rootfs is packed into the iso twice.
You can find the iso under https://people.slitaz.org/~filou/rootfs/
After booting as usual, neither my ethernet nor my WiFi were working, probably because of missing firmware. This might be different for other users...
Offline
Just tried the ISO, it boots, but startx still doesn't work. I have UEFI. Still, it's really nice! It's just weird that the command line has some text "pasted" at my cursor's place every couple of minutes.
Offline
So, uh, about the script for modification of the rootfs... could you post it?
Offline
Sorry (also for being late, been very busy these days...)
Since the upload failed again, I put the scripts in
https://people.slitaz.org/~filou/rootfs/Scripts/
Sorry for them being in German, I hope it is still understandable.
The script [c]custom.sh[/c] unpacks the rootfs.gz to /tmp/ (or offers to proceed in an earlier version) and chroots to the system. You can then install or change everything and after exiting, the system is repacked in /
It was derived from tazusb quite some time ago...
For building an ovl-file I use the [c]writeout.sh[/c] script the following way:
1.) create a directory in which to build the overlay
2.) in this directory, create all directories and files needed (could be only /etc/network.conf)
3.) step back to the parent dir and call the script
Example:
[c]# mkdir network && cd network
# mkdir -p etc
# cp <modified network.conf> etc/
# cd ..
# ./writeout.sh network[/c]
This will result in /tmp/ovl_network.gz being created.
If you use a stackable grub (like grub4dos) then you may use
[c]initrd /rootfs.gz /ovl_network.gz[/c]
and the network.conf from rootfs.gz will be replaced by the modified network.conf during the boot process...
Offline
Some more ideas possible with more recent Linux kernels: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/en/
I have tested le9 patchset with btrfs+zstd compressed root fs by myself on an pretty weak c2d laptop with 2 gigs of ram and also on a Raspberry PI 3b system. Worked as a charm compared to the stock upstream kernel.
If only that kind of magic was available 7-8 years earlier >_>
Offline
@filou
I download your iso from https://people.slitaz.org/~filou/rootfs/Scripts/ , I can not install the package libgdiplus with tazpkg -gi libgdiplus
Offline
@Jianliulin
Please be advised that the iso as well as the packages are experimental and not complete yet.
After having built a working 64 bit SliTaz wok, I am about to compile the packages one by one.
I made a first "sweep" a couple of months ago and built a large amount of libraries etc., some of which are linked to other - older library versions, so another sweep will be necessary for a good amount of them.
All those packages that depend on packages that are not built yet or which show problems during version update or recipe adjustment are not available yet.
Since ligbdiplus is not to be found in my SliTaz64 repository, I was not able to build it without errors yet.
The whole iso is preliminary, e.g. automatic mounting of attached USB devices is not working yet, as gvfs shows problems during compilation.
Since I am on vacation at the moment, the further cooking will be slowed down, but I will stick to this project...
Offline
Short update:
Though gvfs is still not ready yet (because of samba giving me a really hard time, resisting compilation) I managed to compile poppler and epdfview, providing a working PDF-reader solution, which I deem a central capability.
I still have to refine it, though, since openjpeg2 is needed, but not in the dependency list in the receipt yet. For the moment it is necessary to install openjpeg2 manually (in addition, an [c]ldconfig[/c] was necessary for me too, since tazpkg seems not to have triggered it automatically).
... so main message: I am still advancing slowly but continuously...
Offline
Proceeded somewhat:
I uploaded [EDIT] https://people.slitaz.org/~filou/rootfs/211002_rootfs64_office.gz which is a ~62MB rootfs containing the following:
- since gvfs is still not ready yet, I installed spacefm which delivers graphical un-/mounting capabilities
- lxrandr will enable you to configure your (multi-) monitor layout
- AbiWord and Gnumeric together with epdfview provide for the main office functionality
- mtpaint and GPicView for graphics display and manipulation
- unpacking Palemoon, Seamonkey or Firefox will provide for an internet browser
- alsaplayer and asunder provide multimedia (no video player YET).
[attachment=50236,3131]
!!! BUT !!!
I didn't manage to get any sound from my speakers yet. I am sure that this is no kernel issue (using the same for my working 32bit rootfs), but will lie in the pulseaudio - alsa combination.
Maybe there's someone out there who would like to play around with the configuration?
... in the coming days I will pack this together into a new bootable ISO for those who don't want to boot into the rootfs directly...
Offline
Hi, I tried and the audio on my pc is there. Of course I put my kernel its modules and its firmware.
With the reported command I hear white noise, while alsaplayer plays mp3s correctly.
tux@slitaz:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC268 Digital [ALC268 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
tux@slitaz:~$ aplay /dev/urandom
Playing raw data '/dev/urandom' : Unsigned 8 bit, Rate 8000 Hz, Mono
Ciao, ho provato e l'audio nel mio pc c'è. Chiaramente ho messo il mio kernel i suoi moduli ed il suo firmware.
Con il comando riportato si ode il rumore bianco, mentre alsaplayer riproduce correttamente gli mp3.
Offline
Hi gibor!
Good to hear (hahaha...) that the sound problem seems to be a local one... (interestingly enough I am using HDA intel, too...).
@all: so play around with the image and report errors (best together with proposals for improvement) and feed back!!!
Offline
Works !
In fact I simply had to add a one-line file (/etc/modprobe.d/default.conf) containing some info about hda_intel and sound works, too!
So apart from the further struggle with samba and lateron gvfs, I will now concentrate on gimp, vlc and mplayer, along with the necessary dependencies...
For now, I updated the corrected rootfs including the office-packages (Abiword and Gnumeric) and the current version of the wok I use...
Offline
long time slitaz user here.
just checked up on the forum to see whats happening and am glad to see the action!!
guys, you're really doing a great job here. maximum respect. slitaz back on the map!
@Filou: I tried your office image. using your kernel it boots but startx doesnt work. using my arch linux kernel i couldnt use my keyboard. i guess i have to create an overlay with the respective modules?
i could also help compiling packages if needed. do i understand correctly i need to use the wok rootfs? then adapt reciepts of old packages?
Offline
"Filou wrote:
- alsaplayer and asunder provide multimedia (no video player YET)."
What do you think of Celluloid?
Offline
Hi guys!
Glad to see some feedback, felt somewhat lonely in this thread and didn't know if anyone had a closer look apart from gibor, who had substantial feedback which helped me on the way (thanks again to him!) or shann, who even made the very first steps possible (Thx to you too!)
And @K3nn3th: Thx to you for the nice feedback!
I know that an overarching slitaz kernel should be one of the next tasks, which I somewhat evaded in the last weeks due to the complexity of the slitaz receipt. All in all, the rootfs is somewhat running fine on MY HARDWARE since I already use customized kernels for them.
What I am trying to say is: @K3nn3th: yes, I guess it all lies in a working kernel image for your hardware; I am using a lenovo ideapad i7 with i915 graphics which seems to be quite easy to get up and running...
Clearly, this will have to be solved quite soon...
As for the videoplayer: I successfully compiled mplayer package in the meantime. I didn't have a look at Celluloid yet, but I am very open to integrate ANY package on the path, though we will have to be careful not to derive too far from the minimalistic path SliTaz is famous for...
@K3nn3th: if you'd like to compile packages, here is what I do:
1) run a linux (I am using SliTaz 5.0 with customized 64bit kernel)
2) download https://people.slitaz.org/~filou/rootfs/210825_rootfs64_wok.tar.xz
3) cd to any working directory
4) [c]tar xf [download_dir]/210825_rootfs64_wok.tar.xz[/c] (best as root)
5) chroot with [c]./chroot.sh[/c]
6) in the chrooted environment, cd to /home/slitaz/
7) get the wok with [c]./get-wok.sh[/c]
8) update repository with [c]tazpkg recharge[/c]
then, you'll find all receipts in /home/slitaz/wok and should be able to compile any package with [c]cook [package][/c] ...
For any package, I try to figure out the latest version (which is quite easy as the WebSite of the package is provided by the receipt) and edit the receipt accordingly.
Often, there is a change in the compilation setup, switching from configure/make/make install to meson/ninja or cmake, but this is manageable.
Quite a few packages need additional dependencies (Qt is still giving me a headache), some fail to compile with obvious or sometimes very cryptic error messages. If you have compiled a dependency, then you should install it inside the chroot ([c]tazpkg -i /home/slitaz/packages/[Pkg.tazpkg][/c]) as it won't be installed automatically and is not available in the repository yet...)
Step by step, I ususally get ahead and the result (up to now) can bee seen at https://people.slitaz.org/~filou/cooking64/
I suggest, that you play around with this and if you're up and running and would like to contribute, we'll figure out your access to the wok repository ... ?!
Offline
@Filou: Thanks for the detailed description! just cooked my first package (xwax 1.8) on my laptop.
will set it up on my desktop (way more powerful) for a better crunch.
can you tell me which packages have a higher priority?
also i noticed 'tazpkg recharge' has a Database timestamp: 09/25/21 12:03
even though on https://people.slitaz.org/~filou/cooking64/ there are packages (some of which i needed) which were added later than that date. i manually downloaded and installed them to bypass the error.
just thought i'd mention the discrepancy in database timestamp and the package repo.
Offline
edit to my last post:
while setting up the wok on my desktop machine i noticed the database timestamp being 10/10/21.
tazpkg recharge now also gives me the correct one on my other machine.
seems to be working now.
on packages:
- GIMP: compiling protobuf/protobuf-dev/protobuf-python with 3.18.1 worked. compiling mypaint 2.0.1 doesnt work. the strange thing is, even though the url points to the mypaint git repo, i get:
Getting source from mirror...
URL: http://mirror.slitaz.org/sources/packages/m/mypaint-2.0.1.tar.xz
which doesnt exist and halts the cooking.
any idea why it is checking the slitaz mirror?
- python3-setuptools is currently 57.4 in your repo, i made a package for 58.2 and installed it in order to use the latest for the protobuf-python package.
how shall we manage these version changes?
Offline
Hi K3nn3th,
WELCOME ONBOARD !!!
I'm really VERY happy not to be the single soul trying to cook this thing, THX for joining!
Sorry to answer late, I was on a business journey for a couple of days ...
To answer your questions: Every time I successfully compile new packages, I upload them to the repository. Afterwards I normally update the database and timestamp (I have to admit that I rarely miss that last step...)
The included tazpkg scripts are not fit for -x86_64 packages though, so that [c]tazpkg upgrade[/c] will tell you that there are new versions for each and every package though this is not the case (clearly to be seen with a look at the version numbers...). We will have to fix that in the future.
MyPaint and GIMP failed for me too, I think I also failed with protobuf-python, good to hear that you've managed that. (Somehow my Python is stuck here, seemingly doing nothing. I'd be interested in the solution...)
The wok scripts are somehow strange sometimes; nonetheless the download for mypaint worked for me without any modifications of the version presently in the wok (as soon as I eliminate protobuf-python for the moment) ...
For the python3-setuptools I guess this could be fairly easy since (as far as I understood) the setuptools are not linked in any way but are "just a tool on the way to compile with Python"...
The most challenging things to me for the moment seem to be:
- compiling the kernel packages
- compiling Qt (not sure which version(s) will be absolutely necessary)
- compiling gvfs to create full pcmanfm functionality
- adding a browser (webkit based like midori, xombrero; netsurf)
- MyPaint/GIMP
- modifying / brushing slitaz scripts
...
As a first step, I suppose to give you access to the receipt repository so that we can collaboratively proceed ...?
Thx again, Cheers!
Filou
Offline
Collaboration might be much easier, if there was a wok from which to pull and push via mercurial and a cooker to create packages from pushed recipes.
Aleksej Bobylev (and others) created such woks https://cook.slitaz.org/next/ and https://cook.slitaz.org/next64/ with appropriate cooker some time ago.
But sadly these are no longer operable and Aleksej Bobylev abandoned them in frustration.
Might be worth to have a look at them, especially as his work includes some nice features, such as creating subpackages with just one recipe.
Offline
@HGT: Thx for the hint, I see your point; but this seems to be another task on top of all the others, which has already failed for other very motivated developers...
Up to now, this seems to me to be some sort of lonely-rider-show with the potential to grow, but the seed has not taken ground yet.
I have finished and uploaded more than 2.800 packages now (which I haven't all tested or have even seen some to pass an error on startup), but still have some fundamental issues: Qt is not compiling yet and samba is still giving me a headache... (while others like qemu, tightvnc, multiple servers, abiword and Gnumeric, geany and asunder and many more work perfectly well).
... but on the other side I am writing this using a recent 64bit palemoon under "my" SliTaz64 running smoothly and reliably, providing almost all I need for my local tasks.
So there is still progress, I'd welcome any support and I have still not given up...
... so coming back to the mercurial repository and the cooker:
I provide all the recipes via a git repository (which for the time being I solely hold the write permissions, but would gladly extend those to supporters) and stay with a local wok in a chroot environment. This might be some sort of "I don't have time to build a fence, because I have to catch the chickens", but still would be a(nother) distraction from the task I try to fulfill...
... but thank you for the well-meant comment anyway!
Offline
Now this is quite flustering, but I just tried cooking xwax (Kenneths package) after chrooting (I used root (through [c]su[/c]), do you need root?) on my Debian installation and it worked. I used your [c]chroot.sh[/c] script. I was running the kernel I had compiled with aufs support. Unfortunately, I'm in my senior year of highschool so being busy is a given. Should I learn Linux? My command line skills are pretty rudimentary. How do you manage your time and how much do you spend every day? Is half an hour a weekday and 2 on Saturdays enough for help?
Offline
Hi akm,
happy Christmas and thanx for trying....!
Well in fact chrooting (and yes, I think, [c]su[/c] is necessary) is like switching to "another" linux inside your linux, just using the same kernel. So it might seem spooky, but in fact should be expected to work as you did it.
For many packages, it should/could/would be enough to google (or better: startpage or duckduckgo) for the most recent version of the program and edit the receipt. This MIGHT be enough for the program to compile fine and - voilà - we have another package ready to go.
Many others might fail since some dependencies are not available yet and have to be cooked first. Some fail due to reasons I don't understand yet and will have to wait a bit for the repository to still grow.
Occassionally, a package doesn't start to compile, saying "/usr/bin/x86_64-slitaz-linux-g++ is not able to compile a simple test program.". Most often, this can be healed by adding libiconv-dev to the BUILD_DEPS and adding the line
[c]export LDFLAGS="$LDFLAGS -liconv"[/c]
to the receipt, adding the iconv library to the linker path.
Personally, I would refrain from devoting a special amount of time per day or week to this, there's nobody hurrying you. If you'd like to help and have fun playing around with the receipts and learning something about code compilation and so on, then do so as you please. Don't let yourself be pushed in this, as you'd be doing it spending YOUR time with the benefit to OTHERS.
If you'd like to contribute, I suppose you sign up an account on www.github.com and send me your Github Pseudonym, so I can give you access to the wok repository. (You could find my email in the MAINTAINER section of the appstream receipt).
As soon as you have successfully compiled an updated package, you could inform me, I'd recook your updated receipt (as a quality gate and iot to upload the package to the repository afterwards).
This would really be a big help.
Thanx again and have a good and healthy rest of 2021...!
Offline
[ Generated in 0.020 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]