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
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
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
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 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
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
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
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
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.
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
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
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
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
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
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
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
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
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.
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
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,
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.
>
>
>
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
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,
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:
>
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
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
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
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
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.
> >
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:
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:
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
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
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:
> > > >
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
> > 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 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
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,
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.
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
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
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?
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
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:
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
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
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:
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
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
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
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
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
67 matches
Mail list logo
