SCIENTIFIC-LINUX-USERS Archives

December 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Tue, 13 Dec 2011 10:48:18 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (38 lines)
On Tue, Dec 13, 2011 at 01:11:58PM -0500, Jolynn Schmidt wrote:
> 
> I am currently in a situation where I am testing a piece of hardware that
> is experimental and not currently support by any SL version, or upstream
> linux version for what it is worth.  The manufacture has sent me a cd with
> the driver but given that it is a disk controller I have a bit of a chicken
> and egg problem.  This seems to be a common theme for me, it seems that I
> often find myself in this situation and would like to just roll my own
> version of the kernel and initrd that I can use during PXE so I can add
> drivers as needed.  Is there a good document on this process?  It seems
> like the last time I tried this there were issues around md5 check sums.
> 


Hmm... but you did not describe your problem? I think I understand
what you are doing and all of it should work just fine with SL6 (it works
just fine with SL5 and SL4):

- booting the SL kernels using PXE, with NFS-Root or without
- adding custom drivers to the initrd booted by PXE
- booting SL userland using custom Linux kernels, booted from PXE or local disk.

If you have an experimental disk controller that you want to eventually boot
from, I would suggest that you boot using PXE and NFS-Root, fiddle with
your driver until it works. *then* you can go back to trying to add
it to the initrd (so the the disks on this controller are visible at boot
time), trying to mount the "/" partition from this disk, and very last,
try to boot the linux kernel from it.

What exactly are you doing that does not work?


-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2