Sandeep_K_Shandilya@xxxxxxxx wrote:
Hello John
Well I am back, after a bout of sickness :(
:-((
I was wondering about you.
I've been using Linux for about ten years now, and I've become
accustomed to doing things a certain way. I become uncomfortable when a
vendor wants to do things differently, and I really do not like
phone-home software.
<sandeep>
There are lots of people who call Dell asking for drivers when they fail
to install an OS and anaconds says no harddisks found when it does not
find the drivers for disk controllers. The two approaches we could take
to fix this
1. The method we are discussing in this email
2. get the driver into a future update of the OS( we are already doing
this), we still need 1 to take care of the problem currently.
Surely, if you certify for RHEL5.1 (substitute any vendor's release)
this problem will not happen on RHEL5.1.
Surely, if your driver's in the official kernel, it won't happen on any
system, certified or not. If I boot Knoppix, or the systemrescue CD, or
systemimager, it will just work.
I bought a new computer yesterday, it's not a Dell. I know that if I try
to install the latest Fedora beta on it, that it will not find my disks.
I know this because I have another from the same series of models and no
2.6.25 kernel finds its disks though 2.6.24 kernels are fine.
Your solution would not help one bit, it would make things worse.
In the present circumstances I get to kick and scream and generally
misbehave at the Fedora project. The most I need to worry about (apart
from whether it actually gets fixed) is that it remains filed against
the right component.
If the driver was stashed away in some secret spot, then I'd also need
to throw my tantrams at the hardware vendor and face the likely consequence
a <== it's their fault ===> b
This a
method to solve a problem that customers have.
To further clarify things in my mind, I went to Dell.au's website and
chose a server we might conceivably buy where I work. I settled on a
Poweredge R300.
Then I went to the support page and found me a download for RHEL5. I'm
actually running Scientfic Linux 5 on my desktop, so it's a fair
comparison. I figure that what I find on the website's probably about
what I'd be getting from Dell for that system.
I then tried to investigate the package's contents. It was tricky, my
enquiries were about this successful.
09:16 [summer@numbat ~]$ rpm -qp
downloads/sg-3\[1\].5.34dell-1dkms.noarch.rpm --scripts
09:16 [summer@numbat ~]$
That is, no output. So I tried to test installing it:
09:16 [summer@numbat ~]$ sudo rpm -i --test
downloads/sg-3\[1\].5.34dell-1dkms.noarch.rpm
Password:
error: File not found by glob:
downloads/sg-3[1].5.34dell-1dkms.noarch.rpm
09:18 [summer@numbat ~]$
Okay, a bug in rpm. I did better when I renamed the file:
09:19 [summer@numbat ~]$ rpm -qlip sg.rpm
Name : sg Relocations: (not
relocatable)
Version : 3.5.34dell Vendor: (none)
Release : 1dkms Build Date: Wed Jun 13
23:40:10 2007
Install Date: (not installed) Build Host: berlin-4-hem
Group : System/Kernel Source RPM:
sg-3.5.34dell-1dkms.src.rpm
Size : 84574 License: Unknown
Signature : (none)
Packager : DKMS <dkms-devel@xxxxxxxxxxxxxxxxx>
Summary : sg 3.5.34dell dkms package
Description :
Kernel modules for sg 3.5.34dell in a DKMS wrapper.
/usr/src/sg-3.5.34dell
/usr/src/sg-3.5.34dell/sg-3.5.34dell-mktarball.dkms.tgz
09:19 [summer@numbat ~]$
So if I understand you correctly, this is pretty much what you'd be
putting in the driver storage.
I unpacked the rpm using rpm2cpio and find both a prebuilt kernel
module, and what looks to be the source to recreate it.
In this case we have a standard GPL-licenced Linux driver, with a
one-line Dell patch.
I suppose the system was certified at RHEL5.0. If it worked with RHEL5.0
then I don't see the need for RHEL5.0 drivers in usb-storage, unless RH
declined to accept the patch, so I suppose that it was certified with
this patch in place and that I'd need it to install RHEL5.0 and maybe
CentOS5.0 and SL5.0.
Supposing my suppositions are all well-founded, then it would be good to
have the driver in USB storage, I'm very good at losing CDs, and even
without that skill, where I work most of our computers are three years
old before we get them (but then, in such a case, it would be reasonable
to expect not to need the Dell driver).
I'm still not keen on the idea of DKMS, it'd rather not be expected to
maintain a C compiler on a server.
< sandeep >
We have binary versions for the drivers too then you will not need the C
compilers on the server.
The new computer I mentioned a few minutes ago won't be running Fedora,
but I have one like it that does.
Do you track each new Fedora kernel?
What about each new Rawhide kernel?
Or even each new Fedora/Rawhide install image.
Let's assume I buy a Dell system; sales have been a bit sluggish and I
get a good deal because the system's a bit old, maybe it's previous to
the current model. It might be certified for RHEL5.0, but what if I want
to install RHEL 5.2 on it?
This is all solved if the source is in the official kernel.
One of the things I prefer about Windows is that a driver for Windows XP
most likely works for all releases of Windows XP. But, I don't suppose
Linus and the others will change on my account.
I would prefer a yum repo at Dell, together with instructions for
pinning so one gets only the Dell bits from Dell, but getting the
updates from RH etc would be even better.
<sandeep>
That's a good idea for distributing drivers for hardware, it will work
good for system already installed or partially installed and on the
network. but what about the scenario when you will need a driver to
recognise the new hardware (disk controller or NIC) to install the OS?
It would provide an easy-to-find place to look, maybe you could host all
your repost at linux.dell.com where people could find the drivers for
their favourite hardware.
It would be near perfect for any utility software Dell provides.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
