On 20/03/2019 10:41, Pei Jia wrote:
On 2019-03-20 2:04 a.m., Pierre Labastie wrote:
On 20/03/2019 00:43, Bruce Dubbs wrote:
After a long thread on -support today I did a test build on a USB drive
today. These are some observations.
The USB drive was /dev/sdg. I only had one partition on the MSDOS style
partition table.
>From the host I installed GRUB with
grub-install /dev/sdg
To boot, I needed a grub.cfg file:
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
menuentry "GNU/Linux, vmlinuz-5.0-lfs-SVN-20190305" {
linux /boot/vmlinuz-5.0-lfs-SVN-20190305 rootdelay=10 root=/dev/sdg1
ro
}
When booting, I had to tell the system firmware (BIOS) to boot from the USB
drive.
In grub.cfg the line
set root=(hd0,1)
refers to GRUB's view of the system where it thinks the boot drive is hd0.
This allows GRUB to find the kernel, load it and then start it.
The kernel, on the other hand, searches the entire system for hard drives and
identifies them as it finds them. In my case I have six hard drives in the
system. sda, sdb, sdc, sdd, sde, and sdf. The USB drive is thus identified as
sdg. The linux boot line then requires
root=/dev/sdg1 rootdelay=10
The rootdelay is needed so the system has time to find the USB drive, but
/dev/sdg1 is needed for the kernel to find the root partition. The fstab file
also needs the same drive designations as the kernel command line.
If this USB drive is inserted into another system with a different disk
configuration, then these values will need to be changed. The workaround is
to use UUID or PARTUUID designations. PARTUUID is only available on GPT
partition tables [sic], but plain UUID requires an initrd to be created and
loaded by GRUB.
Good summary. I think one of the issues that occured is that the kernel on the
USB stick did not have all the drivers to be able to recognize all the drives
that the host had recognized (sorry for English, hope it is clear
nevertheless). So the host kernel was seeing the USB drive as /dev/sde, while
the lfs kernel could see it as /dev/sdd.
I had not thought of grub seeing the drive it sits on as hd0... That makes
sense.
Pierre
I'd love to report some other *trivial* bugs while building LFS:
1.
http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++.html
../libstdc++-v3/configure \ --host=$LFS_TGT \ --prefix=/tools \
--disable-multilib \ --disable-nls \ --disable-libstdcxx-threads \
--disable-libstdcxx-pch \
--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/8.3.0
should be
../configure \
--host=$LFS_TGT \
--prefix=/tools \
--disable-multilib \
--disable-nls \
--disable-libstdcxx-threads \
--disable-libstdcxx-pch \
--with-gxx-include-dir=/tools/$LFS_TGT/include/c++/8.3.0
Hmm, that's not trivial... There are many configure scripts in the GCC
build tree... The one we want is in the libstdc++-v3 directory, since we
only want to build that part. If you use just ../configure, you have to
do all the same preparation as was done for gcc-pass1, and the whole GCC
will be recompiled, which is not what we want. If you have done that, it
may explain why gcc-pass2 failed.
2.
http://www.linuxfromscratch.org/lfs/view/development/chapter05/binutils-pass2.html
CC=$LFS_TGT-gcc \ AR=$LFS_TGT-ar \ RANLIB=$LFS_TGT-ranlib \
../configure \ --prefix=/tools \ --disable-nls \ --disable-werror \
--with-lib-path=/tools/lib \ --with-sysroot
better separate into two parts:
CC=$LFS_TGT-gcc \ AR=$LFS_TGT-ar \ RANLIB=$LFS_TGT-ranlib
and
../configure \ --prefix=/tools \ --disable-nls \ --disable-werror \
--with-lib-path=/tools/lib \ --with-sysroot
Otherwise, I met some problem as
https://www.linuxquestions.org/questions/linux-from-scratch-13/ch-5-9-binutils-pass-2-error-cannot-run-c-compiled-programs-807747/
Separate it is not the same, unless you add "export CC AR RANLIB" (even
then, it's not exactly the same, see 3a). try:
1) EXAMPLEVAR=example bash -c 'echo $EXAMPLEVAR'
1a) EXAMPLEVAR=example bash -c 'echo $EXAMPLEVAR'; echo $EXAMPLEVAR
# after 1), EXAMPLEVAR is not set in the shell. It was set in the
environment
# of the command "bash -c 'echo $EXAMPLEVAR'"
2) EXAMPLEVAR=example; bash -c 'echo $EXAMPLEVAR'
2a) EXAMPLEVAR=example; bash -c 'echo $EXAMPLEVAR'; echo $EXAMPLEVAR
# after 2), EXAMPLEVAR is set in the shell, but not in the environment
of any command run from the shell
3) EXAMPLEVAR=example; export EXAMPLEVAR; bash -c 'echo $EXAMPLEVAR'
3a) EXAMPLEVAR=example; export EXAMPLEVAR; bash -c 'echo $EXAMPLEVAR';
echo $EXAMPLEVAR
# after 3), EXAMPLEVAR is set in the shell, and also in the environment
of any command run from the shell
We want CC, AR RANLIB to be set during the configure phase, but not in
the shell or the environment after that. That's why
we need to have them in the same command as configure (configuration 1).
I think that what happened was that you run a wrong command for
configuring libstdc++, that it destroyed gcc-pass1, and that explains
why you could not use the correct variables for gcc-pass2. As of what to
do now, the safest would be to restart from chapter 5. Sooner or later,
you'll get some error coming from the fact that the host libraries
leaked into lfs.
Pierre
--
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
