Pierre Labastie wrote: > I have not tried to add /tools to a LIBRARY_PATH, because I am > (maybe wrongly) worried about linking to a libraries which are > then removed.
I think that is a needless worry. gcc uses LIBRARY_PATH so it can get the linkages, but when running, the LD_LIBRARY_PATH variable and the ld.so.cache is used to find the library for running. >> We could also move xz to be before GRUB. > Not tried either, but this should work >> The kernel creates the compressed boot images. GRUB only copies a set >> of bits into memory. I think GRUB wants xz to access a potential >> compressed file system. > As far as I understand the docs, in grub2, there are boot images > <file>.img created by grub, besides the bits copied to the MBR. > Those can be compressed, but the size is not very high anyway Yes. In the plain setup that we use on a MSDOS type partition table (still used by most of us), there is boot.img and core.img. The boot.img is exactly 512 bytes and goes in the first physical record on the hard drive. It contains the master boot record (64 bytes) but also the bootstrap code to load core.img. core.img goes on the first physical track (track 0) after boot.img. That track is conventionally 63 sectors long, so there is room for core.img to be 62 sectors (31K or 31744 bytes). It can be compressed. The first partition starts at track 1. My copy of grub-mkimage does not have xz built in and the /boot/grub/core.img file is 29478 bytes. If the core.img includes too many .mod files when it is built, it will not fit into the first track. We should have xz built into grub-mkimage to help avoid core.img too big errors. I'll note that newer systems will format a blank drive with a gpt type partition table using parted and start the first partition at 1M to make much more room for boot loaders. I haven't learned how to do that manually yet. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
