Would it be correct to replace x86_64 in your documentation bash scripts
with `uname -m`? Because of course everybody knows ARM is the way
of the future. :)
But seriously, I'm not always sure what to relace. Or maybe you could
put them all on one page? It wouldn't detract from the flow of
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 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 07/14/2018 06:56 PM, Hazel Russman wrote:
Gentlemen,
I was given your contact details by Michael Shell, who has been helping me to
troubleshoot this problem via the Linux From Scratch support list.
For some time now I have been unable to boot recent kernels (4.14 or later) on my rather
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 Sat, Jul 14, 2018 at 08:49:19PM -0400, Alan Corey wrote:
> Would it be correct to replace x86_64 in your documentation bash scripts
> with `uname -m`? Because of course everybody knows ARM is the way of the
> future. :)
>
> But seriously, I'm not always sure what to relace. Or maybe you
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 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
Hello,
First, thank you all who have created LFS and graciously offer to
support users who take on the project.
After getting to the end of chapter 5 of the LFS 8.2 book, I noticed
that my /tools directory has both the host and the new
architecture-specific locations:
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
>
> What is the output of "ldd --version | head -n1" on the host system?
>
result : ldd (GNU libc) 2.26
In Section 5.7. Glibc-2.27. does the output of the check in the caution
> block give "/tools/lib/ld-linux.so.2"?
>
> In section 5.10. GCC-8.1.0 - Pass 2, does the output of
> the check in
Gentlemen,
I was given your contact details by Michael Shell, who has been helping me to
troubleshoot this problem via the Linux From Scratch support list.
For some time now I have been unable to boot recent kernels (4.14 or later) on
my rather elderly desktop machine. The kernel panics during
It's correct. Binutils and GCC Pass 1 targets x86_64-lfs-linux-gnu but Pass 2 targets x86_64-pc-linux-gnu.Sent from my phone. Sorry for bad formatting and HTML.--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above
13 matches
Mail list logo
