Re: [lfs-support] Compiling gcc-4.9.2 from 7.7 without CMOV

[Michael Shell]

On Fri, 9 Apr 2021 10:46:30 -0400
Chris Fowler  wrote:

> I am fully aware that other OSS packages could use CMOV with inline
> assembly.  I'm just wanting GCC to forget it even exists when it tries to
> implement CMOV during -03 optimization.


I think the most correct approach for your CPU is just to invoke

-march=i586

to avoid the use of CMOV:

https://clfs-support.cross-lfs.narkive.com/x1E4tLvU/i586-target-with-cmov

This page might also be of help:
https://stackoverflow.com/questions/60837883/removing-cmov-instructions-using-gcc-9-2-0-x86
which suggests adding the options (if you can't/don't use -march=i586)

-fdisable-tree-phiopt[1-4] and -fdisable-rtl-ce[1-3] 

Note that there is a -mno-cmov for gcc, but that only seems to be available
for the NDS32 platform:

https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/Option-Summary.html

Sigh.


   Cheers,

   Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom

[Michael Shell]

On Wed, 27 Jan 2021 11:42:27 -0600
Bruce Dubbs  wrote:

> Very interesting.  Thanks for the report.


Ditto that. I'm sure it will help a lot of folks in the future.

Thanks Steve!


  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 10.0 build on USB

[Michael Shell]

On Sun, 27 Dec 2020 04:08:19 + (UTC)
Kevin Liu  wrote:

> and a grub-img.iso was created. However, even though the grub.cfg was
> in the lfs /boot/grub/ directory, it was not included in the iso
> /boot/grub/, as shown below in red.


  Kevin,

Reading

https://www.gnu.org/software/grub/manual/grub/html_node/Making-a-GRUB-bootable-CD_002dROM.html

it seems that you have to create and populate an extra directory
to get such files included:

mkdir iso
mkdir -p iso/boot/grub
< create/copy the desired grub.cfg in iso/boot/grub >
grub-mkrescue -o grub.iso iso


  Cheers,
  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom

[Michael Shell]

On Sun, 26 Apr 2020 23:53:12 +0200
Stephen Berman  wrote:

> As noted in my reply to Ken, I couldn't cleanly revert the commit in
> recent mainline or stable kernel sources.


If it were me, in this case, I would even consider manually editing
the code. It might come to that to find out exactly where the problem
is.

In anycase, please do report this issue to the kernel developers
and do let us know if you ever find out what the problem was.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom

[Michael Shell]

On Sun, 26 Apr 2020 00:33:42 +0200
Stephen Berman  wrote:

>  kernel/sched/core.c
>  kernel/workqueue.c
>  kernel/workqueue_internal.h
>  3 files changed, 48 insertions(+), 99 deletions(-)


Interesting. A search revealed that a kernel automated test robot flagged
a bug in that commit:

https://lore.kernel.org/lkml/20200327074308.GY11705@shao2-debian/

which resulted in this discussion:

https://lore.kernel.org/lkml/20200327175350.rw5gex6cwum3o...@linutronix.de/

about a race condition.

The end result was this patch:

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=62849a9612924a655c67cf6962920544aa5c20db

However, I *think* that it is only about an erroneous
warning message.


With regard to the problematic commit that bisection revealed
to you:

https://lore.kernel.org/patchwork/patch/1050496/

Can you try with a very recent kernel package, and then revert
just that commit (manually, in an otherwise stock kernel tree,
using the -R option with patch) Does the problem go away?

If so, it would certainly confirm there is an issue with
that commit. And given the discussion among the developers
about what is what, it seems it is very easy to make a
mistake or oversight in that code.

As to why it only happens to you, maybe a certain combination
of config options is needed to trigger the problem.


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom

[Michael Shell]

On Wed, 22 Apr 2020 00:48:29 +0200
Stephen Berman  wrote:

> the machine did power off.  So this took longer than the 20 seconds
> it took when calling shutdown immediately after logging in but
> unlike when running emacs or startx it didn't hang indefinitely.


And I thought it couldn't get any stranger. Obviously, I was wrong. :(

I see that (my, older) emacs is linked against libmount. My best guess
at this point is that both emacs and Xorg "look at" the cdrom and this
is what triggers the infinite hang. However, if nothing "looks" at the
cdrom, then the hang will be limited in duration. Nevertheless, at
this point I believe that both the delay and hang are linked to the
cdrom driver.

What if you issue a command like:

dd count=100 bs=1k if=/dev/cdrom of=/dev/null

with and without a readable disk in your cd/dvd drive?

After the above command is attempted/executed how does your shutdown
proceed then?

If it hangs forever, then I say that accessing the cdrom is what emacs
and Xorg does that triggers the infinite hang.

We could be looking at an interaction bug between your particular
dvd drive's firmware and the kernel. For example, previous kernels
sent the drive certain commands to close, etc. and newer kernels
do it a different way, one that triggers a "bug" in the drive's
firmware. Even if true, this does not mean that the kernel code
should not be changed - there is a general policy of kernel
developers to workaround such hardware issues whenever possible.

The next test would be to see if the hang persists even if the drive
is disconnected (or as Bruce suggested, trying a kernel without
the cdrom driver).

If that confirms it is the cdrom, then you have to bisect until
you find the specific change in the driver that created the
issue.


   Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] linux 5.5.9: shutdown -h hangs on detaching cdrom

[Michael Shell]

On Wed, 15 Apr 2020 10:41:27 +0200
Stephen Berman  wrote:

> But if I run another program before shutdown (the two cases I've tried
> are startx and emacs in the tty), then shutdown does not power off
> the machine.


This is a most perplexing problem!

I found this:

https://forums.developer.nvidia.com/t/system-seems-locked-while-rebooting-with-linux-5-2-1-and-nvidia-drivers-430-34-or-430-26/78262

which may, or may not, be related to your problem. However, it does
demonstrate that video driver bugs (in the kernel) can cause
such a problem.

Now, clearly there will be many other processes running on your
system even after a cold start. Even a bash prompt is a running
process.

Emacs might not be as clean a "console"" test as you might think - it
might trigger the starting of some video related kernel functions even
when running outside of X.

Try something like

more text_file.txt

so that you get a more prompt in that tty. Can you shutdown
with something as simple as more running?

If *any* running command, which was started by you, triggers the
problem, then perhaps it could be some type of permissions/user
issue related to a kernel bug. Namely, if your username starts
a process (perhaps anything other than a shell), then the kernel
seems to be unable to kill that process, and most strangely, all
this seems to be linked to the CDROM.

Another angle is that emacs (and Xorg) "look" at the CDROM
and that is what triggers it. If the more test allows for
a clean shutdown, than what about commands that try to
access the cdrom:

dd count=10 bs=1k if=/dev/cdrom of=/dev/null

Does running that result in shutdown failures (even after
the the dd command finishes/fails)?

What if your emacs process is then killed *before* you try to
shutdown, can you shutdown then? If not, my guess is that any
process that ever "looks" at the cdrom triggers the problem.

Another thing to try - does the problem persist if the CDROM is
physically disconnected from the system (e.g., its SATA cable
disconnected and then the system powered up)? If the system
just hangs at some other point, then that is good evidence that
something other than the CDROM driver/SCSI system is to blame.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] compile 32-bit kernel on a 64-bit LFS?

[Michael Shell]

On Thu, 12 Dec 2019 16:29:27 +0100
Thomas Seeling  wrote:

> take the .config from the 32-bit system and copy into the usual place on
> the compile machine. A multilib gcc is not required. I did not build the
> LFS for my 64-bit machine with multilib afair and it works.
> 
> Since you cannot "install" and "modules_install" you need to give
> temporary install paths for the kernel and the modules. These are 2
> distinct environment variables that have to be set.


  Thomas,

FWIW, the kernel build system also has environment variables to specify
the machine/CPU architecture as well as an alternate compiler.
For example, to build a 64 bit kernel on a 32 bit system, you could
do something like:

make ARCH=x86_64 CROSS_COMPILE=/opt/crosstools/bin/x86_64-linux-gnu- menuconfig
make ARCH=x86_64 CROSS_COMPILE=/opt/crosstools/bin/x86_64-linux-gnu- -j8
make ARCH=x86_64 CROSS_COMPILE=/opt/crosstools/bin/x86_64-linux-gnu- 
modules_install

where x86_64-linux-gnu- is the name prefix assigned to a cross gcc
(a 64 bit capable gcc, built using the --program-prefix=x86_64-linux-gnu-
during gcc configuration.) You can also use this approach to use any special
version of gcc for the kernel build.

In your case, a simple

make ARCH=x86_32 ...

should do the trick as long as your system gcc supports the specified
architecture and your .config is otherwise correct (including the
processor type) for what you want.

Also, there is a patch for the kernel source that enables additional
processor types and CPU specific optimizations:

https://github.com/graysky2/kernel_gcc_patch

IMHO, this patch should be accepted into the mainstream kernel tree.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Problem compiling findutils

[Michael Shell]

On Fri, 2 Aug 2019 23:36:36 -0500
Bruce Dubbs  wrote:

> 4.6.0 does build against the latest glibc with:
> 
> sed -i 's/IO_ftrylockfile/IO_EOF_SEEN/' gl/lib/*.c
> sed -i '/unistd/a #include ' gl/lib/mountlist.c
> echo "#define _IO_IN_BACKUP 0x100" >> gl/lib/stdio-impl.h


Yeah, *we* LFS folks can fix it ourselves with such, but we want upstream
to do a new release and so its helpful to bring up any point that can
help out in that regard. ;)


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Problem compiling findutils

[Michael Shell]

On Wed, 31 Jul 2019 20:47:30 +
Niels Terp  wrote:

> fflush.c:42:20: error: '_IO_IN_BACKUP' undeclared (first use in this function)


FWIW, IMHO, GNU really needs to release a newer version of findutils.
The latest release dates to 2015

https://ftp.gnu.org/pub/gnu/findutils/

and won't compile with the latest glibc, which is the problem you are seeing.
That issue, and many, many more have already been fixed in the findutils
git tree:

https://savannah.gnu.org/git/?group=findutils
https://git.savannah.gnu.org/cgit/findutils.git/

Just look at all the stuff the git version of findutils fixes:

https://git.savannah.gnu.org/cgit/findutils.git/log/

It takes 5 pages of these fixes to reach back to the 4.6.0 release
point. Look at all the bugs that have been fixed since then. Wow!

Remember that when building from git source, you may have to run

autoreconf

first to get a working ./configure script.

Alternatively, debian's findutils source package is based on the git
tree back in May:

https://packages.debian.org/sid/findutils
http://deb.debian.org/debian/pool/main/f/findutils/findutils_4.6.0+git+20190510-2.debian.tar.xz

Maybe we at LFS should consider switching to building findutils
from GIT (or providing our own GIT snapshot release) or use the
debian source package until GNU does another release.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS-8.4 Perl segfaults during build

[Michael Shell]

On Tue, 7 May 2019 17:50:28 -0400
baho-u...@columbus.rr.com wrote:

> May  7 17:24:23 lfs kernel: perl[5349]: segfault at 7fff0fb57ff8 ip 
> 0048ceb9 sp 7fff0fb58000 error 6 in perl[407000+23]


Perhaps this is the same issue discussed here:

https://www.perlmonks.org/?node_id=1002749

about a possible memory limit issue.

Does using ulimit to increase the data segment size also fix
the problem for your case as well?

ulimit -n 1024 -u 35 -m 20 -d unlimited -s 8192 -c 20 -v 2000


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] sh: -I.: command not found while build openssl-1.1.1b?

[Michael Shell]

On Sat, 23 Mar 2019 12:37:14 -0700
Pei Jia  wrote:

> /*/sh: -I.: command not found/* 
> As shown, *sh* has been successfully installed./

Or is sh reporting that the command "-I." was not found.

What happens when you run .config just using:

./config


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Potential damage of $LFS/tools setting in section 4.2 and 4.3 of LFS book.

[Michael Shell]

On Tue, 19 Mar 2019 09:15:25 +0100
thomas  wrote:

> Renaming /tools to another name will be appropriate to come over this
> issue.


Perhaps a more functionally descriptive name would also help in other
ways. After all, the stuff in /tools is for a *temporary* LFS system,
a first stage of the LFS build process.

So, perhaps a dir name such as "lfs_stage1" or "lfs_tmp_toolchain" would
not only avoid the Debian namespace collision, but also would be more
educational, potentially less confusing to the newbie, and functionally
descriptive as well.


 Just my $0.02,

 Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 8.3 | e2fsprogs-1.44.3 | external uuid library not found

[Michael Shell]

On Thu, 14 Feb 2019 22:39:00 +
Adam Cooper  wrote:

> I am getting the error "configure: error: external uuid library not found".


Perhaps it is the same issue as was here:

http://lists.linuxfromscratch.org/pipermail/lfs-support/2016-August/050260.html


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Creating initial partition when disk names not persistent

[Michael Shell]

On Sun, 7 Oct 2018 07:25:55 +0200
"Theodore Driscoll"  wrote:

> But I rebooted once more. Now Suse has swapped the names, so what used
> to be /dev/sda is now /dev/sdb and vice-versa. If I reboot again, the
> names sometimes swap back, sometimes do not.

The kernel developers insist that the kernal assigned /dev/sdx names are
not to be considered persistent even for a constant hardware configuration.
Although it certainly is unusual for internal SATA drives to change between
boots (BIOS behavior?) it is not guaranteed that such names won't ever change
between boots.

So, reference the drives using their PARTUUID. The kernel understands this
referencing method natively and will not require any initramfs.

You can see the PARTUUID of all the drives via:

lsblk -o NAME,FSTYPE,PARTUUID

e.g., 7b01c1ac-a7b2-4841-a36d-3a7eb46ed741

For the kernel command line and grub, the format to reference by PARTUUID
is:

root=PARTUUID=7b01c1ac-a7b2-4841-a36d-3a7eb46ed741

https://wiki.gentoo.org/wiki/GRUB

For fstab it is formatted like:

PARTUUID=7b01c1ac-a7b2-4841-a36d-3a7eb46ed741   /   ext2defaults
1 1

You will have to have a gdisk-created partition table for each partition
to be assigned a PARTUUID.

Note that you cannot use UUID at boot without an initramfs - as UUID's are
post-udev assigned things and will not be available to the kernel during
the initial boot process.


  Cheers,

  Mike Shell




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS Stable 5.31.1 tar-1.30 Testsuite filled up my partition

[Michael Shell]

On Mon, 10 Sep 2018 11:52:50 -0500
Bruce Dubbs  wrote:

> I do not want to start documenting failures that may be host system 
> dependent.


OK, but what about chapter 6? Make check is recommended there (actually
make check is also shown in chapter 5.31) and it is going to require such
an unexpectedly large amount of space. 6GB is the required minimum
according to chapter 2.4 "Creating a New Partition".


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS Stable 5.31.1 tar-1.30 Testsuite filled up my partition

[Michael Shell]

On Sun, 9 Sep 2018 12:59:49 +0200
Christian Friedl  wrote:

> * It would seem that the testsuite for tar (Chapter 5.31: Tar-1.30)
> created one gigantic file, aptly named BIGFILE, that ate up my whole lfs
> partition (all of 5.3GB that were left at that point).


IMHO, we should add a warning to the tar page about that.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Info on package bzip2-1.0.6 in LFS 8.2

[Michael Shell]

On Thu, 06 Sep 2018 18:26:10 +0200
Thomas Trepl  wrote:

> Regarding bzip2:  We as LFS cannot "switch back" to gzip as many
> packages are provided bz2 compressed.


To clarify - I didn't mean "we" as in specifically LFS, but rather "we"
as in the whole world (should stop using bzip). LOL!


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Running the mpfr-4.0.1 Tests

[Michael Shell]

On Tue, 07 Aug 2018 08:07:58 +0800
Xi Ruoyao  wrote:

> I just tried to build MPFR on a completed LFS.  The tests linked to
> libquadmath, but libmpfr.so itself did not.
> 
> Oh no, I think there is another problem.  In 6.16 the final Binutils
> should have been built.  So the final `ld` should have replaced the
> linker used in "Adjusting the Toolchain".


  Xi,

You are on a roll. OK, just to summarize for everyone here, so when binutils
is installed in 6.16, from that point forward, the ld the system is using
will link what is being built to libraries in /usr/lib rather than
/tools/lib.

And that means that when MPFR is built, its configure script should not
be able to even build anything linked against libquadmath because that
does not exist yet in /usr/lib. Correct?

In the mpfr-4.0.1 source tree, I did a:

grep -r MPFR_LIBQUADMATH *

I don't see any effect from the detection of the availability of 
libquadmath other than to add -lquadmath to the LD flags - nothing that
would suggest code pathways being altered or tests being selected or
otherwise changed.

They may have just put the detection in there for completeness, in case
they ever do want to use libquadmath's features, if, and only if, it is
available on the system.

Well, maybe the issue John encountered *is* the whole point of it -
that the tests should error out if they can be built linked against
lquadmath, but not successfully executed - that they wanted to test
for that possibility of things going wrong.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Running the mpfr-4.0.1 Tests

[Michael Shell]

On Mon, 06 Aug 2018 19:52:52 +0800
Xi Ruoyao  wrote:

> No.  /tools/lib/libquadmath.so.* is useless now.  After "6.10
> Adjusting the Toolchain" the default dynamic linker should have
> been changed to /lib64/ld-linux-x86-64.so.2 instead of
> /tools/lib64/ld-linux-x86-64.so.2.  Then it should search /usr/lib,
> not /tools/lib.
>
> MPFR configure script add "-lquadmath" if


   Xi,

Good catch! But, I think what threw me (and Hazel) off is why does
the MPFR build process attempt to link against libquadmath in the
first place? After all, as you said, libquadmath won't be available
(in /usr/lib) until after gcc is (re)installed in step 6.20.1

So, MPFR's configure detects libquadmath (in /tools/lib) and then
links its tests against libquadmath, but those tests later fail
because the dynamic linker is set to link from what is in /usr/lib?

In short, does the presence or absence of libquadmath affect the actual
libmpfr.so or just its test executables - that without libquadmath the
tests would not be linked against it and yet they still work fine?
Does it affect, say, the number of tests that are done? Depending
on the answer here, there may be a case for reinstalling MPFR again
after gcc.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Kernel bug involving physical to virtual remapping

[Michael Shell]

On Thu, 19 Jul 2018 21:54:20 +0200
Frans de Boer  wrote:

> I get an syntax error when compiling pager.c. I had this before and 
> remembered that gcc 8.1 is less forgiving then the 7 series.


  Frans,

FWIW, there was some discussion about gcc 8.1 issues on the kernel
mailing list:

https://lkml.org/lkml/2018/5/5/181

But, it seems the problems they mention are just warnings, annoying
but they don't actually break anything.

There are some gcc 8.1 kernel patches here:

https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=objtool-gcc8

The one of interest are the top two with "Support GCC 8" in the title.

But, I think you'll be more interested in the other set of 
GCC 8 patches here:

https://patchwork.openembedded.org/patch/151479/

two files in the kernel source are changed:

tools/lib/str_error_r.c 
tools/lib/subcmd/pager.c

So, there is your pager.c problem.

Looking at the patch code, it seems there are/were potential problems
in the kernel code which gcc 8.1 detects and warns (or errors) about.
But, gcc 8 itself isn't the cause of these issues.

> I don't believe that this is the right thread anymore.

Yeah, but the recent little odds and ends here sure are interesting.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Kernel bug involving physical to virtual remapping

[Michael Shell]

On Thu, 19 Jul 2018 13:54:19 +0200
Frans de Boer  wrote:

> But I can't compile 4.13. anymore because I now have gcc 8.1 instead
> of the former 7 series.


  Frans,

What goes wrong when you try to build a 4.13 kernel with gcc 8.1? 
It should work, right?

Are there any good reasons not to use a gcc 8 series kernel?


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Mon, 16 Jul 2018 15:35:18 +0100
Hazel Russman  wrote:

> It isn't in either of the two published kernels I built yesterday (4.14.0
> for Crux 3.3 and 4.15.3 for LFS 8.2).


Good! FWIW, I always just go ahead and use the very latest, but stable
(not an rc release), kernel. The note on the LFS page for the kernel
(under the "Linux" package):
http://www.linuxfromscratch.org/lfs/view/development/chapter03/packages.html
pretty much agrees with that approach.

At the other extreme, glibc and gcc tend to be very touchy with regard to
version changes.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Kernel bug involving physical to virtual remapping

[Michael Shell]

On Tue, 17 Jul 2018 14:06:09 +0200
Frans de Boer  wrote:


> Hazel, sorry but where should I remove phys_to_virt()? If I delete the 
> complete if statement in the iounmap function, and replace that with the 
> above code, i get compile errors.


  Frans,

You put (do not remove anything) the statement:

if (is_ISA_range(phys_addr, last_addr))
return (__force void __iomem *)phys_to_virt(phys_addr);

around line 106 of arch/x86/mm/ioremap.c

just before the lines:

/*
 * Don't allow anybody to remap normal RAM that we're using..
 */
pfn  = phys_addr >> PAGE_SHIFT;


You can how the older code was altered here:

https://patchwork.kernel.org/patch/9847859/


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] chapter 6, glibc compile error

[Michael Shell]

On Sun, 15 Jul 2018 21:09:16 +0100
Ken Moffat  wrote:

> Some of the tools progs appear to be ok, maybe only m4 was wrong,
> perhaps you built in stages and resumed without one of the envvars
> set correctly, e.g. PATH ?


Yeah, that! ;)


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Sat, 14 Jul 2018 16:45:36 +0100
Hazel Russman  wrote:

> The system now boots with acpi on, but I suddenly have mouse problems in
> X. Some mouse functions work and some don't. So this is not a complete
> solution yet, though it's a giant step forward.


Be careful here Hazel! Remember, after the patch, you are booting a newer
kernel with *tons* of other changes. If I had to bet at this point, my
money would go on that one of the *other* 4.15 changes caused your mouse
problem - that you are seeing two different problems. For example,
something like:

https://aeolus.tk/viewtopic.php?id=236253

Sometimes newer kernels subtly change the names of devices or report
their capabilities differently. So, it's not a necessarily "bug", yet.

Use

xinput list

to list all the input devices to Xorg. Find the id number for your
mouse. Then, using that id number, call (I've used id=9 below):

xinput list-props 9

do you notice anything different in the output of xinput list-props
between the 4.14 and 4.15 kernels?

Are you running the gpm daemon to provide mouse text console (no Xorg)
cut and paste features?:

ps -aef | grep gpm

which might reveal a command like like:

/usr/sbin/gpm -m /dev/psaux -t imps2 -r 45 -Rraw

(or /dev/mouse, /dev/input/mice, etc.)

The -Rraw option passes the data to /dev/gpmdata so that the X server
can pickup on that so that you can use the mouse under the text console
as well as Xorg.

If you don't run gpm, you can try to install/start/use it under the text
console to see if the movement and center button paste functions work.
You can use midnight commander (/usr/bin/mc) to test if the left button
and scroll wheel work under (with gpm in a text console).

If your mouse works fine under the console, but not Xorg, then Xorg might
just need a settings tweak under the newer kernel. Does Xorg complain any
in its log about the mouse?

If all also fails, you can try kernel bisecting all over again - each time
using the ioremap.c fix, of course. LOL!


  Cheers,

  Mike





-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Sat, 14 Jul 2018 06:44:33 +0100
Hazel Russman  wrote:

> I gather that some remapping that used to be done isn't done any more
> and that's what my machine doesn't like.


  Hazel,

Congrats! OK, now note the offending commit has two parts:
 
https://patchwork.kernel.org/patch/9847859/

All the second part does is add a warning message and is very unlikely to
be the cause of the problem. So, all you have to do to revert to
isolate down to 1-2 lines is add two lines to arch/x86/mm/ioremap.c:

if (is_ISA_range(phys_addr, last_addr))
return (__force void __iomem *)phys_to_virt(phys_addr);

around line 106, just before:

 /*
  * Don't allow anybody to remap normal RAM that we're using..   
  */
pfn  = phys_addr >> PAGE_SHIFT;


If that fixes 4.15 and later, you've certainly confirmed it all the
way down to a line. 

OK, now get a load of what was said about this commit when it was being
reviewed by the kernel developers in June 2017:

https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022513.html

Particularly the post here:

https://lists.linuxfoundation.org/pipermail/iommu/2017-June/022642.html

 "Making this conditional on !sme_active() is not the best idea. I'd
  rather remove that whole thing and make it unconditional so the code
  pathes get always exercised and any subtle wreckage is detected on a
  broader base and not only on that hard to access and debug SME capable
  machine owned by Joe User." -- Thomas Gleixner


Which means they were/are *expecting* some machines to break because of
the change!

Here was the original way they considered:

if (is_ISA_range(phys_addr, last_addr) && !sme_active())
return (__force void __iomem *)phys_to_virt(phys_addr);


The above should also work fine on your system - because the
(unwanted/problematic on your machine) remapping later on by ioremap.c
will still be *prevented* as long as secure memory encryption is
*not* being used.

That is - the lines above remaps via phys_to_virt() on machines for ISA
range addresses. The code later on in ioremap.c is supposed to be able
to handle such re/maps OK with or without SME (without the need to hand
things off to phys_to_virt()).

If you can confirm restoring the line above fixes the problem, then this
is who to report it to:

  Thomas Gleixner  tglx (at) linutronix.de 
  Tom Lendacky thomas.lendacky (at) amd.com
  Borislav Petkov  bp (at) suse.de

Possibly all of them as a CC to a post to the Linux IOMMU support mailing
list:
https://lists.linuxfoundation.org/mailman/listinfo/iommu

When they fix it, they will likely do so with *other* changes later on
in the ioremap.c code. In other words, the code later in ioremap.c is
supposed to work OK on all systems even without the "if (is_ISA_range ..."
line.

But, since your system is only one that has showed a problem so far,
they'll probably want you to run some test code before they decide how
best to fix it. And do let us LFS folks know how it turns out.


   Cheers and thanks,

   Mike


 
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Fri, 13 Jul 2018 09:35:24 -0400
Michael Shell  wrote:

> what exactly did gdb say about systemd's crash?


And FWIW, command output can be logged to a file as well as displayed
on the screen at the same time via the use of tee:

gdb /bin/program | tee gdb_log.txt

Actually, from

https://www.linuxquestions.org/questions/linux-software-2/bash-how-to-redirect-output-to-file-and-still-have-it-on-screen-412611/

it is even better also redirect stderr and use a subshell to avoid
order problems due to buffering:

(gdb /bin/program 2>&1) | tee gdb_log.txt

Then you can interact with gdb as needed and a copy of the
"conversation" will be in gdb_log.txt.


 Cheers,

 Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Fri, 13 Jul 2018 09:35:24 -0400
Michael Shell  wrote:

> In anycase, either by changing the m4/binutils build order, or
> adding the symlink, you can compile glibc successfully, right?


I read Bruce's old post too quickly. That symlink fix was for building
the newer binutils, not glibc. Actually, looking over those posts,
I'm still not sure what caused Bruce's glibc build problem.

Anyway, I think Frans' glibc build problem is due to not setting up
the chroot environment properly:

http://www.linuxfromscratch.org/lfs/view/development/chapter06/chroot.html

at the time glibc is built, what does 

echo $PATH

say? It should contain /tools/bin and so m4 will be found.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Fri, 13 Jul 2018 14:28:12 +0200
Frans de Boer  wrote:

> In an effort to understand why systemd crashes and having a message
> that there is a segfault in glibc while booting, i tried to
> recompile all again. Now I can't even compile glibc.


  Frans,

We kind of leaped over some steps/info here. What exactly did gdb reveal
about glibc when systemd crashed?

As to why you can't recompile glibc, I found this:

http://lfs-dev.linuxfromscratch.narkive.com/EqIzQ6w0/glibc-2-27

where Bruce said, 
  "That was a fix for binutils. We moved the build order to have m4
   before binutils. That change should not be needed. So, we have
   to (now) build m4 before binutils"

And m4 is listed before binutils can be seen in the development tree:
http://www.linuxfromscratch.org/lfs/view/development/

In anycase, either by changing the m4/binutils build order, or
adding the symlink, you can compile glibc successfully, right?

Again, what exactly did gdb say about systemd's crash?


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Thu, 12 Jul 2018 08:41:23 +0100
Ken Moffat  wrote:

> And the generic command is probably 'git revert 7744ccdbc16f' but
> since I'm not currently bisecting, I'm not sure what state that
> would leave things in.


  Ken,

I should have realized that since Hazel was working with the full git tree,
that he could easily revert any commit within git. Duh!

H ... I think what I was thinking was that I didn't trust the results
of the bisection within git (because the identified problem code does not
even seem be active within Hazel's config, and Hazel said he was new to
the bisection process). So, I'm not so sure the commit that is believed
to be the offender really is the guilty party. I was thinking that Hazel
would take the 4.15 source tree (from the official release tarball) and
then manually backout the suspect commit - if that works/boots, then it
is virtually certain we found the problem area (as we didn't depend on
git).

And, if we find the problem commit, the next step might be to manually
change things in the source until we home in on the offending *line*,
if possible. So, we'd be manually tweaking the source at some point
anyway.


With regard to reversing a patch (without any use of git), is it for
certain that the -R option of patch can be used to reverse *any*
patch file?

https://www.drupal.org/patch/reverse

If it is not universally possible to create a reverse patch using only
the information in a patch file, then I'd say that that is an oversight
in the design of diff.


There is a lot more info on the topic of reversing patches here:

https://stackoverflow.com/questions/3902388/permanently-reversing-a-patch-file


The interdiff utility and the patchutils package are new to me:

http://cyberelk.net/tim/software/patchutils/

( simple standard install: ./configure --prefix=/usr
   configure looks for perl and xmlto )

Interdiff can create an "inverse" patch file via:

interdiff file.patch /dev/null > reversed.patch

The resulting reverse patch looks good to me, but when I tried a dry
run:

patch --dry-run -p1 -i 
../tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch

I got:

checking file arch/x86/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n]

I don't understand why it would think the patch had been already applied
as the patch is supposed to *delete* code that is indeed in my Kconfig file.
I think the problem might be because the specific kernel tree I tried it on
has the context lines at 1436 rather than the 1415 specified by the patch.

I've attached a copy of the interdiff created

tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch

in case anyone wants to look at/try it.

Anyway, for the record, in the stackoverflow post, Lie Ryan's script
is not quite right. It reverses the --- and the +++ alright, but
later on it reverses the - and + at the start of the lines which also
ends up affecting the --- and +++ lines and so we end up getting -++
and +--. If he went through all that trouble to create that script,
didn't he take the time to inspect the results of it? Sigh.


  Cheers,

  Mike


tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch
Description: Binary data
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Wed, 11 Jul 2018 16:19:17 +0100
Hazel Russman  wrote:

> Does the "patchwork" site in your link contain the actual patch files
> that correspond to those weird alphanumeric codes? 


  Hazel,

Yes! At the page:

https://patchwork.kernel.org/patch/9847857/

Look at the headers near the top. The link to the patch is labeled
"patch" under the Download section. e.g.,

https://patchwork.kernel.org/patch/9847857/raw/

That will give you the patch that caused those changes which are
identified as "commit 7744ccdbc16f0ac4adae21b3678af93775b3a386":

tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support.patch

Now, I have learned that reversing a patch is often not as simple as
just calling patch with the -R option.

Here are the 5 steps to reverse that patch and remove the memory
encrypt changes from your kernel. 

Make a copy of your "bad/recent/4.15" kernel tree (cp -a , etc.) and
then do the following five changes to the copy:

To revert the 
tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support.patch

*** 1.
in file arch/x86/Kconfig
delete these lines around 1415:

config ARCH_HAS_MEM_ENCRYPT
def_bool y

config AMD_MEM_ENCRYPT
bool "AMD Secure Memory Encryption (SME) support"
depends on X86_64 && CPU_SUP_AMD
---help---
  Say yes to enable support for the encryption of system memory.
  This requires an AMD processor that supports Secure Memory
  Encryption (SME).

config AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
bool "Activate AMD Secure Memory Encryption (SME) by default"
default y
depends on AMD_MEM_ENCRYPT
---help---
  Say yes to have system memory encrypted by default if running on
  an AMD processor that supports Secure Memory Encryption (SME).

  If set to Y, then the encryption of system memory can be
  deactivated with the mem_encrypt=off command line option.

  If set to N, then the encryption of system memory can be
  activated with the mem_encrypt=on command line option.

*** 2.
delete the file arch/x86/include/asm/mem_encrypt.h

*** 3.
in file arch/x86/mm/Makefile
delete the line around 39:

obj-$(CONFIG_AMD_MEM_ENCRYPT)   += mem_encrypt.o

*** 4.
delete the file arch/x86/mm/mem_encrypt.c

*** 5.
delete the file include/linux/mem_encrypt.h


You may also want to comment out or delete the lines in your kernel
.config related to:

# CONFIG_ARCH_HAS_MEM_ENCRYPT is not set
# CONFIG_AMD_MEM_ENCRYPT is not set
# CONFIG_NUMA is not set
 

rerun makeconfig, save your configuration, and then try to build and
install the kernel. Does the modified 4.15 kernel boot OK now?

If so, we are now certain where the problem is.

If not, then the problem is not related to the memory encryption
patch/change after all - tell me as best you can how you came to
determine that the memory encryption change was the one where the
problem first appears.

Here is the info I found on how to biset a kernel problem:

https://www.kernel.org/doc/html/v4.14/admin-guide/bug-bisect.html
http://webchick.net/node/99

If the reversion of the memory encrypt changes don't fix the
problem, then maybe you were off by one with the bisect and this
is the next likely troublemaker:

https://patchwork.kernel.org/patch/9847859/

to revert that one, edit the arch/x86/mm/ioremap.c file and
*delete* the lines that are labeled with + and *add* those that
labeled with a - (remembering to remove those leading - labels when
you actually add them back in). Watch out to include the
"odd man out" line in between the + and -'s:

(void __force *)addr < phys_to_virt(ISA_END_ADDRESS))


> and it would be better done off-list because after all it's not an
> LFS problem (and certainly nothing to do with systemd!)

When you reply to this message, just reply to the message from my
email address and not the one from/to the LFS list. If we ever find
what the problem is, then we can later post that back to the list
so that others will also know.



  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Tue, 10 Jul 2018 08:01:13 +0100
Hazel Russman  wrote:

> Just to say that I've now tried the "acpi=copy_dsdt" boot option (without
> using my corrective initrd) and it doesn't stop the 4.15 kernel from
> panicking on my main machine. 


  Hazel,

Looking again at what you've posted, and the bug report you filed after
you bisected the kernel:

https://www.spinics.net/lists/linux-acpi/msg81646.html

I'd say it is *not* an acpi problem even though it appears that way.
You said that you do not have CONFIG_AMD_MEM_ENCRYPT set.
How about 

CONFIG_ARCH_HAS_MEM_ENCRYPT
CONFIG_NUMA

If CONFIG_NUMA is enabled, what happens if you disable it?
(In "Processor type and features" > "Numa Memory Allocation and 
Scheduler Support") 

Now, are you sure the problem is strictly related to the commit
here:

https://patchwork.kernel.org/patch/9847857/

i.e., if you revert that patch, and only that patch, in your
kernel, the files affected are:

arch/x86/Kconfig
arch/x86/include/asm/mem_encrypt.h
x86/mm/Makefile
x86/mm/mem_encrypt.c
include/linux/mem_encrypt.h

does the problem then go away?

If reverting the change does *not* fix the problem, then what
about the other two changes you mentioned?:

> Bisecting: 2 revisions left to test after this (roughly 1 step)
> [9af9b94068fb1ea3206a700fc222075966fbef14] x86/cpu/AMD: Handle SME reduction 
> in physical address size
> 
> Bisecting: 0 revisions left to test after this (roughly 1 step)
> [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() 
> usage in ioremap()
> 
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [7744ccdbc16f0ac4adae21b3678af93775b3a386] x86/mm: Add Secure Memory 
> Encryption (SME) support
> [unquote]


You can reverse a patch via the -R option

patch -p1 -R -i patchfile

If that works, then it is almost certainly *not* an ACPI problem, but rather
a memory management issue that seems to affect the ACPI system.

Since you are not using an AMD system, the AMD SME patch must have changed
something in the intel code, and that might not be too tough to narrow in
on.

That would be something to report to the kernel memory management people.


  Cheers,

  Mike



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Fri, 06 Jul 2018 15:44:19 +0800
Xi Ruoyao  wrote:


> There is message from systemd crash handler (showing a SIGABRT and dumping
> core), but there is no welcome message.  So the problem should be in
> mount_cgroup_controllers.
> 
> There IS a way to debug systemd - adding log_info into systemd source code
> to output key variables and debug messages.  I was one of the ACM/ICPC
> contestants who are very familiar with this ``debugging technique".  This
> technique often outperforms GDB in programming contests. :)


  Xi,

That is really good stuff to know! However, I don't understand what you
mean by "adding log_info into systemd source code". How exactly do you
do that? e.g., a debug option the source configure script, a manual
alteration of source code (and how/where), etc.

If it is a cgroup issue, it is required that the kernel be built with:

CONFIG_CGROUPS (it is OK to disable all controllers)


  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Thu, 5 Jul 2018 21:48:16 +0200
Frans de Boer  wrote:

> I had even rebuild everything with systemd-232, and that worked as 
> before. But after 232, things started to behave strange. Now way to 
> debug systemd, whatever I do


   Frans,

That's the whole point of being able to start the system with a shell
- so that systemd's startup, or failure thereof, can then be debugged
manually. What happened when you booted to shell and then tried to
start systemd manually?

init=/bin/bash
mount -o remount,rw /

Then, at the bash prompt, you want to try to start systemd manually.
You'll also want to first make sure you get a core file if/when it
crashes:

echo "core" > /proc/sys/kernel/core_pattern
ulimit -c unlimited

/usr/lib/systemd/systemd


With the above, does systemd crash and yield a core file?

Does

dmesg

show any relevant error messages?

If you get a core file, you can run gdb on systemd using the core
file:

gdb -c core /usr/lib/systemd/systemd

then what does the gdb backtrace reveal:

(gdb) bt


You can also try gdb on systemd without the core:

gdb /usr/lib/systemd/systemd
(gdb) run
(gdb) bt


If I had to bet at this point, my money would go on the theory that
your kernel is lacking support for something systemd (now) needs.
You can find a current list of systemd kernel config requirements
here:

https://cgit.freedesktop.org/systemd/systemd/tree/README

Note also, some kernel features must be *disabled*, e.g., 
CONFIG_SYSFS_DEPRECATED=n

Also, "systemd requires that the /run mount point exists.
   systemd also requires that /var/run is a symlink to
   /run "


   Cheers,

   Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Please consider adding --with-gcc-arch=native in libffi configure

[Michael Shell]

On Fri, 29 Jun 2018 20:32:37 -0400
Don Cross  wrote:
 
> I built LFS using jhalfs and the 8.2 version of the book on a machine with
> an Intel G860 processor. The configure script for libffi guessed wrong
> about the processor's capabilities, causing Python 3 to crash with an
> invalid instruction exception.


FWIW, I did file a bug report with libffi's developers:

https://sourceware.org/ml/libffi-discuss/2018/msg00033.html

Mailing list and contact info here:
https://sourceware.org/libffi/

However, there hasn't been any reply, so far.

At the very least, maybe there should be a warning message about this
issue on the LFS libffi page, including noting that it will typically
manifest as a python illegal instruction crash, which can happen
when building meson.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Thu, 28 Jun 2018 16:06:00 +0800
Xi Ruoyao  wrote:

> Now I only use "initrd" directive to update CPU microcode and fix the
> buggy ACPI DSDT of my laptop (another sad story).


  Xi,

If you are also inclined to allow firmware to be contained within the
kernel, the microcode part you can achieve via the 
 
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam15h.bin"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"

kernel config options under Device Drivers > Generic Driver Options.
CONFIG_EXTRA_FIRMWARE points to microcode file within the given
CONFIG_EXTRA_FIRMWARE_DIR= path. Though you'll have to rebuild the
kernel though if the microcode file ever changes, of course.

And as there now seems to be several people who suffer with the
ACPI DSDT driver bug, you guys should make sure upstream is aware
of the problem, if they aren't already.

There is also a recent kernel option, acpi=copy_dsdt that attempts to
fix bad DSDT tables. It might be worth a try if you haven't done tried
it already.



  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Wed, 27 Jun 2018 14:42:47 -0700
Paul Rogers  wrote:

> If that's true, even with systemd, why is there any need to build an
> initramfs for a known system?


  Paul,

Just like you, I build everything I need into a custom kernel and avoid
the need for an initramfs. One other reason people use initramfs is if
they need udev services on boot, say, for a drive the kernel will not be
able to find via a simple specification of root=/dev/X.

I think people should not go through all the initramfs trouble just for
LABEL= or UUID= functionality, but rather should just use PARTUUID=
which the kernel natively understands.

If Frans was using an initramfs, I assume he had some reason for doing
so and that we had to work within that constraint.

But, what really got me about Frans' case is why he could not bypass
systemd with init=. Well, it turns out that won't bypass the initramfs
which, at least for systemd systems, will still try and start systemd
before things can be handed off to the init= executable.

Systemd sure adds tons of complexity and it is scary to debug when
things go wrong. I much prefer the traditional sysvinit. However, when
I get some time, I think I might try runit and see how I like it:

http://www.mikeperham.com/2014/07/07/use-runit/
http://smarden.org/runit/

Finit looks interesting too:
http://troglobit.com/projects/finit/

FWIW, Gentoo has a comparision of the different init systems:

https://wiki.gentoo.org/wiki/Comparison_of_init_systems


  Cheers,

  Mike



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Tue, 26 Jun 2018 08:50:25 +0200
Frans de Boer  wrote:

> I removed the need for using initrd, so now init=/bin/bash is working. 
> Time to move forward and investigate what is causing the ABRT when 
> starting systemd. Thanks for the pointer, it has grossed my mind before 
> but somehow I forgot it again.


  Frans,

Yeah! Now we're on the right track! :)

Looking into it, the reason why initramfs is so tightly linked to systemd
is because:

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html

"At boot time, the boot loader loads the kernel and the initramfs image
 into memory and starts the kernel. The kernel checks for the presence
 of the initramfs and, if found, mounts it as / and runs /init. The init
 program is typically a shell script."


And that init.sh typically executes /sbin/init. So, whatever is in
/sbin/init is what gets executed, regardless of what was specified on
the kernel command line via init= . And on systemd systems, /sbin/init
is typically a link to /lib/systemd/systemd 

So, in order to make a nonsystemd initramfs boot on a systemd system, the
installed initramfs must use a nonsystemd init. 

Another idea would be to change what /sbin/init is linked to, say, to
/bin/bash.

There is also a kernel option, noinitrd, which should be able to disable
the execution of the initrd. So, if you do a 

root=/dev/sda1 (or whatever) init=/bin/bash noinitrd

that should allow for a nonsystemd shell boot. However, the kernel must
have all the drivers it needs to be able to mount the given root
filesystem without any other help.


Do let us know what gdb tells you about where systemd is tripping
up.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Mon, 25 Jun 2018 09:19:35 +0200
Frans de Boer  wrote:

> I have a strong reason to believe that it is systemd, since up-to 
> version 237 all worked well, but with version 237 and 238 - and nothing 
> else changed - it does not boot anymore.


  Frans,

Yes, I too believe that it is systemd. However, why you can't get
init=/bin/bash to boot is something that needs to be answered even if
systemd was booting OK. If you are using an initramfs, then that would
explain it because, as I understand it, in that case, systemd is still
required to start the init= line. This certainly is not a good thing,
IMHO, because init= is needed for such emergencies and there is a lot
that can go wrong with systemd, much, much more so than bash.

The systemd changelog can be seen here:

https://github.com/systemd/systemd/blob/master/NEWS

There are lot of changes to 238. Those that stand out to me are:

 1. The MemoryAccounting= unit property now defaults to on.

 2. Non-service units are now started with KeyringMode=shared
by default.

 3.  /sys/fs/bpf is now mounted automatically.


So, you can try adding to the kernel command line:

MemoryAccounting=false

For #3, in the kernel config, make sure "Enable bpf() system call"
(CONFIG_BPF_SYSCALL) is enabled in the General Setup.

For #2, the unit files could be changed to use
KeyringMode=inherit
or some such.

I would also try using version 239 to see if that works (they may have
fixed a known bug).


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Sun, 24 Jun 2018 10:01:48 +0200
Frans de Boer  wrote:

> Same story, nothing happens.
> I do notice, however, that on the listing by systemd capabilities the 
> text -ELFUTILS is used. I do compile the elfutils, but somehow systemd 
> does not use them. Is that a likely source of the problem?


   Frans,

I don't know, but how do you know that systemd is not using them?

In anycase, I think that if init=/bin/bash can't bring up a shell
prompt, then that indicates a serious issue and one that should
be independent of systemd (unless you are using an initramfs/initrd,
see below).

When trying init=/bin/bash, what exactly does your kernel command
line look like?

Here is how someone approaches that in grub:

https://linuxconfig.org/how-to-reset-lost-root-password-on-ubuntu-16-04-xenial-xerus-linux

Their grub boot was changed to something like:

linux /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\
c5b-44ee-a099-a88eb9520989 rw init=/bin/bash

But, without an initramfs, a PARTUUID should be used instead
(issue a blkid as root to see the list of drive names/IDs).

Now, with an initramfs/initrd it is my understanding that systemd still
starts first and then systemd calls the init= line:

https://lists.freedesktop.org/archives/systemd-devel/2014-June/020016.html

Are you using an initrd? If so, can you build any needed drivers into
the kernel, specifiy your root filesystem via PARTUUID and then
try init=/bin/bash again without the use of any initrd?

Another possibility is that the terminal you get does see your
commands, its just that you can't see the response due to some
type of console setup issue. You could try seeing if issuing
some command, e.g., ls, does cause the hard drive access light
to flash.

I would also try booting the same filesystem, but with another,
known good, kernel to see if that helps.


   Cheers,

   Mike




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Thu, 21 Jun 2018 20:44:57 +0200
Frans de Boer  wrote:


> Alas, tried everything from the site including the init statement to no 
> avail. The shell does not start due to an unapropriate ioctl.


According to this:

https://www.raspberrypi.org/forums/viewtopic.php?t=179344

You should be able to overcome the inappropriate ioctl warning
simply by hitting enter to get the command prompt back.

Also, try

init=/bin/bash

rather than init=/bin/sh

You can also try/add:

systemd.unit=emergency.target

or

systemd.unit=rescue.target

on the kernel command line. But, try to get 

init=/bin/bash

on the kernel command line to work first - that is a last resort failsafe
that should always work. If that won't boot, we can't expect systemd 
or anything else to come up.

Remember, once you get a shell, you will have to do a

mount -o remount,rw /

to get the root directory mounted read/write.


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Mon, 18 Jun 2018 00:53:37 -0400
Michael Shell  wrote:

> init=/bin/sh

To clarify: the above goes on the kernel command line, the others that
follow are commands to be executed in the resulting shell.


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting LFS with systemd

[Michael Shell]

On Sun, 17 Jun 2018 11:22:23 +0200
Frans de Boer  wrote:

> Alas, keeping debugging symbols did not work. I still get the message 
> "no debug symbols found" and as a reaction to the bt command "no stack".


  Frans,

You will have to show us the commands you used so we can understand
what you did.

As per

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883690

did you obtain a systemd.coredump file?

You may have to alter some of the systemd boot parameters to be able
to get more useful information:

https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
https://freedesktop.org/wiki/Software/systemd/Debugging/

The latter link shows how to debug systemd boot problems.

Some of the more relevant systemd boot parameters (to be added to
the kernel command line of your boot loader) mentioned include:

systemd.log_level=debug
systemd.dump_core=true
systemd.crash_shell=true

The first one should give you more information on the console.
The last one should be able to get you a shell after systemd crashes.
There will be a 10 second delay from the crash till the shell appears.

If you can't get a shell via systemd, then you can try booting to init
directly and then try starting systemd manually (to see if it crashes).
You should be able to get a core dump and run gdb on it in this way.
You will also have to manually remount the / filesystem as read/write:

init=/bin/sh
mount -o remount,rw /
exec /usr/lib/systemd/systemd


   Cheers,

   Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Wed, 13 Jun 2018 00:58:09 -0400
Michael Shell  wrote:

> IMHO, lilo had one particularly awful design decision and the resulting
> unexpected behavior was never explained to us as it should have been - 
> lilo would *reinterpret* whatever the user specified for root= in terms
> of device numbers of the current running system and then pass the
> resulting device *number* as the value of root= to the kernel to be
> booted.


FWIW, there once ago was a valid reason for doing this - a long time ago,
kernels only recognized major/minor device numbers for root directory
specifiers:
 
root=0x803

However, at some point kernels became able to recognize (at least the
common) /dev forms (e.g., root=/dev/sda3) and convert that at boot
to the major/minor form used internally even though there was not yet
a functioning /dev directory.

In any case, the lilo man page should have done a better job explaining
what exactly was actually passed to the kernel for root= in the
lilo.conf.


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Tue, 12 Jun 2018 10:28:26 -0500
Bruce Dubbs  wrote:

> I don't think you can say that for all BIOS firmware, but it is 
> certainly true for some.

I'm surprised by this, but you are correct here! According to

t13.org/Documents/UploadedDocuments/project/d1386r0-EDD.pdf 

since 1999 BIOes have had "Enhanced disk drive (EDD)" support for an
Int 13h extension than can address up to "16 mega-tera" sectors (2^64)
in size. It is just a question of upgrading any boot loader to use
this call (and hope the BIOS creator did it correctly).

With the older BIOS call, the sector number is specified as a 32bit
number and drives have historically used 512 bytes per sector.
So, the upper limit with the legacy call is 2^32 * 512 = 2.199 TB


On Tue, 12 Jun 2018 20:42:05 +0100
Ken Moffat  wrote:

> And then /dev/hda became /dev/sda - I never managed to get lilo to
> work with /dev/sd if the machine was currently booting from /dev/hd.

IMHO, lilo had one particularly awful design decision and the resulting
unexpected behavior was never explained to us as it should have been - 
lilo would *reinterpret* whatever the user specified for root= in terms
of device numbers of the current running system and then pass the
resulting device *number* as the value of root= to the kernel to be
booted. The only exceptions allowed were for LABEL= and UUID=, but even
there what we really needed was PARTUUID=. In short, lilo should have
just kept root= exactly as the user gave it in the lilo.conf and passed
that string as-is to the kernel when booting. 

I was working on one of my (really) old machines back in November and
wrote a patch for lilo to do just that. I've attached it to this post.
Once the patch has been applied and lilo rebuilt, you can put anything
you want for root= and it will be passed-on as-is. That means you can
do things like:

root="PARTUUID=1234567a-af67-4c97-8154-438376dc7113"
or
root="/dev/sda1"

and it will work as you expect - root= will be interpreted only at
boot by the booting kernel. And lilo will also work with GPT partitioned
disks just fine! (because lilo only cares about sector numbers, not
partitions).

The main lilo limitations would then be:

 1. The EFI/BIOS must provide the legacy BIOS "compatibility" (CSM)
calls.
 2. Lilo's second stage boot loader and any kernel images to be
loaded must be within the first 2TB boundary. (I think.)
 3. The drive must be using a 512 byte sector size. (I think.)
 4. As always, if lilo's second stage boot loader or a kernel image
file is moved, lilo must be rerun to get the correct sector
number locations of those files.

If they really are problems, both #2 and #3 should also be fixable in
code, well, as long as the BIOS call of the machine supports it.

I suppose my "pass root as-is" patch would have really been helpful
to some folks ... 5 years ago. Oh well.


   Mike



lilo_pass_root_as_is.patch
Description: Binary data
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Tue, 12 Jun 2018 14:25:48 +0800
Xi Ruoyao  wrote:

> efibootmgr uses the library from efivar for /sys/firmware/efi/efivars.
> I searched "efivarfs" in the Github repo and found the commit to add
> efivarfs support:
> https://github.com/rhboot/efivar/commit/5b175a55d53c5d0f44e3636802fc7dc3fe7549a6


Thanks Xi! Yeah, that ability was added already in mid-2013. And so
efibootmgr will auto select between efivarfs and the sysfs interface
depending on what is available.

So, any post-2013 efibootmgr will be able to use either interface.

From
https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt.

"The efivarfs filesystem was created to address the shortcomings of
 using entries in sysfs to maintain EFI variables. The old sysfs EFI
 variables code only supported variables of up to 1024 bytes. This
 limitation existed in version 0.99 of the EFI specification, but was
 removed before any full releases. Since variables can now be larger
 than a single page, sysfs isn't the best interface for this.
"


So, the EFI spec itself changed and that is why we have the new interface.


  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 23:20:51 -0500
Bruce Dubbs  wrote:

> What issues with GPT and legacy boot?  Grub needs some space for it's 
> code that is OS independent.  A separate small partition makes sense. 
> Putting the boot code in firmware is what does not make sense. And you 
> still need a custom EFI partition even then.
>
> Talking about a second stage loader is really about grub legacy.  The 
> current grub doesn't work like that.  The old way of using a fat 
> partition table and loading code in sectors 2-32 was really a kludge.


Well, according to:

https://en.wikipedia.org/wiki/BIOS_boot_partition

"When used, the BIOS boot partition contains the second stage of the boot
 loader program, such as the GRUB 2; the first stage is the code that is
 contained within the Master Boot Record (MBR). Use of this partition is
 not the only way BIOS-based boot can be performed while using
 GPT-partitioned hard drives; however, complex boot loaders such as GRUB 2
 cannot fit entirely within the confines of the MBR's 398 to 446 bytes of
 space, thus they need an ancillary storage space. On MBR disks, such
 boot loaders typically use the sectors immediately following the MBR for
 this storage; that space is usually known as the "MBR gap". No equivalent
 unused space exists on GPT disks, and the BIOS boot partition is a way to
 officially allocate such space for use by the boot loader."


So, with GPT disks under BIOS systems, there is no way to initially load a
boot loader complex enough to be able to read a filesystem. Lilo worked
by requesting the sector numbers that corresponded to its second stage
(and in turn, it's second stage requested the sector numbers of the
kernel image to boot). That is why lilo had to be rerun every time a
kernel image file was moved.

So, when grub is running on a BIOS system with a GPT disk, it works a
bit like lilo, except the second stage loader is contained in its own
partition (where it can't be touched by mv, rm and friends) and that
second stage is smart enough to be able to read files on FAT and EXTx
filesystems without relying on fixed sector numbers. In this way, there
is no need to "rerun" grub if a kernel image file is relocated as is
the case with lilo.

BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo,
etc., must ensure that the (second stage) boot loader as well as any
kernel image files are located within the first 2 TB of the drive
because the BIOS calls can't handle sector numbers beyond that.

> I believe the slots the sata drives are plugged into have priorities. 
> I've never seen the disks reverse identification.  that would really be 
> a bad race condition.  If it was happening, we would certainly have 
> heard about it.

I can't remember exactly how I was bitten by it, but it wasn't via USB.
It might have been from the use of a removable rack or SD card to SATA
adapter (as a "rescue" boot) that sometimes would have media in it and
sometimes not.

In any case, according to
https://wiki.archlinux.org/index.php/persistent_block_device_naming

"If your machine has more than one SATA, SCSI or IDE disk controller, the
 order in which their corresponding device nodes are added is arbitrary."

As I understand it, that is the policy of the kernel developers - a system
might work in many cases, but it is not guaranteed and a future kernel
update could break systems that rely on any fixed /dev/sd* naming. To me,
this means that, until udev becomes active and we can control things as we
wish, any /dev/sd* specifiers are to be considered worthless.

I do not like that policy. Unless countermanded by a kernel option,
on-motherboard controllers should be enumerated before those of any add-on
card or USB device. Also, SATA slots for a given controller should be
enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be
enumerated regardless of whether a drive has been plugged into it. I would
go so far as to make it that an initial, say, half a dozen drive names would
be reserved for each USB controller regardless of whether a USB mass storage
device was actually present at boot. I would also not enumerate USB drives
in the /dev/sdx sequence, they would get their own sequence /dev/usbdx,
because those do not have known/fixed slots as SATA controllers do. 

In a more complex arrangement, controllers could be enumerated like the
devices they carry - /dev/sdAb1 - controller A, drive b, partition 1
with motherboard controllers being enumerated first, and then those on
PCI, etc., slots, in the order of the slots they are plugged into.

In short, I would try hard to avoid changing existing device names, most
especially for devices on controllers on the motherboard, if later
something is merely added-to/plugged-into the system.


  Cheers,

  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes 

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 21:24:08 +0800
niuneilneo  wrote:

> This most updated UEFI installation guide is mainly contributed by Xi
> and already committed to LFS knowledge base.

That is a good one. I missed the importance of the earlier post to it.
Thanks for the tip!

But, my post was not about using grub under EFI, but rather about doing away
with grub entirely. What advantage is there to retaining the use of grub
when the EFI system and efibootmgr does not need it?

If I were going to use a bootloader under EFI, I would use Rod Smith's
rEFInd:

http://www.rodsbooks.com/efi-bootloaders/refind.html

As you might guess, I'm not a big fan of grub. There is a reason it has been
said of grub by the gummiboot developers:

"gummiboot is intended to be a minimal alternative to GNU GRUB that
 'just works'"
https://en.wikipedia.org/wiki/Gummiboot_(software)

I went from BIOS-lilo to pure-EFI without ever using anything in between.


On Mon, 11 Jun 2018 23:13:29 +0800
Xi Ruoyao  wrote:

> If EFI is used, the BIOS boot partition is unnecessary. It is
> used to workaround issues caused by GPT with Legacy Boot.

OK, but if they ever need to boot in BIOS mode under a GPT disk, they will
need that partition to hold grub's second stage loader. In Rob's case, I
can now see he definitely does not need it because his system does not even
support booting using BIOS mode.

Nevertheless, it's good to know that grub won't complain if it does not
find that partition as long as it does not actually need the second stage
loader.

> Using /dev/sd* works, but your computer may refused to boot
> with a USB stick.

Yes, and there was something else that trips up /dev/sd* specifiers before
udev can become active - IIRC, I think if a multicore machine has more than
one SATA controller/card/chip, the order of the device detection/naming can
vary between boots. So, for anything prior to udev's control, we have to use
persistant device naming for it to be reliable. FWIW, I dislike this design
choice of the linux kernel.

> Now we use CONFIG_EFIVAR_FS (y or m), instead of CONFIG_EFI_VARS,

Do you know if efibootmgr will autodetect (at run time) between the two kernel
interfaces (and if this is a recent feature, what version starting supporting
that)? AFAIK, they both can be enabled at the same time. 

As you mentioned, EFIVAR_FS is a more modern interface, but it does
require that a special efivarfs filesystem be (re)mounted r/w:

mount -o rw -t efivarfs efivarfs /sys/firmware/efi/efivars

So, Rob will have to add that to his start scripts - maybe mount it read-only
and then manually remount r/w as needed:

mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars

Thanks for the tips and info!


  Cheers,

  Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 03:01:00 -0400
Michael Shell  wrote:

> Your kernel will have to be compiled with an EFI stub. 


I should have also stated here:

"*if* you want to boot directly using the EFI system and bypassing any
 need for grub or other bootloader".


  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] libffi problems

[Michael Shell]

On Sat, 26 May 2018 19:29:57 +0200
René Nyffenegger  wrote:

> This escaped my notice when I first made libffi. Unfortunately, I have 
> no idea why the tests fail.


Yep, as Filip mentioned, we've seen this problem recently. I've filed a
bug report with the libffi developers and will let the LFS list know
what they say.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] make install of Python 3 causes: 3273 Illegal instruction

[Michael Shell]

On Sat, 26 May 2018 10:14:09 +0200
René Nyffenegger  wrote:

>Architecture:x86_64
> .
> .
>target='x86_64-pc-linux-gnu'
>target_alias=''
>target_cpu='x86_64'
>target_os='linux-gnu'
>target_vendor='pc'


  René,

That all looks OK to me. Can you trigger the illegal instruction
error manually at the command prompt via:

> What's causing the problem seems to be the ensurepip module:
> ./python -E -m ensurepip

If so, then run it through the debugger gdb and try to find out
the specific offending instruction:

gdb ./python
run -E -m ensurepip
display/i $pc


There is a complication here in that you are building a LFS system
which does not include gdb as that is a BLFS utility:

http://www.linuxfromscratch.org/blfs/view/svn/general/gdb.html

So, you will either have to rely in the host gdb, or also install gdb
in your LFS system.

Have you altered your optimization cflags e.g., -O3 ?


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] make install of Python 3 causes: 3273 Illegal instruction

[Michael Shell]

On Sat, 26 May 2018 09:29:40 +0200
René Nyffenegger  wrote:

> /bin/sh: line 7:  3273 Illegal instruction (core dumped) 
> LD_LIBRARY_PATH=/usr/lfs/sources/untarred/Python-3.6.4 ./python -E -m 
> ensurepip $ensurepip --root=/


  Randy,

What CPU does your system have? Also, in your python source directory,
in the file config.log, what does the line with the

target_cpu=

(around line 20048) have as a value?


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] 6.48. Libelf 0.170

[Michael Shell]

On Thu, 24 May 2018 12:38:59 +0200
DM  wrote:

> ar.c:1077:56: error: '%-*ld' directive output may be truncated writing


  Daniel,

This was fixed in elfutils on September 20, 2017:

https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=b10d7eb74064c5906f031cd17c0f82041c6a4ca1

the most recent release of elfutils (0.170) dates to August 3, 2017.

The elfutil developers really should put out another release.

You can either apply the patches in the above URL, or checkout the elfutils
source tree via git:

https://sourceware.org/elfutils/

However, the above does not explain why others have not encountered this
bug in LFS 8.2 - I suppose you are compiling with -O3 which is needed
to trigger the bug. So, another option would be to compile with -O2


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

[Michael Shell]

On Wed, 16 May 2018 21:26:41 -0500
Bruce Dubbs  wrote:

> If it's a true OOM condition, then there should be something in a log. 
> If RAM is short, swap should handle it, although it slows things down.

I agree ... if things otherwise work as they are supposed to.


On Thu, 17 May 2018 17:42:17 -0400
Admin  wrote:

> How real this concern is for lfs? I mean, one of the claims about
> Linux/GNU OS is that it requires very much less resources such that
> even old computers can be made useful again rather than being obsoleted.

I agree with this too. I was thinking that perhaps Tcl-core was triggering
a memory hog type bug/issue with the most recent gcc and that people with
more RAM were not seeing any problem.


On Thu, 17 May 2018 18:03:57 -0400
Admin  wrote:

> Now I have 2 VMs with identical settings where one fails to compile
> tcl-8.6.8 with -O2 and the other where it is fine. I don't know how to
> interpret this. I am accepting that I might have made a mistake in the
> first instance, but the failure was very subtle, undetectable and I don't
> know how to understand the peculiar behavior (compiling only with
> -O2 optimization fails, but -O1 succeeds).

Thanks for letting us know. One possibility was a memory error - the
system made an undetected one byte mistake (in building gcc?) during the
first build.

You could try making a copy of the "bad" system (so you have an unaltered
copy of it to inspect/restore late) then copying over components of the new
system to see which one fixes it. Gcc would be high on the list. e.g., does
copying the gcc executable from the good system to the old one fix the issue
on the "bad" system?


   Cheers,

   Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Libffi 455 tests fail. Step 6.49. Libffi-3.2.1 in the book lfs-8.2 systemd version.

[Michael Shell]

On Thu, 17 May 2018 16:41:12 +0200
Filip Banák  wrote:

> => 0x7601dce4 :vmovq  %r13,%xmm3  <<<


OK, good, vmovq is an avx instruction. Your CPU flags don't list avx
capability:

> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
> xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor
> ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt
> tsc_deadline_timer xsave lahf_lm epb pti tpr_shadow vnmi flexpriority
> ept vpid xsaveopt ibpb ibrs stibp dtherm arat pln pts

And here
https://en.wikipedia.org/wiki/Advanced_Vector_Extensions
it is stated
  "Note: Not all CPUs from the listed families support AVX.
   Generally, CPUs with the commercial denomination 'Core i3/i5/i7'
   support them, whereas 'Pentium' and 'Celeron' CPUs don't."

So, libffi has a bug with regard to the configuration of Celeron G530
CPUs. When you build libffi, what do you see it is using for the
gcc -march option? e.g., 

make 'AR_FLAGS=' 'CC_FOR_BUILD=' 'CFLAGS=-O3 -fomit-frame-pointer
-fstrict-aliasing -ffast-math -march=amdfam10  -Wall -fexceptions'
'CXXFLAGS=-g -O2' 'CFLAGS_FOR_BUILD=' 'CFLAGS_FOR_TARGET='

Inside the libffi source tree there will be an architecture specific
directory "..linux-gnu". Inside there will be a config.log file. In
that file, what does it say on the lines from
"checking for gcc architecture flag"
to
"checking CFLAGS for maximum warnings"

which corresponds to configure:16308 to configure:16799, approx log
lines 690-716 ?

This bug should be reported to the libffi developers.
However, in the meantime, ./configure has an architecture override
option: --with-gcc-arch=

The question then becomes what to put there for your CPU.
Some say it should be pentium4: 
https://forums.gentoo.org/viewtopic-t-722765-start-0.html
e.g., ./configure --with-gcc-arch=pentium4

You could try native and see if gcc gets it right.

Still others say you should do:
-march=corei7-avx -mtune=corei7-avx -mno-avx -mno-aes
https://stackoverflow.com/questions/15576817/what-is-the-proper-architecture-specific-options-m-for-sandy-bridge-based-pen/35049035
which would require you to do
./configure --with-gcc-arch=corei7-avx
and then add
"-mno-avx -mno-aes"
to your CFLAGS to remove support for the avx and aes instructions.

Do let us know what you tried and how it turned out.


  Cheers,

  Mike







-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Stuck at step 5.11 (Tcl-core-8.6.8) from lfs-8.2

[Michael Shell]

On Tue, 15 May 2018 16:38:37 -0400
Admin  wrote:

> BTW, the VM has enough resources - 6G RAM & 128 GB HDD (LFS partition).


I would not be so certain about this. Today, 6GB RAM is not as much as you
might think. For example, the short C++ code shown here:

https://kristerw.blogspot.com/2017/10/excessive-gcc-memory-usage-for-large.html

requires 8GB of RAM for gcc to compile.

Also, gcc requires more memory with increasing levels of optimization. So,
this would explain why -O1 works. Can you increase the VM memory allocation
to say, 12GB and see if that has any effect?


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Libffi 455 tests fail. Step 6.49. Libffi-3.2.1 in the book lfs-8.2 systemd version.

[Michael Shell]

On Wed, 16 May 2018 18:03:34 +0200
Filip Banák  wrote:

> When i execute it like this
> gdb -ex r --args python3 setup.py build
> then I get https://pastebin.com/1H4biM12
> 
> Almost certain something is wrong with libffi.


Right, libffi has been built for a different CPU model. To see the
offending instruction in gdb after the above error, after gdb reports:

:Program received signal SIGILL, Illegal instruction.
:0x75fddce4 in ffi_closure_alloc () from /usr/lib/libffi.so.6

enter this command at the gdb prompt:

(gdb) display/i $pc

and tell us what gdb responds with.



  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Difficulties with instruction on 5.8 Libstdc++-7.3.0

[Michael Shell]

On Sat, 03 Mar 2018 10:11:34 -0500
miguel caldas  wrote:

> "configure: WARNING: stdbool.h: present but cannot be compiled


Back in 2015, the LFS list had a post about the same type of problem:

http://lists.linuxfromscratch.org/pipermail/lfs-support/2015-October/049009.html

If your problem is the same as that one, something went wrong with the
glibc installation step. As Bruce (and Hazel) said, "remember to
ensure the glibc-build and glibc-2.xx directories are removed before
re-extracting the tarball."


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 8.1 rc-1. eudev: a suggestion

[Michael Shell]

On Mon, 26 Feb 2018 00:20:16 -0600
Bruce Dubbs  wrote:

> Mike, maybe you didn't look at how we use LD_LIBRARY_PATH.  It is set as a 
> temporary variable for specific calls to build instructions in the lfs 
> chroot environment.


  Bruce,

Yeah, my post really didn't have anything to do with LFS per say. The
article is a broader commentary about the way things are done in Unix.
He even comments on /etc/ld.so.conf:

: Half-hearted attempts to improve things
:
: Some OS's (For example, Linux) have a configurable loader. You can
: configure what run-time paths to look in by modifying /etc/ld.so.conf.
: This is almost as bad a LD_LIBRARY_PATH! Install scripts should never
: modify this file! This file should contain only the standard library
: locations as shipped with the OS. 


He wants the linking framework itself to be changed to allow for
more customization at the individual application level.


Anyway, that site sure has a lot of interesting articles:

http://xahlee.info/comp/comp_index.html

There's a little bit of everything in there.


   Cheers,

   Mike


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 8.1 rc-1. eudev: a suggestion

[Michael Shell]

On Sat, 24 Feb 2018 10:12:56 -0600
William Harrington  wrote:


> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
> .
> .
> see ``Why LD_LIBRARY_PATH is Bad'' at http://www.visi.com/~barr/ldpath.html
> for an explanation of why. 


For those interested in that article by David Barr, the link to it no
longer works. However, it has been reposted to:

http://xahlee.info/UnixResource_dir/_/ldpath.html

The original is still archived here:

http://web.archive.org/web/20060719201954/http://www.visi.com/~barr/ldpath.html


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Sun, 7 Jan 2018 16:47:00 -0600
DJ Lucas  wrote:

> I might be confused, but I thought microcode updates on consumer 
> processors is handled by BIOS update from the motherboard manufacturer, 
> the AGESA part of the BIOS version, currently 1.0.0.7. I'm not sure if 
> we'll see a late-load .bin for the consumer processors. 


  DJ,

Given that a microcode update would apply to all processors of a given
type and given this is a security related matter, the chances are very
good that *somebody* will extract and "leak" the microcode files to
the public even if Intel/AMD does not (officially) do so.

IMHO, tis kind of silly of Intel/AMD to expect microcode updates to
come only by way of BIOS updates given how reluctantly motherboard
makers issue BIOS updates.


   Cheers,

   Mike
 

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] stow for package management?

[Michael Shell]

On Fri, 5 Jan 2018 20:51:58 +
Jorge Almeida  wrote:

> I just found out about stow. It just seems too good to be true. So:
> did I misunderstood something? Any gotchas that are not obvious?


  Jorge,

I haven't used stow myself so I can't comment on how well it works.
I think it would work in almost all cases and that the packages with
problems would be those that have trouble when installing to *any*
directory other than /usr or /usr/local.

Another possible "gotcha" is when the package to be installed wants
to tweak something (else) in the main filesystem, say /etc, versus
just add something to /path/to/stow/foo/etc

One package manager I have used before is porg (It had that name
long before Star Wars ever used it. Now we have to search using

porg package manager

rather than just porg to find the correct related sites):

http://porg.sourceforge.net/

and I do like it. It does not use simlinks, but rather maintains
a database of the files installed. With stow, this filelist
information is carried by the symlinks themselves. The advantage
of stow is that the package installation step does not have to be
done as root.



  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Fri, 5 Jan 2018 17:26:13 +
Ken Moffat  wrote:

> Does anybody have a link for (any) updated AMD firmware?  Ryzen is
> model 17h, AFAICS linux firmware has nothing for that, and the
> firmware for earlier models has not been updated in a long time.


I also sure would like a link to that if anyone here knows it. That
said, the Debian page for the AMD microcode is here:

https://packages.debian.org/sid/amd64-microcode

There is also a place on github where Linux related firmware is
distributed from. The AMD CPU microcode area of that is here:

https://github.com/wkennington/linux-firmware/tree/master/amd-ucode

But no updates since 2016 so far. Sigh.

The Intel area (in the github link) does not seem to carry anything for
CPUs. Intel's own distribution page for CPU microcode is here (tis the
same link Ken gave earlier):

https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

"This microcode data file contains the latest microcode definitions
 for all Intel processors."

But, as Ken mentioned, it seems that the Debian page has versions more
recent than Intel has officially released. Sigh.

> Like you, I'm very wary of bios updates (I've bricked enough
> hardware over the years).



As long as it is for the correct motherboard, it should work. I've
upgraded motherboard BIOSes many times and doing so has allowed me to
overcome lots of annoyances. Just be sure and record any critical
settings before the update. Be prepared to have to reset your CMOS
settings (or even have them automatically reset by the update process
itself) and then reenter all your settings. One other thing, I never
use the "network BIOS update" feature found on many modern
motherboards. I always download the BIOS file manually and update
from that. Always be sure and get the correct one.

The bigger problem in my eyes is motherboard OEMs not creating/releasing
BIOS updates, especially for older hardware. Now, when they are motivated
enough to do so, it usually means something serious was fixed.

I've also become a fan of the linux flash utility flashrom:

https://www.flashrom.org/Flashrom

Although I have not yet used it to update a motherboard BIOS, it worked
great to update the BIOS on a SATA card. And it allows us to *save* a
copy of the flash rom contents before we overwrite it with an update.

Also, it's good to know that there are sellers on Ebay who are selling
BIOS chips in the $15 range. Do a search for 

BIOS chip yourmotherboard model

to see what's available. Some of these chips are plugin DIPs, but others
are SMT devices that will require the use of soldering skills to replace.
However, it's a venue that will allow you (or your local electronics
technician) an emergency means to unbrick.


IMHO, every firmware update-able device should carry two copies of its
firmware - one that is always read only and is forever fixed at the
factory and the other copy which can be updated by the user. This way,
if an update fails, a switch/jumper can be set to fallback to the OEM
firmware to allow booting so the second (writable) copy can be reflashed.
Also, there should be a second jumper that would force the second
(writable) copy to be read only as well. In this way, malware could be
kept out of firmware - all firmware updates locked out in hardware.





In anycase, from what I understand at present, the Meltdown/Spectre class
of bugs don't allow for things like arbitary code execution - they just
leak information. The spillage of the entire kernel memory area is most
troubling. But, even so, it should be tough for an attacker without shell
access to use that to gain root access. I think the biggest concern here
is for (shared) hosting companies and companies with public servers that
are handling sensitive information, not the normal desktop.

Lastly, IMHO, no application facing the outside world should ever allow
users to be able to craft and execute code at level low enough to permit
such exploits. I think such an ability is a security-related bug in and
of itself.



  Cheers,

  Mike

  
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] The Spectre and Meltdown CPU vulnerabilities

[Michael Shell]

On Thu, 4 Jan 2018 20:16:18 +
Ken Moffat  wrote:

> There are two vulnerabilities, with the shiny names of Meltdown and
> Spectre. Both refer to ways of userspace finding where the kernel
> has been mapped, to try to do harm. Page Table Isolation addresses
> the first of these. Google claim it affects some AMD processors,
> AMD deny this.


Most interesting, but also scary. Here's my own summary take on the info
which I found at:

http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html
https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
https://overclock3d.net/news/cpu_mainboard/amd_releases_response_to_meltdown_and_spectre_exploits/
https://www.phoronix.com/scan.php?page=news_item=Linux-Tip-Git-Disable-x86-PTI
https://www.theregister.co.uk/2018/01/04/intel_amd_arm_cpu_vulnerability/

There are three variants of this new class of vulnerability which all
involve gaining illegal read access to memory:

Variant 1:
Bounds check bypass, aka "Spectre (Version 1)", CVE-2017-5753, 
Supposedly, is to be fixed within the kernel. It is promised to be an easy
and painless fix. Almost all modern processors are affected.

Variant 2:
Branch target injection, aka "Spectre (Version 2)", CVE-2017-5715
May require a CPU microcode update or recompiling all the applications
to fix. More mystery and conflicting info over this one than the other
variants. AMD claims vulnerability is "almost zero". The Zen family may
be an exception (see below).

Variant 3:
Rogue data cache load aka "Meltdown", CVE-2017-5754
The new Linux kernel Page Table Isolation (PTI) feature protects against
this exploit. All post-1995, except Itanium and pre-2013 Atom, Intel
CPUs and Arm Cortex-A15, Cortex-A57, Cortex-A72 and Cortex-A75 cores
are vulnerable. No AMD CPUs are vulnerable to variant 3.

From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
"Variant 1 is software [OS] patchable and affects almost all modern
 processors. The patch itself will have negligible performance hit.
 Variant 2 and 3 are rooted further in hardware and are not patchable
 by any known means of code. Attempting to patch these using software
 will result in performance hits and so far these only seem to affect
 Intel and ARM processors with near zero risk to AMD CPUs."


However, the above quote is a little misleading because the Linux kernel
Page Table Isolation (PTI) feature should be able to prevent Variant 3,
albeit with a load dependent performance penalty.

Tis real bad news for folks using Intel because Intel's processors are
impacted much more severely than those of AMD.

In particular, "it is said that Meltdown (Variant 3) has been tested
on all Intel processor generations since 2011, with 'effectively every
processor since 1995' being affected (with a few exceptions)".

AMD claims its processors are not vulnerable to Variant 3 (and the
upcoming Linux kernel releases will disable the PTI protection config
option by default for AMD processors), and that they have "near zero"
risk from variant 2 (but see below for evidence that Ryzen CPUs might
have an issue with variant 2).

Variant 1 affects almost all modern processors, including those of AMD,
and may require future hardware architecture changes to totally mitigate
without the need for OS patches/protection. However, AMD now claims it
has developed a patch (kernel or microcode level?) that "can mitigate
variant 1 with minimal performance impact."

From https://wccftech.com/intel-affected-by-critical-kernel-bug-amd-hit/
there were four proof of concept exploits that have been demonstrated:

 "During the course of our research, we developed the following proofs
  of concept (PoCs):

  1. A PoC that demonstrates the basic principles behind variant 1 in
 userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU,
 the AMD PRO CPU and an ARM Cortex A57. This PoC only tests for the
 ability to read data inside mis-speculated execution within the
 same process, without crossing any privilege boundaries.

  2. A PoC for variant 1 that, when running with normal user privileges
 under a modern Linux kernel with a distro-standard config, can
 perform arbitrary reads in a 4GiB range [3] in kernel virtual
 memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is
 enabled (non-default configuration), it also works on the AMD PRO
 CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be
 read at a rate of around 2000 bytes per second after around 4
 seconds of startup time.

  3. A PoC for variant 2 that, when running with root privileges inside
 a KVM guest created using virt-manager on the Intel Haswell Xeon
 CPU, with a specific (now outdated) version of Debian's distro kernel
 running on the host, can read host kernel memory at a rate of around
 1500 bytes/second, with room for optimization. Before the attack can
 be performed, some 

Re: [lfs-support] glibc-2.26 make install failed

[Michael Shell]

On Thu, 2 Nov 2017 20:26:57 +0100
Pierre Labastie  wrote:

> The text tells it removes a check that fails in the partial LFS environment.


  Pierre,

And is that check run during the installation step where his error
happened?

For the record, glibc-2.26 and later no longer installs a libnss_nis
by default:

https://bugs.archlinux.org/task/54592

"The NIS(+) name service modules, libnss_nis, libnss_nisplus, and
 libnss_compat, are deprecated, and will not be built or installed by
 default. Replacement implementations based on TIRPC, which
 additionally support IPv6, are available from
 ."


and also note for those upgrading an existing glibc:


"Since nsswitch.conf is a backup file for filesystem, wouldn't dropping
 the obsolete-nsl flag require a manual intervention for everyone with
 a modified nsswitch.conf? As I understand it now, breaking the 'compat'
 module would force all such users to correct it *before* they update
 to a new glibc, or they will become immediately unable to fix their
 system without booting from alternative media or using an emergency
 shell."


It's not clear to me what exactly the new glibc does not like
in "modified" nsswitch.conf. 

Of course, all should be well for a new LFS installation that
follows the book.


   Cheers,

   Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] ALFS: glibc-2.26, pass-1 fails

[Michael Shell]

On Fri, 22 Sep 2017 20:55:16 +0200
Pol Vangheluwe  wrote:

> cannot find crt1.o: No such file or directory
.
.
> The missing libs do exist on my system:
> 
> bash-4.3$ ls -l $LFS/tools/lib/crt*  
> -rw-r--r-- 1 lfs users 3084 Sep 20 11:16 /mnt/build_dir/tools/lib/crt1.o
> -rw-r--r-- 1 lfs users 2024 Sep 20 11:16 /mnt/build_dir/tools/lib/crti.o
> -rw-r--r-- 1 lfs users 1780 Sep 20 11:16 /mnt/build_dir/tools/lib/crtn.o
> 
> I have no idea why they are not found by the linker.


  Pol,

From

https://techoverflow.net/2013/02/28/how-to-fix-cannot-find-crt1-o-on-ubuntu/
https://stackoverflow.com/questions/40233088/ld-cannot-find-crt1-o-no-such-file-or-directory
https://stackoverflow.com/questions/7934642/cross-compile-cannot-find-crt1-o

Try putting the libary path in $LIBRARY_PATH:

LIBRARY_PATH=/mnt/build_dir/tools/lib:$LIBRARY_PATH
export LIBRARY_PATH

or just for make

LIBRARY_PATH=/mnt/build_dir/tools/lib make

also, you can try setting --sysroot= in CFLAGS during the build:

CFLAGS="--sysroot=/mnt/build_dir/tools" make


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS 8.1 binutils-pass1 Error 2. /tools problem?

[Michael Shell]

On Wed, 23 Aug 2017 01:14:21 +0100
Ken Moffat  wrote:

> You've been playing with solaris packages? Google thingks xpg4 is
> something to do with X/Open, but xpg4/bin gets mentioned in questions
> about the differences between multiple versions of common unix tools,
> usually on solaris, sometiems on HP-UX (for POSIX-compliant versions
> of the tools, where the old vendor-supplied versions are "limited").


For those interested, I found a good discussion about it here:

https://unix.stackexchange.com/questions/198905/when-to-use-xpg-version-of-a-command

The xpg versions are POSIX-compliant. The xpg directory is not generally
needed or used under Linux of FreeBSD because the default system utilities
in /bin and /usr/bin are already POSIX-compliant.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Michael Shell]

On Fri, 21 Jul 2017 08:46:35 +0200
Pierre Labastie  wrote:

> I'd say it is enough to remove the "build" directory. But if you keep
> the "build" directory, i'd say you are calling for trouble.


   Pierre,

You are right, after all, being able to keep the source tree pristine
is main incentive to use a build directory.

> However, GCC source is written in C++, so GCC needs libstdc++.
.
.
> The compiler *code* does not use threads (because it was generated by
> GCC pass 1, which has no thread capabilities, but the compiler *can*
> generate code using threads.

That mostly clears it up for me. Although I would say it as "The gcc
*executable* does not use threads ...". (FWIW, several times I caught
myself saying it the exact same way you did in what I wrote below.)

So, gcc pass 1 is linked against the host's libstdc++; and the purpose
of pass 2 is simply so that the new binutils and gcc are linked against
the new glibc and libstdc++.

And at the end of the GCC stage 2 build, a new gcc and a libstdc++ are
created and installed; and when this new libstdc++ is created and installed
as part of the gcc build process, it will overwrite the (nonthreaded) one
installed in section 5.8 and then both gcc and libstdc++ will support
threads (internally, as well as externally as compiled output). 

So, even though gcc pass 2 was *compiled* against a libstdc++ that did not
support threads (as that was built with gcc pass1), it still will be able
to use threads when it (gcc pass 2) is actually run, right?


Doesn't this have ramifications for upgrading gcc? For example, instead
of merely compiling and installing a new gcc, we should first upgrade
libstdc++ by itself as in section 5.8 (but with the \usr --prefix and maybe
even with thread support) and then compile and install the new gcc.
Otherwise, the new gcc will remain linked against the old libstdc++ even
though the gcc build also installs a new libstdc++, right?

It seems to me that libstdc++ should now be separated from gcc just like
glibc is.

> That's why libstdcc++ compilation for pass1 is deferred to after glibc
> build. But note that the just built glibc *has* all the libraries for
> thread support. It is only GCC pass1 that does not have the ability to
> generate code supporting threads, so that --disable-threads needs to
> be passed to libstdc++ pass 1.

OK, but this suggests there is a mistake in the LFS book. Specifically
in the libstdc++ step:

http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html

" --disable-libstdcxx-threads
  Since we have not yet built the C threads library, the C++ one cannot
  be built either.
"
  
  
This is wrong, right? As you note above the reason we have to disable threads
for libstdc++ is because gcc (pass 1) cannot yet output C++ executables or
libraries that utilize threads. glibc (either from the host system or that
installed in section 5.7), however, *does* already have thread support.

From the GCC configure manual:

https://gcc.gnu.org/install/configure.html

"--enable-threads
Specify that the target supports threads. This affects the Objective-C
compiler and runtime library, and exception handling for other languages
like C++."

So, only libstdc++ or other C++/Objective-C code that is to be compiled by
gcc is affected by a gcc configured with --disable-threads. The option does
not affect gcc's ability with regard to compiling threaded C code.


  Cheers and thanks,
  
  Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Michael Shell]

On Thu, 20 Jul 2017 18:48:20 -0400
"Isaac D. Cohen"  wrote:

> But then I decided to try, just to make sure, and redo the second pass
> of gcc with --enable-threads. After doing that I redid the compilation of
> glibc and got the same error. So that doesn't seem to be the problem.


  Isaac,

That first URL:

https://www.mail-archive.com/gcc@gcc.gnu.org/msg81240.html

gives a test program for gcc's threads ability.

Create a file, thread.cc, which contains


#include 
int main(int, char **){
std::thread tt;
}


and then try compiling it with:

g++ -std=c++11 thread.cc -lpthread -o x

which should work without error and produce the executable "x".

If that fails, then your gcc (or should I say, libstdc++) does not have
the proper thread support.

I note that in section 5.8 for Libstdc++-7.1.0 there is:

 "--disable-libstdcxx-threads
Since we have not yet built the C threads library, the C++
one cannot be built either."

Also, note the "--with-gxx-include-dir"

This initial version of libstdc++ will/must be overwritten later by
a full version from gcc. If that does not happen and your gcc is
still using this earlier limited version of libstdc++, then it will
not have thread support from the libstdc++ library no matter how
gcc itself was configured and compiled.

And watch out that in GCC pass 2 you started with a fresh unpacking
of the gcc tarball. (We have to do this, right?) After all, in the
Libstdc++-7.1.0 a ../libstdc++-v3/configure --disable-libstdcxx-threads
had been done in the pass 1 tarball's libstdc++-v3 subdirectory. Does
anyone know if those libstdc++ configure settings will remain or be
properly overridden if gcc's main directory configure is run - e.g.,
what if the LFS builder attempts to start gcc pass 2 with the existing
unpacked gcc tar ball from pass 1?


A question I now have is: At what point in the build process can
the LFS system (i.e., gcc) be expected to be able to compile the
thread.cc test above?

Is it after GCC-7.1.0 Pass 2, or is it only after the final build
of GCC?

If the former is true, then how can GCC-7.1.0 Pass 2 have thread
support when Glibc-2.25+adc7e06 has not yet been rebuilt (since
just after Pass 1, and libstdc++ could not be enabled with thread
support under that glibc)? And if the latter is true, how can the
final build of glibc be expected to pass make check if doing so
requires thread support in gcc/libstdc++ ?


  Cheers,

  Mike




-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] glibc compilation error (in chroo environmentt)

[Michael Shell]

On Tue, 18 Jul 2017 21:12:41 -0400
"Isaac D. Cohen"  wrote:

> make check. It compiled a little and then got stuck on this:
> 
> tst-thread_local1.cc: In lambda function:
> tst-thread_local1.cc:172:7: error: 'thread' is not a member of 'std'


  Isaac,

A google search found this:

https://www.mail-archive.com/gcc@gcc.gnu.org/msg81240.html
https://www.mail-archive.com/gcc@gcc.gnu.org/msg81257.html

 "Yes, I finally realized I had built a GCC with '--enable-threads=no'
  and was using that GCC to build GLIBC. Once I rebuilt GCC with threads
  I could build GLIBC and not get this error."


In the book, the first pass of gcc is built without thread support, but
thread support should be enabled for the second pass (5.10.1).



  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] My finished LFS-7.10 x86-64 build

[Michael Shell]

> So it must be the kernel's crypto functions tripping over it, and I
> can understand new instruction set evolutions wouldn't be
> backwards-compatible.  Still, if gcc weren't trying to embed those
> instructions in the kernel and were just setting the kernel up to use
> gmplib, it seems more likely they would be a runtime error.


  Paul,

I don't think gcc ever exports any gmp code into its output. Rather, gcc
just uses gmp for its own internal purposes.

I searched the net for why gcc needs gmp and found this:

https://stackoverflow.com/questions/15826628/why-does-gcc-require-gmp

which states that under C, gcc uses gmp for (1) constant calculations;
and (2) optimization calculations. So, if for the code to be compiled,
gcc only uses gmp under C compilation for optimization, then one might
be able to get around an "incompatible-CPU-compiled" gmp if one
disables gcc optimization:

CFLAGS='-O0'
CXXFLAGS='-O0'

This might be helpful if you just need to recompile something (maybe even
gmp itself) to rescue a "hosed" machine. Then, after gmp is working, you
can recompile it again with normal optimizations.

(If you ever try this, do let us know if it works as it might help someone
 out of a jam one day.)

However, it likely won't work if the code in question uses constant/macro
math because gcc uses gmp for that too.

In the case of your kernel compile failure:

> drivers/gpu/drm/i2c/ch7006_mode.c:51:3: internal compiler error: Illegal
> instruction
> NTSC_LIKE_TIMINGS,
>   ^

and in drivers/gpu/drm/i2c/ch7006_mode.c we find:

#define NTSC_LIKE_TIMINGS .vrefresh = 60 * fixed1/1.001,\
.vdisplay = 480,\
.vtotal = 525,  \
.hvirtual = 660

where fixed1 is defined in ch7006_priv.h to be:

#define fixed1 (1LL << 32)

where LL means "long long" (or 64 bits).

All gcc has to do here is to evaluate the .vrefresh constant. So, it seems
that gcc tried to use gmp to do the  "60 * (1LL << 32)/1.001" constant
calculation and this is what triggered the problem.


  Cheers,

  Mike
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] My finished LFS-7.10 x86-64 build

[Michael Shell]

On Tue, 04 Jul 2017 14:47:16 -0700
Paul Rogers  wrote:

> I do find it ironic the kernel has to do these strange math calculations
> no other packge uses, except apparently gmp.


Not the kernel code per say, but rather gcc while compiling a kernel.
And gcc in turn calls on gmp to do those calculations (for gcc).

Kernel code tends to dictate/control things at the lower levels 
(e.g., directly inserted assembly code, variables held in specific
CPU registers, "volatile" memory regions, etc.) more than is typical
in normal applications. Perhaps these kinds of special compile
requirements things cause gcc to lean more heavily on gmp in certain
areas thus triggering the problem.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Booting from EFI Hints

[Michael Shell]

On Thu, 25 May 2017 10:52:28 -0600
Alan Feuerbacher  wrote:

> Grub, which loads vmlinuz-4.9.9-lfs-8.0 
> rEFInd, which loads grub, which loads vmlinuz-4.9.9-lfs-8.0 
> Each of the two methods results in the same kernel startup messages and 
> then a hang.


I would try booting directly to a root shell using grub:

https://askubuntu.com/questions/15284/how-to-boot-to-root-shell-when-grub-recovery-menu-fails-to-load-a-shell

linux init=/bin/sh

This way, you should be able to isolate kernel/keyboard problems from
system setup problems.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Using an SSD with LFS

[Michael Shell]

On Sat, 29 Apr 2017 00:29:00 +0100
Ken Moffat  wrote:

> Thanks to both of you for this thread - I had assumed that only
> DataCenter-grade products (as in "unaffordable") were nvme, and those
> (of course) have ridiculous prices.


Bearing in mind that I haven't played with SSD's (yet), but looking
around the web I found this:

https://www.newegg.com/Product/Product.aspx?Item=N82E16820236156

Corsair Force MP500 M.2 2280 120GB, M.2 2280, PCI-Express 3.0 x4,
for $85 (they do have larger versions). Pulls < 5 Watts so it should
run cool.

And also:

https://www.newegg.com/Product/Product.aspx?Item=N82E16815124167_re=PCIe_M.2_adapter-_-15-124-167-_-Product

a Syba SI-PEX40110 M.2 PCI-e SSD to PCI-e bus adapter card.
Will work with PCI-e versions below 3.0, although with some speed loss.
From the reviews, it seems that the integrated M.2 slot on some
motherboards is not as fast as it could be (800Mb/s read versus
3072Mb/s with the card) and so this $15 card can greatly speed things
up in those cases as well as keep the SSD cooler if the motherboard's
M.2 slot is close to the graphics card, CPU, etc.


  Cheers,

  Mike Shell


-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Using an SSD with LFS

[Michael Shell]

On Mon, 24 Apr 2017 13:28:36 -0500
Bruce Dubbs  wrote:


> As for performance, I once did an automated build in a ramdisk. There
> was no IO other than to RAM.  The total speedup was 8% which is barely 
> noticeable if at all.  LFS is CPU bound.


  Bruce,

Not to suggest that your results are anything less than the perfect truth
of the reality of the matter, but I'm a bit surprised by this. Can I ask
what kind of hard drive you had - was it anything especially fast?

Also, I think memory speed is a very important and grossly underrated 
performance parameter. One could do a kernel compilation and compare
the results between various memory speed settings as a test. In fact,
I suspect that many online performance tests and benchmarks skew their
results (say to favor Intel over AMD, or whatever CPU they want to
show in a better light) by using a lower memory speed motherboard
setting with the "designated loser" than the actual RAM is rated for.
Most readers will focus on the CPU clock speed and will miss such a
difference.


   Cheers,

   Mike

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] LFS Installation on Latest Hardware

[Michael Shell]

On Sun, 23 Apr 2017 16:07:42 -0600
Alan Feuerbacher  wrote:

> Ultimately I want to jettison Microsoft stuff.

Amen to that. There comes a point with MS stuff when one finally 
gets the feeling of being a victim in some sort of a sick, and
ever more costly, joke.


  Cheers,

  Mike
 
 
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Building LFS on a Samsung laptop. Hey, no more segfaults!

[Michael Shell]

On Fri, 7 Apr 2017 19:24:55 -
"William Harrington"  wrote:

> gcc -### -march=native -E /usr/include/stdlib.h 2>&1 | grep
> "/usr/libexec/gcc/.*cc1"
>  "/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1" "-E" "-quiet"


And in the /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0 directory,
he can look at what is linked against gcc's cc1 and cc1plus:

ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1
ldd /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus

Any those linked libraries is a suspect. If it wasn't glibc (libm,
linux-gate are from glibc, libdl is from gcc) or gmp, then I think
libmpc, libmpfr would be the likeliest culprits. Libz is also listed.


  Cheers,

  Mike Shell
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] Building LFS with an existing toolkit

[Michael Shell]

On Wed, 22 Mar 2017 17:26:38 +0100
Michele Bucca  wrote:

> Not all BIOSES support GPT. My old PC (2007) is still using a BIOS and does
> not support GPT I guess


AFAIK, it does not really matter if a BIOS recognizes a GPT - well,
unless you want to be able select a specific *partition* within the BIOS
boot options and AFAIK many/most BIOSes don't even support boot selection
for anything other than at the *drive* (MBR) level anyway.

The idea is that the boot loader, installed in the MBR at the start of
the boot disk (and even GPT disks still have an MBR where a boot loader
can be placed), is what actually selects which partition (or should I say
other sectors) to boot (load). So, as long as the boot loader can do
it's job, it really does not matter if the BIOS knows what the heck
a GPT is.

Furthermore, surprisingly enough, even the boot loader itself does not
have to understand GPT. For example, the venerable LILO boot loader can
work with with GPT disks because all it does is load in the requested
sector numbers for the second stage boot loader and then does the
same for the specific kernel image to load. As long as the BIOS can
retrieve the requested boot sectors from the bootloader by absolute
sector numbers alone, the boot system should work. 

And LILO et al. will "understand" what and where the partitions are as
long as the kernel does as in /dev/sXY when LILO et al. is run to
install the loader. i.e., GPT aware kernel = GPT compatible LILO,
at least when LILO is booted from an MBR (even the one within a
GPT disk).

Other than RAID setup problems, the main limitation with older boot
loaders such as LILO is that using 32bit sector numbers means that
it can only "reach" the first 2TB of drives using 512 bytes/sector.
That issue can be overcome, at least for Linux only systems, by
ensuring that /boot is a partition of it's own located within the
first 2TB. (Again, once we can get a kernel image into memory, we're
pretty much good to go as far as the boot process goes.)

Also, I don't know if LILO or the other older boot loaders can
handle modern 4096 byte / sector drives - and then there is the
512 byte/sector "emulation" angle on such modern drives.


Anyway, there seem to be only two potential problems with older BIOSes
with GPT disks, and they are both uncommon:

http://www.rodsbooks.com/gdisk/bios.html

One is that certain BIOSes want to see a bootable partition which won't
exist on standard GPT disks. This problem can be overcome simply by
setting the bootable flag on the protective MBR partition of the GPT
disk (via the experts' menu of gdisk).

Some uncommon older motherboards (e.g., Biostar PT880 Pro-A7, circa 2006)
require "believable" ancient C/H/S (cylinders, heads, sectors per track)
drive geometry info even though the system/drive is using the modern
sane LBA (sector number) addressing. Again, this can be overcome by
setting the protective MBR on a GPT disk to have the needed fake
(and meaningless anyway on drives made in the last 20-30 years) CHS
values (again via the experts' menu of gdisk).

In short, the uncommon BIOS problems with GPT can be overcome by
setting appropriate "lies" in the protective MBR using gdisk.


While on the subject, anyone else out there also think that UEFI is
overly complicated BS? - all they ever needed to do was extend the
old MBR system to overcome the partition number, sector addressing,
and first stage MBR boot loader size and number limitations:

http://yarchive.net/comp/linux/efi.html

  "From: Linus Torvalds
   EFI is this other Intel brain-damage (the first one being ACPI).
   It's totally different from a normal BIOS, and was brought on
   by ia64, which never had a BIOS, of course.

   Sadly, Apple bought into the whole "BIOS bad, EFI good" hype, so
   we now have x86 machines with EFI as the native boot protocol."


UEFI still does not overcome the need have to load any special drivers 
required to access add-on card boot devices (as if that were even
possible - we can't expect a system to be able to use hardware it
hasn't been taught to understand), and once a kernel can be loaded
into memory with all needed drivers, we're home free anyway.

Booting just boils down to just being able to select arbitrary blocks
of data (kernel images, each still only about 20MB of typical size
today) to load into memory and then execute.

Wouldn't have been better to have, say, a standard SDcard slot - a
"universal memory boot device (UMBD)" - on the motherboard which
can contain "files" of OS (kernel) images or boot loaders. The
images could be "addressed" by sector numbers alone, like memory
and not even need or use any specific filesystem. (IIRC, Grub
does something like this with its special EF02 "BIOS boot
partition".)

The BIOS could then select which SDcard image to load into memory
and execute it. One could also use one "OS image" for a more
sophisticated custom boot loader and then get any boot prompt,
custom logo, etc. from that 

Re: [lfs-support] How can I set hostname?

[Michael Shell]

On Wed, 15 Feb 2017 17:08:31 -
"William Harrington"  wrote:

> Does the network interface need to be restarted for the change to show in
> the shell?

Not on my system - the change shows up as soon as I:

> > echo testhost > /proc/sys/kernel/hostname
> > exec /bin/bash
> > export PS1="[\u@\h]: "

but this just is for bash, not networking.

AFAIK, when it starts, bash asks for the hostname via the C-library
gethostname() system call which in turn asks the kernel. The kernel
will report whatever hostname was written to /proc/sys/kernel/hostname,
or by a prior call to sethostname(), and bash will then set its \h and
\H prompt variables to that value.

Also, from a net search, it seems the proper way to restart bash (to
update \h et al.) is indeed to replace it with a new running version
of itself:

exec /bin/bash

I'd be interested to know if there is any quick "restart" bash builtin
like there is for reset (terminal reset) and source (reread a given
bash config file). As I currently understand things, there isn't.


On Wed, 15 Feb 2017 03:58:33 +
Ken Moffat  wrote:

> Apart from what has already been said, you didn't tell us what
> you have managed to do (e.g. with init=/bin/bash you end up
> with a read-only root filesystem - I get the impression you
> have gone past that). So everybody is guessing.


Assuming that there isn't any malfeasance here such as trolling, etc.,
my own best guess is that his case is for an embedded system (hence
the desire for secrecy and low level control). So, he doesn't need all
the startup scripts of a full desktop and wants to be able to
control/specify everything that is done on startup.

If nothing else, the topic is educational.

If I had to guess what is going wrong with ssmtpmailtesting's attempt
here it would be that either bash was not restarted (because it is
serving as init) after the host name was changed and/or that he
doesn't have a /proc filesystem and did not think to use the
hostname utility in conjuction with my suggestion to restart bash
via exec:

hostname testhost
exec /bin/bash

From here:

http://superuser.com/questions/200057/how-to-make-bash-update-its-idea-of-hostname

another approach is to set the $HOSTNAME variable and the system/kernel
hostname and then set the bash prompt to print the value of $HOSTNAME
rather than relying on \h which it seems can only be altered during
bash startup:

export HOSTNAME="testhost"
hostname "$HOSTNAME"
export PS1="[\u@$HOSTNAME]: "

which also does work immediately on my system. Note that in
the above, PS1 will be set to the *current* value of $HOSTNAME so
if $HOSTNAME is ever later changed, $PS1 should also be set again.

FWIW, there is some other good info on setting the hostname here:

http://jblevins.org/log/hostname

In this case, it might be helpful to have a kernel parameter to
set the hostname on boot (e.g., hostname=.. but as far as I know
there isn't a hostname kernel parameter). I don't know if the
kernel parameter ip= will do the trick here.

He could also write a custom little C init program that will make all
the needed config system calls and then fork to bash or some other
application after everything was configured. Such an approach would
be like having a little custom "flat file" mini-systemd.


  Cheers,

  Mike Shell



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] How can I set hostname?

[Michael Shell]

On Tue, 14 Feb 2017 12:02:45 +0600
ssmtpmailtesting ssmtpmailtesting  wrote:

> I added: echo myhostname > /proc/sys/kernel/hostname
> Still same prompt = root@(none)
> But if I install lfs-bootscript, then it changes to root@myhostname.
> I also added /etc/fstab and /etc/inittab
> 
> Did I miss anything?


AFAIK, bash (if you are running a different shell than bash, let us
know) does get the hostname information from the kernel and that that
can be set via writing to /proc/sys/kernel/hostname. An instance of bash
also sets its variable $HOSTNAME to the hostname it found when it started
up. However, do remember that already running instances of bash will need
to be restarted *after* the system/kernel hostname is changed for them to
see the new name.

For example, as root in a bash prompt:

echo testhost > /proc/sys/kernel/hostname
exec /bin/bash
export PS1="[\u@\h]: "

should then yield a 

[root@testhost]:

prompt. If not, what does your

cat /proc/sys/kernel/hostname

say? It should be

testhost

If you don't have a /proc/sys/kernel/hostname file on system startup,
then the kernel may not have proc support and you will either have to
enable that feature or set the host name using a utility that calls
the sethostname() C-library system call (such as /bin/hostname, from
inetutils, as William Harrington suggested).

On Tue, 14 Feb 2017 13:16:12 +0100
Michele Bucca  wrote:

> try this as root:
> echo hostname > /etc/hostname

I think the startup scripts grab the host name from /etc/hostname,
but he doesn't want to use any startup scripts. AFAIK, bash
et al. does not look at /etc/hostname at all.

Does anyone know if any common shell or application does look at
/etc/hostname? If so, he will indeed have to set that one too.



   Mike



-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] How can I set hostname?

[Michael Shell]

On Mon, 13 Feb 2017 07:34:07 +0600
ssmtpmailtesting ssmtpmailtesting  wrote:

> How is hostname set? I'm not using lfs-bootscripts. After login, I see
> root@(none). Why is this? If I do sysctl kernel.hostname, it shows
> can't open /proc/sys... no such file or directory. But /etc/hostname
> has "myhostname".


echo myhostname > /proc/sys/kernel/hostname 

sets the hostname to myhostname. You can read the hostname via

cat /proc/sys/kernel/hostname
 
There is also a /proc/sys/kernel/domainname

If you don't have the /proc/sys filesystem, you'll have to enable
that feature in the kernel.


  Cheers,

  Mike Shell

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style