[arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???
Hi. I'm not that sure what's happening. But I just acquired an HP Pavilion desktop. (My Sister's Hubby just bought a new win 7 box and let me recycle his old xp box... I told him right away that I'd found the problem he was having with the old box, it was running windows...) Anyway it's got AMD 64 processor with a gig of ram, and integrated NVIDIA GeForce 6150 LE (which could be the problem for all I know. But since I don't give a tallywack about 3d acceleration I doubt I'm supposed to need to know much about tweaking NVIDIA graphics. Anyway I promptly used gparted to squeeze the existing winxp installed to the 200 gig sata harddrive down to only 70 gig, & attached an ide seagate 250 gig drive I'd had left over from my former (defunct) desktop which had died about a year ago. Making room for multiple Linux distros. Because PCLinuxOS features a "mylivecd" script that's designed to make it easy for non-experts to make fully configured and installable live cd/dvd images of their running PCLinuxOS installation, PCLinuxOS got the first install. But Arch was supposed to be the 2nd. I installed the core system from an archlinux-2010.05-core-dual.iso But since I already have a 64 bit Arch on my laptop I thought I'd try the i686 image on the desktop... Then I set up my user partitions via udev rule (I've named all my partitions cause something like LABEL=Arch_desk-7, & LABEL=PCLOS_desk-3 are much more human readable than any UUID={string} will ever be). Anyway, I updated the new Arch system and kept working on customizations. I kept getting interrupted so it was a couple of days later that I was comfortable enough to reboot. It does reboot, but right after the bootup screen says something about waiting for UDev events the monitor goes blank. (I expect this to happen cause the arch on my laptop does the same thing except with the laptop, the screen returns to life a moment later with a new screen font that holds true until it enters runlevel: 3 where the font I defined in my rc.conf finally takes over... But on this new desktop which has a nice Sony flat screen monitor, when the screen goes blank, the Sony monitor flashes a pop-up notification about no signal, which is quickly followed by a notice that it's going to power save mode... And the new arch system never sends it any more output to wake it up. No mater what I do to the keyboard or mouse. And no matter how long I wait either. I tried just waiting... Went to bed, got up late the next day. Still no monitor output... But Arch itself is NOT hung up. It will respond to the three fingered salute with a reboot, and I even one time blindly logged in as root to the console and blindly typed: shutdown -h now Which resulted in a powerdown. But I still don't have any idea what's killing my monitor output. I can use my PCLinuxOS installation's root account to examine/edit *ANY* file. But I don't have a clue what to look for. Suggestions anyone??? -- | ~^~ ~^~ | <?> <?> Joe (theWordy) Philbrook | ^ J(tWdy)P | \___/ <<jtwdyp@ttlc.net>>
i got lost in your mail... but i do see from your subject that you should use `pacman -Syu` and not just `pacman -Su`, as the package database wont be updated without `y`... and for blank screen, maybe try kernel option `nomodeset`... and in next mail try to be more precise what you did and what happens... as you talk about "pop-ups", did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?...
On Sun, Jul 04, 2010 at 11:51:12AM +0200, Andre Osku Schmidt wrote:
i got lost in your mail... but i do see from your subject that you should use `pacman -Syu` and not just `pacman -Su`, as the package database wont be updated without `y`...
and for blank screen, maybe try kernel option `nomodeset`... and in next mail try to be more precise what you did and what happens... as you talk about "pop-ups", did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?...
The popups are those generated by the monitor when it doesn't get a valid signal. Having a Sony as well they sound familiar to me. Things seem to go wrong well before Xorg gets involved. The nomodeset option willl probably provide a working system in RL 3. Once that is working we can have a closer look. Ciao, -- Je veux que la mort me trouve plantant mes choux, mais nonchalant d’elle, et encore plus de mon jardin imparfait. (Michel de Montaigne)
It would appear that on Jul 4, Andre "Osku" Schmidt did say:
i got lost in your mail... but i do see from your subject that you should use `pacman -Syu` and not just `pacman -Su`, as the package database wont be updated without `y`...
Sorry for my natural "wordyness" but I do have a hard time with brevity. If I hadn't been trying to keep that book down to a couple of chapters I'd have mentioned that I use pacman Sy as a separate command. It's nice that I could combine them into a single command. But on some systems I still use apt-get, and my ingrained habit of starting with a separate refresh command keeps me out of trouble.
and for blank screen, maybe try kernel option `nomodeset`... and in next mail try to be more precise what you did and what happens...
OK I'll try that on my next reboot cycle. (just have to finish a few E-mail chores first.) I'll let you know what happens...
as you talk about "pop-ups", did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?...
fons@kokkinizita.net nailed that one... I did think that my overlong text did specify that the pop-ups came from the monitor, but Like you said, you got lost in my post. (Sorry) It would appear that on Jul 4, fons@kokkinizita.net did say:
On Sun, Jul 04, 2010 at 11:51:12AM +0200, Andre Osku Schmidt wrote:
as you talk about "pop-ups", did you install xorg ? are you using a DE ? which gfx driver you installed for xorg ?...
The popups are those generated by the monitor when it doesn't get a valid signal. Having a Sony as well they sound familiar to me.
Things seem to go wrong well before Xorg gets involved. The nomodeset option willl probably provide a working system in RL 3. Once that is working we can have a closer look.
ABSOLUTELY. my next task _was_ supposed to be to open a lynx session on one console open to the wiki to remind myself HOW to use another console to get x working on an arch install... (This is only my second arch install ever. The first, on my laptop has worked out fairly well for me.) But I did have X running on that before they stopped passing control of the video back and forth between the kernel and the xserver. (Did I understand correctly that such control now resides only in the kernel whether x is up or not?) But in any case even when I do get X working I won't allow ANY display manager to control my boot/login process. If they take away startx I'll likely give up X before I'll use GDM, KDM, Entrance (etc...) Any graphical login prompt always makes me so uncomfortable that I forget why I was booting the durned computer in the first place. Heck I even insist on a text based grub menu for similar reasons. When I'm ready to put up with a GUI, I use startx, and not until... Still Like I told "Osku", I'll try that nomodeset kernel option and post the results in this thread. Thanks for the help guys. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
On Sun, Jul 04, 2010 at 08:15:26AM -0400, Joe(theWordy)Philbrook wrote:
But in any case even when I do get X working I won't allow ANY display manager to control my boot/login process. If they take away startx I'll likely give up X before I'll use GDM, KDM, Entrance (etc...) Any graphical login prompt always makes me so uncomfortable that I forget why I was booting the durned computer in the first place. Heck I even insist on a text based grub menu for similar reasons. When I'm ready to put up with a GUI, I use startx, and not until...
I'm using XDM which is relatively painless compared to GDM, KDM and friends. With a modified 'Arch' setup it can be made to look nice. Hint: once you have RL3, make sure you have the network and sshd configured and running before doing anything X11. That way you can always log in from another machine if startx leaves the system in an unusable state. It can save a lot of rebooting time... I wonder if you aleady have nouveau installed. Do an lsmod | grep nouveau to check. Nouveau is the new open source driver for Nvidia cards. Unlike nv it is a kernel module, not an Xorg driver and that can be confusing if you're not aware of it. If it is installed, it will be used even before you start X, and the only way to prevent that (if you want X to use another driver) seems to blacklist the module in /etc/rc.conf. The failing modeset could be because you have nouveau and it's doing the wrong thing, or because you don't have it... For X you will have the choice of nv, nouveau, or the proprietary nvidia driver. Nouveau is reported to work well, but on some systems I had to revert to nv to get usable audio latency. This seems to depend on the video card type as on other audio system here nouveau works just fine. Ciao, -- Je veux que la mort me trouve plantant mes choux, mais nonchalant d’elle, et encore plus de mon jardin imparfait. (Michel de Montaigne)
It would appear that on Jul 4, fons@kokkinizita.net did say:
I'm using XDM which is relatively painless compared to GDM, KDM and friends. With a modified 'Arch' setup it can be made to look nice.
What looks nice to me is the console login prompt... Also aside from that, there's another reason I use startx (with a wrapper script that copies the appropiate file to ~/.xinitrc depending on which desktop...) Which is usually E17 which can remember where to put a konsole window based {in part} on the "name" which I can feed to it with a running terminal application via a line like this in the ~/.xinitrc... konsole --workdir ~/mail --name F2alpine --profile BlackGray -e alpine & I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc... I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
Hint: once you have RL3, make sure you have the network and sshd configured and running before doing anything X11. That way you can always log in from another machine if startx leaves the system in an unusable state. It can save a lot of rebooting time...
Well I've evidentaly got the internet as fetchmail is working... Though it said my comcast cablemodem connection to comcast's pop server was insecure. It said something about verisign not being trusted????????????????? sshd is another matter. My personal paranoia settings require NEVER allowing ANY remote logins. If God himself want's to use my computer he dang well better be using the attached keyboard, or there's gonna be trouble... <grin>
I wonder if you aleady have nouveau installed. Do an
lsmod | grep nouveau
to check.
Since I haven't yet remembered how to get gdm working in arch, I redirected that output to a file in lieu of pasteing it into the message. Since I compose with vim that means :r nouveau.out nouveau 477159 0 ttm 38517 1 nouveau drm_kms_helper 21512 1 nouveau drm 131562 3 nouveau,ttm,drm_kms_helper i2c_algo_bit 4319 1 nouveau i2c_core 15144 5 nouveau,drm_kms_helper,i2c_nforce2,drm,i2c_algo_bit button 3738 1 nouveau
Nouveau is the new open source driver for Nvidia cards. Unlike nv it is a kernel module, not an Xorg driver and that can be confusing if you're not aware of it. If it is installed, it will be used even before you start X, and the only way to prevent that (if you want X to use another driver) seems to blacklist the module in /etc/rc.conf.
The failing modeset could be because you have nouveau and it's doing the wrong thing, or because you don't have it...
I say I'm not sure but I think the above output says I do have it and that it must be doing the wrong thing...
For X you will have the choice of nv, nouveau, or the proprietary nvidia driver. Nouveau is reported to work well, but on some systems I had to revert to nv to get usable audio latency. This seems to depend on the video card type as on other audio system here nouveau works just fine.
Since this is my first Nvidia card AND I'm NOT a gamer, I woiuldn't know what to do with any of the above. But since (I think) Arch now favors, ummnnn, What's it called? ahhhh, Oh good I found some of my notes: "KMS" it would make sense to try to configure the kernal module driver first wouldn't it? Is there a how-to that doesn't expect me to be a computer science grad????? By the way, I noticed a couple of odd things durring this "nomodeset" session. Don't know if they are symptoms of problems or possibly the results of having used the nomodxeset kernel option... 1) durring the boot, it said it couldn't load the sun12x22.psfu.gz font I'd prespecified in my rc.conf... Actualy on the assumption that KMS was going to notice my high reasolution monitor I figgured I'd likely need something like ter-128n.psf.gz Like I wound up using in my laptop. But I haven't installed the terminus font package yet... So the biggest I expected to start with was one of the 12x22 fonts... I note that even without loading the large font, I wound up with a large text size on my hi-res monitor (yup an actual 80 column display) So maybe the "nomodeset" option is why the 12x22 font didn't load? 2) a little more disturbing I note that when I switched to another tty and logged in to another console session, it hungup without executing the .bash_profile... If I hit ^C I got a default command prompt but my .bashrc set command path wasn't working untill I used the bash command to open a subshell... Could the nomodeset option be responsible for this??? 3) WHA-DA-{censored} Now I notice I can't get mc to fire up. I used it earlier in this login session, But now the tty just hangs, and I need to use another tty to issue a killall mc to get my prompt back... I'm not sure what changed since I started this Arch session. But something don't seam stable... -- | ~-~ ~-~ Guess I just don't know. | <?> <?> Joseph (the Wordy) Philbrook | ^ J(tWdy)P | ___ <jtwdyp@ttlc.net> <sigh>
On 05/07/10 07:08, Joe(theWordy)Philbrook wrote:
It would appear that on Jul 4, fons@kokkinizita.net did say:
I'm using XDM which is relatively painless compared to GDM, KDM and friends. With a modified 'Arch' setup it can be made to look nice.
I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc...
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
You could try slim, is graphical login manager which uses .xinitrc It works well for me, looks good and very lightweight. Ross.
On Mon, 2010-07-05 at 08:44 +1200, Ross wrote:
On 05/07/10 07:08, Joe(theWordy)Philbrook wrote:
It would appear that on Jul 4, fons@kokkinizita.net did say:
I'm using XDM which is relatively painless compared to GDM, KDM and friends. With a modified 'Arch' setup it can be made to look nice.
I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc...
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
You could try slim, is graphical login manager which uses .xinitrc It works well for me, looks good and very lightweight.
Ross.
Its also not really maintained I think, hence the existance of slim-plus in the AUR.
On Sun, Jul 04, 2010 at 03:08:05PM -0400, Joe(theWordy)Philbrook wrote:
What looks nice to me is the console login prompt... Also aside from that, there's another reason I use startx (with a wrapper script that copies the appropiate file to ~/.xinitrc depending on which desktop...) Which is usually E17 which can remember where to put a konsole window based {in part} on the "name" which I can feed to it with a running terminal application via a line like this in the ~/.xinitrc...
konsole --workdir ~/mail --name F2alpine --profile BlackGray -e alpine &
I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc...
You'r mixing up several things here: 1) starting X, 2) starting a window manager or desktop environment, and 3) restoring or setting up that desktop for a particular user. If you use a 'graphical' login like XDM then (1) is already done when you login. If you use startx after logging in it's your job to keep those things apart (or not).
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
As used here XDM will call ~/.xession, you can put whatever you want in there. I use it to map some keys, then start WindowMaker.
sshd is another matter. My personal paranoia settings require NEVER allowing ANY remote logins. If God himself want's to use my computer he dang well better be using the attached keyboard, or there's gonna be trouble... <grin>
There may be situations where such paranoia is warranted, but in general this just means you're making your own life more difficult than it should be. A ssh login can be set up to require a 1024 or more bit cryptographic token - if that isn't enough nothing will ever be.
I say I'm not sure but I think the above output says I do have it and that it must be doing the wrong thing...
Looks like it...
1) durring the boot, it said it couldn't load the sun12x22.psfu.gz font I'd prespecified in my rc.conf... Actualy on the assumption that KMS was going to notice my high reasolution monitor I figgured I'd likely need something like ter-128n.psf.gz Like I wound up using in my laptop. But I haven't installed the terminus font package yet... So the biggest I expected to start with was one of the 12x22 fonts...
I note that even without loading the large font, I wound up with a large text size on my hi-res monitor (yup an actual 80 column display) So maybe the "nomodeset" option is why the 12x22 font didn't load?
The 80 column display is what 'nomodeset' is supposed to do. You could try the old 'vga' option to switch to a higher resolution even with nomodeset - AFAIK it will work.
2) a little more disturbing I note that when I switched to another tty and logged in to another console session, it hungup without executing the .bash_profile... If I hit ^C I got a default command prompt but my .bashrc set command path wasn't working untill I used the bash command to open a subshell... Could the nomodeset option be responsible for this???
Don't thing so, but I noticed ~/.bash_profile being ignored as well. ~/.profile will probably work.
3) WHA-DA-{censored} Now I notice I can't get mc to fire up. I used it earlier in this login session, But now the tty just hangs, and I need to use another tty to issue a killall mc to get my prompt back... I'm not sure what changed since I started this Arch session. But something don't seam stable...
I don't have any idea as to what 'mc' is... Ciao, -- Je veux que la mort me trouve plantant mes choux, mais nonchalant d’elle, et encore plus de mon jardin imparfait. (Michel de Montaigne)
It would appear that on Jul 5, Ross did say:
On 05/07/10 07:08, Joe(theWordy)Philbrook wrote:
I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc...
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
You could try slim, is graphical login manager which uses .xinitrc It works well for me, looks good and very lightweight.
Ross.
It would appear that on Jul 5, Ng Oon-Ee did say:
Its also not really maintained I think, hence the existance of slim-plus in the AUR.
Well I guess I'll have to remember slim or slim-plus if the distro stops providing a working startx script. (writing startx is WAY beyond my skill level...) But I still prefer to start in console mode and wait until I'm ready to fire up X It would appear that on Jul 4, fons@kokkinizita.net did say:
You'r mixing up several things here: 1) starting X, 2) starting a window manager or desktop environment, and 3) restoring or setting up that desktop for a particular user.
If you use a 'graphical' login like XDM then (1) is already done when you login. If you use startx after logging in it's your job to keep those things apart (or not).
Very true! Though until I'm ready for both #2 & #3, I've no use for #1.
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
As used here XDM will call ~/.xession, you can put whatever you want in there. I use it to map some keys, then start WindowMaker.
That I didn't know. I don't suppose ~/.xsession is just a simple list of commands like ~/.xinitrc is?
sshd is another matter. My personal paranoia settings require NEVER allowing ANY remote logins. If God himself want's to use my computer he dang well better be using the attached keyboard, or there's gonna be trouble... <grin>
There may be situations where such paranoia is warranted, but in general this just means you're making your own life more difficult than it should be. A ssh login can be set up to require a 1024 or more bit cryptographic token - if that isn't enough nothing will ever be.
Here it's a matter of skill level and keeping things set up right. Since I use multiple distros, it sounds like even more work to always have to configure that. My system isn't exactly a prime target for hackers, but then again, until they crack it they don't know that. My first line of defense is to set my _wired_ router to forward nothing to any port... Combine that with never setting up any of my systems to allow remote access, and I've never seen anything to suggest anybody's hacked in yet.
I say I'm not sure but I think the above output says I do have it and that it must be doing the wrong thing...
Looks like it...
I note that even without loading the large font, I wound up with a large text size on my hi-res monitor (yup an actual 80 column display) So maybe the "nomodeset" option is why the 12x22 font didn't load?
The 80 column display is what 'nomodeset' is supposed to do. You could try the old 'vga' option to switch to a higher resolution even with nomodeset - AFAIK it will work.
Good to know, Of course I was always the guy who usually used vga=normal...
2) a little more disturbing I note that when I switched to another tty and logged in to another console session, it hungup without executing the .bash_profile... If I hit ^C I got a default command prompt but my .bashrc set command path wasn't working untill I used the bash command to open a subshell... Could the nomodeset option be responsible for this???
Don't thing so, but I noticed ~/.bash_profile being ignored as well. ~/.profile will probably work.
3) WHA-DA-{censored} Now I notice I can't get mc to fire up. I used it earlier in this login session, But now the tty just hangs, and I need to use another tty to issue a killall mc to get my prompt back... I'm not sure what changed since I started this Arch session. But something don't seam stable...
I don't have any idea as to what 'mc' is...
mc aka Midnight Commander. It's a shell in itself. It's a twin panel console file manager (it's been described as "the swiss army knife of file managers") It's original user interface was blatantly ripped off from the old dos Norton Commander. It's got Lots of uses for quickly navigating, & modifying at will even unfamiliar file systems browsing archive files and even ftp with many tools. it has both a built in command line (with file path and filename pasting as a built in function. And a full screen bash shell that you can toggle to/from that uses whatever directory the currently active panel was pointing at for it's working directory... If you can make sense of a filename view of files and directory trees, and don't need fancy icons to tell you what a file is, It belongs in your utility belt just as much as either vim or emacs does. (in my case vim! But that's a different Holy War...) I'm still hoping that the issues I'm having with mc etc... are related to nomodeset rather than deeper issues. I ran a few empirical tests BTW and fount that if I start mc before I access more than 2 or 3 tty[1-6] consoles it will start. And I discovered that if I don't try to execute a subshell at all from any of them I can log in to all six console screens and have my .bash_profile get processed. But once I start spawning subshells, all bets are off. But getting back to nouveau... Unfortunately, the nouveau wiki entry doesn't tell me much about my situation. If I was trying to get it to work in x, the info there might be useful. Or if I wanted to force it to "load early" But there is nothing I can see for resolving the console mode issue I'm having. The result is I'm lost. I've never had an Nvidia card before. I've never ever had to specifically load any kind of video driver whatsoever. Until now the default graphics configuration implemented without my input during the install of every single Linux I ever used was good enough for me. (All I want is the 2d stuff) I understand that there are 2 other choices for a Nvidia card, are the proprietary "Nvidia" driver package, and something called nv... I can find a wiki entry for Nvidia, but nothing on that "nv" choice. But anyway since it doesn't look like nouveau will work properly in console mode for me, I tried black listing it... Then probably, I thought, I'll have to follow the instructions in the Nvidia wiki entry when I try to get x working. But I found that I'm still having issues in the consoles with respect to subshells and mc. I'm beginning to think I'd be better off reinstalling with the 64 bit iso... It won't likely solve the nouveau issue, but I might get back fully functional console logins. -- | ^^^ ^^^ | <o> <o> Joe (theWordy) Philbrook | ^ J(tWdy)P | ___ <<jtwdyp@ttlc.net>> <sigh>
It would appear that on Jul 5, Joe(theWordy)Philbrook did say:
I'm still hoping that the issues I'm having with mc etc... are related to nomodeset rather than deeper issues. I ran a few empirical tests BTW and fount that if I start mc before I access more than 2 or 3 tty[1-6] consoles it will start. And I discovered that if I don't try to execute a subshell at all from any of them I can log in to all six console screens and have my .bash_profile get processed. But once I start spawning subshells, all bets are off. --<<snip>>-- But anyway since it doesn't look like nouveau will work properly in console mode for me, I tried black listing it... Then probably, I thought, I'll have to follow the instructions in the Nvidia wiki entry when I try to get x working. But I found that I'm still having issues in the consoles with respect to subshells and mc. I'm beginning to think I'd be better off reinstalling with the 64 bit iso... It won't likely solve the nouveau issue, but I might get back fully functional console logins.
Well I did that. But the 64 bit version was having the same problem with the consoles... UNTIL: After I installed nvidia (which required the xorg server) So I went right on ahead and added all the pacman -S commands suggested in the beginners guide for installing X plus xfce4, then followed the install instructions in the enlightenment & e17 wiki pages... added a couple of things I was sure to need and rebooted All the console issues with failed .bash_profile executions and problems with subshells and mc all went away. Probably they were symptoms of not having a working video card driver in place??? On another note however, I had managed, just prior to installing nvidia, to get gpm working in the console via "gpm -m /dev/psaux/mice -t ps2" And accordingly edited the /etc/conf.d/gpm file to include: GPM_ARGS="-m /dev/psaux/mice -t ps2" But after rebooting with a working nvidia driver the CONSOLEFONT: "sun12x22.psfu.gz" still fails to load. (No problem there I'm getting an 80 column display so I don't need to load larger console fonts...) But more irritatingly: Now GPM fails to start. And I can't start it manually either... Could it be that the nvidia drivers xorg dependency is blocking gpm in the console??? Too bad, I like using gpm's copy/paste functions, and wouldn't have minded setting up a /root/bin GPM init command with the correct string to activate it when wanted, even if I needed to gpm -k before running startx... One other odd thing. When I tried to "man gpm" it complained that /usr/bin/less didn't exist. So I symlinked it to /bin/less and man started working... ???? ... Anyway I set my {user} ~/.xinitrc for a minimal e17 start-up and startx got me there. And the mouse worked as expected there... But I'm too tired of all this to bother configuring all my e17 keyboard shortcuts etc... So I'm done for now. Thank You one and all for the kind hearted suggestions! -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
On Mon, Jul 5, 2010 at 02:15, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:
It would appear that on Jul 5, Ross did say:
On 05/07/10 07:08, Joe(theWordy)Philbrook wrote:
I've yet to find a DE that will remember enough details of a konsole window in it's saved sessions method to prestart the correct application(s) in the correct konsole windows etc...
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
You could try slim, is graphical login manager which uses .xinitrc It works well for me, looks good and very lightweight.
Ross.
It would appear that on Jul 5, Ng Oon-Ee did say:
Its also not really maintained I think, hence the existance of slim-plus in the AUR.
Well I guess I'll have to remember slim or slim-plus if the distro stops providing a working startx script. (writing startx is WAY beyond my skill level...) But I still prefer to start in console mode and wait until I'm ready to fire up X
It would appear that on Jul 4, fons@kokkinizita.net did say:
You'r mixing up several things here: 1) starting X, 2) starting a window manager or desktop environment, and 3) restoring or setting up that desktop for a particular user.
If you use a 'graphical' login like XDM then (1) is already done when you login. If you use startx after logging in it's your job to keep those things apart (or not).
Very true! Though until I'm ready for both #2 & #3, I've no use for #1.
I don't suppose XDM can be configured to use a ~/.xinitrc like script that will let me prestart selected terminal applications in a simular manor?
As used here XDM will call ~/.xession, you can put whatever you want in there. I use it to map some keys, then start WindowMaker.
That I didn't know. I don't suppose ~/.xsession is just a simple list of commands like ~/.xinitrc is?
sshd is another matter. My personal paranoia settings require NEVER allowing ANY remote logins. If God himself want's to use my computer he dang well better be using the attached keyboard, or there's gonna be trouble... <grin>
There may be situations where such paranoia is warranted, but in general this just means you're making your own life more difficult than it should be. A ssh login can be set up to require a 1024 or more bit cryptographic token - if that isn't enough nothing will ever be.
Here it's a matter of skill level and keeping things set up right. Since I use multiple distros, it sounds like even more work to always have to configure that. My system isn't exactly a prime target for hackers, but then again, until they crack it they don't know that. My first line of defense is to set my _wired_ router to forward nothing to any port... Combine that with never setting up any of my systems to allow remote access, and I've never seen anything to suggest anybody's hacked in yet.
I say I'm not sure but I think the above output says I do have it and that it must be doing the wrong thing...
Looks like it...
I note that even without loading the large font, I wound up with a large text size on my hi-res monitor (yup an actual 80 column display) So maybe the "nomodeset" option is why the 12x22 font didn't load?
The 80 column display is what 'nomodeset' is supposed to do. You could try the old 'vga' option to switch to a higher resolution even with nomodeset - AFAIK it will work.
Good to know, Of course I was always the guy who usually used vga=normal...
2) a little more disturbing I note that when I switched to another tty and logged in to another console session, it hungup without executing the .bash_profile... If I hit ^C I got a default command prompt but my .bashrc set command path wasn't working untill I used the bash command to open a subshell... Could the nomodeset option be responsible for this???
Don't thing so, but I noticed ~/.bash_profile being ignored as well. ~/.profile will probably work.
3) WHA-DA-{censored} Now I notice I can't get mc to fire up. I used it earlier in this login session, But now the tty just hangs, and I need to use another tty to issue a killall mc to get my prompt back... I'm not sure what changed since I started this Arch session. But something don't seam stable...
I don't have any idea as to what 'mc' is...
mc aka Midnight Commander. It's a shell in itself. It's a twin panel console file manager (it's been described as "the swiss army knife of file managers") It's original user interface was blatantly ripped off from the old dos Norton Commander. It's got Lots of uses for quickly navigating, & modifying at will even unfamiliar file systems browsing archive files and even ftp with many tools. it has both a built in command line (with file path and filename pasting as a built in function. And a full screen bash shell that you can toggle to/from that uses whatever directory the currently active panel was pointing at for it's working directory...
If you can make sense of a filename view of files and directory trees, and don't need fancy icons to tell you what a file is, It belongs in your utility belt just as much as either vim or emacs does. (in my case vim! But that's a different Holy War...)
I'm still hoping that the issues I'm having with mc etc... are related to nomodeset rather than deeper issues. I ran a few empirical tests BTW and fount that if I start mc before I access more than 2 or 3 tty[1-6] consoles it will start. And I discovered that if I don't try to execute a subshell at all from any of them I can log in to all six console screens and have my .bash_profile get processed. But once I start spawning subshells, all bets are off.
But getting back to nouveau... Unfortunately, the nouveau wiki entry doesn't tell me much about my situation. If I was trying to get it to work in x, the info there might be useful. Or if I wanted to force it to "load early" But there is nothing I can see for resolving the console mode issue I'm having.
The result is I'm lost. I've never had an Nvidia card before. I've never ever had to specifically load any kind of video driver whatsoever. Until now the default graphics configuration implemented without my input during the install of every single Linux I ever used was good enough for me. (All I want is the 2d stuff) I understand that there are 2 other choices for a Nvidia card, are the proprietary "Nvidia" driver package, and something called nv... I can find a wiki entry for Nvidia, but nothing on that "nv" choice. But anyway since it doesn't look like nouveau will work properly in console mode for me, I tried black listing it... Then probably, I thought, I'll have to follow the instructions in the Nvidia wiki entry when I try to get x working. But I found that I'm still having issues in the consoles with respect to subshells and mc. I'm beginning to think I'd be better off reinstalling with the 64 bit iso... It won't likely solve the nouveau issue, but I might get back fully functional console logins.
-- | ^^^ ^^^ | <o> <o> Joe (theWordy) Philbrook | ^ J(tWdy)P | ___ <<jtwdyp@ttlc.net>>
<sigh>
Joe: I've used nVidia cards for years and fought the same problems for years (12 or so), and used 3Dfx voodoo cards prior to nVidia. I've personally experienced the same problems with several different generations of nVidia graphics, especially the on board graphics. I finally caved and spent the money for pci cards to solve most of my problems (I realize that's not always an option for many people). Since the nouveau drivers came out I've never managed to get them working. I've tried several times because, like you, I don't need 3d. The xf86vesa driver has always worked, but for decent graphics I've always wound up installing the proprietary drivers. The setup utility that's installed sets up the xorg.conf file and you should be off and running. As to the xf86-nv driver, the quote below says it all. "Linux Magazine Mar 30, 2010 Andy Ritger, NVIDIA manager responsible for the Linux graphics cards, as announced on the X.org mailing list that the graphics chip company will no longer develop the open source 2D video drivers for its chips. He recommends using the VESA X driver instead." Now on to trouble shooting. Please don't take offense at the twenty questions routine everyone gets from typical tech support, but without seeing your machine I have some suggestions. 1. Have you tried hooking up a monitor from another machine and see if you can reproduce the problem. 2. If you happen to have another video card (it's a nice thought), try putting it in and see if you can reproduce the problem. 2. I don't recall any of the older on boards have dual video ports, but if they do switch ports and see what happens. 3. Go into the bios and check the video and power management settings. 4. If the manual came with the computer, RTFineM. LOL. Seriously, with HP boxes it sometimes helps. The do some strange things with the Pavilion line (from my personal experiences) I will again apologize if I have offended you with the above, it wasn't meant to just pass on some of the things I've had to do over the years with nVidia graphics I spent a lot of time learning to hand craft xorg.conf files for nVidia cards. I was actually upset when the newer version of x didn't need them, but have found using the proprietary drivers and the set up utilities work the best. I've also learned not to run a display manager and log in from the console. Myra -- Life's fun when your sick and psychotic!
It would appear that on Jul 5, Myra Nelson did say:
Joe:
I've used nVidia cards for years and fought the same problems for years (12 or so), and used 3Dfx voodoo cards prior to nVidia. I've personally experienced the same problems with several different generations of nVidia graphics, especially the on board graphics. I finally caved and spent the money for pci cards to solve most of my problems (I realize that's not always an option for many people).
Believe me, if cashflow wasn't such an issue that the only way I got to stick a working desktop under that Sony hi-res monitor again was because my brotherNlaw bought himself a new machine I'd have ditched the nvidia just as soon as I knew about it... But it's looking like the proprietary driver will do the trick...
Since the nouveau drivers came out I've never managed to get them working. I've tried several times because, like you, I don't need 3d. The xf86vesa driver has always worked, but for decent graphics I've always wound up installing the proprietary drivers. The setup utility that's installed sets up the xorg.conf file and you should be off and running.
Yup! Of course it bugs me a little that the video driver depends on xorg... I wanted the console to work right before I started installing X... But at lest it was relatively painless. Since pacman -S nvidia pulled in so much of X I immediately followed it with the other packages that the beginners guide suggests And the quickly added a couple of tolerable DE/WM's Rebooted and the console problems were all history...
Now on to trouble shooting. Please don't take offense at the twenty questions routine everyone gets from typical tech support, but without seeing your machine I have some suggestions.
My feeling is that anyone who has the stones to ask for help on ANY technical mailing list {even friendly ones} had dag burned better be prepared to answer questions...
1. Have you tried hooking up a monitor from another machine and see if you can reproduce the problem.
No I didn't. But then again I really wanted to use this flat screen Sony...
2. If you happen to have another video card (it's a nice thought), try putting it in and see if you can reproduce the problem.
No I didn't have one available.
2. I don't recall any of the older on boards have dual video ports, but if they do switch ports and see what happens.
I only saw one place to plug in the monitor cable...
3. Go into the bios and check the video and power management settings.
Now that's a thought. Even though it's now a moot point, I think I'll take a peek, when next I boot, to see what options are in fact there.
4. If the manual came with the computer, RTFineM. LOL. Seriously, with HP boxes it sometimes helps. The do some strange things with the Pavilion line (from my personal experiences)
Nah, Charlie had this pc to long to know what he did with the fine manual.
I will again apologize if I have offended you with the above, it wasn't meant to just pass on some of the things I've had to do over the years with nVidia graphics I spent a lot of time learning to hand craft xorg.conf files for nVidia cards. I was actually upset when the newer version of x didn't need them, but have found using the proprietary drivers and the set up utilities work the best. I've also learned not to run a display manager and log in from the console.
None taken Myra, While I tend to prefer open source stuff, I'm not allergic to using proprietary drivers, especially when I can get them via my distro's package management system without having to write somebody a check... And aside from the xorg dependency I have to admit as soon as I installed nvidia, it all started working (except that I think it's blocking the gpm daemon... {so much for copy/paste in the console...}) I never got used to using a display manager in the first place Every time I install a new distro, one of the first things I gotta do is find out how to avoid their preferred DM and use startx when (and if) I decide I'm ready for X to start. Thanks for the suggestions Myra, If I'd have had your response before I'd installed nvidia, I'd have tried most of your suggestions. But it could be that the next person with a similar problem will catch a clue from this thread so I'm glad to here even the ones that no longer make sense for me. -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
Joe: I gave up on gpm in a terminal before x is started. I never could manage to get to work right. The other thing I've noticed about the onboard graphics is some manufacturers seem to modify the drivers slightly. I had one laptop with ATI onboard and the only drivers I could make work were the ones from the laptop manufacturer. Glad you got it working, mostly at least. Myra On Tue, Jul 6, 2010 at 18:41, Joe(theWordy)Philbrook <jtwdyp@ttlc.net> wrote:
It would appear that on Jul 5, Myra Nelson did say:
Joe:
I've used nVidia cards for years and fought the same problems for years (12 or so), and used 3Dfx voodoo cards prior to nVidia. I've personally experienced the same problems with several different generations of nVidia graphics, especially the on board graphics. I finally caved and spent the money for pci cards to solve most of my problems (I realize that's not always an option for many people).
Believe me, if cashflow wasn't such an issue that the only way I got to stick a working desktop under that Sony hi-res monitor again was because my brotherNlaw bought himself a new machine I'd have ditched the nvidia just as soon as I knew about it... But it's looking like the proprietary driver will do the trick...
Since the nouveau drivers came out I've never managed to get them working. I've tried several times because, like you, I don't need 3d. The xf86vesa driver has always worked, but for decent graphics I've always wound up installing the proprietary drivers. The setup utility that's installed sets up the xorg.conf file and you should be off and running.
Yup! Of course it bugs me a little that the video driver depends on xorg... I wanted the console to work right before I started installing X... But at lest it was relatively painless. Since pacman -S nvidia pulled in so much of X I immediately followed it with the other packages that the beginners guide suggests And the quickly added a couple of tolerable DE/WM's Rebooted and the console problems were all history...
Now on to trouble shooting. Please don't take offense at the twenty questions routine everyone gets from typical tech support, but without seeing your machine I have some suggestions.
My feeling is that anyone who has the stones to ask for help on ANY technical mailing list {even friendly ones} had dag burned better be prepared to answer questions...
1. Have you tried hooking up a monitor from another machine and see if you can reproduce the problem.
No I didn't. But then again I really wanted to use this flat screen Sony...
2. If you happen to have another video card (it's a nice thought), try putting it in and see if you can reproduce the problem.
No I didn't have one available.
2. I don't recall any of the older on boards have dual video ports, but if they do switch ports and see what happens.
I only saw one place to plug in the monitor cable...
3. Go into the bios and check the video and power management settings.
Now that's a thought. Even though it's now a moot point, I think I'll take a peek, when next I boot, to see what options are in fact there.
4. If the manual came with the computer, RTFineM. LOL. Seriously, with HP boxes it sometimes helps. The do some strange things with the Pavilion line (from my personal experiences)
Nah, Charlie had this pc to long to know what he did with the fine manual.
I will again apologize if I have offended you with the above, it wasn't meant to just pass on some of the things I've had to do over the years with nVidia graphics I spent a lot of time learning to hand craft xorg.conf files for nVidia cards. I was actually upset when the newer version of x didn't need them, but have found using the proprietary drivers and the set up utilities work the best. I've also learned not to run a display manager and log in from the console.
None taken Myra, While I tend to prefer open source stuff, I'm not allergic to using proprietary drivers, especially when I can get them via my distro's package management system without having to write somebody a check... And aside from the xorg dependency I have to admit as soon as I installed nvidia, it all started working (except that I think it's blocking the gpm daemon... {so much for copy/paste in the console...})
I never got used to using a display manager in the first place Every time I install a new distro, one of the first things I gotta do is find out how to avoid their preferred DM and use startx when (and if) I decide I'm ready for X to start.
Thanks for the suggestions Myra, If I'd have had your response before I'd installed nvidia, I'd have tried most of your suggestions. But it could be that the next person with a similar problem will catch a clue from this thread so I'm glad to here even the ones that no longer make sense for me.
-- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
-- Life's fun when your sick and psychotic!
It would appear that on Jul 7, Myra Nelson did say:
Joe:
I gave up on gpm in a terminal before x is started. I never could manage to get to work right.
Whereas I've almost always got gpm working... In fact I had it working on this install (right after blacklisting nouveau, got me a semi-usable console, right up until I installed nvidia. (sigh) But for anything short of boot screen error messages, I can redirect or tee into a file and use vim's :r command to include anything I really want. It's just such a pain that way...
The other thing I've noticed about the onboard graphics is some manufacturers seem to modify the drivers slightly. I had one laptop with ATI onboard and the only drivers I could make work were the ones from the laptop manufacturer.
Now why doesn't that surprise me???
Glad you got it working, mostly at least.
Me too! Heck now that it's working, I've had time to fully configure xfce, e16 & my operational favorite, e17... Course I may like "_USING_" e17 best, but configuring it is always a chore. For example this time the keyboard shortcut assignment tool kept ignoring the keyboard (2 out of 3 times) when I'd want to set up shortcuts to exec things like: xterm -bg darkviolet -fg green -fn 12x24 -geometry 92x30 Fortunately I figured out that I could use the mouse pointer to mark the syntax example that always needs to be deleted, then a right click on the marked text let me "cut" it, and finally by switching to a terminal window with an editor session open, I could create the text of the command there, and then mark it with the mouse, switch back to the semi-functional shortcut routine and paste the text it wouldn't let me type... <sigh> But I can't complain too much, Once I manage to get it configured to taste, E17 has always been a pleasure to use... At this point I've got Arch sufficiently squared away for me to consider making my next project installing Xubuntu an another partition... But not tonight! Thanks again to everyone who offered advice... -- | --- ___ | <0> <-> Joe (theWordy) Philbrook | ^ J(tWdy)P | ~\___/~ <<jtwdyp@ttlc.net>>
participants (6)
-
Andre "Osku" Schmidt
-
fons＠kokkinizita.net
-
Joe(theWordy)Philbrook
-
Myra Nelson
-
Ng Oon-Ee
-
Ross