Hello, Thanks for the help. The solution is very simple and I should have thought about it myself! Now, I need one more help. As already written, I have installed nano, wget and lynx successfully after completing LFS. In fact, I am wondering why they have not been included in LFs in the first place as a simple editor and Net connectivity are essential to go beyond LFS.
I first installed Wireless Tools, WPA_supplicant and DHCP. I was getting "SERVICE" and other errors. I installed Firmware rtl8192cufw.bin. Even then, there was problem. So I tried "dhcpcd". Now, I can "ifup wlan0" and USB Wireless modem gets lighted. But when I try to connect I get this error message: "No DHCPOFFERS received. No working leases in persistent database - sleeping." after assigning itself of IP - 169.X.X.X. I wanted to do these all over again as dhcpcd and DHCP may be clashing but I do not know how to uninstall. Help will be highly appreciated. Thanks in advance as I find the whole thing very interesting for someone who has been working with Linux on the surface only for a number of years. (Now, I am in my sixties!) V S Nagasayanam, [email protected] On Sun, Oct 26, 2014 at 12:30 AM, < [email protected]> wrote: > Send lfs-support mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.linuxfromscratch.org/listinfo/lfs-support > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of lfs-support digest..." > > > Today's Topics: > > 1. make check error at section 6.9. Glibc-2.20 (Patrick Kennedy) > 2. Re: make check error at section 6.9. Glibc-2.20 (Bruce Dubbs) > 3. Re: make check error at section 6.9. Glibc-2.20 (Pierre Labastie) > 4. UEFI and GPT Structure (Dan McGhee) > 5. Re: UEFI and GPT Structure (Bruce Dubbs) > 6. Re: UEFI and GPT Structure (Ken Moffat) > 7. Re: UEFI and GPT Structure (Bruce Dubbs) > 8. LFS-7.6 Request for help in grub.cfg for multi-booting > (Nagasayanam,V.S) > 9. LFS-7.6 Request for help in grub.cfg for multi-booting > (Nagasayanam,V.S) > 10. Re: LFS-7.6 Request for help in grub.cfg for multi-booting > (William Harrington) > 11. Re: LFS-7.6 Request for help in grub.cfg for multi-booting > (Dan McGhee) > 12. Re: UEFI and GPT Structure (Dan McGhee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 24 Oct 2014 15:10:50 -0400 > From: Patrick Kennedy <[email protected]> > To: LFS Support List <[email protected]> > Subject: [lfs-support] make check error at section 6.9. Glibc-2.20 > Message-ID: > < > ca+srnkm7wz6oon7+-1mqgbw0vh3pz+4jvob1wdp55djlr7k...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Everything was clear sailing until I reached section "6.9. Glibc-2.20". > I'm getting an compile error while running "make check" as follows: > > ...snip... > > /sources/glibc-build/tests.sum > FAIL: posix/tst-getaddrinfo4 > Summary of test results: > 1 FAIL > 1721 PASS > 121 XFAIL > 3 XPASS > Makefile:321: recipe for target 'tests' failed > make[1]: *** [tests] Error 1 > make[1]: Leaving directory '/sources/glibc-2.20' > Makefile:9: recipe for target 'check' failed > make: *** [check] Error 2 > > I am using the 7.6 LFS book (standard, not systemd) on Debian Wheezy 7.6. > > Here's what my host system requirements info - > > ./version-check.sh > bash, version 4.2.37(1)-release > /bin/sh -> /bin/bash > Binutils: (GNU Binutils for Debian) 2.22 > bison (GNU Bison) 2.5 > /usr/bin/yacc -> /usr/bin/bison > bzip2, Version 1.0.6, 6-Sept-2010. > Coreutils: 8.13 > diff (GNU diffutils) 3.2 > find (GNU findutils) 4.4.2 > GNU Awk 4.0.1 > /usr/bin/awk -> /usr/bin/gawk > gcc (Debian 4.7.2-5) 4.7.2 > g++ (Debian 4.7.2-5) 4.7.2 > (Debian EGLIBC 2.13-38+deb7u4) 2.13 > grep (GNU grep) 2.12 > gzip 1.5 > Linux version 3.2.0-4-amd64 ([email protected]) (gcc version > 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u3 > m4 (GNU M4) 1.4.16 > GNU Make 3.81 > patch 2.6.1 > Perl version='5.14.2'; > GNU sed version 4.2.1 > tar (GNU tar) 1.26 > xz (XZ Utils) 5.1.0alpha > g++ compilation OK > > Any idea on the nature of the error doing the "make check" testing part? > Thanks. > > ~Patrick > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20141024/25501dd1/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Fri, 24 Oct 2014 14:48:47 -0500 > From: Bruce Dubbs <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] make check error at section 6.9. Glibc-2.20 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Patrick Kennedy wrote: > > Everything was clear sailing until I reached section "6.9. Glibc-2.20". > > I'm getting an compile error while running "make check" as follows: > > > > ...snip... > > > /sources/glibc-build/tests.sum > > FAIL: posix/tst-getaddrinfo4 > > Summary of test results: > > 1 FAIL > > 1721 PASS > > 121 XFAIL > > 3 XPASS > > Makefile:321: recipe for target 'tests' failed > > make[1]: *** [tests] Error 1 > > make[1]: Leaving directory '/sources/glibc-2.20' > > Makefile:9: recipe for target 'check' failed > > make: *** [check] Error 2 > > > Any idea on the nature of the error doing the "make check" testing part? > > Did you read section 6.9 where it says: > > posix/tst-getaddrinfo4 will always fail due to not having a network > connection when the test is run. > > -- Bruce > > > > > ------------------------------ > > Message: 3 > Date: Fri, 24 Oct 2014 21:48:33 +0200 > From: Pierre Labastie <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] make check error at section 6.9. Glibc-2.20 > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > Le 24/10/2014 21:10, Patrick Kennedy a ?crit : > > Everything was clear sailing until I reached section "6.9. Glibc-2.20". > I'm > > getting an compile error while running "make check" as follows: > > > > ...snip... > > > /sources/glibc-build/tests.sum > > FAIL: posix/tst-getaddrinfo4 > The book says: > > You will probably see some test failures. The Glibc test suite is somewhat > dependent on the host system. This is a list of the most common issues seen > for this version of LFS: > > posix/tst-getaddrinfo4 will always fail due to not having a network > connection when the test is run. > > Pierre > > > ------------------------------ > > Message: 4 > Date: Fri, 24 Oct 2014 16:48:07 -0500 > From: Dan McGhee <[email protected]> > To: LFS Support List <[email protected]> > Subject: [lfs-support] UEFI and GPT Structure > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > I started this thread so that I wouldn?t hijack my own over on -dev. > > One of the comments on my draft hint was this: > > > It's uncler to me the order of partitions of if it matters. I think > > using GRUB and UEFI requires both a 1MB GRUB partitiion (type ef02) and > > a 250 MB FAT32 (type 0700) partition. > > > In the overall scheme of things these distinctions may or may not be > important. But they are needed to use UEFI firmware to boot into EFI Mode > which is what the hint is about. Here?s where my knowledge is incomplete. > I *think*?and I?ll attempt to bolster this with additional research?that > the partition types, especially the FAT32 partition, indicate how the > firmware will boot. [Writing this cleared up the ?I *think* part. It?s > now a matter of ?how it boots.? It?s a matter of where grub goes *to* > boot.] Type ef02 indicates the system?s ESP, EFI System > PartitionAdditionally, which is the location of any and all executable boot > loaders?this even includes an actual kernel image. > > Researching this particular comment caused me to review my knowledge and > got me to a reference about which I had forgotten. I will be able to add > clarification. The ?meat? of the hint is operational and not conceptual. > Therefore, information with the detail in this post, probably won?t be > included, except in a reduced form. > > The reference is an article from Issue #168 March 2013 of ?Linux Format,? > entitled ?UEFI: Boot redefined.? The pdf file is 450kb and I don?t want to > attach it to a list post. I cannot supply a link from linuxformat.com < > http://linuxformat.com/> because the archives are available only to > magazine subscribers. > > Here is a small excerpt of the discussion on UEFI and MS-DOS and GPT > partitioning. > > The GPT scheme also includes a master boot record, and its purpose is to > help prevent corruption of a GPT disk by tools that are not GPT-aware. This > Protective MBR, or PMBR, contains an MSDOS partition table with one > partition covering the whole disk (or 2TiB if the disk is bigger). This > partition is marked with a type of 0xEE. Systems unaware of GPT will see an > unknown partition occupying the whole disk and leaving no available space. > > > > Another use of the protective MBR is to allow a BIOS to boot a GPT disk. > If it contains > > a bootloader then the BIOS will blindly load and execute it. If that > bootloader understands GPT then it can boot it. One such bootloader is > Grub2, and is used by many Linux distributions. This allows BIOS-based > systems to use disks greater than 2TiB. > > > > MS-DOS partitioned disks usually leave a gap (known as the DOS > Compatibility region), starting at sector 1 and running up to the beginning > of the first partition. Bootloaders traditionally used this unallocated > space to locate code (Grub 1 wrote its stage 1.5 loader here). With GPT, > the partition table begins at sector 1, immediately after the PMBR ? so > there is no unallocated space to use in this way. Instead, the GPT > specification provides for a special BIOS boot partition for use by boot > loaders that would otherwise have used the DOS Compatibility region. Grub 2 > writes its bootloader directly onto that partition (it does not contain a > filesystem). Given that the presence of the DOS Compatibility region was by > convention rather than definition, having a specifically allocated > partition is more robust. > > > The article goes on from here with an exercise using VirtualBox to ?...set > up a new system based on UEFI and GPT. Our new system will dual boot: it > will work with both UEFI and BIOS firmware. ? The disk created was 10GB. > > I am not able to ?copy and paste? the partition table after the exercise > from running <parted -l>. So I will attempt to recreate the table: > > Number Start End Size > Code Name > 1 2048 411647 200.MiB > EF00 EFI System > 2 34 2047 1007.0 > KiB EF02 BIOS boot partition > 3 411648 821247 200.0 MiB > 8300 Linux /boot filesystem > 4 821248 20971486 200.0 MiB > 8300 Linux /root filesystem > > I hope that table comes through holding the formatting. > > I guess that the specific reply to the comment is that the GPT > specification has this partitioning scheme. It?s not required by the > combination of UEFI-GPT-GRUB. It?s a matter of a user being able to > distinguish between the partitions and where the grub image will be > installed. > > Writing this post has helped solidify my knowledge of this and I think > discussions like this are quite valuable in this ?new? UEFI environment. > > Before the end, I must reiterate?UEFI and ?Secure Boot? are not > synonymous. Maybe that should be my e-mail signature. :) > > Dan > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20141024/9c694d25/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Fri, 24 Oct 2014 18:08:56 -0500 > From: Bruce Dubbs <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] UEFI and GPT Structure > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Dan McGhee wrote: > > I started this thread so that I wouldn?t hijack my own over on -dev. > > > > > The article goes on from here with an exercise using VirtualBox to > ?...set up a new system based on UEFI and GPT. Our new system will dual > boot: it will work with both UEFI and BIOS firmware. ? The disk created > was 10GB. > > > > I am not able to ?copy and paste? the partition table after the > exercise from running <parted -l>. So I will attempt to recreate the table: > > > Number Start End Size Code Name > > 1 2048 411647 200.MiB EF00 EFI System > > 2 34 2047 1007.0 KiB EF02 BIOS boot partition > > 3 411648 821247 200.0 MiB 8300 Linux /boot filesystem > > 4 821248 20971486 200.0 MiB 8300 Linux /root filesystem > > > > I hope that table comes through holding the formatting. > > Not quite. I reformatted a bit by removing tabs/spaces. > > However, I think the format of the disk above is poor. The partitions > are out of order. 1 and 2 are reversed. Also, the BIOS boot partition > is not aligned on a 1MiB boundary. On a modern disk, is the loss of > 1007.0 KiB really important? That's less than a floppy disk. > > When you copied, the size of partition 4 is way off. Should be around > 10G by my calculation. > > No swap partition? Personally, I think a /home partition is always > useful. Change the system, but not user data. But that's really a > different discussion. > > > I guess that the specific reply to the comment is that the GPT > > specification has this partitioning scheme. It?s not required by the > > combination of UEFI-GPT-GRUB. It?s a matter of a user being able to > > distinguish between the partitions and where the grub image will be > > installed. > > I agree. > > -- Bruce > > > ------------------------------ > > Message: 6 > Date: Sat, 25 Oct 2014 03:13:34 +0100 > From: Ken Moffat <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] UEFI and GPT Structure > Message-ID: <20141025021334.GB18746@milliways> > Content-Type: text/plain; charset=utf-8 > > On Fri, Oct 24, 2014 at 06:08:56PM -0500, Bruce Dubbs wrote: > > Dan McGhee wrote: > > >I started this thread so that I wouldn?t hijack my own over on -dev. > > > > > > > ?...set up a new system based on UEFI and GPT. Our new system will dual > > boot: it will work with both UEFI and BIOS firmware. ? The disk created > > was 10GB. > > > > > >I am not able to ?copy and paste? the partition table after the > > exercise from running <parted -l>. So I will attempt to recreate the > table: > > > > >Number Start End Size Code Name > > >1 2048 411647 200.MiB EF00 EFI System > > >2 34 2047 1007.0 KiB EF02 BIOS boot partition > > >3 411648 821247 200.0 MiB 8300 Linux /boot filesystem > > >4 821248 20971486 200.0 MiB 8300 Linux /root filesystem > > > > > >I hope that table comes through holding the formatting. > > > > Not quite. I reformatted a bit by removing tabs/spaces. > > > > However, I think the format of the disk above is poor. The partitions > are > > out of order. 1 and 2 are reversed. Also, the BIOS boot partition is > not > > aligned on a 1MiB boundary. On a modern disk, is the loss of 1007.0 KiB > > really important? That's less than a floppy disk. > > > > When you copied, the size of partition 4 is way off. Should be around > 10G > > by my calculation. > > > > No swap partition? Personally, I think a /home partition is always > useful. > > Change the system, but not user data. But that's really a different > > discussion. > > > > Just a comment on the bios boot partition's alignment: I forget > exactly how I set this up, and it is too late to look through my > notes tonight, but gdisk on this machine shows: > > Disk /dev/sda: 976773168 sectors, 465.8 GiB > Logical sector size: 512 bytes > Disk identifier (GUID): D7E3F344-D44D-1E7E-40B5-479D3F1E4309 > Partition table holds up to 128 entries > First usable sector is 34, last usable sector is 976773134 > Partitions will be aligned on 8-sector boundaries > Total free space is 16072685 sectors (7.7 GiB) > > Number Start (sector) End (sector) Size Code Name > 1 34 204833 100.0 MiB EF02 BIOS boot > partition > 2 204834 2301985 1024.0 MiB 0700 Linux/Windows data > etc > > So to me, sector 34 for the bios boot partition looks correct > (that's the one where grub lives, isn't it ?) > > sda2 is /boot, the other partitions are whatever suits me. > > As it happens, I now use 15GB for each potential '/', (I like to > keep old systems semi-usable, and to have multiple development > systems, but *anybody* intending to use LFS long-term ought to have > at least two potential '/' partitions). > > To me, an example with only a single 10GB system for '/' is fine for > a vm, but not a good thing to show as an example if people are going > to be following it on real disks (repartitioning a real disk, even > with good backups, is always a pain, and restoring the data is > usually a slow job). > > ?en > -- > Nanny Ogg usually went to bed early. After all, she was an old lady. > Sometimes she went to bed as early as 6 a.m. > > > ------------------------------ > > Message: 7 > Date: Fri, 24 Oct 2014 21:45:19 -0500 > From: Bruce Dubbs <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] UEFI and GPT Structure > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Ken Moffat wrote: > > On Fri, Oct 24, 2014 at 06:08:56PM -0500, Bruce Dubbs wrote: > >> Dan McGhee wrote: > >>> I started this thread so that I wouldn?t hijack my own over on -dev. > >>> > >> > >> ?...set up a new system based on UEFI and GPT. Our new system will dual > >> boot: it will work with both UEFI and BIOS firmware. ? The disk created > >> was 10GB. > >>> > >>> I am not able to ?copy and paste? the partition table after the > >> exercise from running <parted -l>. So I will attempt to recreate the > table: > >> > >>> Number Start End Size Code Name > >>> 1 2048 411647 200.MiB EF00 EFI System > >>> 2 34 2047 1007.0 KiB EF02 BIOS boot partition > >>> 3 411648 821247 200.0 MiB 8300 Linux /boot filesystem > >>> 4 821248 20971486 200.0 MiB 8300 Linux /root filesystem > >>> > >>> I hope that table comes through holding the formatting. > >> > >> Not quite. I reformatted a bit by removing tabs/spaces. > >> > >> However, I think the format of the disk above is poor. The partitions > are > >> out of order. 1 and 2 are reversed. Also, the BIOS boot partition is > not > >> aligned on a 1MiB boundary. On a modern disk, is the loss of 1007.0 KiB > >> really important? That's less than a floppy disk. > >> > >> When you copied, the size of partition 4 is way off. Should be around > 10G > >> by my calculation. > >> > >> No swap partition? Personally, I think a /home partition is always > useful. > >> Change the system, but not user data. But that's really a different > >> discussion. > >> > > > > Just a comment on the bios boot partition's alignment: I forget > > exactly how I set this up, and it is too late to look through my > > notes tonight, but gdisk on this machine shows: > > > > Disk /dev/sda: 976773168 sectors, 465.8 GiB > > Logical sector size: 512 bytes > > Disk identifier (GUID): D7E3F344-D44D-1E7E-40B5-479D3F1E4309 > > Partition table holds up to 128 entries > > First usable sector is 34, last usable sector is 976773134 > > Partitions will be aligned on 8-sector boundaries > > Total free space is 16072685 sectors (7.7 GiB) > > > > Number Start (sector) End (sector) Size Code Name > > 1 34 204833 100.0 MiB EF02 BIOS boot > partition > > 2 204834 2301985 1024.0 MiB 0700 Linux/Windows > data > > etc > > > > So to me, sector 34 for the bios boot partition looks correct > > (that's the one where grub lives, isn't it ?) > > Yes it is but 100M is *way* too big. Note that for disks with 4K > sectors with 512 byte sector emulation, sector 34 above does not align > with the physical sector. It's not really that big a deal because it's > rarely written and only read at boot time. > > See for instance > > http://askubuntu.com/questions/201164/proper-alignment-of-partitions-on-an-advanced-format-hdd-using-parted > > If it's done the same on all drives, then you don't need to worry about > the disk's physical format. > > I've found on a virtual system like qemu, if I create a new GPT with > gdisk, the first sector is created at sector 2048 by default, which is a > good standard to use everywhere. parted doesn't do it right by default > and the syntax is crazy. > > > sda2 is /boot, the other partitions are whatever suits me. > > Right. > > > As it happens, I now use 15GB for each potential '/', (I like to > > keep old systems semi-usable, and to have multiple development > > systems, but *anybody* intending to use LFS long-term ought to have > > at least two potential '/' partitions). > > Right again. > > > To me, an example with only a single 10GB system for '/' is fine for > > a vm, but not a good thing to show as an example if people are going > > to be following it on real disks (repartitioning a real disk, even > > with good backups, is always a pain, and restoring the data is > > usually a slow job). > > True. > > -- Bruce > > > ------------------------------ > > Message: 8 > Date: Sat, 25 Oct 2014 18:18:18 +0530 > From: "Nagasayanam,V.S" <[email protected]> > To: [email protected] > Subject: [lfs-support] LFS-7.6 Request for help in grub.cfg for > multi-booting > Message-ID: > < > cabk-ucew_6acvcayq7rqxhzpj2fx01bpfkk3vb53xummarm...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Thanks to the excellent book as well as LFS users in Internet, I have > managed to install LFS-7.6 which is highly satisfying. As I found Vim a > little complicated, I installed Nano after compiling. As I have only Wi-Fi > connectivity at this moment, I tried wireless tools but have not been > successful so far. I then tried to boot into Fedora 20 (my host system) in > which wi-fi modem is working. > > However, I face one small problem. Here is my grub.cfg file: > > > _________________________________________________________________________________________________________ > > set default=0 > set timeout=15 > insmod ext2 > set root=(hd0,6) > > menuentry "LFS" { > linux /boot/vmlinuz-3.16.2-lfs-7.6 root=/dev/sda6 ro > } > > set root=(hd0,1) > menuentry "Fedora 20" { > linux /boot/vmlinuz-3.11.10-301.fc20.i686+PAE > root=/dev/sda1 ro > initrd /boot/initramfs-3.11.10-301.fc20.i686+PAE.img > } > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Whenever I try to change booting from fedora 20 to LFS or vice versa, I had > to press "any key" and then have to add this: > > set root=(hd0,1) OR > set root=(hd0,6) > > to boot successfully. > Please help me to avoid this problem. > Thanks in advance and regards. > V S Nagasayanam, > [email protected] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20141025/fb1c0c29/attachment-0001.html > > > > ------------------------------ > > Message: 9 > Date: Sat, 25 Oct 2014 18:23:25 +0530 > From: "Nagasayanam,V.S" <[email protected]> > To: [email protected] > Subject: [lfs-support] LFS-7.6 Request for help in grub.cfg for > multi-booting > Message-ID: > <CABK-UCFxJrU=9npTKSV8Akff5N= > [email protected]> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Thanks to the excellent book as well as LFS users in Internet, I have > managed to install LFS-7.6 which is highly satisfying. As I found Vim a > little complicated, I installed Nano after compiling. As I have only Wi-Fi > connectivity at this moment, I tried wireless tools but have not been > successful so far. I then tried to boot into Fedora 20 (my host system) in > which wi-fi modem is working. > > However, I face one small problem. Here is my grub.cfg file: > > > _________________________________________________________________________________________________________ > > set default=0 > set timeout=15 > insmod ext2 > set root=(hd0,6) > > menuentry "LFS" { > linux /boot/vmlinuz-3.16.2-lfs-7.6 root=/dev/sda6 ro > } > > set root=(hd0,1) > menuentry "Fedora 20" { > linux /boot/vmlinuz-3.11.10-301.fc20.i686+PAE > root=/dev/sda1 ro > initrd /boot/initramfs-3.11.10-301.fc20.i686+PAE.img > } > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Whenever I try to change booting from Fedora 20 to LFS or vice versa, I had > to press "any key" and then have to add this: > > set root=(hd0,6) OR > set root=(hd0,1) > > to boot successfully. > Please help me to avoid this problem. > Thanks in advance and regards. > V S Nagasayanam, > [email protected] > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20141025/55f06f2f/attachment-0001.html > > > > ------------------------------ > > Message: 10 > Date: Sat, 25 Oct 2014 08:09:37 -0500 > From: William Harrington <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] LFS-7.6 Request for help in grub.cfg for > multi-booting > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > > On Oct 25, 2014, at 07:53, Nagasayanam,V.S <[email protected]> wrote: > > > > set default=0 > > set timeout=15 > > insmod ext2 > > set root=(hd0,6) > > > > menuentry "LFS" { > > linux /boot/vmlinuz-3.16.2-lfs-7.6 root=/dev/sda6 ro > > } > > > > set root=(hd0,1) > > menuentry "Fedora 20" { > > linux /boot/vmlinuz-3.11.10-301.fc20.i686+PAE > root=/dev/sda1 ro > > initrd /boot/initramfs-3.11.10-301.fc20.i686+PAE.img > > } > > I boot between dev builds and a server build in this example: > > menuentry "SERVER BUILD" { > set root=(hd0,2) > linux /boot/linux-3.14.22 root=/dev/sda2 > } > > menuentry "CLFS-GIT" { > set root=(hd0,1) > linux /boot/linux-3.12.17 root=/dev/sda1 > } > > Sincerely, > > William Harrington > > ------------------------------ > > Message: 11 > Date: Sat, 25 Oct 2014 08:27:34 -0500 > From: Dan McGhee <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] LFS-7.6 Request for help in grub.cfg for > multi-booting > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > > > On Oct 25, 2014, at 08:09, William Harrington <[email protected]> > wrote: > > > > > >> On Oct 25, 2014, at 07:53, Nagasayanam,V.S <[email protected]> wrote: > >> > >> set default=0 > >> set timeout=15 > >> insmod ext2 > >> set root=(hd0,6) > >> > >> menuentry "LFS" { > >> linux /boot/vmlinuz-3.16.2-lfs-7.6 root=/dev/sda6 ro > >> } > >> > >> set root=(hd0,1) > >> menuentry "Fedora 20" { > >> linux /boot/vmlinuz-3.11.10-301.fc20.i686+PAE > root=/dev/sda1 ro > >> initrd /boot/initramfs-3.11.10-301.fc20.i686+PAE.img > >> } > > > > I boot between dev builds and a server build in this example: > > > > menuentry "SERVER BUILD" { > > set root=(hd0,2) > > linux /boot/linux-3.14.22 root=/dev/sda2 > > } > > > > menuentry "CLFS-GIT" { > > set root=(hd0,1) > > linux /boot/linux-3.12.17 root=/dev/sda1 > > } > > > > Yes, there needs to be a ?set root=? statement for each kernel?inside the > curly brackets and before the ?linux? command. It tells GRUB where to look > for the kernel you want to boot. > > Dan > > > ------------------------------ > > Message: 12 > Date: Sat, 25 Oct 2014 10:04:56 -0500 > From: Dan McGhee <[email protected]> > To: LFS Support List <[email protected]> > Subject: Re: [lfs-support] UEFI and GPT Structure > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > > > On Oct 24, 2014, at 21:45, Bruce Dubbs <[email protected]> wrote: > > > > Ken Moffat wrote: > >> On Fri, Oct 24, 2014 at 06:08:56PM -0500, Bruce Dubbs wrote: > >>> Dan McGhee wrote: > >>>> I started this thread so that I wouldn?t hijack my own over on -dev. > >>>> > >>> > >>> ?...set up a new system based on UEFI and GPT. Our new system will dual > >>> boot: it will work with both UEFI and BIOS firmware. ? The disk created > >>> was 10GB. > >>>> > >>>> I am not able to ?copy and paste? the partition table after the > >>> exercise from running <parted -l>. So I will attempt to recreate the > table: > >>> > >>>> Number Start End Size Code Name > >>>> 1 2048 411647 200.MiB EF00 EFI System > >>>> 2 34 2047 1007.0 KiB EF02 BIOS boot partition > >>>> 3 411648 821247 200.0 MiB 8300 Linux /boot filesystem > >>>> 4 821248 20971486 200.0 MiB 8300 Linux /root filesystem > >>>> > >>>> I hope that table comes through holding the formatting. > >>> > >>> Not quite. I reformatted a bit by removing tabs/spaces. > >>> > >>> However, I think the format of the disk above is poor. The partitions > are > >>> out of order. 1 and 2 are reversed. Also, the BIOS boot partition is > not > >>> aligned on a 1MiB boundary. On a modern disk, is the loss of 1007.0 > KiB > >>> really important? That's less than a floppy disk. > >>> > >>> When you copied, the size of partition 4 is way off. Should be around > 10G > >>> by my calculation. > >>> > >>> No swap partition? Personally, I think a /home partition is always > useful. > >>> Change the system, but not user data. But that's really a different > >>> discussion. > >>> > > This reduces to a problem when quoting a technical document in a venue > such as this without being able to provide a link to or copy of that > document. In choosing what to include here I omitted some things, which > have, obviously, become important to the discussion. This exercise used > the Arch Linux ISO liveCD in VirtualBox to install Arch Linux. The > partitioning was done in preparation for that. So, most probably, the ARCH > pacstrap utility takes care of the things you mentioned. > > There is a discussion on using gdisk, but here are the parted commands > that wrote the partition table and made the partition: > > >> parted /dev/sda > >> (parted) unit s > >> (parted) mktable gpt > >> (parted) mkpart primary 2048 411647 > >> (parted) set 1 boot on > >> (parted) name 1 ?EFI System Partition? > >> (parted) mkpart primary 34 2047 > >> (parted) name 2 ?BIOS Boot Partition? > >> (parted) set 2 bios_grub on > >> (parted) mkpart primary ext2 411648 821247 > >> (parted) name 3 ?Linux /boot filesystem? > >> (parted) mkpart primary ext4 821248 20971486 > >> (parted) name 4 ?Linux /root filesystem? > >> (parted) quit > > The article then goes on to say, ??GPT partitioning here, but MSDOS > partitioning can be used instead if the disk is smaller than 2TiB. In that > scenario, omit the BIOS boot partition and use *fdisk* to change the > partition type of the EFI System Partition to 0xEF.? The exercise is to > show the difference between BIOS and UEFI booting. > > >> > >> Just a comment on the bios boot partition's alignment: I forget > >> exactly how I set this up, and it is too late to look through my > >> notes tonight, but gdisk on this machine shows: > >> > >> Disk /dev/sda: 976773168 sectors, 465.8 GiB > >> Logical sector size: 512 bytes > >> Disk identifier (GUID): D7E3F344-D44D-1E7E-40B5-479D3F1E4309 > >> Partition table holds up to 128 entries > >> First usable sector is 34, last usable sector is 976773134 > >> Partitions will be aligned on 8-sector boundaries > >> Total free space is 16072685 sectors (7.7 GiB) > >> > >> Number Start (sector) End (sector) Size Code Name > >> 1 34 204833 100.0 MiB EF02 BIOS boot > partition > >> 2 204834 2301985 1024.0 MiB 0700 Linux/Windows > data > >> etc > >> > >> So to me, sector 34 for the bios boot partition looks correct > >> (that's the one where grub lives, isn't it ?) > > > > Yes it is but 100M is *way* too big. Note that for disks with 4K > sectors with 512 byte sector emulation, sector 34 above does not align with > the physical sector. It's not really that big a deal because it's rarely > written and only read at boot time. > > > > See for instance > > > http://askubuntu.com/questions/201164/proper-alignment-of-partitions-on-an-advanced-format-hdd-using-parted > < > http://askubuntu.com/questions/201164/proper-alignment-of-partitions-on-an-advanced-format-hdd-using-parted > > > > > > If it's done the same on all drives, then you don't need to worry about > the disk's physical format. > > > > I've found on a virtual system like qemu, if I create a new GPT with > gdisk, the first sector is created at sector 2048 by default, which is a > good standard to use everywhere. parted doesn't do it right by default and > the syntax is crazy. > > The reason for Sector 34 on a GPT disk is that a GPT disk can hold 128 > partitions. Each partition record is 128 bytes long. With the information > stored in each partition record, a GPT disk needs 16,384 bytes=32 sectors. > Therefore, the first available sector is 34. Make things ?pristine,? as > alluded to in the ubuntu document, you could start the first partition at > sector 40. > > I?ve discovered also that gdisk by default is aligned to "2048-sector > boundaries,? and I agree that?s a good convention. Some people might call > that ?wasted space,? but it?s available to use for whatever reason. > > The 100M thing is probably true. I *think* it?s convention rather than > standard. It needs be only large enough to hold a grub, in this case, > image. > > > > >> sda2 is /boot, the other partitions are whatever suits me. > > > > Right. > > > >> As it happens, I now use 15GB for each potential '/', (I like to > >> keep old systems semi-usable, and to have multiple development > >> systems, but *anybody* intending to use LFS long-term ought to have > >> at least two potential '/' partitions). > > > > Right again. > > > >> To me, an example with only a single 10GB system for '/' is fine for > >> a vm, but not a good thing to show as an example if people are going > >> to be following it on real disks (repartitioning a real disk, even > >> with good backups, is always a pain, and restoring the data is > >> usually a slow job). > > > > True. > > I enjoy discussions like this. They help me cement what I already know, > cause be to bolster what?s weak and provide areas for new knowledge. For > the purposes of responding to the comment i received about my draft hint, > the point is to be able to recognize, and created as necessary, what?s > needed to boot LFS using grub in EFI mode on UEFI firmware. That?s a > specific subset of what we have been discussing. > > Dan > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20141025/ebb6bbd4/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > -- > http://lists.linuxfromscratch.org/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > > > ------------------------------ > > End of lfs-support Digest, Vol 153, Issue 1 > ******************************************* >
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
