The next part of LFS Ch. 4.2, creating a limited directory layout.
Descent into Hell
The manual says: As root,
for i in in lib sbin; do ln -sv usr/$i $LFS/$i done
Google AI Mode explained that the “usr” in this code is relative to $LFS and therefore will be in $LFS and not in the host machine root.
I had made one print-out from Google AI Mode that did explain what to do but since I didn’t understand it I didn’t use it and in fact misplaced it. Instead I tried various ways.
sudo for i in bin lib sbin; do ln -sv usr/$i $LFS/$i done
The typical error message (among others) is:
bash: syntax error near unexpected token 'do'
OK. Googling all this, the consensus seemed to be that “sudo” and “for” interfere with each other.
The first thing that actually worked was:
sudo bash -c 'for i in bin lib sbin; do ln -sv usr/$i $LFS/$i done'
which I did somehow get onto three lines.
However, it made symlinks on the host machine, which I can see with ls:
/bin/bin -> usr/bin
/lib/lib -> usr/lib
/sbin/sbin -> usr/sbin
I ran crying to Google AI Mode. It confirmed that these were made on the host machine. It said that they did not overwrite anything but however could confuse the host system at a later date.
The first thing I did was remove them. AI Mode suggested unlink as safer than rm:
sudo unlink /bin/bin
sudo unlink /lib/lib
sudo unlink /sbin/sbin
Then as far as actually carrying out the for loop from Hell, Google AI Mode explained [as it had previously in the misplaced print-out] how LFS had to be defined within the command:
sudo bash -c 'LFS="/mnt/lfs"; for i in bin lib sbin; do ln -sv usr/$i $LFS/$i; done'
When I did that, this created the symlinks
/mnt/lfs/bin -> usr/bin
/mnt/lfs/lib -> usr/lib
/mnt/lfs/sbin -> usr/sbin
My documentation has some quote marks in it, I’m not really sure what the exact output was.
I verified that everything was where it were supposed to be:
ls -al $LFS
As I post this I am concerned again that “usr” really is relative to LFS and feel like I should check this out.
More directories
I was not very interested in struggling with the next line of code in the manual:
case $(uname -m) in x86_64) mkdir -pv $LFS/lib64 ;; esac
This Reddit post https://www.reddit.com/r/linuxfromscratch/comments/1cxksbr/stuck_at_chapter_42/
had a comment suggesting to simply confirm that the PC is x86_64 and then make the $LFS/lib64 directory, so that’s what I did.
uname -m
x86_64
sudo mkdir -pv $LFS/lib64
Then from the manual:
sudo mkdir -pv $LFS/tools
Verifying
ls $LFS shows these directories:
bin – shown in cyan – symlink
etc – shown in blue – directory
lib – shown in cyan – symlink
lib64 – shown in blue – directory
lost+found – shown in blue – directory
sbin – shown in cyan – symlink
sources – shown in blue with green highlighting – directory that is world writable
tools – shown in blue – directory
usr – shown in blue – directory
var – shown in blue – directory
The lost+found was made by GParted when it made the partition. Google AI Mode says that it is ok to be there, will not interfere with LFS, and is in fact necessary as it is used for data recovery. It was created by ext4 filesystem.
Note
Note from manual: I am supposed to make sure there is never a /usr/lib64 directory.
Danger, Will Robinson
Edit –
Descent into Hell: The first issue here was trying to use “sudo” instead of “sudo su -” . I needed to be root as a login shell.
The commands in LFS/BLFS book does not work with sudo!
sudo can only run executables as root. It does not understand internal grammar constructs of the shell, for example “case”, “cd”, “for”, “if”, “|” (piping), “>” (redirecting output to a file), etc.
For example, when the book tells to run echo /bin/zsh >> /etc/shells as the root user, you cannot run sudo echo /bin/zsh >> /etc/shells as a non-root user and expect it to work. The output redirection is performed by the shell, so the shell needs to open /etc/shells for write and doing so requires a privilege. But sudo has no way to raise the privilege for the current shell. It can only raise the privilege for the echo command with /bin/zsh as the parameter, but this is not helpful at all.
For another example, when the book tells to run for i in /usr/lib/libfoo*.so; do chmod 755 $i; done, you cannot prepend sudo before the command and run it as a non-root user. for is a shell grammar construct, not an executable. So sudo will report “for: command not found”.
Permissions: Here I looked to see that the directories existed, but I didn’t look at their permissions. Screwy permissions may (or may not) be the only bad effect of “sudo” at this phase.