Re: [lfs-support] A Question about EFI Partition
On Tue, 12 Jun 2018 10:28:26 -0500 Bruce Dubbs wrote: > I don't think you can say that for all BIOS firmware, but it is > certainly true for some. I'm surprised by this, but you are correct here! According to t13.org/Documents/UploadedDocuments/project/d1386r0-EDD.pdf since 1999 BIOes have had "Enhanced disk drive (EDD)" support for an Int 13h extension than can address up to "16 mega-tera" sectors (2^64) in size. It is just a question of upgrading any boot loader to use this call (and hope the BIOS creator did it correctly). With the older BIOS call, the sector number is specified as a 32bit number and drives have historically used 512 bytes per sector. So, the upper limit with the legacy call is 2^32 * 512 = 2.199 TB On Tue, 12 Jun 2018 20:42:05 +0100 Ken Moffat wrote: > And then /dev/hda became /dev/sda - I never managed to get lilo to > work with /dev/sd if the machine was currently booting from /dev/hd. IMHO, lilo had one particularly awful design decision and the resulting unexpected behavior was never explained to us as it should have been - lilo would *reinterpret* whatever the user specified for root= in terms of device numbers of the current running system and then pass the resulting device *number* as the value of root= to the kernel to be booted. The only exceptions allowed were for LABEL= and UUID=, but even there what we really needed was PARTUUID=. In short, lilo should have just kept root= exactly as the user gave it in the lilo.conf and passed that string as-is to the kernel when booting. I was working on one of my (really) old machines back in November and wrote a patch for lilo to do just that. I've attached it to this post. Once the patch has been applied and lilo rebuilt, you can put anything you want for root= and it will be passed-on as-is. That means you can do things like: root="PARTUUID=1234567a-af67-4c97-8154-438376dc7113" or root="/dev/sda1" and it will work as you expect - root= will be interpreted only at boot by the booting kernel. And lilo will also work with GPT partitioned disks just fine! (because lilo only cares about sector numbers, not partitions). The main lilo limitations would then be: 1. The EFI/BIOS must provide the legacy BIOS "compatibility" (CSM) calls. 2. Lilo's second stage boot loader and any kernel images to be loaded must be within the first 2TB boundary. (I think.) 3. The drive must be using a 512 byte sector size. (I think.) 4. As always, if lilo's second stage boot loader or a kernel image file is moved, lilo must be rerun to get the correct sector number locations of those files. If they really are problems, both #2 and #3 should also be fixable in code, well, as long as the BIOS call of the machine supports it. I suppose my "pass root as-is" patch would have really been helpful to some folks ... 5 years ago. Oh well. Mike lilo_pass_root_as_is.patch Description: Binary data -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A Question about EFI Partition
On Tue, Jun 12, 2018 at 10:28:26AM -0500, Bruce Dubbs wrote: > On 06/12/2018 12:43 AM, Michael Shell wrote: > > There are a lot of things that can go wrong when disk sector numbers are > embedded into the code like lilo does. I do not know anything about the > internals of elilo though. > (Just a few comments, not related to EFI) - I liked lilo, and I deviated from the book to use it on most of my machines - perhaps only one had grub-legacy at that time, and that was just for testing the book. Hell, on pure64 (cross-lfs) we couldn't even build grub-legacy at first. And then /dev/hda became /dev/sda - I never managed to get lilo to work with /dev/sd if the machine was currently booting from /dev/hd. > > > BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo, > > etc., must ensure that the (second stage) boot loader as well as any > > kernel image files are located within the first 2 TB of the drive > > because the BIOS calls can't handle sector numbers beyond that. > > I don't think you can say that for all BIOS firmware, but it is certainly > true for some. Personally, I always make the grub partition sda1. > My only machine with drives bigger than 2TB uses them for RAID-1 not for booting. ISTR that I had to use GPT on them to be able to use the whole drive. For msdos partitioning, I've got /boot all over the place - sda14 on one machine which is towards the end of a nominally 500GB drive. > > > I believe the slots the sata drives are plugged into have priorities. > > > I've never seen the disks reverse identification. that would really be > > > a bad race condition. If it was happening, we would certainly have > > > heard about it. > > > > I can't remember exactly how I was bitten by it, but it wasn't via USB. > > It might have been from the use of a removable rack or SD card to SATA > > adapter (as a "rescue" boot) that sometimes would have media in it and > > sometimes not. > > On my oldest machine (very old) the drive devices move around according to which connectors have a drive attached. I think I've also seen that on other machines over the years : plug in only to the first connector, it is sda, but add another drive on a "later" connector and sda became sdc. Not all connectors on some consumer-grade motherboards use the same SATA driver. > > In any case, according to > > https://wiki.archlinux.org/index.php/persistent_block_device_naming > > > > "If your machine has more than one SATA, SCSI or IDE disk controller, the > > order in which their corresponding device nodes are added is arbitrary." > > Yes. I recall using e2label for consistent naming (I think on that machine, even with the exact same connections, a newer kernel could also move them around - and that is, of course, with the drivers built-in. > > As I understand it, that is the policy of the kernel developers - a system > > might work in many cases, but it is not guaranteed and a future kernel > > update could break systems that rely on any fixed /dev/sd* naming. To me, > > this means that, until udev becomes active and we can control things as we > > wish, any /dev/sd* specifiers are to be considered worthless. > > I see. I guess I've never had a system with multiple disk controllers. My > development system has six sata drives, but they are all plugged into the > motherboard so that is one controller. I think that multiple controllers > are rare outside of large organizations. > > > I do not like that policy. Unless countermanded by a kernel option, > > on-motherboard controllers should be enumerated before those of any add-on > > card or USB device. > > USB is separate as is a CD/DVD device. At least it is in any BIOS that I > have worked with. Perhaps it is a problem if multiple USB drives are > plugged in at boot. I have not tried that. Plugging in a usb drive before power on often used to give problems. ĸen -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] Rather a lot of glibc check errors
On Tue, Jun 12, 2018 at 06:29:20PM +0100, Hazel Russman wrote: > Building LFS 8.1 on my Samsung laptop, I was surprised to see a large number > of math errors in the chapter 6 glibc check: > > The failed tests were: float-cabs, float-fma, float32-cabs, > float32-fma, float64x-acosh, float64x-atan, float64x-atan2, > float64x-cacos, float64x-casin, float64x-casinh, float64x-catanh, > float64x-clog, float64x-clog10, float64x-finite-acosh, float64x-finite-atan, > float64x-finite-atan2, float64x-finite-cacos, > float64x-finite-casin, float64x-finite-casinh, float64x-finite-catanh, > float64x-finite-clog, float64x-finite-clog10, float64x-finite-log10, > float64x-log10, ifloat64x-acosh, ifloat64x-atan2, ifloat64x-cacos, > ifloat64x-casin, ifloat64x-casinh, ifloat64x-catanh, ifloat64x-clog, > ifloat64x-clog10, ildouble-acosh, ildouble-atan2, ildouble-cacos, > ildouble-casin, ildouble-casinh, ildouble-catanh, ildouble-clog, > ildouble-clog10, ildouble-log10, ldouble-acosh, ldouble-atan, ldouble-atan2, > ldouble-cacos, ldouble-casin, ldouble-casinh, ldouble-catanh, ldouble-clog, > ldouble-clog10, ldouble-finite-acosh, ldouble-finite-atan, > ldouble-finite-atan2, ldouble-finite-cacos, ldouble-finite-casin, > ldouble-finite-casinh, ldouble-finite-catanh, ldouble-finite-clog, > ldouble-finite-clog10, ldouble-finite-log10, ldouble-log10. > Hi Hazel, googling for a couple of random tests in that list found failures in the release notes for glibc-2.26, which I think you are using, and glibc-2.27. But they were all on other architectures. > I've never had so many failures before. ISTR that earlier editions of LFS > warned about failures in maths tests on non-intel non-amd processors (the > Samsung has a Via nano) but 8.1 doesn't mention this. I suspect we removed that text because nobody who follows the dev list has non-intel non-AMD x86 CPUs these days. > > Do I need to rebuild and, if so, can anyone suggest what parameters I might > need to use to avoid a repetition? The proof of the pudding is in the eating! Probably very few people, if any, are using this CPU to build and test packages such as glibc. Usually, a test failure does not cause any noticeable problems at runtime. I would suggest you continue. ĸen > -- > Hazel Russman > -- > http://lists.linuxfromscratch.org/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > > Do not top post on this list. > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > http://en.wikipedia.org/wiki/Posting_style -- Keyboard not found, Press F1 to continue -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
[lfs-support] Rather a lot of glibc check errors
Building LFS 8.1 on my Samsung laptop, I was surprised to see a large number of math errors in the chapter 6 glibc check: The failed tests were: float-cabs, float-fma, float32-cabs, float32-fma, float64x-acosh, float64x-atan, float64x-atan2, float64x-cacos, float64x-casin, float64x-casinh, float64x-catanh, float64x-clog, float64x-clog10, float64x-finite-acosh, float64x-finite-atan, float64x-finite-atan2, float64x-finite-cacos, float64x-finite-casin, float64x-finite-casinh, float64x-finite-catanh, float64x-finite-clog, float64x-finite-clog10, float64x-finite-log10, float64x-log10, ifloat64x-acosh, ifloat64x-atan2, ifloat64x-cacos, ifloat64x-casin, ifloat64x-casinh, ifloat64x-catanh, ifloat64x-clog, ifloat64x-clog10, ildouble-acosh, ildouble-atan2, ildouble-cacos, ildouble-casin, ildouble-casinh, ildouble-catanh, ildouble-clog, ildouble-clog10, ildouble-log10, ldouble-acosh, ldouble-atan, ldouble-atan2, ldouble-cacos, ldouble-casin, ldouble-casinh, ldouble-catanh, ldouble-clog, ldouble-clog10, ldouble-finite-acosh, ldouble-finite-atan, ldouble-finite-atan2, ldouble-finite-cacos, ldouble-finite-casin, ldouble-finite-casinh, ldouble-finite-catanh, ldouble-finite-clog, ldouble-finite-clog10, ldouble-finite-log10, ldouble-log10. I've never had so many failures before. ISTR that earlier editions of LFS warned about failures in maths tests on non-intel non-amd processors (the Samsung has a Via nano) but 8.1 doesn't mention this. Do I need to rebuild and, if so, can anyone suggest what parameters I might need to use to avoid a repetition? -- Hazel Russman -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A Question about EFI Partition
On 06/12/2018 12:43 AM, Michael Shell wrote: On Mon, 11 Jun 2018 23:20:51 -0500 Bruce Dubbs wrote: What issues with GPT and legacy boot? Grub needs some space for it's code that is OS independent. A separate small partition makes sense. Putting the boot code in firmware is what does not make sense. And you still need a custom EFI partition even then. Talking about a second stage loader is really about grub legacy. The current grub doesn't work like that. The old way of using a fat partition table and loading code in sectors 2-32 was really a kludge. Well, according to: https://en.wikipedia.org/wiki/BIOS_boot_partition "When used, the BIOS boot partition contains the second stage of the boot loader program, such as the GRUB 2; the first stage is the code that is contained within the Master Boot Record (MBR). Use of this partition is not the only way BIOS-based boot can be performed while using GPT-partitioned hard drives; however, complex boot loaders such as GRUB 2 cannot fit entirely within the confines of the MBR's 398 to 446 bytes of space, thus they need an ancillary storage space. On MBR disks, such boot loaders typically use the sectors immediately following the MBR for this storage; that space is usually known as the "MBR gap". No equivalent unused space exists on GPT disks, and the BIOS boot partition is a way to officially allocate such space for use by the boot loader." So, with GPT disks under BIOS systems, there is no way to initially load a boot loader complex enough to be able to read a filesystem. Lilo worked by requesting the sector numbers that corresponded to its second stage (and in turn, it's second stage requested the sector numbers of the kernel image to boot). That is why lilo had to be rerun every time a kernel image file was moved. There are a lot of things that can go wrong when disk sector numbers are embedded into the code like lilo does. I do not know anything about the internals of elilo though. So, when grub is running on a BIOS system with a GPT disk, it works a bit like lilo, except the second stage loader is contained in its own partition (where it can't be touched by mv, rm and friends) and that second stage is smart enough to be able to read files on FAT and EXTx filesystems without relying on fixed sector numbers. In this way, there is no need to "rerun" grub if a kernel image file is relocated as is the case with lilo. The code on the boot sector is very short (448 bytes as I recall). That does have enough to find the grub partition and read from there. In grub legacy the boot sector (sector 0) read exactly one sector (sector 1) and that loaded the other sectors up through sector 31. The sector 1 code was referred to stage 1 and the sectors 2-31 were stage 2. Sometimes this mechanism interfered with other programs. Autocad, for instance, wrote some data to the same area. BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo, etc., must ensure that the (second stage) boot loader as well as any kernel image files are located within the first 2 TB of the drive because the BIOS calls can't handle sector numbers beyond that. I don't think you can say that for all BIOS firmware, but it is certainly true for some. Personally, I always make the grub partition sda1. I believe the slots the sata drives are plugged into have priorities. I've never seen the disks reverse identification. that would really be a bad race condition. If it was happening, we would certainly have heard about it. I can't remember exactly how I was bitten by it, but it wasn't via USB. It might have been from the use of a removable rack or SD card to SATA adapter (as a "rescue" boot) that sometimes would have media in it and sometimes not. In any case, according to https://wiki.archlinux.org/index.php/persistent_block_device_naming "If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary." As I understand it, that is the policy of the kernel developers - a system might work in many cases, but it is not guaranteed and a future kernel update could break systems that rely on any fixed /dev/sd* naming. To me, this means that, until udev becomes active and we can control things as we wish, any /dev/sd* specifiers are to be considered worthless. I see. I guess I've never had a system with multiple disk controllers. My development system has six sata drives, but they are all plugged into the motherboard so that is one controller. I think that multiple controllers are rare outside of large organizations. I do not like that policy. Unless countermanded by a kernel option, on-motherboard controllers should be enumerated before those of any add-on card or USB device. USB is separate as is a CD/DVD device. At least it is in any BIOS that I have worked with. Perhaps it is a problem if multiple USB drives are plugged in at
Re: [lfs-support] A Question about EFI Partition
On Tue, 12 Jun 2018 14:25:48 +0800 Xi Ruoyao wrote: > efibootmgr uses the library from efivar for /sys/firmware/efi/efivars. > I searched "efivarfs" in the Github repo and found the commit to add > efivarfs support: > https://github.com/rhboot/efivar/commit/5b175a55d53c5d0f44e3636802fc7dc3fe7549a6 Thanks Xi! Yeah, that ability was added already in mid-2013. And so efibootmgr will auto select between efivarfs and the sysfs interface depending on what is available. So, any post-2013 efibootmgr will be able to use either interface. From https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt. "The efivarfs filesystem was created to address the shortcomings of using entries in sysfs to maintain EFI variables. The old sysfs EFI variables code only supported variables of up to 1024 bytes. This limitation existed in version 0.99 of the EFI specification, but was removed before any full releases. Since variables can now be larger than a single page, sysfs isn't the best interface for this. " So, the EFI spec itself changed and that is why we have the new interface. Mike -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A Question about EFI Partition
On 2018-06-11 20:21 -0400, Michael Shell wrote: > On Mon, 11 Jun 2018 23:13:29 +0800 > Xi Ruoyao wrote: > > Now we use CONFIG_EFIVAR_FS (y or m), instead of CONFIG_EFI_VARS, > > Do you know if efibootmgr will autodetect (at run time) between the two kernel > interfaces (and if this is a recent feature, what version starting supporting > that)? AFAIK, they both can be enabled at the same time. efibootmgr uses the library from efivar for /sys/firmware/efi/efivars. I searched "efivarfs" in the Github repo and found the commit to add efivarfs support: https://github.com/rhboot/efivar/commit/5b175a55d53c5d0f44e3636802fc7dc3fe7549a6 It was released in efivarfs-0.4. > As you mentioned, EFIVAR_FS is a more modern interface, but it does > require that a special efivarfs filesystem be (re)mounted r/w: > > mount -o rw -t efivarfs efivarfs /sys/firmware/efi/efivars Yes. Systemd mounts efivarfs automatically. But with sysvinit we should mount it manually, or in /etc/fstab. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Re: [lfs-support] A Question about EFI Partition
On 2018-06-12 01:43 -0400, Michael Shell wrote: > As I understand it, that is the policy of the kernel developers - a system > might work in many cases, but it is not guaranteed and a future kernel > update could break systems that rely on any fixed /dev/sd* naming. To me, > this means that, until udev becomes active and we can control things as we > wish, any /dev/sd* specifiers are to be considered worthless. > > I do not like that policy. Unless countermanded by a kernel option, > on-motherboard controllers should be enumerated before those of any add-on > card or USB device. Also, SATA slots for a given controller should be > enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be > enumerated regardless of whether a drive has been plugged into it. I would > go so far as to make it that an initial, say, half a dozen drive names would > be reserved for each USB controller regardless of whether a USB mass storage > device was actually present at boot. I would also not enumerate USB drives > in the /dev/sdx sequence, they would get their own sequence /dev/usbdx, > because those do not have known/fixed slots as SATA controllers do. > > In a more complex arrangement, controllers could be enumerated like the > devices they carry - /dev/sdAb1 - controller A, drive b, partition 1 > with motherboard controllers being enumerated first, and then those on > PCI, etc., slots, in the order of the slots they are plugged into. That's why devtmpfs and udev are here. Differnet people have different tastes of naming policy. Now they can just modify udev rules to provide a custom naming convention. But udev is not in early boot stage... If I have to use a persistant naming policy at early boot, I'll write a script to implement it and create an initrd. -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. 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
