Re: #lfs-support IRC

On Thu, 2024-12-12 at 05:56 -0700, jeremy wiig wrote:
> It is clear the editors intend for the #lfs-support irc channel to be
> a place of condescension, denigration, fear, intimidation and
> cyberbullying. A typical interaction:
> --------------------------------------------------------------------
> newuser> are there instructions somewhere i missed for how recompiling
> the kernel for blfs works?
> newuser> also is there a specific place i'm supposed to put the kernel
> source instead of just "/sources"?

I normally use $HOME/sources.

> niceperson> why are you recompiling the kernel for blfs?
> newuser> i'm not yet, i'm just expecting i might want to
> niceperson> oh like upgrading the kernel? 
> newuser> i'm using LFS as a learning exercise, so i'm not sure what
> BLFS software i might eventually want to install
> niceperson> have you got a running LFS yet? 
> newuser> for this reason i also want to learn how the process of
> recompiling the kernel works for its own sake
> newuser> i haven't compiled the kernel the first time yet, so no
> niceperson> i have probably built and rebuilt the LFS dev version
> numerous times , each time fine tuning my scripts for automation, but
> there is the jhalfs if you really want 
>                    automate
> newuser> i'm using LFS as a learning exercise
> niceperson> some start with a slackware .config , or there is the
> fedora .config 

I don't think this is a good idea.  Say there are 10,000 different
hardware drivers, and your computer only needs 100 ones.  Then starting
from a major distro's .config, you'll need to either turn off 9,900
drivers (as a major distro must support different hardware
configurations), or wasting some CPU time to build unnecessary drivers.

Instead I start from a minimal config and just add the drivers needed in
menuconfig.

> newuser> i'm not planning on using this as a real system
> niceperson> copying that after the make mrproper

Or run "make oldconfig" if you've copied .config to /boot/config-
$version as the LFS book told.

However make mrproper also removes all compiled .o files, so you'd be
wasting CPU times on unnecessary rebuilding if running it.  Thus it's
better not to run it at all and the kernel build system does a good job
on only rebuilding the .o files necessary to be rebuilt.

Also I've proposed to remove make mrproper at all from the book several
years ago, because for all other packages we've been relying on the
package release manager to provide a clean tarball (i.e. we don't run
"make distclean" everywhere) and I'd prefer to make the kernel build
instruction consistent with all other packages on this prospective.

But I was told the kernel doc explicitly recommended (and likely, still
recommends today) to run make proper for a freshly extracted kernel
tree.

> newuser> my questions are 1. whenever BLFS says to recompile the
> kernel if necessary, does that include the mrproper step

No.  Just "make menuconfig" to modify the configuration, then "make".

> and 2. should the linux kernel source directory be anywhere in
> particular?

No, anywhere reasonable (for e.g. /tmp is unreasonable if you want to
keep the kernel source instead of deleting it).

> newuser> i became concerned because i learned that make mrproper also
> resets the kernel config
> newuser> and also i heard on a few places on the internet when i was
> trying to google about this some fuss about people putting the source
> directory in some spot or another and whether wherever it was is where
> it's "supposed" to be so
> i am also wondering if there's somewhere it's supposed to be

Many years ago (with Linux 2.x) people need to use /usr/src/linux as the
directory to support building out-tree modules, but today the out-tree
module build system refers the kernel source tree with the symlink
/lib/modules/$(uname -r)/build.  The "make modules_install" command
creates it, pointing to the kernel source tree.

Also (B)LFS does not supporting build out-tree modules, as the kernel's
internal API is deliberately unstable.

> niceperson> this could be a good read https://docs.kernel.org/
> niceperson> i had tryed /opt/source for my LFS source archives
> newuser> i'm assuming it's probably fine if the linux source is in
> /source like the other extracted tarballs, and that i can always move
> it later

It's perfectly fine, as long as you've made sure it owned by root as the
book says:

   In many cases, the configuration of the kernel will need to be updated
   for packages that will be installed later in BLFS. Unlike other
   packages, it is not necessary to remove the kernel source tree after the
   newly built kernel is installed.
   
   If the kernel source tree is going to be retained, run chown -R 0:0 on
   the linux-6.12.1 directory to ensure all files are owned by user root.
   
> cyberbully> best to config it once nad be done  enable what ya need
> for blfs
> cyberbully> and*

Well, not all people can anticipate the list of BLFS packages to be
installed before starting to read.  And maybe when you need to update a
package you find a new dependency with some kernel configuration
requirements...

> newuser> i'm also assuming that i should skip the mrproper step
> whenever i need to recompile, because not doing that would erase the
> configuration
> cyberbully> mrproper is always run every time a fresh untar is used
> newuser> i'm just a little nervous because the instructions aren't
> super clear about either topic
> cyberbully> right if you reuse the source again for a change/add  then
> no need
> cyberbully> the book isnt meant as a reference on kernel building
>  cmon
> newuser> i know lol
> cyberbully> you sound like ya dont know crap
> newuser> that's why i'm here, i'm working through LFS in order to
> learn the internals of a linux system
> cyberbully> lfs is written for experienced builders

I don't think it's correct.  I was not even close to "experienced" when
I built LFS first time in 2015.

> newuser> "One important reason for this project's existence is to help
> you learn how a Linux system works from the inside out. Building an
> LFS system helps demonstrate what makes Linux tick, and how things
> work together and depend on each other."
> cyberbully> right where does it say its for beginners
> cyberbully> and read the channel topic
> newuser> for the record i'm not a beginner, i've been daily driving
> fedora for a couple years now and i know pretty well how to use and
> debug a linux system
> cyberbully> thtas user level knowledge  not compiling source
> experience
> cyberbully> thats*
> niceperson> i would start by moving from fedora to either Arch or
> Gentoo as a daily

Arch is still a binary distro, thus there's no fundamental difference
from Fedora or Debian.  I'm not sure about Gentoo as I've not used it.

> newuser> which is why i'm asking specific sanity-check questions like
> "i've learned from reading the linux docs myself before even logging
> into the irc that make mrproper deletes the config file, so i assume
> i'm not supposed to do that?"

It would be better.

> newuser> as i've said, i want to learn how linux systems work
> internally, and i've mostly done that myself; i'm not interested in
> daily driving a fully custom linux system or automating the process,
> and that's because i know what i want, not because i don't know how to
> do things
> newuser> i understand that you guys must get a lot of confused noobs
> in these channels and that must be frustrating but i'm not
> appreciating the condescending tone
> niceperson> cause this is the support channel for the LFS book for
> questions regarding the building of the book, there is a separate
> channel #lfs for just chat

[email protected] may be better, but I'm not sure
(I don't monitor #lfs-support nor #lfs).

> cyberbully> too bad go get the compiling experience and then you'll
> understand my tone
> newuser> i asked two very specific questions and got chatter in
> response
> cyberbully> you got accurate explanations not chatter a-hole

No, I cannot see an explanation accurate enough.  At least nobody
explained make mrproper would likely waste a lot of build time, in
addition to just removing .config.

> cyberbully> care for  ban?
> newuser> i'm trying to meet you in the middle here
> newuser> you answered my first question, thank you for that
> cyberbully> you sound like a spoiled noob who expects to be catered to
>  
> newuser> now i'm just wondering if there's anywhere in particular the
> linux source tree should be
> niceperson> have you read this
> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
> newuser> i have, but thank you for reminding me
> niceperson> if you are building from source the LFS is what you make
> it, and how you build it yourself
> newuser> i will put it in /usr/src then

Hmm, FHS doesn't like this:

   Source code may be placed in this subdirectory, only for reference
   purposes. [37]

   [37] Generally, source should not be built within this hierarchy.
   
IIUC, FHS expects the user to cp -av the source tree (owned by root)
from /usr/src and build the package in the copy./

Just imagine the situation where two users are simultaneously
configuring the kernel in /usr/src/linux-6.12.1 and overwriting the
changes from each other... :(

Normally /usr/src is only writable by root, but building packages as
root is a really bad practice.  Strictly speaking, even in the LFS book
we shouldn't build packages as root, but building as an unprivileged
user would make the book too cumbersome.

> newuser> i'm not expecting to be catered to, you've answered my
> questions perfectly well enough, i'm just expecting not to be called
> stupid for asking for support in the support channel

I agree.

> newuser> but being that this is the support channel i'm not going to
> drag the topic out further
> newuser> thank you both for your help!
> --------------------------------------------------------------------
> Thank you for providing such a cold place where idiot noobs with their
> ridiculously stoopid questions can be quickly put in their place and
> sent packing.

So are we expected to ban "cyberbully" for some period of time?  Again
it has to be decided by some editor monitoring the channel.

-- 
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University

-- 
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page