SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Starting with 144, udev looks in /lib/firmware/$(uname -r) and then /lib/firmware. So there is a very clean way to install the correct firmware without colliding with the Slackware package.
Ahh, I see. That's an interesting approach for those who want to leave /lib/firmware as shipped by Pat. Thanks for the tip.
I'm not really familiar with how firmware gets loaded and I didn't realise it was udev that does it - I always assumed it was the kernel itself - which has now left me wondering how systems without udev manage to do it. Might have to look into this.
Distribution: Ubuntu variants (ubuntu/Mythbuntu) and Windows Home Server/Windows 7
I have a newbie question (or stupid, if you want to be honest about it). On another tutorial, the person has you move vmlinuz to the /boot directory instead of bzImage. What's the difference between the two files? What I mean is in this tutorial, you have
cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux3.3-rc6, and in the other tutorial (he's compiling the 3.0 kernel), he has mv /boot/vmlinuz /boot/vmlinuz-3.0.0 I realize that he messed up and moved his 220.127.116.11 kernel to the 3.0 kernel's image. My point is that he's moving the vmlinuz file instead of the bzImage file.
P.S. On a side note, I'm thinking that I can fix my issue with his compilation by moving the appropriate files (/usr/src/arch/x86/boot/bzImage and /usr/src/arch/x86/boot/System.map to the /boot directory).
Well, the link that I used the first time (with the typo) was the first tutorial that I found yesterday. I didn't realize that it had a typo until I found this thread today. Right now, I'm using the original poster's tutorial (converted into a shell script), and I'll see what happens. It's all in a virtual machine, so if I mess up, I'm not out anything major.
From Alien Bob's tutorial, I got my answer. bzImage is compressed, and vmlinuz is uncompressed. But, they are both the same file essentially.
So, I have another question (or two). I'm making my kernel in /root/kernel352/ (as it's the 3.5.2 version). If I need to get to the source code, do I have to point to that location, or will it automatically point there? And, if I wanted to copy the sources over to /usr/src after I'm done, what's the best way to do it? I'm figuring it's either run make mrproper in the kernel352/linux-3.5.2 directory (as I only want the source code), and copy the directory over to /usr/src, or copy the .tar file over to /usr/src and untar it there.
For preparing kernel sources for permanent storage you should issue `make clean`, not `make mrproper` (see `make help` in the kernel source directory for information). If you want to move kernel sources, you can just move them -- but you will have to correct the symlinks (build and source) in /lib/modules/`uname -r`/, which should point to the top directory of the kernel sources. This allows you to build as a normal user in a home directory, for example, with the ability to relocate the sources to a proper system directory (/usr/src/linux-`uname -r`). I don't run any kernel commands as root (I build as a user and install as a user, passing DESTDIR and INSTALL_MOD_PATH where needed [again, see `make help`] and then chown/package the result as root). However, the best kernel guide remains Alien Bob's, so unless you understand what you're doing and what each command does, it is probably easier to build as root as suggested by Alien Bob.
Distribution: Ubuntu variants (ubuntu/Mythbuntu) and Windows Home Server/Windows 7
Originally Posted by Didier Spaier
I won't elaborate, but you should better follow Alien Bob's tutorial.
And remember that if you apply a guide blindly (i.e., not understanding what is the purpose and will be the effect of each and every proposed command), sooner or later expect troubles.
Totally understandable and agreed (about the not understanding the purpose and effect of each command). The only reason I ask about the copying of the sources is because depending on what tutorial you follow, they tell you to either do everything from /usr/src, or don't do anything from /usr/src. In my case, I'm going to be doing driver development (specifically one driver for a Pinnacle PCTV 80e TV Tuner), and it requires me to recompile the kernel. In doing that, from my understanding (from the linuxtv project's wiki), I need to have the kernel sources and headers available to me. So, my question still stands: Do I need to point to the location of the sources, if I don't compile them in /usr/src, or should I copy them over there? And, if I should copy them over, would it have the same effect if I copy the tar.bz2 file over and untar it, or do I need the compiled files as well (understanding that "make" compiles the source code, and creates .o files)?
All of this is also why I'm doing this in a virtual machine. Until I get everything perfected (including the understanding of what I'm doing), I don't want to trash my computer. Once I've perfected it, I'll do everything on a live system, so I can verify that everything really works (going on the theory that something might work on a virtual machine, but not in a live system--and vice versa). It's also why I'm stepping out of my comfort zone, and using Slackware. If I wanted to do this in Ubuntu (which is my distribution of choice), I'd have to jump through hoops just to get the kernel to boot. And if I wanted to do it in a Linux From Scratch system, I'd have to learn how to resolve circular dependencies and a whole bunch of other issues, just to get the base system ready for the development--let alone what I'd have to do each time I tried to compile a new kernel.
Anyhow, thanks for any information that you do provide me. And have a great day.
Distribution: Slint64-14.2beta2 on Lenovo Thinkpad W520
To do driver development you will among other things need to know how-to:
0) Use the linux commands (see http://tldp.org)
1) Program in the C language
2) Use Makefiles to compile, link and install C programs
3) Find you way in the kernel source tree and insert your driver in it (to begin with, read the Makefile at the root of the kernel source tree)
That needs a lot of reading and doing exercises, certainly not limited to reading and following one page tutorials.
Other than that, as you are using Slackware, again take the time to read Alien BOB's tutorial as it is adapted to Slackware.
Whether you should put the kernel source in /usr/src or elsewhere to experiment, that doesn't matter at all for Slackware are explained by Alien Bob in his tutorial.
All you have to know is that you should issue the "make" command from the root of the kernel source tree, wherever it be. "man make" to know more, and "make help" when at the root of the kernel source tree to know all the options to configure and compile the kernel.