"Dependency info is missing!"

Adrian · External Since: Mar 04, 2007 Posts: 2

After I have done update/emerge of 'debianutils' my system is severely
mulfunctioning now.

No service could be run, and after booting (or switching a runlevel) the
following message arrives:

Dependency info is missing! Please run
# /sbin/depscan.sh
to fix this.

(No to mention running 'depscan.sh' does nothing.)

Please help!

--
Adrian

Adrian · External Since: Mar 04, 2007 Posts: 2

Adrian <adrn.TakeThisOut@virtualpoland.wp.pl> wrote in
news:Xns98E966B11B6Eadrnwppl@194.177.96.78:

> Dependency info is missing! Please run
> # /sbin/depscan.sh
> to fix this.

Please, help me! I have the whole system stranded Sad

No service could run...
Running #/sbin/depscan.sh doesn't help at all!

I have no idea what could happen and suspect 'depedency info' is not the
clue...

--
Adrian

Unruh · External Since: May 27, 2005 Posts: 2213

Adrian <adrn RemoveThis @virtualpoland.wp.pl> writes:

>Adrian <adrn RemoveThis @virtualpoland.wp.pl> wrote in
>news:Xns98E966B11B6Eadrnwppl@194.177.96.78:

>> Dependency info is missing! Please run
>> # /sbin/depscan.sh
>> to fix this.
>
>Please, help me! I have the whole system stranded Sad

>No service could run...
>Running #/sbin/depscan.sh doesn't help at all!

>I have no idea what could happen and suspect 'depedency info' is not the
>clue...

Please reread that post and try to figure out how anyone else could figure
out what you are talking about.

Arthur Hagen · External Since: May 30, 2004 Posts: 45

On Mon, 2007-03-05 at 00:52 +0100, Michael Mauch wrote:
>
> I had the same problem today, but I believe that the cause was a kernel
> panic (and the tendency of XFS to write '\0' bytes into files in case of
> a crash).

Malapropos the original problem, but XFS does that deliberately, for
security reasons. The file system can't know whether a file that was
being written to was a temporary file containing sensitive information,
so it overwrites the original data and zeroes it out (IIRC, first with
0xAA (10101010 pattern), then 0x55 (01010101 pattern) and finally 0x00).

These days, it's less common to get zeroed out files after a crash,
unless you have mounted xfs partitions with "nobarrier" option, as
"barrier" is the default on kernel 2.6.18(?) or newer. With "barrier"
in effect, the journal data is always flushed when the metadata is,
meaning the files are more often OK, at the price of a (sometimes
severe) speed penalty. Due to this speed penalty, I recommend
mounting /var/tmp, /var/cache and similar file systems with "nobarrier"
for speed, but make sure that root is mounted with barriers enabled.

And, for dog's sake, if using any journalling file system, put "sync"
in /etc/conf.d/local.stop, as the 1 second delay after the final sync
that the system does isn't always enough to flush a full set of buffers
(unless you turn of the HD write cache).

Regards,
--
*Art

Arthur Hagen · External Since: May 30, 2004 Posts: 45

On Mon, 2007-03-05 at 01:28 +0100, J.O. Aho wrote:
> Michael Mauch wrote:
>
> > I had the same problem today, but I believe that the cause was a kernel
> > panic (and the tendency of XFS to write '\0' bytes into files in case of
> > a crash).
>
> Have you disabled write ahead?
> SGi writes in their on-line documentation that if you have write ahead enabled
> on the hard drives you will have the risk of corrupting files.

Old docs. These days, the barrier mount option fixes most of that
problem. You might want to turn off write caching during shutdown,
though. But only if either (a) your HDs default to write caching
enabled without remembering the previous settings, or (b) all the OSes
you use can turn it back on during startup. So if you have a fairly
recent HD and dual-boot with Windows, that's a "no".

Regards,
--
*Art

Michael Mauch · External Since: May 21, 2004 Posts: 45

Adrian wrote:
> Adrian <adrn.DeleteThis@virtualpoland.wp.pl> wrote in
> news:Xns98E966B11B6Eadrnwppl@194.177.96.78:
>
>> Dependency info is missing! Please run
>> # /sbin/depscan.sh
>> to fix this.
>
> Please, help me! I have the whole system stranded Sad

> No service could run...
> Running #/sbin/depscan.sh doesn't help at all!
>
> I have no idea what could happen and suspect 'depedency info' is not the
> clue...

I had the same problem today, but I believe that the cause was a kernel
panic (and the tendency of XFS to write '\0' bytes into files in case of
a crash).

Here I could fix it by removing /var/lib/init.d/depcache and
/var/lib/init.d/deptree, both of which showed only "^@^@^@..." when I
looked into them with "less". Running depscan.sh afterwards recreated
these files.

Regards...
Michael

J.O. Aho · External Since: Mar 26, 2004 Posts: 2216

Michael Mauch wrote:

> I had the same problem today, but I believe that the cause was a kernel
> panic (and the tendency of XFS to write '\0' bytes into files in case of
> a crash).

Have you disabled write ahead?
SGi writes in their on-line documentation that if you have write ahead enabled
on the hard drives you will have the risk of corrupting files.

--

//Aho

Michael Mauch · External Since: May 21, 2004 Posts: 45

Arthur Hagen wrote:

> These days, it's less common to get zeroed out files after a crash,
> unless you have mounted xfs partitions with "nobarrier" option, as
> "barrier" is the default on kernel 2.6.18(?) or newer. With "barrier"
> in effect, the journal data is always flushed when the metadata is,
> meaning the files are more often OK, at the price of a (sometimes
> severe) speed penalty. Due to this speed penalty, I recommend
> mounting /var/tmp, /var/cache and similar file systems with "nobarrier"
> for speed, but make sure that root is mounted with barriers enabled.

Oh, you're my hero! I just remounted my video partition "nobarrier", and
now it's really a lot faster. Especially with large writes, i.e. cutting
a video, the system is a lot more responsive now. I always wondered why
the system got so slow in these situations, for a few months now.

I'll move /var/tmp etc. to a different partition with nobarrier as soon
as I get my other disk back from repair. Extracting large .bz2 files
(e.g. kernel sources) also makes the system slow down at the moment.

> And, for dog's sake, if using any journalling file system, put "sync"
> in /etc/conf.d/local.stop, as the 1 second delay after the final sync
> that the system does isn't always enough to flush a full set of buffers
> (unless you turn of the HD write cache).

"sync" in local.stop sounds like a good idea, too.

Thanks...
Michael

lubo777 · Joined: Jun 27, 2008 Posts: 1