[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: INIT PANIC



> > >  INIT: PANIC: segmentation violation! giving up..
> > > 
> > > and the booting procedure stopped there, forcing a manual reboot which
> > > was successful only after yet another fsck.
> > > 
> > bad trouble is going on ...
> > make a surface-check of your hdd to see if it's a hardware failure.
> 
> Hope not, the hd is a few months old (new).
> 
if it's new enough, it would be not that bad - you surely have warranty,
don't you?
well - as now all seems to be normal, a hardware failure is a less
probable possibility. i would make a check anyway ...

> > have you run another operating system, that might have messed up you linux
> > install?
> Uh, yes... and not.  I have OpenBSD installed, but on a second hd, not
> on the same hd.  To be honest, I've mounted the Linux ext2 partitions
> from OpenBSD several times, and done a bit of copying and moving.
> 
as i don't have the foggiest notion of *bsd, i can't tell you if this
could be a problem of any kind. i don't think so ...

> BTW, the fs I usually get more trouble with (fsck inconsistencies) is
> /var.
> 
not much surprising - this is the partition where most write operations
are done.
i have to manually fsck it after nearly every crash ...

> > the panic is probably caused by a destroyed kernel-image, init-executable
> > or some vital configuration file (e.g., /etc/inittab).
> 
> I've tried a couple of reboots, and everything seems to be working fine
> now (everything except the ../lost+found/#10.... files which still are
> there and the system cannot clean when starting).  But I expect some
> more trouble as these problems don't usually go away on their own :(
> 
if everything seems to be ok now and no new problems arise, then you
should not worry _too_ much. possibly you should check all the
config-files in /var if anything seems to work not as expected.
look, if you find something useful in lost+found - these are orphaned
i-nodes, etc.
a thread about undeletable files we had already some days ago. the point
is, that these files have the ext2-attribute "immutable" (or something
like that) set. you need the ext2-tools (no idea, how the package is
named) to remove them.

if the disaster was neither caused by hardware failure nor by external
impact nor by crash, then a question arises (guess which ;-) ) ...
which kernel are you using? i heard some ugly things about 2.2.13 ...
another weird idea: the sync(8) man-page states, that sync only schedules
the syncing, but does not wait for it to complete. possibly the shutdown
script does not leave enough time to flush all buffers before it
halts/reboots.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Linux - the last service pack you'll ever need.



Reply to: