adamw

Great useful post, thanks! Did you also upload the system info to the HCL, http://hcl.mandriva.com ? The first time wizard offers to help you with that. A note on the graphics - VIA has said it will contribute to and support development of the openchrome driver in future, presumably dropping the proprietary driver, so we (really, I, I'm the one who mostly looks after Chrome stuff in MDV) are just planning to stick with the openchrome driver. I need to check on the status of the DRI driver development (that's what actually determines 3D support, not any code in openchrome itself).

Thanks again for all the support, guys.

Hey, guys, and thanks for all your support, it means a lot to me :) There is a way in which it kinda makes sense to get rid of me, though. Unfortunately it's bad news for all you guys. It's possible the company is going to retrench around corporate / OEM work. In which case most of what I do becomes superfluous. Of course, that's potentially bad news for Mandriva-as-a-general-purpose-end-user-distribution; it will come to rely ever more heavily on volunteer contributions as the paid staff work only on things that benefit OEM / corporate products. It would make it important to get something like Per Oyvind's foundation idea up and running. I don't know if that's what's happening, because no-one's told me. It's probably not something you could say about a lot of companies, but Mandriva is one which really *NEEDS* more strategy meetings. Then at least I'd know what the hell the strategy is. :) But it makes logical sense just going on the information I have, which isn't much. If you look at our financial results, the income from the 'community' unit has been dropping off a cliff for several quarters (which is part of what prompted my infamous Canonical blog post).

There's no point discussing KDE 3 in Cooker, as there will be no KDE 3 in 2009 Spring. It is being dropped. We will maintain some KDE 3 packages in order for important KDE 3-based apps which are not stably ported to KDE 4 to work, but we will almost certainly not ship a working KDE 3 desktop in 2009 Spring. KDE 4 in Cooker is being changed very rapidly - it went from 4.1.72 to 4.1.73 overnight and then up to 4.1.80 (4.2 beta 1) almost immediately. So it's very likely you had a mix of different packages, which is why it would fail. You have to wait for it to stabilize at a given version.

For printing, make sure system-config-printer is installed, then you should be able to access printer configuration from the MCC as normal (though it's a different interface from 2008.1.).

Does the nvidia-settings tool not let you set the resolution?

Instead of bothering to learn kanji, my cunning master plan is to wait forty years or so, at which point no Japanese people will understand the damn things either. =)

Also, make sure you have the correct resolution / ratio settings on the TV. Usually you'd want the 'native' setting.

Does it work if you pick Xgl rather than native support?

CRT monitors can generally support a higher refresh rate the lower the resolution. 100Hz support isn't that uncommon. It doesn't have any benefit, though, unless you have incredibly sensitive eyes that can see flicker at 85Hz. The only way to force a specific refresh rate is via xorg.conf , but X will automatically use the highest rate available for the given resolution, on a CRT. So if it's using 85Hz it's because nothing higher is supported by your monitor at that resolution.

taupist: once the .xml files for package info are downloaded once, they are cached for future use, so you should be able to retrieve the information from them offline.

First, don't do builds as root. It's pointless and dangerous. You only need to do the install step as root. Second, it looks to me like you're missing the SDL development package. I don't know what that would be called on SUSE.

bryenski: Mandrake 10.1 is an extremely old version and unlikely to work at all well on current hardware. Our latest release is 2009, which you can download at http://www.mandriva.com/en/download . Please give that version a try :)

pmpatrick: the kernel update that fixes many of the hda-intel sound issues has already been released as an official update yesterday.

If you click on the message, it gives you an option to NOT do the upgrade and make the message go away permanently. If you do the upgrade from 2008.1 to 2009 in that manner - via MandrivaOnline / MandrivaUpdate - you will get 2009 with KDE 3, not 2009 with KDE 4.

Is Compositing enabled in your xorg.conf ?

Well, how else would you suggest naming them? The name has to include a reference to a specific kernel, because it's a binary module build that will only work with one particular kernel. We could call it nvidia-current-2.6.24.7-desktop-2mnb , but that just makes it look like 2.6.24.7 is the version of the NVIDIA module, not the version of the kernel it works with. kieth: you only actually have two kernels installed: kernel-desktop586-2.6.27-0.rc8.2mnb and kernel-desktop586-2.6.27.4-1mnb . The first is the initial 2009 kernel version, the second is the first official update which came out a few days ago. If the updated kernel works well for you you can safely remove the older one, but having it around doesn't do any harm (except take up some disk space). kernel-firmware contains GPL firmware for various kernel drivers, kernel-desktop586-latest is a metapackage which ensures the kernel gets automatically updated (it has to be done this way for slightly complex reasons which are explained elsewhere), and all the others in your list are various kernel modules. scarecrow: virtualbox-kernel / dkms-virtualbox is for the host. vboxadd-kernel / dkms-vboxadd and vboxvfs-kernel / dkms-vboxvfs are for the guest. kernel-rt and kernel-linus are both perfectly well described in their package descriptions: "NOTE: This kernel has no Mandriva patches and no third-party drivers, only Ingo Molnar -rt (realtime) series patches applied to vanille kernel.org kernels." "NOTE: This kernel has no Mandriva patches and no third-party drivers." so yes, kernel-linus is a vanilla upstream kernel and kernel-rt is a vanilla Linus kernel with the -rt patches applied.

lzma-kernel and vbox-kernel are not kernels. Any package with the name (something)-kernel is not a kernel. It's a package containing kernel modules (drivers) built via DKMS. We handle some kernel modules externally like this (rather than building them into the kernel package) for various reasons. lzma-kernel is to do with LZMA support for SquashFS: http://www.squashfs-lzma.org/ we use squashfs to compress One and Flash. It's not something you need to worry about. I think it hangs around after you install One but is not actually needed any more, but it won't hurt anything to keep it. vbox-kernel is the kernel module required for VirtualBox to work. There are (in 2009) three official kernel flavors: kernel-desktop586 , kernel-desktop , and kernel-server . kernel-desktop586 is built with i586 optimizations, so it supports true i586 CPUs (original Pentiums and AMD K6, notably, and a few others). It's used on One to ensure One supports the widest possible range of processors. kernel-desktop is the 'standard' kernel, expected to be used on most systems; it's built with i686 optimization, support for up to 4GB of RAM, and with timers and scheduling optimized for desktop use. kernel-server supports up to 64GB of RAM and has its timers and scheduling optimized for server use. kernel-tmb is an alternative, experimental kernel developed by a volunteer member of our kernel team (Thomas Backlund). It's mostly used a testbed for stuff that is too experimental to get into the main kernel these days. It has its own set of flavors (slightly different from those used by the official kernel). Then there are several kernels meant mainly for testing purposes, like kernel-linus and kernel-rt. These are unmodified builds of various upstream kernel trees, using mainly for regression testing.

Look in /etc/sysconfig/network-scripts and /etc/ppp .

Did you have to resort to urpmi, or did the graphical tools get it right in the end?

In this situation, you could try using kppp instead. I've read several cases where it's worked well.

You can configure rpmdrake's meta-information downloading policy in the Media Manager. Options / Global Options / XML meta-data download policy. You can set it to 'never' if you never want rpmdrake or urpmi to automatically retrieve extra information on packages as you query them. This will result in you not seeing the package description or list of files or changelog in rpmdrake, and you also won't be able to search based on this information using urpmq / urpmf.

The NVIDIA proprietary driver is provided in the official Mandriva repositories. If you install from One, it will be installed automatically. If you install from Free, you should follow these instructions to install it: http://wiki.mandriva.com/en/Installing_pro...eo_card_drivers 177.80 is available in /non-free/backports , but I wouldn't recommend bothering with that unless you have problems with 177.70 (the version you'll get by following the above instructions). If you got kernel-server on install, as discussed above, you will run into a problem where the NVIDIA driver will not work with it. You can either switch to kernel-desktop, or update to the latest kernel-server and kernel-server-devel available in the /main/testing repository, which resolve this problem. The fix will be issued as an official update soon. On an i586 install, kernel-server is the correct kernel if you wish to take advantage of your whole 4GB of RAM: due to issues with how the PC architecture handles memory, a kernel which supports '4GB' of RAM will in practice usually lose around 200-500MB on a 4GB system (so it will only see 3.5GB-3.8GB or so). This is basically because there are 'holes' in the PC memory mapping system, so the very end of your 4GB of RAM is actually mapped to address space beyond the 4GB mark. The kernel-server kernel supports up to 64GB of RAM via PAE, so it does not suffer from this limitation; it will support all of your memory. On an x86-64 kernel, this issue is irrelevant; the fact that the installer installs the kernel-server kernel on systems with 4GB of RAM and more in the x86-64 edition is a bug. It's probably best to switch to kernel-desktop in this case.

scarecrow: input hotplugging is a new feature of X server 1.5, it's not some special Ubuntu evilness. I'm surprised they didn't build it so you can override it via the standard configuration file, though. X.org seem to be trying to get rid of xorg.conf entirely, I'm really not 100% convinced it's a good way to go...ah well.

Seems high, but it's *possible*. Do you have a lot of packages installed?