Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
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.
I have a 64 bit amd system that I am playing with very heavily. I only rebuilt this version of it 2 days ago. The motherboard has built in raid0 and raid1. There is no "real" raid controller, it is the cheap, built-in software kind. I am installing with debian testing. I used the BIOS ability to make RAID arrays, I tried all 3 possibilities, RAID0, RAID1, and JBOD, but no matter what, the debian installer sees the 2 seperate sata disks.
I have been installing using LVM, so that I can combine both satas into one huge space. I would prefer to let the BIOS do the RAID, freeing up resources within linux. I have just built the brand new 2.6.12-4 kernel on this system. I have read on google and here that from 2.6.11 and on, the kernel is supposed to be compatible with BIOS/software RAID. Obviosuly though, if I reboot and have the BIOS create a RAID0 array, I'll lose the 2.6.12 kernel and be sent back to the install kernel, which is 2.6.8. Is there a way to put the 2.6.12 kernel on a CD/DVD, or somehow modify the debian install.iso to include the new kernel instead of the one that is does? My goal is to get a RAID 0 array created in the software BIOS, then get debian with a current kernel installed, so that it will see the RAID0 during install.
Sorry that this might not be the best location ofr this post. Debian seems to rarely get visitors. I also simply didn't have any luck using the search tool for things like move kernel, keep kernel reinstall. Probably a terminology issue on my side. Thanks for whatever help people can give me.
Why would rebooting "lose" the new kernel? Sure, you may need to adjust a few /etc/fstab entries, but it should come up. (I am assuming that your proposed actions are not ones that would wipe-out the boot partition.)
Personally, if the "RAID is not really RAID," I wouldn't bother to use it. Linux offers software-RAID too. This feature you describe sounds like nothing more than a marketing-gimmick for the hardware salesman. If two pathways lead to essentially the same hardware-result, take the easiest one. It sounds to me like "let Debian do it" would be considerably easier at this point, and functionally equivalent in every way.
If you really want RAID, get a real RAID controller. They are not that expensive...
Rebooting by itself wouldn't do anthing to the kernel, but I want to create a raid array with the bios, which will format the drives in the process of creating the stripes. All data on both SATAs will be lost. I also don't want to buy more hardware when the newest kernel is supposed to support the RAID that is already available at no extra cost.
Okay then, I believe that the only way you'll get this done is with some kind of external drive or second-drive that you can push the data off to. Then it will be a reinstall, because you're describing a total scrub of what's on those disks now.
Por claro, the reason for my previous comment was yours that said it was, in the end, a software-RAID implementation. I was just looking for what might be the easiest-way-out... not being as familiar as you are, of course, with the actual particulars for your hardware.
I do fully agree that the BIOS version of software SATA is not that great, but I would like to keep the linux system free from such tasks as RAID, so that the full resources can always be directed at important things, like the search for ever larger prime numbers.
I do have an 80 gig usb drive, as well as a 120 gig IDE drive. That still takes me to the original question of my post - if I move the kernel onto one of the other drives, then boot into the install CD, how do I force the 2.6.12-4 kernel into the install?
I don't do RAID, especially the on-board kludge, but I have a preference for /boot always being a non-RAID partition.
Makes the boot-loader and kernel image isolated from these type of concerns.
In a little while, we'll all laugh that we had to even consider this, but for now it just makes sense.
I prefer the KISS principle - *especially* when it has the potential to affect the boot process.
in any rate, you can just burn the bzimage that you build to a cd. it is usually in /boot and called whatever you called it. or sometimes and usually vmlinuz is symlinked to it. so if you find nothing do:
ls -l /boot/vmlinuz
and just burn the image, and maybe the config you know-- in case
you might want to get the System.map that was built wiht the kernel too. up to you. then just use whatever burner tools you use on there and burn them. then on the install, i havent dont a debian in a long time, but it should ask you where your kernel is located or somehting likehtat. pop in that disc and tell it. and it should isntall it. or just let it install whatever it wants and dont reboot when all is said and done, and go in and cp the image to where it needs to be and edit lilo or grub manually. you know what they say, linux is about choices.
Thanks guys! I do have /boot in a non-raid partition. Everything else is in the LVM, but /boot is 100 MB on a standard partition on the beginning of the first SATA. I never do the bzimage step during kernels, as Debian has this great make-kpkg utility that gets the whole kernel process completed in about 4 steps, make menuconfig, make-kpkg clean, make-kpkg --with lots of tags, and dpkg -i kernel image.deb. In my non-raid boot I have these files - config-18.104.22.168-take1, initrd.img-22.214.171.124-take1, System.map-126.96.36.199-take1, and vmlinuz-188.8.131.52-take1. The symbolic links initrd and vmlinuz both point to the files from the old kernel, but a uname -r shows 184.108.40.206-take1.
I will burn all of the key files (I suppose it wouldn't hurt to bring /boot/grub and /usr/src along for the ride?) and then go through expert install, where what kernel you want to install is asked. The "standard" install in Debian testing doesn't ask, but that should be asked in expert mode. What will be interesting to see is this - the disks to install the base system on have to be detected before the kernel is installed, so will that effect things? IE if I use the same installer, even if I get it to install the newest kernel, the disks have to be detected prior to the kernel installation, no?
With the setup you have JimBass, I don't know why the hell you are fretting so much.
Have a look at menu.lst (grub.conf maybe, don't know what Debian uses), and see what the kernel name that is loaded is - must be your new one.
The kernel folks are smarter than all the rest of us. Given you are loading the kernel you want, the kernel will find the correct .conf and System.map based on the kernel name, provided you have them sensibly named, and in a sensible location. Seems you do.
Grub stage1 (in the MBR) knows where the later stage files are (by relative sector count), and will find everything o.k. so long as you don't go screwing with (especially don't move) the /boot partition. So long as you have the kernel (and initrd in your case) in the /boot, all will be found and loaded as you need them.