Mark's Tech Blog

Yes – you heard right!

After months and months of testing, contemplating over switching to Porteus and waiting for Tomas to come up with a new version of Slax, I decided it just wasn’t worth doing anymore. I had been trying to use Tomas’ Linux Live Scripts to make a modular Ubuntu, which would at least give us the option of having a software repository with apt-get, but the Linux Live Scripts just didn’t work with Debian (even though Tomas claims they do). The methods of making a live media Ubuntu were all not modular and proceeding with that would actually be a regression, considering we had come from a non-modular live cd to a fully modular Slax. The decisions of the kernal contributors to do away with bootsplash in preference of Frame Buffer also meant very little customizations to the look and feel. Given all that and the effective size and cost of thumbdrives these days which can hold a fully installed Linux, and be booted from almost any modern system, I figured there was no point carrying on with BioSlax.

Its been a great run and I learned a whole lot creating it, (the lessons have been extremely useful in other projects), but for now, BioSlax development is shutdown.

Porteus has released its long awaited v2.0 of its live OS. Porteus is a fork of SLAX and when Tomas went into hibernation mode after SLAX 6.1.2, Fanthom (a prominant user on the SLAX forums) forked the distro. It was first called SLAX Remix, and then later with its own website and all, it changed to Porteus.

Unlike SLAX which is basically a one man operation, Porteus is completely community run, with multiple developers working on different aspects of the distro. It helps for better cohesiveness in the production of the releases thats for sure and all the users contribute actively to the betterment of the distro with the developers paying close heed to the needs of the users.

I suppose Tomas’ idea creating SLAX was mainly for his own use and decided to share what he had to others. It that situation, he more often than not disregards what users suggest when the suggestions are not in line with what he wants to do. Can’t fault him for that, its his distro, but it annoys users to no end and tends to pull them towards other distros.

Porteus is light (under 300MB) and has a lot of bells and whistles like the GUI installer and package manager which makes it easy for novices to handle installations to the system. It has multiple desktop environments (DEs) to choose from such as KDE, LXDE and RazorQT with Gnome and Cinnamon coming soon. Bad point (one so far) is that it doesn’t have a Live Kit installer like SLAX has – as in theres no application that will allow one to create a Porteus live distro from a customized porteus setup. Its got to be done manuall, which from what I understand from Fanthom, is exactly how each release of Porteus is made.

So, all the pluses and just one very minor, insignificant minus, which makes it no mystery why I’m seriously considering Porteus as a base now for BioSLAX 8. After the dissapointments in SLAX 7, Porteus seems like a very likely answer. The actual mystery, is what I’m waiting for.

Porteus is close enough to SLAX for me to know the inner workings and customize it so why am I hesitant about making the switch? Seriously I don’t know. Maybe its a sentimental attraction to SLAX or perhaps the fact that my disto does have the term SLAX in it, but whatever the reason, I find myself silently waiting for SLAX7 to get better.

Initially I could say I was waiting because Porteus v2.0 was only released as RCs, but that can’t hold up any more since they just put out the final version. I am particularly interested in having Cinnamon as a DE which Porteus is going to do and I hear Tomas is going to release a newer version of SLAX 7 with KDE 4.10 and the 3.8 kernel. So at least for now, I still have a reason to hold off on jumping to Porteus, but I’m seriously running out of excuses. Heres hoping Tomas gives me a good enough reason with the next version of SLAX.

Amongst my frustrations with the new SLAX 7 was this annoying effect with older Core2 machines where an attached thumbdrive at boot would be identified as /dev/sda instead of allocating the internal hard disk as /dev/sda.

After a month of complaining and getting no response, mainly because no one else could replicate the problem, I spent a long while Googling and found this site:

https://lkml.org/lkml/2012/10/25/595

It basically explains that the issue was due to a kernel configuration for floppy devices. You read right – floppy devices. In order to save the bootup time and detection for floppy devices that weren’t there, some changes were made to the kernel and if you set:

CONFIG_BLK_DEV_FD=Y

then all drives would be named according to the order they are detected and that usually means USB first. This happens only on the older Core2 machines as I stated and its highly annoying for a distro that uses LILO as its boot manager since the boot devices etc have to be defined in the /etc/lilo.conf. Folks were saying “use UUIDs” with LILO but there was very limited success in doing so and this posed a huge problem in wanting to install SLAX as a fully installed Linux.

To restore the correct naming for the drives, the kernel needs to be compiled with:

CONFIG_BLK_DEV_FD=m

How did we find this out? Well trying to find a solution to the issue, I tried out Porteus (another live distro forked from SLAX) and found that it had no issues with the naming of the drives. Together with the link I found above, I made mention to Tomas, who then compared the .config files from both SLAX and Porteus and found that on Porteus, the config option was set to “m”.

I recompiled the kernel with the option set to “m” and just like that, the naming went back to what we’re all used to with the internal hard drives getting named first.

Another issue solved!

When SLAX 7 was released on Dec 10th, the initial feel was that it was pretty good and ready as a base for the new release of my own BioSLAX distro, but after playing with it for a week and interacting with Tomas and other users, I think its not ready at all.

• No PXE boot
• SCSI controllers are weird (if you boot up with a usb drive/thumbdrive, it will allocate sda to the usb drive instead of your internal drive)
• Doesn’t auto mount partitions or drives
• Missing a tonne of software and libraries
• KDE 4 is still lacking in user friendliness

Don’t know if it was released in an unpolished state because of pressure from Tomas’ commercial investors or some other reason, but its just not built like Slax 6 was.

Other nuisances include the Kernel Mode Settings (KMS) which while is great for setting the native resolution of screens, wrecks havoc on bootsplash. As you know from an earlier post, I was able to get bootsplash working with the new initramfs, but even then, KMS completely kills it when the system hands over control of the graphics setting to the kernel – no /proc/splash means no bootsplash and no decor for the VTs either. Advice so far as been to use things like fbsplash or plymouth. The complexity of both isn’t really justified and I’m still looking for a way to use bootsplash with the whole thing.

UPDATE:

Tomas has implemented the PXE boot after a few of us requested it. Also the SCSI controller problem seems to be isolated only to older Core2 machines. The i3s, i5s and i7s don’t seem to have this issue and it also doesn’t exist with Slackware 13.37. Might be a stray kernel option in the compilation, but I need to look into this more.

UPDATE 2:

Solved the SCSI controller problem and it turns out to be floppy device issue!

I finally managed to have bootsplash patched into the SLAX kernel using the patches from here:

http://www.uli-eckhardt.de/bootsplash/index.en.shtml

Just need to edit one of the patches to remove some stuff from “Patch for 3.4 bootsplash-3.4.diff.bz2”. It will still work with later kernel versions.

After recompiling the kernel, to get the bootsplash working isn’t very clear on most websites. With the old initrd or initrd.gz, one would just do

splash -s -f [full path to bootsplash config] >> initrd

This unfortunately doesn’t work as the cpio created initramfs gets messed up if you do this. After going though a lot of websites with methods that didn’t work, I managed to look at the bootsplash patches and noted the portion under the “init” which basically says it will attempt to open the file /bootsplash. So that kind of implies that the bootsplash image should be in the initramfs. A little more Googling and I confirmed this on least two more websites. It was like finding gold let me tell you. A bit of experimenting prooved the point and I have bootsplash with the initramfs running now.

Lots of people have said bootsplash is the past and with KMS it will be obsoleted, but I still think its the easiest to get working and for now it gives an option for those who want to brand their distros but don’t want to start compiling something else like fbsplash or plymouth. These are the steps I took:

• Get the bootsplash user space utilities from from any of the links here: http://www.filewatcher.com/m/bootsplash-3.1.tar.bz2.112416-0.html
• Compile and install the utilities. You should have a /etc/bootsplash and the splash tools in /sbin now.
• Get your verbose and silent splash images or theme and config into /etc/bootsplash/themes
• Generate the init bootsplash from the config with:

  /sbin/splash -s -f /etc/bootsplash/themes/<themename>/config/<configfile>.cfg > /tmp/bootsplash

• Extract the initramfs to someplace (eg:/tmp/inittree) using:

  mkdir /tmp/inittree; cd /tmp/inittreexz -dc <path-to-slax-initrfs>/initramfs | cpio -i

• Copy the whole of /etc/bootsplash to the /tmp/inittree/ and copy /tmp/bootsplash to /tmp/inittree (so its in the root of the inittree):

  cd /etc; cp -R /etc/bootsplash /tmp/inittree/etccp /tmp/bootsplash /tmp/inittree

• Recompress initrfs with:

  cd /tmp/inittree; find . -print | cpio -o -H newc 2>/dev/null | xz -f --extreme > /tmp/initramfs

• If this is for SLAX, the initramfs should be initrfs.img and you should then replace the stock Slax vmlinuz and initrfs.img with the patched kernel and the new initrfs.img. The initrfs.img increases by 30KB and vmlinuz increases by 10KB.
• Make sure to edit the boot options and set vga=791 to get the bootsplash to show

The bootsplash will only show up like the old behaviour until the KMS kicks in, then it will dissapear. To keep the bootsplash around and have graphic background for your virtual terminals, use kernel parameter “nomodeset” (which disables KMS) at boot.

I’ve been playing around with nomodeset and a lot of different graphic cards and even without KMS, the X resolution is fine, especially for the new distros. The only card I’m constantly having trouble with is the Intel GM945. Thats the only one I need to use KMS modeset with so far.

I figure there are other cards that give issues too, but I find a majority still work well without KMS, especially with the newer distros.

Based on this, to make a SLAX based distro more appealing, I would propose the default to be booted with “nomodeset” to maintain the bootsplash and graphic background virtual terminals and have the KMS as a fall back mode for those troublesome cards. In other words, another option “KMS” other than “Persistent changes”, “Graphical Desktop”, “Copy to Ram”, etc. on the boot page of SLAX. Thats what I’ll be doing for the new BioSLAX anyway.

Its been a long wait, 3 years in fact, but SLAX, the pocket operating system on which my own BioSLAX is based, has resurfaced. SLAX 6.2 was the last official version released somewhere in late 2008, early 2009 and its creator Tomas Matejicek stopped all work on the project. Followers of his personal blog did know that he was still tinkering in the background, and when he announced that he had found commercial backing for SLAX, most of us started rubbing our hands in glee.

In any case, SLAX 7 was released a few days back – time to see if all that waiting was worth it.