Jump to content

Kjel Oslund

Members
  • Posts

    106
  • Joined

  • Last visited

Contact Methods

  • Website URL
    http://
  • ICQ
    0

Profile Information

  • Location
    Toronto, Canada

Kjel Oslund's Achievements

frequent

frequent (3/7)

0

Reputation

  1. The driver for Nvidia cards (nv) that comes with the version of Xorg shipped with MDV2006 is broken. Your description of your screen is exactly what you get when when that driver is used in your /etc/X11/xorg.conf file. Mandriva did include a version of the commercial (non-GPL) driver from Nvidia on CD3, as package dkms-nvidia-7676. You should be able to install that from the command line using the command "urpmi dkms-nvidia-7676", and you can get to the command line using the failsafe boot option. I haven't installed the dkms package myself -- I use the driver directly from Nvidia -- so I can't walk you through the process in detail. Perhaps someone who has will add to this thread.
  2. Is anyone else having problems with CUPS with the new dbus-0.50 version installed? I get very wait times for printer output while CUPS times-out trying to contact dbus. Is there a work around, or do we just have to wait until Mandriva or the upstream developers get around to updating CUPS for dbus-0.50 (eggcups too).
  3. Yes it did something, but not quite what you were expecting. The commands you got from Easy-Urpmi did two things. One, it set up a list of respository locations from which to download updates and new software. Two, it downloaded the catalogues from those sites. To update your system using the command line you need to run the command urpmi --auto-select Before you do that, you usually want to make sure your catalogues are up-to-date since urpmi uses them to determine what needs updating, so the usual command sequence is: urpmi.updatemedia -a urpmi --auto-select This is essentially what running a software update from the MCC gui does for you, so you didn' t do any damage to your system by using two methods: they are really the same. By default the update packages are not stored permanently on your system, they are deleted once they have been successfully installed. The latest updates are always available from the web so there is usually little reason to keep the downloads. If you want to keep the update packages, you would use the --noclean option with urpmi. The files are saved in the directory /var/cache/urpmi/rpms
  4. Add module ide-floppy to your /etc/modprobe.preload file. Udev will then see your zip drive in /sys/block/ and create the appropriate entries in /dev. Do NOT configure your zip drive to use supermount. It doesn' t work correctly and can corrupt the file systems on your disks. You will have to manually mount/unmount you zip drive.
  5. I haven't changed modprobe.conf yet. I just manually load the module and ignore the error from modprobe. The error just means that snd-emu10k1 is already loaded -- the error comes from the --first-time argument used in the install snd-emu10k1 line. I want to do a bit more research on the modprobe/insmod dependency chain. There has got to be a better way to fix this. Unfortunately I don't know how this was handled in previous releases and I don't want to reload an old version of Mandy just yet to take a look.
  6. In previous releases of MDK/MDV the snd-eum10k1-synth module was automatically loaded when snd-emu10k1 was loaded (soundblaster/audigy alsa driver). This is no longer happening in MDV2006 beta (running cooker). I can load the module manually using modprobe and it works, but I do get a modprobe error when modprobe tries to reload snd-emu10k1. modprobe says that that is a FATAL error, but it isn't. Its due to the --first-time option used in the modprobe.conf install line for the snd-emu10k1 module. I'd have to monkey with Mandriva's emu10k1 modprobe.conf configuration to get this to work cleanly. I'm not sure whether this should be reported as a bug, or whether Mandriva expects users to configure this module manually. Recommendations?
  7. Take a look at /etc/udev/cdsymlinks.conf. udev is responsible for creating the appropriate links. Edit the OUTPUT line to add DVD as a required link.
  8. I've been off 10.1 for a while so the details may be a bit fuzzy, but here goes. If you check your /dev/hd* entries you will probably see that there is NO entry for your ZIP drive. Under 10.1 with the 2.6 series kernels ZIP drives are accessed using the ide-floppy driver instead of the ide-scsi driver used in earlier versions of MDK. The ide driver system doesn't seem to detect ZIP drives properly at boot. No /sys/block entries are created and no device files are created in /dev. The simplest way to fix this (at least in 10.2) is to add "ide-floppy" to the /etc/modprobe.preload file. On 10.2 every thing else then works properly (well sort of). In 10.1 I worked around the problem by modifiying /etc/init.d/udev to manually create the /dev/entries for my ZIP drive. You may still have to do that. One further problem that has not yet be resovled: the ide-floppy drive doesn't support changing media! If you mount your ZIP drive using supermount and change disks, you can corrupt the data on your disks. You'll have to go with manual mounts until this problem is fixed (by the ide-floppy and supermount maintainers). If your new to linux all these notes will probably be too high level. Post a reply and try to break it down for you.
  9. Based on the error messages it looks like you have only a partial install of XFree86, the X server packages. That's possible if it was your intention to set up your server without a GUI environment. If so, you would need to install the XFree86 pacakge to keep urpmi happy. If not, then its possible your RPM database is shot. You can check for individual packages that you think should be installed by using "rpm -q <package-name>". If things don't look right, you may want to rebuild your rpm database using "rpm --rebuilddb". I'm assuming you have your urpmi repository information set up correctly. If not, see the Easy-Urpmi link at the top of the page. Finally, make sure you run "urpmi.update -a" to bring your repository information up-to-date before running "urpmi --auto-select".
  10. The file is "/etc/sysconfig/desktop". It should contain the line: DISPLAYMANAGER=GNOME You can select the type of session you want (KDE, GNOME or other) from the GDM login display, but if you want GNOME to be the default, add the following line to /etc/sysconfig/desktop DESKTOP=GNOME
  11. I spent some time looking at the source for cdrecord and the kernel and I've found that there are serious problems with the code for Plextor drives. cdrecord generates SCSI commands that are not recognized by the kernel and are rejected by the kernel's SCSI-CMD filter. cdrecord's mmc driver has special tests specifically for Plextor drives and generates drive specific commands. I also found an archive thread on the LKML mailing list that contains a somewhat heated debate between Alan Cox and Joerg Schilling (the author of cdrecord) an others about handling cdrecord SCSI commands. See a segment starting here LKML: Re: PATCH.... I've submitted a bug report to Mandrake, but I wouldn't expect a quick resolution of this problem, it looks a little too complicated for a quick fix.
  12. I have a friend on who's system I've just installed MDK 10.2 RC2. His system has the same CD-RW drive, a PLEXTOR CD-R PX-W2410A, that is showing a similar problem. I was successfully able to burn a data CD and his daughter was able to burn a single audio CD. Since burning the audio CD any attempt to burn another audio CD (haven't tried a data CD yet) results in a hung system. Looking at the logs (after a reset0 I see these error messages: Apr 4 13:49:02 ross kernel: scsi: unknown opcode 0xe9 Apr 4 13:49:02 ross kernel: SCSI-CMD Filter: 0xe9 not allowed with write-mode Apr 4 13:49:02 ross last message repeated 2 times Apr 4 13:49:02 ross kernel: scsi: unknown opcode 0xed Apr 4 13:49:02 ross kernel: SCSI-CMD Filter: 0xed not allowed with write-mode Apr 4 13:49:02 ross kernel: SCSI-CMD Filter: 0xe9 not allowed with write-mode Apr 4 13:49:04 ross kernel: scsi: unknown opcode 0x01 Apr 4 13:49:04 ross kernel: SCSI-CMD Filter: 0x1 not allowed with write-mode Apr 4 13:49:04 ross kernel: SCSI-CMD Filter: 0xe9 not allowed with write-mode Apr 4 13:49:06 ross kernel: scsi: unknown opcode 0xf5 Apr 4 13:49:06 ross kernel: SCSI-CMD Filter: 0xf5 not allowed with write-mode Apr 4 13:49:06 ross kernel: SCSI-CMD Filter: 0xe9 not allowed with write-mode Apr 4 13:50:53 ross kernel: hdd: packet command error: status=0x51 { DriveReady SeekComplete Error } Apr 4 13:50:53 ross kernel: hdd: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } Apr 4 13:50:53 ross kernel: ide: failed opcode was: unknown Apr 4 13:50:54 ross kernel: hdd: packet command error: status=0x51 { DriveReady SeekComplete Error } Apr 4 13:50:54 ross kernel: hdd: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } Apr 4 13:50:54 ross kernel: ide: failed opcode was: unknown Apr 4 13:50:55 ross kernel: hdd: packet command error: status=0x51 { DriveReady SeekComplete Error } Apr 4 13:50:55 ross kernel: hdd: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } Apr 4 13:50:55 ross kernel: ide: failed opcode was: unknown The packet command errors continue until the system was reset. Any ideas?
  13. Yes, I filed the report: Bug 15147. I'll test the fix as soon as it hits the mirrors.
  14. In case anyone is interested, the problem turned out to be the media. I'd used a brand of CD-R that I hadn't tried before (Memorex 700MB 48x). Several coasters later I found out that I could burn discs smaller that 700MB, but the RC2 ISO all failed. I guess they were too close to the limits for that brand. I bought a pack of Verbatim discs, the brand I've used before and I was able to burn the RC2 ISO successfully. I found out a few other things while solving this problem. GnomeBaker works well: its much like K3B at the UI level, but doesn't have a disc verify option nor does it give you as much control over the burn parameters. Nautilus-cd-burn doesn't work at all, it fails at the point that it puts up its burn progress dialogue. I got xcdroast to finally recognize my drive correctly (had to uninstall and then reinstall it), but it doesn't like Gnome's automount features. It won't work unless you unmount a blank disc before starting it. It also can't eject or load a disc from the UI, something it used to be able to do.
  15. I've found part of the answer. The RC2 ISO appear to have been created as UDF images rather than the traditional ISO 9660 images. When the images on disk are mounted as loopback file system mount declares them to be UDF as well. The 10.1-OE images are mounted as ISO 9660, distinctly different. Tools such as file(1) have not been updated to identify UDF specifically. The RC2 ISO's are probably in UDF-Bridge format that seems to be compatible with IS0 9660. Now on to the real problem, am I getting bad burns from K3B with latest cooker versions, or is something else wrong with this release?
×
×
  • Create New...