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.
Yes, the initrd was where I screwed up the most, though for completeness sake, I screwed every part up more than once! Ha. Glad we were able to get it working, now I'm off to the office to have a little fun!
What does mkinitrd do exactly and where exactly do you execute this line of code? Is this what is necessary for the /boot/initrd.gz file to be created? Is this really necessary? What does the initrd.gz file do? I checked in the /boot/ folder for the initrd.gz file and the file doesnt exist, seems it has to be created manually with the command you gave.
Basically (very basically), the _huge_ kernel does not need an 'initrd', the _generic_ kernel does.
'initrd' is supposed to load modules that are required for the boot to succeed (eg. if you have some exotic fs as the rootfs, then, if that is not supported in the 'huge' kernel, you need an 'initrd' loading that particular module first)
As for what an initrd should contain, I can only point to Alien's excellent /usr/share/mkinitrd/mkinitrd_command_generator.sh which, when run, will give you the modules needed to generate an appropriate initrd
yup - it _was_ marked as solved. Then I referred to it in another topic by 'dumdadum' and he posted the question(s) above my last answer, so I thought it just proper to answer him. Guess I should mark the thread as 'truly solved' *chuckles*
All I wish to say is that by default, you need to declare /dev/sda1 as a minimum before using the OS on the usbkey being on device /dev/sdbX.
That is _wrong_ - well, kindof ...
If you want it to be 'sdbX', yes, then you must have a 'sda' somewhere.
My point - and the way I am using it - is that grub so easily lets me change the 'sdb3' to sda3, sdc3, sdd3, etc etc
If you have no idea about how many disks are in the computer, then it will fail at loading the root filesystem, but ... it will tell you which partitions are available, so you can recycle power and then change to the correct sdX3 on the next boot.
However, by grafting a proper initrd (like damgard did), then you can have persistent naming, ie you can use root=UUID=... (this goes for both lilo and grub). _My_ problem with persistence is that making an initrd will be valied for that _particular_ computer only (though most of the required modules are generic (as such) and not really hardware dependent) which is why I choose to change the boot=/dev/sdX3 at boot-time.
Hope this makes sense ...