Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
it's something that shouldn't happen. If it is a broken filesystem then this is the reason that the kernel is panicing because it can't find it's initrd file.
Innit = A phrase used by common scum in England.
Init in linux = a part of the linux kernel/that part of bootup, that is stored somehow seporate from the actual kernel for some reason. AKA initialisation i guess.
However, the filesystem may be fine; it's just a minor problem due to the filesystem not unmounting correctly before reboot with ext3 telling you that it's fixing the problem like a journaling filesystem should.
So if the filesystem is fine and the ext3 Group descriptors error message is not critical what could be causing the problem?
The error message "init" not found happens when a someone tries to run a new kernel without telling lilo (via /etc/lilo* perhaps) where it can find initrd. This means it needs to be told where the init file is.
Now, it's just possible that someone has hacked you, replaced your kernel with one they've cooked up and got the thing to reboot, only they screwed up because they didn't sort out initrd so it won't boot anymore.
If the filesystem is damaged, or someone who you know has installed a new kernel = not hacked.
If filesystem was actually fine or we have confidence in the idea that the sudden reboot was NOT caused by a system crash that I personally haven't heard of = Hack likely.
What I'd do:
- out of interest for hack check the filesystem to see if it's ok, possibly checking for badblocks (boot from floppy distro/install cdrom/rescue cdrom + fsck /dev/DEVICE).
- backup as little as possible bearing in mind it could all be infected / dodgy
- Blank and format the lot
- reinstall anyway just in case
- update stuff fast, keep updated. Understand how redhat updates work - do they include a kernel update that could confuse lilo as to it's init perhaps?
I agree with jago25_98 filesystem checking is the first thing you should do.
"well i'm reacting without checking to see if it will boot with boot disk".
You're on the bloody wrong track. You should always try all options to determine the cause of the problem.
If it all doesn't work try to read the filesystem booting from a rescue disk and save all logs. If you can find anomalies post 'em here. While booting from the rescue disk run your filesystem integrity checker (you have one of these, right?: Aide, Samhain or Tripwire). If unsure load up chkrootkit(.org) as well.
If there's nothing in the logs, no unknown files/devices on the filesystem and chkrootkit doesn't return weirdness then chances are getting smaller (in the good sense) your box has been hacked.
*If you don't have a filesystem integrity checker, can't run chkrootkit or can't access/read the logs your chances of detecting a possible compromise are smaller as well: in a bad way tho. Then a reformat of the disk and reinstall is the only option to make sure you have a "trusted" box.
**Overclocking, a bad power supply or excessive heat can lead to spontaneous reboots as well.
well hardware is fine i quit overclocking awhile ago( cook'd mobo/cpu).
i was able to get everything going again, with rescue disks. i had to take wife out for breakfast, and when i cam back system was lock'd up. tried to rescue again but couldn't get it goin again.
i'll try again later, gota lota work to do.
thanks for the help, will post back when i have time /results