Language Selection

English French German Italian Portuguese Spanish

Beyond Beyond Linux from Scratch (lfs - part3)

Filed under
Linux
HowTos
-s

In continuing with my Linux From Scratch series with Part 3, I present my adventures in setting up a more productive desktop system. Up until this point I have concentrated on just getting the basic underlying system in place and later installing X and a window manager. Today we strike out on our own some as we venture out of the docbook to go beyond Beyond Linux from Scratch.

Picking up where I left off last time, without kde's ksnapshot I was going to need some way to take screenshots. I remembered Imagemagick contains the "import" tool, but I also remembered scrot. Scrot is a small, easy-to-compile utility that would meet my needs. So, that was the route I took. Download giblib and scrot.

Then it's as simple as:

tar -zxvf giblib-1.2.4.tar.gz
cd giblib-1.2.4
./configure --prefix=/usr && make
su to root
make install

And do the same with scrot:

tar -zxvf scrot-0.8.tar.gz
cd scrot-0.8
./configure --prefix=/usr && make
su to root
make install

Then at the cli, one can take screenshots using a command something like this:
scrot -d 6 desktop.jpg

In this example the option "-d" is delay in seconds. My command delays taking the screenshot for 6 seconds, giving one time to open menus or whatever.

My friend wrote me on the day, actually right about the same time, I published my LFS: Part 2 and sent screenshots of a window manager he installed probably more as a joke than anything. To his surprise I wrote back and said "how cuuute!" I had fluxbox installed already, but my next course of action was to install Equinox Desktop Environment. I googled for the site and downloaded the required library and ede packages. I followed the Installation How-to and they installed in about 5 minutes with no issue. And I can really say that I'm enjoying it. To make icons, one right clicks the desktop, chooses "New desktop item" and fills in the blanks. Ede comes with a few icons in it's package, so that's handy. To set a wallpaper, right click the desktop and choose "Background Settings," and browse to the desired wallpaper. Of course it has all these menu entries for which I don't have applications. Big Grin Actually a few have the corresponding apps and I installed a few. But just when I was thinking "if it just had some other desktops..." I find it does. In the panel there's an icon of an indistinguishable image that allows one to choose another desktop. I find that a little inconvenient as one has to click twice to reach the other desktop, but at least it's there. Included are settings for the fonts, colors and windecs. There are
other themes on the website.

So, for a nice little light desktop that takes about 5 minutes to
install:

Download: the efltk library and the Equinox Desktop Environment package.

tar -jxvf efltk-2.0.5.tar.bz2
cd efltk-2.0.5
./configure --prefix=/usr --disable-mysql --disable-unixODBC --enable-xft && make
su to root
make install

tar -jxvf ede-1.0.4.tar.bz2
cd ede-1.0.4
./configure --prefix=/usr && make
su to root
make install

Then either type:
/usr/X11R6/bin/xinit /usr/bin/startede
or put startede in your ~/.xinitrc file to start it.



        

        

        

        



In case you noticed in my screenshots the output of:


configuration error - unknown item 'OBSCURE_CHECKS_ENAB' (notify administrator)
configuration error - unknown item 'CRACKLIB_DICTPATH' (notify administrator)
configuration error - unknown item 'PASS_CHANGE_TRIES' (notify administrator)
configuration error - unknown item 'PASS_ALWAYS_WARN' (notify administrator)

That's one little bug to which I hadn't paid too much attention at the time of my last write up, but it's easily fixed by editing out those lines in the /etc/login.defs file, as those functions are now handled by PAM. They're harmless and I'd been too lazy to fix it before the screenshots and now I'm too laz...er... busy to redo the screenshots. Big Grin

Next order of business was setting up a word processor or office application. My sources directory had become quite large and at this point I found I was going to have to delete what was in it. Freeing up over 3 GB, I preceded with the download of latest version of OpenOffice.org at the time - beta 2 of 2.0. But what a mess I found. The binary package was all rpms at the time and source package was about 100 different directories with no central configure script or makefile. I wasn't about to spend all day cd into each of those and doing the dance, so I downloaded the 30-day trial of TextMaker. I really like this program, too bad it costs 50 bucks. And of course I have vim and nano installed, so hopefully by the time the textmaker trial is up, OpenOffice.org will have a decent package for us who don't have rpm installed. The installation of TextMaker is simply a matter of untaring/uncompressing the downloaded tar.gz into our directory of choice and the start binary is called tml. So unless you put that directory in your path, you will need the full command to start it.

For example in my case that would be:

/usr/local/textmakertrial/tml.

...Or actually I made a desktop icon to that for me. FYI, the BLFS handbook does contain full instructions for installing OpenOffice-1.1.4.

I soon grew tired of the little xterm and decided it was time to install Eterm. It was merely a matter of installing libast and then Eterm. No problems there and now I could use my "myeterm" script to which I've grown quite spoiled. Eterm is my favorite terminal emulator because you can customize it so easily. If you wish to use Eterm:

download: the libast library and

tar -zxvf libast-0.6.1.tar.gz
cd libast-0.6.1
./configure --prefix=/usr && make
su to root
make install

download: Eterm and

tar -zxvf Eterm-0.9.3.tar.gz
cd Eterm-0.9.3
./configure --prefix=/usr && make
su to roo
make install

The command I use to start mine so that it'll look like the terminal is running on the background (transparent with no windec or scrollbars etc.) is this:
Eterm --trans -g 75x25 -f white -F '-*-lucidatypewriter-medium-r-normal-sans-16-*-*-*-*-*-*-*' -O --tint=#ffffff --shade 0 --borderless --scrollbar-popup --scrollbar-floating --scrollbar no --double-buffer -a "toggles buttonbar false"

If you are like me, there is nothing more annoying than booting a system to do some work and notice that your time is off by 15 minutes or even 6 hours. There should be a law against an OS changing anything in the bios!!! This is another petpeeve of mine. To quietly handle this problem, I enlist the services of ntpdate. The instructions for installing NTP-4.2.0 are included in the BLFS docbook and work quite well. Follow those, and then instead of running the ntpd all the time, we can just use the included utility ntpdate. You can run ntpdate as a stand alone command any time you wish in any terminal, set it up to run periodically as a cron job, or as I do as a boot time service. After your ntp package install, forego the configuration instructions unless
you're needing to supply time service to your network. Instead:

nano /etc/rc.d/init.d/ntpdate
and simply type and save as root:

/usr/sbin/ntpdate -b time.nist.gov

Then as root issue the following commands to make it executable and run at boot:

chmod ug+xr /etc/rc.d/init.d/ntpdate
ln -s /etc/rc.d/init.d/ntpdate /etc/rc.d/rc3.d/S22ntpdate

You may even wish to adjust your bios time, and in which case you can add on the next line in your /etc/rc.d/init.d/ntpdate file:

/sbin/hwclock --systohc

The -b switch tells ntpdate to use 'settimeofday' instead of the 'adjtime', which I'm convinced is a curse from satan himself (no hate mail please). And the --systohc for hwclock tells it to set the bios time to our new adjusted system time.

For image manipulation, Gimp is outlined in the BLFS docbook, but if you follow it word for word, it won't be able to decode jpegs. So, modify their suggestions to:

./configure --prefix=/usr --sysconfdir=/etc --disable-print && make

And as a bonus, the menu entry in Ede now works. Big Grin

Some other applications from the BLFS docbook one might need are: unzip, which, and openssh. The instructions work well for these.

For a backup and the availability of xffm, I decided to include xfce4 as well. For the sake of brievity I don't think I'll outline each and every command used, as this is quite a collection of modules. However, download the xfce4 package. With the xfce4 package uncompressed you will find many directories containing the required library and base install as well as the different modules that you might like. Just cd into each one of interest and do the configure, make, make install routine. A graphical installer is available as well, although it installs an older version and the site is in German.

    

I use bash for my file manager, but it's always nice to have a graphical version available. A real nice and extremely useful one is emelfm. You can download it here. Installation is easy peasy, just

tar -zxvf emelfm-0.9.2.tar.gz
cd emelfm-0.9.2
make
su to root
make install

Note however, the executable will be located in /usr/local/bin.

So at this point we have our basic system with X and nvidia graphic drivers, three window managers from which to choose, xffm and emelfm for file management, mozilla and opera for browsing, news and email, feh, iv, and gimp for image viewing and manipulation, and TextMaker, vim, and nano for publishing and editing. Next is multimedia. <deep breath>

    

You may not know this about me, but I have to have xawtv. I've tried a lot of tv applications over the years, but none stack up to the stability and resource overhead of xawtv. So the next order of business was installing xawtv. This isn't the daunting task it once was before the kernel included bttv drivers. Now it's just simply a matter of enabling support in the kernel and installing xawtv. Xawtv is a fairly straight forward compile. Download: xawtv and tv-fonts.

tar -jxvf tv-fonts-1.1.tar.bz2
cd tv-fonts-1.1
./configure --prefix=/usr && make
su to root
make install

then:
tar -zxvf xawtv-3.94.tar.gz
cd xawtv-3.94
./configure --with-x --enable-gl --enable-quicktime -with-xvideo
--with-alsa --prefix=/usr && make

su to root and make install.

You'll need a configuration file, ~/.xawtv, and if you don't have one, here's an exerpt of mine for an example:

[global]
freqtab = us-cable

[defaults]
input = Television
norm = NTSC

[WKRN (2)]
channel = 2

[VMP (3)]
channel = 3

[WSMV (4)]
channel = 4

[WTVF (5)]
channel = 5

That was the easy one. Next I require mplayer, and I require mplayer to play anything it encounters. In the old days that meant downloading all the libraries and codecs from many many sources and reading a long doc to get all the flags to use during compile time. This became obsolete with distros like pclos, gentoo, and some others. All this to say, I'm a little rusty in this area. But thankfully the BLFS has the instructions in their docbook and a lot of the codecs are bunded together in one (or two) package(s). And of course, it went without a hitch. Using the information in the instruction I can now watch any movie file I run into.

    

Also included in the multimedia section of the docbook are xmms and cdrecording applications and tools. At the risk of repeating myself, the instructions work wonderfully in these areas as well and I recommend just following the instructions.

As of now, I have a fairly complete system all compiled from scratch and taking up about 1.3 gig of space. It boots in less than 30 seconds and performs very well. It's fast and stable. More than that is the satisfaction and sense of accomplishment that can come from completion or near completion of a daunting task. I found the whole experience quite fullfilling, educational and fun. I can't encourage you enough to visit the Linux from Scratch website and download your instruction book today.

Part 2
Part 1

Excellent series

Thanks for the LFS/BLFS/BBLFS series. They were very informative and makes me want to try it again. I did get a basic LFS up and running two years ago, but never went beyond mainly because the computer I was playing with is a P2 300 Sad Time to convince the wife that we really could use new computers Wink

re: Excellent series

Why thank you kind sir for your nice words. It was really quite a bit of work, but it was a labor of love - not done for the sake of an article (or 3). Big Grin

I know what you mean about the slower computers, I put gentoo on a p150 about 18 months ago and well, it don't get updated too often. Tongue

----
You talk the talk, but do you waddle the waddle?

re: comparison

Well, I'd say that gentoo is much easier in that it does all the grunt work for you. If I want an application/package in gentoo I type emerge <application> and it handles all the downloading and installing of dependencies as well as the compile and install. And their repository is so huge, I've rarely searched for something and it not be in gentoo's portage. Although some packages I prefer to do on my own, KDE being one of them, I can still get the dependencies installed through portage. For the source-based distro fan, it's like having your cake and eating it too. Fortunately the lfs/blfs docbooks lists dependencies and provides links, and that helps big time.

As far as kde not being installed on my LFS, I was being lazy or in too bigga hurry I guess. KDE itself is a fairly easy compile usually, but it does have a lot of dependencies and can take quite a bit of time. Yes, mozilla/firefox and opera were shortcuts to getting on the internet. The BLFS docbook contains instructions for kde and gnome.

----
You talk the talk, but do you waddle the waddle?

Part 4 Perhaps? :)

Hi!

First off, great review regarding LFS!

I know it's been quite some time since your last review/reply to comments here. I've wondered how goes the LFS install?

Have you continued to tweak it, expand on the package? I've wondered if you kept it around, played with it, and, or, made it a part of your everyday computing experience Smile

I'll try not to date myself heavily here, I started way-way back with only a CLI learning basic/basica and dabbled in assembly. Through that time I went from dos/unix/posix/windows/linux (variations ie: DosLinux) and I always found myself coming back to Linux in one flavour or another.

Recently, the last year or so I've found myself totally going over to Linux. I missed the CLI environment and feel of yesteryear..lol With that I've been put off in a sense with many of the distributions and such that just seem to weigh down a really top-notch OS such as Linux. I stumbled across LFS somehow, who knows, and now my son and I (he's 14, yes I'm old) have a bit of a competitive project going on. We're both currently working on building the base LFS system then we're going to migrate to BLFS as well and see who's system is the best in functionality and asthetics, but not only that, we'll both be taking a step neither of us ever considered and it's kind've added another new excitement to beyond computing in general Smile

Your review was just what I was looking for and should've read it beforehand. It's helped a lot seeing someone successfully complete the process and give it a very decent pat on the back.

Thanks for taking the time to review it, and thanks for reading this rather lengthy comment Smile

Take Care!

re: Part 4 Perhaps? :)

Um, no I haven't kept it up. I played with it for a few months adding features and stuff, but I didn't implement one of the package management ideas and soon just quit messing with it. If I hadn't already been settled into Gentoo I might have made it my permanent system. It's a very cool project for sure. I surely enjoyed setting it up.

Thanks for your visit and comments. I might look around and see if I still have it around here somewhere and if it can be saved.

LFS or Arch Linux

Hi, Im reading this exellent review of LFS, because I have just downloaded liveCD of LFS. Im new to Linux, about four months, I have passed through few distros: Fedora, Ubuntu, and Slackware, ending up with Mint and Arch Linux. I wonder if you could compare LFS with Arch, witch I enjoy very much for its simplicity, speed, and the pacman command. But, Im thinking to give LFS a try, although some say that LFS is not good as distro for daily use, but just as learning experience to know Linux better.
Blessing.

re: LFS or Arch Linux

Well, I really couldn't compare LFS with anything else - not even Gentoo. Although Gentoo would probably be the closest. Arch is a binary distro with a great commandline package manager. LFS didn't have a package manager last I messed with it. There were methods of managing packages, but the user had to sorta build it from scratch. Big Grin

There's no reason why LFS couldn't be fine for an everyday desktop if that's what you wanted to do. If so, perhaps you might want to look into some of those described package management solutions.

Go ahead and go for it. I don't know how you have your disk partitioned, but I suggest slicing it up into several partitions so that you can play with one distro while keeping one or two intact for daily use.

LFS or Arch Linux

Hi,
thanks a lot for this fast reply. Yes. I will take your advice about partitioning. I wonder why there are so few good reviews of LFS. The more your afford is appreciated. Take care.

The nice thing about LFS

The nice thing about LFS is that you can always install any package manager including pacman, make packages and even start your own distribution.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Games: Surviving Mars and OpenMW

Kernel and Security: BPF, Mesa, Embedded World, Kernel Address Sanitizer and More

  • Concurrency management in BPF
    In the beginning, programs run on the in-kernel BPF virtual machine had no persistent internal state and no data that was shared with any other part of the system. The arrival of eBPF and, in particular, its maps functionality, has changed that situation, though, since a map can be shared between two or more BPF programs as well as with processes running in user space. That sharing naturally leads to concurrency problems, so the BPF developers have found themselves needing to add primitives to manage concurrency (the "exchange and add" or XADD instruction, for example). The next step is the addition of a spinlock mechanism to protect data structures, which has also led to some wider discussions on what the BPF memory model should look like. A BPF map can be thought of as a sort of array or hash-table data structure. The actual data stored in a map can be of an arbitrary type, including structures. If a complex structure is read from a map while it is being modified, the result may be internally inconsistent, with surprising (and probably unwelcome) results. In an attempt to prevent such problems, Alexei Starovoitov introduced BPF spinlocks in mid-January; after a number of quick review cycles, version 7 of the patch set was applied on February 1. If all goes well, this feature will be included in the 5.1 kernel.
  • Intel Ready To Add Their Experimental "Iris" Gallium3D Driver To Mesa
    For just over the past year Intel open-source driver developers have been developing a new Gallium3D-based OpenGL driver for Linux systems as the eventual replacement to their long-standing "i965 classic" Mesa driver. The Intel developers are now confident enough in the state of this new driver dubbed Iris that they are looking to merge the driver into mainline Mesa proper.  The Iris Gallium3D driver has now matured enough that Kenneth Graunke, the Intel OTC developer who originally started Iris in late 2017, is looking to merge the driver into the mainline code-base of Mesa. The driver isn't yet complete but it's already in good enough shape that he's looking for it to be merged albeit marked experimental.
  • Hallo Nürnberg!
    Collabora is headed to Nuremberg, Germany next week to take part in the 2019 edition of Embedded World, "the leading international fair for embedded systems". Following a successful first attendance in 2018, we are very much looking forward to our second visit! If you are planning on attending, please come say hello in Hall 4, booth 4-280! This year, we will be showcasing a state-of-the-art infrastructure for end-to-end, embedded software production. From the birth of a software platform, to reproducible continuous builds, to automated testing on hardware, get a firsthand look at our platform building expertise and see how we use continuous integration to increase productivity and quality control in embedded Linux.
  • KASAN Spots Another Kernel Vulnerability From Early Linux 2.6 Through 4.20
    The Kernel Address Sanitizer (KASAN) that detects dynamic memory errors within the Linux kernel code has just picked up another win with uncovering a use-after-free vulnerability that's been around since the early Linux 2.6 kernels. KASAN (along with the other sanitizers) have already proven quite valuable in spotting various coding mistakes hopefully before they are exploited in the real-world. The Kernel Address Sanitizer picked up another feather in its hat with being responsible for the CVE-2019-8912 discovery.
  • io_uring, SCM_RIGHTS, and reference-count cycles
    The io_uring mechanism that was described here in January has been through a number of revisions since then; those changes have generally been fixing implementation issues rather than changing the user-space API. In particular, this patch set seems to have received more than the usual amount of security-related review, which can only be a good thing. Security concerns became a bit of an obstacle for io_uring, though, when virtual filesystem (VFS) maintainer Al Viro threatened to veto the merging of the whole thing. It turns out that there were some reference-counting issues that required his unique experience to straighten out. The VFS layer is a complicated beast; it must manage the complexities of the filesystem namespace in a way that provides the highest possible performance while maintaining security and correctness. Achieving that requires making use of almost all of the locking and concurrency-management mechanisms that the kernel offers, plus a couple more implemented internally. It is fair to say that the number of kernel developers who thoroughly understand how it works is extremely small; indeed, sometimes it seems like Viro is the only one with the full picture. In keeping with time-honored kernel tradition, little of this complexity is documented, so when Viro gets a moment to write down how some of it works, it's worth paying attention. In a long "brain dump", Viro described how file reference counts are managed, how reference-count cycles can come about, and what the kernel does to break them. For those with the time to beat their brains against it for a while, Viro's explanation (along with a few corrections) is well worth reading. For the rest of us, a lighter version follows.

Blacklisting insecure filesystems in openSUSE

The Linux kernel supports a wide variety of filesystem types, many of which have not seen significant use — or maintenance — in many years. Developers in the openSUSE project have concluded that many of these filesystem types are, at this point, more useful to attackers than to openSUSE users and are proposing to blacklist many of them by default. Such changes can be controversial, but it's probably still fair to say that few people expected the massive discussion that resulted, covering everything from the number of OS/2 users to how openSUSE fits into the distribution marketplace. On January 30, Martin Wilck started the discussion with a proposal to add a blacklist preventing the automatic loading of a set of kernel modules implementing (mostly) old filesystems. These include filesystems like JFS, Minix, cramfs, AFFS, and F2FS. For most of these, the logic is that the filesystems are essentially unused and the modules implementing them have seen little maintenance in recent decades. But those modules can still be automatically loaded if a user inserts a removable drive containing one of those filesystem types. There are a number of fuzz-testing efforts underway in the kernel community, but it seems relatively unlikely that any of them are targeting, say, FreeVxFS filesystem images. So it is not unreasonable to suspect that there just might be exploitable bugs in those modules. Preventing modules for ancient, unmaintained filesystems from automatically loading may thus protect some users against flash-drive attacks. If there were to be a fight over a proposal like this, one would ordinarily expect it to be concerned with the specific list of unwelcome modules. But there was relatively little of that. One possible exception is F2FS, the presence of which raised some eyebrows since it is under active development, having received 44 changes in the 5.0 development cycle, for example. Interestingly, it turns out that openSUSE stopped shipping F2FS in September. While the filesystem is being actively developed, it seems that, with rare exceptions, nobody is actively backporting fixes, and the filesystem also lacks a mechanism to prevent an old F2FS implementation from being confused by a filesystem created by a newer version. Rather than deal with these issues, openSUSE decided to just drop the filesystem altogether. As it happens, the blacklist proposal looks likely to allow F2FS to return to the distribution since it can be blacklisted by default. Read more

gitgeist: a git-based social network proof of concept

Are you tired of not owning the data or the platform you use for social postings? I know I am. It's hard to say when I "first" used a social network. I've been on email for about 30 years and one of the early ad-hoc forms of social networks were chain emails. Over the years I was asked to join all sorts of "social" things such as IRC, ICQ, Skype, MSN Messenger, etc. and eventually things like Orkut, MySpace, Facebook, etc. I'll readily admit that I'm not the type of person that happily jumps onto every new social bandwagon that appears on the Internet. I often prefer preserving the quietness of my own thoughts. That, though, hasn't stopped me from finding some meaningfulness participating in Twitter, Facebook, LinkedIn and more recently Google+. Twitter was in fact the first social network that I truly embraced. And it would've remained my primary social network had they not killed their own community by culling the swell of independently-developed Twitter clients that existed. That and their increased control of their API effectively made me look for something else. Right around that time Google+ was being introduced and many in the open source community started participating in that, in some ways to find a fresh place where techies can aggregate away from the noise and sometimes over-the-top nature of Facebook. Eventually I took to that too and started using G+ as my primary social network. That is, until Google recently decided to pull the plug on G+. While Google+ might not have represented a success for Google, it had become a good place for sharing information among the technically-inclined. As such, I found it quite useful for learning and hearing about new things in my field. Soon-to-be-former users of G+ have gone in all sorts of directions. Some have adopted a "c'mon guys, get over it, Facebook is the spot" attitude, others have adopted things like Mastodon, others have fallen back to their existing IDs on Twitter, and yet others, like me, are still looking. Read more