Admiral LSD

Gentoo compiles on amd64, you might want to look into that. Just be prepared for a fairly lengthy install process.

It's going to be a tad difficult without knowing a little more about your setup but I'll try and be as general as I can. First, you need to get yourself a "Live" type distro on a bootable CD that has the "mount" and "chroot" commands. I don't know about Knoppix but I know the Gentoo stage 1 LiveCDs have those commands as they're essential in installing Gentoo. Once you have the CD and have booted into whatever environment it sets you up in you're going to have to mount the Linux partitions on your hard disk. Before you can do that though you're more than likely going to have to create a "container" directory for the mounted Linux filesystem. To do that, launch a shell (it's important this all be done as root btw, make sure whatever LiveCD you use gives you this capability. The Gentoo CDs do but I'm not sure about anything else), change to the /mnt directory and then create your container directory (I usually name it according to what distro gets mounted there, a habit from installing Gentoo, but for simplicity I'm just going to call it linux) using the mkdir command. To summarise: Code: cd /mntmkdir linux Now, to mount the partitions type: Code: mount /dev/hdxy /mnt/linux/mountpoint where x represents the drive the partition is located on, y represents the number of the partition and mountpoint is the directory that partition normally gets mounted into (such as /home, /usr etc. / just gets mounted into /mnt/linux and should be mounted first). Once you have your partitions mounted, use the chroot command to "enter" your Linux installation: Code: chroot /mnt/linux /bin/bash and from there you can run the commands to restore your bootloader. Once you've finished, type exit to exit the chroot shell and then unmount your partitions (from last to first making sure you're not in any of the directories your trying to unmount) using the umount command on their mount points. To unmount a partition you use the umount command. So, for example to unmount the /mnt/linux directory you type: Code: umount /mnt/linux Once all that's done, you can shutdown the LiveCD and hopefully your bootloader will be restored allowing you to boot into your existing Linux installation (just remember to remove the LiveCD from your drive and/or set the BIOS up to boot from your hard drive first!).

Anything - and I do mean ANYTHING - that isn't based on RPM. Avoid RPM and distributions based on it like the plague. If you want something to cut your teeth on then I suggest you try this: http://www.slackware.com/

Quote: Believe it or not jclem, installing the new nvidia modules used to be MUCH more difficult than it is now, and that was only a year ago! The only thing that was difficult about installing them a year ago was trying to use the RPMs, installing them from the source tarballs was a piece of cake and much less hassle.

You could always install Slackware on it and make the most of it Slackware's real good on slower machines as it doesn't have a lot of the useless cruft distributions like Red Hat or Mandrake do. The downside to this is that it's a tad harder to use but that isn't such a bad thing, you actually learn a thing or two about Linux, notably how to survive outside a GUI environment, something Red Hat and other distros seem content to gloss over, in the process.

If you created a boot disk when you first set Linux up you can simply use that to boot your system and then restore your boot loader by logging in as root and, at a terminal, typing lilo to restore LILO. If you use GRUB though it's a little more complicated as you need to know the hard drive and partition numbers of your boot partition (the one with the /boot directory on it. It's become quite common to mount this in its own partition these days even though this isn't strictly necessary). Once you have that info, you can simply start the GRUB shell by typing grub at the prompt and then typing the following (assuming GRUB is installed into the MBR): Code: root (hdx,y)setup (hdx) where x represents the hard drive number (GRUB numbers hard drives from 0 starting at the first HDD in the system. If you only have one drive though, it'll always be 0) and y represents the number of the boot partition (like hard drives, GRUB numbers the partitions starting from 0 and employs the same numbering scheme that Linux does so 0-3 represent your 4 primary partitions and 5 upward represent logical drives. A quick rule of thumb is the GRUB number will be the Linux number subtract one so if your boot partition is /dev/hda5, it'll be (hd0,4) in GRUB). edit: I forgot to mention that if you don't have a boot disk for your system you're going to need to find an alternative way to get into your system in order to run the requisite lilo or grub commands to restore the bootloader. For this, you're going to need to get your hands on a "Live" type distribution such as Knoppix that'll let you mount your existing Linux partitions, chroot into your installed Linux environment and restore the bootloader.

A better solution would be the people creating the RPMs getting a bit of sense and supplying stuff like this as a single package instead of trying to split it up into as many components as possible regardless of whether or not those components are useful on their own. This isn't such a bad thing in packages such as Samba or MySQL, which allow you to seperate the server from the client, but with mplayer and the Mozilla packages I had so much trouble with it's just ridiculous. YUM doesn't eliminate the problem (you'll probably find it calls RPM with -f to deal with it itself) it just sweeps it under the carpet.

Mandrake *should* provide the kernel source somewhere, have a look on your distro CDs. If it's not there, have a poke around the FTP archives and download it from there. Also, make sure the kernel source you're downloading matches the kernel version you're running (which you can find out by typing uname -r at the prompt) otherwise it probably won't work.

Try dropping the * at the end of the name (ie rpm -e mplayer-skins), RPM *should* be able to match it without any help.

Isn't RPM wonderful? It was crap like that that forced RH8.0 off my machine and made me vow never to install another RPM-based distro again. If you really want to persist with Red Hat and RPM though you could try using the force parameter (-f I think but check the RPM man page) on both packages to tell RPM to ignore the failed dependencies and install them anyway.

That sounds about right, the need to enable agpgart is well known among nForce2 users as it was a source of much aggravation until nVidia provided AGPGART support for nForce2 to the 2.6 kernel team and later backported it to 2.4. If they'd searched around they'd have probably found a quicker way to get them up and running: http://www.linuxquestions.org/questions/showthread.php?s=&threadid=83035 Yes, it's for Slackware but it should have work just as well (if not better as you avoid the need to use the godawful RPM) on Red Hat/Fedora. And I can't help but think they're doing something wrong in the way they're using fglrxconfig as I've been using it here on Gentoo for ages and never had a single problem with the configuration files it creates. edit: oops, I didn't realise that was actually your site, I somehow got the idea you'd just mirrored the actual info hence the wording of my posts. Sorry about that.

nForce boards are relatively easy to set up under Linux, particularly now that virtually all of the necessary patches (such as AGPGART and IDE support) are now part of the stable kernel tree. The big problem (this is going to sound like a rant and it many ways it is so I'll apologise for it in advance) now is, and I see this a lot over at nForcersHQ, is users who aren't used to dealing with drivers in the way Linux handles them. This isn't helped by distros such as Red Hat who paint over a lot of this inherent complexity with graphical tools that work great when they work but get in the way and are a royal PITA when they don't (which is frequently the case when you introduce drivers outside the stock set). The other problem is nVidia insisting in supplying the drivers in the godawful RPM format without really mentioning the fact the packages are fairly kernel specific. This leads to a whole load of RPM BS and kernel/driver mismatches that could have been easily avoided had they compiled the drivers from the "sources" nVidia provide. With that out of the way, there's been a 2.5/2.6 patch for nvnet floating around for a while now. There's a sticky about it in the nForce Linux forum at nForcersHQ. forcedeth obsoletes it somewhat but it's still a useful bit of info nonetheless. Although it'll be the real winner when it arrives as far as nForce2 support goes, 2.6 isn't strictly necessary for decent support now. A lot of the nForce-specific enhancements have been backported into the stable kernel tree and anything from about 2.4.20 up can be coaxed into support nForce boards fairly well without an awful lot of trouble. ALSA hasn't given me all that much trouble under 2.4 either. There was a period there with ALSA 0.9.7 where it would act up (the sound device would just lock up, the system would continue to run fine but anything that tried to use sound got caught in a loop) and require a hard reboot (shutting the system down would fail when it tried to unload the ALSA modules) but that was fixed in about ALSA 0.9.7c and hasn't appeared to return since (I'm now using ALSA 1.0-rc1). ALSA is definitely worth the trouble though, it's far better than any of the OSS drivers and it's the direction sound in Linux is heading. ALSA's inclusion in the 2.6 kernels means that OSS support is now deprecated and will ultimately be removed entirely. I'm running Gentoo Linux on an EPoX 8RDA+ motherboard running a 2.4.23 kernel using forcedeth for LAN (although I never really had a problem with nvnet) and ALSA for sound and it's solid as a rock, even with the notoriously troublesome APIC support enabled. AGPGART support, which is necessary to get hardware 3D acceleration on my Radeon 9500 Pro, is hassle-free as well.

nForce2 is where it's at for Athlon chipsets these days, even under Linux. The A7N8X Deluxe is a known troublemaker in Linux so I'm not surprised you had problems with it. This is more a fault with the board (and manufacturer) than the chipset though, other nForce2 boards are much better behaved. My EPoX 8RDA+ for instance hasn't had a single issue since upgrading to kernel 2.4.22. nForce2 also has some of the best onboard video, audio and LAN implementations of any chipset out there. Audio is a little dicey under Linux though as it's only supported in basic AC'97 mode instead of the full "bells and whistles" APU mode the Windows drivers put it in. There's a movement under way to try and change this but whether it succeeds or not remains to be seen. The audio is no less usable (provided you can put up with only being able to play one sound at a time although that isn't as bad as it sounds) though, the only thing that really makes use of the higher order APU functions is games and they're not really big on Linux yet. EPoX make a board called the 8RGA+ which is almost identical to my 8RDA+ except it has the integrated graphics version of the North Bridge which I'd definitely look at if I were in the market for that kind of board. Regarding IDE controllers, I have a Silicon Image SiI680 based ATA133 controller in my PC and that's relatively well supported under Linux. Kernel's 2.4.20 and up include the driver natively but 2.4.18 and I think .19 require a patch. Distro's like Red Hat used to include this patch when they were running 2.4.18 but most sane distros have standardised on at least 2.4.20 now so it shouldn't be an issue.

I'd just like to point out here that any issues Linux may have with NTFS are most likely specific to certain distributions. I had absolutely NO trouble whatsoever getting my Gentoo install to play nice with my XP NTFS partition. I also have 3 other distros on here (Slackware, Arch and Sourcemage) but since they boot using the version of GRUB installed by Gentoo they don't really count except maybe to say that I've installed Slack (and many other distros, Red Hat and Mandrake are two recent - as in the last 12-18 months - examples that come to mind) alongside Windows 2k and XP on NTFS before without any trouble.

It may be your 1Gb RAM. Linux can support this much RAM but needs a few options to be set (mainly to do with high memory support) in the kernel first which Fedora's kernel might not do. If that's the case then you're looking down the barrel of a rebuild, which isn't as hard as it sounds as there are plenty of tutorials on it floating around. If you can, try removing half your RAM and see if the machine boots. If it does, install the kernel source (as well as the development tools so you can actually compile it) and enable high memory support before recompiling and installing the new kernel. While you're at it, you might want to grab these as they'll give you much higher performance with that video card of yours than the stock DRI drivers do.

Woody comes with XFree86 4.1.0, it's Sarge and Sid that have 4.2.0 (although Sid should really have 4.3.0 by now except Debian's ridiculous 'all or nothing' policy toward packages and architectures is keeping it stuck at 4.2). ATi supply drivers that cover the whole gamut of XFree86 4.x drivers but these are only for the 8500 and up (including their FireGL variants) so are useless for you 7500. In any even though, I'd suggest you upgrade to at least Sarge (though preferably Sid) as quickly as possible. You shouldn't have to reinstall for this, just edit to change anything that reads 'stable' to either 'testing' or 'unstable' before running apt-get update && apt-get dist-upgrade and you should be right. Next, I'd suggest you take a look here and see if they maintain a driver for the 7500 (I think they do). It won't perform as well as the ATi native drivers but it'll get a graphical environment up and running.

Both nVidia and ATi supply Linux drivers for their graphics chipsets so it shouldn't be too hard to get decent display support up and running.

Quote: Admiral LSD: Red Carpet is also available for Debian Really? I had a look at the Ximian site earlier and there was no mention of Debian being a supported OS for Red Carpet, only Red Hat. Mandrake and SuSE...

I doubt he'd be running Red Carpet as he's running Debian which has the 'real' apt and not the bastardised RPM version. I had a similar problem when I tried installing KDE on Debian a while ago. apt-get install kde would fail citing broken packages. So much for apt's wonderful dependency resolution...

If you're feeling up to it, you can try installing the ATi drivers by hand using a variation on the method outlined here. Mandrake most likely won't have the rpm2targz utility (it was written by Slackware IIRC) but the Linux from Scratch guys have thoughtfully made it available on one of their sites. Just download the bz2ball, uncompress it into a temporary directory and run the supplied install script. You also won't have the Slackware pkgtool so instead, change to the root directory and just untar the fglrx tarball into there. Lastly, you'll need the source of the exact kernel that you're running. If you selected the Kernel Development group when you installed Mandrake then this most likely would have been done for you otherwise load up whatever package management tool you use and hunt around for a package with a name like kernel-source-whatever and install it. Once that's done you should be able to just change to /lib/modules/fglrx and run to the two installation scripts (build_mod/make.sh and make_install.sh) to compile and install the fglrx modules. Assuming that completes successfully you can then run the ATi fglrxconfig tool to make a customised XF86Config-4 file using the fglrx modules. Quote: p.s. how do i install amsn if its .tar ? anyone know how to tweak mtu or rwin on linux? You don't . You download Gaim and use that instead, it's much better.

Quote: There are KDE 3.1.4 RPMs for Red Hat 9 available: http://download.kde.org/download.php?url=stable/3.1.4/RedHat/9/i386/ There's KDE 3.1.4 RPMs in the RedHat rawhide ftp archive as well apparently: ftp://ftp.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/ (you'll have to scroll down a bit or search for it though as there are a lot of packages in there) Just out of curiosity, do either of these work properly with Red Hat's "BlueCurve" themes? I've been using these under Gentoo for a while as, quite frankly, they're the only good thing about Red Hat's distro and the only thing I really miss about it, and I've noticed that as I've upgraded through successive versions of the redhat-artwork package (0.73, 0.81 and recently, 0.84) more and more of the overall theme seems to be missing. 0.81 seemed to fail to include the KDE version of the "new" BC theme as well as BlueCurve versions of several of the KDE icons (the fact the 0.81 SRPM is smaller than the 0.73 indicates that this might be deliberate) neither of which is any great surprise as Red Hat tends to favour GNOME anyway (although ignoring KDE entirely erodes the foundation of what BlueCurve was supposed to achieve in the first place) but the real surprise came when I installed 0.84 and noticed several GNOME icons weren't properly "BlueCurve-ised" either. What I'm trying to ask is whether this is a problem inherent to the way I'm installing the themes (I am installing them outside of Red Hat after all) or are Red Hat users experiencing similar issues.

su is generally the accepted way of doing this, why doesn't it work on your system? I know on Gentoo you have to be a member of a special group (wheel) before it'll let you use the su command, perhaps SuSE has something similar?

If I may be blunt, I'd forget any notion of running KDE on a system like that as it's likely to be too slow. In fact, I'd go so far as to say to forget running a Desktop Environment altogether and install a simple Window Manager like Blackbox or Fluxbox as neither of these bring even a fraction of the amount of overhead a full desktop does. One thing you might want to check out though is xfce which is supposed to be a fairly lightweight desktop although I don't have any practical experience with it.

Unless you want to keep experimenting with hdparm (which can be made to work, at least according to some of the SATA users over at nForcersHQ), 2.6 is probably your best bet. Just be prepared for a fair bit of other stuff (such as lm_sensors although I think that's being made redundant by 2.6) to not compile right under it yet. If you want to stick with a stable 2.4 kernel, do a search here (It's an nForce forum but as a lot of nForce boards also include SiI3112 SATA chips, it's as good a place to find info as any) for stuff to try to get DMA enabled on you board.

Unless you want to keep experimenting with hdparm (which can be made to work, at least according to some of the SATA users over at nForcersHQ), 2.6 is probably your best bet. Just be prepared for a fair bit of other stuff (such as lm_sensors although I think that's being made redundant by 2.6) to not compile right under it yet. If you want to stick with a stable 2.4 kernel, do a search here (It's an nForce forum but as a lot of nForce boards also include SiI3112 SATA chips, it's as good a place to find info as any) for stuff to try to get DMA enabled on you board.