Vdubjunkie

vi /etc/inittab change "id:5:initdefault:" to "id:3:initdefault:" and get used to the following new commands... startx shutdown -h now shutdown -r now just my 2 cents

I've never found that running WindowMaker. I do also have ample memory, so perhaps that is part of it. Or maybe it is the fact that my desktop is a aesthetically pleasing manner of running multiple terminals a lot of the time.

I may have misread this, and apologize if I did, but I think arthurking is saying he cannot map shares on his XP box shared by his nix box. If that is the case, the first thing I would do is ditch the gui... anybody know me not see that coming? Open up two terminals. Su to root on both and "killall smbd" "killall nmbd". Then on each terminal "nmbd -i" and "smbd -i" on the other. Nmbd won't likely help you much, but it is all interesting to watch anyway. Watch that smbd as you try to connect. Other things to look over are to visually inspect the /etc/samba/smbpasswd file to ensure the user you are logged in as on the XP box is in there. Once you are sure it is in there, make sure it also exists in /etc/passwd and /etc/shadow (this last one keeps you from having to go plain text on passwords). Once you see that they all exist, sync up the passwords with the following: passwd <username> smbpasswd <username> All of this is to be done as root. Another nice thing to do on the nix box is to perform a "testparm" to make sure all your syntax is good in /etc/samba/smb.conf and then a "smbclient2 -L localhost" or "smbclient -L localhost" for those running pre 2.2.8a. That will show you everything "you" are sharing. Ok, hope this helps. If not, let us know. I have a pretty good amount of experience with Samba troubleshooting as I run a decent little sized mixed network.

I read a post from a guy (touting another distro) and he talked about something called cdbakeoven. He compared it to some of the best doze progz out there. Not certain it does that, but I bet it does. Worth looking in to. If I remember correctly, when I looked for it, I did not find it in rpm, but just source. :o

This may not have any merit whatsoever, but also comes to mind that xine and Totem may not have "been aware" of those during compilation if you used that method of installation. I've run into that type of thing a whole lot.

This is actually my preferred method of running programs. You get so much more information that way. Plus you can run them as other users when you want. As nice as a menu is, I nearly never use it.

That's not very phunni man!! Hey, when you find out, let me know so I can tell my nix + guitar buddy, alright?

I have to admit, these would have been my answer to the problem.

A follow up to my last follow up: I've abandoned killall -HUP smbd and nmbd as I saw it fail me once. I'm critical that way. Now I take the longer route of "killall nmbd" and "killall smbd" followed by "nmbd -D" and "smbd -D". Also, nmbd is strictly supposed to be about name resolution and what "level" your samba server is, etc., but I typically go ahead and restart it too just to be sure even if I am just changing a share definition. I don't claim to be a know all on Samba, but I have done quite a bit of learning and use it a lot.

For those of you interested in the result of this, I have yet to actually replace the NIC, but after reloading a fresh install of 9.1 on this server to a totally different drive, I have made a not so big assumption that my NIC was to blame. I still find myself having to sign in and "bring up" my ethernet each time. It is always good to eliminate core and necessary software "glitches" as possibilities!

You may come to the point where you have to take drastic measures. Isolating the problems past all other variables. Despite the fact that it seems no hardware should be the problem, I cannot tell you how many times I started out with that idea only to be proven wrong later. Anyway, perhaps starting off with a crossover cable and having the two machines "talk directly" ensuring that both have static ip addresses in the same subnet. Then, if you still find problems you get on both boxes and take them both to minimal necessity operating daemons/processes. Not that this is directly relevant, but last night I banged my head against the wall for some time why my Samba on my server wouldn't work properly when the same version from the same rpm source worked fine on my workstation running the same version of Linux. Long story short was that I had decided to install prelude when rebuilding the server recently. It's default config was to blame. I have yet to figure out the software to see why and make it work for me, but when I stopped it from running on the machine, Samba was back to "normal." This is why I say you may have to work it down to minimal operating necessity in your troubleshooting. Effective troubleshooting is sometimes extremely taxing and tedious, but is ultimately based on one principal. Eliminate variables. Hope this helps man. I have been down this road more times than I care to count. Spent more hours than I would ever want to know...

I've partially delved into qcad (since it is free and I can afford that!), and it looks pretty good. I was working with it virtually, so the experience was not as good as it could have been, but I think it just may do what I need it to. At least if I cannot do a virtual walk through, I think I could make plans that could be used on a construction site which is what is truly important.

That response makes it all worth while. Thanks for the response. And on that note, I'm off to post follow ups in other posts I've made to finalize them with what I've "figured out" from them. :D

In case there are any other freaks out there like me willing to do things the hard way just so they know how it all works: I did figure this out myself. Synopsis: Existing server has it's OS reloaded to a new drive thus eliminating the drive with the existing OS. In the process, retain all possible settings, etc. Retaining many files (if not all) from the /etc folder especially /etc/raidtab in this instance was vital. Next, just to make sure years or data didn't get wiped due to some glitch or something, I unhooked all unnecessary drives while installing the new OS. (MD 9.1 in this case) After OS was up and running and all other important config files were in place for my normal operating purposes, I restored the /etc/raidtab file and rebooted not because it is the easy way out of starting everything up, but to ensure everything started properly from a "reboot" status.:deal: Much to my dismay, it choked on bringing up /dev/md0 and /dev/md1 in /etc/fstab. So, I went to a rescue boot from the install disks, commented out the appropriate lines in /etc/fstab referring to the /dev/mdX devices and rebooted. "rpm -qa | grep raid" told me that I didn't even have raid tools installed. "urpmi --media germanupdate raid" figured out for itself that the only appropriate rpm to install was raidtools-0.90-12mdk. After reading all over the place and banging my head against the wall, I decided against doing a "mkraid -f /dev/md0" for fear I might just lose data. Ultimately I decided to do a simple "raidstart -a" and I was nearly instantly back in business. Mount the devices (or more accurately mount the filesystems attached to the devices) and I have the remaining strongest majority of my important files available to me again!!

My advice is to learn vi. When you can't get to gui you have vi. When you have nearly nothing useful in rescue mode, etc. you have vi. http://www.ahinc.com/linux101/vi.htm It really isn't as hard as it seems. I started out doing things the slow way by only knowing the necessary stuff. Then I started picking up a new command each week and now I am pretty proficient. :woops:

Don't forget win4lin. My friend uses it and loves it. However, you are still bound by legalities of actually running win98. It is also about $150 I think. It literally runs windows better than windows runs windows. Of course dos would go along with it since you are actually running win98.

Hello all: I just upgraded 9.0 to 9.1 on my server the other day. Knowing it may cause problems I went ahead and made a backup of my pristine /etc directory and copied the entire contents of my old install's /etc over it. I then put /etc/fstab back in place and adjusted it because I knew a couple of things would be different there. Pretty sweet I must say. Upon reboot my system had the right name, ip, etc... However, I did not make backups of any /var items or anything else but /home really.:unsure: I do have two software raid configurations I would like to retain. I thought about doing a "mkraid -f /dev/md0" and md1, but I am afraid it may cause me to lose data. I already tried performing a "mkraid -u /dev/md0" and it reported nothing was able to be updated. Basically what I am asking is if anybody knows definitively whether or not I risk losing data by using the -f switch to "make" my raid devices over. I nearly just did it knowing I may lose years worth of data:screwy:, but decided to ask the MDusers community first.

I'm pretty sure that was fuzzy's logic initially

Cool, thanks guys. I'll have to check these out.

Actually I am running two separate video cards. I'm sure that makes a difference in the config file. I'm also sure I could find it on the net if I wanted to take the timeto search it out. It was low priority. Just thought I'd ride the coat tails of your post! jester

ok, you beat it out of me... :P I am very critical of software, and I really don't like obtrusive gui especially. Installation of Realplayer had always gone like this for me. Run install.. uncheck all of the CRAP I didn't want it to install complete install Run realplayer Find out that it totally ignored all of my desires in the installation config.. lovely, now it is watching everything i do and forcing things on to my screen then when you try to undo all of the annoying settings about it's interface it is impossible to find or doesn't work anyway. To boot, at this point in time I was installing it on a daily basis to several machines. If it annoys me that much it definitely kills non computer savvy folk, so I have to fix it for them. My ideal would be laying out a fat command line for the install putting it to the background and knowing that it would just go right and be right when it were done.

If I'm understanding what you want, it sounds like you want the "toolbar" across the bottom of both screens (not one separate for each side) and to be able to drag a window across both screens, yet not have full screen actually expand to both screens. If I am right in that, I don't think it can be done. However, I do fully admit I could be wrong, just think I read that before. Anyway, if any experts on the subject come along, I am looking to expand my desktop across both screens rather than having separate desktops for each screen. My code currently looks like this: Section "ServerLayout" Identifier "layout1" InputDevice "Keyboard1" "CoreKeyboard" InputDevice "Mouse1" "CorePointer" Screen "screen1" Screen "screen2" RightOf "screen1" #Option "Xinerama" What would I change?

Hello all, When I last installed a MD.. lemme see, a couple months ago maybe.. I noticed a software that claimed CAD type capabilities. I don't remember what it was. Anyway, I was hoping to make a full set of home blueprints all for free on my wonderful linux box. Does anybody here know of or suspect any softwares for such a task?

Anybody who knows me well on a computer level well knows my utter hatred for realplayer. I have even deleted files or not viewed clips I really wanted to see simply because I did not want to install realplayer so badly. My advice will always be to do anything you can to avoid installing anything realplayer puts out. On a related note, as a testament to the amount of love I have for my wife, at one point on a previous incarnation of a computer still running today I did install realplayer so that she could view some clips on the web. ok, so maybe that wan't necessarily useful for anybody, but it did me some good! :huh:

I don't know if you are up for it or specifically if it will work better on dial-up, but I understand Ximian's Red Carpet is absolutely amazing. I have used it a bit but I know of people who use it like crazy and find it bulletproof. It may be worth a try if you get desperate. Incidentally, I hadn't put much effor into Red Carpet yet because I have been having such good luck with urpmi since finding a really good source, but now my urpmi is broken and I am stuck. It simply hangs after downloading everything and beginning to attempt the install of the appropriate packages. Bummer. Anyway, if you want to give it a try, go to www.Ximian.com and check out Red Carpet. Oh yeah, you were told that it wouldn't remove a directory because of the lack of the -R switch. When removing an entire directory you want to use "rm -Rf <location>"