|
written by Tomas M. 7 years ago I'd like to announce the next update of Slax Live Linux version 7.0.6. The main change is new Linux kernel 3.8.2 and updated KDE to 4.10.1. It was a bit harder than I expected, mostly due to some really odd changes made by KDE developers, which I had to work around to get the same functionality like we are used to.
Raw changelog:
- Upgraded Linux Kernel to version 3.8.2
- Upgraded KDE to version 4.10.1
- Fixed missing notification when module is activated or deactivated
- Upgraded all packages to reflect changes in Slackware-current
- Updated FireFox to 19.0.2
- Show date on taskbar under current time
- The device notifier in KDE is now hidden since it was showing on mad positions.
Slax size has been increased by about 3MB due to new stuff provided by KDE software compilation, I'm going to reduce that somehow in the next release. There are some svg icons and some other files which are not necessary at all.
16 comments 16 new
written by Tomas M. 7 years ago New version of Slax is almost done. While testing the new kernel 3.8 I noticed it has some "improved" support for DRM, that is Direct Rendering Management, do not confuse with Digital Rights management :)
The thing is, it blocks console output on some devices, making it effectively impossible to start Slax on console only (without X). To fix this, one has to use vga=normal instead of vga=773 boot parameter which is used to start 1024x768 framebuffer on Slax on boot. I got several notices from users with 1024x600 screens that they see an error when starting Slax since it tries to setup a bigger framebuffer than their screen supports, so I finally decided to use vga=normal as a default parameter for Slax.
6 comments 6 new
written by Tomas M. 7 years ago Google has recently released a new open-source compression algorithm called Zopfli (thanks Thiago Silvino for the notice). From the four page paper which is authored by Google, Zopfli has better compression ratio than gzip, 7-zip, and kzip, while the compression time is slower - it gets increased by about 10000% (!!). Actually we do not care about compression time at all since that is done just once, when Slax is made. So, could this new algorithm be used in Slax with any benefit?
To answer that question we need to understand what data are we comparing. Slax is using LZMA2 (XZ) compression, which was introduced by 7-zip. LZMA2 is by far the best compression available nowadays. Yet Zopfli claims to provide better compression than 7-zip. It could really seem it is better. But there is a catch. The catch is, Zopfli compression generates data backward compatible with DEFLATE algorithm. When the benchmarks were made, they all compressed some test data to a format which is backward compatible with DEFLATE too. Even when 7-zip application was used, it didn't compress by LZMA2, it did compress by DEFLATE (that is the format you are using in ZIP archives).
So, the answer is no. We can't use Zopfli in Slax, since the compression is insufficient for our needs. But I am sure Zopfli will find its way to the web, where static html pages may be compressed using the improved algorithm, while being still uncompressible with all the existing DEFLATE decompressors used in web browsers.
5 comments 5 new
written by Tomas M. 7 years ago I've been somehow busy with other stuff lately, but we had to wait for AUFS for Linux Kernel 3.8 anyway. It's now available, and KDE has released bugfix version 4.10.1, so there is everything we need for the next Slax update release. It should be finished this week, or at the beginning of the next week.
23 comments 23 new
written by Tomas M. 7 years ago I think that getting flu may be good for something. For example you have to lie in bed all the time, since you do not have enough strength for anything else. And while lying, you can only cough and think. That is what I did. And besides all my pessimistic thoughts that I can't possibly survive this flu since it brings inexpressible pain and is so hugely devastating for my body, I had one more idea, more useful one. Ha Ha. :)
It all starts with the skype module. Microsoft, the current owner of skype, refuses to release 64bit version for Linux. I'm not sure if that is due to Microsoft programmers being so stupid, or rather thanks to some undisclosed secret internal policies, but it's how it is. Since Slax 64bit is a real 64bit system, it can run neither 32bit skype nor any other 32bit application. I think it is a pity. So I googled a bit and noticed that it is possible to include both 32bit and 64bit libraries in one system and make both 32bit and 64bit applications usable in 64bit Slax. The method is called multiarch and is widely used by many 64bit Linux distributions.
I prefer to ship the 64bit version of Slax just like it is, as a purely 64bit system. I have no plans for including multiarch in Slax at all. But I understand it may be useful for some users, so I made a module for it. You may try it for yourself, just slax activate multiarch-libs. It will essentially download a 20MB module file which will let you run Skype and many other 32bit applicaions in 64bit Slax. The module itself consists of preselected 32bit libraries, so if you find a software which doesn't work with multiarch-libs (complains about some other missing libraries), just feel free to use ldd to find out what libs are missing and mail me so I will include them in this module too.
24 comments 24 new
written by Tomas M. 7 years ago Some time ago I wrote that my wife and kids got flu, while I was miraculously immune. Well I guess my time has come, and I just noticed that I am infested infected too! :) Terrible experience, I must say.
By the way, kernel 3.8 has been released just yesterday, so as soon as I can, and as soon as aufs is available for this kernel, I will compile it and release new Slax version with KDE 4.10 :)
53 comments 53 new
written by Tomas M. 7 years ago Last week I've added a download counter for all modules, so each time a module is activated or downloaded, its counter gets incremented. This way we will be able to see module popularity in the future. The counter required some rewrite_rules on apache, and just today I noticed that one of the rules was somehow broken. Nothing really serious, but as a result, the build server was unable to read build scripts in queue, and no buildscripts were processed. It's now fixed (16 builds scripts still in queue). It was my mistake, I'm sorry for that.
9 comments 9 new
written by Tomas M. 7 years ago I wasn't quite happy with the search button at modules page, so I rewrote it to be somehow better. You can now choose from a dropdown menu which category are you willing to search through, furthermore you can also choose to search in all modules.
16 comments 16 new
written by Tomas M. 7 years ago I've compiled KDE 4.10 for Slax. It has somehow different look (using Air style instead of Oxygen), and it has some noticable problems such as strange Device notifier placement. I guess I am going to wait for 4.10.1 which will hopefully address the issues I encountered, or I may try to workaround them myself if there is some time. Last two weeks were really problematic for me, my wife and two kids got flu at the same time, and it's almost impossible to do anything under that circumstances. I wonder how is that possible that I didn't get infected as well till now :) Most likely it was thanks to the drugs (vitamins) I consume :) Anyway, they are all fine now so I'm looking forward to fully resume my work on Monday.
36 comments 36 new
written by Tomas M. 7 years ago I noticed several comments regarding the 'feature' that Slax deletes the .sb module file on deactivation. Currently it works this way, since module is automatically downloaded (created) on slax activate, so it's also deleted (destroyed) on slax deactivate. The situation is a bit different if you deactivate the module by giving full path to the .sb file as a parameter, in that case the file is kept.
Some users may activate modules which they downloaded beforehand and they do not like the module file to be deleted on deactivation. At the same time they do not like to use full path to the module file as a parameter. So I'd like to ask you here for your opinion regarding this.
I think that at some point Slax should delete the module file on deactivation, especially if it was activated online (downloaded automatically to /slax/modules/). The reason for that is if the module is not deleted, then it will get activated the next time you boot. I think it is correct to delete it in this case.
Do you think that the correct behavior should be different? Should Slax somehow remember what modules were downloaded automatically and delete only those, while keeping the others? Or do you think that sufficient solution could be to delete only module files if they reside in /slax/modules/ on the USB disk, or in /mnt/live/memory/modules/ in memory, but preserve them if .sb files are in any other locations?
41 comments 41 new
written by Tomas M. 7 years ago I've hired a person to check and fix buildscripts in Slax module repository. His name is Michal and he will be responsible for correct module categories, proper descriptions, and for screenshots. Furthermore he will check if the modules are working fine and will eventually provide advice to the module maintainer in order to make his module better (eg. by correcting menu entries, and so on).
Michal has full rights to modify all build scripts submitted to Slax website, but he will mostly just fix the categories and descriptions at the beginning. If your buildscripts are properly written then there will be no changes made to them at all. In all cases, if you're going to update any buildscript which you previously uploaded, then I'd like to kindly ask you to re-download it and make your changes to it afterwards, to make sure you're editing the newest version. Use slax buildscript download [name] to download your buildscript.
11 comments 11 new
written by Tomas M. 7 years ago There was some confusion recently regarding how does the post-install feature work in Slax modules. So here is a short desscription. If you activate a module, it does this:
1) mount the module
2) add to aufs union to merge with current root filesystem
3) execute ./run/activate.sh from the module
If your module A requires other module B, it works this way:
1) mount module A
2) mount module B
3) add module B to aufs union
4) run ./run/activate.sh from module B
5) add module A to aufs union
6) run ./run/activate.sh from module A
So in general, the activation script is called for every module after it gets merged with the aufs unioned root. And in general, every module is added to aufs union only after all dependencies are firstly activated. It's recursive.
50 comments 50 new
written by Tomas M. 7 years ago Hello everybody, a new version of Slax has been released yesterday. Slax 7.0.5 updates KDE to version 4.9.5 and FireFox 18.0.1, furthermore it provides new feature which lets you upload screenshot of any application to Slax website in order to assign it to a module of your choice.
Sorry I didn't publish the release announcement sooner, I wanted to get Software Center prepared so I can show you some screenshot. Here you go :)
If you wish to get your module listed in Top Picks, feel free to send me a nice 128x128px icon and I will add it there.
Vmware users will notice better mouse support thanks to updated UDEV rules, so the mouse will grab and ungrab automatically for you, no need to do that manually anymore.
The acitvate / deactivate functionality has been improved, you can now activate a module by single click (through the software center) and all dependencies will download automatically.
Download Slax 7.0.5 here
112 comments 112 new
written by Tomas M. 7 years ago As Slax users upload more and more build scripts to create Slax modules, it is needed to also have a good and easy method of taking screenshots of the applications. So I've prepared a simple wrapper for this task. Since Slax 7.0.5 you will be able to select Share Image option in ksnapshot's Send To menu, which uploads the screenshot to Slax server. You will be also asked which module you wish to assign the screenshot to. It will be also (of course) necessary to moderate the uploaded screenshots in order to protect teenage children from seeing inappropriate content uploaded by other teenage children :) (a mature human being will keep the porn for himself, she will not share it with others!) :)
So you will be able to just hit PrntScrn on your keyboard to launch the ksnapshot application, click the button Take a new snapshot to make a screenshot of just the application window you click on in the next step, and then you select Send To -> Share Image. The screenshot will be uploaded as soon as you enter a name for the module you wish to assign the screenshot to. Some autodetection will be in place to offer reasonable default value, so for example if you started supertux and then you're attempting to upload a screenshot, it will offer 'supertux' as a default value for the name, so it should be simply enough in most cases to just confirm the default value by clicking OK. The screenshots uploaded this way will appear at the module detail page, as can be seen here, here or here.
60 comments 60 new
written by Tomas M. 7 years ago I'm going to publish few words from time to time about interesting modules made for Slax. For today, I've selected two games, two office packages and some firmwares.
abiword
Abiword is a word processing program similar to Microsoft Word.
 abiword module page
gnumeric
A GNOME spreadsheet app, similar to Microsoft Excel.
 gnumeric module page
supertux
SuperTux is a classic 2D jump'n run sidescroller game. In a style similar to the original Super Mario games, featuring 9 enemies and 26 playable levels, supertux game ensures long lasting fun.
 supertux module page
crack-attack
Crack Attack is roughly based on the Super Nintendo game Tetris Attack. Slowly, your stack of colored blocks grows from the bottom, and you've got to make sure it never reaches the top. If it does, you lose. To eliminate blocks from the stack, line up at least three of one color, horizontally or vertically. Once you do, those blocks disappear, and put off slightly your inevitable demise.
 crack-attack module page
And finally, firmware drivers, you probably know them, those are important if you wish to use some hardware which doesn't have the driver included in Slax natively. Kernel firmware is somehow big and bloated, contains lots of fw drivers from many sources. B43 firmware is a special tiny package with only broadcom wifi firmware drivers. module page for kernel-firmware and module page for b43 broadcom wifi firmware
38 comments 38 new
written by Tomas M. 7 years ago You can now sign in to Slax website using Yahoo! or Twitter account.
7 comments 7 new
written by Tomas M. 7 years ago I was trying to implement twitter sign in using OAuth (since this very same method should work on some other social networks too, such as yahoo). I've followed the instructions given at the official documentation and was getting 401 Unauthorized response all the time, I couldn't even get the oauth_token. Yet finally I found it. As a part of the OAuth request, there is a timestamp transferred. It must not be in the past. It can be years in the future, but not in the past. The OAuth protocol is Crap.
So we should see twitter and yahoo and maybe some others sign in options hopefully soon.
Why am I spending so much time on this? Actually the reason is that I am planing to make some of the features of this website for signed users only. Thus I need as many supported sign in providers as possible, to make life easier for everybody.
10 comments 10 new
written by Tomas M. 7 years ago I noticed that many other Linux distributions can detect if they are running in vmware virtual box and automatically configure X to grab / ungrab the mouse cursor. You probably know what I am talking about if you ever tried Slax in vmware, you had to press Ctrl+Alt to release mouse cursor from the guest, and you had to click inside the vmware window to grab the cursor in the virtual machine again. That may be annoying. I thought that vmware tools are needed for automatic grab/ungrab to work, but today I learned it can work out of the box without vmware tools at all.
Xorg has vmmouse driver for long time. It even provides /usr/bin/vmmouse_detect binary, which is a tiny program which detects if the moduse is to be handled by the vmmouse driver. Yet the package xf86-input-vmmouse contains only HAL rules to autodetect vmware mouse, and since HAL is no longer included in Slackware since version 14, X falls back to evdev driver or something like that. The following can be seen in Xorg.log.0:
Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled
So how to make Xorg use the vmmouse driver? The following udev rule makes the trick, and will be included in Slax:
ACTION=="add|change", ENV{ID_INPUT_MOUSE}=="?*", ATTRS{description}=="i8042 AUX port", KERNEL=="event[0-9]*", PROGRAM="/usr/bin/vmmouse_detect", ENV{ID_INPUT.tags}="vmmouse"
This is in debian for very long time, but didn't make its way to the official xorg input driver nor to Slackware. I'm going to submit this upstream as well since this tiny change makes a big difference for vmware users.
6 comments 6 new
written by Tomas M. 7 years ago New version of Slax pocket operating system has been released. Improvements and fixes include:
added 'load=' and 'noload=' boot parameter support to filter loaded modules. The first parameter (load=) affects only modules from /slax/modules/ directory - if specified, only those modules matching the pattern are loaded. The other one (noload=) affects all modules, even the core ones. You can use regular expression pattern, for example noload=kde|devel|ffox
better bootinst.sh compatibility with ubuntu and its clones, since those have different default shell which behaves a bit differently than I expected
PXE now tries to get Slax data over TFTP (from the same server) if http connection to port 7529 fails, so you don't need to have a dedicated HTTP server running for PXE if you don't need the best performance (tftp is slow)
fixed a bug which appeared when using from=... to load Slax from a path which included a directory with two letters, like /os/.
fixed URL open in KDE (using %u in exec command in firefox.desktop), so clicking a link in pidgin for example opens it in firefox instead of downloading the URL by kde kioslave. Thanks to Manfred M. for the suggestion
support for special files in Slax Bundles. Content of file /run/activate.sh gets executed on activate, content of /run/deactivate.sh gets executed on module deactivation. File attributes don't matter at all, so there is no need to set them executable.
the autobuild system now adds a file /run/requires to all modules which require other modules. This file is used by 'slax activate' command to recognize and activate all dependencies automatically.
even more improved X autodetection. Tries to fallback to modesetting driver if X -configure fails to produce a working xorg.conf file, and fallbacks to vesa driver if modesetting is not available.
deactivation of Slax module now removes the module file, unless you deactivate it with the real filename as argument - then it is kept
added unRAR support (compiled from official unrar sources)provide rightclick menu option to activate / deactivate Slax bundles in dolphinhide loop devices from showing in dolphin by udev rulebuildscript now requires description, it is no longer optionalfixed korean support (added missing font to korean module)
Download Slax 7.0.4 here
132 comments 132 new
written by Tomas M. 7 years ago I've extended the documentation for best practices by the followint paragraphs. Feel free to share your opinion about them. Thanks!
Remove huge documentation. Lots of software comes with big documentation. If possible, avoid inclusion of this documentation in Slax modules. The reason is simple, almost nobody reads that anyway. Keep man pages, since those are widely used, but also just the necessary ones. Some applications may have the docs in /usr/doc, some in /usr/share/gtk-doc, or even somewhere else. Removeing the HTML/PNG documentation is highly recommended. In general, you can keep the documentation in the module if it is of a reasonable size, for example like 5% of the size of the final module. But if the documentation files are making the module 2MB bigger that is should be removed, unless it is necessary for the module to work properly.
Keep translations in /usr/share/locale. This directory contains translations for most software. Slax is a multi-language distro and there are many users who choose to download Slax in their mother language rather than in English. Keeping translations will make the software speak the different language automatically.
25 comments 25 new
written by Tomas M. 7 years ago If you're writing build scripts to produce Slax modules, always bear in mind that there will be other users using your module. Here are some of the best practices you should follow in order to make your modules smaller, easier to install, and more useful for Slax users:
Use minimum runtime dependencies. If the software you're compiling requires other libraries, which are not absolutely essential for the software to run properly, always check if there are some compile-time options to compile it without the given dependency. If the compilation requires perl or python or other module but the software itself runs without it, make sure to distinguish compile-time dependencies and do not include those in regular dependency list.
Write good descriptions. The better description you write for your module, the easier it will be for the user to find your module (by fulltext search) and to understand what is it useful for.
That is all what I can think of for now. I will add this to the documentation section and I will be happy for your suggestions what you feel is a good practice for building modules (writing build scripts). Thank you.
19 comments 19 new
written by Tomas M. 7 years ago At first I have to say that I really like Ubuntu. No I don't, I'm lying. The reason why I stick with Slackware is the fact that things are actually working as one would really expect, every time the same, not like on the others *buntu based crappy systems. Sorry for the rude words, it made me feel much happier now :)
So where is the problem? On Slackware, you can use echo -ne 'some\ntext' and the output gets rendered on two lines, one line containing word 'some' and the other line containing word 'text'. This is what one would expect to happen. And that happens all the time, even if you run this command in a subshell. Not on ubuntu or other distros based on the same base. You may guess what the command actually echoes. No, it is not some\ntext. It's surprisingly this:
-ne
some
text
What the f**k?!
I am not even slightly able to understand why that happens, maybe it is even my fault to expect something else to happen, I don't know. The most important thing is that due to this behavior (unexpected for me) the bootinst.sh installer wasn't able to make a properly working Slax USB stick on Ubuntu and others, since I was using the above mentioned construct to echo some characters at the standard input of fdisk, to make Slax partition bootable, which didn't work since it received different text than I wanted.
Anyway, to keep better compatibility with the 'other' distros (read: ubuntu), I'll simply use multiple echo commands, to make sure that fdisk understands what are we trying to tell it:
echo a
echo b
echo c
This change will be included in Slax 7.0.4. Thanks to Jerzy Glowacki for spotting that the problem is in boot flag, which allowed me to find out what's really happening there.
38 comments 38 new
written by Tomas M. 7 years ago All build scripts which are uploaded using slax buildscript upload command are automatically executed in a virtualized Slax environment on special server. Till now, if the build script failed for one reason or another, the users didn't have any information about the reasons. Starting of today, I've added email notifications, which inform each user about the status of module compilation from his build script.
If a module is properly created on server by using the build script, the user receives email with just an OK message. However if a module fails to build, the user receives tail of the log file so he can investigate the issue, fix his build script and update it in the repository. Furthermore, if the module builds properly but has unresolved dependencies, it is refused and the user is informed by email what libraries are missing.
I hope that these changes will help people to work with build scripts much more effectively.
Another change has been made to the output of command slax info. This command prints information about any build scripts uploaded to Slax repository, even those which were not built properly. Added information now include status of module creation, thus you can see if the build script has module files created or not.
21 comments 21 new
written by Tomas M. 7 years ago When I first started to work on Slax many years ago, my goal was never to make money from it - I just wanted to learn something about Linux and share that with others. However, it turned out that if a project makes some money then it can grow much more rapidly and it can be, as a result, even more useful.
Slax didn't make any significant revenue in the past. It was maybe due to the fact it wasn't marketed properly, or maybe because it didn't offer anything to spend the money on. With Slax 7, I decided to change that. You could already see that at the main page, where you can find a form to order Slax on a cool USB flash drive; many of you received the device already. I'd like to thank to all buyers once more again for their support.
Each drive sold brings profit to Slax, which in turn makes me spend more time on it, which in turn makes Slax better :) I'm very happy to report that Slax project has generated, for the fist time in the history, an income significant enough to mention it. By selling the USB drives, Slax made $4079 in December 2012. That is just the income before deducting the costs, so final profit will be of course lower.
In the near future, there will be more ways how to spend money on Slax :) and there will be even ways how to earn money on Slax. This all is possible only thanks to you, Slax users. Thank you!
17 comments 17 new
written by Tomas M. 7 years ago If Slax is started with the boot option "Act as PXE server", it executes /sbin/pxe script during startup (in between runlevel 3 and runlevel 4). The pxe script has several goals. First of all, it takes the current initramfs directory tree from currently running Slax (from /mnt/live), adds to it all currently available network drivers from /lib/modules/ from the currently running Slax system, and packs everything into a new initramfs image, which is much bigger than the original one (since it contains all the drivers). It is stored in /var/state/dnsmasq/root/initramfs.img). This image is packed by gzip rather than xz because gzip has much better compression speed, and we don't care about compression ratio here, the size actually doesn't matter so much.
When the new initramfs image is created, Slax data files are symlinked to /var/state/dnsmasq/root/* so the files can be downloaded by the client machines later.
Finally, several services are started in background, such as DHCP, TFTP and HTTP. This ensures that the client machines get IP address assigned properly and are instructed to download vmlinuz and initramfs.img over TFTP from the server. Later, the client machines will download Slax data files over HTTP (which is much faster than TFTP in general) and Slax is started on the clients.
Update
If you have your own existing PXE server and just would like to boot Slax on your client machines by using it, you can actually do that too, but it is a bit tricky. First of all, you'll have to boot Slax acting as PXE server, and locate files in /var/state/dnsmasq/root/. You'll see initrfs.img image there and a link to vmlinuz. These two files must be served by your own PXE server over TFTP. Next, you'll have to setup a webserver on the same machine where your PXE server is running, on port 7529 (this number appears if you type SLAX on your mobile phone). Your webserver must provide PXEFILELIST file as you can find it in /var/state/dnsmasq/root/ as well as the data files listed in the PXEFILELIST.
40 comments 40 new
written by Tomas M. 7 years ago A new version of Slax Linux is available for download. This release adds several new features and fixes few bugs as well. Probably the most interesting feature is PXE boot support and improved X autodetection.
PXE feature description:
All modern computers nowadays support PXE, which allows booting of an operating system over network interface independently of data storage devices (like hard disks). Slax fully supports PXE booting now. How to do that? One computer will act as a server, so just boot Slax on it from CD or USB and make sure to have the appropriate boot menu option "Act as PXE server" checked. Slax on the server computer will provide DHCP, TFTP and HTTP services to enable PXE booting for other computers in your network. Now turn on all the other computers (clients) and make sure to select PXE boot in BIOS boot menu of all these computers. All the clients will autodiscover Slax PXE server and will load all needed data from it. Slax will start on all clients over network.
Raw changelog for Slax 7.0.3 follows:
- added PDF file with Slax documentation- added PXE server and client support- added dnsmasq, added httpd support to busybox- improved X autodetection by calling X -configure if default configuration fails- added xev, a tool to list code of pressed key, so user can easily remap it with xmodmap- bashrc file has been fixed to properly show current directory on command prompt- fixed cleanup of 'slax' script (remove temporary files from /tmp using trap)- fixed buildscipt checks to allow required bundles with + and _ characters in name- fixed deb2sb (and deb2txz) script to support lzma-compressed DEB packages- run kbuildsycoca4 on module activation to update KDE menu- include mc.sh in bashrc so mc remembers last directoryBig thanks to Manfred M. (http://www.fluxflux.net/) for suggestions!
Enjoy the new Slax release, and feel free to submit your comments.
117 comments 117 new
written by Tomas M. 7 years ago While we're waiting for FTP mirrors to get updated for the next Slax release with PXE support, please take a while to review Slax documentation. I tried to cover the most important topics there, including module usage and buildscript creation, yet it is fairly possible that I forgot something or just wrote some part improperly. I'll be very grateful if you could possibly go through the documentation and let me know if there are sections which need more clarification or explanation. Thank you.
19 comments 19 new
written by Tomas M. 7 years ago After numerous requests for PXE support I've decided to implement it. It wasn't such hard, yet I struggled two problems. First one was an odd behavior of cpio, which wasn't able to create correct archive when asked to pack files from several directories into one. I didn't really find out how to make it work the way I wanted, so I had to create a temporary directory where all files are copied a priory and packed into a CPIO archive later. Another problem was pivot_root call, which refused to work and returned Invalid Argument error every time. Took me a hour to find out what's wrong. Linux live kit though it already escaped initramfs due to forgotten flag file. Anyway, the problems were resolved and I'm now running Slax which booted over PXE.
There is yet one more issue I'd like to address, it is the speed of downloading Slax bundles (.sb files) over TFTP. It's very slow. So I'm compiling busybox with httpd support (yeah) and I'm going to try that instead of tftp, in the hope that it will be somehow faster.
How PXE works: One computer (a server) is running Slax. Use command or boot parameter (unnamed yet) to prepare Slax to act as PXE server - it will just create an initramfs image with all network kernel drivers which are currently available in the currently running Slax, and will start dhcp and tftp services.
Other computers (clients) will have PXE boot selected instead of disk boot. PXE autodiscovery will send to each client computer a new IP address and the needed files (vmlinuz, initrfs.img). Slax boots on client machines, modprobes kernel drivers to enable networking, downloads *.sb files from the local server into memory and runs from there.
31 comments 31 new
written by Tomas M. 7 years ago I had an impression that recent versions of xorg can autodetect everything on its own when no configuration file is present, so I didn't care much about this in Slax. I thought that xorg is a smart system. I was wrong, it seems :) Yesterday I just purchased a cheap mini notebook (netbook) from Acer and Slax wasn't able to start X automatically on this device. What a shame. Yet X was running properly after xorgsetup command. So I started to wonder, what makes the difference?
I have to say that it's pretty odd. The difference is in running 'X -configure' to create an xorg.conf file which is later used by X itself again. One would say that if X can autodetect the hardware to create the configuration file, it should be smart enough to do the very same thing when running without one. But apparently that is not the case, so I saw "no screens found" error instead of X.
Good news is that thanks to these findings I can improve Slax again :) I will simply make it run X -configure first before X is started, to assure that there is at least some config file for further usage.
32 comments 32 new
written by Tomas M. 7 years ago In older Slax version (6.x) all modules could include rc script in /etc/rc.d/ which get executed even during 'activate' command. This is not the case for Slax 7, there is no such functionality so far. I'd like to make it a bit differently.
This is not implemented yet, but I'm thinking about something like this: the directory /run in each Slax module could include several special files. For example, a special file /run/activate.sh could be a script which is to be executed when the module is activated by user while running Slax. Other file could be /run/deactivate.sh, which would be executed when the module is deactivated (perhaps to properly shutdown the application and close all files so the module could be even deactivated at all). Those scripts could be also executed during system startup, so you don't need to have your own rc scripts in /etc/rc.d/ or /etc/init.d/
The main idea is that /run is overmounted by tmpfs in Slax anyway, so if the module has files in /run then those won't be visible in Slax' root filesystem at all, making them effectively hidden, only accessed through /mnt/live/memory/bundles/123-module.sb/run/* so only Slax could understand them and execute them as needed.
31 comments 31 new
| |
