Jump to content

tlahtopil

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by tlahtopil

  1. I don't even know what KDE version I am on, only know this morning keyboard was just plain dead, as told here, only on my account, only in KDE. After deleting all X, Qt and kde configuration files I found, it was still the same. Then it occurred to me to open kcontrol from Gnome, and in Session manager I disabled previous session restoration. I killed kde, restarted with a clean new session, and problem was solved. Hope this is of some use.
  2. 20060317 update: Has anyone around here tried with a "paid" distro? I'm reading at Mandriva products page that boxed LE2005 has (verbatim) "enhanced Hardware support... * Full support for Adaptec Host RAID controllers (RAID, SCSI, SATA)"... It's +/-30 USD/EUR these days... I'm thinking seriously about buying it, but money isn't an issue of give-away for we the freesoft advocates, is it? "Free" as "freedom" also means "free not to waste my money". So, if anyone in this forum has tried succesfuly boxed LE2005 with SATA discs, let me know, please.
  3. SATA recognizing problem appears more often in x86-64 versions, be LE2005 or 2006. Seems to be a "cooker-related" or "halfbakery" issue: MS style, 64bit distros were labeled "official" 'cause of marketing rush (When came x64 Fedoras, SUSEs BSDs out, related to Mandriva's?), not because they were readily ready for stable use. I've seen this since I got my brand new AMD Athlon 64 "OS-proof" white box (all-generic components) some months ago and tried first to install 2006-64. Whatever you attempt, installer simply fails to see the SATA disc, or if it does, Lilo fails to boot (but it in fact loads!) after one hour of butt-painstaking installation and update-download. First of all, disable all new-tech disc features in BIOS, and wherever you find it, choose to make the disc appear as anything but RAID (i.e. PATA, IDE, etc.). May be the case (as sometimes is mine) that Mdk installer sees disk only if RAID is active in BIOS, but after installation never boots, or if it boots, your Windoze system partition results unreadable for Win-loader (but it also loads!)... If you don't want dual-boot, play a little with that of Raid-noRaid thing. But if dual-boot is a need for you (i.e., your wife doesn't know of anything but Windoze), try installing an i586 (32 bit) version by now, noRaid BIOS mode. MDK LE2005 (mostly) and 2006 (less) for i586 pass neatly over SATA recognition most of times; it's a pity to have a Ferrari running with a Civic engine (a 64 bit system stripped to 32 bit), but it will work while full-fledged x84-64 versions arrive (let's later talk about X server issues in 2006-64) and, of course, usable 64bit apps.
  4. As an Spanish-speaking user, every time I have to install Samba I find that my accented vowels and 'ñ' dissapear when browsing smb-servers in Windoze Explorer or Crapintosh Finder, same as I've read happens to German-speaking users with umlauts ans ess-tset. So, if you use a Latin-based alphabet, here's my recipe: 1. Set your global environment encoding to ISO8859-1 (I use Konqueror > Preferences > Configure > Fonts; notice this may not work with other environs, text or graphic, but KDE is the one and almost only for me). 2. Find and edit (maybe as root) smb.conf; don't ask me where it lives, I'm an almost-newbie, so perform a local search and edit it with the tool you feel most comfortable; I suggest Swat or Webmin, better the former. 3. Write these values in "[global]" (literaly; copy-paste this if you want): [global] dos charset = CP850 unix charset = iso8859-1 display charset = LOCALE In Swat, go to Globals > Advanced, type those values and click on "Commit". 4. Save smb.conf and restart Samba. I don't assure it will work for you, I don't even know if it works the same in all Samba versions, but there is where I head to every time I have to setup a new Samba server. As far I've read in forums, the main thing is to first tie your environment to a concrete encoding, so don't ever let that line blank or as "environment default", "local language default", etc. For Latin based alphabets, always try first ISO8859-1 in your environment and "Unix charset", if that doesn't work, try ISO8859-15, and if that either, ISO8859-13. Last resorces are ASCII and CP-850 (this may be needed if you have a disk with very old DOS partitions or old-DOS-long-filenames, but your Ext-2/3 partitions may then suffer). If you're working on a multiboot PC with preexisting Windoze partitions, don't install your *n*x with "Unicode as default", 'cause that will mess all their special-char-filenames (well, they remain ASCII or CP850 correct, but *n*x won't translate them well, and if you retype them, then WExplorer will also scramble the Unicode chars). As far as I've experienced, the holy grial of correct encode-mangling is to first install *n*x on a fresh new PC with "Unicode as default", later install Windoze (NT family is less-worse) and also pick Unicode as default, and then, afer a good reboot, begin creating special-char filenames. Removable FAT, FAT32 and NTFS media should be expected to have ISO8859-15 encoding, which you can configure in Drakconf. Good luck.
  5. Maybe after an upgrade, or even a reinstall over an old installation, filenames in your Windoze partitions (FAT and NTFS) show no special characters at all (console), these are shown as two wide spaces or grayed blocks (konqueror) or appear as "?" with the note "invalid encoding" (Nautilus). If this is the case, don't rename the affected files or directories, because that would cause further problems when you reboot on Windoze. Go to your start menu - System - Settings - Other - Localedrake (system) and uncheck "Unicode as default", after verifying your LOCALES is right. Repeat the same with Localedrake (user). [moved from Installing Mandriva by spinynorman]
  6. Newbie? Welcome, me too... I'm a years-long newbie, it means, an average-desktop-user fed up of Crapintosh and Windoze. Hope my experience as end-user is useful to you. 1. Murphy (the one of the so-called laws) and adamw are right: if it isn't broken, don't fix it. I mean, if your Lnx box gives you all (or the most) you _really_ need to work, leave it as is. Very frequently, we the newbies mess all up just because we want a new Windoze or Crapintosh-like eyecandy (KDE 3.3 sound scheme is wonderful, btw). Once solved the bugs in 2.4 kernels, you'd better stick to your Mdk distro, which may run on a very realiable and versatile 2.6 kernel. If it doesn't, keep reading. 2. The most _apparently_ friendly way for an average-desktop-end-user (everything is done from the graphic environment tools) is to add the 2005LE sources in MDK Control Panel, and in "Install software" option you'll get all you need to upgrade. I began upgrading KDE to 3.3 (otherwise process was aborted by inconsistent dependecies), then the rest. I recommend you to stop afer upgrading your preferred desktop environment or window manager, and installing the latest bugfixes... In my case, I didn't obbey Murphy and it was all messed up until I restarted session, afterwards, some icons (and entries in more than a case) were lost in the KMenu, and some apps were removed and not-always substituted (ie, I can't control my CUPS from web-browser anymore; Mozilla was kicked off by Firefox... But my by-hand-installed Netscape was fixed). That was yesterday, and today I found the PC didn't shut down (X server kept alive all-night long), the restart got frozen and I had to boot Windoze to open this forum and find some workarounds. 3. The _real_ friendly way is to download and burn/floppysave an installation boot image, or burn the installation ISO images (I prefer the little-CD-ROM "boot.iso" for ftp installation) and startup your PC from disk, then select "upgrade". The process goes much smoother, be using CD-ROMS (much faster) or FTP (sometimes very slow). I stopped burning CD-ISO's when I found that my drawer was topped with Lnx distros, and don't trust floppies since a lot of installation attempts got miserabily stalled by read-errors. 4. As a five-year-long Mdk user (since 8.1?), I recommend you to make a fresh install; you'll avoid a lot of head-sratching, unless you have a good bounch of third-party plug-ins, add-ons, not-mdk-specific apps (count here your Wine and Windoze apps), patches (see the one I got for K3b) and weird customizations (ie, very personalized mount points for Windoze, SMB and removable partitions/discs/filesystems). 5. Evenso, you may preserve a variable amount of these customizations if you choose "fresh install" without reformatting and let the installer to overwrite files with newer versions. You'll get some fragmentation, but nothing that drops performance. Almost certainly, you'll loose patches for a lot of standalone binaries, ie, cdrecord, so backup the most you can. Be prepared for some mess after restart. 6. Again: think twice and trice and better leave it as is, and if you insist (or really _need_ to, ie, upgrading to 2.6+ kernel), make a fresh install, Lnx partitions reformating included.
  7. If you burn a CD in K3B with "Start multisession" option, you may get a corrupted disc, unmountable and unreadable by almost any general purpose computer. This happens because cdrecord is called with "-xa1" flag, wich forces a very uncommon disc format. There's no way yet for the average desktop user (like me) to change the command sent by a frontend like K3B, so, if your frontend doesn't allow to change the command line in the Preferences or Configure windows, and thus delete or replace the "-xa1" flag with "-data" (so your disc has the most-common format), you may need a hack to get rid of it. Here's the one I found (http://www.linuxquestions.org/questions/ar...005/05/3/283857), translated to more understandable terms: 1. Quit all your CD burning frontends. 2. All this must be done as Root, so you may better work in a Root terminal or start a Konqueror-like graphic file manager as Root, with terminal emulator enabled. 3. Find cdrecord (type "which cdrecord" in your terminal). 4. Create a script with a plain text editor: # replace "-xa1" with "-data" re_match="-xa1" replace="-data" parg=$(echo $* | sed -e "s/$re_match/$replace/") #echo "$parg" /usr/bin/w_cdrecord $parg 5. Save it as "cdrecord-wrapper" in a new directory inside the one you found cdrecord (here, "/usr/local/bin/patch/"). 6. Enable all permissions on cdrecord-wrapper for everybody, including the execution ones. 7. Rename cdrecord to "w_cdrecord" (select the icon and hit F2; in terminal, type "mv /usr/bin/cdrecord /usr/bin/w_cdrecord"). 8. Make a symlink in the same directory where you found cdrecord (now, w_cdrecord) called (of course) "cdrecord", that points to the script (type in terminal "ln -s /usr/local/bin/patch/cdrecord-wrapper /usr/bin/cdrecord"). _Don't_ create a symlink with the graphic file manager, it may not work. 9. Leave immediately Root mode (close your Root terminal or graphic file manager). 10. Start K3B or your preferred frontend and give a try. If K3B finds any problem with permissions, it will guide you to fix them. You may also need to open Preferences > Configure K3B... (with dots) > Programs, select "cdrecord" and click on "Find". Toys like "magicdev" or "automount" may crash your burning process, so you better disable or kill them before starting K3B. I found this mandatory to continue multisession discs. ** Silly question I don't want to answer with my own box: May it work if instead of making a "cdrecord" symlink to the script this one is named "cdrecord" itself and saved in /usr/bin? [moved from Software by spinynorman]
  8. Not in my box. It runs Mdk 10.1, which is the one that best suits my needs.
  9. Nope. Not in Mdk 10.1, which is the one I have in my box.
  10. Kill MAGICDEV with KDE System Guardian. That's all, or is for my box. You can re-enable it later from command-line typing "magicdev". I had to download and run NeroLinux to have understandable advice on how this fancy process blocks burners, and in fact, as soon as I ran K3B without MD, my multisession problem disappeared. Nero, well, it never saw the burner in the choosable recorder list, even after killing MD, but ¡thanks for the advice! Maybe it'll now be the "DMA disabled" thing it complains about, but K3B can live perfectly with that, so I stick to K3B. Now I'll do some try-and-fail so K3B stops duplicating files (8.3 names in new session) and shortening names, despite my saved preferences. So, you the fine and wonderful KDE people, please add an advise under "continue multisession" that tells us, K3B users, to do so, or point us to a K3B patch or routine that overpasses magicdev.
×
×
  • Create New...