Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Tue, 20 Jun 2006 21:07:53 -0500
On 19 Jun 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<1150780654.758803.104980@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, iforone wrote:
BTW - What was that keyboard sequence, I saw you post recently (in
another thread) , concerning Reading the Startup "Buffer" of the Bootup
messages...being able to scroll backwards through it. Was it Press ALT
and then PageUp/Down, or Press ???, then Alt PageUp/Down -- and you
even explained Why :-)
Left shift key and PageUp/Down. You're reading the frame buffer, so you
have to do this before starting a GUI display manager, or logging in.
I've heard of a "magic" bit (or setting) that can be set in syslog.d(?)
or similar that will store and keep these unfindable errors/messages
that one sees during Bootup (such as one sees the tail of, when using
Ctrl+Alt+F1 to enter the 1st VT/VC
Oh-oh - that suggests a GUI login tool. I've never really gotten into
the code, but my understanding is that the system starts up in whatever
native text mode is that the computer's video card handles. This means
lots more space for words instead of pretty icons in 24 bit color.
I notice all the startup daemons, like hald, nfsd, klogd, portmapd,
inetd, nmbd, smbd, sshd, etc, etc), but this is NOT available (AFAIK)
in a 'dmesg' -- since the buffer flushes(?) before moving on....and
before initiating those record files/daemons.. I know I've said that
wrongly.
Time to read those startup scripts, while remembering that each process
gets a "goes-inta", a "comes-outta" and a "whoopsie" - which the dry
man page probably calls stdin, stdout and stderr. You may be aware that
in the shell, you can re-direct things with arrows (meaning "<" and ">")
as well as piping things for further processing. To redirect stderr in a
Bourne (and friends, which includes Bash) shell, you stick a '2> file'
at the end - a common one being '2>/dev/null' to toss those annoying
errors into the bit-bucket. Now the _default_ for these three hoses
are the keyboard for stdin, and the "terminal" or display for both stdout
and stderr. If you want to keep those outputs for later review, you have
to stick things into some kind of file. Now, reading the startup scripts,
you can see places where information is written to the screen (almost
always an 'echo' command, but nowhere do you see stderr being redirected
(other than to /dev/null on occasion).
I hear ya - some convulted contraption of RedHat -- but RH 9 (and other
knowlegdegable ppl using it, and their posts on certain Listservs that
I suscribed to at that time) was the one that caught my ear and
_started_ me being interested in (wondering about) Linux.
From 1996 to perhaps 2003, Red Hat was the major player, although bothDebian and Slackware were important players. A _lot_ of distributions were
based on these three. They were not the first in this racket, and they
won't be the last.
For what we'd be looking for (is it talking - are we seeing errors), it's
not all that complex.
I hear ya - but I've seen *many* errors in the various /var/log files,
and quite frankly, I think it may be a hardware issue (since I see
-s-o- many various errors throughout the files).
This would be the errors on the wire itself - such as packets appearing
to go out, and none returning - none being received at all.
I bought this NIC, besides b/c it was the right price ($19.00 USD), but
also b/c it listed this info in the specs. and I knew I wanted to
test/convert to a *nix based OS;
Netgears are inexpensive, mainly because the cards were made overseas by
enslaved gerbils in a seventh world country, but other than that, they
were fairly decent. (Actually, there are few parts, and just about every
assembly activity is fully automated.)
I don't either on Linux usually - ...it turns out; I was trying to help
someone concerning a certain ASUStek mobo, and their stupid site
packages the Manuals as PDFs, *but* pre-wrapped in d/l ZIP files.
As the man page says - combination of tar (combining files into an archive)
and a compression program. It's one of the few semi-open mechanisms for
transporting files for DOS. Back in the old 'BBS' days, there were a few
other used as well - I vaguely recall .ARC, .BQS, and self extracting
executables.
I *think* that issue is taken care of, but I'm not really sure
why...KDE is *extremely* complex AFAICT -- I guess after reading below,
I'd have to say Yes...
One of the early desktops on X was called CDE. It was no where _NEAR_ as
bloated as KDE, which seems to be targeting the windoze user to give them
a familiar "Click here and be amazed" experience. I didn't like CDE either.
I think the current KDE assembly is larger than some entire Linux distros
only a few years aso.
This info I recall (silly me), but likely only b/c you mention/describe
it correctly...IOW, if you stated an untruth, I'd have a hard time
arguing against -- but en.wikipedia.org has been a great resource for
things like that.
wikipedia... and you think Scott Mueller is bad?
I'm pretty sure the confusioin started when "the powers that be"
decided to enlighten the User, via also enabling the full command
Option name (ex; --status), rather than the unclear option (-s) -- so
the user can decipher it's meaning.
Blame the Free Software Foundation - they're the ones who started using
the --understandable options rather than those easily confused single
letters (partially because they ran out of single letters, but don't
tell anyone).
I have very very *many* issues with this GUI stuff -- yet I can say
*some* things that have been implemented (like the ability to implement
javacrap on a site-by-site basis, for ex.) are like almost 'reading my
mind' ...I'm caught between a rock and a hard place :-) and it's all
MS's fault - until now!
Not really. A good GUI gives you a user friendly mechanism for every
option that the author thinks you may need. If that's all you need, things
can be (relatively) simple, and easy to use. But there's the rub. Which
is the icon that I click to get statistics on the number of RFCs that
are identified as STANDARD, INFORMATIONAL and HISTORIC, etc.? Whereas
[compton ~]$ sed 's/^$/\%/' < rfcs/rfc-index.txt-06.10.06 | tr -d '\n' |
tr '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
123 BEST CURRENT PRACTICE 1380 INFORMATIONAL
122 DRAFT STANDARD 1361 PROPOSED STANDARD
256 EXPERIMENTAL 87 STANDARD
190 HISTORIC 909 UNKNOWN
[compton ~]$
[Lecture: Know what the file you are trying to extract data from looks
like, and work with that. In this case, there are a bunch of entries that
look like
0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
(Status: STANDARD)
0792 Internet Control Message Protocol. J. Postel. September 1981.
(Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950)
(Also STD0005) (Status: STANDARD)
0793 Transmission Control Protocol. J. Postel. September 1981.
(Format: TXT=172710 bytes) (Updated by RFC3168) (Also STD0007)
(Status: STANDARD)
which happens to be interesting documents by the way. Because each entry
can be on one or more lines, the first sed turns all empty lines into a line
with a unique character, the first tr then deletes all newlines, while the
second translates that unique character into a newline (resulting in each
entry being on one long line). We then select each line that starts with
a number (which eliminates notes and the introduction), squeeze multiple
spaces to a single, toss lines referring to RFCs that were not issued, then
strip off everything up to the space following the colon after the word
"Status", strip off the closing parenthesis, sort the remaining text, and
count each set - then display the output in a column format. Simple, no?
I knew an instructor in the long distant past that used to like to teach
what we call 'one-liners' where you use the simplicity and pipes to do what
seems to be incredibly complex, but is actually just a bunch a very simple
steps. This certainly isn't the least CPU intensive way to do things -
actually a perl script would probably be easier - but what we are trying
to do is get the information that we need right now. "Pretty" can come
later. This was a 4 unit class, and I don't think anyone finished the final
exam (30 questions relating to scripts, sed, awk, tr, grep and who remembers
what else) in less than two hours. Another bottom line: If there are
multiple tools that will do a specific tasks, use the one you are most
comfortable with, and get on with solving the problem. (end Lecture)]
_That's_ what I'm doing wrong - I *need* to enter _some_ relevant
keystrokes prior to using tab-tab -- that's why it's called Tab
"completion".... doh!
I always seem to get the inevitable;
"Are you sure you want to see all 545324679796434 commands" :-)
Nah, it just seems that bad ;-)
Old guy
.
- Follow-Ups:
- References:
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: Moe Trin
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: Moe Trin
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: Moe Trin
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: Moe Trin
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: Moe Trin
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- From: iforone
- Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- Prev by Date: Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- Next by Date: Re: ICMP ping effecting network flow?
- Previous by thread: Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- Next by thread: Re: asrock, problem with nic after windows-boot - Exact Opposite issue the OP is having
- Index(es):
Relevant Pages
|
Loading