Re: [lfs-support] Architecture suggestion
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 could put > them all on one page? It wouldn't detract from the flow of the main page > much that way. > You think we know the details for architectures we don't use ? And one expression :) RISC-V ĸ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
[lfs-support] Architecture suggestion
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 the main page much that way. --- Sent from Alpine connected to Gmail on my 64-bit Raspberry Pi -- 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
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
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
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
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] Kernel bug involving physical to virtual remapping
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 elderly desktop machine. The kernel panics during boot and the problem seems (superficially) to lie in the acpi driver. At least that is where the visible error messages come from. Booting with "acpi=off" works but is hardly an ideal solution. However a git bisection showed that this is actually a memory management issue. The kernel commit that caused the problem is : [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap(). Reintroducing the code: "if (is_ISA_range(phys_addr, last_addr)) return (__force void __iomem *)phys_to_virt(phys_addr);" makes the system bootable again. I have also tested this on a 4.15 kernel and it works there too. If you want me to carry out any further tests, I would be happy to oblige, but do please bear in mind that I am not an expert, so you will need to give fairly basic instructions. Hazel Russman Thnx Hazel, I will try this in the comming days ahead. --- 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] Dual architecture-triplet binutils directories in temp /tools
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 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] Kernel bug involving physical to virtual remapping
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 boot and the problem seems (superficially) to lie in the acpi driver. At least that is where the visible error messages come from. Booting with "acpi=off" works but is hardly an ideal solution. However a git bisection showed that this is actually a memory management issue. The kernel commit that caused the problem is : [33c2b803edd13487518a2c7d5002d84d7e9c878f] x86/mm: Remove phys_to_virt() usage in ioremap(). Reintroducing the code: "if (is_ISA_range(phys_addr, last_addr)) return (__force void __iomem *)phys_to_virt(phys_addr);" makes the system bootable again. I have also tested this on a 4.15 kernel and it works there too. If you want me to carry out any further tests, I would be happy to oblige, but do please bear in mind that I am not an expert, so you will need to give fairly basic instructions. Hazel Russman -- -- 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] LFS8.1 chapter 5.10 : /tools/bin/gcc is dynamically linked to host linker
>
> 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 the caution block give "/tools/lib/ld-linux.so.2"? I see
> from the above, tha tit does not, do the problem is before is in the
> initial packages. Do not do beyond 5.10 until the output of the above is
> correct.
>
All checks that are mentioned in the book had passed successfully !!
even the last check in section 5.10 gives the output as in the book!!!
The PS1 variable above is confusing. When you change to the lfs user, (su -
> lfs), the startup file .bash_profile should set PS1 to "\u:\w\$ '. The
> debian_chroot should not show up in PS1.
>
this is my .bash_profile : exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$
' /bin/bash
On Sun, Jul 1, 2018 at 8:52 PM, Bruce Dubbs wrote:
> On 07/01/2018 09:02 AM, Mohamed Dawod wrote:
>
>> YES, I removed the build and source dirs after compile ( I need to know
>> why this is mandatory ? )
>>
>
> Because we build packages multiple times and the old source directory is
> compromised from the previous build. Deleting and extracting ensures you
> start with a clean source directory. A side effect is that it also saves
> space on the /mnt/lfs partition.
>
> and I made sure that seds in gcc pass1 worked well, I opened the effected
>> files and noticed the differences between the new files and the original
>> files as required
>> BUT.. the only not effected line is that line =(( #define
>> GLIBC_DYNAMIC_LINKERX32 "/libx32/ld-linux-x32.so.2" ))
>> NOTE : my host system is UBUNTU-14.4 LTS
>>
>
> I am not sure where you found GLIBC_DYNAMIC_LINKERX32. We do not mention
> it in the book or in the patches.
>
> What is the output of "ldd --version | head -n1" on the host system?
>
> On 1.7.2018. 10:15, Mohamed Dawod wrote:
>>
>>
>> HI,
>>
>> I hope that some one can help me..
>> This is the 8th time i restart LFS building from chapter3 !!
>>
>> The problem starts to appear in chapter6.7 (Linux-4.12.7 API
>> Headers)
>> (/tools/bin/gcc file doesnt exist error)
>>
>> The problem is explained in details here :
>> http://archive.linuxfromscratch.org/mail-archives/lfs-
>> support/2016-February/049686.html
>>
>
>
>> So, I restart from chapter5 and when I reached to section 5.10.
>> (GCC-7.2.0 - Pass 2) , I tried to check the linking of
>> /tools/bin/gcc using the command
>>
>> $readelf -l /tools/bin/cc | grep "interpreter"
>> --The result :
>> [Requesting program interpreter: /lib/ld-linux.so.2]
>> __
>> The path for my lfs usr : $echo $PATH
>> --The result : /tools/bin:/bin:/usr/bin
>> __
>> The environmental variables for lfs usr : $env|sort
>> --The result :
>> HOME=/home/lfs
>> LC_ALL=POSIX
>> LFS=/mnt/lfs
>> LFS_TGT=i686-lfs-linux-gnu
>> OLDPWD=/mnt/lfs
>> PATH=/tools/bin:/bin:/usr/bin
>> PS1=${debian_chroot:+($debian_chroot)}\u@\h:\w\$
>> PWD=/home/lfs
>> SHLVL=1
>> TERM=xterm
>> _=/usr/bin/env
>>
>
> The above tells me you are building using a 32-bit host OS.
> I have not done that for a few years now since I no longer have any 32-bit
> systems. Perhaps the following may be helpful:
>
> 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 the caution block give "/tools/lib/ld-linux.so.2"? I see
> from the above, tha tit does not, do the problem is before is in the
> initial packages. Do not do beyond 5.10 until the output of the above is
> correct.
>
> The PS1 variable above is confusing. When you change to the lfs user, (su
> - lfs), the startup file .bash_profile should set PS1 to "\u:\w\$ '. The
> debian_chroot should not show up in PS1.
>
> -- 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
>
--
Mohamed Dawod
Computer Engineering Department
Faculty of Engineering
Cairo 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.
Re: [lfs-support] Booting LFS with systemd
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
[lfs-support] Dual architecture-triplet binutils directories in temp /tools
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: /tools/x86_64-lfs-linux-gnu /tools/x86_64-pc-linux-gnu And, more disturbingly, it seems that gcc prefers the linker from the host architecture directory: $ type gcc gcc is /tools/bin/gcc $ gcc -print-prog-name=ld /home/lfs/LFS_8p2_temp/tools/bin/../lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld This seem wrong. I did notice the dual directories early, but figured it was an artifact of the initial pass and would be adjusted in later steps. Maybe it's not wrong; the remaining work is still being performed on the build system, which would mean that the above linker location is correct? Sorry, this is a bit confusing to me; I'm fairly new to the practice of cross-compiling. 1. Is this incorrect? 2. What might I have done incorrectly to cause it? 3. Any shortcut to correcting it? Thanks and kind regards, Dave -- 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
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
