Re: [lfs-support] Booting LFS with systemd - SOLVED

2018-08-05 Thread DJ Lucas

On 07/25/2018 11:41 AM, Frans de Boer wrote:


I remember that we only need doxygen as an additional package to build 
systemd without the LFS patch, right?


It is libxslt that is needed to build the man pages. Additionally, the 
test suite is disabled for part of the build due to lack of 
dependencies. As far as pre-generating the man-pages, it is simply built 
on a system that has the tools available, then the target (build/man 
IIRC) is tarred up so that we can bypass building of the man pages 
(temporarily linking /usr/bin/xsltproc to /tools/bin/true). The one 
patch for systemd is new for glibc-2.28.


--DJ

--
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 - SOLVED

2018-07-25 Thread Frans de Boer

On 07/24/2018 01:01 AM, Ken Moffat wrote:

On Mon, Jul 23, 2018 at 05:20:41PM -0500, Douglas R. Reno wrote:

On Thu, Jul 19, 2018 at 8:47 AM Frans de Boer  wrote:


This quite frustrating. After recompiling, following the book to the
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after
systemd has detected that it is on a virtual machine. A number of
error messages is send, but due to ratelimiting I can't see them
because they are suppressed.

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

Help?

Frans,

Can you please try systemd-239? It should show up in the render tomorrow
morning (US Central time, I'm not sure what it is in UTC).

I'll make sure it lands in BLFS here in the coming days, just extremely
busy outside of LFS.

If that does't help, now that I've had to apply a workaround
to two of my sysv systems to speed booting (lack of entropy on some
machines with integrated video and only an SSD) I've got an
alternative suggestion - if the kernel is 4.17 or later, or 4.16.4
or later, or (perhaps) 4.14.36 or later, it contains a CVE fix which
ensures that getrandom() will not return until the CRNG is properly
initialised.

That is reported to severely impact _some_ VMs' startup times.

The easiest workaround is to install haveged in chroot, and its
systemd file in your case.  If that is the problem, people differ
about the quality of what haveged provides - if you need to generate
long-lived security kees (e.g. for gpg) in the VM see
https://lkml.org/lkml/2018/7/23/857 (Ted Ts'o's reply to me when I
suggested that if I had to use haveged the boot was fast but didn't
it weaken future entropy?)

ĸen


Thanks to the availability of systemd-239 and the fact that finally the 
patch regarding the man-pages is available, I can now confirm that all 
is well again with systemd-239.
Thus, it was a systemd problem, I have tried the standard systemd-239 a 
long time ago, but since I have no idea how to make the specific patches 
to for LFS, I could not build that. Maybe make it clear what is done to 
make the specific systemd patch or is it a lot of hand work?


I remember that we only need doxygen as an additional package to build 
systemd without the LFS patch, right?


Regards, Frans.

--
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

2018-07-23 Thread Ken Moffat
On Mon, Jul 23, 2018 at 05:20:41PM -0500, Douglas R. Reno wrote:
> On Thu, Jul 19, 2018 at 8:47 AM Frans de Boer  wrote:
> 
> >  This quite frustrating. After recompiling, following the book to the
> >  letter, I still get a frozen LFS system.
> >  One thing I do note however is that the freezing always occurs after
> >  systemd has detected that it is on a virtual machine. A number of
> >  error messages is send, but due to ratelimiting I can't see them
> >  because they are suppressed.
> > 
> >  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
> > 
> >  Help?
> > >>>
> >
> Frans,
> 
> Can you please try systemd-239? It should show up in the render tomorrow
> morning (US Central time, I'm not sure what it is in UTC).
> 
> I'll make sure it lands in BLFS here in the coming days, just extremely
> busy outside of LFS.

If that does't help, now that I've had to apply a workaround
to two of my sysv systems to speed booting (lack of entropy on some
machines with integrated video and only an SSD) I've got an
alternative suggestion - if the kernel is 4.17 or later, or 4.16.4
or later, or (perhaps) 4.14.36 or later, it contains a CVE fix which
ensures that getrandom() will not return until the CRNG is properly
initialised.

That is reported to severely impact _some_ VMs' startup times.

The easiest workaround is to install haveged in chroot, and its
systemd file in your case.  If that is the problem, people differ
about the quality of what haveged provides - if you need to generate
long-lived security kees (e.g. for gpg) in the VM see
https://lkml.org/lkml/2018/7/23/857 (Ted Ts'o's reply to me when I
suggested that if I had to use haveged the boot was fast but didn't
it weaken future entropy?)

ĸen
-- 
   Entropy not found, thump keyboard to continue

-- 
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

2018-07-23 Thread Douglas R. Reno
On Thu, Jul 19, 2018 at 8:47 AM Frans de Boer  wrote:

> On 06-07-18 16:44, Bruce Dubbs wrote:
> > On 07/06/2018 01:20 AM, Frans de Boer wrote:
> >> On 07/05/2018 11:56 PM, Bruce Dubbs wrote:
> >>> On 07/05/2018 02:48 PM, Frans de Boer wrote:
>  On 06/30/2018 01:29 PM, Hazel Russman wrote:
> > On Fri, 29 Jun 2018 01:25:29 -0400
> > Michael Shell  wrote:
> >
> >> 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).
> >>
> >> .
> >>
> >> 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.
> >>
> > ...
> >>Cheers,
> >>
> >>Mike
> >>
> >> --
> > I did a git bisect on my system, but I couldn't make much sense of
> > the result. The commit it finally settled on didn't seem to have
> > anything to with acpi.
> >
> > [quote]
> > 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]
> >
> > I sent the result to the kernel acpi development list but never got
> > an answer. If someone else on this list wants to try, I can send
> > him my complete bisect logs.
> >
> > --
> > Hazel
>  This quite frustrating. After recompiling, following the book to the
>  letter, I still get a frozen LFS system.
>  One thing I do note however is that the freezing always occurs after
>  systemd has detected that it is on a virtual machine. A number of
>  error messages is send, but due to ratelimiting I can't see them
>  because they are suppressed.
> 
>  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
> 
>  Help?
> >>>
> >>> I don't mean to be pedantic, but I really don't think you would run
> >>> into these types of problems using System V.  Why not try that?
> >>>
> >>>   -- Bruce
> >>>
> >> Hi Bruce,
> >> With System V there is - of course - no problem. The thing is that
> >> systemd - if it runs well - is somewhat easier to use because of the
> >> use of .service files.
> >
> > I'll have to disagree that service files are easier.  What I do agree
> > with is that they are more consistent among distros.  The boot scripts
> > for System V are really quite easy to read and, if needed, write.
> >
> >   I also noticed that some packages are only shipping
> >> .service(.in) files and have abandon the use of sysVinit files.
> >
> > Then they are abandoning those distros that do not use systemd such as
> > the BSDs and Devuan.  But those distros can easily add their own boot
> > scripts.  I'll note that all the BLFS packages that need boot scripts
> > have them,
> >
> >> Combined with the fact that most distributions have embraced systemd
> >> as their primary or only init system let me believe that we are stuck
> >> with this piece of ever growing mutation. And as LFS is a teaching
> >> ground, it should - however reluctant - incorporated this too.
> >
> > As a teaching tool, NOT using systemd is essential.  There is far too
> > much done by systemd in an opaque manner that System V demonstrates and,
> > if desired,implemented in custom ways.
> >
> >> Also, the goal is that someone fire-up their basic hardware with a LFS
> >> born OS, but for testing or use in VM's development is nowadays mostly
> >> within the VM realm.
> >
> > When I teach LFS in class, I always have the students use real HW, There
> > are too many things that VMs hide,
> >
> >-- Bruce
> >
> Bruce,
>
> I agree that VM's hide some issues and I do understand you position
> about systemd. Although I disagree to some level. After all, should we
> learn people how to crackup a (very) old car or the new generally
> available way using some sort of key. Just focusing only on System V is
> precisely what industries mean when they talk about "they are not being
> taught the modern technics.".
> Remember the days past, the discussion of having systemd included in the
> LFS book? Eventual it was included. Now the next "new" thing maybe?
>
> Why not using VM's when one can continue developing without having to
> reboot into an incomplete system environment.

Re: [lfs-support] Booting LFS with systemd

2018-07-19 Thread Frans de Boer

On 06-07-18 16:44, Bruce Dubbs wrote:

On 07/06/2018 01:20 AM, Frans de Boer wrote:

On 07/05/2018 11:56 PM, Bruce Dubbs wrote:

On 07/05/2018 02:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--
I did a git bisect on my system, but I couldn't make much sense of 
the result. The commit it finally settled on didn't seem to have 
anything to with acpi.


[quote]
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]

I sent the result to the kernel acpi development list but never got 
an answer. If someone else on this list wants to try, I can send 
him my complete bisect logs.


--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of 
error messages is send, but due to ratelimiting I can't see them 
because they are suppressed.


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


Help?


I don't mean to be pedantic, but I really don't think you would run 
into these types of problems using System V.  Why not try that?


  -- Bruce


Hi Bruce,
With System V there is - of course - no problem. The thing is that 
systemd - if it runs well - is somewhat easier to use because of the 
use of .service files.


I'll have to disagree that service files are easier.  What I do agree 
with is that they are more consistent among distros.  The boot scripts 
for System V are really quite easy to read and, if needed, write.


  I also noticed that some packages are only shipping
.service(.in) files and have abandon the use of sysVinit files. 


Then they are abandoning those distros that do not use systemd such as 
the BSDs and Devuan.  But those distros can easily add their own boot 
scripts.  I'll note that all the BLFS packages that need boot scripts 
have them,


Combined with the fact that most distributions have embraced systemd 
as their primary or only init system let me believe that we are stuck 
with this piece of ever growing mutation. And as LFS is a teaching 
ground, it should - however reluctant - incorporated this too.


As a teaching tool, NOT using systemd is essential.  There is far too 
much done by systemd in an opaque manner that System V demonstrates and, 
if desired,implemented in custom ways.


Also, the goal is that someone fire-up their basic hardware with a LFS 
born OS, but for testing or use in VM's development is nowadays mostly 
within the VM realm.


When I teach LFS in class, I always have the students use real HW, There 
are too many things that VMs hide,


   -- Bruce


Bruce,

I agree that VM's hide some issues and I do understand you position 
about systemd. Although I disagree to some level. After all, should we 
learn people how to crackup a (very) old car or the new generally 
available way using some sort of key. Just focusing only on System V is 
precisely what industries mean when they talk about "they are not being 
taught the modern technics.".
Remember the days past, the discussion of having systemd included in the 
LFS book? Eventual it was included. Now the next "new" thing maybe?


Why not using VM's when one can continue developing without having to 
reboot into an incomplete system environment. Also, if one has multiple 
systems to spare, bare metal can be a way. If not, VM's are a welcome 
solution.


So, I think that I am chasing the wrong ghost and have a talk with the 
systemd developers instead. Despite the lack of interest for using VM's, 
I shall share any positive result with the LFS list.


Regards, Frans.
--
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 t

Re: [lfs-support] Booting LFS with systemd

2018-07-17 Thread 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] Booting LFS with systemd

2018-07-16 Thread Hazel Russman
On Mon, 16 Jul 2018 03:10:49 -0400
Michael Shell  wrote:

> 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. > 
> 
>   Cheers,
> 
>   Mike
> -- 
Turns out this was a bug that got fixed quickly! 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). So I don't particularly want to waste time chasing it.

What I wanted out of all this was the kernel native to each of my distros 
booting with full acpi functionality and no panics. Like it used to do before 
all this happened. And now I have that.

We'll see if the kernel hackers have need of any further action on my part. 
I'll be happy to do what I can for the community. But in any case I owe you a 
big thank-you for all your help.


-- 
Hazel
-- 
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

2018-07-16 Thread 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

2018-07-14 Thread Bruce Dubbs

On 07/14/2018 03:57 PM, Ken Moffat wrote:

On Sat, Jul 14, 2018 at 03:43:14PM -0500, Bruce Dubbs wrote:


Try using a separate partition that is not raid for the root partition. It's
only 5-10 Gb.  Recovering a failed root partition from a backup should be
very straight forward if it fails.


Size depends on what goes in separate partitions, and what you
build.  With /boot, /home, /sources (but not /opt) on separate
filesystems I find 5 GB would have been enough for my server.  But
my desktops have mostly had the root partition increased to 25 GB
because 20GB was becoming too restrictive.


Putting /opt and /var on a separate partition should reduce things 
greatly.  And, of course, LFS still supports a separate /usr.


[ / ]$ sudo du -sh bin etc lib lib64 root sbin
23M bin
22M etc
65M lib
4.0Klib64
39M root
32M sbin

It would be an interesting experiment, but it looks like I could get by 
with a root partition of less than 200 Mb.


  -- Bruce

--
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

2018-07-14 Thread Ken Moffat
On Sat, Jul 14, 2018 at 03:43:14PM -0500, Bruce Dubbs wrote:
> 
> Try using a separate partition that is not raid for the root partition. It's
> only 5-10 Gb.  Recovering a failed root partition from a backup should be
> very straight forward if it fails.
> 
Size depends on what goes in separate partitions, and what you
build.  With /boot, /home, /sources (but not /opt) on separate
filesystems I find 5 GB would have been enough for my server.  But
my desktops have mostly had the root partition increased to 25 GB
because 20GB was becoming too restrictive.

ĸen
-- 
  Keyboard not found, Press F1 to continue
-- 
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

2018-07-14 Thread Bruce Dubbs

On 07/14/2018 03:22 PM, Tim Tassonis wrote:

On 07/12/2018 07:03 PM, Bruce Dubbs wrote:

On 06/27/2018 04:42 PM, Paul Rogers 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:


Correct me if I'm wrong, but I thought the only good reason for an 
initramfs is so a totally generic kernel could be built with every 
possible device driver for any unpredictable hardware out there as 
modules, then with discovery keep only those modules with the running 
kernel and dump the rest.


That's generally correct, but the initrd is also used for other things 
than just drivers.  It can be used for mounting a root filesystem that 
is encrypted or be needed with LVM or other custom filesystems or for 
finding a partition identified with a UUID.


I also seem to be needing it when having the root partition on an md 
raid device. I have not yet found a way to mount it without an initrd, 
but maybe I am doing something wrong?


Try using a separate partition that is not raid for the root partition. 
It's only 5-10 Gb.  Recovering a failed root partition from a backup 
should be very straight forward if it fails.


  -- Bruce

Apart from that, compiling with SATA/IDE and ext4 not as modules, none 
of my boxes ever needed an initramfs, even if I have all the rest as 
modules.


Cheers
Tim


--
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

2018-07-14 Thread Tim Tassonis

On 07/12/2018 07:03 PM, Bruce Dubbs wrote:

On 06/27/2018 04:42 PM, Paul Rogers 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:


Correct me if I'm wrong, but I thought the only good reason for an 
initramfs is so a totally generic kernel could be built with every 
possible device driver for any unpredictable hardware out there as 
modules, then with discovery keep only those modules with the running 
kernel and dump the rest.


That's generally correct, but the initrd is also used for other things 
than just drivers.  It can be used for mounting a root filesystem that 
is encrypted or be needed with LVM or other custom filesystems or for 
finding a partition identified with a UUID.


I also seem to be needing it when having the root partition on an md 
raid device. I have not yet found a way to mount it without an initrd, 
but maybe I am doing something wrong?


Apart from that, compiling with SATA/IDE and ext4 not as modules, none 
of my boxes ever needed an initramfs, even if I have all the rest as 
modules.


Cheers
Tim
--
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

2018-07-14 Thread Hazel Russman
On Sat, 14 Jul 2018 05:43:55 -0400
Michael Shell  wrote:

> 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;
> 
That works (hallelujah!) up to a point. 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. We've 
certainly identified the locus of the problem. 
> 
> 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()).

No, that doesn't work. The compiler doesn't like the sme_active() function and 
crashes the build. However istr that there was an sme header that was deleted 
in the original patch. Maybe that needs to be reinstated to make your condition 
work. I'll check up on that.

> 
> 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.
> 
Before I go any further, I want to try the same fix on the 4.15 kernel which is 
the native one for LFS 8.2. If that works (apart from any mouse problems), I'll 
contact the people you name.

Thanks for all your help.

-- 
Hazel
-- 
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

2018-07-14 Thread 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

2018-07-13 Thread Hazel Russman
On Fri, 13 Jul 2018 08:26:01 +0100
Ken Moffat  wrote:

> On Fri, Jul 13, 2018 at 12:47:50AM -0400, Michael Shell wrote:
> > 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).
> >   
Gentlemen, I have a confession to make. Over the past two days I have repeated 
the bisect (for safety) and it turns out that the original one was terminated 
prematurely. That's what happens when you have people blindly following 
instructions and not really knowing what they are doing!

The actual "guilty party" is the *next* commit -- which is why the one I 
reported before didn't seem relevant. Here is the final end:

# good: [872cbefd2d9c52bd0b1e2c7942c4369e98a5a5ae] x86/cpu/AMD: Add the Secure 
Memory Encryption CPU feature
git bisect good 872cbefd2d9c52bd0b1e2c7942c4369e98a5a5ae
# good: [7744ccdbc16f0ac4adae21b3678af93775b3a386] x86/mm: Add Secure Memory 
Encryption (SME) support
git bisect good 7744ccdbc16f0ac4adae21b3678af93775b3a386
# bad: [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() 
usage in ioremap()
git bisect bad 33c2b803edd13487518a2c7d5002d84d7e9c878f
# first bad commit: [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm:
Remove phys_to_virt() usage in ioremap()

When I do "bisect show" I get:
 "Currently there is a check if the address being mapped is in the ISA range 
(is_ISA_range()), and if it is, then phys_to_virt() is used to perform the 
mapping. When SME is active, the default is to add pagetable mappings with the 
encryption bit set unless specifically overridden. The resulting pagetable 
mapping from phys_to_virt() will result in a mapping that has the encryption 
bit set. With SME, the use of ioremap() is intended to generate pagetable 
mappings that do not have the encryption bit set through the use of the 
PAGE_KERNEL_IO protection value.

Rather than special case the SME scenario, remove the ISA range check and usage 
of phys_to_virt() and have ISA range mappings continue through the remaining 
ioremap() path."

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

I suppose I now need to find the patch and revert it by hand and see what that 
does. I plan to do that today. Thank you for all your help so far.
-- 
-- 
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

2018-07-13 Thread Frans de Boer

On 13-07-18 16:24, Michael Shell wrote:

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

In order to use gdb, I need to compile it in. However, I now am stuck at 
glibc not compiling when following the LFS instruction is chapter six 
exactly.


So, I need that to be fixed first, then I need tlc, expect, deganu and 
gdb to be compiled in to even load it.


--- Frans.
--
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

2018-07-13 Thread 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

2018-07-13 Thread 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

2018-07-13 Thread 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

2018-07-13 Thread Frans de Boer

On 06-07-18 08:23, Frans de Boer wrote:

On 07/06/2018 05:32 AM, Michael Shell wrote:

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


Hi Mike,
I will follow your suggestions, of which few are new to me, and will 
come back with a report.


--- Frans

I get the following error:

...
bison --yacc --name-prefix=__gettext --output 
/sources-lfs/glibc-2.27/glibc-build/intl/plural.c plural.y

bison: m4 subprocess failed: No such file or directory
make[2]: *** [Makefile:46: 
/sources-lfs/glibc-2.27/glibc-build/intl/plural.c] Error 1

make[2]: Leaving directory '/sources-lfs/glibc-2.27/intl'
make[1]: *** [Makefile:215: intl/subdir_lib] Error 2
make[1]: Leaving directory '/sources-lfs/glibc-2.27'
make: *** [Makefile:9: all] Error 2

If I include 'ln -sfv /tools/bin/m4 /usr/bin' as suggested some time 
ago, I can compile glibc. 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.


Is this a result of some modification in the tool chain, or is de 
documentation not upto date?


--- Frans.
--
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

2018-07-13 Thread Ken Moffat
On Fri, Jul 13, 2018 at 12:47:50AM -0400, Michael Shell wrote:
> 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).
> 

At the risk of teaching people to suck eggs ...

If someone has the git tree (either Greg's stable tree for a
particular minor version, or Linus's tree for .0) the suspected
commit can be viewed with

 git show 7744ccdbc16f

(in stable trees, backported commits will have a different hash).

Assuming that command does show the suspected commit,

 git show 7744ccdbc16f >/tmp/suspect1

then view /tmp/suspect1 to confirm it, and

 cat /tmp/suspect1 | patch -p1 -R --dry-run

(other invocations are available, but I like pipes)

to see if it will revert cleanly.  If it does, revert it, rebuild
the kernel, see if it fixes the problem.

> 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
> 

No.  For context diffs in the kernel, there have been several
instances where a hunk (of an update, but the principle is the same)
gets applied to similar code elsewhere in the file.  Those cases
were with git, but I'm sure patch will do the same.  But things like
that are uncommon.

Backing up the file before reversing (modern patch will often do
this, creating a .orig version - I think it depends on the amount of
fuzz) and then diffing the two and comparing to the patch, and
perhaps looking at more details in the before and after files, should
be able to catch this.

Also, if too much has changed since the patch was created then it
cannot be reversed.  But I'm sure you knew that.  In those cases
(e.g. a function got changed, or extra code added in the middle of
what is being changed) it needs to be fixed up manually.
Unfortunately, that is fairly common when trying to apply our own,
or distro, patches in BLFS or beyond-BLFS.

> 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.
> 

Dunno, but in beyond-BLFS, or trying to apply a BLFS patch to a
newer version, I often get that.  Sometimes I can see differences
which make me go "yes, changed code", other times it all looks
unaltered but still rejects.  In either case, manually apply the
.rej items with any necessary changes, then remove the .orig and
.rej, rediff, and test to see if it builds (and if it does, test to
see if it works).

In theory, just moving a block of code by a few lines should only
increse the fuzz.  But recent versions of patch seem to be more
sensitive.

> I've attached a copy of the interdiff created
> 
> tip-x86-mm-x86-mm-Add-Secure-Me

Re: [lfs-support] Booting LFS with systemd

2018-07-12 Thread 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

2018-07-12 Thread Bruce Dubbs

On 06/27/2018 04:42 PM, Paul Rogers 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:


Correct me if I'm wrong, but I thought the only good reason for an initramfs is 
so a totally generic kernel could be built with every possible device driver 
for any unpredictable hardware out there as modules, then with discovery keep 
only those modules with the running kernel and dump the rest.


That's generally correct, but the initrd is also used for other things 
than just drivers.  It can be used for mounting a root filesystem that 
is encrypted or be needed with LVM or other custom filesystems or for 
finding a partition identified with a UUID.


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

I also use one to update the CPU firmware.  We show how to create this 
limited initrd at the section 'Early loading of microcode' in


http://www.linuxfromscratch.org/blfs/view/stable/postlfs/firmware.html

  But with LFS, given that 1) we know what hardware we have and that's 
unlikely to change much, if at all, 2) those modules need to be 
available to the system at all times, and 3) rebuilding the kernel isn't 
fearsome for us, I've never seen ANY need for an initramfs and build 
what's necessary as a monolithic kernel.


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


Because systemd is trying to insinuate itself into all critical 
functions of Linux,  It just makes the boot process more complex than it 
needs to be.


  -- Bruce


--
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

2018-07-12 Thread Ken Moffat
On Thu, Jul 12, 2018 at 02:17:05AM -0400, Michael Shell wrote:
> 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":
> 

Michael,

 whilst your advice is good, this seems horrendously complicated.  I
will admit that I have trouble when a bisect points to a *merge*
commit, and since I'm not currently doing a bisect I lack details
for reverting a commit, but surely -

if you have the git tree, you can look at the particular commit,
e.g. 'git show 7744ccdbc16f' (might sometimes need more digits),
and then in worst case add '>../dodgy' (so, the created file is not
in the git tree) and then something like 'cat ../dodgy | patch -R'
[ probably needs more specification, e.g. -p1 or whatever, so
--dry-run ].

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.

The important thing is that the 'weird alphanumeric codes' identify
a particular commit [ some variant of a shasum, I think ] and can be
used to identify the commit in git.

Regards,

ĸen
-- 
  Keyboard not found, Press F1 to continue
-- 
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

2018-07-11 Thread 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

2018-07-11 Thread Hazel Russman
On Tue, 10 Jul 2018 20:37:47 -0400
Michael Shell  wrote:

>   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
CONFIG_NUMA is not set. CONFIG_ARCH_HAS_MEM_ENCRYPT is set, but you can't unset 
it. It comes automatically with the x86 architecture.
> 
> 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
This is a wee bit over my head. I understand the concept of patching, but I 
don't understand how it relates to the git tree that I was using. I carried out 
the the bisection purely by rote, following instructions that I found on the 
web. I didn't really understand what I was doing and found the online git 
documentation quite opaque.

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

I would like very much to follow this up because who else can? I'm the only 
person I know about with hardware that triggers this bug. But I really need 
someone like you to hold my hand at least through the first few steps, and it 
would be better done off-list because after all it's not an LFS problem (and 
certainly nothing to do with systemd!) Could we perhaps start a thread in Linux 
Questions? I have an account there.
-- 
Hazel
-- 
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

2018-07-10 Thread 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

2018-07-10 Thread Hazel Russman
On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:

> 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
> 
> -- 
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. But thanks anyway. 

Funnily enough, my Samsung laptop (which is another old banger) boots 4.15 with 
full acpi and without any problems at all.

-- 
Hazel
-- 
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

2018-07-07 Thread Michael Shell
On Sat, 07 Jul 2018 14:38:36 +0800
Xi Ruoyao  wrote:

> For example I can insert
> 
> log_info("I am still alive!!!");
> 
> into systemd source code somewhere.


  Xi,

Thanks! Yeah, that's a good approach for developers. But, a lot of users
aren't going to be able to do that.

> Systemd seems to handle errors well (most of time). SIGABRT is strange.
> Someone said "-D_FORTIFY_SOURCE=2" may cause systemd to SIGABRT.

That's something else Frans can try (disable D_FORTIFY_SOURCE when
compiling systemd). Also, doing a search based on the above, I found this
which states that a watchdog timer can also trigger a SIGABRT:

https://lists.libreswan.org/pipermail/swan-dev/2016-July/001587.html

So, Frans can also try disabling the systemd watchdog timer:

edit /etc/systmed/system/ipsec.service and set

WatchdogSec=0

and see if that changes anything.


  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

2018-07-06 Thread Xi Ruoyao
On 2018-07-06 05:32 -0400, Michael Shell wrote:
> 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.

log_info() is a systemd internal function.  The usage of it is like printf.
It outputs to system log and screen.

For example I can insert

log_info("I am still alive!!!");

into systemd source code somewhere.  If I can see the message, I'll know
systemd doesn't crash before the line I inserted.  Then I can actually do
a bisect to know which source code line actually crashes.

And I can also output systemd variables like

log_info("foo = %d", foo);
 
> If it is a cgroup issue, it is required that the kernel be built with:
> 
> CONFIG_CGROUPS (it is OK to disable all controllers)

If /proc/cgroups does not exist, there will be an error message

"Failed to enumerate cgroup controllers: No such file or directory"

Systemd seems to handle errors well (most of time).  SIGABRT is strange.
Someone said "-D_FORTIY_SOURCE=2" may cause systemd to SIGABRT.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
-- 
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

2018-07-06 Thread Bruce Dubbs

On 07/06/2018 01:20 AM, Frans de Boer wrote:

On 07/05/2018 11:56 PM, Bruce Dubbs wrote:

On 07/05/2018 02:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--
I did a git bisect on my system, but I couldn't make much sense of 
the result. The commit it finally settled on didn't seem to have 
anything to with acpi.


[quote]
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]

I sent the result to the kernel acpi development list but never got 
an answer. If someone else on this list wants to try, I can send him 
my complete bisect logs.


--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of 
error messages is send, but due to ratelimiting I can't see them 
because they are suppressed.


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


Help?


I don't mean to be pedantic, but I really don't think you would run 
into these types of problems using System V.  Why not try that?


  -- Bruce


Hi Bruce,
With System V there is - of course - no problem. The thing is that 
systemd - if it runs well - is somewhat easier to use because of the use 
of .service files.


I'll have to disagree that service files are easier.  What I do agree 
with is that they are more consistent among distros.  The boot scripts 
for System V are really quite easy to read and, if needed, write.


 I also noticed that some packages are only shipping
.service(.in) files and have abandon the use of sysVinit files. 


Then they are abandoning those distros that do not use systemd such as 
the BSDs and Devuan.  But those distros can easily add their own boot 
scripts.  I'll note that all the BLFS packages that need boot scripts 
have them,


Combined 
with the fact that most distributions have embraced systemd as their 
primary or only init system let me believe that we are stuck with this 
piece of ever growing mutation. And as LFS is a teaching ground, it 
should - however reluctant - incorporated this too.


As a teaching tool, NOT using systemd is essential.  There is far too 
much done by systemd in an opaque manner that System V demonstrates and, 
if desired,implemented in custom ways.


Also, the goal is that someone fire-up their basic hardware with a LFS 
born OS, but for testing or use in VM's development is nowadays mostly 
within the VM realm.


When I teach LFS in class, I always have the students use real HW, 
There are too many things that VMs hide,


  -- Bruce

--
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

2018-07-06 Thread Baho Utot



On 07/06/2018 02:46 AM, Xi Ruoyao wrote:

On 2018-07-05 17:05 -0400, Baho Utot wrote:

On 07/05/2018 03:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).

.

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.

I don't know if it is a driver bug.  It seems to me a bug in DSDT itself.


I moved to FreebSD, but I am moving back to linux because of all the
non  sense going on with FreeBSD.  I'll be using the "old and proven"
init system.

Just curious, is there anything like "BSD From Scratch"?

Yes, but it doesn't work either

--
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

2018-07-06 Thread 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

2018-07-06 Thread Xi Ruoyao
On 2018-07-06 08:23 +0200, Frans de Boer wrote:
> On 07/06/2018 05:32 AM, Michael Shell wrote:
> > 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,

I read some systemd-238 code (src/core/main.c:1820):

> if (arg_system) {
> /* Make sure we leave a core dump without panicing the 
> kernel. */
> install_crash_handler();
> 
> if (!skip_setup) {
> r = mount_cgroup_controllers(arg_join_controllers);
> if (r < 0) { 
> *ret_error_message = "Failed to mount cgroup 
> hierarchies";
> return r;
> }
> 
> status_welcome();

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 Ruoyao 
School of Aerospace Science and Technology, Xidian University
-- 
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

2018-07-05 Thread Xi Ruoyao
On 2018-07-05 17:05 -0400, Baho Utot wrote:
> On 07/05/2018 03:48 PM, Frans de Boer wrote:
> > On 06/30/2018 01:29 PM, Hazel Russman wrote:
> > > On Fri, 29 Jun 2018 01:25:29 -0400
> > > Michael Shell  wrote:
> > > 
> > > > 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).
> > > > 
> > > > .
> > > > 
> > > > 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.

I don't know if it is a driver bug.  It seems to me a bug in DSDT itself.

> I moved to FreebSD, but I am moving back to linux because of all the 
> non  sense going on with FreeBSD.  I'll be using the "old and proven" 
> init system.

Just curious, is there anything like "BSD From Scratch"?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
-- 
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

2018-07-05 Thread Frans de Boer

On 07/06/2018 05:32 AM, Michael Shell wrote:

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


Hi Mike,
I will follow your suggestions, of which few are new to me, and will 
come back with a report.


--- Frans
--
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

2018-07-05 Thread Frans de Boer

On 07/05/2018 11:56 PM, Bruce Dubbs wrote:

On 07/05/2018 02:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--
I did a git bisect on my system, but I couldn't make much sense of 
the result. The commit it finally settled on didn't seem to have 
anything to with acpi.


[quote]
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]

I sent the result to the kernel acpi development list but never got 
an answer. If someone else on this list wants to try, I can send him 
my complete bisect logs.


--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of 
error messages is send, but due to ratelimiting I can't see them 
because they are suppressed.


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


Help?


I don't mean to be pedantic, but I really don't think you would run 
into these types of problems using System V.  Why not try that?


  -- Bruce


Hi Bruce,
With System V there is - of course - no problem. The thing is that 
systemd - if it runs well - is somewhat easier to use because of the use 
of .service files. I also noticed that some packages are only shipping 
.service(.in) files and have abandon the use of sysVinit files. Combined 
with the fact that most distributions have embraced systemd as their 
primary or only init system let me believe that we are stuck with this 
piece of ever growing mutation. And as LFS is a teaching ground, it 
should - however reluctant - incorporated this too.


Also, the goal is that someone fire-up their basic hardware with a LFS 
born OS, but for testing or use in VM's development is nowadays mostly 
within the VM realm.


Regards,
Frans
--
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

2018-07-05 Thread 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] Booting LFS with systemd

2018-07-05 Thread Douglas R. Reno
On Thu, Jul 5, 2018, 4:56 PM Douglas R. Reno  wrote:

>
>
> On Thu, Jul 5, 2018 at 2:54 PM Frans de Boer  wrote:
>
>> On 06/30/2018 01:29 PM, Hazel Russman wrote:
>> > On Fri, 29 Jun 2018 01:25:29 -0400
>> > Michael Shell  wrote:
>> >
>> >> 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).
>> >>
>> >> .
>> >>
>> >> 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.
>> >>
>> > ...
>> >>Cheers,
>> >>
>> >>Mike
>> >>
>> >> --
>> > I did a git bisect on my system, but I couldn't make much sense of the
>> result. The commit it finally settled on didn't seem to have anything to
>> with acpi.
>> >
>> > [quote]
>> > 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]
>> >
>> > I sent the result to the kernel acpi development list but never got an
>> answer. If someone else on this list wants to try, I can send him my
>> complete bisect logs.
>> >
>> > --
>> > Hazel
>> This quite frustrating. After recompiling, following the book to the
>> letter, I still get a frozen LFS system.
>> One thing I do note however is that the freezing always occurs after
>> systemd has detected that it is on a virtual machine. A number of error
>> messages is send, but due to ratelimiting I can't see them because they
>> are suppressed.
>>
>> 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
>>
>> Help?
>> Frans.
>> --
>> 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
>
>
> Hi,
>
> I see you're using Virtualbox. systemd has special instructions that have
> to do with running inside of hypervisors, and VirtualBox is one of them.
>
> I have a Windows machine here with Virtualbox installed. I'll give it a
> shot, I've been looking for an excuse to do it anyway.
>

Or rather, QEMU. Sorry about that.

It uses the same core, and the hypervisor comment still applies. Disregard
the above.

>
-- 
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

2018-07-05 Thread Douglas R. Reno
On Thu, Jul 5, 2018 at 2:54 PM Frans de Boer  wrote:

> On 06/30/2018 01:29 PM, Hazel Russman wrote:
> > On Fri, 29 Jun 2018 01:25:29 -0400
> > Michael Shell  wrote:
> >
> >> 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).
> >>
> >> .
> >>
> >> 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.
> >>
> > ...
> >>Cheers,
> >>
> >>Mike
> >>
> >> --
> > I did a git bisect on my system, but I couldn't make much sense of the
> result. The commit it finally settled on didn't seem to have anything to
> with acpi.
> >
> > [quote]
> > 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]
> >
> > I sent the result to the kernel acpi development list but never got an
> answer. If someone else on this list wants to try, I can send him my
> complete bisect logs.
> >
> > --
> > Hazel
> This quite frustrating. After recompiling, following the book to the
> letter, I still get a frozen LFS system.
> One thing I do note however is that the freezing always occurs after
> systemd has detected that it is on a virtual machine. A number of error
> messages is send, but due to ratelimiting I can't see them because they
> are suppressed.
>
> 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
>
> Help?
> Frans.
> --
> 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


Hi,

I see you're using Virtualbox. systemd has special instructions that have
to do with running inside of hypervisors, and VirtualBox is one of them.

I have a Windows machine here with Virtualbox installed. I'll give it a
shot, I've been looking for an excuse to do it anyway.
-- 
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

2018-07-05 Thread Bruce Dubbs

On 07/05/2018 02:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--
I did a git bisect on my system, but I couldn't make much sense of the 
result. The commit it finally settled on didn't seem to have anything 
to with acpi.


[quote]
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]

I sent the result to the kernel acpi development list but never got an 
answer. If someone else on this list wants to try, I can send him my 
complete bisect logs.


--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of error 
messages is send, but due to ratelimiting I can't see them because they 
are suppressed.


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


Help?


I don't mean to be pedantic, but I really don't think you would run into 
these types of problems using System V.  Why not try that?


  -- Bruce


--
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

2018-07-05 Thread Baho Utot



On 07/05/2018 03:48 PM, Frans de Boer wrote:

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--
I did a git bisect on my system, but I couldn't make much sense of 
the result. The commit it finally settled on didn't seem to have 
anything to with acpi.


[quote]
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]

I sent the result to the kernel acpi development list but never got 
an answer. If someone else on this list wants to try, I can send him 
my complete bisect logs.


--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of 
error messages is send, but due to ratelimiting I can't see them 
because they are suppressed.


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


Help?
Frans.


This is exactly why I don't use systemd, I suggest you do the same.   At 
least with System V init you can disable things until you get a handle 
on what is happening.


I moved to FreebSD, but I am moving back to linux because of all the 
non  sense going on with FreeBSD.  I'll be using the "old and proven" 
init system.


--
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

2018-07-05 Thread Frans de Boer

On 06/30/2018 01:29 PM, Hazel Russman wrote:

On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:


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).


.

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.


...

   Cheers,

   Mike

--

I did a git bisect on my system, but I couldn't make much sense of the result. 
The commit it finally settled on didn't seem to have anything to with acpi.

[quote]
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]

I sent the result to the kernel acpi development list but never got an answer. 
If someone else on this list wants to try, I can send him my complete bisect 
logs.

--
Hazel
This quite frustrating. After recompiling, following the book to the 
letter, I still get a frozen LFS system.
One thing I do note however is that the freezing always occurs after 
systemd has detected that it is on a virtual machine. A number of error 
messages is send, but due to ratelimiting I can't see them because they 
are suppressed.


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


Help?
Frans.
--
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

2018-06-30 Thread Hazel Russman
On Fri, 29 Jun 2018 01:25:29 -0400
Michael Shell  wrote:

> 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).  
> 
> 
> .
> 
> 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.
> 
...
> 
>   Cheers,
> 
>   Mike
> 
> -- 
I did a git bisect on my system, but I couldn't make much sense of the result. 
The commit it finally settled on didn't seem to have anything to with acpi.

[quote]
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]

I sent the result to the kernel acpi development list but never got an answer. 
If someone else on this list wants to try, I can send him my complete bisect 
logs.

--
Hazel
-- 
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

2018-06-30 Thread Frans de Boer

On 06/28/2018 09:54 PM, Thanos Baloukas wrote:

On 28/06/2018 10:44 μμ, Frans de Boer wrote:

On 06/28/2018 04:21 PM, Hazel Russman wrote:

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


On 2018-06-28 01:08 -0400, Michael Shell wrote:

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?
I had used initramfs to setup a loopback device and boot the system 
in an
image.  But it seems grub can handle loopback device (though I've 
never

tried).

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.
Agree.  Now I only use "initrd" directive to update CPU microcode 
and fix

the buggy ACPI DSDT of my laptop (another sad story).
--
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
--
Nice to know someone else does this. I use an initrd on my main 
machine for precisely these two purposes. I had hoped that rewriting 
the acpi dsdt to remove some reported errors would allow me finally 
to boot the latest kernels, which are giving me panic in the acpi 
driver, but no such luck!


Mind you, I'm not using systemd.

Great, new development, now I can't even install systemd due to the 
next error:

...
RuntimeError: File 'man/binfmt.d.5' could not be found
FAILED: meson-install

When looking for the missing file, I only found 'man/binfmt.d.xml'. I 
also refreshed the two systemd-238 packages to exclude a fallen bit, 
to no avail. Any suggestion where this might come from?




Did you extract the man pages?
tar -xf /path/to/systemd-man-pages-238.tar.xz


Shoot, I had commented that out for another test :( Thnx.

And the story continues.


--
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

2018-06-28 Thread 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

2018-06-28 Thread Thanos Baloukas

On 28/06/2018 10:44 μμ, Frans de Boer wrote:

On 06/28/2018 04:21 PM, Hazel Russman wrote:

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


On 2018-06-28 01:08 -0400, Michael Shell wrote:

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?
I had used initramfs to setup a loopback device and boot the system 
in an

image.  But it seems grub can handle loopback device (though I've never
tried).


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.
Agree.  Now I only use "initrd" directive to update CPU microcode and 
fix

the buggy ACPI DSDT of my laptop (another sad story).
--
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
--
Nice to know someone else does this. I use an initrd on my main 
machine for precisely these two purposes. I had hoped that rewriting 
the acpi dsdt to remove some reported errors would allow me finally to 
boot the latest kernels, which are giving me panic in the acpi driver, 
but no such luck!


Mind you, I'm not using systemd.

Great, new development, now I can't even install systemd due to the next 
error:

...
RuntimeError: File 'man/binfmt.d.5' could not be found
FAILED: meson-install

When looking for the missing file, I only found 'man/binfmt.d.xml'. I 
also refreshed the two systemd-238 packages to exclude a fallen bit, to 
no avail. Any suggestion where this might come from?




Did you extract the man pages?
tar -xf /path/to/systemd-man-pages-238.tar.xz

--
Thanos
--
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

2018-06-28 Thread Frans de Boer

On 06/28/2018 04:21 PM, Hazel Russman wrote:

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


On 2018-06-28 01:08 -0400, Michael Shell wrote:

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?

I had used initramfs to setup a loopback device and boot the system in an
image.  But it seems grub can handle loopback device (though I've never
tried).


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.

Agree.  Now I only use "initrd" directive to update CPU microcode and fix
the buggy ACPI DSDT of my laptop (another sad story).
--
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
--

Nice to know someone else does this. I use an initrd on my main machine for 
precisely these two purposes. I had hoped that rewriting the acpi dsdt to 
remove some reported errors would allow me finally to boot the latest kernels, 
which are giving me panic in the acpi driver, but no such luck!

Mind you, I'm not using systemd.

Great, new development, now I can't even install systemd due to the next 
error:

...
RuntimeError: File 'man/binfmt.d.5' could not be found
FAILED: meson-install

When looking for the missing file, I only found 'man/binfmt.d.xml'. I 
also refreshed the two systemd-238 packages to exclude a fallen bit, to 
no avail. Any suggestion where this might come from?


Regards,
Frans.
--
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

2018-06-28 Thread Hazel Russman
On Thu, 28 Jun 2018 16:06:00 +0800
Xi Ruoyao  wrote:

> On 2018-06-28 01:08 -0400, Michael Shell wrote:
> > 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?  
> 
> I had used initramfs to setup a loopback device and boot the system in an
> image.  But it seems grub can handle loopback device (though I've never
> tried).
> 
> > 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.  
> 
> Agree.  Now I only use "initrd" directive to update CPU microcode and fix
> the buggy ACPI DSDT of my laptop (another sad story).
> -- 
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University
> -- 
Nice to know someone else does this. I use an initrd on my main machine for 
precisely these two purposes. I had hoped that rewriting the acpi dsdt to 
remove some reported errors would allow me finally to boot the latest kernels, 
which are giving me panic in the acpi driver, but no such luck!

Mind you, I'm not using systemd.

-- 
Hazel
-- 
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

2018-06-28 Thread Xi Ruoyao
On 2018-06-28 01:08 -0400, Michael Shell wrote:
> 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?

I had used initramfs to setup a loopback device and boot the system in an
image.  But it seems grub can handle loopback device (though I've never
tried).

> 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.

Agree.  Now I only use "initrd" directive to update CPU microcode and fix
the buggy ACPI DSDT of my laptop (another sad story).
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
-- 
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

2018-06-27 Thread 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

2018-06-27 Thread Paul Rogers
> > 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:

Correct me if I'm wrong, but I thought the only good reason for an initramfs is 
so a totally generic kernel could be built with every possible device driver 
for any unpredictable hardware out there as modules, then with discovery keep 
only those modules with the running kernel and dump the rest.  But with LFS, 
given that 1) we know what hardware we have and that's unlikely to change much, 
if at all, 2) those modules need to be available to the system at all times, 
and 3) rebuilding the kernel isn't fearsome for us, I've never seen ANY need 
for an initramfs and build what's necessary as a monolithic kernel.

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

-- 
Paul Rogers
paulgrog...@fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)
-- 
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

2018-06-26 Thread 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

2018-06-25 Thread Frans de Boer

On 06/26/2018 07:16 AM, Michael Shell wrote:

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


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.


Regards, Frans

--
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

2018-06-25 Thread 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

2018-06-25 Thread Xi Ruoyao
On 2018-06-25 09:19 +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.
> 
> Regards, Frans.

See .

Try the Early Debug Shell.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University
-- 
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

2018-06-25 Thread Frans de Boer

On 06/25/2018 03:51 AM, Michael Shell wrote:

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




Mike thanks for your replies. I shall follow your suggestions this week 
and shall be back when I have more answers.


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.


Regards, Frans.

--
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

2018-06-24 Thread 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

2018-06-24 Thread Armin K.

On 24.6.2018. 10:01, Frans de Boer wrote:

On 06/22/2018 07:30 AM, Michael Shell wrote:

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

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?


Regards,
Frans.


If you install elfutils the LFS way, it will always be like that. 
systemd needs full package (well, all libs and headers at least).

--
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

2018-06-24 Thread Frans de Boer

On 06/22/2018 07:30 AM, Michael Shell wrote:

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

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?


Regards,
Frans.
--
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

2018-06-21 Thread 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

2018-06-21 Thread Frans de Boer

On 18-06-18 06:53, Michael Shell wrote:

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

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

also the gdb command still say "no stack".

It allstoped working with systemd 237.
I have checked and re-checked every item with the BSS (chapter 6) range. 
Found some spelling errorrs but still a dead system.
I do notice, hoeever, that it always ends with something of the 
clocksource. But surely, if I follow the book it should be right, i think.


Any more suggestions?

Regards,
Frans.
--
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

2018-06-17 Thread 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

2018-06-17 Thread 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] Booting LFS with systemd

2018-06-17 Thread Frans de Boer

On 16-06-18 22:13, Frans de Boer wrote:

On 29-05-18 08:39, Frans de Boer wrote:
First of all I apologize for the initial flood of messages. They where 
the result of multiple tries to get the message to the list in the 
first place. Only yesterday I found that LFS is - still - not handling 
TLS while my server had the line that is must encrypt messages. Of the 
many subjects I exchange messages with, LFS is the only one not 
supporting TLS covered traffic.


Now on subject: I will look into that matter, but normal production 
systems have the same message and do not fail.

I'll keep you informed.

Regards,
Frans.


On 29-05-18 06:43, Michael Shell wrote:

On Thu, 24 May 2018 16:21:53 +0200
Frans de Boer  wrote:


Attached is a picture with a repeatably failing boot when I build LFS
with systemd support. Any suggestion where I screwed-up?



   Frans,

A few lines before the crash, your systemd errored with:

"failed to insert module 'autofs4': No such file or directory"

That might have triggered the abort a few lines later.

Here:

https://www.linuxquestions.org/questions/linux-general-1/boot-problem-failed-to-insert-module-%27autofs4%27-4175485121/ 



they suggest recompiling the kernel with

CONFIG_AUTOFS4_FS=y

(under "Kernel automounter version 4 support (also supports v3)" in the
File systems config section) i.e., built-in rather than as a module.

If that does not fix it, see here for how to use gdb on the systemd
core dump to see the sequence of events that led to the downfall:

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

and post the bt output for us to see. In anycase, if you resolve
the problem, do post to the list what the answer turned out to be.


   Cheers,

   Mike Shell



Hello, it has taken some time before I could follow-up the given 
suggestion. To no avail as expected. The error message about autofs4 has 
vanished, but the rest remains. So, still no solution.


As for the output of the gdb bt command, I need to rebuild all again and 
skip the removal of debug information. I will start this this evening, 
so hopefully I have some more info tomorrow.


Regards,
Frans.


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".


I probably doing something wrong, but what can it be?

Regards,
Frans.
--
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

2018-06-16 Thread Frans de Boer

On 29-05-18 08:39, Frans de Boer wrote:
First of all I apologize for the initial flood of messages. They where 
the result of multiple tries to get the message to the list in the first 
place. Only yesterday I found that LFS is - still - not handling TLS 
while my server had the line that is must encrypt messages. Of the many 
subjects I exchange messages with, LFS is the only one not supporting 
TLS covered traffic.


Now on subject: I will look into that matter, but normal production 
systems have the same message and do not fail.

I'll keep you informed.

Regards,
Frans.


On 29-05-18 06:43, Michael Shell wrote:

On Thu, 24 May 2018 16:21:53 +0200
Frans de Boer  wrote:


Attached is a picture with a repeatably failing boot when I build LFS
with systemd support. Any suggestion where I screwed-up?



   Frans,

A few lines before the crash, your systemd errored with:

"failed to insert module 'autofs4': No such file or directory"

That might have triggered the abort a few lines later.

Here:

https://www.linuxquestions.org/questions/linux-general-1/boot-problem-failed-to-insert-module-%27autofs4%27-4175485121/ 



they suggest recompiling the kernel with

CONFIG_AUTOFS4_FS=y

(under "Kernel automounter version 4 support (also supports v3)" in the
File systems config section) i.e., built-in rather than as a module.

If that does not fix it, see here for how to use gdb on the systemd
core dump to see the sequence of events that led to the downfall:

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

and post the bt output for us to see. In anycase, if you resolve
the problem, do post to the list what the answer turned out to be.


   Cheers,

   Mike Shell



Hello, it has taken some time before I could follow-up the given 
suggestion. To no avail as expected. The error message about autofs4 has 
vanished, but the rest remains. So, still no solution.


As for the output of the gdb bt command, I need to rebuild all again and 
skip the removal of debug information. I will start this this evening, 
so hopefully I have some more info tomorrow.


Regards,
Frans.
--
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

2018-05-28 Thread Frans de Boer
First of all I apologize for the initial flood of messages. They where 
the result of multiple tries to get the message to the list in the first 
place. Only yesterday I found that LFS is - still - not handling TLS 
while my server had the line that is must encrypt messages. Of the many 
subjects I exchange messages with, LFS is the only one not supporting 
TLS covered traffic.


Now on subject: I will look into that matter, but normal production 
systems have the same message and do not fail.

I'll keep you informed.

Regards,
Frans.


On 29-05-18 06:43, Michael Shell wrote:

On Thu, 24 May 2018 16:21:53 +0200
Frans de Boer  wrote:


Attached is a picture with a repeatably failing boot when I build LFS
with systemd support. Any suggestion where I screwed-up?



   Frans,

A few lines before the crash, your systemd errored with:

"failed to insert module 'autofs4': No such file or directory"

That might have triggered the abort a few lines later.

Here:

https://www.linuxquestions.org/questions/linux-general-1/boot-problem-failed-to-insert-module-%27autofs4%27-4175485121/

they suggest recompiling the kernel with

CONFIG_AUTOFS4_FS=y

(under "Kernel automounter version 4 support (also supports v3)" in the
File systems config section) i.e., built-in rather than as a module.

If that does not fix it, see here for how to use gdb on the systemd
core dump to see the sequence of events that led to the downfall:

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

and post the bt output for us to see. In anycase, if you resolve
the problem, do post to the list what the answer turned out to be.


   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

2018-05-28 Thread Michael Shell
On Thu, 24 May 2018 16:21:53 +0200
Frans de Boer  wrote:

> Attached is a picture with a repeatably failing boot when I build LFS 
> with systemd support. Any suggestion where I screwed-up?


  Frans,

A few lines before the crash, your systemd errored with:

"failed to insert module 'autofs4': No such file or directory"

That might have triggered the abort a few lines later.

Here:

https://www.linuxquestions.org/questions/linux-general-1/boot-problem-failed-to-insert-module-%27autofs4%27-4175485121/

they suggest recompiling the kernel with

CONFIG_AUTOFS4_FS=y

(under "Kernel automounter version 4 support (also supports v3)" in the
File systems config section) i.e., built-in rather than as a module.

If that does not fix it, see here for how to use gdb on the systemd
core dump to see the sequence of events that led to the downfall:

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

and post the bt output for us to see. In anycase, if you resolve
the problem, do post to the list what the answer turned out to be.


  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


[lfs-support] Booting LFS with systemd

2018-05-28 Thread Frans de Boer

Dear all,

Attached was a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.


Since pictures are not allowed:
The output ends with:
systemd[1]: Detected virtualization vw-other
systemd[1]: Detected architecture x86_64
systemd[1]: Caught , dumped core at pid 39
systemd[1}: Freezing execution
it then continues with three lines about the clocksource and it is frozen.
--
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


[lfs-support] Booting LFS with systemd

2018-05-28 Thread Frans de Boer

Dear all,

Attached was a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.


Since pictures are not allowed:
The output ends with:
systemd[1]: Detected virtualization vw-other
systemd[1]: Detected architecture x86_64
systemd[1]: Caught , dumped core at pid 39
systemd[1}: Freezing execution
it then continues with three lines about the clocksource and it is frozen.
--
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

2018-05-28 Thread Baho Utot



On 5/25/2018 4:35 AM, Frans de Boer wrote:

Dear all,

Attached was a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.


Since pictures are not allowed:
The output ends with:
systemd[1]: Detected virtualization vw-other
systemd[1]: Detected architecture x86_64
systemd[1]: Caught , dumped core at pid 39
systemd[1}: Freezing execution
it then continues with three lines about the clocksource and it is frozen.


The only thing I know about systemd is to stay the hell away from it. 
Sorry I can not help

--
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


[lfs-support] Booting LFS with systemd

2018-05-28 Thread Frans de Boer

Dear all,

Attached is a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.
-- 
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


[lfs-support] Booting LFS with systemd

2018-05-28 Thread Frans de Boer

Dear all,

Attached was a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.


Since pictures are not allowed:
The output ends with:
systemd[1]: Detected virtualization vw-other
systemd[1]: Detected architecture x86_64
systemd[1]: Caught , dumped core at pid 39
systemd[1}: Freezing execution
it then continues with three lines about the clocksource and it is frozen.
--
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


[lfs-support] Booting LFS with systemd

2018-05-28 Thread Frans de Boer

Dear all,

Attached was a picture with a repeatably failing boot when I build LFS 
with systemd support. Any suggestion where I screwed-up?


This is already like the introduction of systemd-238.

Regards, Frans.


Since pictures are not allowed:
The output ends with:
systemd[1]: Detected virtualization vw-other
systemd[1]: Detected architecture x86_64
systemd[1]: Caught , dumped core at pid 39
systemd[1}: Freezing execution
it then continues with three lines about the clocksource and it is frozen.
--
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