adamw

you can do the same thing. go to http://easyurpmi.zarb.org/ and that will help you set up sources for urpmi, Mandrake's package manager. then you can do urpmi --auto-select, which updates to latest versions. There aren't a huge amount of updates from 10.1CE ISOs to current right now, but quite a few.

no, that's not what auto does. auto is for unattended updates; it automatically goes through steps urpmi usually queries you on (confirm the list of packages to be updated - pick a package to be installed where more than one can satisfy a dependency - remove obsoleted / conflicting packages). it always picks the safest option. If you're doing automated updates via cron or something, urpmi --auto-select --keep --auto is the best command line to use, completely non-interactive and as safe as it can get.

some stuff may break going from 10.0 to 10.1 via urpmi; kdmrc needs to be replaced with kdmrc.rpmnew and you may need to remove the devfs=mount section from your lilo.conf. those are the two biggues. technically, rpmdrake does not use urpmi as a backend. rpmdrake never invokes an urpmi command. They are both interfaces to the perl-URPM backend and share common database and configuration files. to answer one of spunky's questions: running the steps at easyurpmi will define the new sources and update the list of packages they contain, but it *won't* actually download and update any packages. After doing the easyurpmi steps you need to either do "urpmi --auto-select" from the command line, or use the graphical tool's "all upgradeable packages" filter (well, it's called something like that, don't remember precisely). urpmi --auto-select will update all packages for which an update is available. The graphical tool has a view which shows all the packages for which updates are available and you can then pick which to update.

or nano, but unfortunately it's in contrib. you could always take out the devfs entry *before* upgrading; it won't break an existing system (it'll just revert to using a static /dev).

oh, to clarify - that's not the same as kernel-multimedia. That would give you the old 2.4 multimedia kernel, which no longer works very well.

One tiny correction - the best kernel to use to get the lirc modules, on 10.1, would be kernel-multimedia-2.6. This is svetljo's bleeding-edge kernel, the spirutal successor to kernel-tmb, which thomas no longer has time to update...

btw, with 10.1 we now actually use dbus to do insert notification, and the gnome-volume-manager tool to actually run the application or create the icon, with GNOME. Dunno what's used in KDE, something equivalent. The end result is the same, though - an appropriate app pops up for writable CDs, audio CDs, DVDs etc, and an icon appears for data disks. when you do an upgrade from 9.2 (which used supermount) or 10.0 (which used magicdev) and the systems collide, Exciting Things may happen...

to sound less negative - official releases require a separate updates tree because the main tree is static: nothing in it can be changed. the community version is more of a rolling distro, like cooker, so changes in the main tree are allowed. thus there's no need for a separate update tree.

oh, and it would be helpful if you could run the command "lspcidrake -v" as root and also "lsmod | grep snd", and then create a bug on the Mandrake bug tracker with a description of the problem and both outputs included. Then the default levels for your sound chip can be adjusted so the problem doesn't happen to others.

"mixer" is the, possibly not great, standard linux name for volume control tools. They live under the "multimedia" entry in the program menu. You need to mute the microphone input. Some laptops have extremely sensitive microphones that cause this problem if the microphone input is set to a level above, like, 5.

that wouldn't be for a USB hard disk. it's using the devfs name for the partition you'd usually identify as hdb1 (read it like this: bus0 is the first IDE port, so hda or hdb; target1 means hdb (hda would be target0); lun0 is not relevant to any IDE device you'll ever come across, so ignore it; part1 is the partition number). So this is actually the same as /dev/hdb1. It's a duplicate entry for that partition - which it seems is actually NTFS - which tries to mount it as an ext2 or fat32 partition via supermount. This looks broken. I think harddrake is probably putting it there...

jackp: did you upgrade from 10.0 or do a clean install? If you upgraded, try installing kdmrc (it's in /etc somewhere, dunno where, I don't run kde) with kdmrc.rpmnew, if it exists. (it'd be in the same directory). what do you mean by "broken"? what happens, exactly? Do you just get the normal login screen?

could be a kernel issue. try acpi=off noapic as boot parameters.

xon: you're probably missing some devel packages. look at the name of the package it's supposedly missing, then do a search for that name with rpmdrake or urpmq, and install any likely-looking devel packages.

erm :). I'm not entirely sure what's on the fourth and fifth CDs, haven't investigated yet. If there's any commercial stuff on there, then that may not be available online yet - it seems there's no Club commercial repository for 10.1 as of yet. That's the only stuff that wouldn't be available in online media, though; contrib, plf and jpackage stuff all would be. one thing I'm not sure of is whether the unsupported kde 3.3 packages that were supplied on the 10.1 CE ISOs are available online...anyone know?

there are actually five CDs for 10.1 CE available, so most of the stuff you have would be updated. For your situation, though, it might be an idea to try an urpmi-style upgrade - define sources for 10.1 main, contrib, plf and everything else you use, then do urpmi --auto-select. That way you get more control over what's going on and more of your packages will be updated. Yes, 10.0 sources will by and large be useless on 10.1, but 10.1 versions of most should be available (contrib and plf certainly are).

btw, since the original post has been modified I can't tell, but is there a reason we don't use the Mandrake (or rather, stolen-Debian) menu system and menudrake here?

this ought to work. devfs -> udev migration is handled, might need to remove devfs=mount from lilo.conf, though. the other big one to watch out for that I can think of is make sure that you overwrite kdmrc with kdmrc.rpmnew - apparently, if you don't, mdkkdm won't work. other than that, should be fine. (btw, my laptop hasn't had a fresh install since 9.0 :>)

anything with a bt chip is probably the easiest way to go. any cheap Hauppage card will have this chip. steer clear of USB stuff, it's harder to get working - get a basic cheap Hauppage PCI card and it'll work fine.

"Contrary to the information in the release notes, my NIC got the alias eth0 and my firewire/IEEE1394 (on my Audigy2 sound card) got the alias eth1." Yep, this should now happen in all cases. It was fixed a little while ago and somehow release notes were not updated.

for kilimanjoe, this is a far better way to do it. you should NOT be using a publically accessible web server to do this. it's insane. make sure sshd is installed on your home machine (via urpmi or rpmdrake). make sure it's running (through control centre). then install PuTTy on the machine at school, connect to your IP address, type in your username and password. done. you're in.

gowator: no, it's not difficult, but it is *hideously* insecure - anyone who knows his IP address can also browse his files. or, say, delete them. this is why we use ssh for this and not nfs or http...

vdub: actually, it'd be far more secure to use a different port. either tell ssh to use a different port and open that, or set your firewall to forward an external connection on some other port to internal port 22. why use the port every hacker *knows* is ssh?

artificial intelligence - that's the wrong solution. you should never run a normal app like thunderbird as root. Changing the badly created permissions is the correct solution.

"My solution would be to compile the kernel myself and use the module that you know will work." that would be bad advice, given that this is *removable* hardware. for those having trouble - see if the module orinoco_cs is loaded. if not, what happens if you modprobe it? if nothing appears to happen, what do you see when running "dmesg" as root immediately after modprobing? [edited by spinynorman]