[arch-general] screen goes blank on reboot after 1st pacman Su of new install!!!???

[Joe(theWordy)Philbrook]

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 at 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 at ttlc.net>>

       <sigh>