Re: [lfs-support] Booting LFS and UEFI
On 12/19/2013 01:22 PM, William Immendorf wrote: Thanks for posting advice for EFI users. You should probally make this into a hint sometime soon. I might want to add info about Gummiboot [1] (or at least mention it) - it's really useful if you want to take advantage of EFI and still be able to choose almost instantly which OS you want to boot into. And you should also mention that the GPT tools are essential if you are building LFS on a EFI-enabled system. William [1]: http://freedesktop.org/wiki/Software/gummiboot/ - This requires gnu-efi (https://www.archlinux.org/packages/extra/x86_64/gnu-efi-libs/), which in turn requires PCIUtils (I think). Gummiboot doesn't have a dedicated package host, but you can see the git repo (and get snapshot archives) from http://cgit.freedesktop.org/gummiboot/ You're welcome, William. I wrote it this way as a result of a conversation on this list a couple of months ago. A hint, if this is not somehow incorporated into the book, is advisable. I purposefully didn't mention gummiboot because I wanted my presentation to be as minimal as possible. The same reason for no logic and references. I really like gummiboot. And yes, it it PCIutils that it needs. Thanks for mentioning GPT tools. Parted uses them, but I'm so used to using it that I didn't think to include it in my write up. While I've got you on the phone :) , I cannot get my LFS system to be gummiboot's default. This is my loader.conf: timeout 10 default lfs74.conf Have I not identified the LFS loader properly? The gummiboot examples have a number in their example loader.conf and I don't know whether that's a machine ID or UUID. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB
On 12/18/2013 02:08 PM, loki wrote: On Wed, 2013-12-18 at 09:24 -0600, Dan McGhee wrote: Are you trying to do this on a UEFI system? Dan Nope. I'm not even sure that this old rig is EFI capable And secondly I'm too lazy to learn it since for the servers that I use 4 primary partitions is the most I'm going to use and the other gizmos and gadgets that EFI has are also overkill. And I'm somewhat old school, I don't believe that the computer itself should have a full fledged operating system embedded on it. I'm from the Kickstart Disk generation. Basic Input Output System, just get it to the state where the operating system can take the computer over and then vanish. But at the end I'm very reluctant to use something that is embedded on the machine and has the touch of MICROSOFT on it. :p You and I have similar attitudes, esp with regard to the "M-word." :) From the research I did I concluded that the UEFI thing is here to stay--doesn't necessarily mean "secure boot" either. In fact, that's the first thing I turned off with my new machine. What I like is not being limited to four primary partitions. The trick for grub users is to get it to "look across" the partitions without having to have a "signed" grub.efi file. And as soon as I get my LFS system to the point I want to reach, I'm going to do another build and see if I can make that happen. What else I learned was that UEFI is a manufacturer thing, but secure boot is the innovation (?) of the "M-word." Go figure. Of course, if your "rig" is old, this is not relevant. But as my niece tells me, "Old is only a number." :) :) Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB
On 12/18/2013 03:44 PM, Bruce Dubbs wrote: Dan McGhee wrote: On 12/18/2013 02:08 PM, loki wrote: On Wed, 2013-12-18 at 09:24 -0600, Dan McGhee wrote: Are you trying to do this on a UEFI system? Dan Nope. I'm not even sure that this old rig is EFI capable :) And secondly I'm too lazy to learn it since for the servers that I use 4 primary partitions is the most I'm going to use and the other gizmos and gadgets that EFI has are also overkill. :) And I'm somewhat old school, I don't believe that the computer itself should have a full fledged operating system embedded on it. I'm from the Kickstart Disk generation. Basic Input Output System, just get it to the state where the operating system can take the computer over and then vanish. But at the end I'm very reluctant to use something that is embedded on the machine and has the touch of MICROSOFT on it. :p You and I have similar attitudes, esp with regard to the M-word. :) From the research I did I concluded that the UEFI thing is here to stay--doesn't necessarily mean secure boot either. In fact, that's the first thing I turned off with my new machine. What I like is not being limited to four primary partitions. You can do that in a BIOS based system. You can use GPT without UEFI. I think there may be an issue if you have a boot partition that ends above 2T, but I always recommend a small partition at the beginning for /boot. You're right about the GPT without UEFI. But, AFIK, the user must *make* the partition behave with the GUID's. But, again AFIK, if the firmware is MBR based, you're still limited to four primaries. The trick for grub users is to get it to look across the partitions without having to have a signed grub.efi file. And as soon as I get my LFS system to the point I want to reach, I'm going to do another build and see if I can make that happen. Doesn't UEFI systems have a 'Legacy' mode where that stuff is not needed? Yes. If you install GRUB2 this way, its files are written to the MBR protected layer, and then the partition behaves like it has MBR-BIOS. This is what I have gleaned from getting my LFS to boot in a UEFI environment anyway. Thus far I have been able to boot only by employing the efi stubs of the kernel. I'm almost finished with my write up on how to do that. I don't want to quit researching because it's interesting. I would like to learn how to employ GRUB2 and all its capabilities in this environment. I think it's possible by manipulating the secure variables of EFI, but I have to learn how to do that. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB
On 12/18/2013 04:09 PM, akhiezer wrote: Date: Wed, 18 Dec 2013 16:00:11 -0600 From: Dan McGhee beesn...@grm.net To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB [...] But, AFIK, the user must *make* the partition behave with the GUID's. [...] Not quite sure what you're meaning there, Dan - apols if/that am being dense: elab if poss? (No probs of course if not.) No prob anywhere. [...] But, again AFIK, if the firmware is MBR based, you're still limited to four primaries. IIUYC: no; e.g. got an old (a testing-machine) p4 on a supermicro p4spa+ (or sim) mainboard, running modern blfs/slack1337, with disks partitioned with GPT and each disk has ~16 partitions. No non-/pre-GPT stuff in sight, no UEFI stuff in sight, and all goes just fine. This is what I meant. The user needs a gpt capable partitioning tool to *make it so* on an older machine. And, again IIUYC re 'primaries': no such concept in GPT, at least not in pre-GPT sense; and in pre-GPT sense, yes, the spec only allows for 4 primaries anyhow. This is another source of misunderstanding. May be too strong a word. It's all vocabulary. MSDOS MBR's don't have the bit length to physically support more than what is know as a primary, as opposed to extended partition. I don't have a pdf reader set up on my new LFS yet so I can't refer to an article I'm thinking of. But if I remember, the old MBR is 16 bit. The UEFI bios firmware is 128 bit. There, of course, is a limit to the number of partitions, but it's large. :) I find this subject fascinating, but until I get my new system where I want it, I'm hampered by jumping back and forth between Ubuntu and LFS. So I'm just still building until then. Thanks for responding akh, you've provided me with some more precision in my ability to talk about this. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB
On 12/18/2013 05:54 PM, Bruce Dubbs wrote: Dan McGhee wrote: On 12/18/2013 04:09 PM, akhiezer wrote: And, again IIUYC re 'primaries': no such concept in GPT, at least not in pre-GPT sense; and in pre-GPT sense, yes, the spec only allows for 4 primaries anyhow. This is another source of misunderstanding. May be too strong a word. It's all vocabulary. MSDOS MBR's don't have the bit length to physically support more than what is know as a primary, as opposed to extended partition. Not quite. The MBR handles 32-bit words. That gives addressing of up to 4G of 512-byte partitions. That's how you get the 2T limit. The limit could be higher if the block size is 4K, but that creates a lot more problems for the legacy BIOS, so it's better to just use GPT that has 128-bit lengths for sector addressing. That's enough for a zetabye or so even with 512-byte sectors. Try to run fsck on that! :) Extended partitions have the same limitations as MBR primary partitions, but there are just in a linked list and not an array. I don't have a pdf reader set up on my new LFS yet so I can't refer to an article I'm thinking of. But if I remember, the old MBR is 16 bit. The UEFI bios firmware is 128 bit. There, of course, is a limit to the number of partitions, but it's large. :) I think it is 128 partitions by default, but it can be made to handle more. Another difference is that classical systems start the first partition at the 2nd 'physical' track (often faked in drives) of 63 sectors. That leaves about 31K for the GRUB2 code. For GPT, we make a raw boot partition for grub, usually 1Mb, that give it lots of space for expansion, but is negligible compared to the whole disk drive. From our perspective, the only thing that is needed is to load one 512-byte sector into memory and execute it. The bootstrapping continues from there and only needs very basic BIOS calls to load other sectors into memory. Of course after booting, the kernel does not need the BIOS/UEFI at all. Bruce, I think we're saying the same thing and are being limited by our language--at least from my side of the fence. I would provide a link to the article I have used in my research, but I've misplaced it. I am sorry for a long quote, but I wanted to provide it to show why I think we're saying the same thing. The notes at the bottom of the pages of this article by John Lang say page no.LFX March 2013. (Linux Forum Journal ()) The BIOS was originally devised as an interface between hardware devices and the Disk Operating System (DOS, more commonly known as MS-DOS). It was, and remains, a 16-bit real-mode programme. As operating systems have evolved through the years to 32- and now 64-bit code, they no longer use the BIOS interface, but contain their own device drivers instead. The BIOS’s role has been reduced to beginning the boot process, and is largely irrelevant once the operating system has booted. The MBR serves two purposes: it contains the bootloader that the BIOS executes to boot the computer, and it contains the partition table that defines the location of the filesystems on the disk. All of this information is stored in the first sector (called sector0) of the disk, and is therefore limited to 512 bytes: 446 bytes for the bootloader, and a partition table containing up to four 16-byte records. The last two bytes contain a signature that the BIOS uses to recognise a valid MBR. The partition tables use 32-bit sector addresses fields, which means they can’t address disks larger than 2TiB. This type of partition table is often referred to as an MSDOS partition table in an attempt to differentiate it from the new GPT. The problems with this configuration include being limited to one bootloader, the limitation of four partitions and the 2TiB maximum disk size. The UEFI supports multiple bootloaders, and the GPT supports up to 128 partitions and works with disks that are bigger than 2TiB. The other thing that UEFI brings to the table is the ability to secure the boot process. Because the BIOS expects the bootloader to be located in the first sector of the disk, there can only be one per disk. Most BIOSes allow selection of the boot disk and, therefore, can support as many bootloaders as there are physical disks. In contrast, UEFI ignores any bootloader in sector 0, but instead allows multiple bootloaders to exist on a single disk by using a special partition instead of an absolute sector. The special partition is known as the EFI System Partition, or ESP, and is formatted with a FAT filesystem (usually FAT32) and typically sized between 100MiB and 250MiB. The UEFI specification requires it to be the first partition and that it must have its boot flag set. On a Linux system it is customary to mount the ESP under /boot/efi. Convention dictates that bootloaders are stored on the ESP in vendor-specific sub-directories
Re: [blfs-support] Troubles Building NSS-3.15.3 [Corrected Major Error]
On 12/05/2013 11:20 AM, Dan McGhee wrote: This build has failed three times for me. Here is the applicable portion of the build log: [What I originally included was an excerpt from my error log. I apologize for the mistake. 1411 make[2]: Entering directory `/usr/src/nss-3.15.3/nss-3.15.3/nss/lib/pk11wrap' 1412 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11cert.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11cert.c 1413 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11akey.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11akey.c 1414 rm: cannot remove 'Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ': Is a directory 1415 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11auth.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11auth.c 1416 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11cxt.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11cxt.c 1417 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/dev3hack.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss dev3hack.c 1418 Assembler messages: 1419 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11err.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11err.c 1420 Fatal error: can't create Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11cert.o: No such file or directory 1421 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11list.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11list.c 1422 gcc -o Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/pk11kea.o -c -O2 -D_POSIX_SOURCE -D_BSD_SOURCE -D_XOPEN_SOURCE -fPIC -DLINUX2_1 -Wall -Werror-implicit-function-declaration -Wno-switch -pipe -DLINUX -Dlinux -DHAVE_STRERROR -DXP_UNIX -DSHLIB_SUFFIX=\so\ -DSHLIB_PREFIX=\lib\ -DSHLIB_VERSION=\3\ -DSOFTOKEN_SHLIB_VERSION=\3\ -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -I/usr/include/nspr -I../../../dist/Linux3.8_x86_64_glibc_PTH_64_OPT.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss pk11kea.c 1423
[lfs-support] Configuring 3.10.10 for quad-core processor
I was slogging through dmesg in my new LFS system and didn't find more than one CPU loaded. I have an AMD-10-5745M processor which has a quad-core. I tried to reconfigure the kernel to support it but it wouldn't boot. Am reverting back to the one I know works. Can anyone suggest the .config settings to enable this in 3.10.10? I've also heard that in addition to enhanced Radeon graphics support, kernel 3.12 has enhanced support for AMD processors, but I can't verify this. When I configured 3.10.10, I set GENERIC_x86_64=y and have been looking for support for this particular processor. Any other knowledge? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring 3.10.10 for quad-core processor
On 12/04/2013 04:02 PM, Bruce Dubbs wrote: Ken Moffat wrote: Powernow is for cpufreq (a good thing to use, IMHO, but not mentioned in LFS) and not used anymore for K10 and newer CPUs (the support is now in acpi-cpufreq). From memory, the initial K10 was the athlon64xII. My git-foo isn't good enough to identify which release that happened in, but the indications are that it was well before 3.10. SMP is the key. If Dan is building only for that machine (and doesn't intend to use the system to boot any replacement machine when the time comes) then optimizing for the specific processor family, i.e. AMD x86_64 (Opteron/Athlon/Hammer/K8 : this is CONFIG_MK8 but works on K10 ;-) might gain a little, as might Multi-Core Scheduler support. I hate to mention the obvious, but is CONFIG_X86_64_SMP set in the kernel? Other possibilities: CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_SMP=y CONFIG_HAVE_TEXT_POKE_SMP=y Mentioning the obvious always helps--the old forest and trees. In this case, however, even with cat .config | grep X86_64_SMP that particular option doesn't seem to be present. But, I discovered much to my embarassment that CONFIG_SMP was not set. Rats. Ken, are K10 and A10 the same? I suppose I could set it and if I didn't need it wouldn't hurt anything. I also suppose that I could google around to see if they are separate families or are somehow related. Some of the documentation I found today referred to increased support for AMD processors, including A10. I don't know how to go to 'kernel.org' and slog through the patches. I wouldn't even know where to start. I was, however, really distracted by my thunderbird build, which was ultimately successful, and maybe I'll be able to search more systematically tomorrow. But someone could just tell me so I wouldn't have to look. 8-) Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[blfs-support] Proprietary Radeon Driver
I'm working my way throught the Xorg installation and getting close to installing the drivers. Xorg hasn't quite caught up yet with my chip which is Radeon HD 8610G, and I'm going to use the proprietary driver from ATI. I'm asking for advice on when to install it. It's a pre-compiled binary and installs with a script. Should I install it when I install drivers for Xorg, or should I wait until I'm finished with Xorg and install it before I start Xorg for the first time? This driver comes with a QT based configuration utility. As I look at the BLFS book, I see Qt-4.85 and Qt-5.1.1. In what circumstances are both of these necessary? I'm thinking of building 5.1.1 because of its recentness. I'm not that familiar with Qt--in fact I'm quite ignorant of it--and want to install what is necessary for my system to work. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Interesting Names
On 11/26/2013 07:53 AM, William Harrington wrote: On Nov 25, 2013, at 8:06 PM, Dan McGhee wrote: There were many allusions to the new naming convention. enpxx for ethernet and wlpxx for wireless. Where does this name convention exist? I remember that xlnglp posted about what he had discovered in the different names, but I can't find what he wrote. I don't remember if he had identified a source. Possibly it came from here: http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming Check out biosdevname Sincerely, William Harrington Thanks, William. That link led down an interesting path. It appears that this name thing originated at Dell. I don't know if the fellow who came up with the idea is a maintainer for UDEV or not. Anyway, The above link led me to this: http://marc.info/?l=linux-hotplugm=128892593821639w=2 It is an interesting discussion on how to implement or cancel the name thing in udev. This, and William's suggestion, led me to biosdevname. It is a utility to take a kernel device name and return the BIOS-given name it 'should' be. (That from the biosdevname man page.) [semi-rant]There is no indication of the identity of the true BIOS name giver.[/semi-rant] Also from the biosdevname man page: The *physical* policy is the current default. However, when invoking biosdevname in udev rules, one should always specify the policy you want, as the default has changed over time. The *physical* policy uses the following scheme: emport[_virtual instance] for embedded NICs pslotpport[_virtual instance] for cards in PCI slots The *all_ethN* policy makes a best guess at what the device order should be, with embedded devices first, PCI cards in ascending slot order, and ports in ascending PCI bus/device/function order breadth-first. However, this policy /does/ not work if your PCI devices are hot-plugged or hot-pluggable, including the virtual functions on an SR-IOV device. In a hot-plug scenario, each separate udev instance will be invoked in parallel, while the device tree is still being populated with new devices. Each udev instance will see a different PCI tree, and thus cannot provide consistent enumeration. Use of this policy should be limited to only scenarios where all PCI devices are present at boot (cold-plug). So, it appears that this name thing is a udev thing and not a kernel thing. If my conclusions are correct, then I still wonder why Alan's NIC, which is the same as mine, got a different name. The only difference I know of so far is that he used LFS_SVN and I used LFS-7.4. I'm discounting the kernel difference. I don't know if there's any difference in results between UDEV-206 (LFS-7.4) and UDEV-208(LFS-SVN). The only other possible difference is that Alan may have added UDEV Extras from BLFS. On the other hand, I can understand another possible difference unless I don't understand what hot-plug means. To me it's the ability to plug something in while the computer is running and have it work--much like a USB device. If my NIC is hot-pluggable, I would have to open the laptop case to remove it. Also, in the last 3-4 months, I've not seen anyone encounter this situation but Alan. Does it exist in LFS, as written, yet? I personally don't care what my NIC is named. I just want to be able to make it work if it doesn't. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On 11/26/2013 10:34 AM, Bruce Dubbs wrote: Simon Geard wrote: On Mon, 2013-11-25 at 20:18 -0600, Bruce Dubbs wrote: I know the answer to that one. To ensure that really big iron with many ethernet devices will not have ethx assigned in random order due to race conditions. It probably comes up more frequently when using systemd which launches processes during boot up in parallel. In other words, a solution for the 1% that need it forced on the 99% who don't. But really, what's wrong with it? All the melodrama, talking about abominations and complaining about Lennart breaking things - but what's actually wrong with it, that makes that 1% solution a problem for you? It's more complex. It's changing something for everybody that was working for 99% of users. I suppose for most users that install a mainstream distro it doesn't make any difference, but for most of us that build from source, it is an unneeded change to the default that we have to work around. I wouldn't have minded the change if the new behavior wasn't made the default. Because it's not something I'd even notice - I've no idea what the network device on this machine is called, because I've never needed to know it, other than when I first set it up an age ago. What do you do differently, that the new naming convention can annoy you so much? In LFS, the /etc/sysconfig/ifconfog.* files need to know the name of the interface. Usually the init-net-rules.sh script takes care of it, but in this thread there was a difference between what Fedora comes up with and what a current udev names the interface. It was painful for Alan to get things straight. -- Bruce FWIW, I agree with Bruce. I did an abbreviated document search the results of which are in cyberspace right now to the list. I also agree with Simon. I don't care what my card is named, I just want it to work. From my short research I learned that this name thing was done for system administrators who couldn't consistently name all the items in their system. As Bruce says, this is the vast minority of users. Therefore, I think that instead of turning this behavior off, it might be better to be able to turn it on for those who need it. From what I read, this became the default for UDEV at least 18 months ago. If the changes that LFS makes to UDEV upon extracting it from systemd change this behavior, I don't know how Alan achieved naming his NIC enp3s0. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Interesting Names
On 11/26/2013 11:23 AM, Bruce Dubbs wrote: Dan McGhee wrote: On 11/26/2013 07:53 AM, William Harrington wrote: On Nov 25, 2013, at 8:06 PM, Dan McGhee wrote: There were many allusions to the new naming convention. enpxx for ethernet and wlpxx for wireless. Where does this name convention exist? I remember that xlnglp posted about what he had discovered in the different names, but I can't find what he wrote. I don't remember if he had identified a source. Possibly it came from here: http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming Check out biosdevname Sincerely, William Harrington Thanks, William. That link led down an interesting path. It appears that this name thing originated at Dell. I don't know if the fellow who came up with the idea is a maintainer for UDEV or not. Anyway, The above link led me to this: http://marc.info/?l=linux-hotplugm=128892593821639w=2 It is an interesting discussion on how to implement or cancel the name thing in udev. This, and William's suggestion, led me to biosdevname. It is a utility to take a kernel device name and return the BIOS-given name it 'should' be. (That from the biosdevname man page.) [semi-rant]There is no indication of the identity of the true BIOS name giver.[/semi-rant] Also from the biosdevname man page: The *physical* policy is the current default. However, when invoking biosdevname in udev rules, one should always specify the policy you want, as the default has changed over time. The *physical* policy uses the following scheme: emport[_virtual instance] for embedded NICs pslotpport[_virtual instance] for cards in PCI slots The *all_ethN* policy makes a best guess at what the device order should be, with embedded devices first, PCI cards in ascending slot order, and ports in ascending PCI bus/device/function order breadth-first. However, this policy /does/ not work if your PCI devices are hot-plugged or hot-pluggable, including the virtual functions on an SR-IOV device. In a hot-plug scenario, each separate udev instance will be invoked in parallel, while the device tree is still being populated with new devices. Each udev instance will see a different PCI tree, and thus cannot provide consistent enumeration. Use of this policy should be limited to only scenarios where all PCI devices are present at boot (cold-plug). So, it appears that this name thing is a udev thing and not a kernel thing. If my conclusions are correct, then I still wonder why Alan's NIC, which is the same as mine, got a different name. The only difference I know of so far is that he used LFS_SVN and I used LFS-7.4. I'm discounting the kernel difference. I don't know if there's any difference in results between UDEV-206 (LFS-7.4) and UDEV-208(LFS-SVN). The only other possible difference is that Alan may have added UDEV Extras from BLFS. The difference could be the motherboard architecture or the slot the Ethernet is plugged into. On the other hand, I can understand another possible difference unless I don't understand what hot-plug means. To me it's the ability to plug something in while the computer is running and have it work--much like a USB device. If my NIC is hot-pluggable, I would have to open the laptop case to remove it. There are such things as USB Ethernet adapters. I'm not sure how useful they are today. Perhaps some tablets have USB but not a Ethernet socket. You're right, Bruce. I had my tongue in my cheek when I wrote what I did about hotplugging. From reading that policy statement in the man page, I think my NIC should also be named enpXsY but it's eth0. Like I've said, I really don't care. These are just dots that don't quite connect for me, and I don't like loose dots hanging around. :) Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Interesting Names
On 11/26/2013 11:52 AM, Bruce Dubbs wrote: Dan McGhee wrote: From reading that policy statement in the man page, I think my NIC should also be named enpXsY but it's eth0. That's because you ran the init-net-rules.sh script as a part of the udev installation. -- Bruce That's what the book says to do. That solves the mystery for me. Having a different name then is a departure from the book, n'est pas? Now I know to ask that question. Thanks. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
Please excuse the top post. I've done it for a reason.
Alan, you have gotten a number of great suggestions from some really
helpful people. I think, however, that the waters are very muddy right
now. The main problem is that your system can't find your ethernet
card--eth0. That's the first goal. After your system sees and
acknowledges it's existence, then troubleshoot connecting if any
problems persist.
On 11/25/2013 08:59 AM, Alan Feuerbacher wrote:
On 11/24/2013 2:33 PM, Pierre Labastie wrote:
lsmod
##
Module SizeUsed by
x86_pkg_temp_thermal45110
##
This shows that either the module is not loaded or that it's configured
into your kernel.
I think Bruce was talking about a working distribution (the one you used to
build LFS for example). Boot it and run lsmod.
The information you get there could indicate the right driver for the kernel.
Ah! Here's the output from the Fedora host with lsmod :
###
Module Size Used by
snipped irrelevant stuff
mac80211 564847 1 b43
cfg80211 460310 2 b43,mac80211
rfkill 21694 5 cfg80211,bluetooth,asus_wmi [This may be only
for wireless. I don't know.]
r8169 71677 0
mii13527 1 r8169
This shows you the modules Fedora uses to get your card working.
BTW, I got the X Windows system running. The expected 3 xterm windows
pop up, but the mouse does not work. The one window that has focus
responds to linux commands. I'm certain that there's something wrong
with how I set up the mouse stuff in the LFS book, but that's for
another thread.
I recommend you start another thread for this. Otherwise it might get
lost in the responses.
To see what might be happening to your ethernet card when LFS boots, run
dmesg | grep Ethernet
Here are the results I get:
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
I left that second line it to show you that you might get a number of
lines. But the one you're looking for is the first one. You and I have
the same card.
If this doesn't show up, your system somehow does not recognize, can't
or won't load the driver. Please refer back to the results of 'lsmod'
from your Fedora distro. You need mac80211, cfg80211 and mii in
addition to r8169. It wouldn't hurt to make sure that rfkill is
available. Since we have the same card, I know that yours also supports
bluetooth and that utilizes rfkill.
So now you know that you need
CONFIG_{MAC80211,CFG80211,MII,RFKILL,R8169}=y or m in your kernel
.config. A really easy way to check this is to use cat -n [config file
name] | grep SOMETHING. The caps are important. For example, here are
my results from cat -n /boot/config-3.10.10 | grep R8169:
1843CONFIG_R8169=m
That reveals what line it's on cat -n and how it's set. You then have
to merely open the file in an editor and go to that line if you want to
change it. Use grep to find all the instances of 80211 and the
others, make any changes you need to and reboot.
FWIW, work on getting eth0 recognized first. Configure it just like the
LFS book says and don't worry what Fedora calls it. iptables and routing
aren't going to help you if your system doesn't see your card.
In my estimation 'dmesg,' 'cat -n,' 'lsmod,' 'lspci,' and 'grep' are
indispensable troubleshooting tools.
Hope this helps.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On 11/25/2013 12:46 PM, Fernando de Oliveira wrote: Em 25-11-2013 15:22, Dan McGhee escreveu: On 11/25/2013 11:05 AM, Fernando de Oliveira wrote: Em 25-11-2013 13:27, Dan McGhee escreveu: It can find the interface. Replying to Ken, Alan wrote: Em 24-11-2013 14:04, Alan Feuerbacher escreveu: On 11/24/2013 10:48 AM, Ken Moffat wrote: I think Alan needs the r8169, this is what I use : CONFIG_NET_VENDOR_REALTEK=y and CONFIG_R8169=m (actually 'y' would be better, i.e. faster to come up) Ok, I set that and recompiled the kernel. No luck; the eth0 interface will not come up. Alan Then more recently he sent a post to which I replied, in which the interface was there: Em 25-11-2013 11:59, Alan Feuerbacher escreveu: On 11/24/2013 2:33 PM, Pierre Labastie wrote: Le 24/11/2013 19:24, David Kredba a écrit : Per Ken's suggestion, I added the ethernet driver for my Realtek ethernet device, recompiled the kernel, reinstalled systemd/udev from scratch. Still no luck. Fernando, I'm responding to this only because I want to make sure that I'm not getting across the breakers with any of you experienced people on this list. No problem at all. Just I might have been wrong, but after Alan told he had built the R8169 driver, after ĸen suggested, and Bruce suggested him to do it, and other listings from LFS and Fedora that Alan provided, I thought the driver should now be there, loaded. I don't think you are wrong, and what you used in this post is precisely what I considered confusing for the rest of the discussion. I know that many times, when I get focused on solving a problem, I miss the basics. I hope he either gets his card to come up or posts the results of 'dmesg | grep Ethernet' to determine whether the driver was loaded. That particular driver needs mii, and CRC32--I think that's the one--to run and his info didn't include whether or not those two things were configured. I'm coming back to LFS after a number of years and so my detailed knowledge of how things work has many, many rust spots. I hesitated, could not remember anymore if you had written to have been away for some years or if Alan had written it. I wanted to write that these weird names might be new and confusing to some who have been away, and surprised most people here, including myself, when first appeared. ISTR it was xinglp who first noticed them. Sorry if it sounded differently. Your response was fine. In fact, you sorted through all the responses and gave a great summary. I hope that you and anyone else who frequents this list will excuse and help me polish any rust spots that I show. Because if it's not the driver for his card, I'll drop out of the help race. When it comes to networking I forget things faster than I learn them. :) And that's hard to do. I saw what xinglp posted and am on guard for it. Thankfully I haven't run into anything yet. But thanks for the reminder. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] LINKS in Graphic Mode
On 11/23/2013 01:24 PM, Pierre Labastie wrote: Le 23/11/2013 20:12, Dan McGhee a écrit : I don't know how to interpret video 29. There's no such group and adding myself to the video group didn't solve the situation. You have certainly done it, but to be sure, did you logout and then login back after adding yourself to the video group? DUH! I sure am, or at least others are as I post to this list, identifying all kinds of rust spots in my linux and LFS skills after a 3-4 year lay off. Thanks, Pierre. Worked like a charm. log-out--log-in--log-out--log-in. Same as wax-on--wax-off--wax-on--wax-off from The Karate Kid. :) Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Error: invalid file name When Booting For the First Time
On 11/23/2013 01:32 PM, Alan Feuerbacher wrote: On 11/23/2013 4:43 AM, Pierre Labastie wrote: Le 23/11/2013 03:39, Alan Feuerbacher a écrit : At any rate, I recompiled the kernel and reinstalled the grub stuff. I'm still getting an error: error: file '/vmlinuz-3.12-lfs-SVN-20131119' not found. I invoked the grub command line to see what I could see: ls = (hd0) ... (hd1) (hd1,msdos2) (hd1,msdos1) (hd2) So grub apparently sees my disk /dev/sdb as (hd1). Next I tried: ls (hd1) = Device hd1: No known filesystem detected - Total size 3907029168 sectors I also tried this with (hd0) and (hd2). Same response: no filesystem detected. So for whatever reason, grub is not recognizing the disks. Having tried the same thing with the two other disks, /dev/sda and /dev/sdc, which grub lists above as (hd0) and (hd2), I'm at a loss. All three of these disks are in operation, since when I fire up Fedora19 on /dev/sda, I can write to and read from all of the disks. Any ideas? By chance, Alan, are you trying to do this with GRUB2 installed on your EFI partition after compiling it in EFI mode? I can't find the beginning of this thread, but your results sound suspiciously close, or exactly the same as, the results I got during my recent testing. One of the conclusions that I have drawn is that GRUB2 in it's current state will not boot a kernel compiled and installed via LFS. Fedora, OpenSuse, Ubuntu and one other, seriously hack grub for their own purposes. The only way I have found to use my UEFI firmware outside of a distro is to use the efi stubs of the kernel. If this is what you're trying to do, please respond to the list and I will post a quick and dirty howto. I'm in the process of writing a more complete version for the list, but it's not ready to post. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Error: invalid file name When Booting For the First Time
On 11/23/2013 03:44 PM, Baho Utot wrote: On 11/23/2013 03:21 PM, Dan McGhee wrote: One of the conclusions that I have drawn is that GRUB2 in it's current state will not boot a kernel compiled and installed via LFS. Nonsense grub2 will boot kernels compiled and install from LFS. I do it all the time. Although I am not using UEFI. I have ONE boot partition and I have Fedora 19, FreeBSD 9.2, LFS built by the book and LFS built with rpm package manager. I also have LFS-7.2 that boots from usb drive used to correct oh sh*t problems Let me re-write that sentence so that it does not depend on the inference of the first sentence of the paragraph in which it was originally written. To stand alone that sentence should read: One of the conclusions that I have drawn is that GRUB2 in its current state will not boot a kernel compiled and installed via LFS when trying to boot from the EFI partition. That last phrase is the key. Even if someone has UEFI firmware, GRUB2 can be installed and utilized in BIOS mode. The statement refers only to the case in which GRUB2 is compiled using --with-platform=efi --target=x86_64 and installed on the EFI partition. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS7.4 - Wifi or Eth ?
On 11/22/2013 03:55 AM, Vasco Almeida wrote: It is not very practical for me to stretch a 8-meter cable from the pc to the router. So I am wondering if LFS7.4 allows a beginner to jump straight into wifi configuration in order to have networking available when coming round to booting from the LFS partition. Thanks for your input. Best regards. Vasco I am in similar situation except that my cable would have to be closer to 10 m. :) The LFS book does not specifically address wireless configuration. If you have a non-secure router; i.e. no password required, then the configuration is as simple as that described in Ch. 7 for a wired network. Instead of, or in addition to, ifconfig.eth0 you would create ifconfig.wlan0--or whatever deivice name you give your wireless adapter. All else is the same. The LFS bootscripts would bring up your wireless adapter too. If your router is secure and you don't want to use static routing, you need to install some things from BLFS. DHCP, for its client, or dhcpcd and wpa_supplicant. These packages also have dependencies that need to be installed. Additionally, there are some bootscripts from BLFS that are required. This is the first build I have done and used wpa_supplicant and, for me, dhcpcd. The combination worked, using the configuration supplied by the packages and the BLFS book, right out of the box. Good luck. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] No wireless connection to network
On 11/22/2013 06:27 AM, hans kaper wrote:
Op Mon, 18 Nov 2013 06:35:07 +0100 schreef Bruce Dubbs
bruce.du...@gmail.com:
hans kaper wrote:
Compared with the discussion about efi-booting, which I follow with
interest and admiration, I am still in the stone-age. I installed LFS 7.4
on an old laptop. It boots fine, but I cannot connect wireless to my
network.
Wired is no problem (although I cannot find the eth0-device anywhere; how
does this work?).
The laptop uses a Cisco-Linksys wireless usb-adapter. Running udevadm
monitor and inserting the adapter gives device-information that I put in a
rule into 70-persistent-netrules with the name wlan0:
SUBSYSTEM=usb, ACTION==add, ATTR{idVendor}==13b1,
ATTR{manufacturer}=Cisco-Linksys , ATTR{idProduct}==0020, NAME=wlan0
I added ifconfig.wlan0 to /etc/sysconfig:
ONBOOT=yes
IFACE=wlan0
SERVICE=ipv4-static
IP=192.168.178.26
GATEWAY=192.168.178.0
PREFIX=24
The GATEWAY shouldn't have this address with this netmask. The .0 is
the network address and it will probably confuse the routing table.
You are right, a typo.
I am now looking into the kernel, comparing the Mint-kernel with lfs, whether
I miss something there.
And installing wpa-supplicant of course, but that only makes sense when the
device is found and ready.
Hans.
Hans, what is in 'dmesg' about your network cards? From that you can
tell whether you have a kernel, driver or set-up problem. Since it's usb
and if your kernel is modular, it is important that the usb modules load
in the right order. The book covers this in the kernel chapter.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[blfs-support] Radeon Extra Firmware [WAS: Boot Failure with wlan0 firmware]
On 11/18/2013 01:18 PM, Ken Moffat wrote: On Mon, Nov 18, 2013 at 11:56:14AM -0600, Dan McGhee wrote: If you look down there, you will see rt3290.bin, and if you click on 'plain' in a graphical brower you can put it in /lib/firmware [ so that future kernel versions will also be able to find it ]. [The above refers to 'linux-firmware' obtained from 'git.' (inserted by Dan)] If it is anythong like recent radeon graphics chips, you might have to repeat the process for subsequent firmware blobs. When I came back to this post to ask my current question, I couldn't pass this up. My radeon graphics chip is so recent that the linux Catalyst driver at ATI is *.beta1. I learned that I needed this when I learned that for the current generation of on board ATI-Radeon HD graphics 'fglrx' was not compatible and that ATI would release only proprietary drivers. I burned up three laptops because of this ignorance. Ergo, I'm really sensitive and cautious towards my graphics. A nice segue for my question below. I might have misunderstood a few of the datails, but this is what I currently do on my newest radeon machine [ the one that needs loads of blobs ] n the kernel .config- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE=radeon/BTC_rlc.bin radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin radeon/ARUBA_rlc.bin radeon/TAHITI_uvd.bin rtl_nic/rtl8168e-3.fw CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware CONFIG_FW_LOADER_USER_HELPER=y I'm asking this question because I really want to re-build my kernel only once. My LFS kernel is looking for ARUBA_pfp.bin and TAHITI_uvd.bin. In '/linux-firmware/radeon I have the same three ARUBA files that you have indicated. So, obviously, I'll put them in /lib/firmware and indicate them in the extra_firmware line. When it comes to TAHITI though, I have the -uvd.bin, but also _ce.bin, _mc.bin, _me.bin, _pfp.bin, _rlc.bin and _smc.bin. Do you know if I need all those TAHITI files, or should I just put them in to be safe and not have to reconfigure my kernel again, and again, and again? From memory, the help on the firmware settings is a bit confusing and with this setup it pulls the firmware in near the end of the kernel compile - at which point any missing firmware becomes apparent. My firmware is in directories (radeon/, rtl_nic/) because that is conventional for those particular blobs. For you, I guess you can put rt3290.bin into /lib/firmware and use CONFIG_EXTRA_FIRMWARE=rt3290.bin. Technically, you could put it/them anywhere that is readable at kernel compile time, but /lib/firmware is the common choice. After you set it in menuconfig and save the config, take a look at it to confirm that the entries look correct. In particular, /lib/firmware unless you want to use lib/firmware in the kernel tree and to have to reload that every time you untar the kernel source. ĸen Ken, this has turned out to be a quite useful and necessary piece of information. Thanks. Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On 11/22/2013 09:17 AM, Douglas R. Reno wrote: Hello, After completing a successful build of LFS, I restart to get into the system for the first time and my screen turns black and then comes back on for about 1 second. I have a NVidia Vanta LT card in my PC. I am using the Nouveau drivers for the framebuffer, as I plan to install X. I have Nouveau configured as well in the kernel. I can tell that the system booted successfully, but I have already tried various options in kernel configuration (such as Generic VESA). I would also like to keep my bootlogo, but I am willing to remove it if necessary. The system appears to have issues detecting the card because of the resolution (it stays at about 640x480). I have booted several LiveCDs (Ubuntu and System Rescue CD) successfully without this problem. Host: System Rescue CD (added bison to image) NOTE: this system is i686 Compaq Presario 5230us if that helps. Thank you, Douglas Reno If you haven't done it yet, I highly recommend examining the output of 'dmesg.' I find it a really useful diagnostic and troubleshooting tool for things like this. Through it I identified and resolved, with the help of this list, a problem with my wireless driver, and I'm currently working on finetuning my graphics drivers. It's a great help. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] LFS 7.3 Screen Flickering problem
On 11/22/2013 10:23 AM, Douglas R. Reno wrote: Dan, If I were able to export the contents of dmesg to a file, could I use grep to sift through it faster? First of all, let me gently remind you about top posting on this list. Please don't do it. Dmesg is nothing more than the kernel log. It already exists in a file. Dmesg is only, I think, for the current boot and it updates at each kernel event. If it's easier for you to go to a file, then go ahead. The slowness is a function of your ability to read, recognize and comprehend. So whatever helps you the most. Dan On Nov 22, 2013 10:18 AM, Dan McGhee beesn...@grm.net mailto:beesn...@grm.net wrote: On 11/22/2013 10:01 AM, Douglas R. Reno wrote: I will try it tonight when I have a chance. Is there anything specific I should be looking for? I can't describe it, but I know it when I see it. :) Sorry, I couldn't resist it. Dmesg output is quite verbose. I use 'dmesg | less' You'll have to wade through all the kernel, memory and bus stuff. Just scan for anything having to do with graphics: framebuffer, fb(0), trying to load firmware, dri, etc., etc., etc. You'll also recognize the names of your graphics drivers. I don't remember whether or not there are any references to VESA or VGA, but there are instances of resolution. Going through dmesg can be tedious. However, if you're meticulous about it and bear with it, you will probably find something to put you on the right track. I many times get enough information only to ask the right question. But it's a start. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Good Results with LFS and EFI
At the start here, I want to apologize to those who may be frustrated with my changing the subject line for this EFI stuff. The subject appears to be at least a warm one, if not a hot one. Therefore, many things get hidden in the replies. So, in an attempt to keep things fresh and simple, I just start a new thread. When the time comes, and it will be quite soon now, I will post the basics of my how I did it and, if people are interested, post what I learned, the reasons why I did what I did, my conclusions and what I think is left for my future testing. I was able to get the kernel to load. That's the good news. The bad news is that I got a kernel panic. But, as I write this, I'm fixing that. I have another kernel in the oven. Using the kernel's efi-stubs was last on my list of testing. I thought I knew grub pretty well and didn't know anything about initrd's and initramfs, and everything that I had read about the efi-stubs included one of those two. But Geoff's success with his imbedded kernel command line looked promising so I did it. One of the things he cautioned about, and I'm reinforcing now, is to make sure that all the drivers the kernel needs to boot are either configured into the kernel or made available on the EFI partition so that the kernel can load them. That turned out to be my problem. I had the ahci drivers configured as modules, and since the kernel couldn't load my hard drive, it couldn't mount the filesystem. Here are the kernel configuration options I used: CONFIG_CMDLINE_BOOLEAN=y CONFIG_CMDLINE=root=/dev/ (=partition containing LFS) CONFIG_EFI_PARTITION=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_RELOCATABLE=y CONFIG_EFI_VARS=n (shows up as Not Set) CONFIG_EFIVAR_FS=y Please note that these are the same as Geoff posted last night with the exception that he used EFIVARS and not EFIVARFS. I did this because efivarfs is replacing efivars sometime in the future. Then it's just a matter of getting the kernel to the EFI partition and getting the entry into the Boot Manager. My EFI partition is mounted at /boot/efi so it was: mkdir -vp /boot/efi/EFI/lfs-7.4 cp -v /boot/vmlinuz-et cetera /boot/efi/EFI/lfs-7.4/vimliuz-et cetera.,efi I don't know if the .efi was necessary, but all the files I've seen on the EFI partition end like that. Geoff gave the command he used for efibootmgr, but I started using gummiboot, so I did my gummiboot thing. The result of booting was a kernel panic, but that's farther than I have gotten since I started doing this research. I can fix a kernel panic. But the interesting conclusion that I have drawn is that unless GRUB2 is hacked it won't boot a kernel in the old way. When I was testing, I never got my kernel to load and I couldn't load Ubuntu unless I chainloaded its efi file like I do Windoze. Last night William Harrington posted a link to the Fedora site regarding grub patches. There were a lot. Also, let me quote the FEDORA.README from that link: GRUB 2 provides various feature enhancements over the previous GRUB version (referred to as GRUB, or GRUB Legacy) which has been unmaintained upstream for years. GRUB has thus been deprecated in Fedora and replaced by GRUB 2 for BIOS systems. (EFI systems still uses GRUB Legacy from the new grub-efi package.) So, Fedora is using grub legacy to boot into an efi environment. The vast majority of threads I have found at arch-linux, ubuntu, gentoo and openSuse all talk about not being able to boot other things with GRUB2. Very few, if any, people complain about their distros not booting. I think that if LFS is going to document how to boot using an EFI partition, then the most stripped down way is with the kernel efi-stubs and efibootmgr. If someone chooses that option for their system, there is no need for GRUB2. Multiboot options can be handled either by efibootmgr, which is the simplest, gummiboot or rEFInd. I'm still going to try to find a way to use GRUB2 in this. But, I haven't done any building for my LFS system in almost a month and I want to get back to it. I'm going to let this grub stuff grow penicillin in my brain for awhile and then try again. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Almost Finished with Grub and EFI--But First Some Basics
On 11/13/2013 07:52 PM, Bruce Dubbs wrote: Dan McGhee wrote: But in the meantime, here's the command I used to make the image: grub-mkimage -O x86_64-efi -o grubx64.efi -p part_gpt fat ext2 normal chain boot configfile linux multiboot I'm not sure why you want --prefix=''. I think you want /efi/boot. Have you seen http://wiki.osdev.org/GRUB#Grub_for_EFI ? Bruce, I've been meaning to answer this question, but I kept being diverted by my testing. I found this http://lists.gnu.org/archive/html/help-grub/2010-06/msg00026.html at the grub mailing list. It's short so I'll just quote it: Actually change the command to : ./grub-mkimage -d . -o grub.efi -O TARGET_EFI_ARCH-efi -p Your list of GRUB2 Modules The 2 double quotes after -p is very important. Without the double quotes, grub_prefix is set to /boot/grub (default) in the generated efi app and grub.efi searches for /boot/grub/grub.cfg (not /efi/grub/grub.cfg or /efi/grub2/grub.cfg). If you specify null prefix parameter, grub.efi will check for the path from where it has been loaded and set that path as grub_prefix, thus making grub.efi portable. Your insights are so valuable that I wanted to get back to you right away. Sorry for the delay. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Good Results with LFS and EFI
On 11/18/2013 10:54 AM, Bruce Dubbs wrote: I monitor the grub-devel mailing list and there is a lot of activity discussing UEFI. This seems to be an important issue. What I'd like to do is have GRUB load and then be able to load whatever I want to whatever partition I specify without having to rebuild a kernel every time. I also like having the command line capability of GRUB. I agree with you. GRUB is a great tool, and I also believe that it's in a state of transition. Using GRUB you can do what you want from the menu except boot your own LFS. :) And, you're right about the kernels. I've spent the majority of two days configuring kernels. yuk. I just wish I knew C so that I could understand what's going on at the dev level of grub. Right now I think GRUB on UEFI are really bleeding edge. I can't participate directly because I don't have the HW but I think your work is important for LFS. It is, at a minimum, a good transition to what will end up being a stable solution. Thanks for the vote of confidence. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/17/2013 04:10 PM, Alan Feuerbacher wrote: On 11/16/2013 6:10 PM, Dan McGhee wrote: snipped your answers to my questions. Thank you. They helped. For background on my comments below: Motherboard: ASUS P8Z77-V LK with latest BIOS update #1104 Intel i7-3770K 16G Corsair DDR3 2 Western Digital 2TB hard drives One drive has Fedora 19 installed on it. The other drive has all the LFS stuff on it. I had a setback today. Up through this morning, I was able to execute Launch EFI Shell from filesystem device, and to do various things in the EFI shell. But after making some changes to my hard drive arrangement several times in an attempt to get the system to boot up, this simply quit working. No matter what I name the EFI shell -- shellx64.efi and variations of that -- and no matter which hard drive I power up -- one or the other or both -- and no matter which SATA slot I plug the drive(s) into, the BIOS will not launch the EFI shell. This, even after I updated the BIOS again. So I've filed a technical request with ASUS Support to try to get some explanation, and hopefully documentation, on what's going on. I'm really frustrated because it's like the ASUS BIOS changes itself without input from me. The really weird thing about the ASUS board is that no matter which SATA slot I put the hard drives in, it always finds the Fedora Linux image, but never the LFS image. This tells me that the BIOS is doing some undocumented things. I had a similar experience but on only one hard drive. I would run an experiment and try to boot. The boot would fail and the System Boot Manager would remove my LFS entry and write one for Ubuntu. There was a time when, just trying to see what would happen, I had four entries for Ubuntu. I learned that there was at least one thing I needed to do: not use efivars but efivarfs. Once I did this, I could keep my LFS entries--although I still couldn't get LFS to boot. It's interesting that you're having a similar experience but with Fedora. That distro, along with Ubuntu and OpenSuse, have paid Microsoft and can use secure boot. Since the key and the signature reside in the firmware, I'm wondering if it isn't the firmware that's giving priority to Ubuntu in my case and Fedora in yours. Microsoft can black list any signature it wants at any time. These revisions are installed by means of Windows Update. Keys are OEM specific, and organizations like ASUS and HP incorporate them into their firmware. These OEM's can change their key configurations at any time. I'm guessing they do it through BIOS updates. Your story really interests me. There is only one other option that's keeping me from booting in this environment. It's so distasteful that I don't even want to write it. But, at least in my firmware, it may be necessary for me to sign my kernel. That's not even for secure boot. I hope that's not true. What are the implications of that? Why is it so distasteful? The introduction to the answer to your question is what I wrote above. At its worst, the situation could be, or become, that an individual must register a key with the OEM to install anything other than what came on the computer--or even use the firmware. What's worse is that an OEM could black list my key on my own computer. For what reason, I don't know, but it's an extension of the logic. I just don't like any person or organization telling me how to operate and what I can run on my own machines. I hope I don't sound like a conspiracy theorist. I'm not. But look at what has happened in the Windows World. We can't even get installation disks with our computers any more. That was a 3/4 rant. I apologize. One conclusion that emerges as a result of yours, mine and Geoff's experiences is that GRUB built from source may not be able to deal with the EFI environment in the way we're used to. I don't know how, or even if, the distros have modified GRUB in their packages. Everything I've read and all my experiements say that GRUB2 should work. Thus far, I haven't been successful--almost, but not quite. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/17/2013 06:03 PM, Ken Moffat wrote: On Sun, Nov 17, 2013 at 05:10:57PM -0500, Alan Feuerbacher wrote: On 11/16/2013 6:10 PM, Dan McGhee wrote: The kernel. It dies with a message like ... kernel panic ... Must you do a hard reset to start over or can you use ALT-CTRL-DEL? I have to recycle the power. With your later comment about today's setback, this suggestion is irrelevant unless/until you can get back to this state. But if you manage to recover to there, please see if any indications of what is wrong get to the screen. If anything useful is there (i.e. not scrolled off), google it just in case someone has found a fix. If not, my first suggestion is to try newer kernels. This sounds very like the sort of thing that was discussed in the various lkml threads about EFI/UEFI I alluded to when replying to Dan in the past month (a change which fixes some machines breaks others). I suggest that you start by trying 3.12.0. No idea if anything there will fix it, but it is current. I normally don't recommend people try early -rc kernels, and 3.13-rc1 wasn't even released when I last checked. If you haven't had any success when 3.13-rc1 is released then certainly try it : but expect unrelated breakage in all sorts of weird and wonderful corner cases. So, if 3.12.0 doesn't work I would then try 3.10.0 in case a later fix broke something, and after that perhaps 3.8.0, 3.6.0, 3.4.0 (assuming your glibc --enable-kernel= isn't as aggressive as mine and will let your init run old kernels). IFF you can find something old which boots, you then get to work out what broke it. ĸen, glad to be a luddite using the bios and an MBR - at least until you guys have sorted out what needs to be done. I don't know where in the boot sequence Alan was when he had a freeze. I know it happened to me early on and I had to do a hard reset. There were no messages from grub or kernel. Just a blank screen. When I figured out how to configure the grub build for efi and to use efivarfs, the system would still stop after I got the echo of Booting LFS-7.4.. But in those instances I could reboot with ALT-CTRL-DEL. That told me that I had successfully gotten in to the grub system, but that something was stopping me from going further. I googled, and googled and googled--in addition to offering the birth rights of my first-born-son--but I got no pertinent or useful results. Ken, you have something about using a newer kernel. I think it was in rodsbooks that I read something to the effect this fails on some kernels, then works on the next one. My efforts have led me back to grub or kernel 3.10.10 as the culprit. I used the configuration file for kernel 3.8.something from Ubuntu. I knew that config would produce a bootable kernel. But I got the same results. Geoff reports that he can boot without GRUB by using the efi-stub of 3.10.10. This tells me that 3.10.10 is one of those kernels in which it works. Soo, I'm back to looking at GRUB. I've got one more test to do before I copy my 3.10.10 to the EFI partition in an attempt to get the results Geoff got. With all the reading I've done at Arch-wiki, Gentoo-wiki, rodsbooks, Ubuntu I think I've discovered that this stuff is so new, no one really knows how it works or how to make it work reliably build to build or platform to platform. I find the lack of information at Linux Foundation, kernel.org and grub terribly interesting. It supports my newness conclusion. There even are no How do I fix this? posts at Linux Questions. Bottom line. I'm still trying. But it looks like, as far as efi is concerned, kernel efi-stubs and efibootmgr are the way to go. With this there is no need for grub. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/16/2013 05:44 PM, Geoff Swan wrote: On 17/11/2013 10:10 AM, Dan McGhee wrote: On 11/16/2013 03:40 PM, Ken Moffat wrote: On Sat, Nov 16, 2013 at 02:04:31PM -0500, Alan Feuerbacher wrote: Hi, After getting the stock LFS system installed, with an MBR type boot installation, I'm experimenting with installing to a UEFI type boot location on a brand new hard drive. I've been reading a lot of online documentation, and have tried a first-cut installation, but am not having success in installing. While I can install the entire set of LFS programs, and a lot of BLFS programs, when I try to boot up, Linux fires up but quickly generates a fatal error. Is there any possibility of advice from the LFS staff? http://www.mail-archive.com/lfs-support@linuxfromscratch.org/ See the posts from Dan McGhee - most recently on 13th November, but starting on 28th October. Four threads, titles mentioning GRUB or EFI. At the moment they are all on the first page at that link, at least in firefox. Our best advice / guesses is in those threads. Dan hasn't cracked it yet, but your hardware might be different. ?en I thought I was going to be able to report success this afternoon, but as yet no joy. My efforts so far have resulted in the following conclusions: 1. There is something wrong in my grub set-up. 2. My kernel is not bootable. 3. I have missed something in the EFI info. At this point, all I want is some indication that my kernel is booting. As long as I get only one message from the kernel and the system freezes I can conclude that all else is fine except my kernel. I'm writing this e-mail on the fly and don't have my EFI sources at hand. I read last night that from the EFI partition the bootloader--in this case GRUB--doesn't know where the file system is even though it can read the partition table. Therefore, and initramfs is called for. I know nothing about these. I've read what the BLFS book has and have tried it with no success. At this point, I don't know enough to solve any gotcha's that the initramfs hint gives. Gonna try dracut. If I can't make any head-way in the next few days, I'm going to install a minimal ArchLinux system and try the various GRUB options. I don't think they sign their kernels--see last paragraph--and that will test the GRUB stuff. I cannot verify this in any documentation. It's just a hunch I have. When it comes to booting using an EFI partition, we must ignore everything we've learned about booting and using GRUB. It may be that using GRUB in a multiboot environment we cannot use the linux /boot/vmliz* root=/dev/xxx ro to get to another distro. We may have to use grub's chainloader to do that. I say this because, I have not been able to get Ubuntu to boot from my LFS-7.4 system in the old way. I was successful using the chainloader. If all this is true, then the easiest way to accomplish this is to use 'efibootmgr' or 'gummiboot' and boot everything thing we have from the EFI partition. My goal is to be able to be able to answer these questions when my testing is over. @Alan Did you remove GRUB from your MBR Protected Layer or are you still using it? Do you use an initrd or initramfs? Did you boot your kernel successfully before you started these EFI experiments? Does your failure message come from the kernel or from the LFS bootscripts? What does it say? Must you do a hard reset to start over or can you use ALT-CTRL-DEL? There is only one other option that's keeping me from booting in this environment. It's so distasteful that I don't even want to write it. But, at least in my firmware, it may be necessary for me to sign my kernel. That's not even for secure boot. I hope that's not true. Dan Dan, I could not get EFI and Grub2 to co-operate so I went for the Linux EFI image route instead and eliminated the boot manager. It is not really necessary unless you want to select from different kernels on the system. The kernel must be compiled with the EFI settings: CONFIG_EFI=y CONFIG_RELOCATABLE=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_EFI_PARTITION=y CONFIG_EFI_VARS=y CONFIG_EFI_STUB=y and also the kernel parameters built-in: CONFIG_CMDLINE=root=/dev/sda3 ro --verbose then use efibootmgr to register the new kernel image with the BIOS, so it can be selected at boot time. Geoff Geoff, your comments are giving me a break from answering questions in make oldconfig :) Just so I understand. You got your kernel--3.10.10 (?)--to boot from the EFI partition? And without initrd or initramfs? The answer to this question is important to me. As I said before, I don't have my references close right now, but you may want to consider reconfiguring your kernel with CONFIG_EFI_VARS=n and enabling evifarfs. efivars is going away. I'll check my references and post later with the appropriate one. I have been using efivarfs mounted at /sys/firmware/efi/efivars with great success. Otherwise, I have been
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/16/2013 05:44 PM, Geoff Swan wrote: On 17/11/2013 10:10 AM, Dan McGhee wrote: On 11/16/2013 03:40 PM, Ken Moffat wrote: On Sat, Nov 16, 2013 at 02:04:31PM -0500, Alan Feuerbacher wrote: Hi, After getting the stock LFS system installed, with an MBR type boot installation, I'm experimenting with installing to a UEFI type boot location on a brand new hard drive. I've been reading a lot of online documentation, and have tried a first-cut installation, but am not having success in installing. While I can install the entire set of LFS programs, and a lot of BLFS programs, when I try to boot up, Linux fires up but quickly generates a fatal error. Is there any possibility of advice from the LFS staff? http://www.mail-archive.com/lfs-support@linuxfromscratch.org/ See the posts from Dan McGhee - most recently on 13th November, but starting on 28th October. Four threads, titles mentioning GRUB or EFI. At the moment they are all on the first page at that link, at least in firefox. Our best advice / guesses is in those threads. Dan hasn't cracked it yet, but your hardware might be different. ?en I thought I was going to be able to report success this afternoon, but as yet no joy. My efforts so far have resulted in the following conclusions: 1. There is something wrong in my grub set-up. 2. My kernel is not bootable. 3. I have missed something in the EFI info. At this point, all I want is some indication that my kernel is booting. As long as I get only one message from the kernel and the system freezes I can conclude that all else is fine except my kernel. I'm writing this e-mail on the fly and don't have my EFI sources at hand. I read last night that from the EFI partition the bootloader--in this case GRUB--doesn't know where the file system is even though it can read the partition table. Therefore, and initramfs is called for. I know nothing about these. I've read what the BLFS book has and have tried it with no success. At this point, I don't know enough to solve any gotcha's that the initramfs hint gives. Gonna try dracut. If I can't make any head-way in the next few days, I'm going to install a minimal ArchLinux system and try the various GRUB options. I don't think they sign their kernels--see last paragraph--and that will test the GRUB stuff. I cannot verify this in any documentation. It's just a hunch I have. When it comes to booting using an EFI partition, we must ignore everything we've learned about booting and using GRUB. It may be that using GRUB in a multiboot environment we cannot use the linux /boot/vmliz* root=/dev/xxx ro to get to another distro. We may have to use grub's chainloader to do that. I say this because, I have not been able to get Ubuntu to boot from my LFS-7.4 system in the old way. I was successful using the chainloader. If all this is true, then the easiest way to accomplish this is to use 'efibootmgr' or 'gummiboot' and boot everything thing we have from the EFI partition. My goal is to be able to be able to answer these questions when my testing is over. @Alan Did you remove GRUB from your MBR Protected Layer or are you still using it? Do you use an initrd or initramfs? Did you boot your kernel successfully before you started these EFI experiments? Does your failure message come from the kernel or from the LFS bootscripts? What does it say? Must you do a hard reset to start over or can you use ALT-CTRL-DEL? There is only one other option that's keeping me from booting in this environment. It's so distasteful that I don't even want to write it. But, at least in my firmware, it may be necessary for me to sign my kernel. That's not even for secure boot. I hope that's not true. Dan Dan, I could not get EFI and Grub2 to co-operate so I went for the Linux EFI image route instead and eliminated the boot manager. It is not really necessary unless you want to select from different kernels on the system. The kernel must be compiled with the EFI settings: CONFIG_EFI=y CONFIG_RELOCATABLE=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_EFI_PARTITION=y CONFIG_EFI_VARS=y CONFIG_EFI_STUB=y and also the kernel parameters built-in: CONFIG_CMDLINE=root=/dev/sda3 ro --verbose then use efibootmgr to register the new kernel image with the BIOS, so it can be selected at boot time. Geoff I think efivarfs is new in 3.10.10 CONFIG_EFIVAR_FS=(y or m) is what I recommend if you're using 3.10.10 Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/16/2013 06:51 PM, Alan Feuerbacher wrote: On 11/16/2013 7:36 PM, Dan McGhee wrote: I think efivarfs is new in 3.10.10 CONFIG_EFIVAR_FS=(y or m) is what I recommend if you're using 3.10.10 The information I've gotten so far about setting these CONFIG variables, from Arch Linux, rodsbooks.com and other places, is summarized here, from my incomplete notes from the last several weeks: *** # For UEFI booting, according to ArchLinux you also need to ensure that the following # https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface # kernel configuration options are set: ## CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y # UEFI Runtime Variables Support (efivarfs filesystem - /sys/firmware/efi/efivars). This option is important as this is required to manipulate UEFI Runtime Variables using tools like /usr/bin/efibootmgr. The below config option has been added in kernel 3.10 and above. CONFIG_EFIVAR_FS=y # UEFI Runtime Variables Support (old efivars sysfs interface - /sys/firmware/efi/vars). This option should be disabled. CONFIG_EFI_VARS=n # GUID Partition Table GPT config option - mandatory for UEFI support CONFIG_EFI_PARTITION=y # Note: All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos. ## # # ALSO need to set this: ## CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE= ## # See # and in make menuconfig set these with Processor Type and Features - Built-in kernel command line # # Also, in installing Cups-1.6.3 the BLFS book states: # # Kernel Configuration # Note # # There is a conflict between the Cups libusb backend and the usblp kernel driver. If you want to use Cups with libusb, do not enable USB Printer support in your kernel. # # If you want to use the kernel usblp driver, enable the following options in your kernel configuration and recompile the kernel: # # If you want to use the kernel usblp driver, enable the following options in your kernel configuration and recompile the kernel: # # Device Drivers --- # [*] USB support --- # .. # In make menuconfig, get rid of the * in USB support *** Since I have not yet been successful in booting Linux 3.10.10 with UEFI, I can't comment on the above. For what it's worth. Alan Alan, thank you for validating my research. Let me validate yours. Those recommendations work. Did you see the questions I asked you earlier? I hope you will answer them. They are important to my research. I'm so close to success, I can smell it. Hopefully it won't be long and I can post everything here. It will be quite long. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/16/2013 07:26 PM, Alan Feuerbacher wrote: On 11/16/2013 8:17 PM, Dan McGhee wrote: Alan, thank you for validating my research. Let me validate yours. Those recommendations work. Good! Did you see the questions I asked you earlier? I hope you will answer them. They are important to my research. Yeah, I saw them. I'm in the process of answering them, but I have to revisit a lot of stuff first, so it will take awhile. No rush. I'm so close to success, I can smell it. Hopefully it won't be long and I can post everything here. It will be quite long. We can compare notes. I've got a LOT of stuff as well. And a lot of holes left to fill. I have holes too. I'm looking forward to the exchange of info. Earlier on this list Geoff Swan posted. I want to verify from him that he got kernel 3.10.10 to boot from using the system Boot Manager. I'm trying to verify the need for an initrd or initramfs. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Help with Installing to UEFI Motherboard
On 11/16/2013 07:56 PM, Geoff Swan wrote: Just so I understand. You got your kernel--3.10.10 (?)--to boot from the EFI partition? And without initrd or initramfs? The answer to this question is important to me. Yes. 3.10.10. Selectable in the BIOS efi boot manager and boots directly, fast. No initrd or initramfs is needed, I built all the drivers required for the server hardware into the kernel. If you build modules required for boot then you have to make them available in the EFI partition too. I found it easier to build everything into the kernel. Available in a directory on the EFI partition? This might be why many, many people use initramfs. Thanks for the info, Geoff. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] More GRUB--Progress by Failure--Now Questions
I pooled Bruce's and Ken's comments from the last few days with my
observations and goals. I now get GRUB2 to load in EFI. That's a good
thing. I must do it manually by interrupting the boot process and
selecting grubx64.efi. I want the Boot Manager to default to this, but
that's the project after I can boot LFS-7.4, Ubuntu and Windows 8 from
my grub screen. I cannot boot either LFS-7.4 or Ubuntu from my
grubx64.efi.
Thinking of what Ken said about my LFS kernel not being bootable, I
added a menuentry for Ubuntu whose kernel I know boots. The same thing
happens when I try to boot LFS or Ubuntu--the screen goes blank and I
get a white, non-flashing dash in the upper left hand corner of my
screen. I now have a situation I that can be solved practically
rather than experimenting with theory--a good change. I think my
grub.cfg needs massaging. Here is that file in all of its radiant beauty:
set gfxmode=auto
insmod all_video
insmod gfxterm
set lang=en_US
set timeout=10
menuentry 'LFS-7.4' {
insmod part_gpt
insmod ext2
set root=(hd0,gpt6)
linux /boot/vmlinuz-3.10.10-lfs-7.4 root=/dev/sda6 ro
}
menuentry 'Ubuntu' {
insmod part_gpt
insmod ext2
set root=(hd0,gpt10)
linux /boot/vmlinuz-3.8.0-33-generic root=/dev/sda10 ro
initrd /boot/initrd.img-3.8.0-33-generic
}
menuentry Windows 8 {
set root=D60C-39DF
chainloader (${root})/EFI/Boot/bkpbootx64.efi
}
Before I quit last night, I had only the menuentry for LFS in the file
and when I tried to boot, I got the message No suitable video mode
found. This morning I read, and copied and plagiarized and came up
with the entries at the top of the file. I don't know if I have good
ones, or enough or the right ones. What I do know is that in addition
to the inability to boot LFS7.4, I cannot boot Ubuntu--which I know
boots--using this grub.cfg. (BTW, I did not test Windows from this file.)
As a highlight (?) to this post let me add something. As I was writing
this and looked at the entry for Windows 8, I thought that I could get
Ubuntu to boot, by directing grub to Ubuntu's *x64.efi file. If that's
true, then I would be using GRUB as a Boot Manager in EFI and not a
bootloader--although each grub.cfg would have that's distro's root,
kernel and image files. This bears further research.
But for right now, I'd like to get both LFS and Ubuntu to boot from this
grub.cfg using linux and initrd lines--like in the old :) days.
Hopefully, I can get a good analysis and fix from the folks here on this
list. I could do the video stuff before grub evolved to the state it
is today. Now, I'm in the dark--and not because it's night. :)
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] More GRUB--Progress by Failure--Now Questions
On 11/10/2013 09:22 AM, Dan McGhee wrote:
I pooled Bruce's and Ken's comments from the last few days with my
observations and goals. I now get GRUB2 to load in EFI. That's a good
thing. I must do it manually by interrupting the boot process and
selecting grubx64.efi. I want the Boot Manager to default to this, but
that's the project after I can boot LFS-7.4, Ubuntu and Windows 8 from
my grub screen. I cannot boot either LFS-7.4 or Ubuntu from my
grubx64.efi.
Thinking of what Ken said about my LFS kernel not being bootable, I
added a menuentry for Ubuntu whose kernel I know boots. The same thing
happens when I try to boot LFS or Ubuntu--the screen goes blank and I
get a white, non-flashing dash in the upper left hand corner of my
screen. I now have a situation I that can be solved practically
rather than experimenting with theory--a good change. I think my
grub.cfg needs massaging. Here is that file in all of its radiant beauty:
set gfxmode=auto
insmod all_video
insmod gfxterm
set lang=en_US
set timeout=10
menuentry 'LFS-7.4' {
insmod part_gpt
insmod ext2
set root=(hd0,gpt6)
linux /boot/vmlinuz-3.10.10-lfs-7.4 root=/dev/sda6 ro
}
menuentry 'Ubuntu' {
insmod part_gpt
insmod ext2
set root=(hd0,gpt10)
linux /boot/vmlinuz-3.8.0-33-generic root=/dev/sda10 ro
initrd /boot/initrd.img-3.8.0-33-generic
}
menuentry Windows 8 {
set root=D60C-39DF
chainloader (${root})/EFI/Boot/bkpbootx64.efi
}
Before I quit last night, I had only the menuentry for LFS in the file
and when I tried to boot, I got the message No suitable video mode
found. This morning I read, and copied and plagiarized and came up
with the entries at the top of the file. I don't know if I have good
ones, or enough or the right ones. What I do know is that in addition
to the inability to boot LFS7.4, I cannot boot Ubuntu--which I know
boots--using this grub.cfg. (BTW, I did not test Windows from this file.)
As a highlight (?) to this post let me add something. As I was writing
this and looked at the entry for Windows 8, I thought that I could get
Ubuntu to boot, by directing grub to Ubuntu's *x64.efi file. If that's
true, then I would be using GRUB as a Boot Manager in EFI and not a
bootloader--although each grub.cfg would have that's distro's root,
kernel and image files. This bears further research.
But for right now, I'd like to get both LFS and Ubuntu to boot from this
grub.cfg using linux and initrd lines--like in the old :) days.
Hopefully, I can get a good analysis and fix from the folks here on this
list. I could do the video stuff before grub evolved to the state it
is today. Now, I'm in the dark--and not because it's night. :)
Thanks,
Dan
Using the article that Ken found at Arch-Wiki I learned that video had
to be initialized in efi. I changed the first part of grub.cfg to
insmod efi_gop
insmod efi_uga
insmod font
if loadfont ${prefix}/fonts/unicode.pf2
then
insmod gfxterm
set gfxmode=auto
set gfxpayload=keep
terminal_output gfxterm
fi
That changed the results to a new blank screen. Although slight, it's
still more progress. But I have exhausted my knowledge and my googling
isn't revealing anything new. I'm stymied. I'd like to get some
suggestion as to where to go from here.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
I know I'm top-posting and ask for forgiveness. Please consider this a
preface to my responses to what Bruce offered. And thanks, Bruce, for
your thoughts. I am frustrated by not being able to find documentation
about what the grub modules do--and now for many of the variables grub
uses. A simple this does that would suffice. But I digress.
I have so many things ricocheting around the grey cells that I may
have unwittingly supplied muddied water in my original request. I need
to focus right now on only one thing--getting LFS-7.4 to boot only once
in an uefi environment. That means I do not want to use legacy in my
firmware and I do not want grub to write to the Protected MBR Layer of
my GPT partition.
Just for the sake of clarity, and at the risk of pedantry and
obtuseness, let me demonstrate the old vs new scheme.
OLD = one bootloader --- OS
NEW = Boot Manager bootloader1, bootloader2bootloader128
---OS(1),OS(2).OS(n)
To get LFS-7.4 to boot just once I need
Boot Manager---grub(ubuntu) or grub(LFS-7.4) LFS-7.4
For the Boot Manager to see the different bootloaders, the bootloaders
reside on the EFI partition. On my setup this is /dev/sda2/ or in
current grub-speak (hd0,gpt2). My LFS partition is /dev/sda6 or (hd0,gpt6).
The grub images, named grub.efi, reside in /dev/sda2/EFI/{ubuntu,LFS-7.4}
That's the preface for my responses to Bruce's questions. I have a few
more of my own.
On 11/08/2013 07:48 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
snipped some great analysis of grub.cfg lines GRUB modules. They can be
here or global (my preference).
Mine too with the addition of as few as is needed. In this case, since
I've copied what works, I have shot gunned the approach and more
than likely have loaded more modules than I actually need.
set root='hd0,gpt6'
Where to search for grub.cfg, kernel, and initrd.
I can parrot your statement and I think it's precisely the issue that
causes me not even to be able to load grub. If grub.efi exists on
/dev/sda2/EFI/LFS-7.4 how do I get grub to look at /dev/sda6/boot/ for
vmlinuz and /grub/grub.cfg? I need to keep it this way so that if my
Boot Manager goes to ubuntu's version of grub.cfg I can boot LFS-7.4
from that grub menu. I'm not familiar enough with manipulating the Boot
Manager yet and want to keep this option open. I'll snip the part about
ubuntu's grub.cfg, it has two, one in EFI/ubuntu and one in /boot/grub,
and include it here.
search.fs_uuid 0ef1c9a3-59ad-4637-be37-72ebcc07d660 root hd0,gpt10
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
Bruce indicated that the search stuff was for times when the hard
drive got re-partitioned. My goal is to get this to work only once right
now, so I think that to get grub.efi to look into my LFS partition to
see the real grub.cfg there I can change the first line to
set root=hd0,gpt6
Does not grub also have to know where its modules are? If it does need
to know, does it look in /boot/grub by default or does it know somehow
that, on my setup, they are in /usr/lib/grub/x86_64-efi/ ?
snipped more good analysis
echo'Loading Linux 3.10.10-lfs-7.4 ...'
linux /boot/vmlinuz-3.10.10-lfs-7.4 root=/dev/sda6 ro
Looks right.
And just to make sure--this is right *after* grub knows to look in
(hd0,gpt6)? Right? Does root here refer to grub or the mount point for
the kernel?
That long UUID stands for /dev/sda6 or hd0,gpt6 and is my LFS
partition. All of a sudden it occurred to me that 'root' is the place
where GRUB2 looks for its files and since they're not on /dev/sda6 it's
looking in the wrong place.
Where are they?
I hope I have cleared that up.
snipped the rest of the message because it's beryond the focus of what I
want to do right now
menuentry 'LFS-7.4' {
insmod part_gpt
insmod ext2
(hd0,gpt6)/linux /boot/vmlinuz-3.10.10-lfs-7.4 root=/dev/sda6 ro
}
Which is pretty close to what's in the book.
Occcam's razor again, Bruce. The simplest solution is, invariably, the
best I must confess though that I am, right now, limited by my
ignorance and frustrated that I'm having trouble resolving it.
The next thing I want to resolve is generation of the grub-image. As a
guide, I'm using an article that I've referenced in other messages, to
get this uefi stuff to work. ( In it the author would have one work in
the grub-core directory of the compiled source. In this article, which
is ubuntu based, the author does not install the grub binaries and
modules as we do in LFS. Maybe he's assuming that these already exist on
the system. But that doesn't seem logical when he goes to the compiled
source directories. Oh well.) I mention that because I've been doing
things manually and have not used grub-install. I've sifted through
that script quite a few times in the last few days and have run
grub-install --help I don't know how many times. I'm absolutely
paranoid that grub will write
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On 11/08/2013 08:40 PM, Ken Moffat wrote: On Sat, Nov 09, 2013 at 02:35:35AM +, Ken Moffat wrote: [ snip EFI / grub.cfg details, I'm going to query your reasoning ] I see Bruce has replied while I was composing this. Definitely try his suggestions first (he understands those horrid gpt partitions and the even more horrid [1] grub ;-) Only come back to my painful suggestions if you have to. ĸen 1. ALL bootloaders are horrid, it's in their nature. I wanted to respond directly to you, Ken, because your original was so detailed and obviously took a long time. Thanks for that. I'm keeping your suggestions for the if all else fails part of my work. In what I have observed, the Boot Manager is trying to hand off to a boot loader. I get a really, really quick screen that has two very, very short lines--that's all I can distinguish--before it moves almost instantaneously to the Ubuntu grub screen. That's why I think it's not a kernel problemyet. Although your steps may be quite painful, they may be necessary. Is that called regression testing? I've done a little of that myself recently and regressed to the oral expulsive stage of my personality development in which my hp-envy almost became hp-sattelite when I wanted to make the hp-efi into hp-ufo. And to refer to Bruce's analysis of what you wrote I wonder if things are horrid because they become simply complicated; e.g. kernel configuration from scratch. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On 11/09/2013 10:49 AM, Bruce Dubbs wrote: Dan McGhee wrote: I know I'm top-posting and ask for forgiveness. Please consider this a preface to my responses to what Bruce offered. And thanks, Bruce, for your thoughts. I am frustrated by not being able to find documentation about what the grub modules do--and now for many of the variables grub uses. A simple this does that would suffice. Does this help? http://www.gnu.org/software/grub/manual/grub.html -- Bruce Thanks, Bruce, but no. It's the same one I have. For example, Section 3.4 might lead someone to believe that the discussion tells how to install GRUB in a UEFI environment since it talks about using GPT. I know it's under BIOS installation. I think it's a little misleading. GRUB2, as I have learned in the last week-and-a-half, has much more capability than what is documented in that manual. As another example in the section about how grub names things, there's not discussion of designating devices as in (hd0,3) as (hd0,gpt3). Once again, I'm not ranting or blaming. I know that developers develop and don't have the time or want to write. Additionally, the changes, which are starting to be limiting, in UEFI firmware and structure are happening rapidly. Also, I'm not saying that the manual is not helpful. It just doesn't go far enough for me. An example of this is, as I was just perusing it to get ready to answer you, I found a couple of paragraphs about the embedded config file in the image and the need to search for a UUID to get to root. That bears further examination for me a little later. I appreciate your efforts on my behalf. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Configuring GRUB2--Request for a Logic Check
On 11/09/2013 11:57 AM, Ken Moffat wrote: On Sat, Nov 09, 2013 at 10:42:14AM -0600, Dan McGhee wrote: I wanted to respond directly to you, Ken, because your original was so detailed and obviously took a long time. Thanks for that. I'm keeping your suggestions for the if all else fails part of my work. In what I have observed, the Boot Manager is trying to hand off to a boot loader. I get a really, really quick screen that has two very, very short lines--that's all I can distinguish--before it moves almost instantaneously to the Ubuntu grub screen. That's why I think it's not a kernel problemyet. Understood. I've no idea what happens on efi. So I looked for something detailed and useful about grub efi booting on intel _mac_. It has been painful, but I can discuss it now and can generate options on how to go. Ubuntu's best effort seems to be the *old* page at https://help.ubuntu.com/community/UEFIBooting (the newer page it links to says the old one might be better for macs). That points to a major source of the kernel problems (a mix of EFI 1.x and UEFI 2.x). Arch goes into some detail at https://wiki.archlinux.org/index.php/GRUB#UEFI_systems_2 but I get the impression they do things very differently from ubuntu. There is a page at http://www.rodsbooks.com/efi-bootloaders/grub2.html which talks in general terms - possibly targetted at windows users, I'm not sure if it will tell you anything you haven't already discovered. The links in what is on rodsbooks, got me to the ubuntu one. I'm using both references to do my work. But, and this is where I owe you a real debt of gratitude, I took a closer look at the archlinux article. For some reason, I went blowing past it when I found it originally. Maybe at that time I didn't even know enough to recognize what I was reading. After looking at it just now, I think it's exactly what I need. For one thing it resolved my paranoia about where grub would write. I couldn't quite nuke out what 'grub-install' actually did by reading the script. That page addresses that. Therefore, if I'm missing anything in my manual work, I won't miss it now because I'm gonna use grub-install. That paranoia led me to my desire to know more about the guts of grub. But I also understand, If it ain't broke, don't fix it. If grub-install works and I don't understand why, I don't care. The rest of it is just configuring and getting grub to look in the right places. The gentoo links that google found all seemed to be untested. A mageia link noted that EFI is very flexible so every vendor (I think the writer means every distro) does things differently. (Reminds me of VSAM - a flexible and powerful tool, really easy for the unwary to screw things up). Yes, the different distro sites seem to be rather silent on this stuff. And you found something that I was hesitant to mention. This stuff does depend a lot on vendors. Many have written their own Boot Managers and I've found many comments and articles on how buggy and unreliable many are. As of a year ago, HP was one of those that had lots of complaints. That may be something else I need to research. rEFInd and gummiboot, look out I may be headed your way. I don't mind not doing things the way ubuntu does. Since I started using it as a host system five or six years ago, it has more rapidly approached behavior that is quite similar to that other OS that has almost a stranglehold on the market. In fact, Ubuntu caved in and is paying the fine to use secure boot. As I've said, I'd like to accomplish two things: 1) get LFS-7.4 to boot in a UEFI environment, and 2) do it in a way that will be useful to LFS. Thank you very much, Ken, for your efforts. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Configuring GRUB2--Request for a Logic Check
I have everything in place to boot LFS in EFI-mode. The problem is that
something is failing and the messages go by so fast that I can't see
what it is. Just like I have it set up, the laptop boots to Ubuntu if
the LFS boot failed. My problem is that I'm stymied in my troubleshooting.
I've reasoned that the problem is probably in my grub.cfg.
The grub image--grub.efi--, grub.cfg and all the grub modules reside in
my EFI partition--/dev/sda2. I cheated and used grub-mkconfig to
generate grub.cfg, and this is the entry for LFS
menuentry 'LFS-7.4' --class gnu-linux --class gnu --class os
$menuentry_id_optio
n 'gnulinux-simple-d52e1640-9ac4-4c5d-aad1-9c79ff1f0bbd' {
load_video
insmod gzio
insmod part_gpt
insmod ext2
set root='hd0,gpt6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt6
--hint-efi=hd0,gpt6 --hint-baremetal=ahci0,gpt6
d52e1640-9ac4-4c5d-aad1-9c79ff1f0bbd
else
search --no-floppy --fs-uuid --set=root
d52e1640-9ac4-4c5d-aad1-9c79ff1f0bbd
fi
echo'Loading Linux 3.10.10-lfs-7.4 ...'
linux /boot/vmlinuz-3.10.10-lfs-7.4 root=/dev/sda6 ro
}
That long UUID stands for /dev/sda6 or hd0,gpt6 and is my LFS
partition. All of a sudden it occurred to me that 'root' is the place
where GRUB2 looks for its files and since they're not on /dev/sda6 it's
looking in the wrong place. My logic check consists of this question.
Should I change every reference to gpt6 to gpt2 (this is sda2)? If
that's the case then I'm confused on the 'linux' line. Should that
remain the same or does it need to say:
linux (hd0,gpt6)/boot/vmlinuz-3.10*7.4 root=/dev/sda2 ro
I think I could put /dev/sda6 in the path to the image.
I'm trying to do this like Fedora does and put all the grub stuff on the
EFI partition. I don't know if Fedora puts the kernel image there or not.
I could also do it like Ubuntu does, which is a little closer to the way
LFS does it. In Ubuntu there is /boot/grub which contains the grub.cfg
and the directory x86_64-efi that holds all the modules. But in this
case there's a grub.cfg that exists on the EFI partition with the grub
image. It's contents are:
search.fs_uuid 0ef1c9a3-59ad-4637-be37-72ebcc07d660 root hd0,gpt10
set prefix=($root)/boot/grub
configfile $prefix/grub.cfg
That UUID is for /dev/sda10, or (hd0,gpt10). In this case the grub.cfg
that holds the commands for booting is in the place we're used to and
there would be no changes to the generated grub.cfg.
Since I want to share all of this with the LFS world, I'd like to get
both methods to boot, so I'd still be grateful for thoughts on my LFS
menuentry and the root stuff.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Configuring and Installing GRUB for {,U}EFI
On 11/06/2013 09:15 PM, Bruce Dubbs wrote: Dan McGhee wrote: On 10/28/2013 10:55 AM, Bruce Dubbs wrote: Dan McGhee wrote: When all this is successful, I could write the procedure up and post it. Then, if anyone wanted to, it could be put in the book somewhere. I could also write a hint if that were more practical. For now, just let us know your results. -- Bruce So far my results are just learning. I really haven't done anything yet, but some people may be interested in what I have found to date. This is long. Booting Linux in general, or LFS specifically *can be* as straightforward as it always has been. But if someone wants to make use of their UEFI--formerly EFI--firmware, then it is not so straightforward and can be down right complex. The first thing to note, in the current milieu, is that if you want to use *secure boot*--which is an add-on to and not synonymous with UEFI--you can install GRUB like you always have, but you will never see it boot anything because, if you're doing it in a pre-UEFI fashion, it's irrelevant to secure boot and won't be seen. Secure boot is an option in Linux right now if and only if you are using Ubuntu12.10, Fedora, OpenSuse--I don't know the version numbers--or if you have paid Microsoft $95 to let you write a key that you can use with your firmware and then figure out how to write a file that will check with the firmware to make sure all is OK and then check with the bootloader to make sure it's not vicious or malicious. (Sorry for the sarcasm). All of this means that you must turn off secure boot in your firmware setup. So far the only thing we have done in our preparation to boot LFS is turn off secure boot. Onward! The next option is to turn turn on legacy mode or CMS in the firmware. This is vendor specific so there are probably a number of things this is called. It just means going back to the way things used to be.--a bootloader in the first sector of the disk. In days of yore this was the way all computers shipped. We are all familiar with it--one bootloader, chain-linking and four primary partitions. Except if you have a GPT partition table. To insure backwards compatibility GPT partition tables now have an area at the beginning of the disk called the Protective MBR Layer. This is the place where GRUB would go on a GPT disk. This is also the place at which things start to muddy a bit. BIOS based firmware could handle only one bootloader, because it was limited to one physical spot on a fixed disk. UEFI overcomes that by using a Boot Manager to select the boot loader, and there can be, theoretically, any number of boot loaders, because these loaders now reside in a partition and not an actual physical spot on the disk. The following is the snipped results of my running parted -l /dev/sda Number Start End Size File system Name Flags 1 1049kB 420MB 419MB ntfs Basic data partition hidden, diag 2 420MB 693MB 273MB fat32 EFI system partition boot If someone has this partition, chances are they've been booting in EFI Mode. What I've read so far is that the EFI partition is usually the first partition of the disk, but it's not on mine. Another vendor thing I think. This partition contains two directories: boot and EFI. I've discovered that it's standard in Linux to mount it at /boot/efi--that's the way it is in my Ubuntu system and it's listed in /etc/fstab. Here are the results of ls /boot/efi/EFI using Ubuntu on my HP-Envy: Boot HP Microsoft ubuntu I've put this in here because the Boot Manager--whether written by HP or Microsoft I don't know--reads this directory and gives, as choices, the names of the directories--Boot comes across as Recovery for an option. You can access the Boot Manager by interrupting the boot process. On my machine it's done by holding the ESC key during boot and then selecting what I want. This is what I had to do to get to Ubuntu after I first installed it. The problem is in getting the Boot Manager to have a different default selection other than Microsoft. The solution to that is not trivial and I don't want to write about it until I study the process some more and, possibly, try it. But at this point let me show you the magic. Since version 3.3, the Linux kernel has had efi hooks. So--and I think it's this simple--you could create a directory in /boot/efi/EFi--let's call it LFS-7.4--and put the kernel in it. Then LFS-7.4 would appear as option in the EFI Boot Manager, you select it and Holy shiny boots, Batman, there's my new LFS system and I didn't even use GRUB! What I've tried to do is describe the easy ways to boot LFS now. If you want the computer to default to Grub2 with all the selections on it, then there's more. I've found two interesting articles on the nuts and bolts of all of this. Managing EFI Bootloaders for Linux http://www.rodsbooks.com/efi-bootloaders/installation.html gives a lot of good detail about EFI, elilo, Grub2
Re: [lfs-support] Configuring and Installing GRUB for {,U}EFI
On 11/07/2013 11:10 AM, Bruce Dubbs wrote: Dan McGhee wrote: But, as an intermediate step, I could set up to boot this way. Currently, I have some technical questions about GRUB2 build options and grub-install options. I hesitate to experiment because I want to be able to boot my computer. It's easy to back-up Ubuntu and LFS, but that other bloated, leaky operating system is the problem. I don't even have a copy of that any more. -- Bruce I would love to be in that position, but until Apple writes a Linux version of iTunes, I'm stuck. I know, I know I could use iCloud for my phone and iPad, but I'm to cheap, er frugal, to buy more space. :) Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] GRUB2 Nuts and Bolts
This is not a rant or finger pointing session, I have a statement and
some questions about GRUB2 options both in building it and installing it.
I have found no real useful information describing how to configure
GRUB2 or in using grub-install. Anything I've been able to try or
further research comes from ./configure --help, grub-install --help
and grub-mkimage --help. I've also opened grub-install and read it to
find out some of what I want to know. The currently available GRUB
Manual goes only so far as grub-2.00-rc-1 and was written in Jun 2012.
I don't know how many rc's there were, but I know that there's more
capability in GRUB2 now than the manual covers.
Before I start into the specifics of my discoveries and questions, I
want to say that I have not found any, useful or not, descriptions of
the grub modules. Oh, I know that many are self-explanatory by their
name, like chainload, but what does efiemu do? Either I haven't
researched enough or there's nothing. If anyone knows a place where
this information exists, I would love to hear about it.
Configuring GRUB2 for an efi install means varying from the Book.
Using This document https://help.ubuntu.com/community/UEFIBooting I
learned about the option --with-platform= and the only thing that
./configure --help indicated was
--with-platform=PLATFORM
select the host platform [[guessed]]
and I didn't know whether or not this was something that I should know
because I use Linux or whether it was something specific to the GRUB2
build. Anyway, the referenced article had this command for configuring
GRUB2 for a 64-bit {,U}EFI build.
export EFI_ARCH=x86_64
./configure --with-platform=efi --target=${EFI_ARCH} --program-prefix=
Now, to backtrack a little, when I built GRUB2 during my LFS-7.4 build,
I used the configure options just as stated in the book. The message I
got at the end of configuring included the statement Platform: i386
and the installed directory in /usr/lib/grub was i386-pc.
I can't remember where I read this in my research, but something to the
effect that if grub installed its files as *-pc then it would have led
to a GRUB2 situation of writing to the MSDOS MBR of a non-GPT disk or
the MBR Protected Layer of a GPT disk. I didn't want that.
So, I did a DESTDIR install of GRUB2, with the same configure options
of the book with the addition of --with-platform=efi Then the
configure message said, Platform: x86_64-efi and efiemu runtime: No
(not available on efi. And the directory in /usr/lib/grub was
x86_64-efi. I think this is significant to those who want to ultimately
get grub on the EFI partition.
I found it also interesting that efiemu was not available. Since I
couldn't find any description of that module, I have concluded that it
does something when grub is read from the MBR Protected Layer of a GPT
disk. I really don't know, though.
Now it comes to actually installing the grub files somewhere. I know
that grub-install utilizes grub-mkimage and grub-setup to
accomplish its task. I know what grub-mkimage does, but I don't know
exactly what grub-setup does. Does it just look at a disk to see
what's there? Or does it look to see what device a particular path
refers to?
I can try to use grub-install for all of this or I can do it manually as
in the article. This is the point at which the options for grub-install
become important. And this statement from grub-install --help has me
concerned.
grub-install copies GRUB images into /boot/grub, and uses grub-setup
to install grub into the boot sector.
I don't want to install grub to the boot sector because there is none on
my disk. Just the EFI partition. And I just discovered that grub-setup
doesn't exist on my LFS build now. I'm wondering if that didn't happen
because of the configure option --with-platform=efi. Based on this
info, I'm thinking of using
$ grub-install --bootloader-id=GRUB2-LFS-7.4 --efi-directory=$my EFI
partition mount point
The manual install involves this command:
cd grub2_compiled_source_dir/grub-core
../grub-mkimage -O ${EFI_ARCH}-efi -d . -o grub.efi -p part_gpt part_msdos
ntfs ntfscomp hfsplus fat ext2
normal chain boot configfile linux multiboot
Obviously the author didn't install the compiled grub binaries so I
would be working as root in some directory and using those binaries.
${EFI_ARCH} for me is x86_64. What I don't know is why those particular
modules and should there be any more or any less. Anybody?
This is much, much longer than I intended it to be, but I think the
detail was necessary so others can understand my questions, what I'm
trying to do and how I'm trying to accomplish my goal.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Configuring and Installing GRUB for {,U}EFI
On 10/28/2013 10:55 AM, Bruce Dubbs wrote: Dan McGhee wrote: When all this is successful, I could write the procedure up and post it. Then, if anyone wanted to, it could be put in the book somewhere. I could also write a hint if that were more practical. For now, just let us know your results. -- Bruce So far my results are just learning. I really haven't done anything yet, but some people may be interested in what I have found to date. This is long. Booting Linux in general, or LFS specifically *can be* as straightforward as it always has been. But if someone wants to make use of their UEFI--formerly EFI--firmware, then it is not so straightforward and can be down right complex. The first thing to note, in the current milieu, is that if you want to use *secure boot*--which is an add-on to and not synonymous with UEFI--you can install GRUB like you always have, but you will never see it boot anything because, if you're doing it in a pre-UEFI fashion, it's irrelevant to secure boot and won't be seen. Secure boot is an option in Linux right now if and only if you are using Ubuntu12.10, Fedora, OpenSuse--I don't know the version numbers--or if you have paid Microsoft $95 to let you write a key that you can use with your firmware and then figure out how to write a file that will check with the firmware to make sure all is OK and then check with the bootloader to make sure it's not vicious or malicious. (Sorry for the sarcasm). All of this means that you must turn off secure boot in your firmware setup. So far the only thing we have done in our preparation to boot LFS is turn off secure boot. Onward! The next option is to turn turn on legacy mode or CMS in the firmware. This is vendor specific so there are probably a number of things this is called. It just means going back to the way things used to be.--a bootloader in the first sector of the disk. In days of yore this was the way all computers shipped. We are all familiar with it--one bootloader, chain-linking and four primary partitions. Except if you have a GPT partition table. To insure backwards compatibility GPT partition tables now have an area at the beginning of the disk called the Protective MBR Layer. This is the place where GRUB would go on a GPT disk. This is also the place at which things start to muddy a bit. BIOS based firmware could handle only one bootloader, because it was limited to one physical spot on a fixed disk. UEFI overcomes that by using a Boot Manager to select the boot loader, and there can be, theoretically, any number of boot loaders, because these loaders now reside in a partition and not an actual physical spot on the disk. The following is the snipped results of my running parted -l /dev/sda Number Start End Size File system Name Flags 1 1049kB 420MB 419MB ntfs Basic data partition hidden, diag 2 420MB 693MB 273MB fat32 EFI system partition boot If someone has this partition, chances are they've been booting in EFI Mode. What I've read so far is that the EFI partition is usually the first partition of the disk, but it's not on mine. Another vendor thing I think. This partition contains two directories: boot and EFI. I've discovered that it's standard in Linux to mount it at /boot/efi--that's the way it is in my Ubuntu system and it's listed in /etc/fstab. Here are the results of ls /boot/efi/EFI using Ubuntu on my HP-Envy: Boot HP Microsoft ubuntu I've put this in here because the Boot Manager--whether written by HP or Microsoft I don't know--reads this directory and gives, as choices, the names of the directories--Boot comes across as Recovery for an option. You can access the Boot Manager by interrupting the boot process. On my machine it's done by holding the ESC key during boot and then selecting what I want. This is what I had to do to get to Ubuntu after I first installed it. The problem is in getting the Boot Manager to have a different default selection other than Microsoft. The solution to that is not trivial and I don't want to write about it until I study the process some more and, possibly, try it. But at this point let me show you the magic. Since version 3.3, the Linux kernel has had efi hooks. So--and I think it's this simple--you could create a directory in /boot/efi/EFi--let's call it LFS-7.4--and put the kernel in it. Then LFS-7.4 would appear as option in the EFI Boot Manager, you select it and Holy shiny boots, Batman, there's my new LFS system and I didn't even use GRUB! What I've tried to do is describe the easy ways to boot LFS now. If you want the computer to default to Grub2 with all the selections on it, then there's more. I've found two interesting articles on the nuts and bolts of all of this. Managing EFI Bootloaders for Linux http://www.rodsbooks.com/efi-bootloaders/installation.html gives a lot of good detail about EFI, elilo, Grub2 and the kernel. That document links to UEFI Booting https://help.ubuntu.com
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
On 11/03/2013 11:14 AM, Bruce Dubbs wrote: If the bootscripts are exiting, then it's no wonder that my efforts are failing. I consider this one of the simple things that I miss. My knowledge of the bootscripts is slowly coming back. I knew them well six years ago. :) The bootscripts were completely rewritten for LFS 7.0. That's why we are at 7.x and not 6.x. I had noticed some big differences from what I was used to. My last complete LFS build was 6.7. I was going to ask later, but you just let me know. Thanks. Before I forget. Once I get the directory thing straightened out, should I, as root, touch /run/var/bootlog? That wouldn't be needed if /ver/run has been created, but I don't understand running the bootscripts in chroot. Why are you trying to do that? -- Bruce The original situation got lost in the responses to a passing comment I made when I originally posted. The comment was that 'ifup' complained that /run/var/bootlog didn't exist. I want to build up through Xorg in chroot. I've done it before, but I used the host system to down load packages and patches and read the book. I thought that if I could get my wifi working in chroot then I could do what I wanted to and could download packages directly to the LFS tree without having to go through the host system to do that. Just an idea to make it easier for me. I posted in LFS because I didn't know if this was possible in chroot and knew that someone would tell me if it weren't. The problem I'm having is a BLFS one in that I've not configured either dhcpcd or wpa_supplicant correctly. I'm learning that it might be an Ubuntu phenomenon. Short version with no more info is that my card wlan0 authenticates and, then, immediately de-authenticates. I'm still trying to troubleshoot and learn. But.with the info about the bootscripts, I got rid of the error messages in chroot. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
I'm still on the trail of getting my wireless up in chroot. I have all the ifconfig files I need, and, except for the static stuff in Ch. 7 of the book, they are cut and paste from BLFS. This time in chroot, after I had turned off my card in the host system I used /etc/rc.d/init.d/network start for my command. The third set of screen output was: Starting wpa_supplicant on the wlan0 interface.../lib/lsb/init-functions: line 664: /run/var/bootlog: No such file or directory Could not set interface wlan0 flags (UP): Operation not possible due to RF-kill * [ OK ] (Received complaints about /run/var/bootlog all through the process. They were right, it doesn't exist yet.) The last line of screen output was: /lib/lsb/init-functions: line 586: /run/var/bootlog: No such file or directory RTNETLINK answers: Operation not possible due to RF-kill I don't know how, when or where the RF-kill generates, but based on the fact that it's a kernel message, I'm wondering if it didn't originate somewhere in the wpa_supplicant process because dmesg gave me the following when I checked it after I couldn't ping anything. [ 3547.476338] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 3554.073619] wlan0: authenticate with c4:3d:c7:70:07:e7 [ 3554.088957] wlan0: send auth to c4:3d:c7:70:07:e7 (try 1/3) [ 3554.090954] wlan0: authenticated [ 3554.092919] wlan0: associate with c4:3d:c7:70:07:e7 (try 1/3) [ 3554.096066] wlan0: RX AssocResp from c4:3d:c7:70:07:e7 (capab=0x411 status=0 aid=2) [ 3554.096156] wlan0: associated [ 3554.096256] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 4217.269801] wlan0: deauthenticating from c4:3d:c7:70:07:e7 by local choice (reason=3) Compare that output with this output when I awoke my laptop from sleep a little later. [ 4246.722109] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 4248.988116] wlan0: authenticate with c4:3d:c7:70:07:e7 [ 4249.003441] wlan0: send auth to c4:3d:c7:70:07:e7 (try 1/3) [ 4249.004987] wlan0: authenticated [ 4249.007303] wlan0: associate with c4:3d:c7:70:07:e7 (try 1/3) [ 4249.010487] wlan0: RX AssocResp from c4:3d:c7:70:07:e7 (capab=0x411 status=0 aid=2) [ 4249.010571] wlan0: associated (I accidently cut off the last line which stated that wlan0 link was ready.) They are both identical except for that last line in the first set. If I am correct, the authenticate/deauthenticate stuff comes from wpa_supplicant. I'm not sure what is happening. I checked after the failed attempt and all the right drivers were loaded. I think wpa_supplicant has everything it needs based on the config file and the arguments in its service script. The only other thing I can think of right now is d-bus. Because I ultimately want to run wpa_supplicant with Network Manager, I installed d-bus and built and configured wpa_supplicant with d-bus support. My question is, then, do I need to start the d-bus daemon as a result? Is wpa_supplicant not talking to whom it needs to speak. I've not used d-bus or wpa_supplicant on such an intimate level. I Ubuntu it just happens. The last current question I have is, in the service script for wpa_supplicant, it is called with the -q option for little debugging operation. If I add -d, for more debug info, in the ifconfig.wifi0 file under WPA_ARGS=, will that over ride the behavior of the service script? In the meantime, I'm trying to learn how to use wpa_cli so that I might get a better handle on what's happening. Obviously, I'm focusing on wpa_supplicant right now. Does anyone see another or different alternative to where the problem might be? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Using wpa_supplicant [Was: ifup--a really uninformed question]
On 11/02/2013 02:50 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
(Received complaints about /run/var/bootlog all through the process.
They were right, it doesn't exist yet.)
Do you have /run/var?
I just discovered. No I don't. Nor do I have /run/lock. I looked in the
book Sections 6.5 and 6.6 to see where and how I missed these. I didn't
see their creation in either section. Would you please tell me where in
the book they get created? I've got to see if I missed anything else.
When I create them, just to double check, make sure the permissions are
0755?
/run is mounted form fstab
tmpfs/run tmpfs defaults 0 0
in the very first boot boot script (mountvirtfs):
# Make sure /run/var is available before logging any messages
if ! mountpoint /run /dev/null; then
mount /run || failed=1
fi
mkdir -p /run/var /run/lock /run/shm
...
The scripts all use so the only reason that you would get this error
is iv /run is not mounted. Actually, even then the writing would be to
a standard directory so the issue would be permissions. These scripts
need to be run as root.
That's great info. Thanks. Referencing the paragraph above, the
directories /run/{var,lock} get created the first time the system boots?
I do have /run/shm. It got created in Section 6.2.
Since I'm operating in chroot, I need to mount /run. Again, to double
check, is the following command the one to use?
mount -v -t tmpfs tmpfs /run
If the bootscripts are exiting, then it's no wonder that my efforts are
failing. I consider this one of the simple things that I miss. My
knowledge of the bootscripts is slowly coming back. I knew them well six
years ago. :)
Before I forget. Once I get the directory thing straightened out, should
I, as root, touch /run/var/bootlog?
Thanks, Bruce,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] ifup--a really uninformed question
It has been so very, very long since I have worked with the
bootscripts. I have just forgotten. Please pardon this really basic
question.
If I want to bring up my wireless card, will ifup wifi0 work
backwards, using the service scripts in /etc/sysconfig, or do I need to
run 'ifup' twice? ifup wlan0 ifup wifi0
I have all the correct files installed for wpa_supplicant and dhcpcd and
wlan0. I reviewed 'ifup' and the only variable it works with is ${1},
and in this case it was wifi0. I got the messages that dhcpcd and
wpa_supplicant had started on wlan0, but when I tried to ping my router
I got the message NETWORK NOT AVAILABLE.
I probably needed to say that I'm doing this from chroot environment. I
disconnected from my router and turned off the card in Ubuntu. Then I
ran the 'ifup' command in chroot. In 'dmesg' I saw that the kernel was
trying to associate, but there was no message that wlan0 was ready. I'm
thinking that I didn't trigger the udevd event that I thought I would.
I thought that in one of my previous LFS builds, I had used my network
in the chroot environment. I remember using wget and lynx from a
terminal, but I just can't remember if it was in chroot or after I
booted into the LFS system.
I know I'm missing something pretty simple, but I just can't dredge it up.
Thanks.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
So that I can hit the deck running after I get my new system to boot, I want to add a few packages, and their associated boot scripts, from BLFS. These are dhcpd, wpa-supplicant, libxml, libn, open-ssl and d-bus. I seem to remember reading somewhere, and I thought it was in the LFS book, that it was OK to do what I'm thinking of. I don't see anything that will hinder my plan, but I thought I'd ask here where many people know a lot more about this than I do. Anything to be careful of? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On 10/31/2013 03:02 PM, Ken Moffat wrote: There used to be some packages that gave problems if building in chroot. But I don't remember what they were. In the last couple of years I've done some complete builds in chroot while I sorted out changes to my build scripts, so I don't think you'll have any problems. You might want to add a text browser so that you can read the BLFS book. ĸen Thanks, Ken. My memory and experience say the same thing, I just wanted to check just in case some where deep in LFS things had changed. The first thing I usually do in BLFS is get a text browser. I just wanted things to be ready, so I can check them out with ping and iproute, before I start building. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Some BLFS Packages Before Making LFS-7.4 Bootable
On 10/31/2013 03:51 PM, Bruce Dubbs wrote: Dan McGhee wrote: So that I can hit the deck running after I get my new system to boot, I want to add a few packages, and their associated boot scripts, from BLFS. These are dhcpd, wpa-supplicant, libxml, libn, open-ssl and d-bus. I seem to remember reading somewhere, and I thought it was in the LFS book, that it was OK to do what I'm thinking of. I don't see anything that will hinder my plan, but I thought I'd ask here where many people know a lot more about this than I do. Anything to be careful of? For the most part, you are OK as long as you maintain the virtual file systems that are mounted in Chapter 6. I usually build over ssh so I make sure that openssl and openssh are in place. Other things I build early are lsb-release (for my scripts), sudo, which, and wget. I also have my sources in /usr/src and that is a separate partition so I can use it from any build. I recommend the following as separate partitions: /boot, /home, and /usr/src. /opt is also a possibility. -- Bruce I have a script that gets me to chroot and it mounts those each time I go in. I forgot about wget, thanks for reminding me. A separate partition for /usr/src? Never occurred to me, but it's a good idea. Thanks, Bruce. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] EFI, UEFI and LFS--Complicated, Confusing or Can of Worms
As a continuation of the quest I started the other day with learning about GRUB configuration and my system, I have encountered some *interesting* information that could, as an extension of logic, have an impact on building LFS. In trying to discern whether my new HP Envy has UEFI firmware, I've done some extensive reading in the last couple of days. The first thing of which I became aware is that many terms in use these days; e.g., BIOS System, are uses that aren't quite specific to the actual situation. More precisely, in terms of booting, the question is, Does the BIOS use an MBR partition or EFI partition to boot? I have learned that in even UEFI firmware there is an MBR protected area at the beginning of the hard drive. This is for backward compatibility. I have also learned that GRUB can work in old, hybrid, or new firmware environments. This all depends on where GRUB puts its stage 2 files. Of course, when GRUB is configured for efi, there are no stage 2 files. The indicators that the firmware is UEFI and that an *actual* GPT partition is in use are that there exist an EFI partition with a FAT32 file system and that the number of primary partitions is not limited to four. If a person has Windows installed, one can go to disk management and look at the volumes. If one is, EFI, healthy then there is an actual, not hybrid, GPT partition. If there is no such animal and the partition table show only C:\ which is healthy and has the boot flag set, it is an MBR partition. I have also learned that the kernel must be configured with the efi options turned on. I can't remember their specific names right now, but I'll note and report when I configure my kernel shortly. Those are all the complicated or confusing things. Now to the possible can of worms. It's the signing of kernels and boot loaders. At the start, I must say that the way around this is to turn off secure boot in the BIOS setup. But, then, some folks may not want to do this. If so, they may have to deal with this signing stuff. Right now, and I repeat, right now; i.e., currently, GRUB can be used as a bootloader in a secure environment, if and only if, there is a signed key. Only Ubuntu and Fedora have those. There is a way to generate personal keys, but I haven't learned that yet. I'm just hoping that this stuff doesn't progress to the point at which we, LFS builders, will need them. The war has already started. Microsoft can revoke any firmware certificate it wants without notice. It does this through Windows Update. I don't know how far this will go, but I'm distressed about it. As long as I don't have to proceed with secure boot, I'm happy. Anyway, I just wanted to share what I have discovered. This may lead to posts like, I did this and it didn't work. The book needs to be changed. The implementation of LFS, configuring and installing both the kernel and GRUB can be successful regardless of how the BIOS boots. There is a learning curve though. And some of GRUB's building and installing arguments need to be a little different. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] EFI, UEFI and LFS--Complicated, Confusing or Can of Worms
On 10/30/2013 11:26 AM, Casey Daniels wrote: On 10/30/2013 12:17 PM, Dan McGhee wrote: Anyway, I just wanted to share what I have discovered. This may lead to posts like, I did this and it didn't work. The book needs to be changed. The implementation of LFS, configuring and installing both the kernel and GRUB can be successful regardless of how the BIOS boots. There is a learning curve though. And some of GRUB's building and installing arguments need to be a little different. Dan I played with UEFI Boot for almost a week and couldn't get anywhere with it. I could get Grub Loaded, and and I could get grub to find the Kernel, but then it would ALWAYS fail at some memory point during the Kernel load, and I played and played with the kernel for that week and it keep freezing at the same point. The thing with UEFI Boot is you don't need Grub to boot if you don't want to. If you have a Linux only or Windows only, computer you can actually boot with out user input without a bootloader. From my understanding though if you have a dualboot system you need at a minimum a boot manager to boot without user intervention. If you don't mind typing a few commands you can boot with out a boot manager or bootloader in a dual boot system, you just have to understand the UEFI Shell you get. Casey Casey, your experience confirms what I have learned by reading and my own experience. Yes, on dual boot you need a manager to get to the loader you want. That's one of the functions of the EFI partition. I don't want to address your specific situation until I have practical experience with my LFS build and that won't be for a couple of more days. If you have not been successful in booting your LFS system and you want to play, I recommend turning off secure boot, checking your kernel configuration to support efi and running grub-install --help to select the arguments you use for grub. I just finished reading grub-install and it looks like it should detect your partition type--MBR or GPT. I don't want to suggest anything definite because I haven't proved them with my own experience. One of the possible outcomes is that your computer won't boot. I would rather be the victim of my own eperiments rather than having someone else be that victim. :) Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Configuring and Installing GRUB for {,U}EFI
GRUB is the next package in Ch. 6 that I will be building. I'm going to have to deviate from the book to do this since I have a GPT hard drive and want to maintain it as is. This means installing GRUB with EFI enabled. From looking at ./configure --help in the GRUB source tree, I think that this is the only change I need to do in the book's configure options; i.e., enable-efiemu. Is this correct or do I need any other options. That was my basic question and the purpose of this post. However, in thinking about GRUB, I thought forward to making the new system bootable. I have an HP ENVY m6 Sleekbook which came, obviously, with secure boot enabled and Windows 8. If at all possible, I'd like to make it work, on boot, as designed. This took me to grub-install. The options --bootloader-id, --efi-directory and --uefi-secure-boot got my attention. I know how to handle the --efi-directory. Using parted, I found it. I don't know how to use --bootloader-id or even if it's necessary. If it is necessary, how do I find the id of any bootoader. I know that my laptop now has three boot managers: HP, WINDOWS and GRUB. How do I find their numbers? (This may be semantics, but is GRUB a boot manager?) Now for --uefi-secure boot. The man page says that this option can be used only if the grub-efi-amd64-signed package is installed. I looked around for a package and it seems that it is only available at ubuntu or debian. I think that ubuntu (debian) is the only distro who has currently, as one person put it, paid the fine to microsoft and can use secure boot. If this is true, maybe this package is proprietary and I just can't download it. I can try to tear the .deb package apart to see if I can to anything with it. BTW. I currently have secure boot disabled. I don't need it. In fact, I think secure boot is *really* paranoid and is, more specifically, another cash cow for microsoft. But I rant. Please forgive. Anyway, GRUB is my current default boot loader. Ubuntu is supposed to work out of the box in the UEFI environment, but it was not true in my case. I had to get a package, at Ubuntu, called boot fix to get my boot process to the point at which I no longer needed to go into the boot manager menu at startup. The problem is that I couldn't (can't) find any log that tells me what this application did. But GRUB now is my default loader. This leads me to my final point and question. The warning in Section 8.4 says of grub-install, Do not run this command if not desired... Since my laptop boots into a GRUB menu, can I just copy the appropriate files to a directory on the efi boot partition? (I could do this from a terminal in ubuntu since I don't think that the chroot environment has the tools to translate ext4 to FAT32 yet.) And after copying, generate my grub config file. When all this is successful, I could write the procedure up and post it. Then, if anyone wanted to, it could be put in the book somewhere. I could also write a hint if that were more practical. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Glibc-2.18 Test Suite Failed
In fact, I don't think it conducted any tests. The commands I use in the glibc-build directory come right out of the book make -k check 21 | tee glibc-check-log grep Error glibc-check-log I do call them from a function defined in a build.conf file called check_commands, but that shouldn't make any difference--I think. Now that I think about it, the test suite didn't run for very long. Maybe 1/2-3/4 hr. I was doing something else. I was really surprised when I found the file I make from grepping glibc-check-log empty. Yup, no info. And the glibc-check-log looked like everything had happened normally with make[1-4] leaving directories until I was in the directory containing the source and build directories. I checked the error log I generate during the build and the following line appeared twelve times: make[2]: Circular /usr/src/glibc-2.18/glibc-build/linkobj/libc.so - /usr/src/glibc-2.18/glibc-build/linkobj/libc.so dependency dropped. Hopefully putting 2+2 together I googled on this and found: commit 5f855e3598a576c35e54623a13b256f3e87fcd4d Author: Brooks Moses bmo...@google.com Date: Thu Oct 3 10:38:14 2013 -0700 Fix erroneous (and circular) implied pattern rule for linkobj/libc.so. [BZ #15915] As described in the bug, the pattern rule for lib%.so files in Makerules includes linkobj/libc.so as a dependency. However, the explicit rule for linkobj/libc.so is in the top-level Makefile. Thus, the subdirectory makefiles that include Makerules end up with an erroneous makefile pattern rule for linkobj/libc.so that includes itself as a dependency. The result is make warnings whenever rules for other .so files are resolved -- and, on occasion, actual makefile failures when a race condition causes the implicit rule to actually be used. This patch moves the explicit rules for linkobj/libc.so into Makerules to clear up this problem. It also elaborates a couple of comments that I'd initially found confusing. at upstream-tracker.org/changelogs/glibc/current/changelog.html I don't know how to get this patch, nor do I even know if this is what caused the failure. Couldn't find anything on point in the support or dev archives. Any thoughts? How to get the patch? Am I barking up the wrong tree? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] No Pattern Matching Using $foo in Chroot Environment
On 10/18/2013 10:08 AM, Dan McGhee wrote:
I'm trying to run a script to build a package--I use the package users
hint--which has the following:
package=$(whoami) #In this case I'm man-pages-3.5.3
packagedir=/sources
archive=$packagedir/$package.tar.*
Later when I want to define a variable containing the name of the
directory into which tar will extract the archive, I have
pkgsrcdir=$(tar -tf $archive | grep / | head -n 1 | cut -d '/' -f 1)
The script bails out at this point complaining that there's no file or
directory by that name. Running sh -x script_name reveals archive =
(BTW sh reports that $packagedir and $package are properly defined.)
I have discovered that when I use {ls /sources/$(whoami) or $anything
that gives man-pages-3.5.3.tar*} as a package user, the return is
man-pages-3.5.3*: No such file or directory. /sources is world
readable and writable.
If, however, I issue ls /sources/man-pages* the return is
man-pages-3.5.3.tar.xz
The pattern matching is fine for root:
foo=man-pages-3.5.3
ls /sources/$foo.tar.*
gives the right answer.
I've never encountered this before. My hunch is that it's some
environment variable. I know that pattern matching involves globbing
and clobbering, but I don't know enough--and can't find the info--to
even experiment.
In the past, something like this usually leads to, I can't see the
forest because there are so many trees in the way. I don't know if I'm
really focusing on those trees or not.
In the meantime, I'm going to go through the bash man page. I will be
grateful for any pointers or suggestions.
Thanks,
Dan
Hopefully, I can be a little more secific about this now after reading
for while.
First, it appears that in the chroot environment and use of
$foo{*,.tar.[b,g,x,z][b,g,x,z][b,g,x,z]} in a command does not expand
the file name in the way I understand the use of * and []. Ex. ls
/sources/$foo* returns the no such file error, and ls /sources | grep
$foo returns nothing. ($foo=man-pages-3.5.3)
From the Bash Reference Manual I get:
Pattern Matching: After word splitting, unless the -f option has been
set (see The Set Builtin
http://www.gnu.org/software/bash/manual/bashref.html#The-Set-Builtin),
Bash scans each word for the characters '*', '?', and '['. If one of
these characters appears, then the word is regarded as a pattern, and
replaced with an alphabetically sorted list of file names matching the
pattern. (This is what does not happen using $foo*.)
Set Builtin: -f
Disable filename expansion (globbing). (The behavior is as if the -f
option was given, but I don't know how to determine if it was and, if
so, to reverse it.)
Shopt Builtin: extglob
If set, the extended pattern matching features described above (see
Pattern Matching) are enabled.
and: globstar
If set, the pattern '**' used in a filename expansion context will match
all files and zero or more directories and subdirectories. If the
pattern is followed by a '/', only directories and subdirectories match.
I then ran shopt -s extglob,globstar and echo $BASHOPTS gives:
cmdhist:expand_aliases:extglob:extquote:force_fignore:globstar:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath
I looks like I have everything I need to do filename expansion and
pattern matching is there, but the results are the same.
I haven't seen anything on how I can check on the behavior of $.
Once again, I can use pattern matching and expansion as long as I don't
use the value of a variable. ls /sources | grep man-pages-3.5.3 works
great as does ls /sources/man-pages*.
In my script I would like to call the archives and the patch files
knowing only the name of the package; i.e. $package name.tar.* and
$packagename*.patch. But until I can get this pattern matching thing
resolved, I'll need to manually enter these parameters in the script.
And that's not elegant. :)
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] No Pattern Matching Using $foo in Chroot Environment[SOLVED]
On 10/18/2013 01:38 PM, Bruce Dubbs wrote:
Dan McGhee wrote:
Hopefully, I can be a little more secific about this now after reading
for while.
First, it appears that in the chroot environment and use of
$foo{*,.tar.[b,g,x,z][b,g,x,z][b,g,x,z]} in a command does not expand
the file name in the way I understand the use of * and [].
Ex. ls /sources/$foo* returns the no such file error, and
ls /sources | grep $foo returns nothing. ($foo=man-pages-3.5.3)
Does $foo exist in the chroot environment?
On my system it's man-pages-3.54 so
# foo=man-pages-3.54
# ls /sources/$foo*
/sources/man-pages-3.54.tar.xz
works fine. Note that if you did specify '$foo=man-pages-3.5.3' then 1)
the syntax is wrong, and 2) the man pages file name is formatted with an
extra dot which will result in 'No such file or directory'.
-- Bruce
Yup, forests and trees again. Frustrating. The good news is that I
learned a lot more about bash this AM. Including the preferred way to
redirect standard output to standard input. word. Easier to remember
than 21.
Everything works fine now.
Thanks, Bruce
red-faced Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Grateful
I decided to write this since even in my old age I like receiving
feedback that my efforts are not in vain.
Hats off to you {,B}LFS editors, maintainers, developers and list
supporters. The job you do is almost insurmountable, yet you do it with
aplomb. The LFS book is exactly what it says it is: a follow the
directions exactly learning experience to build an operation system.
That takes work and attention to details. Not only that, but you take
care of broken links on the web site, e-mails not automatically going to
those who need them--yes, I follow the list--and all sorts of other
housekeeping chores.
But given all of this, you take the time to aid people. I know I can be
a pest because I like to have things right in my mind before I go
ahead. It's worse right now since I'm scouring the rust from my
building skills. Just this week, Ken Moffat, Bruce Dubbs and Pierre
Labastie have taken the time to point me in the right direction so I can
do things the way I want to.
I remember from my working days that the trenches can get so deep I
wanted to throw in the towel. I urge you not to lose your attitudes.
Thanks to you all.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] Using 'find' to Help Make Package Users Simpler
This may come close to or straddle the off topic line for this list.
I thought I'd ask my question anyway since there are some who use the
More Control hint and who run into some of the same frustrations that I
do. There is a question about the use of find in this post. If you
don't want to read the reasoning behind doing this and some history skip
the following three paragraphs.
The install directory is an important concept in this system. It is a
directory in which any package user can write, but that files in it can
be changed only by the owner of that file--ug=rwx,o=rxt. The initial set
of these directories is listed in a file called installdirs.lst. This
file is used to set the permissions of all directories to which
different package users could write. The most frustrating, naggy and
four letter word evoking event is trying to write to a directory made
by a different package user and in which the current package user cannot
write. This is the purpose of the auxiliary install group. The
trick, then, is to identify all the new directories from a package and
make them install directories. This used to be a really down-in
-the-trenches manual job.
Rob Taylor did some great work in scripting the search for new
directories. He has a series of 'find' statements that step through the
directory tree--/usr, /bin, /lib, et.al.--finding all directories and
sending them to installdirs.lst. He then has a sed command that
removes /usr/src/ tree directories--this is the tree in which the
package users have their home directories and these should not be group
writable. He then has two statements 'chown' and 'chmod' whose input is
$(cat installdirs.lst).
This system works and is really a nice addition to package users'
support. The first 'find' statement re-creates installdirs.lst and
the remaining 6 append to it. And sed removes /usr/src each time. I
thought it would be more economical to not over write installdirs.lst
each time, and to use 'find' to identify only the new directories,
change their group ownership, then their permissions, and finally append
them to installdirs.lst. I know that find is powerful enough to ignore
/usr/src, so the need for the sed statement goes away.
Here's the find statement:
find / -xdev -type d -gid $(id -g packageuser name) \! -path /usr/src
\! -path /tools -print
This statement achieves all the parameters stated above with the
addition that it ignores /tools also. Now I would like to change group
ownership and permissions and redirect the output to installdirs.lst. I
know I could do that using an intermediate file:
find tmpfile
chown $(cat tmpfile)
chmod $(cat tmpfile)
tmpfile installdirs.lst
rm tmpfile
But, and here's the real question of this post, can I do this with one
statement? Here's my first idea:
'find' | 'chown' | 'chmod' installdirs.lst
Or, can I use more than one -exec option in 'find'? The statement would
look something like this
find (stuff) -exec chown :install {} \; -exec chmod ug=rwx, o=rxt {} \;
installdirs.lst
The reason I'm asking this question is that one of my references says
[-exec] will execute the program once per file while xargs can handle
several files with each process. I've never been successful with xargs
and I don't know if 'find' will, then ignore the second -exec. I
haven't been able to glean anymore from wandering around on the internet
and wading through man pages.
I have piped the output of find only once many times, but I don't know
if the output would survive two pipes.
I guess that it's just one question after all. Can I use chained
pipes or -execs before I redirect?
Anyone have any comments or suggestions. In the meantime, I'll just
play. What can I do, but screw things up, and I've done that twice this
week already.
Sorry for the long post. I appreciate your patience.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Using 'find' to Help Make Package Users Simpler
On 10/16/2013 03:15 PM, Pierre Labastie wrote: I've never tried two -exec directives in find, sorry. What I know is that xargs is more flexible, and I recommand that you insist on having it work. It could be something similar to: find... -print| xargs -I xxx sh -c 'chmod xxx; chown xxx; echo xxx installdirs.lst' more robust: find... -print0 | xargs -0 -I xxx sh -c 'chmod xxx; chown xxx; echo xxx installdirs.lst' Good luck Pierre Thank you, Pierre! I now know why I was not successful with xargs. I didn't know about sh -c. I never really jumped into the examples at the end of the man page. And know I need to really get a firm handle on all the options for xargs so I can use it. I don't understand, though, -I xxx. First, I don't know what the xxx would mean, and secondly, the way I see it in my limited knowlege, the file name would be the standard input, but what string would it be replacing. My understanding of -I is that standard input would replace some string. Would you please tell me if my understanding of -I is right, and then indicate what I might put in place of xxx. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Using 'find' to Help Make Package Users Simpler
On 10/16/2013 03:59 PM, Dan McGhee wrote: On 10/16/2013 03:15 PM, Pierre Labastie wrote: I've never tried two -exec directives in find, sorry. What I know is that xargs is more flexible, and I recommand that you insist on having it work. It could be something similar to: find... -print| xargs -I xxx sh -c 'chmod xxx; chown xxx; echo xxx installdirs.lst' more robust: find... -print0 | xargs -0 -I xxx sh -c 'chmod xxx; chown xxx; echo xxx installdirs.lst' Good luck Pierre My understanding of -I is that standard input would replace some string. Would you please tell me if my understanding of -I is right, and then indicate what I might put in place of xxx. Thanks, Dan I had it exactly backwards! -I replaces standard input with a specified string. I used, simply, file. The command line with print0 did exactly what I wanted. Maybe I should now learn about aliases instead of writing a one line script. :) Thanks again, Pierre. You really helped. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Vim Early in Ch. 6
On 10/14/2013 08:54 PM, William Harrington wrote: On Oct 14, 2013, at 8:08 PM, Bruce Dubbs wrote: ./configure --prefix=/tools make make install Should probably also include this: echo '#define SYS_VIMRC_FILE /tools/etc/vimrc' src/feature.h It looks like I'd run that before I ran ./configure. Am I correct? There have been many threads in the past throughout the various LFS versions even before 5.1.1 to add an editor in ch5, but the LFS devs never found it useful, although I have, and others have, too. Some of us do require an editor in ch6. Sed isn't that great, cat is okay with more as a pager before less isbuilt. But when you have text like this: It is a good idea to visually inspect the specs file to verify the intended change was actually made. when adjusting the toolchain, it's much easier in a text editor. Either way, users have a pager which can be used, not ideal if a need to edit. If someone wants a full set of tools to build a complete final system, an editor is required, even if the build commands don't use it. But, don't see an editor in ch5 any time soon. Although, if you want to learn how to use sed and gawk, go for it! Learn how to edit without an editor! Cause the LFS devs are hardcore! I really got a kick out of reading this. As one who employs Package Users, an editor is almost better than a steak dinner. I've developed my own scripts for this system and it's a necessity. But this is personal and not generic. An editor is really not a whistle or a bell, and, as you point out, it's not necessary to produce a functional system. And this points the question to the purpose of LFS, and, I think, why the editors are hardcore. I've seen them reject some really meaningful things over the years because what was requested would dilute the learning process of LFS. A process, which, by the way, I support 100%. My knowledge of linux type systems and my facility at the command line is all due to LFS. Yes, I could learn sed and gawk--the key word is learn. I'd like to, but haven't taken the time. Maybe no editor is a subtle way of pushing towards learning sed and gawk. That would be part of the LFS philosophy. I hope those hardcore editors don't see me as heretical, but I want my editor! So I'll build it with their help. :) Thanks for the command, William--and the enjoyment of your post. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Vim Early in Ch. 6
On 10/15/2013 10:28 AM, Dan McGhee wrote: On 10/14/2013 08:54 PM, William Harrington wrote: On Oct 14, 2013, at 8:08 PM, Bruce Dubbs wrote: ./configure --prefix=/tools make make install Should probably also include this: echo '#define SYS_VIMRC_FILE /tools/etc/vimrc' src/feature.h It looks like I'd run that before I ran ./configure. Am I correct? I thought of this just after I sent my first reply. I haven't looked at ./configure --help yet, but I'm wondering the define statement does the same thing as --sysconfdir=/tools/etc. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Ncurses Libraries in Perl Library Tree
In trying to add Vim at the end of Ch. 5, I discoverd that four ncurses
libraries weren't where they were supposed to be. Instead of /tools/lib
I found libncurses{,w}.so.5{,.9} (actually two of these are soft links)
in /tools/lib/perl15/5.18.1/x86_64-linux-gnu/. This just doesn't seem
right. I think I can remember typing x86_64-linux-gnu when building
Ch. 5, but I can't remember in what section. The only instructions in
either ncurses or perl that could have caused any typing issues--and I
usually copy and paste to eliminate those--are in the perl build. cp
-Rv lib/* /tools/lib/perl5/5.18.1.
I now have doubts about the success of my Ch. 5 efforts and want to wipe
the partition and start over unless someone can tell me that moving
those four items back to /tools/lib will solve the situation.
I discovered this situation when vim failed to configure because it
couldn't find terminal libraries and --with-tlib=/tools/lib didn't help.
I'd really just like to move those things, but right now I have no
confidence that all in my tool chain is correct. The other
clarification I need to add is that I had already set up and entered the
chroot environment once. I was in $LFS as me to configure and compile
and was going to install as root.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Ncurses Libraries in Perl Library Tree
On 10/15/2013 12:40 PM, Ken Moffat wrote:
On Tue, Oct 15, 2013 at 12:16:48PM -0500, Dan McGhee wrote:
In trying to add Vim at the end of Ch. 5, I discoverd that four ncurses
libraries weren't where they were supposed to be. Instead of /tools/lib
I found libncurses{,w}.so.5{,.9} (actually two of these are soft links)
in /tools/lib/perl15/5.18.1/x86_64-linux-gnu/. This just doesn't seem
right. I think I can remember typing x86_64-linux-gnu when building
Ch. 5, but I can't remember in what section. The only instructions in
either ncurses or perl that could have caused any typing issues--and I
usually copy and paste to eliminate those--are in the perl build. cp
-Rv lib/* /tools/lib/perl5/5.18.1.
On my 7.4 builds, in chapter 6 perl installs some files into
/usr/lib/perl5/5.18.1/x86_64-linux-gnu/. It doesn't do that in
chapter 5.
Similarly, in chapter 5 the book doesn't install the wide versions
of ncurses.
No idea how you could have got ncurses libs installed into the perl
directory tree. I guess you aren't scripting chapter 5, but if your
lfs user's bash history is available it might show something.
ĸen
There is one way, Ken. If I used the directions in Ch. 6 for perl
instead of Ch. 5. This I could have done inadvertently. But I remember
typing podlator and podman. Oh well. But as to how the ncurses
libraries got there Dunno. Everything else I've done is
peachy--except vim. I'll just move the ncurses libraries back to
/tools/lib and see what happens. If I'm not mistaken, by the time I get
to the big stuff in Ch. 6, all the support stuff has been built and
/tools is irrelevant for them. Thanks.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED][RESURRECTED]
On 10/13/2013 11:02 PM, Bruce Dubbs wrote: Drew Ames wrote: On 10/13/2013 06:48 PM, Dan McGhee wrote: I got to chroot and the copied su from shadow in Ch 5 didn't work. I can find no reason that it didn't. What I want to do now is compile it in chroot environment and install only it there. Just in case I missed some kind of linking. That seems unlikely, but ldd /tools/bin/su (on the copied version) provided: linux-vdso.so.1 (0x79b38000) libcrypt.so.1 = /tools/lib/libcrypt.so.1 (0x7f20fb668000) libc.so.6 = /tools/lib/libc.so.6 (0x7f20fb2b8000) /tools/lib64/ld-linux-x86-64.so.2 (0x7f20fb8a) as did ldd on my DESTDIR install, so it looks like everything is there. did some snipping Dan, Bruce, and Ken, I've been following this thread with interest. I'm into my fourth LFS build, using LFS 7.4. For my previous three builds, I successfully use the package user hint without any problems. Now I'm facing the same issues as Dan. more snipping I tried building su from an old source at this link, starting at line 802: http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904 I built it with GCC at the end of chapter 5 (I typed 'gcc -o su su.c'), then copied it to /tools/bin. When I got to chapter 6, as the root user in the chroot environment, that copy of su would not switch users to the linux-libc-headers user I created for the first package. I got the error: bash: /tools/bin/su: No such file or directory I then copied su from the host system and got the same results. Dan, when you say that su didn't work for you. Did you get an error message? I don't know, but I wonder if the problem is the lack of passwd, group, shadow, etc files. You need to track the source to find out. Just add printf statements at strategic places. Bruce, I think your on to something. Thank goodness for this list. Many times I can get into a thinking rut when I'm troubleshooting. Fresh minds really help. I'm thinking that the previous version of su supplied with coreutils was a stand alone binary. The versions supplied now by shadow and util-linux depend on auxiliary stuff as you mentioned; i.e., we don't install su from util-linux because it depends on pam, which we don't use. Shadow, I think, integrally supplies the monitoring that pam does. When I examined shadow's configure --help this AM, I found this: --enable-shadowgrp enable shadow group support [default=yes] ... --enable-account-tools-setuid Install the user and group management tools setuid and authenticate the callers. This requires --with-pam. Additionally, shadow tracks the number of logins, failed logins and all that other stuff. But I don't know how few of these additional files are needed to run it. If someone were familiar with printf, Bruce, I think you're right. :) I've been trying to learn about it this morning and know that I can change decimal numbers to octal or hex or any combination of that. I found that I can make pretty tables and center text, but I could find no examples of how to use it in the way you described. What kind of strategic places were you thinking and in what context? Until I understand more than what I do now about printf, I need to use brute force. :) My first thought is to try to use shadow's su from my DESTIR install without configuring shadow. If this works, I could then start removing stuff from DESTDIR/bin until su fails. Absent success there, I could do the same thing in chroot environment. I don't like to erase the slate but I could always nuke my build thus far, bring in my backed up /tools, and do the shadow stuff as lfs. For the package users who are monitoring this thread, Rob Taylor installed and configured shadow at the beginng Ch. 6. He then overwrote it in its regular sequence. There were a few hiccups as he noted in his build notes, but package users know how to get past those. :) Here's a link to his notes: https://www.javacrypt.com/lfs/my_lfs_7_4_notes.txt I'm always interested in learning more about this stuff. I would appreciate it, Bruce, if you could share some of your ideas about the printf strategy, if you can spare the time. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED][RESURRECTED]
On 10/14/2013 10:18 AM, Bruce Dubbs wrote: Dan McGhee wrote: On 10/13/2013 11:02 PM, Bruce Dubbs wrote: Drew Ames wrote: On 10/13/2013 06:48 PM, Dan McGhee wrote: I got to chroot and the copied su from shadow in Ch 5 didn't work. I can find no reason that it didn't. What I want to do now is compile it in chroot environment and install only it there. Just in case I missed some kind of linking. That seems unlikely, but ldd /tools/bin/su (on the copied version) provided: linux-vdso.so.1 (0x79b38000) libcrypt.so.1 = /tools/lib/libcrypt.so.1 (0x7f20fb668000) libc.so.6 = /tools/lib/libc.so.6 (0x7f20fb2b8000) /tools/lib64/ld-linux-x86-64.so.2 (0x7f20fb8a) as did ldd on my DESTDIR install, so it looks like everything is there. did some snipping Dan, Bruce, and Ken, I've been following this thread with interest. I'm into my fourth LFS build, using LFS 7.4. For my previous three builds, I successfully use the package user hint without any problems. Now I'm facing the same issues as Dan. more snipping I tried building su from an old source at this link, starting at line 802: http://wiki.linuxfromscratch.org/hints/browser/trunk/PREVIOUS_FORMAT/more_control_and_pkg_man.txt?rev=904 I built it with GCC at the end of chapter 5 (I typed 'gcc -o su su.c'), then copied it to /tools/bin. When I got to chapter 6, as the root user in the chroot environment, that copy of su would not switch users to the linux-libc-headers user I created for the first package. I got the error: bash: /tools/bin/su: No such file or directory I then copied su from the host system and got the same results. Dan, when you say that su didn't work for you. Did you get an error message? I don't know, but I wonder if the problem is the lack of passwd, group, shadow, etc files. You need to track the source to find out. Just add printf statements at strategic places. Bruce, I think your on to something. Thank goodness for this list. Many times I can get into a thinking rut when I'm troubleshooting. Fresh minds really help. I'm thinking that the previous version of su supplied with coreutils was a stand alone binary. The versions supplied now by shadow and util-linux depend on auxiliary stuff as you mentioned; i.e., we don't install su from util-linux because it depends on pam, which we don't use. Shadow, I think, integrally supplies the monitoring that pam does. When I examined shadow's configure --help this AM, I found this: --enable-shadowgrp enable shadow group support [default=yes] ... --enable-account-tools-setuid Install the user and group management tools setuid and authenticate the callers. This requires --with-pam. Additionally, shadow tracks the number of logins, failed logins and all that other stuff. But I don't know how few of these additional files are needed to run it. If someone were familiar with printf, Bruce, I think you're right. :) I've been trying to learn about it this morning and know that I can change decimal numbers to octal or hex or any combination of that. I found that I can make pretty tables and center text, but I could find no examples of how to use it in the way you described. What kind of strategic places were you thinking and in what context? In the source, add something like: printf( After executing foo\n ); at places and recompile. Then test and see if you get that output. If not then back up. Sometimes I just use printf( \n );, , , etc in the code. Note that the same thing can be done easier in gdb using stepping and preakpoints, but that's a bit difficult in this environment. If you are not familiar with C and have trouble understanding the code, this may not be the method that works for you. -- Bruce Therin lies the rub, Bruce. For many things in LFS, I know enough to ask semi-relevant questions, but the only thing I know about C is that it exists. Sounds like a project for one of those long, midwest winter nights when the north wind is howling at about 25 knots during a blizzard, and I have my hands wrapped around a piping mug of tea with honey and lemon. But for the topic at hand. I couldn't get su to work from a DESTDIR install even after I configured it in the DESTDIR--in chroot environment. Look like a regular install of shadow is in order. For purposes of the hint, assuming success with this step, I'll use the nuke the build option and see if I can get shadow to work at the end of Ch. 5. Depending on which one succeeds, I will recommend updating the hint accordingly. Thanks for the help. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script[RESOLVED]
On 10/12/2013 11:27 AM, Dan McGhee wrote: I'm melding my build script to the current one from this hint. I've found a possible syntax error and want to see if my thinking is correct. Since I've been monitoring this list closely again, i.e.; the last three weeks, I've not seen anyone who has had a problem running this script. But I think that few people build this way. :) Here is the line in question: cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1 snipped a few paragraphs If and || are logical operators, shouldn't the whole command be enclosed in double brackets, [[ command1 command2 || command3 ]]? The other syntax I know would be [ command1 -a command2 -o command3 ]. Of course, this is all predicated on the use of and || as logical operators. But if they're not, I don't understand the command. Comments? Answers? Recommendations? Rants? Thanks, Dan I ran this script for two different packages in Ch. 6 and it behaved flawlessly. Apparently Ken Moffat was right when he commented that the syntax function of gedit might be confused. Thanks to all who responded. This was a good learning and memory refreshment situation. Speaking of learning situations. I just learned to make sure that there's an escape route in scripts run by root. I wrote and ran a script to allow follow-on package users to write to directories created by an earlier user. (NOTE: This happens in the Package User hint.) I ran the script and forgot to pass an argument. I just hosed my LFS build. Oh well. I needed to test something else before Ch. 6 anyway. Thank goodness I backed up the tool chain. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED][UNRESURRECTED]
On 10/14/2013 10:40 AM, Dan McGhee wrote: But for the topic at hand. I couldn't get su to work from a DESTDIR install even after I configured it in the DESTDIR--in chroot environment. Look like a regular install of shadow is in order. For purposes of the hint, assuming success with this step, I'll use the nuke the build option and see if I can get shadow to work at the end of Ch. 5. Depending on which one succeeds, I will recommend updating the hint accordingly. Thanks for the help. Dan I've tested four different ways to provide su before starting to build the linux headers in Ch. 6. 1. compile shadow and cp su to /tools/bin in Ch. 5 2. install shadow at the end of Ch. 5 as lfs and not root. 3. compile shadow as root in the chroot environment and copy su to /tools/bin 4. install shadow as root before building the headers in Ch. 6 The only one that worked for me is the last one. The only thing I didn't do was configure shadow after installation, and su still worked. I'll configure it when shadow is installed in the course of going through Ch. 6. So, I think this process needs to be added to the hint. One of the reasons I like Package Users is that it's really easy to completely remove the files installed by a package. Installing shadow as root this way eliminates that and I don't know that shadow will over write it's files when installing as a package user when originally it was installed as root. That's something I'll be watching for as I make my way through. This might be the time to mention a trick I learned with find. Using -newer and ! -newer in a find command can bracket those files installed by one package. You can create a time window that's only two minutes wide. I haven't tested the seconds. Thanks to all who responded in this thread. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Vim Early in Ch. 6
I'm getting lazy in my old age and want to edit files while I'm working my way through Ch. 6. Package users employs a build.conf in each users home directory. The options for configure, make and install are entered here--along with other options. To make this a little easier I'd like to use Vim right away in Ch. 6. The section on it didn't have any dependency info. Will I be screwing anything up or making my build harder if I install it before I get started? Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Vim Early in Ch. 6
On 10/14/2013 08:08 PM, Bruce Dubbs wrote: Dan McGhee wrote: I'm getting lazy in my old age and want to edit files while I'm working my way through Ch. 6. Package users employs a build.conf in each users home directory. The options for configure, make and install are entered here--along with other options. To make this a little easier I'd like to use Vim right away in Ch. 6. The section on it didn't have any dependency info. Will I be screwing anything up or making my build harder if I install it before I get started? Just build vim at the end of chapter 5. ./configure --prefix=/tools make make install After you create the main directories, create /etc/vimrc according to taste. -- Bruce Thanks, Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED][RESURRECTED]
On 10/08/2013 11:14 AM, Dan McGhee wrote: On 10/07/2013 08:33 PM, Bruce Dubbs wrote: Ken Moffat wrote: On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: The usual way to look at what gets installed is to run 'make DESTDIR=/path/to/somewhere install [ optional args ]' - once you get into DESTDIR installs for looking at what is installed you will find some packages use other variables (often INSTALLROOT or something like that) - if shadow is such a package,then running *as a user* will fail. So try it as a user, to a directory which that user can write to. OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. If the only thing needed is su, then I'd build shadow with: ./configure make cp src/su /tools/bin It doesn't need to be suid since it's run by root. -- Bruce SNIP I have su now in the tool chain. I won't need it until I get to CH. 6, but with my OCD kicking in I wanted to build it just after coreutils in CH. 5. I suppose it doesn't really make any difference, but... snip I got to chroot and the copied su from shadow in Ch 5 didn't work. I can find no reason that it didn't. What I want to do now is compile it in chroot environment and install only it there. Just in case I missed some kind of linking. That seems unlikely, but ldd /tools/bin/su (on the copied version) provided: linux-vdso.so.1 (0x79b38000) libcrypt.so.1 = /tools/lib/libcrypt.so.1 (0x7f20fb668000) libc.so.6 = /tools/lib/libc.so.6 (0x7f20fb2b8000) /tools/lib64/ld-linux-x86-64.so.2 (0x7f20fb8a) as did ldd on my DESTDIR install, so it looks like everything is there. The two lines from the install log that I need are libtool: install: /usr/bin/install -c su /home/dan/LFS-7.4/shadow/bin/su and chmod -f 4755 /home/dan/LFS-7.4/shadow/bin/su; So after I compile I need either make install -c -m 0755 src/su /tools/bin or install -c -m 0755 src/su /tools/bin Which of the two commands will give me the necessary linking I need? Does it make a difference? Is the sytax correct. I apologize for being such a make and install dummy. It's just one of those things that I haven't gotten. BTW, I neither need nor want mode 4755 for the chroot environment. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED][RESURRECTED]
On 10/13/2013 08:56 PM, Drew Ames wrote: The two lines from the install log that I need are libtool: install: /usr/bin/install -c su /home/dan/LFS-7.4/shadow/bin/su and chmod -f 4755 /home/dan/LFS-7.4/shadow/bin/su; So after I compile I need either make install -c -m 0755 src/su /tools/bin or install -c -m 0755 src/su /tools/bin Which of the two commands will give me the necessary linking I need? Does it make a difference? Is the sytax correct. I apologize for being such a make and install dummy. It's just one of those things that I haven't gotten. BTW, I neither need nor want mode 4755 for the chroot environment. When I got to chapter 6, as the root user in the chroot environment, that copy of su would not switch users to the linux-libc-headers user I created for the first package. I got the error: bash: /tools/bin/su: No such file or directory I then copied su from the host system and got the same results. Dan, when you say that su didn't work for you. Did you get an error message? Drew, good to see you're still around. It has been a long time. I got no error or anything when I tried. Since I posted, I configured and compiled shadow using the book instructions for its installation in Ch. 6, removed the su I had copied earlier, then ran install -c -o 0755 src/su /tools/bin I got the same results--nothing. I was still root after I ran su linux-headers I'm stumped. I don't know where to look to troubleshoot. Rob Taylor just installed shadow before the linux headers and su worked. He reinstalled shadow in the normal course of things. This causes a few hiccups during Ch. 6--largely with install directories. I found an su file that is installed to /etc/pam.d, but since Ch 6 configures shadow not to depend on pam--because it's not installed--I doubt that would have any affect on the situation. Before I give up and install the entire shadow pacakge, I'm probably going to do a DESTDIR install somewhere in /mnt/lfs and try coping the binary to /tools/bin. We'll see what happens. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Possible Syntax Error in Current Package User Hint Build Script
I'm melding my build script to the current one from this hint. I've found a possible syntax error and want to see if my thinking is correct. Since I've been monitoring this list closely again, i.e.; the last three weeks, I've not seen anyone who has had a problem running this script. But I think that few people build this way. :) Here is the line in question: cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1 This patter occurs a number of times in the script and, therefore, I think it's important. For this question the references to what actually exist are not relevant. It's only the syntax. In attempting to understand what this statement is doing, I've come up with this plain language interpretation. Change to the package build directory IF AND ONLY IF the package source directory is the same as the current directory OR exit with a status of 1. In typing this I've also generated a question about the 's, but it's the use of the logical operators, which I've capitalized, that has my attention. Here's the question: If and || are logical operators, shouldn't the whole command be enclosed in double brackets, [[ command1 command2 || command3 ]]? The other syntax I know would be [ command1 -a command2 -o command3 ]. Of course, this is all predicated on the use of and || as logical operators. But if they're not, I don't understand the command. Comments? Answers? Recommendations? Rants? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On 10/12/2013 03:01 PM, Ken Moffat wrote:
On Sat, Oct 12, 2013 at 01:36:04PM -0500, Dan McGhee wrote:
I suppose that the most practical thing for me to do is jump into Ch.
6 and build with the script in the hint as it exists now. I could
pause at the end of this command to see what was happening. However,
in a previous life I was an engineer (Oh, no!!) and my OCD has kicked
in. First of all, I want to understand everything the script is doing
and when I looked at it in my text editor (gedit in Ubuntu) I saw a
problem. With that editor the only valid thing in pick is what's
between two quotes in an echo command. Anything else in pink has
something wrong in front of it--a syntax error. In gedit everything in
the script after $(pwd) is pink. There's something wrong, and I'd
like to find it before I start.
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
It's also, of course, possible that there is an apparent error
_before_ this which makes the highlighter confused.
That was another one of my first thoughts--of course that begs the
question of how many _first_ thoughts can there be. But I'll be
hornswaggled if I can find anything.
The package users hint now uses a build.conf file to input the specific
commands from the book for each package. The line in question first
appears in a function call to add patches if required. Let me repeat
the whole call for clarity.
-patch)
cd $HOME/xxxbuild/yyysrc srcdir=$(pwd) || exit 1.
patch_commands # no logging for patch necessary
#test_pipe
;;
Everything just changed! I had a moment of clarity. I can't believe it.
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Thanks again, Ken.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] Possible Syntax Error in Current Package User Hint Build Script
On 10/12/2013 05:48 PM, Ken Moffat wrote:
On Sat, Oct 12, 2013 at 04:59:04PM -0500, Dan McGhee wrote:
On 10/12/2013 03:01 PM, Ken Moffat wrote:
Maybe the syntax highlighting in that version of gedit is missing
or broken. Try vim and see how it looks ('syntax on' in ~/.vimrc or
/etc/vimrc). I use a black background, with ':colorscheme elflord'
I didn't see anything unusual when I pasted that line into a script.
Not that vim's highlighting is perfect, it occasionally gets
confused but usually only when I scroll a long way through a long
script.
That was one of my first thoughts and so I loaded up a script that I
knew worked and looked at it. It was fine. BTW it was the build script
you helped me with a few years ago. You taught me how to extract the
package name from a tar archive not knowing what the final extender
was--gz, tz, bz, bz2. If you're interested, I've got that down to one
line now instead of four since tar -xf works for all the stuff that I've
tested.
Yeah - I think I've still got that in my functions. As you say, it
hasn't been needed for a few years. The problem is knowing when the
last system with an old version of tar has gone. I know, I'll claim
I'm retaining it in case I ever have to build from a debian system
joke/.
Goodness! I'm using ubuntu as my host system. Hope tar works! joke/ | joke
My thought was, If there's something wrong in that line, the cd...
line, then if I edit it, I might get all the pretty colors back in the
rest of the script. The offensive character I found when I removed it
is the following $(pwd). When I remove the gedit indicates that the
syntax is OK. The problem, and it's not really a problem, is that this
exact line is the first in every function call of the script for _make),
_check) and _install). I understand the command because it puts you in
the right directory to run ./configure, make and install.
When I first saw this line, I thought that the purpose of all the was
to keep the shell from expanding things execpt a few special
characters. As a matter of fact, after I did some more editing just
know, I discovered that it's the combination of () and with $pwd that
causes the problem. Either set of characters *used alone* works. In
combination everything after ...d) including the is pink in gedit. I
know that last was a highly technical statement of the analysis. :)
I wonder if the first escapes the first ( and the last is seen as an
unresolved quote. Well, at least I found the problem, even though the
syntax sin escapes me--no pun intended, but when I read it, it's not a
bad one.
The script has been recently edited. I don't know how recently tested.
Hopefully, we can get the situation corrected.
Parentheses can be a pain. In metaflac all tag values are input in
double-quoted strings, but I've never managed to get parentheses in
a tag - I did once manage \( which wasn't at all what I wanted, but
every other attempt got an error report from bash.
Similarly, a parenthesised subshell which is commented by # in a
here document (e.g. the command to get the libxul sdk in firefox's
mozconfig in the BLFS book) *is* evaluated by bash - took me a long
while to work out where the message :
Package libxul was not found in the pkg-config search path.
Perhaps you should add the directory containing `libxul.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxul' found
was coming from when I built firefox without xulrunner :)
That's a real lesson. I know.
But it's all about learning.
Amen!! And it's the learning that has motivated me to ask my question.
Some of the people who have helped me on this may roll their eyes when
they read what I'm about to say. In my build script, I don't intend to
use the construction I asked about. My version successfully does what
this command indicates. I learned in the Navy, If it ain't broke,
don't fix it. I'm incorporating the new stuff in the package users
hint into my build script. Mine stops to review logs and recovers from
failed make and install. There are a lot of little, nit-picky and
naggy things in package users that will cause make and install to fail.
It's a real drag to start from scratch for these things. My script is
designed to make the process less frustrating. Rob Taylor has recently
done some work with wrappers and scripts to further reduce the frustration.
But it's the learning that motivated me to ask my question. I too have
had problems with parentheses. And just like your experience with
firefox, I like to learn what the _precise_ use of something is. For
example, many people will say that command1 command2 means run
command2 after command1. And that's generally how it works. The
precise meaning is run command2 if and only if command1 has an exit
status of 0. That's a real, albeit purely logical and subtle,
difference. I've had problems before when using
Re: [lfs-support] More control and package management using package users
On 10/07/2013 11:27 PM, Rob Taylor wrote:
Dan,
The build script itself already exists in the
more_control_helpers.tar.bz2 which is as it was before I got to it.
I altered it a little but for the most part it is as I found it. Now
that is not to say that I can not explain most of what it does... I
can, however I don't want to take credit for its design or function.
Now some things become quite clear for me in the historical sense. After
reading this e-mail, I went to the Change Log in the hint and saw some
things dating back to 2005. I wasn't aware of these. I'm trying to
find the exact date, but my last download of the scripts and helpers
must have been before Matthias' update in Dec, 2005. Whenever I got
ready to build LFS I just skimmed the hint to see if there were any
major changes, but used the one I had originally printed and maintained
my notes. I can't find it now. Drat! I thought you had developed the
build.conf concept, but apparently you didn't. Still. The wrappers you
modified and the helpers you designed, IMO, should be mentioned in the
Change Log. Build.conf is NOT in that log. That's why I thought you
did it and why you should make entries there. Some people do read those
things. :)
Re:root_{pre,post}_install
I noticed that when a function is missing from the build.conf file,
the step is just skipped. It appears that Matthias was experimenting
with this and didn't include it in the build.conf. I haven't tested
it, but the -c switch given to the su command is generally how you can
execute a script or command as a different user. So calling the script
itself with a specific option mentioned, and executing it as an option
to the su command should theoretically execute that phase of the
script as the specified user (in this case root). I expect the build
script would pause at this point expecting the user to enter the root
password since I don't see how it is getting passed.
My conclusion is, then, that they don't exist yet. I'll stop looking.
First reaction: I can't remember if it's a vim or emacs convention, but
my experience is, when working with an executable script in a graphic
text editor, that no color coding indicates a syntax problem and the
script will stop running at that point. Usually it's an extra or
missing 'fi,' a typo or a bracket problem. When I get there, I'll test
this build script to see if it runs. How long has it been since you
used it? (I think there is an extra 'fi' when calling the
root_pre_install commands. But, as you said, if it's not in build.conf
it would skip to _install.)
Second reaction: I'm just gonna have to look in the Advanced Bash
Scripting Guide I have--after I make sure it's current--and check on su
in a script. Regardless of the parameters passed, I think it's a bash
no-no.
https://www.javacrypt.com/lfs/dev_user_package_management.txt
If you look at the source code for the wrapper scripts that I have
been working on, you will see they seem rather involved. I noticed
that there was a great variety of ways that packages used the
commands: install, rm, ln, sln, unlink, mkdir, chmod, chown, chgrp
etc.. I also noticed that they did things that don't even seem to be
documented, such as placing folder and file references first and
options last, or putting the -m option between source and target file
and directory options. Also did you know that it is perfectly
acceptable to have a line feed in the middle of a file name? One of
the packages test this and so my wrapper scripts had to become more
and more robust to deal with these oddities.
But on that note it is worth mentioning that the wrapper scripts are
not really required until the install step. If you suspect that a
make check or make test is failing due to the wrapper scripts you
can simply disable them by changing the path, for the build check step.
For example, the rebuild of coreutils to enable acl in the BLFS was
checking things that were not permitted by the wrapper scripts... so I
simply did this in the build.conf file for the check function:
check_commands()
{ :
# for whatever reason, the wrapper scripts caused make test to fail
so...
WRAPPER_PATH=$PATH;# back up the PATH
export PATH=/bin:/usr/bin:/sbin:/usr/sbin;
make test
export PATH=$WRAPPER_PATH;# restore the PATH
}
It's for these things I think you should take credit in the Change Log.
That's a lot of work.
I am creating a my_blfs_7_4_notes.txt file, to carry on from the
similarly named LFS file, but I am a long ways off from publishing it.
I read your lfs notes and your developer notes. Outstanding job.
I almost have the su thing ready to go. I've got to correct somethings
in my current build and then I'll at least get su in /tools. It will be
a couple of days before I get to Ch. 6 to test it.
Enjoy your vacation and take care,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ:
Re: [lfs-support] Getting su in Chapter 5 [SOLVED]
On 10/07/2013 08:33 PM, Bruce Dubbs wrote: Ken Moffat wrote: On Mon, Oct 07, 2013 at 11:59:00PM +0100, Ken Moffat wrote: The usual way to look at what gets installed is to run 'make DESTDIR=/path/to/somewhere install [ optional args ]' - once you get into DESTDIR installs for looking at what is installed you will find some packages use other variables (often INSTALLROOT or something like that) - if shadow is such a package,then running *as a user* will fail. So try it as a user, to a directory which that user can write to. OK, so you can't try a DESTDIR install as a normal user because you are root and 'su' doesn't exist. Build outside the new system as user lfs and do a DESTDIR, e.g. to /home/lfs/somewhere or /tmp/somewhere. The same for su from old coreutils (my notes show that I had to build all of coreutils to get su linked - there might be a shorter series of commands - but NOT which old version of coreutils last contained 'su'. If the only thing needed is su, then I'd build shadow with: ./configure make cp src/su /tools/bin It doesn't need to be suid since it's run by root. -- Bruce Thanks to you both. Ken, I had forgotten about DESTDIR and was able to refresh my memory. I have su now in the tool chain. I won't need it until I get to CH. 6, but with my OCD kicking in I wanted to build it just after coreutils in CH. 5. I suppose it doesn't really make any difference, but... Bruce, I've forgotten the ins and outs of login vs. nonlogin shells, but in the package user system su is used to go from 'root' to 'pkgusr.' Of course, then, it's run by root, but I have also used it to go from 'pkgusr' to 'root' so I don't have to keep logging in. The test for this build will occur when I get to Ch. 6. Thanks again to you both. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Getting su in Chapter 5 [SOLVED]
On 10/08/2013 11:33 AM, Bruce Dubbs wrote: I don't use the pkgusr technique. I just use jhalfs. That said, I think I'd install sudo from blfs just before chapter 6 for doing what you want. The syntax is easier and it can be set to not request a password. To use it, you would need to wait until after section 6.6. -- Bruce Thanks, Bruce. It's been three years since I've done any of this, and the whole thing involves a lot of memory refreshment. In fact, in the last build I did, coreutils supplied su. So As far as using 'root' in pgkusers, there are two things: 1. ldcong 2. the commands in Ch. 6 that must be run as root. This all goes away after the shadow install and currently package user's scripts have one that works around needing to be root to use ldconfig. I've not tried it yet. AND, I never considered sudo until Ken mentioned it earlier. It's going to be a day or two until I get to CH. 6, but I'll see what the easiest approach will be. This AM, I used the copying method you suggested, but su needed a password and crypt killed the process. Probably because I'm still using the host system. Maybe things will be different after CHROOT. We'll see. Thanks again. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] Getting su in Chapter 5
I use the more_control hint in my builds. I need su before I start
working in Ch. 6. It's used to go back and forth between 'root' and a
'package_user.' When coreutils still supplied su, the procedure was
just to copy it to /tools/bin after installing coreutils to the build
chain. Su itself was not installed because user 'lfs' is the installer
and coreutils wanted to install it suid root. In the 'package users'
system, there is no need for it to be suid root, but it's needed before
the installation of shadow in Ch. 6.
One option is to install 'shadow' at the beginning of Ch. 6, but that
leads to some hiccups down the road. They're not insurmountable, but
they can be frustrating. I'm want to install only su from shadow
before I get to Ch. 6. My problem is that I know only enough about
make and make install to make me dangerous, and I get bogged down
reading the documentation.
Knowing that there are some packages in LFS that will either make one
target or install one target or copy the desired binary from the source
directory, I looked in the configure and makefile and just couldn't see
a way to do what I wanted. After I compiled it, I found all the
programs shadow installs in a directory called src. In it are sets of
files in the form filename.{,c,o}. Of course, in my situation I am
interested in only su, su.c and su.o. At this point can I just copy su
to /tools/bin? Do I need the other two files? If so, where do they go?
Alternatively, I have a question about how to use make install. The
following is part of the output from ./install-sh --help:
Usage: ./install-sh [OPTION]... [-T] SRCFILE DSTFILE
or: ./install-sh [OPTION]... SRCFILES... DIRECTORY
or: ./install-sh [OPTION]... -t DIRECTORY SRCFILES...
or: ./install-sh [OPTION]... -d DIRECTORIES...
In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.
The way I see this is that I'll get what I want if I run make install
su /tools/bin
Is this correct? Of course, I'm back to the copy mode if I can't
install this as user lfs. I do not want it suid.
I appreciate any and all help.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] More control and package management using package users
On 10/05/2013 11:11 PM, Rob Taylor wrote:
Hi Dan,
Thanks for the feedback. I'm just on vacation for a couple of weeks to
Hawaii, the big island. So I may not seem very responsive to emails
for a bit.
Oh goodness! I don't want to impact your vacation, but I'll still
post--so that you can respond if you think this stuff is as much fun as
Hawaii. :) BTW. I retired three years ago, so I am on continuous
vacation. I love it. Besides, in one of my previous lives I was an
engineer, and right now I'm trying to line up all my ducks before I
start my build. So there is plenty of time. There are a few things I
want to play with during my Ch. 5 efforts (see below) and that will slow
me down.
Feel free to change or use anything I have created. I didn't really
take over the hint, partially because I am not sure how much time I
will have to put into supporting it. But I did work on the wrapper
scripts because I tried out this user package management idea and I
could see room for improvement. Anything you or anyone else can add to
improve this project is welcome.
Which goes to my first question in this round. As a general statement,
I'm closely reading the build and build.conf scripts. All of my
questions stem from that.
Where can I find the 'root_{pre,post}_commands'? They do not appear in
'build.conf' and don't seem to be defined in 'build.' You call them as
for .configure, make and install and make the logs, but I can't find the
commands themselves. Ubuntu uses gedit for it's text editor and, when
you print the file, it puts things in nice pretty colors depending on
what the statement is. The last technicolor statement in the build
script is echo -n Preparing for install(root) The next statement
calls root_pre_install_commands, and it is in black as is the rest of
the printed script. I'm thinking that it can't find the commands.
I downloaded the tarball yesterday.
...Su no longer exists in coreutils so copying it in section 5 can not
occur. I see from the other effort mentioned here
https://github.com/ericherman/package-users that he suggests
installing shadow into the /tools area instead of /usr. That would
make sense to avoid any collision of files later when the normal
shadow install occurs.
This is one of the things I thought I'd play with after I learned about
no 'su.' My building skills are a little stale, but they're slowly
coming back. I seem to remember that you can 'make' or 'make install'
individual targets. I'm wondering if you can do that in 'shadow' during
Ch. 5. I think--remember I'm stale. please don't laugh--' make
target=su' or 'make install -su'. If it's possible, the syntax escapes
me right now. I seem to remember that there are some packages in LFS
that build only one or a few targets in a package. I'll review the
syntax and see what happens.
I thought about changing my_lfs_7_4_notes.txt
https://www.javacrypt.com/lfs/my_lfs_7_4_notes.txt to use that
approach but then decided that the example of how to deal with file
overwrite issues is a useful demonstration of the scripts handling of
these issues.
Gonna re-read those to see if it helps with the 'root_*_install
commands' stuff.
6. The build script will still quit after a section such as the
check fails. What I was referring to is that rather than a command
such as
install -c -m04755 -o root -g root ../../sourcefilename /sbin
failing and causing the entire make install to fail because the package user
does not have permissions to run it,
my wrapper scripts will filter out the -o root -g root and will alter the
-m04755 to be -m755 and will create a log
of the command as it was before and after modification, present working
directory when the command ran, any errors returned from
the command if it was run and in doing so the make install will continue to
run through to completion installing any and all
files that would have been run after the failure. So when you are all done with
a successful install, all you need to do is
examine the logs to see the list of files that you may or may not want to make
SetUID or SetGID root etc..
My wrapper scripts will also examine any issues of ownership of files, log
those issues and skip the specfic command that would
have generated a permission error so that the make install will continue as
far as possible generating a complete list of these
files with ownership issues so that a single chown command can be run to fix
all these permissions issues before rerunning
make install again without issue. You really would have to experience the
process to appreaciate what I mean. Also, suppose you don't
want this package to have replaced those specific files where there was an
overwrite situation? In this case if the overwrites
(which are logged for reveiew) are the only issue with an install and the
install completed with a result of success, you can simply move on.
This is much more seamless than having to edit Makefile.in
[lfs-support] Results of version-check.sh
In preparing for a new build and following the book religiously--as usual--I checked the versions on Ubuntu 13.04 with the following interesting results: 1. bin/sh is a link to dash 2. make info: command not found I know nothing about dash or texinfo. Are these two discrepancies serious enough to install more packages from Ubuntu? Which ones? Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Results of version-check.sh
On 10/06/2013 10:55 AM, Dan McGhee wrote: In preparing for a new build and following the book religiously--as usual--I checked the versions on Ubuntu 13.04 with the following interesting results: 1. bin/sh is a link to dash 2. make info: command not found I know nothing about dash or texinfo. Are these two discrepancies serious enough to install more packages from Ubuntu? Which ones? Dan Shouda looked before I leapt. Installed texinfo, but am still interested in knowing if dash is a suitable substitue for bash, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Results of version-check.sh [SOLVED]
On 10/06/2013 11:14 AM, Bruce Dubbs wrote: Dan McGhee wrote: On 10/06/2013 10:55 AM, Dan McGhee wrote: In preparing for a new build and following the book religiously--as usual--I checked the versions on Ubuntu 13.04 with the following interesting results: 1. bin/sh is a link to dash 2. make info: command not found I know nothing about dash or texinfo. Are these two discrepancies serious enough to install more packages from Ubuntu? Which ones? Dan Shouda looked before I leapt. Installed texinfo, but am still interested in knowing if dash is a suitable substitue for bash, Not for LFS. -- Bruce Thanks, Bruce. All done. Proceeding. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] More control and package management using package users
On 10/04/2013 01:57 PM, Rob Taylor wrote: I have updated the wrapper scripts to handle some new chmod functionality. It now supports OCTAL-MODEs that are longer than 4 digits or have preceding @ signs. See: https://lists.gnu.org/archive/html/bug-coreutils/2012-03/txtWUJXdGwYNs.txt Where it says: chmod, mkdir, install now accept new style of octal mode specification. When octal mode is preceeded by @ or is 5+ digits long with leading zeros, it can clear the set user id and set group id bits on directories. Get the latest more_control_helpers.tar.xz file from https://www.javacrypt.com/lfs/ Thanks, Robert Taylor On Mon, Sep 23, 2013 at 2:08 PM, Rob Taylor rtaylor...@gmail.com mailto:rtaylor...@gmail.com wrote: Thanks for the link Hans. On Mon, Sep 23, 2013 at 12:51 PM, hans kaper spaky...@xs4all.nl mailto:spaky...@xs4all.nl wrote: Op Mon, 23 Sep 2013 21:05:01 +0200 schreef Rob Taylor rtaylor...@gmail.com mailto:rtaylor...@gmail.com: I have been working through LFS 7.2, 7.3 and 7.4 testing and revising scripts for this package management system. I have added a number of scripts and in some cases almost entirely rewritten the existing scripts. While I have tested these scripts no one else has so, my version of this package should be considered Alpha or Beta at best. You can play with the revised project and see my notes here: https://www.javacrypt.com/lfs/ Another interesting piece of work on this subject you can find at https://github.com/ericherman/package-users. There was also a discussion on this subject on this support site about two years ago, initiated by Drew Ames. Robert-- Great job on this hint! I've used it since .the first time I ever built LFS. After a hiatus, I'm gearing up to do another build and saw this e-mail. I read your new hint, comparing it to the old one, and reviewed your scripts, build and build.conf. They are really, really elegant. I'm impressed. I have some questions and comments. 1. My first comment is constructive criticism. You have not taken credit for your work, either in becoming the maintainer nor in the improvements you've made. I urge you to identify yourself as maintainer at the beginng of the hint and take credit for your improvements in the Change Log. 2. Is it a personal preference to us AUFS? Or is there a technical motivation? 3. Is there something other than making a pretty prompt in the terminal that you added INPUTRC to a user's environment? 4. The last sentence of Section 5.10 ldconfig.c says, Because it doesn't evaluate any user input and doesn't pass any user-provided data to ldconfig, it can safely be made setuid root. I'm assuming that the first it refers to ldconfig.c and the second it refers to ldconfig. Is that corrrect? If it is, I recommend changing the end of that sentence to read, ...ldconfig, which can, then, safely be made setuid root. 5. Do you install 'shadow' as the first package after chroot so that you could get su? If so, since the hint tells you to copy 'su' to /tools/bin in Ch. 5, I'm wondering what advantage there is, especially since it causes some hiccups down the road. But, then, that may merely be an approach different to mine. 6. And that's a good segue to this comment. You designed your build script to continue through to completion regardless of errors--at least that's what I think I got from reading your build notes. I've found that unless I make a dumb mistake--copy and paste takes care of most of those :)--the only interrupts I had were about the lack of install_dirs or permissions like '-o root' I've written a build script which is not nearly as elegant as yours, but recovers from failed make and make install. That way, I can fix problems as they occur. When the build completes, then, I'm done and don't have to do anything extra with errors. Mine also pauses after running a test suite so that you can examine the results in a text window before proceeding. [interruption] Think I'll add that pause after 'configure' and 'make' so I can review *.err logs.[/interruption] If you don't mind, I'm going to plagiarize some of your ideas to spruce up my script. I will send youthe script as it exists now, while I'm plagiarizing :) , if you'd like to review it. Lastly, Hans talked about a discussion on this list a few years ago. I was part of that along with Drew. We were exchanging many, many ideas. One of those was version management for upgrades. If he's still around, I hope he jumps in here. I hope you have not reacted negatively to anything I've said here. You have done a great job. Thanks. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/13/2011 01:06 PM, Dan McGhee wrote:
On 03/12/2011 08:00 PM, Neal Murphy wrote:
snipping
OR use:
[ -e file_1 ] [ ! -e file_2 ] {
commands;
}
# equivalent: test -e $file_1 test ! -e file_2 {
OR even use:
[ -e file_1 -a ! -e file_2 ] {
commands;
}
# equivalent: test -e file_1 -a ! -e file_2 {
snipping
Thanks for the insight, Neal. I'm starting to play with the script. In
the above examples are you suggesting that I enclose the names of the
files in quotes? I can't find this syntax in my references. If you are
suggesting it, is it so that no expansion takes place?
I just found in the fine print of an example. ABS Guide uses it to allow
for spaces.
Nothing else on your script pokes me in the eye with a sharp stick.
Good.
Thanks again.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 06:00 PM, Dan McGhee wrote: One thing I want it to do is recover from a failed 'make' or 'install' without have to run the whole script again. This feature *used to* work. It now doesn't. If everything is OK, the script runs from the beginning to the successful end of a build. But if there is a glitch, the recovery doesn't happen. I'm replying to my own original post. Needed to have some stuff that the others snipped to show the error of my ways. The script was doing exactly what I told it to do. There were no problems with variables, syntax or exit status. What I didn't put in my original post, and this is my personal logic error, is that when I exited the script after make, simulating a failed install, it started at make again and not install. Please look at the following sequence. # This one recovers from failed make. if [ -e $logdir/make-`echo $package`.err ] \ [ ! -e $logdir/install-`echo $package`.err ]; then # This one recovers from a failed install if [ -e $logdir/make-`echo $package`.log ] \ [ ! -e $HOME/$package-files.list ]; then # This one does everything through configure, make, make install if [ ! -e $logdir ]; then The order is failed make, failed install and fresh build. If the install fails after make, the conditions exist to make,and the script will start there. So the order of the first two tests needed to be reversed. I did that and everything works the way I want it to. Thanks, Aleksandar and Neal, for your inputs. My syntax is now more elegant in addition to working. I learned a trick from the Advanced Bash Scripting Guide that proved to me that everything was as it should be except what I wanted the script to do. I had inspected and made sure that all the files and directories existed and had the right names. They did. But that didn't mean that the tests were parsing everything correctly, so I wanted to do something to test the test. I stumbled on this which is exactly what I needed: if [ -e $file ]; then echo $file exists else echo $file does not exist fi Inserting two loops like this to check my tests is what lead me to realize that the test order was not correct. Once again, thanks for the responses. I learned quite a bit. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
What might make this OT is that it's not a question specifically about
building LFS, but rather a question of a script that I use to build LFS
not working the way I want it to. If this is really OT, maybe someone
will respond privately if the any have any ideas.
As many of you know, I use the More Control with Package Users
management system. I have modified the build scripts in the hint to
minimize the pedantic work at the keyboard that's involved with a
build. The script is designed to find the tarball, un-tar it and the
configure, make,make check and install. Additionally, I add other
necessary commands from the book in the appropriate places; e.g.
patches, creating symlinks and moving files around.
The script has evolved over six years and, much to my chagrin right now,
I've not been good at keeping the old versions or maintaining a changelog.
One thing I want it to do is recover from a failed 'make' or 'install'
without have to run the whole script again. This feature *used to*
work. It now doesn't. If everything is OK, the script runs from the
beginning to the successful end of a build. But if there is a glitch,
the recovery doesn't happen.
The most common interruption in a build, when using more control, is
write permissions to a directory. This causes the 'install' to abort.
The fix is simple. Change the write permissions and re-run the script.
I want it to pick up with the make install command, but right now it
goes to the make command on any abort. I thing the testing for
conditions is failing, and I cannot see the flaw in the logic or
construction. It is in this area that I'd like some help. A fresh set
of eyes, so to speak.
Following is the script from the variable definition through the logic
tests. I've eliminated all the extra stuff.
#! /bin/bash
# Begin Build for PACKAGE
# Run this script from the package user's home directory by invoking it
# with the package name--ex. vim-7.2. ./build vim-7.2 or ./build
$(whoami) It will find
# the tarball in $PACKAGES, untar it, change to the created directory
# and configure, make, make check and make install. Then it will
clean up
# by creating a list of the installed files and remove the source tree.
# It will create 6 log files in the $HOME directory:
# configure.log: All messages output during configure
# configure.err: Just the errors output during configure
# make.log: All messages output during make
# make.err: Just the errors output during make
# install.log: All messages output during make install
# install.err: Just the errors output during make install
# variables
package=$@
logdir=$package-logs
PACKAGES=/sources
CURRENT=$package
took out a lot of stuff
# Begin tests and function calls for fresh and failed builds.
# This one recovers from failed make.
if [ -e $logdir/make-`echo $package`.err ] \
[ ! -e $logdir/install-`echo $package`.err ]; then #Now build
removed make, make check and make install sections
fi
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
removed make install section
fi
# This one does everything through configure, make, make install
if [ ! -e $logdir ]; then
removed configure, make, make check and make install sections
removed extra commands and clean up sections.
fi
# End Build
This script creates six logs: configure.{log,err}, make.{log,err} and
install.{log,err}, which I put in a log directory, $logdir. The very
last thing is does is create a list of files installed,
$package-files.list. Therefore, and here comes the testing logic, at
the beginning there is no log directory, and the test becomes [ ! -e
$logdir ].
The necessary and sufficient conditions to define a failed make are a
make log or configure log that exists and an install log or package file
list that does not exist. If an install fails, there will be a make
log but no file list. An install log *may* exist so I don't consider it
in the logic.
The preceding two paragraphs are my logic. Would someone please, using
that, compare the logic to the test statements to see if they match, if
the tests are constructed properly or if I need different logic.
As I said, if all is well, the script runs like a charm. If there's a
hiccup, a failed install, the script starts from the make test.
Doesn't that mean the the logic failed?
I've removed a lot of stuff in the script trying to make things relevant
and specific to only the question. Please feel free to ask for
additional info.
I'm hoping that someone can point me to better constructs or better logic.
Thanks,
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Hopefully Someone Will Check and Comment on My Logic [OT Maybe?]
On 03/12/2011 06:47 PM, Aleksandar Kuktin wrote:
On Sat, 12 Mar 2011 18:00:56 -0600
Dan McGheebeesnee...@att.net wrote:
[snip]
Following is the script from the variable definition through the
logic tests. I've eliminated all the extra stuff.
[snip]
# This one recovers from a failed install
if [ -e $logdir/make-`echo $package`.log ] \
[ ! -e $HOME/$package-files.list ]; then
[snip]
I've removed a lot of stuff in the script trying to make things
relevant and specific to only the question. Please feel free to ask
for additional info.
[snip]
Thank you, Aleksandar.
Well... DOES the script add all the logfiles it is supposed to add?
Are you /sure/? Have you checked?
Yes, yes and yes.
The tests look kosher, as far as that matters, but I would turn my
attention to the creation of logfiles.
Other than that, my money is on the `echo $package` substitutions.
If ${package} has a space in it, that could break it.
You can fix this by doing ''[ -e ${logdir}/make-${package}.log ]''.
This is what I was hoping to hear--that the logic is sound,but that
there might be a problem in the construct. I've shied away from ( ) and
{} in $ xxx statements because I'm really shaky on what they mean. I've
also never seen the ' ' [ ] ' ' construct. I use the Advanced Bash
Scripting Guide as my reference. Thank you for your feedback. I'll play
with this.
Take a small package (gzip?), and build it in such a way that it breaks
at various points, then inspect the relevant directories to see what is
there and what is not.
I've done this with GDBM by adding `exit 1` at various points. The
results are as I have described in my first post.
I appreciate your input. We'll see what happens.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: Help Needed with 6.12 Binutils + Package Users
On 01/10/2011 07:57 PM, Brian Winfrey wrote: I am unable to get passed 6.12 Binutils due to expect -c spawn ls returning the ptys error. if the command is run on host system it succeeds. this indicates that my kernel has support. if run on host as su lfs it succeeds. this indicates that it is not due to permissions. if run upon entering chroot it succeeds. this indicates that /dev is mounted correctly. if run in chroot as su binutils it fails. (ditto if run as 'su another_user'.) I notice that when I 'su another_user' in host the resulting SHLVL is 1; however, in chroot the result is 2. This is my third attempt, thinking I had missed something, so I have scripted everything. I do not think I have missed any steps on this attempt, but I may fall short on Package Users Hint - prerequisite 2 ;-) Any help is appeciated thanks, Brian If you take a close look at the Package Users hint you will see in the first two paragraphs of Section 6 some information about installing 'su' in Chapter 5 of the book. In Chapter 5.17 of the book, Coreutils-8.5, the last paragraph and the last command deal with this. There are a number of solutions. The one I used was to make 'su' setuid root. Therefore, this situation is a permissions one and one that has evolved with LFS leaving the hint a mite outdated in this regard. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Editorial Question on Chapter 7.4 of LFS-6.7 [SOLVED]
On 01/01/2011 11:03 AM, Andrew Benton wrote: On Sat, 01 Jan 2011 09:04:40 -0600 Dan McGheebeesn...@grm.net wrote: I'm just reacting to the way things used to be. The title of Chapter 7.4 is Configuring the setclock Script. The file created in this section is now named /etc/sysconfig/clock. I'm used to having it named setclock. I couldn't find any mention of a change in the Change Log. Is this now going to be the name of this script? That file has been called clock for as long as I can remember. Perhaps you're thinking of /etc/rc.d/init.d/setclock? Additionally, I'm not used to having anything else defined in this script. So should the line CLOCKPARAMS= be commented out. CLOCKPARAMS is not mentioned in /etc/sysconfig/clock, but it is mentioned in /etc/rc.d/init.d/setclock. As it stands setting the variable CLOCKPARAMS to null is safer than commenting the line out as the variable CLOCKPARAMS may have been set in the environment for some other use which may cause a problem for hwclock. Andy My router and I were not playing nicely yesterday and my reply to my own questions got lost somewhere. I found the information I needed in Appendix D, Boot and sysconfig scripts version 20100627. Another well of information that I hadn't used before. It's a great addition to the book. Andy, you're probably right about what I was thinking. Except for my very first build many years ago, I have copied and pasted the commands from the book. Soo... Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Editorial Question on Chapter 7.4 of LFS-6.7
I'm just reacting to the way things used to be. The title of Chapter 7.4 is Configuring the setclock Script. The file created in this section is now named /etc/sysconfig/clock. I'm used to having it named setclock. I couldn't find any mention of a change in the Change Log. Is this now going to be the name of this script? Additionally, I'm not used to having anything else defined in this script. So should the line CLOCKPARAMS= be commented out. Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Editorial Question on Chapter 7.4 of LFS-6.7 [SOLVED]
On 01/01/2011 09:04 AM, Dan McGhee wrote: I'm just reacting to the way things used to be. The title of Chapter 7.4 is Configuring the setclock Script. The file created in this section is now named /etc/sysconfig/clock. I'm used to having it named setclock. I couldn't find any mention of a change in the Change Log. Is this now going to be the name of this script? Additionally, I'm not used to having anything else defined in this script. So should the line CLOCKPARAMS= be commented out. The answer is in Appendix D. Nice addition. Thanks. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
OK to Build Ch.6 with Glibc2.12.1 having Glibc-2.11.2 in Ch.5 Tool Chain?
I see that LFS-SVN has been updated and one of the changes is moving to GlibC-2.12.1. I just completed Chapter 5 using SVN-20100803 which has GlibC-2.11.2. Is it best to rebuild Chapter 5 or can I just proceed with Chapter 6 using SVN-20100808? Thanks, Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: OK to Build Ch.6 with Glibc2.12.1 having Glibc-2.11.2 in Ch.5 Tool Chain?
On 08/09/2010 01:36 PM, Bruce Dubbs wrote: I think you can get by with proceeding to Chapter 6, but you'll be building glibc-2.12 with glibc-2.11.2. I suspect that it would be OK. I know. That's why I asked. Thanks, Bruce. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Glibc Makefile_fix Patch Doesn't Appear to be Available for Download
Using SVN-20100803 at Chapter 5.2, Glibc-2.11.2. Applying the patch command for glibc-2.11.2-makefile_fix-1.patch failed with No such file or directory. The patch is in the wget-list but I couldn't find it on any of the LFS download sites. Is there another way, about which I have forgotten, to get it? Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: Glibc Makefile_fix Patch Doesn't Appear to be Available for Download
On 08/04/2010 12:11 PM, Ken Moffat wrote: Yeah, I suspect make-3.82 will turn out to be too close to the bleeding edge. AFAICS, only Mandriva are using it (not necessarily for glibc, but make-3.82 is in 'cooker') and most of us don't have a clue what needs to be changed. Does this mean that we should revert to make-3.81 and proceed merrily from there? Maybe just continue on with the current SVN and document failures to the list? I'm building x86_64 and there was a note on the ticket that glibc built fine without the patch. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (SVN 20100726) - 6.9 Glibc-2.11.2
On 08/04/2010 01:42 PM, Andrew Benton wrote: Slightly more refined version, 2 seds, one after the other: sed -i 's/ot \$/ot:\n$/' manual/Makefile sed -i '/pot/a\\ttouch $@' manual/Makefile Better still, combine the 2 sed -i 's/ot \$/ot:\n\ttouch $...@\n$/' manual/Makefile Andy, just to be clear. You apply this sed command in Chapter 6 and *not* in Chapter 5? I've got make-3.81 installed on my host system, Ubuntu-10.04, I'm building for x86_64 and using LFS-SVN-20100803. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: LFS (SVN 20100726) - 6.9 Glibc-2.11.2
On 08/04/2010 07:38 PM, Andrew Benton wrote: I didn't apply it in chapter 5 as my host had make-3.81. However, next time I build it will be with a host which uses make-3.82, so I will need to apply the sed in chapter 5. At least, until they fix the glibc/manual/Makefile. Got it. Thanks, Andy. Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
