adamw

10.0 and 10.1 don't need commercial drivers for the nforce networking; they use the open-source forcedeth drivers. Any version of 10.0 or 10.1, free or commercial, will support the nforce2 onboard networking right out of the box. You could get it to work under 9.2 using the closed-source driver from www.nvidia.com (download the chipset drivers pack for nforce and ignore the audio driver, you don't need it, just build the nvnet driver). But using 10.0 or 10.1 is better anyway. :)

BTW, 'urpmi gnome2' will automatically download all packages required for a working gnome2 system. If the terminal you're using is buggy you could always use another, I use gnome-terminal on my main system and rxvt on my laptop...a *nix system is never short of terminals :)

you want to *DIS*able it, not *EN*able it.

same error in the logs? or is it different now?

'database locked' means you're running something else that uses the urpm database at the same time - any of the urpm* apps, rpmdrake, edit-urpm-sources, MnadrakeUpdate, anything dealing with MDK packages. Only one app can access the urpm / rpm databases at once.

how does xine feel about it? If xine can't play it, totem won't be able to, and it's a xine problem not a totem one...

hdparm is a fairly rough-and-ready test; it might not catch some problems. Maybe there's some kind of more fine-grained problem going on here. Hard to know *what*, though... btw, what results do you get with hdparm on the IDE drive? just for comparison.

If you just run 'alsactl restore' as root after a reboot it will probably restore your good settings. I have the same problem currently on one of my machines, the alsactl restore run during boot fails for some reason. I think it's called too fast, or something. If you call it manually after booting it works fine. It also started working for me while I was twiddling with kernel boot options and BIOS settings last night in a vain attempt to make prism54 work, but I didn't take a note of which particular settings made it work, unfortunately.

If you don't change the static hardware in your machine you could always just turn it off. Run 'chkconfig harddrake off' as root, or you can do it graphically from drakxservices. Stuff like USB, Firewire - anything hotpluggable - will still be detected fine, harddrake deals with stuff like PCI cards.

Yeah, that's a really stupid package naming 'feature/bug'. There's a Bugzilla bug with a bit of a flamefest going on about it, IIRC. Hope it gets fixed.

did you do an update from a previous version, by any chance? I don't believe 10.1 would use supermount for such a drive on a fresh install, and I don't know if supermount even works on 10.1...

Rubbish. You should use the latest official updated package for the distribution version you are using. Ripping something as integral as XFree86 out of 9.2 and replacing it with x.org because x.org is New and Shiny is frankly reckless and irresponsible. The correct X package to be using on 9.2 would be XFree86-4.3-24.6.92mdk , the current X version in the offical 9.2 updates tree. You would not be able to install X.org via urpmi unless you defined a source from a later release of Mandrake or from Cooker. Neither path is recommended, supported or likely to work without causing major system problems.

acpi=off is the correct form for that command. You might try 'vgalo acpi=off noapic nodma'.

Basically, anything at the first level of the directory hierarchy that *isn't* its own partition is part of /. Following me? For instance, the following directories are present on virtually any mdk system: /var /etc /usr /home Any of those which isn't specifically created as a separate partition will be part of the / partition. YES, you should definitely back up anything in /var you need to keep. A fresh install will wipe it. /storage will be fine, since it's a separate partition. Just make sure you know *what* partition it is and tell the install routine to mount it and *not* format it. I'm not quite sure what you mean by 'losing' webmin, ssh, ftp etc. You won't have the *same* copies after a reinstall, obviously, but you can perfectly well install them. If you have customised configurations for them in /etc, it's probably best to keep copies. In the install simply do 'custom package selection' and make sure the webmin, sshd, proftpd (or pureftpd, or whatever) packages are installed. HTH!

Konqueror is respecting the Reg's bad font settings and using a (bad) font to satisfy them. There's no easy way around this, really. The hacky solution is to go and kill all the ugly X fonts, which is an ugly idea but works. The slightly more elegant solution is just to brute force fontconfig into replacing ugly fonts with sans; this post - http://www.mail-archive.com/fonts@xfree86.org/msg01428.html - gives details of how. I use this to forcibly replace practically every font you often come across (arial, verdana, helvetica, lucida etc) with its Vera equivalent. It's cleaner to make these modifications in /etc/fonts/local.conf (for systemwide) or ~/.fonts.conf (for one user) than directly in /etc/fonts/fonts.conf .

No, it doesn't - it sounds like he can boot to runlevel 1 only. runlevel 5 is graphical environment, runlevel 3 is multi-user console environment, runlevel 1 is single-user mode. His problem is getting from 1 and 3.

"Parse error on line 94 of section seven in file /etc/x11/xorg.conf The default depth keyword requires a number to follow it" That suggests that the part of xorg.conf that sets the default screen depth - that's the number of colours used in the display - is empty. It shouldn't be, though, I wonder how it got that way. You could run XFdrake as root and see if that fixes it, or you could just go in and edit the line directly - a value of 16 should be safe to use.

If building KDE from source didn't work (heck, that was a *bad* first troubleshooting step choice, the #1 rule of troubleshooting is to start with the simple stuff :>) then the problem is almost certainly in your user profile. Create a new user and see if KDE works for that user; if so, you'll need to delete your ~/.kde directory (or move it somewhere) and let KDE create a new one. But by now you've probably sufficiently stuffed up your system that DeVries' suggestion is the best :)

patrick's exactly right, the main point of a /boot partition is to make sure it's always accessible to boot managers. It's perfectly supported by lilo and grub and ought to work fine.

I just noticed something in the original (great) articles is out of date; it no longer needs to reference Cooker bash and external bash-completion, as both a bash that supports extended completion and a working bash-completion package are in stable Mandrake now. You can just 'urpmi bash-completion'. Could it perhaps be edited?

cd /var du -H see if that helps any...

"packages will only add menu entries if they are compiled to do so by the developer & only if they have a gui interface to go with them." Not *quite* true, MDK does add menu entries for some apps which seem to merit them but aren't shipped with one. But you're mostly right, in that Mandrake make decisions about what goes on the menu. Neither of these apps gets a menu entry. If you just run mp3info nothing useful happens - it's a little console tool that need arguments to do anything useful. If you just run 'units' you can use it, but it's a console app not a gui, so the policy is not to put it in the menu. units is amazingly useful, it has just about every unit - scientific, engineering, domestic, *everything* - known to man programmed into it. Just reading /usr/share/units.dat (the file that contains the actual units) is absolutely worth spending an afternoon doing, it's an education in itself (it's excellently commented). One thing I've found units invaluable for is cookery, especially when using American recipes with quantities specified in cups - these can't be converted to proper weights easily because a cup of chocolate has a completely different weight from a cup of, say, flour. units has the correct weight for a cup of just about *anything* programmed into it, which is brilliant.

bvc: that output wouldn't be normal the *first* time you run make, but it would be entirely normal the *second* time, because there's nothing left for make to do! That's what the 'Nothing to be done' means, it means everything make has been told to do in that directory is already done. scotty: "Sooo after ./configure, make, make install, going to the root dir and typing 'gentoo' results in "no such command". I assumed then it wasn't installed?" That would suggest it wasn't properly installed, yeah. Did you run make install as root? If you did, maybe it just puts itself in a weird place or something. If you're still interested in what the problem was, go to the directory where you built gentoo and look around for a file just called 'gentoo'. Go the the directory it's in and try calling it directly with ./gentoo . If you don't care any more now you have tree-view nautilus, never mind :)

My answer was exactly relevant to your problem; it told you exactly how to setup your system so that you would be *able to download and install the necessary development libraries with no hassle*. BTW, the 'average user' you talk about would likely have no need whatsoever to install said development libraries, because they wouldn't be writing their own code or attempting to build kdevelop from scratch, would they?

just remember to run the installer with X disabled (from a terminal run service dm stop), and I also sometimes have to run the installer twice when upgrading the driver or switching kernel versions - if you get any odd error message, just run the installer again. When you're finished with the installer remove and reinsert the nvidia module, just to be safe - # modprobe -r nvidia # modprobe nvidia and restart X: # service -f dm and off you go!