scoonma

Hi Ian, you wrote: I found CuteCom, which is quite up to date: http://cutecom.sourceforge.net/ Maybe later you find this handy (serial/net proxy): http://sourceforge.net/projects/ser2net Have fun, scoonma

You should also check your firewall settings. If it's up and running during connect: Can you accesss webpages when it's down? HTH, scoonma

Hi Lando, you wrote: The syntax you presented above reminds me of tcsh. Bash is different in treating variables. Please try the following pattern: #$> JMFHOME=/home/lando/JMF-2.1.1e ... You can check by #$> echo $JMFHOME HTH, scoonma

Hi Per, you can have multiple FontPath entries to your xorg.conf. Just put in all fonts you need. (100dpi, 75dpi, Speedo, ttf, Type1,...) I don't know much about KDE, but if it's using other fonts, you should add them too. HTH, scoonma

I've used etc-update but this was doing no good. After rebooting, the whole filesystem was crashed beyond repair. There must have gone something deeply wrong. Now I've reinstalled from scratch (everything except /home) and the system runs fine again. But I hate this sort-of windumb method for fixing... Thx nonetheless! scoonma

Hi aioshin, you wrote: Tried, but it didn't help. I'm suspecting an issue with pam now. But re-installing passwd and pam didn't help either. Too bad! scoonma

Thx for your hints! However, the error resists. Shell is /bin/bash, (as normal). The .bash* files within /home/user dir are all intact (and are rarely touched). When creating new users, their accounts suffer from the same problem (i.e. su/login not possible). The corresponding directories are created though, also the defaults from /etc/skel are copied. I did some further googling and found this page: http://www.wlug.org.nz/EACCES. It states that the EACCES error mentioned above is likely being caused by file permission conflicts, but I don't know which places I still haven't checked. Last "candidate" was /bin/bash; I changed permissions from rwx------ to rwxr-xr-x, but this didn't help either. The offending place must be rather central, but not influencing the root acount in this regard. Hm.

Hi Ian, thx for your fast response! I've done/re-checked what you suggested (/home dir exists, has correct permissions, ...), but unfortunately it does not help. The clue must be located elsewhere. When being root, "su clamav" or "su adm" (or any other user) do result in the very same error: "could not open session". This is why I'm so puzzled. Regards, scoonma

Hi all, I recently stumbled over a strange problem of similar type Urza reported of: Unable to login as *any* user, I still can login to the system (Mandriva 2007 cooker) as root. Trying to login as normal user from console (i.e. "login: " prompt, the system kicks me out immediately. By lowering processor speed I was able to see the small error message: It says there is no home directory for that user, but it actually exists! There is no kernel message giving any hint on "F-12 console", no valuable information on /var/log/messages or /var/log/secure. When trying to "su <user>" after root login, the only error is "could not open session". By googling I found out that this could be caused by file permissions wrongly set. So I've checked the following (which should be okay, AFAIK): /etc drwxr-xr-x /etc/pam.d drwxr-xr-x /etc/passwd rw-r--r-- /etc/shadow rw------- It does not matter wether trying to use an existing user in /home or after creating a new one with "useradd", so it's likely to be a system wide error. Last option that came to my mind is to use strace. I tried "strace -oout.txt su <user>" and found the following: [...] open("/etc/pam.d/other", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=154, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "#%PAM-1.0\nauth required "..., 131072) = 154 read(3, "", 131072) = 0 close(3) = 0 munmap(0xb7d01000, 131072) = 0 getuid32() = 0 getuid32() = 0 open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340 close(3) = 0 munmap(0xb7d01000, 131072) = 0 time(NULL) = 1155194279 getuid32() = 0 getuid32() = 0 open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=1340, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 131072) = 1340 close(3) = 0 munmap(0xb7d01000, 131072) = 0 open("/etc/shadow", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0600, st_size=831, ...}) = 0 mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7d01000 read(3, "root:$1$pAlg6jqo$Q4EOt4pn2aApAsq"..., 131072) = 831 close(3) = 0 munmap(0xb7d01000, 131072) = 0 time(NULL) = 1155194279 setfsuid32(501) = 0 setfsgid32(501) = 0 access("/usr/bin/xauth", X_OK) = 0 open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/ld.so.cache", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/tls/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/tls/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/i686/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) open("/usr/lib/libnss_compat.so.2", O_RDONLY) = -1 EACCES (Permission denied) getuid32() = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 readlink("/proc/self/fd/0", 0x8055f70, 4095) = -1 EACCES (Permission denied) fstat64(0, {st_mode=S_IFCHR|0600, st_size=makedev(0, 0), ...}) = 0 stat64("/dev/pts", 0xbff16878) = -1 EACCES (Permission denied) open("/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 EACCES (Permission denied) getuid32() = 0 time(NULL) = 1155194279 open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) open("/etc/localtime", O_RDONLY) = -1 EACCES (Permission denied) socket(PF_FILE, SOCK_DGRAM, 0) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 EACCES (Permission denied) close(3) = 0 write(2, "could not open session\n", 23) = 23 exit_group(1) = ? Any ideas please? Greetings, scoonma [moved from Software by spinynorman]

Hm. Me finds a new structure, too. But the difference seems to be that the actual packages now reside one level deeper, i.e. in /media/main/release instead of /media/main (same goes to contrib,...). The media_info dir containing hdlists is still below. Kind regards, scoonma

If you could not manage to fix this in the meantime, the following may help: 1. Find out the "real location" of your (X11) fonts. After the last cooker update, this is /usr/share/fonts on my system. 2. Create one or two symbolic links pointing from the old location(s) to the new one: "ln -s /usr/share/fonts /usr/lib/X11/fonts" "ln -s /usr/share/fonts /usr/X11R6/lib/X11/fonts" If (one of) the latter doesn't help, please check the X11 error message in detail and adjust the softlink target appropriately. Good luck, scoonma

Hi Urza, you wrote: Maybe this article will help you: http://linux-net.osdl.org/index.php/Bridge However, this is background explanation, too. But it also contains a link to sourceforge. You can find a tarball for bridge-utils here: http://sourceforge.net/project/showfiles.p...ackage_id=17598 Good luck, scoonma

Hi Ian, you wrote: GNOME is relying on cairo. Regarding the memory issue: I am used to having this prob some time, but never was really able to find out the reason (i.e. the actual task causing the leak). When using "top", can you see memory being eaten up slowly, too? Do you have any zombie tasks lying around? Maybe we can work this out together. Kind regards, scoonma

Hi Per, you wrote: Maybe the "chkfontpath" command fits your needs. You can see the options by "chkfontpath --help". Good luck, scoonma

ld.so.conf is the configuration file for locations of shared libraries. With standard options all library installations from tarball sources in Mandriva go into /usr/local/lib. So you should add the line "/usr/local/lib" to your ld.so.conf file. (See also http://www.daemon-systems.org/man/ld.so.conf.5.html ) Then update by "ldconfig". If pkg-config is still unable to find atk.pc, you can use the environment variable PKG_CONFIG_PATH: (From http://www.die.net/doc/linux/man/man1/pkg-config.1.html ): "PKG_CONFIG_PATH A colon-separated (on Windows, semicolon-separated) list of directories to search for .pc files. The default directory will always be searched after searching the path; the default is libdir/pkgconfig where libdir is the libdir where pkg-config was installed." You can do this by simply typing "PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig" before installing gtk.This will add the local lib path of pkgconfig to the old (standard) path. Good luck! Scoonma

Hi Urza, I'd do the following: 1. Check wether the required version of atk is actually installed. Installed packages should show up at typing "pkg-config --list-all". 2. Sometimes you have to enter "ldconfig" as root after installing from tarballs. 3. If the above does not help, check your /etc/ld.so.conf. 4. Maybe update pkg-config, too. 5. Find your atk.pc by using "locate or slocate" Which system are you installing on? Mandriva doesn't like mixing up builds from source and .rpm package installs that much, if you're not really experienced. HTH, scoonma

A (very short and abstract) concept of a firewall is as followed: LAN ----- DMZ -------- Internet Servers in the DMZ are partially exposed to the internet, (i.e. why the zone is DM,no?) Where is your router within this sceme? Where is your Laptop? Regards, Scoonma

Hi all, in the process of upgrading to new Mandriva versions I found it more or less regular that haldaemon refused to start during boot. Entering "service haldaemon start" manually as root often did not help either. The problem seemed to be quite common considered to google hits. hald does not write an error log by defaul and without an error message on console you're stuck at first. (hal can be hell...) The purpose of hal is to present a transparent userspace layer for hardware accesss (HAL=Hardware Abstraction Layer). This is important i.e. for USB device access and many other type of hardware from Gnome-Desktop, for example. Relying on udev and dbus it builds a database for further use. Most important is dbus/messagebus: hald won't work without. Messagebus has two components: One for the system side (which should be running now) and a user component. The system component starts first after booting (and probably you've managed to get it running so far). The user component does not start until "X" is started. So it's handy to care 1. for the system component, 2. then for hal, and 3. finally start X to let GDM or KDE or... (hopefully ;-) run the user component of messagebus fine when the rest is okay. So you could do the following: Start your system into console mode. Udev should be up and running. You should be root (su root, then give password) and type: "service udev status" If it's not working properly, make sure it does. Do an update if possible ("urpmi udev"). Typing "service messagebus status" should result in a message that dbus-daemon is running with some PID number. This is the process ID of the dbus-system part. hald will try to connect to it. You can check the number by using "ps". The number printed out should be identical to the entry in line with 'dbus-daemon --system' here (ps output). Note that names can be somehow confusing at the beginning: 'dbus-daemon' is the program actually run, 'messagebus' denotes the according service. For hal it's 'hald' (actual program) and 'haldaemon' (service). You can find the configuration files of messagebus in '/etc/dbus-1'. This is the place you should begin consistency checking if something is wrong. Closely inspect the system.conf. Hal attaches to dbus not only through the PID given here, but also relies on the local socket. So the most important entries here are: <pidfile>/var/run/messagebus.pid</pidfile> (The process id number you should have seen) and <listen>unix:path=/var/run/dbus/system_dbus_socket</listen> Now messagebus and haldaemon shall both be started at boot time. Hald is invoked from /etc/initd./haldaemon. For messagebus we have /etc/init.d/messagebus. The names of the services and processes are given here, too. So check /etc/init.d/messagebus, wether it contains the same full path entry for the pid file as given in /etc/dbus-1. Be aware of overall consistency! You could search for hours, when in one place 'dbus-1' as a path component is given, but another config file tries to access .../dbus/... (i.e. socket path in /etc/dbus-1). So hopefully you managed to get messagebus up and running by now. Hald builds his database by looking at your hardware. If typing "service haldaemon start" still won't work, you could do this by typing the following: "hald --verbose=yes --daemon=no" It prints out a big bunch of messages (use Scroll & Stop on keyboard to check). This can take a few minutes, depending on your hardware. But finally when it comes to an end the database should be rewritten and ready to use. Exit with Ctrl-C and try again: "service haldaemon start") If something goes wrong, you could check hal.conf (residing in /etc/dbus/system.d/ ). Sometimes it's necessary that hal's policies are being updated. So you could do the following: 1. Find out the package names of hal and libhal ("urpmq hal" and "urpmq libhal") 2. Force-delete these packages (i.e. "rpm -e --nodeps libhal0"; "rpm -e --nodeps hal") 3. Reinstall hal: "urpmi hal"; "urpmi libhal1" (or "urpmi libhal0") Then step back to rebuilding the hal database. Afterwards you may be able "service haldaemon start" successfully. The rest (i.e. invoking the user-components of messagebus) should be done automatically by your X system. Try "startx" as normal user from console and see if it works. Good luck! Scoonma See also: HAL: http://www.freedesktop.org/wiki/Software_2fhal (Messagebus is from GNOME, server actually in transit)

It was not the BIOS settings, but me not yet being fit enough to make a proper kernel. ;-) The sources strongly suggested to build the proper ide-module fix into the kernel, when booting from an ide drive. I was trying to do that, but also included generic IDE built-in, not as a module. Now generic support is only accessible as a module - and hooray: it works! (First time I've not only managed to build a working kernel, but also an actually usable one. :-) Greetings, Scoonma

Hi all, very nice forum here! Maybe someone can help me on this topic: ATM I'm trying to get this kernel (2.6.18-rc1.2) running 66Mhz instead of 33Mhz on the PCI/IDE bus. Actually, hoping the new sources would support my Jetway N2PAP Ultra board, but no way. BIOS version is A10 (up to date). The documentation says I could set a kernel option: "idebus=66" when starting, but it won't work. After bootup /var/log/kernel/warnings there's always the following entries: Jul 13 08:50:28 radon kernel: NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. Jul 13 08:50:28 radon kernel: NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround. Jul 13 08:50:28 radon kernel: NFORCE2: User given PCI clock speed impossible (66000), using 33 MHz instead. Any ideas please? Kind Regards, Scoonma

If you're able to mount the disk again, this tool might be helpful: http://jbj.rapanden.dk/magicrescue/ Good luck, Scoonma

Running Mandriva 2006.1 with a Radeon 9600, after many tries I found out that using ati-xorg plus dkms from plf worked fine (inlcuding 3D support). Choosing this method, you should discard all propriatary (fglrx) drivers. The driver will be compiled against your kernel (automatically) before first use, so you also need the sources matching your kernel, too. HTH, scoonma

Actually, it *has* something to do with your kernel and it's version. However, it's possible to keep different kernel versions on one system. To be sure which one you're using, type in the following in a console window: "uname -a" The output tells you the correct version. Regards, Scoonma

Hi all, I'm ready to share my experiences with GARNOME on Mandriva here. It's not that it cannot be done, but it really takes time. You should reserve two full days on a 2GHz i686 machine building (ccache enabled). This is not due to compilation time, but you'll have to work around some errors here and then, even using the stable version. However, it *is* an interesting adventure (you'll probably not succeed with all packages). If you *really* want to get to know your desktop system, have it a go! Still you should have done some smaller projects yet. Sometimes you'll have to set config values, sometimes do minor changes in the Makefiles. In that case you should also join the GARNOME mailinglist. On the other hand, if you just want to use an actual gnome build (or move on from 2.10 because of the errors, as my first intention had been), I'd suggest using the cooker. Even being alpha now, it's *a lot* easier to route out user config errors than fiddling with the system itself. I can also recommend Linus' latest kernel, works fine here (even got ati 3D hardware acceleration working now!) Regards, Scoonma