You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

We released coreutils-8.11 less than two weeks ago.
Why a new release so soon? Because under unusual conditions,
coreutils-8.11's copying code could cause trouble. Data loss trouble.
The trouble could arise only when these conditions are all met:
- when using linux-2.6.39-related kernels (including at least -rc3) and
- using an xfs file system and
- copying (via cp, install, mv) a file with a so-called "unwritten
extent" shortly after it has been created, yet before some
data in that unwritten extent has made it to disk.
This would happen if you're using the "gold" linker, which
preallocates using fallocate and then writes its output
(the binaries) into those unwritten extents, and you then
immediately copy those binaries into place via "make install".
Under those conditions, just building coreutils and running "make
install" quickly enough after compile and link would result in
installing files containing all 0 bytes.

See the commit logs for links to plenty of discussion.
See the NEWS below for a brief summary.

To reduce load on the main server, use a mirror listed at:http://www.gnu.org/order/ftp.html
[*] You can use either of the above signature files to verify that
the corresponding file (without the .sig suffix) is intact. First,
be sure to download both the .sig file and the corresponding tarball.
Then, run a command like this:

gpg --verify coreutils-8.12.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 000BEEEE

and rerun the `gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.68.71-af300
Automake 1.11a
Gnulib v0.0-5115-ga81348d
Bison 2.4.588-2f658

cp's extent-based (FIEMAP) copying code is more reliable in the face
of varying and undocumented file system semantics:
- it no longer treats unwritten extents specially
- a FIEMAP-based extent copy always uses the FIEMAP_FLAG_SYNC flag.
Before, it would incur the performance penalty of that sync only
for 2.6.38 and older kernels. We thought all problems would be
resolved for 2.6.39.
- it now attempts a FIEMAP copy only on a file that appears sparse.
Sparse files are relatively unusual, and the copying code incurs
the performance penalty of the now-mandatory sync only for them.

cp's extent-based (FIEMAP) copying code is more reliable in the face
of varying and undocumented file system semantics:
- it no longer treats unwritten extents specially
- a FIEMAP-based extent copy always uses the FIEMAP_FLAG_SYNC flag.
Before, it would incur the performance penalty of that sync only
for 2.6.38 and older kernels. We thought all problems would be
resolved for 2.6.39.