EXEC OF INIT ((NULL)) FAILED - BAD ADDRESS
KERNEL PANIC! - NOT SYNCING: ATTEMPTED TO KILL INIT
Please View
the graphical illustrations
All of this happened as a result of my attempting to rename a directory/ create a duplicate dir w/ a similar name.
when i tried to "preview" some HTML, Quanta Plus (KDE webdev IDE) was unhappy w/ my Mozilla Program Directory being named "mozilla" instead of "mozilla-1.7.xx", so i attempted to fix this (instinctually, albeit unknowingly) by the following procedure:
NOTE: Sudo? Su? root? i'm not sure which "personality" i was using (ie. is there not a difference between typing "su" and "su --" (or "su -") at the CLI prompt when under the default system user. From what i understand, there is a functional difference (with or without the "dash" (or double-dash?) in the "su" command), but i've not mastered the knowledge yet.
so, for the purpose of discussion, and my commiting that it most likely was the case, i've indicated below that i logged in as "su --".
Code:
EDITED (01:54 Sept 17)
[user@localhost ~]$ su --
Password: xxxxx
[root@localhost ~]# cd /usr/lib
[root@localhost lib]# mkdir ./mozilla-1.7.13/
[root@localhost mozilla]# mv -v ./mozilla* ./mozilla-1.7.13
## i realize the above is illogical CLI syntax - i'm trying to show my 'possible entries' **
i wanted to "take the mozilla directory, and rename it to mozilla-1.7.13 " -- but, fumbling w/ that, i probably had to mkdir ./mozilla-1.7.13 first (i think) -- essentially the problem being similar names of dirs and non-existing dirs -- which i eventually fixed enough to proceed to the mv part.
then viewing
Code:
[@localhost /lib]# ls -l
, i recall seeing that it appeard as if my re-naming, or moving/copying the files was a success, because i "think" i saw mozilla-1.7.13 present as a dir where it was not present before-- or perhaps they were both present. in other words, i am 99% certain i saw "some modification" to the directories and/or files within, but i felt as if the Terminal Error Messages were perhaps only half-right (assuming it is possible that term throws an error at times even when the function was performed, or an error is thrown for one-part-in-a-unit of functions-- so some, but not all of the intended command did in fact execute).
it must have been my attempted USE OF SHORTCUTS in the CLI Syntax (such as the asterisk or the dot slash -- as in: mv -v /usr/lib/mozilla* ./* [move verbose usr-lib-mozilla-asterisk dot-slash-asterisk])
since this didn't seem such an "abnormal" procedure, i didn't take notes, so i can NOT recall my exact syntax and directories. i'm hoping that we can determine a solution based on recollection of "what must have / might have happened". it was about 24 hours ago since this happened.
NOTE: i "think" i was in /usr/lib/mozilla]# while executing these commands, but i might have been in /usr/lib/ (or even /usr/share/mozilla/.... i'm sorry i just don't recall precisely what was going on -- i'm learning here, obviously-- trying to learn to utilize the power of the CLI -- oft referencing http://www.ss64.com/ by way of a nifty sidebar-friendly file located here: http://webtoman.com/opera/panel/ )
if you need more info about the dynamics of the situation, please ask.
currently, i'm operating on the same system but from a 20GB drive i stuck in here and loaded a fresh FC5 (wiping the old data)-- the thought being, if i need to, i might be able to browse, and repair the Sick drive this way-- but thus far, i've had no success w/ that method (as you might see from the illustration at the URL above). I tried the Fedora Core 5 Rescue CD, but i don't know what to do-- it claims there's no Fedora partitions anyway!
thanks so much for reading. i look forward to your reply.
Logical Vols. Active: WARNING: can't access (null)
