SliTaz Forum
You are not logged in.
About to compile kernel. Could try debian kernel. How did you put in aufs support? Just take latest patch from 2015 and rename all files to reference kernel version?
Offline
Debian 10 is the last one to have some package called aufs-dkms. does that mean the module is integrated into the current kernel I have installed on debian?
Offline
Kernel version 5.10.45 by the way.
Offline
@akm: thank you for the suggestion, but rather than using the kernel of another distro, I'd go for a direct vanilla build.
How to build a kernel with all the possible modules is straightforward and quite clear to me, it's more about the distribution into the diferrent module-packages that could be difficult.
We already have the linux-xyz/receipt(s) that are optimized for the 3.x. kernel, but I want a 5.x kernel to be up to date.
So I guess I / we will have to work all the way down through the single receipts to get to a similar module distribution as in good old slitaz32, since the concept of our tiny distribution is to offer very small and modular packages where you can pick exactly what you need...
Offline
Ah, sorry, didn't express my question properly. I meant, I don't have a clue about how to put aufs support into the kernel, yet I read that aufs was needed for this rootfs. Can you lay down some instructions?
Offline
Ah, ok.
Did you check http://aufs.sourceforge.net/ ?
There you'll find how to download (via git) a full already patched mainline kernel or how to download a standalone package and to apply the necessary patches to a vanilla kernel (even how to compile a module only).
In addition, you need to compile aufs-utils, but that's explained there, too.
I'm afraid I could not explain the necessary steps better than the webpage, but experienced the explanations to be quite straightforward...
Offline
Hi there,
meanwhile I managed to compile the latest version of slim, compilation runs through without errors, file information is correct and package size and files are comparable to the 32bit version.
Starting with [c]slim -v[/c] displays the correct version information, the binary seems to be sane.
Nonetheless, slim does not start and [c]/etc/init.d/slim start[/c] returns that the service could not be started. What is lacking is a clear error message.
Could anyone with more "SLiM experience" play around with it and maybe give a helpful hint, please?
Apart from that, gnumeric is available as 64bit tazpkg now (goffice is not yet in its dependency list, so it has to be installed additionally, I will correct that), so step by step, the system is developing...
I'll soon turn to the kernel...
Offline
I might have compiled a very bloated kernel, but...
Do I place that rootfs64 into the root of a partition along with the kernel? Is it basically some kind of initramfs, loaded by the initrd utility in the kernel?
Offline
It is exactly that: an initramfs.
On the screenshot of my Screen1 in the post from last week (https://forum.slitaz.org/topic/slitaz-future/page/11?bb_attachments=50108&bbat=3094) you can see the grub4dos menu entries I use for booting the image.
All I add is the kernel itself and an overlay with the necessary kernel modules...
Remember that it is not necessary to put this image into the ROOT of a partition. It could be anywhere as long as grub can find and boot it...
You could also use my uploaded kernel and kernel modules to be found under https://people.slitaz.org/~filou/rootfs/ , I am just not sure if this suits your hardware, but it might be worth a try...
Offline
@Filou
There is a patch to apply for slim that eliminates PAM. Once done I installed it on your rootfs.gz along with libjpeg-turbo-2.0.6 and everything works... except that the user configuration needs to be reviewed (login session failed).
C'è una patch da applicare per slim che elimina il PAM. Una volta fatto l'ho installata sul tuo rootfs.gz assieme a libjpeg-turbo-2.0.6 e tutto funziona... salvo che c'è da rivedere la configurazione utente (login session failed).
https://www.linuxquestions.org/questions/slackware-14/slim-1-3-6-problem-with-compilation-4175529742/
Offline
Managed to boot, but no keyboard input (I use USB). I think I have to place the kernel modules. But, just out of curiosity: why do we need aufs?
Offline
We don't need aufs in this rootfs.
Aufs is only necessary for the wok, because compilation is done in an overlayed directory, protecting the underlying system.
So if you just want to run the rootfs, incl. maybe palemoon (you can extract the 64bit version and run it directly from its directory), gnumeric, mtpaint and so on, then aufs is absolutely NO necessity...
Offline
Thanks to gibor's input, I was able to get slim running now. In fact, it was just the config file shipped with slim that didn't work together with slitaz.
I made a "hard" switch for the time being, correcting just the rootfs,which is available under https://people.slitaz.org/~filou/rootfs/ with today's date.
I will have to correct the receipt however, in order to create a valid tazpkg. (but will do that later...)
Offline
You will certainly have noticed this, but in any case I will report some of the problems I found during my tests:
udevd[167]: invalid key/value pair in file /etc/udev/rules.d/90-permissions.rules on line 8, starting at character 17 (',')
Creating the udev hardware database...
Failure writing database //etc/udev/hwdb.bin: Read-only file system
failed to set locale!
[error] cannot open locale definition file `i18n_ctype': No such file or directory
pcmanfm does not show internal partitions
pcmanfm: select a file or folder with the right button and properties, shows nothing.
Offline
Hi gibor,
Thank you, and yes, I did notice it.
Since udev absolutely failed to compile and is a needed dependency for many packages, I decided to stick to Beyond-Linux-From-Scratch descriptions and went for eudev as a replacement. The 90-permission is a residual of udev (I guess) and will have to be cleared and corrected later.
But all in all, eudev seems to be running ok, a [c]udevadm monitor[/c] clearly registers and reports a USB HD being attached and assigns correct device nodes.
I have to admit that my eudev expertise is sparse and I (maybe "we") will have to work on that in order to function properly, if there should still be flaws.
This - together with still missing gvfs-packages - will be the reason for the missing support for the internal partitions as well as lack of USB drives showing up and the missing properties.
As I said: still a long way to go!!! But looking back, what was achieved in the last six months was at least a functional graphical desktop on a recent x86_64 architecture with more or less "classic" tazpkgs and a local wok that can handle the receipts that of course have to be updated and patched...
Offline
I have to admit that my eudev expertise is sparse and I (maybe "we") will have to work on that in order to function properly, if there should still be flaws.
it is well known that udev does not work well since version 181. all output messages are hidden...
file /etc/init.d/rcS
udevd --daemon 2>/dev/null
just as I will never understand why merge pcmanfm with gnome, which has an infinite number of dependencies....
On my 64bit version I still use udev-172 and pcmanfm-0.5.2 together with the hated hal...
Offline
As far as I understood, the "automount/-display" (not to mix up with the automount daemon) should work with a combination of (e)udev, udisks2 and gvfs together with pcmanfm.
udisks2 (Version 2.9.2) shows an error during compilation, requiring systemd to finish.
I compiled systemd correctly with the wok, but it is quite a monster concerning number and size of files and therefore was rejected for slitaz.
elogind seems to be an alternative but is a derivative of systemd an doesn't seem to be much slimmer.
But according to BLFS, elogind is "recommended", not "required" and as far as I read, (B)LFS does NOT use systemd by default.
I didn't find any udisks2 configure options nor a patch to switch off systemd. Slitaz cooking 32bit uses udisks2 (Version 2.1.8) and doesn't require systemd. The receipt was only slightly adjusted for the update.
Does anybody of you have an idea how I could proceed to compile udisks2 without systemd?
Offline
Hi, I've never compiled systemd, but udisk-2.9.2 has, and I seem to have no errors.
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var –disable-static
I'll post the whole config.log if you need it.
Ciao, non ho mai compilato systemd, ma udisk-2.9.2 sì, e mi sembra di non aver avuto errori.
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var –disable-static
se ti serve posto anche il config.log per intero.
Offline
Hi gibor,
thank you again for the hint.
As it turns out, I was mistaken by the wok's report, which stated that systemd could not be found and ended with an error. This, as I found out now, was just a report from the configuration part, that searched for available assests and just told me that systemd was not installed.
By that I focused on systemd and overlooked the actual error that in fact hid behind:
[c]GEN org.freedesktop.UDisks2.policy
/usr/bin/msgfmt: cannot locate ITS rules for org.freedesktop.UDisks2.policy.in[/c]
msgfmt, being part of gettext-tools, seems to be working ok.
Based on my first search result, we have an issue with either intltool (which is the latest version 0.51.0) or rather with polkit (installed version is 0.119).
For polkit, there is a version 0.200 on gitlab, but this release depends on libmozjs, which I provided already, but which adds about 7M of package size...
So I understand that this is an issue about converting the file org.freedesktop.UDisks2.policy.in located in the sources/data directory into org.freedesktop.UDisks2.policy, a file that is needed in order to trigger polkit.
But how can I solve it? Any ideas or even better, deeper insights?
Offline
I don't know, I don't get that error. I used polkit-0.118 in mine, but then I removed everything because I didn't want to go that route. Now only the sources are left on an external partition, and I don't really know how to help you track down the source of your problem.
It may not mean anything but one thing that sounds bad to me is:
Gtk-WARNING **: 14:43:49.363: Locale not supported by C library.
Using the fallback 'C' locale.
Non so, quell'errore non mi compare. Nel mio avevo usato polkit-0.118, ma poi ho levato tutto perché non era mia intenzione seguire quella strada. Ora rimangono solo i sorgenti su di una partizione esterna e, non saprei prorpio come aiutarti a rintracciare la fonte del tuo problema.
Può non significare nulla ma una cosa che mi suona male è:
Gtk-WARNING **: 14:43:49.363: Locale not supported by C library.
Using the fallback 'C' locale.
Offline
... found the error...
since I follow SliTaz' principle of minimalism, I overlooked that polkit's receipt left out a policy file that was essential here...
Rebuilt polkit and now udisks2 went through fine...
I will proceed with gvfs and hopefully, we have the automount/-display features enabled in pcmanfm again...
Offline
I downloaded your kernel, but startx doesn't work. I saved the log, I've supplied it with this post. I think the modules still pose a problem. How do the rootfs and the overlay play together? I'm sure there's a symbolic link or a folder somewhere in the rootfs, where all of the modules are located. As I've compiled a kernel with aufs support, and upgraded my Debian installation to it, I think I could place my 5,4 gigabytes of modules from /usr/lib/modules/5.10.47/ into it, or extract them from the rootfs automaticallly built. Is there a .so file in the rootfs?
Offline
Here's my entry for GRUB2 in the file /etc/grub.d/40_custom
[c]menuentry "UnderConstruction" {
search --set=root --fs-uuid ad1b45cb-a187-464a-bc12-64ad892a0b0f
linux /bzImage root=UUID=ad1b45cb-a187-464a-bc12-64ad892a0b0f ro quiet splash
initrd /boot/myrootfs64.gz /boot/ovl_modules.gz
}[/c]
All I have on that partition are the bzImage in the root folder the rootfs.gz and the ovl_modules.gz in the /boot folder. Nothing else, not even folders other than /boot.
Offline
@akm
I'm sorry but I don't speak English, I'll try with a translator and write in Italian.
Do not use debian or similar kernels that require initrd booting. In that case errors will occur with the init which is not the default slitaz init.
Another thing is to unpack the whole downloaded rootfs.gz onto a partition of your choice (ext3 or ext4)
lzma -d 210615_rootfs64.gz -c | cpio -idv
add to that partition the /boot folder containing the kernel-64bit of your choice (bzImage).
always of your kernel add its modules and firmware in /lib/modules and /lib/firmware
with a grub4dos set the boot in
title Slitaz
root (hd0,1) <<< or your partition choice
kernel /boot/bzImage root=/dev/sdb2 <<< or your partition of choice
------------------------------------------------------------------------------------------------------------------------
scusami ma non parlo inglese, tento con un traduttore scrivendo in italiano.
Non usare kernel debian o similari che richiedono avvi con initrd. In quel caso avvengono errori con l'init che non è quello predefinito di slitaz.
Altra cosa scompatta per intero la rootfs.gz scaricata su di una partizione a tua scelta (ext3 o ext4)
lzma -d 210615_rootfs64.gz -c | cpio -idv
aggiungi su quella partizione la cartella /boot che contiene il kernel-64bit a tua scelta (bzImage)
sempre del tuo kernel aggiungi i relativi moduli ed il firmware in /lib/modules e /lib/firmware
con un grub4dos imposta l'avvio in
title Slitaz
root (hd0,1) <<< o la la tua partizione
scelta
kernel /boot/bzImage root=/dev/sdb2 <<< o la la tua partizione
scelta
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.6 MiB (Peak: 1.77 MiB) ]