Saturday, May 30, 2009

Another update for Slack/390

Just a quick note...

xpdf has been updated for Slack/390.
This is a security patch, so update your -current system with SlackPkg without further ado! ;-)

In the mean time: I've been playing around with ARMedslack. I'm just waiting for an opportunity to test it on real hardware, but for the moment I'm running it on the Qemu ARM emulator.

Expect some posts on ARMed slack in the near future...


Wednesday, May 27, 2009

On partitioning your hard drive...

As I've been using Linux for over a decade, I am asked a lot of questions about my favorite operating system. I don't consider myself an expert, just an experienced enthusiast :-)

One question that pops up every now and then is about the "ideal" partitioning scheme for Linux.
The short answer is that there is no such thing as an "ideal partitioning scheme". It all depends on so many things, like:
- your hardware
- how you are going to use your system
- your future needs
- etc...

When a new Linux user asks me how to partition his new drive for Linux, I usually say that he should just use two partitions: one for swap and one for the rest. Yes, even with a 500+ GB drive...
Why? Because new users can get into trouble filling up a partition that was created too small and then things stop working.
Sometimes I get funny reactions like: "But I read that it is better to create a partition for /home, another for /usr/local etc...". And some even show expressions of disbelief...

But, since the question keeps coming back, I decided to write how I partition my system.
Like I said - it all depends... So the partitioning for my situation might not apply to yours, but reading through this post you might learn a thing or two.

First of all, I "don't do windows", so you won't read anything about how to double boot between Linux and Microsoft Windows, but basically you can just create an extra primary partition to waste some part of your hard disk and configure your preferred boot loader (Lilo or Grub) to access the alternative.

What follows is "the long answer" on partitioning your hard drive ;)

1. About types of partitions
Partitions come in two types: Primary and Extended. You can have a maximum of 4 partitions on one hard disk. But one of them can be of the "Extended" type, in which you can create several "Logical" partitions.

Remember this when you create your partitions, as you cannot transform a Primary in an Extended partition without backing up all your data, deleting the primary partition, creating the Extended and Logical partitions and then restoring your data.
After you created four Primary partitions, you're done... No way to go back without erasing!

2. The first partition - SWAP
The SWAP partition was originally invented to use as an overflow for your memory needs. If your system needs more memory than it has available, it starts "swapping" unused data from memory to this SWAP area. This was very common in the days when computers had less memory.
For the readers to have an idea: the first systems I worked with had 1 MB of RAM...
The old rule was that the SWAP partition should be twice the amount of RAM in your system.

Nowadays memory is cheap and plentiful in modern systems, so you might think you won't need a SWAP partition.
But don't just skip right now...
First of all, the SWAP partition is also used to 'hibernate' your system if it is capable of doing this (actually, I think *all* systems are capable, but normally only notebooks use this).
Hibernating simply saves all memory to the hard drive and reloads it when you reboot your system.
Guess where the memory is saved? Yes, on the SWAP partition.
So, despite the old rule, it should be at least the size of your RAM.
If you have like 4 GB of RAM, you won't need 8 GB of SWAP space. A SWAP partition of 4.1 GB is good enough.

If you use several Linux flavors on your system, you can have a single SWAP partition for all of them. Just remember you'll loose the 'hibernate' function if you reboot in a different flavor!

The SWAP partition is of the type "82" for those using fdisk under Linux.

3. The second partition - "root"
The "root" partition is the base (or 'root') of the hierarchical file system. It is mounted as "/" in Linux and from there you can go down the hierarchy to any folder or device.
The standard of how this hierarchy is set up is well defined in the Filesystem Hierarchy Standard (or FHS) for all Unix-like operating systems. You can read more on this standard here and here.
Unfortunately, not all Unix or even Linux flavors adhere 100% to the standard, but that's life...

The root partition is where the basic operating system is installed and all files needed to boot your system, get it connected to the network, etc., should be installed here.
Other files, like data, applications not needed for basic operations, user files, etc., can be on other partitions that are mounted later in the boot process.
The "/root" - the 'home' directory of the "root" user must be on the root partition to guarantee that root can login, even if the network is unavailable or external hard drives are not accessible.

Most modern Linux distributions are about 5 to 7 GB in size when fully installed.
To have some extra space, I usually create my root partitions with a size of 15 GB.

4. Extra "root" partitions
Why create extra root partitions? Because you might want to experiment with newer versions of programs, without messing up your working installation.
Or you might want to try out a completely different distribution of Linux for a change.
I personally keep three "root" partitions on my drive, but two should be enough in most setups.
If you make them 15 GB, like your first root partition, you should be ready for most installations.

5. The "/boot" partition
In Linux the /boot folder is used to store the kernel and the 'initrd' files. It is (normally, but do read on...) only used during the boot process.

Most people forget to make a separate partition for /boot. If you run only one installation of Linux on your system, that's fine. But if you plan to setup a multiple-boot system, with more than one Installation of Linux, possibly mixing different flavors, you might get confused when configuring your boot loader.

For instance, let's say you install Slackware and Ubuntu on your system.
From Slackware, you configure your /etc/lilo.conf to read the kernel from /boot/vmlinuz-xxxx
To include Ubuntu in your lilo menu, you would need define your image as /dev/sdxx/boot/vmlinuz-yyyy
And to make things worse, after booting Ubuntu, your /etc/lilo.conf there will have to be different, referring to the Slackware kernel as /dev/sdyy/boot/vmlinux-xxxx

To keep things simple, have a separate /boot partition on your drive that is accessible from all your Linux installations as /boot. Just take care to name your kernels in an organized way, so that you can remember which kernel belongs to which Linux distro.

Now you will still have several copies of your /etc/lilo.conf, as it stays on the root partition of your Linux installations.
I solved this by creating an /etc folder in /boot, where I put the lilo.conf file and then create a symbolic link in /etc with this command:
# ln -s /boot/etc/lilo.conf /etc/lilo.conf
This way I can edit my lilo configuration from any Linux installation and keep things simple.

As for the size of the /boot partition, I make it 250 MB and that has always been enough for me, even with several kernels from several concurrent installations.

6. The (optional) "/home" partition
The /home partition is the subject of many discussions. Each user on a Unix or Linux system has its own /home/<username> folder, accessible only to this user and the all-powerful root.
User-specific configuration files are stored there as well, mostly in hidden sub-folders like .mozilla, .mc, etc.
If your system is only going to have one user, you might as well store everything you want in your "home" folder. But if your system has several users that share files, it is not a good idea to store them here.

The /home partition also can cause problems if one specific user put a lot of files in his home folder, filling up the whole partition and effectively locking the system for other users that can't even save a simple configuration file. The solution to this problem is configuring a quota-system, but that is beyond the scope of this post.

As a simple rule, I create my /home partition with the size of (number of users) x 2 GB. That should be enough to save all configuration files. Shared data (downloaded MP3 files, pictures from digital cameras, etc.) go in a separate partition for data (just continue reading...)

7. The (optional) "/usr/local" partition
As I wrote above, I create my root partitions with the size of 15 GB. This is normally more than enough for a standard Linux installation plus several extra programs.
If you are installing a server with lots of local, non-standard (read: not provided by the standard installation of your Linux distribution) programs, you might want to create a /usr/local partition.

The size of this partition depends on your specific needs.

8. The (optional) "data" partition
Your desktop (or server) might contain data files you want to share with other users - locally or over the network.
I have seen many discussion on where these files should be saved on a Linux system.
Some prefer the "home" folder of the user, but then they will be available only to that particular user (unless you change the standard permissions, which is not a good idea).
Others prefer a special folder in the root directory, like "/data", "/photos", "/mp3", etc. I personally don't like this idea, as it goes against the FHS mentioned before.

In *my* opinion, data should be stored under /srv/xxxx, which is defined by the FHS as "site-specific data which is served by this system".
If you are sharing your pictures or mp3 files, you are "serving specific data" on your system.
So I mount my "data" partition on /srv/data with sub-folders like "pictures", "music", etc.

The size of this partition is limited by your hard drive only and your specific needs.

9. Final conclusions
Do not forget to define all your partitions in your /etc/fstab file to mount them at boot time.

And - I can't say this enough - it all depends on your needs.
You might not need all these partitions. You can very well survive with just a SWAP and a single root partition on a 1 TB drive. You just might encounter some problems when updating your system...

Labels: , ,

Saturday, May 2, 2009

Using SlackPkg on Slack/390

As promised in my previous post, some instructions to use SlackPkg in Slack/390 to keep your installation up-to-date.

After almost two years without activiry, the maintainers have released some patches / upgrades for Slack/390 - both the -stable and the -current versions.
Since I use SlackPkg on my other Slackware installations (12.1, 12.2 & -current), I wanted to use this same tool in my Slack/390 installation.

First i tried with the version that is included in /extra in Slack/390, but it is quite old (1.4, from 2005) and it simply didn't work.

The first problem is that the big majority of packages on the Slack/390 mirrors do not have the associated xxxx.tgz.asc file, which contain the GPG ckecksum of the package.
This was simple to resolve, setting CHECKGPG=off in /etc/slackpkg/slackpkg.conf

But the second problem I encountered was with the naming of some files on the Slack/390 mirrors that differs from the 'main' Slackware version:

  • The MANIFEST.bz2 files are called MANIFEST.s390.bz2 in Slack/390

  • The CHECKSUM.md5 files are called CHECKSUM.s390.md5 in Slack/390

  • The PACKAGES.TXT files are called PACKAGES.s390.TXT in Slack/390

  • The FILELIST.TXT file is called FILELIST.TXT.s390 (yes, at the end) in Slack/390

I remembered from the newer versions that there was an option for the 'architecture', so I decided to try SlackPkg 2.70.5 from slackware-12.2
It can be downloaded here or any valid Slackware mirror.
Since SlackPkg is written as a collection of scripts and marked as "noarch", I expected no problems.

So I downloaded the package, upgraded the 1.4 version with upgradepkg and edited /etc/slackpkg/slackpkg.conf
I commented out the 'standard' x86 architecture and uncommented the ARCH=s390 line.
But no luck yet... Still the same problems with the differences in the file names.

At this moment I reached the conclusion that I had to 'hack' the SlackPkg scripts to get it working.

I ended up modifying two files, /usr/bin/slackpkg & /usr/libexec/slackpkg/

The first patch is to the main slackpkg script and defines a variable 'subARCH' to insert the ".s390" text in the filenames in case the ARCH is s390:

--- slackpkg.orig 2009-04-10 23:44:49.000000000 -0300
+++ /usr/sbin/slackpkg 2009-04-10 23:57:28.000000000 -0300
@@ -40,6 +40,7 @@
SOURCE=$(grep -e "^\([a-z]\)" $CONF/mirrors)
. $CONF/slackpkg.conf
+[ "$ARCH" = "s390" ] && subARCH=".s390"
KERNELMD5=$(md5sum /boot/vmlinuz 2>/dev/null)
TMPDIR=$(mktemp -p /tmp -d slackpkg.XXXXXX 2>/dev/null || echo "FAILED")

The second patch is to the core-functions script and inserts the $subARCH variable in the filenames:

--- 2009-04-10 23:53:19.000000000 -0300
+++ /usr/libexec/slackpkg/ 2009-04-11 00:02:49.000000000 -0300
@@ -618,16 +618,16 @@
echo -e "\t\tList of all files"
- getfile ${i}/MANIFEST.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \
+ getfile ${i}/MANIFEST${subARCH}.bz2 $TMPDIR/${i}-MANIFEST.bz2 && \

echo -e "\t\tPackage List"

if [ "$CHECKPKG" = "on" ]; then
echo -e "\t\tChecksums"
+ getfile CHECKSUMS${subARCH}.md5 ${TMPDIR}/CHECKSUMS.md5

@@ -635,7 +635,7 @@
echo -e "\t\tPackage descriptions"
for i in $DIRS; do


With these changes, I got SlackPkg working in my Slack/390 installation!

There are still some problems, but they depend on some cleaning up of the Slack/390 mirrors.
In the following image you can see that SlackPkg wants to "upgrade" some packages to older versions:

The fact that SlackPkg want to "downgrade" itself to version 1.4 is understandable, as it is the official version for Slack/390.
The suggestions to downgrade abiword, gftp and gucharmap are caused by the fact that these packages exist two times on the mirrors, once in slackware/gnome (the older versions) and once in slackware/xap (the newer versions).
I wrote about these inconsistencies to but unfortunately have not received any answers yet.

Even with these minor problems, keeping your Slack/390 installation is a lot simpler now with a working SlackPkg!

Labels: , ,

Friday, May 1, 2009

Update on Slack/390

For those who have been following my posts on installing Slack/390 on Hercules:
There has been a security update this week - see the ChangeLog

I recently managed to patch a current version of SlackPkg to work on Slack/390 (the version included in /extra does not work).
I'll try to organize my notes during the following days and publish the patch so that everyone can keep Slack/390 updated with this wonderful tool :)

Labels: , ,