pmpatrick

For a keyboard sequence, if you do Ctrl-Alt-Backspace, the X server will be killed and you automatically go back to the login screen. If X is locked up pretty good, sometimes that won't work. You can then try doing CtrlAlt-F1 or F2 which will take you to a virtual terminal(no X) with a command line login. Login as root and run "reboot" from the command line. It seems to me that on a cold boot, your wireless card is simply not detected for some reason or another. eth0 is assigned to the first network device that your system tries to bring up and the orinoco driver is associated with that interface so that driver is loaded and associated with your intel nic which won't make it function and no other nic is detected. Later in the boot process the eepro driver is loaded but too late. It could be hardware related in that the wireless card needs time to "warm up" in order to be detected which would be the case on reboot. If that's the case, removing the modules and reloading may work. A lot of times when you modprobe a module, it loads not only the module you designate but also some some subsidiary helper modules as well that it depends on. When you try to rmmod the module, it won't let you do it until you remove the helper modules first. That's the reason for the error message. If you did rmmod orinoco_cs followed by rmmod orinoco, that should have worked. But there may be other submodules associated with orinico and you have to do them in the right order. You can tell all the modules in the orinoco family by doing: # lsmod | grep orinoco If your not using the wireless nic, here's what I would suggest. Remove the eth0 interface like you did in mcc. Remove the eth1 interface in mcc. After doing that, make sure ifcfg-eth0 and ifcfg-eth1 have been deleted in /etc/sysconfig/network-scripts; if not, manually delete them. Sometimes mcc forgets to do this when you have multiple nics. Reboot and make sure the orinoco and eepro drivers are no longer loading. Check with: # lsmod | grep orinoco # lsmod | grep eepro There should be no output with either command. Go back into mcc and select the option to setup a new interface>Cable or Lan. You should then come to a screen where you can select your standard intel nic to be associated with eth0 which will be the default selection. If it tries to force you to use the prism wireless card on eth0, tick the manual box and select eepro100 driver and proceed through the setup steps selecting dhcp. See if the network comes up Ok and see if it survives a reboot.

This is puzzling. Please describe your hardware. Without knowing that, I'm just playing twenty questions. In particular, do you have two network cards, one wireless and the other a standard nic and what brand are they? What steps have you taken to configure these devices? Is this a laptop and is either card a pcmcia card, your lsmod output would indicate that this is a laptop with a pcmcia slot? Driver modules are loaded differently for pcmcia card devices. I need some basic information on your hardware setup before I can help you further. At this point, I'm inclined to try forcing the orinoco driver to load from moprobe.conf or modprobe.preload since everything seems to work OK when it's loaded first. Please post both those files. Your dmesg output shows that your eepro card is assigned eth0 when the orinoco driver isn't loaded and the network doesn't come up and eth1 when the orinoco driver loads first with the wireless card being assigned eth0. It's obviously a timing issue but I have no idea at this point where the orinoco driver is loading from. Hopefully, some info about your hardware will help. We could try testing by removing both modules and reloading them in proper order when the network doesn't come up and see if that helps. You would do that with: # rmmod orinoco # rmmod eepro100 # modprobe orinoco # modprobe eepro100 Then try and bring the network up with: # ifup eth1 The boot codes I gave you are just that. The net effect of those boot codes is to disable acpi and apic or portions of it during the boot process. acpi/apic has been known to cause problems with certain hardware configurations. The noapic nolapic acpi=off can be thought of as a magical incantation to accompolish that. apic = Advanced Programmable Interrupt Controller acpi = Advanced Configuration and Power Interface lapic = local apic

My bad, that was a typo; the command should be "dmesg"not "demsg". However, I dont think you need to look there as it appears you have two nics battling it out, eth0 and eth1. One is a standard nic using eepro100 module and the other I think is using the orinoco module which is for wireless nics. Does any of this make sense to you re your hardware? I think we want to stop the orinoco driver from loading. You may also have another network confguration file, ifcfg-eth0 along with ifcfg-eth1. Drivers are generally loaded from one of two confguration files, /etc/modprobe.conf and /etc/modprobe.preload. Modprobe.conf is the more likely one. Open the file and look for a line that starts with: alias eth0 and put a # in front of that line to comment it out. That will stop the orinoco driver from loading. If you want, you can post the entire modprobe.conf file. Try rebooting and run ifconfig again. That will tell you what interfaces are there. The problem is that the first network interface loaded is designated eth0 and the system may insist on designating the former eepro eth1 interface as eth0. Post back with your results and we'll try to sort it out. If you're not using the wireless orinico nic in linux, it shouldn't be any problem to properly configure your regular nic.

I just installed Photomatrix on linux with Crossover Office and it runs fine. You could probably get this to run with wine with a little fiddling.

All of what Mhn asked plus can you su to root in a console from a non-admin account? You should note that root logins are disable by default with ssh and with a gui. You have to login as an ordianry user and su to root in a console. Also, if you have your security level set at "5", I believe that is the "Paranoid" level and I'd imagine that root logins in general are prohibited there. It's a security measure. In order to breakin, some one would have to crack an ordinary user password and then crack your root password for root access.

You can get all your boot messages that the kernel generated by opening a console immediately after booting and running: $ demsg To save to a text file for easier viewing run: $ demsg > demsg.txt A running log of this output can be found in /var/log/boot.log. Just to rule this out, try passing these boot parameters by hiting the Esc key as soon as you see the lilo boot selection screen which will take you to the boot prompt. At the prompt type: linux noapic nolapic acpi=off The first word "linux" refers to the lilo entry you are booting which is "linux" by default in mandriva. If you normally boot a different entry, use that name instead. All the available lilo boot selections will be printed out on the top of the screen just above the boot prompt. See if this has any effect on your network problem. This will disable acpi which has been known to cause problems with certain nics in the past. To verify that it is a module loading problem, after booting and the network not coming up, run as root: # lsmod that will list all the loaded modules. See if you can find your nic module in the output. If you nic module is loaded, check the output of: # ifconfig and post back here. Also, check your network config file which is: /etc/sysconfig/network-scripts/ifcfg-eth0 and post that here as well.

I think Tux Magazine has shut down for economic reasons: http://www.desktoplinux.com/news/NS5510030186.html So, if there is demand for this kind of magazine you won't be competing with Tux Magazine.

Add this to the end of your /etc/rc.d/rc.local file and see if it helps: ifdown eth0 ifup eth0 rc.local is the last init script to run. I agree with arctic's observation that the nic driver may not have fully loaded at the time when the network attempts to start up. By restarting the network at the end of the boot process, you can get around this potential problem. The above assumes your network interface is eth0 which may not be the case if you are using a wireless connection.

Oh, it's a bug alright. It may only show up on certain hardware but it goes away when you use gdm, is absent in gnome and went away forever when I updated kde to kde 3.5.4 from mandriva kiosk: http://kiosk.mandriva.com/ but you need to be a club member to access those rpms. All that without doing anything to acpi/apm. And your right about the limitations of using gdm with kde; you can only logout and then you can shutdown/reboot from within gdm.

I had the same problem with mdv2006. The only way I could shut down was to open a console, su to root and run "reboot" or "shutdown now". It's a bug in mandriva's implementation of kde and kdm. You won't have this problem in gnome/gdm IIRC. You can change your dm(display manager) from kdm to gdm in the Mandriva Control Center and see if that helps. The dm controls the login screen you get. IIRC if you change it to the gnome dm, gdm, you can logout OK but you have to go back to the login screen and select the shutdown option from within there. You can't shutdown directly from within kde; you can just log out.

You can check in mcc under Services or you can run as root: # chkconfig --list to list all available services and their status for every run level. For just sshd do: # chkconfig --list sshd

You can easily change the resolution in kde if that's what you want. There's a kde tool called krandr which is in the Kmenu on my box under System>Configuration>Hardware>Screen Resize and Rotate. When you run it, it will put a little blue rectangle icon in your taskbar at the right end. If you click on that icon, all the available resolutions will be displayed and you can select whatever you want. This tool is also embedded in the kde Control Center under Peripherals>Display. If you have kde set to restore the previous session(default configuration), the icon will be there after rebooting so you will always have it there to change the screen resolution.

For anyone else wondering about this issue, from the ndiswrapper FAQ: So if you want to use ndiswrapper on a 64-bit rig, there must be a 64-bit windows driver for it. You cannot use the 32-bit windows driver.

Right click on the window title bar and go to Advanced>Special Window Settings. In the popup window go to the Geometry tab and tick the Full Screen box and in the menu across from the box change the selection from "Do Not Affect" to "Force" and tick the box to the right of the menu. The next time you start the app, it will start full screen without any window border/title bar no matter what resolution you are in. You can no longer change the window settings with the mouse so if you want to do that, you just hit Alt-F3 and the menu you get when right clicking on the title bar will reappear. From there you can go into the Advanced window settings and change whatever you want.

That difference between the gateway ip and the network ip is normal. Here's my routing table which is pretty vanilla: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 10 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.1.1 0.0.0.0 UG 10 0 0 eth0 I agree that the routing table seems wrong - it has no entry for 127.0.0.0 and he has no idea what 169.254.0.0 is. All this points to a misconfiguration of the network probably caused by the botched attempt at configuration using the mcc tools. Rather than trying to track down exactly what went wrong, I would suggest removing wlan0 using the mcc tools. Make sure that ifcfg-wlan0 is deleted in the process. If not, delete it by hand. Then confirm that wlan0 is no longer up by opening a console and checking with: # ifconfig There should be no entry for wlan0. Wlan0 should still be detected with iwconfig if the ndiswrapper is still loaded. Confirm this is the case with: # iwconfig If it's not there, load the ndiswrapper driver and check again with: # modprobe ndiswrapper # wlan0 Assuming wlan0 is detected, I would try to get it running from the command line. First, for simplicity, disable any encryption from your router. Then run: # iwconfig wlan0 essid <insert your essid name> # dhclient wlan0 If it doesn't hang on dhclient and report an error, this should connect you with your router using dhcp. Check that everything is OK by pinging your router and running route -n. Then see if you can get on the internet.

See if the card is detected from the command line with: # iwconfig If it doesn't show up or reports that wlan0 has no wireless extensions, it's probably a kernel problem. Ndiswrapper breaks frequently with new kernels, particularly smp kernels. You just have to wait till they update ndiswrapper to be compatible with the new kernel. Alternatively, you could get the rpms for the mdv2006 kernel and kernel source and try installing that kernel on mdv2007. You will have to reinstall ndiswrapper on the new kernel but it should work if it's a kernel issue causing the problems.

That card certainly supports resolutions greater than 1280x1024: http://reviews.cnet.com/eVGA_com_e_GeForce...7-30422569.html See the above link. Unless you are talking about the max resolution that you can play a certain game at which may very well be limited to 1280x1024 at the max color depth. However, to answer your question, assuming you already have mandriva setup for the new 21 inch LCD, you probably won't have to do anything. I just upgraded from a 5900 ot a 7600(AGP) myself and didn't have to do anything but I reran the nvidia driver install just to be on the safe side. Worst that will happen is you will have to reinstall the driver. I would disable hardrake in mcc>System>services. Hardrake picks up new hardware on boot and may try to install the open source nv driver for your new card.

Post your /etc/X11/xorg.conf file. That's the graphics configuration file. I pretty sure you can edit that file to get the behaviour you want. If you look in the "InputDevice" section, you should see a line like: Option "MaxTapTime" "<some integer>" If you set that to: Option "MaxTapTime" "0" That should disable tapping on the pad. You need to be root to edit xorg.conf and the changes won't take effect until you restart X.

There's a lot of different ways to do this depending on the ".run" file. But you usually have to make the file executable before anything will happen. Open a console and run: $ cd <path to directory with .run file> $ chmod +x <name of .run file> $ ./<name of .run file> If this is not clear, post back with the specific file you are trying to run and any questions you have about the above commands and I will go into more detail.

I'm sure rc.local is running. To test put this in rc.local: echo "I am running" > /home/<username>/test.txt Anyway, if rc.local wasn't run, error.txt could not have been created. It seems denyhosts may be running but not be picked up from what you say. See if the process is picked up with: $ ps aux | grep denyhost

Here's the link for the Ultimate Boot CD: http://www.ultimatebootcd.com/ It's a great tool to have.

Truer words were never spoken. My experience is the exact opposite of ian's right down to the shutdown issue. I couldn't get mdv2006 to shutdown, no problem with mdv2007 on one box. Mdv2006 works perfectly to this day on an Acer centrino laptop with intel integrated graphics. It all depends on your hardware IMHO.

After you boot, can you get rid of the module by running: # rmmod snd-usb-audio If you can, then you can get rid of the module by placing that command at the end of /etc/rc.d/rc.local with: # echo "rmmod snd-usb-audio" > /etc/rc.d/rc.local

I was going to suggest adding yourself to the disk group.

Open a console and run: $ top which will give you an ongoing printout of ram and cpu usage. On a P4 3.2GHz with 1GB of ram, when I hit the install software button in mcc, the cpu pegs at 90% for several seconds until the software selection screen comes up. I can only imagine what it does on a P1. Reading the availble software database is apparently very cpu intensive. ian's suggestion may help since you are dealing with a much smaller file, KBs instead of MBs.