I found an old 4GB ipod mini that hadn't been used for so long, that it had a Belinda Carlisle playlist on it. Formatted that bastard good and quick I can tell you.
I tried to set up the partition on it using the command line 'fdisk' program. Yeah, that was a fucking disaster. So I fired up the GUI program gparted instead. I deleted all the partitions on the drive and made a new, bootable, ext2 partition. We'll properly configure this below.
I then tested the disk to see if it is bootable. No it fucking isn't. In fact is is so unbootable, that when you choose to boot from it on the usual BIOS screen, it spews garbage ascii characters onto the screen. I have tried to boot loads of disks and this is pretty much the most non-bootable thing I have ever seen.
Right. I am now back from the shops with a brand new 8GB USB Key. It came with a FAT32 partition. I removed that and replaced it with another bootable ext2 partition.
Now to format the partition. I know it is sdb1 because I noted it when using gparted. If you are unsure, or suddenly affected by crippling self doubt and uncertainty, run this command to print out the details of all drives and partitions to double check:
sudo fdisk -l
Now you have double checked, you can format the drive as follows:
mke2fs -jv -L amiga /dev/sdb1
This command [m]a[ke]s a ext[2] [f]ile[s]ystem with [j]ournaling, which is actually what an ext3 filesystem is. The additional [v] option tells the command to act [v]erbosely, or in other words to report as much information as possible about how the command is executed. This is a common option, so assume that any [v] in subsequent commands is for verbose output unless I say otherwise. It also gives the new partition the [L]abel [amiga]. This is useful because it lets us refer to that partition directly without having to know exactly what device id [sd{a-d}] it has been allocated.
mke2fs: Permission denied while trying to determine filesystem size
Right. I had hoped that using a LiveCD may have stopped all this permissions bullshit, but apparently not. I will just prefix all my commands with 'sudo' to get them to work.
sudo mke2fs -jv -L amiga /dev/sdb1
Job done. Lets make a mount point:
sudo mkdir -pv /media/lfs
The [p] option tells the command to make the [p]arent /media/ directory if it didn't exist.
sudo mount -v -t ext3 /dev/disk/by-label/amiga /media/lfs
This command, unsurprisingly [mount]s the [/dev/disk/by-label/amiga] partition (of [t]ype [ext3] to the [media/lfs] point which we just created.
Now lets make a directory to store the source code we have downloaded:
sudo mkdir -v /media/lfs/sources
And, lets change the fucking permissions nonsense:
sudo chmod -v a+wt /media/lfs/sources
This [ch]anges the [mod]e of the [/media/lfs/sources] directory by [+]adding the permission for [a]ll users to [w]rite to the directory. It also sets a s[t]icky bit. I have no idea what that is, but it sounds funny. Now let's uncompress the sources package that we downloaded in the last step.
cd /media/lfs/sources tar -xf /cdrom/lfs-packages-6.6.tar cd lfs-6.6-sources mv *.* ../ cd .. rm -rvf lfs-6.6-sources
What happens here is that the .tar file gets unpacked to its own directory. We do not want it that so we [c]hange into the [d]irectory and then [m]o[v]e all [*.*] the files in it down one directory step [../]. We then follow them and delete the now empty directory.
We also need a directory to install the Toolchain that we talked about previously.
sudo mkdir -v /media/lfs/tools
Now, we are going to be compiling the toolchain using the host system. We want all our programs to think that they are being installed to the directory /tools. This is so that when we 'chroot' into the /media/lfs directory in the fullness of time, the programs will appear in /tools. But the tools directory we have just made is /media/lfs/tools – how do we make that appear to be /tools? Simple – we make a [s]ymbolic [l]i[n]k to that directory in the root directory [/]:
sudo ln -sv /media/lfs/tools /
The report from that command is worth looking at, because it confirms what we have done quite well:
`/tools' -> `/media/lfs/tools'
So /tools is now actually /media/lfs/tools. Anything we install to /tools will actually appear in /media/lfs/tools. Ideal. Now, to avoid breaking our current running OS it is a good idea to do the tricky stuff with a temporary user account. Every user in Linux needs to be a member of a group. Create a group with the simple command:
sudo groupadd lfs
Now we add a user with the following command:
sudo useradd -s /bin/bash -g lfs -m -k /dev/null lfs
This [add]s a [user] [lfs] which is the member of the [g]roup [lfs] that we just created. The user uses the [/bin/bash] program as its [s]hell. The [m] option creates a home directory in /home and the [k] option tells the command to copy common user configuration files from the [/dev/null] directory. /dev/null is always empty (if you move something to /dev/null it is like deleting it) so this effectively makes sure that NO configuration files are copied for this new user.
To avoid the permissions bullshit, make the lfs user the owner of the install directories that we just made:
sudo chown -v lfs /media/lfs/tools sudo chown -v lfs /media/lfs/sources
This just [ch]anges the [own]er of the directories specified to [lfs].
Now, set a password for the new user:
sudo passwd lfs
I chose 'lfs' as the password, just to keep things simple
Finally, to get this build going, login as the lfs user:
su - lfs
It will ask you for the password, put in the one you just specified. I now need to configure the new user properly. Remember the files that we didn't get from /dev/null? Well we do need them now. First of all we make a .bash_profile file:
cat > ~/.bash_profile << "EOF" exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF
The idea with a command like that is that you paste all three lines into the terminal in one go. The command con[cat]enates the lines which follow and puts [>] them into the [~/.bash_profile] file. If you wanted to add the lines to the end of the file instead of overwriting it you would use [>>]. The [<<] bit tells the command to keep adding lines until it comes across a line which matches the text in quotes. Here it is “EOF” which stands for End Of File. It could just as well be ARSE though, as long as that pattern appears below.
A file which starts with a . ends up as a hidden file. It will not show up in directory listings unless you ask for hidden files as well. The next line is the text which is going to end up in that file. When the file is processed this line [exec]utes the [/bin/bash] shell with certain [env]ironmental variables set. The [i] option tells it to start with a blank environment. The [$] before a word means that it is the variable in question. So [HOME=$HOME] sets the home variable to whatever it was in the first place. The same applies to [TERM=$TERM]. [PS1='\u:\w\$ '] configures the prompt – which is the text that appears before the flashing cursor. It means print the logged in user, then a colon, then the current directory, then a dollar sign, and finally a space before the flashing prompt, hence: lfs@ubuntu:~$. Obviously the next line is the EOF line that the [cat] command has been waiting for,
When the /bin/bash command is run by the .bash_profile file it reads the .bashrc file. So we had better create it:
cat > ~/.bashrc << "EOF" set +h umask 022 LFS=/media/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu CORES_TO_USE=-j2 PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL LFS_TGT PATH CORES_TO_USE EOF
This is essentially the same command as we just ran, but for a different file, and with different contents. The [set +h] command turns off a feature of the bash program. Ordinarily bash remembers where it found executable files so it does not have to check the PATH every time you run a file. Usually this is handy and speeds up execution. Because we will be creating program files when we build the toolchain, which we want to use immediately, this feature gets in the way. We actually want bash to check the PATH every time to see if it can use one of our files yet, instead of the programs that are on the Ubuntu LiveCD.
The [u]ser [mask] command sets the default binary bullshit permissions crap that will be applied to every new file created by the lfs user. The next line sets a special variable called [LFS] which is set to be [/media/lfs] which is of course where we mounted the USB Key.
According to the LFS book, the [LC_ALL=POSIX] command is something to do with localisation. Which, in my head, means that programs speak in an american accent or a british accent. I have no idea what a POSIX accent sounds like though, so I might be entirely wrong. I am just going to leave this as is.
The next command [LFS_TGT=$(uname -m)-lfs-linux-gnu] sets another variable. This is going to be used in compiling some programs. This is all a bit complicated and is best left alone. The [uname -m] bit turns into 'i686' when I run it on my PCs.
The [PATH=/tools/bin:/bin:/usr/bin] just sets the PATH variable. Note that the first place to look for programs is in the /tools directory.
The CORES_TO_USE sets a variable that we will use when [make]ing packages. This tells the system how many cores in your machine to use for the compilation. To use both of the virtual cores on my celeron I have set this to [2]. If I was using a single core system I would leave it blank. For my four core i5-750, I set this to [4]. The idea is that you just need to change this setting when setting up the LFS user, and it will be used for all packages.
The last line in the file [export]s the variables we just set, so that they are available after the script has run, NOT just while the script is running.
Finally, before actually building anything, lets process the two files we just made:
source ~/.bash_profile
We only have to run this one, because as I said, when that script runs the /bin/bash command it automatically runs the .bashrc script.
What I am also going to do is to use the /tmp directory unpack the build the various files. Why am I going to do this? Well when booted from the Live Key, the whole filesystem is held in ram, so the /tmp folder turns into a ramdisk. Clever. I have tested this on machines with both 4Gb and 2Gb of ram and it works fine. Less than that, it may run out of space, in which case you would need to build on the Amiga Key itself. To do that, just use ...
cd $LFS/sources
... instead of ...
cd /tmp
... at the beginning of the Toolchain build. When we are using the toolchain to do the actual build, this will be a bit trickier because the [chroot] command (more of which later) means that we cannot see the /tmp directory on the Live Key when we use it. Lets cross that bridge when we come to it.
Warning - because it is a Ramdisk you will lose anything in it when you power off. Remember you can use the Amiga Key instead if it doesn't work from /tmp.
If you have powered off and want to resume the install, the first thing that you need to do is to reconfigure your Live environment. Do that by running the following selection of the above commands:
umount -v /media/amiga sudo mkdir /media/lfs sudo mount -v -t ext3 /dev/disk/by-label/amiga /media/lfs sudo ln -sv /media/lfs/tools / sudo groupadd lfs sudo useradd -s /bin/bash -g lfs -m -k /dev/null lfs sudo chown -v lfs /media/lfs/tools sudo chown -v lfs /media/lfs/sources sudo passwd lfs
Set the password, I would use lfs again, and log in:
su - lfs
Enter the password.
cat > ~/.bash_profile << "EOF" exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash EOF cat > ~/.bashrc << "EOF" set +h umask 022 LFS=/media/lfs LC_ALL=POSIX LFS_TGT=$(uname -m)-lfs-linux-gnu CORES_TO_USE=-j2 PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL LFS_TGT PATH CORES_TO_USE EOF source ~/.bash_profile
No comments:
Post a Comment