fsuk-manchester
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fsuk-manchester] Follow-up: MFS Meeting. Tue, 20 March. "GNU/Linux-libr


From: Michael Dorrington
Subject: [Fsuk-manchester] Follow-up: MFS Meeting. Tue, 20 March. "GNU/Linux-libre from scratch - start"
Date: Sun, 25 Mar 2018 22:53:26 +0100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

It was good to see everyone bringing laptops and giving GNU/Linux-libre
a try.

Book (we are doing version 8.2, current stable):

* http://linuxfromscratch.org/lfs/

Linux-libre (remember to download this, the book uses non-free Linux):

*
https://linux-libre.fsfla.org/pub/linux-libre/releases/4.15.3-gnu/linux-libre-4.15.3-gnu.tar.xz
*
https://linux-libre.fsfla.org/pub/linux-libre/releases/4.15.3-gnu/linux-libre-4.15.3-gnu.tar.xz.sign


Some tips on doing GNU/Linux from scratch:

1. Use the HTML version of the book, not the PDF version.  With the HTML
version you can copy & paste the commands, even multi-line commands.
With the PDF version there are copying issues with multi-line entries,
has formatting errors and the page breaks during command blocks can be
confusing.

2. Read the book from the beginning.  It has important information early
on that isn't repeated later on.

3. Don't worry about whether to build 32-bit or 64-bit system, just
build default of your host system.  Unless you really know what you are
doing.

4. It is very important that the environment variable LFS is set and
exported, keep checking with:

printenv LFS

and, when needed,

printenv LFS_TGT

5. Partitioning.  This is something that should be thought about, not
rushed as mistakes can wipe your system.  Doing this during the talk is
not a good idea!  While still being careful, you can build in a
partition that might not be the final place you want as you can still
move by tar and untar until near the very end.

And I recommend a separate `/boot` (as does the book).

6. The book uses some shell techniques people aren't used to.  This, I
think, is to stay in the shell command line and perhaps to show off what
the shell can do.

The bit where is says:

time { ./configure ... && ... && make install; }

actually means put the 'configure', 'make' and 'make install' lines
inside the curly braces.  Which ends up looking something like:

time {
../configure --prefix=/tools            \
             --with-sysroot=$LFS        \
             --with-lib-path=/tools/lib \
             --target=$LFS_TGT          \
             --disable-nls              \
             --disable-werror &&
make &&
case $(uname -m) in
  x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
esac &&
make install
}

But really you only need the 'configure' and 'make' to get an idea of
the SBU time.
If you don't put the end curly bracket on a newline then you need a
semi-colon after the last command.

What are the curly brackets doing?  They are a "Block of Code" aka
"inline group", which basically is just grouping several commands
together so, in this case, they can be timed all as one.  For more info:

http://www.tldp.org/LDP/abs/html/special-chars.html#CODEBLOCKREF

Another shell feature that confused people was the use of '<<' for example:

cat > ~/.bash_profile << "EOF"

This is a "here document" aka "here doc".  Basically, in the above, the
command takes input until it sees EOF only on a line on its own.  As far
as the shell is concerned the EOF has no other special meaning, anything
could be used as long as you close with it.  And you don't need the
quotes around EOF.  More info:

http://www.tldp.org/LDP/abs/html/here-docs.html

Other commands that caused confusion were pushd and popd.  They are
commands for changing directories but make use of a stack.  The 'pushd'
command changes directory but also pushes original directory to the top
of the stack and 'popd' takes the top directory off the stack and
changes to it.  These commands are often used in building software as it
involves traversing around directories.

7. /bin/sh being Bash.  The books says /bin/sh of the host should be
Bash (well, is tested with this) but in most modern systems it will
likely be Dash.  If a package fails to build because it expects /bin/sh
to be Bash then this is a bug; the package should use /bin/bash if it
wants Bash.  I'm going to build with /bin/sh being Dash.  If you want
`/bin/sh` to be Bash then options include:

* `dpkg-reconfigure dash`
** You need to understand the implications!
* `switchsh` program/package
** Haven't tried but can make /bin/sh be Bash for LFS builds only

8. Package download security.

* Nearly all the download URLs can use https even though listed as http.
** Try https!
* Nearly packages have .sig files that can be downloaded as well.
** Download and check sigs.
* Don't download packages on public Wi-Fi.

9. Keep a note of where you're up to otherwise it easy to get lost and
forget what you have and haven't done.

Right, think that's it!

I'll post my progress as I go and we'll finish off at the next meeting.
This will probably be how to get the system booting and where to go from
when the system is up.

M.

-- 
FSF member #9429
http://www.fsf.org/register_form?referrer=9429
http://www.fsf.org/about
"The Free Software Foundation (FSF) is a nonprofit with a worldwide
mission to promote computer user freedom and to defend the rights of all
free software users."


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]