Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yep, our hardware is pretty much the same. I saw your other post on video troubles, too, but you left it at "I guess I will try a modeline generator.", and when I went to try a modeline generator it worked easily, so I figured you succeeded as well. Check out http://xtiming.sourceforge.net/cgi-bin/xtiming.pl After getting a modeline from this site, I modified my /etc/X11/xorg.conf until it looked like this (in part):
Notice how I tweaked my VertRefresh parameter slightly, to give it a little wiggle room. It originally had 60 - 60.
After installing the latest Xorg as per http://wiki.x.org/wiki/CvsPage (so that my video card would be properly detected), it worked fine at 1680x1050.
I used the "#define ProjectRoot /opt/Xorg-cvs-050203", and then just made a symbolic link to /opt/Xorg-cvs-050203/bin/Xorg, so as not to disturb my normal installation. I have yet to get DRI working, though, so my frame rates are pathetic, but at least the 2D is snappier than with the default (1280x1024) VESA driver. I'm also *still* working on sound (PCI ID 8086:2668).
Anyhow, on to simply getting the installation to work: I've noticed that I can "Disable Smilies in This Post". I think that was what was giving me trouble in posting the gzipped, uuencoded patch. Here it is again (part 1 of 2, wish me luck):
Now, if you have a machine with a 2.6.x kernel installation, you'll likely be able to cat these two patch parts to uudecode and get a kernel-2.6.x-src.RPM.patch.gz to apply as follows when rebuilding the kernel:
Once the RPM is generated, you'll likely have to pull it apart in order to have the files necessary to create a viable bootdisk:
Code:
cd /tmp
rpm2cpio kernel-2.6.10-1.760_FC3_jbp.i586.rpm | cpio -id
You'll also need to keep the actual RPM around (something that I *didn't* originally do) so that you can install it as the default kernel once you've installed Fedora Core and are about to reboot for the first time.
Your profile says you are a newbie Twinkel, but you seem to be a little more advanced than I. I don't understand all the steps you've laid out in your posts. Here is what I've done so far:
I've used the diskboot.img image on the Fedora install disk 1 to create a boot disk to use as a base on my pen drive. I know I need to now add the drivers to the modules.cgz file, but this is where I get a little lost. Where are the drivers that I'm supposed to be adding to the modules file? I understand that I need to recompile the kernel to include the libata patch, but I don't really understand how to do this. I have recompiled kernels before, but I'm not sure how to get the libata patch included in the recompile. You talk about tweaking the kernel spec file and a few other things I don't understand. Sorry, this is all just new to me. Is there any way you could just supply the boot image you used on your pen drive and the final kernel rpm you used to install on your machine right before you rebooted? I appreciate all the info you've given, but I'm not sure I'm going to be able to figure out all the steps you've described in your posts on my own.
This process is definitely advanced. I was surprised I got through it in one piece (especially since I can't even get sound working... can you tell that's bugging me? ). Anyway, the patch I've uploaded actually performs the *.config and *.spec file tweaking, as well as drops in the portion of the libata patch that is not included. This is much preferred to performing these processes yourself, but if you wish to do it manually, here's the rundown:
When you successfully cat and uudecode the two patch segments I've provided here, you'll get a kernel-2.6.x-src.RPM.patch.gz which, if ungzipped, contains sections like the following:
Code:
diff -urN ./SOURCES/kernel-2.6.10-i586.config ../redhat.new/SOURCES/kernel-2.6.10-i586.config
--- ./SOURCES/kernel-2.6.10-i586.config 2005-02-02 00:09:58.000000000 -0500
+++ ../redhat.new/SOURCES/kernel-2.6.10-i586.config 2005-02-03 10:26:31.516096352 -0500
@@ -2636,3 +2636,5 @@
# CONFIG_SMP is not set
# CONFIG_MICROCODE is not set
# CONFIG_PROFILING is not set
+CONFIG_SCSI_ATA_ADMA=m
+CONFIG_SCSI_PATA_PDC2027X=m
diff -urN ./SOURCES/kernel-2.6.10-i586-smp.config ../redhat.new/SOURCES/kernel-2.6.10-i586-smp.config
--- ./SOURCES/kernel-2.6.10-i586-smp.config 2005-02-02 00:09:58.000000000 -0500
+++ ../redhat.new/SOURCES/kernel-2.6.10-i586-smp.config 2005-02-03 10:26:38.804988272 -0500
@@ -2634,3 +2634,5 @@
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_M586=y
# CONFIG_MICROCODE is not set
+CONFIG_SCSI_ATA_ADMA=m
+CONFIG_SCSI_PATA_PDC2027X=m
diff -urN ./SOURCES/kernel-2.6.10-i686.config ../redhat.new/SOURCES/kernel-2.6.10-i686.config
--- ./SOURCES/kernel-2.6.10-i686.config 2005-02-02 00:09:58.000000000 -0500
+++ ../redhat.new/SOURCES/kernel-2.6.10-i686.config 2005-02-03 10:26:52.440915296 -0500
@@ -2637,3 +2637,5 @@
# CONFIG_SMP is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
+CONFIG_SCSI_ATA_ADMA=m
+CONFIG_SCSI_PATA_PDC2027X=m
diff -urN ./SOURCES/kernel-2.6.10-i686-smp.config ../redhat.new/SOURCES/kernel-2.6.10-i686-smp.config
--- ./SOURCES/kernel-2.6.10-i686-smp.config 2005-02-02 00:09:58.000000000 -0500
+++ ../redhat.new/SOURCES/kernel-2.6.10-i686-smp.config 2005-02-03 10:26:46.849765280 -0500
@@ -2644,3 +2644,5 @@
CONFIG_NR_CPUS=32
# CONFIG_X86_PC is not set
CONFIG_X86_GENERICARCH=y
+CONFIG_SCSI_ATA_ADMA=m
+CONFIG_SCSI_PATA_PDC2027X=m
These diffs modify the *.config files to properly define the new configuration values (rpmbuild chokes if not all values are defined). This simply appends the same two lines to the i586 and i686 uP and SMP configs. Immediately following these hunks is the bulk of the libata patch. Then, at the bottom, is the following:
Code:
diff -urN ./SPECS/kernel-2.6.spec ../redhat.new/SPECS/kernel-2.6.spec
--- ./SPECS/kernel-2.6.spec 2005-02-01 23:56:10.000000000 -0500
+++ ../redhat.new/SPECS/kernel-2.6.spec 2005-02-03 10:25:51.409193528 -0500
@@ -22,7 +22,8 @@
%define sublevel 10
%define kversion 2.6.%{sublevel}
%define rpmversion 2.6.%{sublevel}
-%define rhbsys %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] && echo || echo .`whoami`)
+%define rhbsys _jbp
+# %([ -r /etc/beehive-root -o -n "%{?__beehive_build}" ] && echo || echo .`whoami`)
%if %{FC2}
%define release 1.11_FC2%{rhbsys}
@@ -327,6 +328,9 @@
Patch3021: linux-2.6.9-ipw2200.patch
Patch3022: linux-2.6.9-ieee80211.patch
+# libata patch
+Patch3100: linux-2.6.10-bk9-libata-dev1.patch
+
#
# 10000 to 20000 is for stuff that has to come last due to the
# amount of drivers they touch. But only these should go here.
@@ -656,6 +660,9 @@
%patch3021 -p1
%patch3022 -p1
+# libata patch
+%patch3100 -p1
+
#
# Patches 5000 to 6000 are reserved for new drivers that are about to
# be merged upstream
Hunk #1 tweaks the suffix on the generated RPM, so that I know it's not a stock RPM. Hunk #2 declares the existence and location of the libata patch parts, and hunk #3 includes it in the build procedure. When all of this succeeds, rpmbuild will generate RPMs that you can then take apart with rpm2cpio to get a directory tree which contains (in part) boot/vmlinuz-2.6.10-1.760_FC3_jbp and lib/modules/2.6.10-1.760_FC3_jbp/kernel, which contains many *.ko files in subdirectories. The vmlinuz-* is the required replacement for the vmlinuz file on the diskboot.img, and the *.ko files are the drivers that must wholly replace the files in modules.cgz. Executing:
Code:
zcat modules.cgz | cpio -id
in a writable directory will create (IIRC) a 2.6.9-1.677/i586 subdirectory containing many *.ko files. You can get a list of these files with:
Code:
(cd 2.6.9-1.677/i586; \ls) > files.txt
and then create a replacement modules tree and modules.cgz with
Of course, having said all of this, I'm happy to upload my own diskboot.img and kernel-smp-2.6.10-1.760_FC3_jbp.i686.rpm, but they are 6MB and 16MB(!) respectively, so I can't exactly post them here. I've sent mail to the email account that you posted with the following headers:
Code:
Subject: trouble with promise sata378 scsi controller
Date: Thu, 10 Feb 2005 09:11:26 -0500
Sift through all that spam and we can work something out, I'm sure.
I too have been having problems with this. I have tried many distrobutions and many files from promise. For some reason the clossest i get is mandrake recognizine my SCSI controller, but then it has issues with the intel storage bridge. I would like to put SUSE on this laptop, or even Redhat.
Is there any chance that you could send that boot disk to me? I have a gmail account so the space is not a problem.
Originally posted by BlackBic Is there any chance that you could send that boot disk to me? I have a gmail account so the space is not a problem.
I think I may still have it around. I'm not surprised that many distributions do not work properly, since the libata patch is brand new, and I don't think the pertinent parts have even been integrated into kernel 2.6.11, even.
Oh... here I've found them. I have diskboot-jbp.img (6MB), which is a boot image for a flash drive, and kernel-{,smp-}2.6.10-1.760_FC3_jbp.i686.rpm ({17,16}MB), which are the RPMs that you *must* install before rebooting from the standard installation procedure. Let me know where to send them.
please send the files to my e-mail that is posted on here..or here it is too blackbic@gmail.com. how do you install rpms if you do not have linux installed already? That is the only way i know of?? thanks a ton for this, i have literally been working on this for over a month and a half already.
Originally posted by BlackBic how do you install rpms if you do not have linux installed already?
For one brief moment, after you've successfully installed the OS and before you've rebooted, you have a complete, functional system [in truth, you're not in *that* precarious of a position... you can always reuse the pen drive and install CDs to boot up a rescue system]. Check the post on the thread from 02-02-2005 08:57 AM. Particularly, the paragraph about ctrl-alt-f2. You probably have to "chroot" to wherever the hard drive is mounted in order to then do a "rpm -Uvh ...". You'll also have to manually start up your networking in order to ftp the RPMs over from some other machine you have lying around, or else put the RPMs on a CD, to get them on the machine.
Until the Fedora guys integrate this new libata stuff, you'll have to manually apply the patch that was posted here, and rebuild the RPM, before installing an updated kernel.
There have been many posts that raid0 will not work, but it will. At least I've got it working with gentoo, so I assume it will work with most other distributions.
findusbmount() {
if [ "$#" -gt "0" ]
then
for x in $*
do
echo -e "${GOOD}>>${NORMAL} Attempting to mount USB:- ${x}"
mount -t vfat -r ${x} /newroot/mnt/cdrom > /dev/null 2>&1
if [ "$?" = '0' ]
then
# Check for a LiveCD
if [ -e /newroot/mnt/cdrom/livecd ]
then
echo -e "${HILITE}---- USB medium found on ${x}${NORMAL}"
mounted="${x}"
REAL_ROOT="${x}"
break
else
echo -e "${HILITE}---- ${x} is not a LiveUSBStick; skipping...${NORMAL}"
umount /newroot/mnt/cdrom
fi
fi
done
if [ "${REAL_ROOT}" != "" ]
then
echo -e "${GOOD}>>${NORMAL} USB medium found on ${x}"
fi
fi
}
bootstrapUSB() {
if [ "${CDROOT_DEV}" = '' ]
then
findusbmount /dev/sd*
# Not in /dev/cdroms: try /dev/ide/cd
[ "${REAL_ROOT}" = '' ] && findusbmount /newroot/dev/sd* # USB Keychain
else
# Device specified on command line
findusbmount /newroot/${CDROOT_DEV}
fi
}
# This code worked for me, you might have to check different device names.
I replaced the bootstrapCD call with
echo -n -e "${WARN}>>${NORMAL}${BOLD} About to mount the USB stick"
bootstrapUSB
if [ ! "$mounted" ]; then
echo -n -e "${WARN}>>${NORMAL}${BOLD} USB mount failed, checking for CDRom"
bootstrapCD
fi
Then the key is to get the volumes up and running. I used the code alread in linuxrc, namelye the startvolumes code, I just always call it so
put
startVolumes
just before the line
[ "${CDROOT}" -eq '0' ] && startVolumes
# now make scotts.igz
umount /mnt/loop2/
gzip -9 /mnt/gentoo3
cp /mnt/gentoo3.gz /mnt/pockey/scotts.igz # put it onto your USB device.
You also need to make a kernel. For my USB I used the 2.6.10 kernel, and applied the gentoo genpatches (which you need for sqaushfs) and I applied the libata dev patch. I'm prettys sure the lates (2.6.11.5 currently) will work, as I am now booting with it, but I was genting errors with the libata patch and I had read that it didn't work with 2.6.11 only 2.6.10.
Once you patch, you can compile it. I used the config file the oeri posted on http://notebookforums.com/archive/in...p/t-50624.html
( http://www2.oeri.ath.cx/2.6.10-config) to get it compiled. This config file bascially has everything in the kernel so no modules. This helped as occasiionally when booting from the USB it would freeze up looking for modules to load. If you do compile modules don't forget to put them in the /lib/modules directory in the root image that you just created above.
cp arch/i386/boot/bzImage /mnt/pockey/scotts # copy the compressed kernel to the USB drive
Boot from the USB.
If everything worked and you didn't get a kernel panic because you missed a step (or I missed on here and you were following too closely) or have a typo, or you hardware is different than mine, you should now have your partitions show up /dev/mapper/pdc_xxxxxx
ls /dev/mapper
If so, the follow the gentoo installed guide and set up gentoo.
The next step is to get it booting. This was a pain, as I kept making mistakes.
Originally, I used partition magic 8.0 to change the 160G NTFS partition to a 20G one, then added a 10G / ext3 partion, a big /home partitition a swap partion and another NTFS partion (this can be shared between linux and xp)
But this failed to boot, so I used partition magic to add a 50Mb partition in front of the NTFS partitiont, used it for /boot (make sure you make it active, I used PM for this).
I did not retry booting from the origing 10G / partition.
I made mistakes like not using /dev/ram0, not putting the initrd in the right place (correct name for my grub.conf), using the boot partition when I should be using the root partition, etc.
But it finally booted just fine. This was using the 2.6.10 kernel that I had used on the USB device.
The next step was to compile a 2.6.11.r5 kernel. After getting all of the options correct, finally, it booted just fine. At one point I was using devfs (even though they said not to, but I didn't feel like recompiling the USB kernel), and so I had to che the ln -s line in the USE_DEVFS_HACK in the linuxrc file the dmraidinitrd used. But it worked.
I still don't have the X or the network working in this kernel, but I will shortly. I'm just posting this before I forget what I did and forget to post, so hopefully those out there still trying might be successfull.
And a big thanks to everyone who has posted so much help on getiting these portables up and running!
Hey Twinkel. Glad to see someone was able to get FC3 working with an Alienware system. I myself have an almost identical system to yours. I've got the Alienware MJ-12m 7700 Mobile Workstation. Can't get any distro to load on it though. I read on page 1 that someone got SuSe 9.1 to work with the drivers from Promise. Well i got those drivers and SuSe won't install period. Tried FC2 with it's Sata_promise drivers and the install freezes. FC3, well it's a joke on this machine. lol. Off to see if i can find a distro that'll work.
I'd try your steps involving the kernel re-build, but i've never succesfully been able to build a kernel.
I have, most recently, installed vanilla Fedora Core 4 without the need to recompile anything. I believe I did have some issues with installation, but these may have been of my own making (DVD was not readable in laptop drive, so had to install over NFS from other machine, booted from USB key (do *not* remove key during installation)). I'm still having some trouble with my sound card, and using LVM stuff absolutely failed (had to partition manually without LVM), but other than that, things seem reasonably stable. The installation locked up at the very end a few times (it took me about 5 attempts to get everything right), so I opted to do an installation other than the 6.8GB "everything", and then just "yum install <whatever>".
Originally posted by phantasm Are you saying that FC4 has support for the SATA 378 chipset?
Yes. More particularly, the kernel that comes standard with Fedora Core 4 will recognize and allow access to my hard drive without even the need to use a third-party driver. Nothing but the Fedora discs were required for installation (minus my personal caveats of DVD not recognized, etc. I'm sure it would have been much easier if I had just made CDs instead of a DVD, but downloading the iso's may well have taken the total six hours that I, instead, used to bang my head against the DVD-via-NFS install).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
). Anyway, the patch I've uploaded actually performs the *.config and *.spec file tweaking, as well as drops in the portion of the libata patch that is not included. This is much preferred to performing these processes yourself, but if you wish to do it manually, here's the rundown:
