Getting a hold of all the source packages is tricky. The server beach mirror has everything in the same place, and as a result is very very useful.
The trio of glibc, gcc and binutils is at the core of Linux from Scratch. They also take the most time to get up and running in both the tool chain build and the actual build. Well, aside for the test suites for the auto* packages. They also take most resources to compile and, presumably, install.
Getting the fucking thing to boot is really tricky. Kernel configuration is an expert level task, but the online resources are very useful if you can wade your way through them. It would be very useful if the book could highlight some common problems, and how to solve them. The interaction between /etc/fstab, grub, and the kernel is not clearly explained, and it could be. The treatment of Grub 1.97 in LFS6.6 in particular is pretty shoddy.
The next tricky bit was the installation of X. It is almost like doing the tool chain all over again. It involves multiple packages, and you have to keep your wits about you. I was able to go though it with NVidia and Intel graphics, but I haven't tried it with ATI hardware yet. Switching from Nvidia to Intel should, I feel, be easier than uninstalling and reinstalling the driver every fecking time, but it is the only way I could get it to work. The problem is that the Nvidia driver swans about this place like lord of the manor and deletes all the DRI files that the Intel driver needs.
As for the other hardware, networking is a hit or a miss depending on your card. I tried three different network cards and the results were:
Linksys WMP54GS (Broadcom 4306) - kernel driver worked fine, but needed (non-free) firmware to be obtained independently.
Abit Airpace (Atheros) - an absolute doddle - works as soon as the Atheros options are enabled in the kernel configuration.
Compaq Mini built in (Broadcom 43XX - not sure exactly) - bastard hard. You have to download and compile a stand alone module for the kernel AND disable the existing broadcom drivers before this will work.
Audio was actually a piece of piss. Just make sure you enable the correct drivers in the Kernel configuration, and then install alsa. That, literally, is all there is to it. I am aware, like some native tribesman seeing fighter planes pass high over head, that there is a whole world of fucking hurt out there that I know very, very, little about. In my case, that world is called pulseaudio.
When it comes to the LFS build most things are very well explained. One exception is static and dynamic libraries. I still have only a very sketchy idea what the difference is and what they do. A strong point behind doing a LFS build is to learn how this stuff works, but I am still in the dark.
Also, the sed stuff is a bit of a nightmare. Clearly it is doing something, but it is far from clear, and intuitive, how it is doing what it is doing. Given how prevalent sed is in the build, it would be useful if LFS could give an explanation, or even link to one, about how it fucking works. In a similar, but far less prevalent, vein not all of the patches that are applied are fully explained.
Dependency resolution is a bitch. This is why more user friendly distributions are use friendly! You can just type:
apt-get install libgtk2.0-0
in ubuntu. Sorry:
sudo apt-get install libgtk2.0-0
and it will go and get all the dependencies for you. With LFS, or BLFS you need to read through screeds and screeds of material to find out exactly what packages you need to be able to build gtk, then find them on the internet. THEN find which packages you need to build those ones, etc etc. Then you need to install them all in the right order. It is a bit of a trial. It's a shame that BLFS couldn't maintain a search able database of dependency information on the website. You could then type in the package you wanted to install and it would come back with all the dependencies you would need on top of LFS to get your package to work. It would be AWESOME if the search could auto generate a .wget file with links to all the source code for the dependencies as well. I mean, all of this information is in BLFS anyway - it is just a matter of managing it properly.
I also learned a couple of useful tweaks to the standard LFS instructions which dramatically improve performance. Setting the variable CORES_TO_USE to either -j2 or -j4 made switching the build between my hyperthreading CPU and my Quad Core very easy. Also, using a ramdisk as the working area to unpack archives and compile the software really sped things up - its just a shame that GCC needs a machine with more than 2Gb of RAM to compile in that scenario.
In terms of e-uae, I was actually pleasantly surprised. Other than needing to install GTK to get the GUI and SDL to get fullscreen graphics, it mostly worked fine. I am still not entirely sure what SDL is, but is seems to work.
The Amiga software itself was interesting. The Green Amiga Alien's guides were essential. The only massive problem I encountered was the case sensitive rom file to enable the harddisk, and that was easily solved by just reading the fucking error messages. The documentation for installing the IPF support was woeful, but trial and error got it to work.
In summary, when I started this project a couple of months ago, I had absolutely no idea if it would work. By and large, however, it has. The base system that I have managed to build is one that is a very flexible base. I have chosen to stick an Amiga emulator on top of the install, but you could just as easily stick a desktop environment and an office suite, creating a system that you could actually use for day to day tasks.
No comments:
Post a Comment