Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB
On Dec 18, 2013, at 9:24 AM, Dan McGhee wrote:
/usr/share/grub/grub-mkconfig_lib: line 53: 12058 Segmentation
fault (core dumped) ${grub_probe} -t fs $path /dev/null
21
Path `/boot/grub' is not readable by GRUB on boot. Installation is
impossible. Aborting.
Did you use optimizations while building grub?
Sincerely,
William Harrington
--
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
William Harrington wrote:
On Dec 18, 2013, at 9:24 AM, Dan McGhee wrote:
/usr/share/grub/grub-mkconfig_lib: line 53: 12058 Segmentation
fault (core dumped) ${grub_probe} -t fs $path /dev/null
21
Path `/boot/grub' is not readable by GRUB on boot. Installation is
impossible. Aborting.
Did you use optimizations while building grub?
I've always thought that not having a separate /boot partition that is
separate from any raid device makes things unnecessarily complicated.
The typical size of 100-200 Mb is trivial on today's drives and the fact
that it is read mostly means that backups should be easy.
-- 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] LFS 7.4 - Chapter 8.4 - GRUB
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 On Wed, 2013-12-18 at 10:08 -0600, William Harrington wrote: Did you use optimizations while building grub? Sincerely, William Harrington Yup. -O3 -march=native. And that said, something comes into my mind that I've read somewhere that grub does not play well with -O3. Thanks. Will try that on Friday. On Wed, 2013-12-18 at 10:32 -0600, Bruce Dubbs wrote: I've always thought that not having a separate /boot partition that is separate from any raid device makes things unnecessarily complicated. The typical size of 100-200 Mb is trivial on today's drives and the fact that it is read mostly means that backups should be easy. -- Bruce Agree 100% with you on that but my 20+ machines showed me that grub2, at least since LFS 7.2, plays very well with software raid1. And I have this obsessive compulsive 'optimization' behavior and not using raid on the boot here would leave me a partition of 200MB barren on one of the HDs and that would bother me a lot :). It would rob me of my sleep at night. But I have to admit that this is the first time that I'm using metadata version 1.2 on the boot partition. Until now I've always used v1.0. But I didn't prepare this machine, my young apprentice did, and I was just to lazy to rectify it. And I wanted to see what happens. :) Thanks all. Will keep you informed after I try compiling grub without optimizations on. Regards... attachment: face-smile.png-- 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 Dec 18, 2013, at 2:08 PM, loki wrote: Yup. -O3 -march=native. And that said, something comes into my mind that I've read somewhere that grub does not play well with -O3. Thanks. Will try that on Friday. Don't optimize the bootloader. Grub doesn't need optimizations. No bootloader needs optimization from gcc. You are dealing, also, with assmebly that the authors write for the target platform. Segfaults commonly come from grub when using optimizations. Also, may as well install strace and gdb and debug. I write this because grub, in the past has, segfaulted when using -O3 or -march set, even from before Grub 1. Even when using -O3 you can get a loading grub... message that hangs. Rebuild grub without optimizations and return with results. SIncerely, William Harrington -- 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
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. 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? -- Bruce 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
Date: Wed, 18 Dec 2013 15:44:17 -0600 From: Bruce Dubbs bruce.du...@gmail.com To: LFS Support List lfs-support@linuxfromscratch.org Subject: Re: [lfs-support] LFS 7.4 - Chapter 8.4 - GRUB . . 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? Every new machine passing thru or stopping here in past few years, _has_ - partly cos we check priorly that it will have: but ISTR talk recently on/via anandtech/... that the predictable is happening - i.e. of some machines being purely uefi; there's always some manuf that will/may want to 'cut corners' sooner rather than later and just do uefi-only, at least for some models. (And as noted elsewhere and here again, legacy-mode and gpt work just fine together; tho' I guess there'd be corner-cases.) akh -- 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] 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
Dan McGhee wrote: 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. 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 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 As an
