Hi there, I don't know if anybody else has been having problems that I've been having, but anyways here's the solution to my problem. Now I'm new to the
BackTrack Linux distribution, but have been using Linux for quite a long time so when I encountered a problem I always try to find a solution.
So what was my problem you ask? Well after doing some reading about BackTrack and it's roots to the Slax distribution I discovered the powerful modularity of the distribution using the lzm modules. So I started customizing my new Thumb Drive with the BackTrack distro installed on it and I ran into problems loading the modules.
Loading the modules created with
dir2lzm at boot time worked like a charm, but when I tried to load them using the
activate and
uselivemod utilities the problems started. For some weird reason they didn't want to load, which for me was really odd because the same modules when located in the
BT3/modules directory at boot time loaded just fine. So the first thing I did is searched and searched the BackTrack forums and didn't find any solutions to the problem other than placing them in the modules directory and letting the boot process taking care of the loading. Maybe the answer actually was somewhere in the forums but I was tired of searching. After retracing the entire boot process I found the
liblinuxlive script file is used to manage the modularity of the system.
The
liblinuxlive file is basically a library of utility functions used for the mounting of modules. This library is also used by the
uselivemod and
activate utilities. I looked at these 2 scripts and found the functions which were failing, then I traced the point of origin of the error to the mount_device function. The error was located in the mount command, which failed with a exit code of 32 which meant a mount failure. I tried different types of variation of the mount command used in the script but they all failed. Finally I got fed up and did a strace on the mount command and found that it was failing on the filesystem detection. Now because the system is built to be modular, all the mount commands do not specify a file system type, so the mount command is left to determin filesystem.
Mount uses 2 methods of detecting the filesystem either using
blkid(libuuid) or the
/etc/filesystem file. The first method was failing so mount reverted to the
/etc/filesystem method of dectection, now because this file does not exist in the distribution, mount uses the
/proc/filesystem file. The order of the filesystem types in the filesystems file is the order in which mount tries to detect the filesystem type of the device/file being mounted.
Knowing this this and knowing that the lzm module is a squashfs type filesystem I looked at the
/proc/filesystems file and found that it's almost at the end of the file. So somewhere in between the start of the file and the location of the
squashfs line, mount is failing. Looking at the strace ouput I found that the place which its failing on is the
gfs2(RedHats distributed file system for clusters) filesystem type. The error that mount was displaying was the following:
Code:
mount: No buffer space available
and was due to this gfs2 filesystem test.
And so to successfully load a module using the
activate or
uselivemod utilities you have to relocate the squashfs line before the gfs2 filesystem line. Because I like the modularity and want to have an unmodfied distribution a created the following little script which places the squashfs line at the begining of thefile.
Code:
cat /proc/filesystems | grep -v nodev | grep squashfs > /etc/filesystems
cat /proc/filesystems | grep -v nodev | grep -v squashfs >> /etc/filesystems
This little script is then packed into lzm module which is loaded automaticaly at system boot(rc.local).
I hope this info helps someone out, and sorry for the lengthy explanation.