Re: dump/mksnap_ffs & fsck failure

From: Kris Kennaway <kris_at_obsecurity.org>
Date: Thu, 7 Oct 2004 10:02:50 -0700
On Thu, Oct 07, 2004 at 05:55:20PM +0100, Chris Elsworth wrote:

> > > # /sbin/dump -0 -LuaC32 -f /backup/root.dump /
> > > mksnap_ffs: Cannot create //.snap/dump_snapshot: Input/output error
> > > 
> > > # fsck_ufs /dev/mirror/gma
> > > ** /dev/mirror/gma (NO WRITE)
> > > ** Last Mounted on /
> > > ** Root file system
> > > ** Phase 1 - Check Blocks and Sizes
> > > fsck_ufs: cannot alloc 4294967292 bytes for inoinfo
> > 
> > Why can't it write to the device?  Is it mounted read-write?  Drop it
> > to read-only and retry.  Vice versa for the root filesystem; is it
> > mounted read-only?
> 
> Ah, sorry, should have said - yes, the filesystem was mounted
> read-write (/dev/mirror/gma and / are the same thing), but it does the
> same thing in read-only:
> 
> # init 1
> ..
> # umount -a
> # mount -o ro /
> # mount
> /dev/mirror/gma on / (ufs, local, read-only)
> devfs on /dev (devfs, local)
> # fsck -y /
> ** /dev/mirror/gma
> ** Last Mounted on /
> ** Root file system
> ** Phase 1 - Check Blocks and Sizes
> fsck_ufs: cannot alloc 4294967292 bytes for inoinfo
> 
> 
> Surely fsck doesn't really need 4GB of physical mem? There is 1GB of
> physical and 4GB of swap configured in this.

Perhaps it's trying to allocate a negative amount of memory (that
value is 2^32-4, or (unsigned int)(-4)), perhaps because it's failing
to check for an error condition and using the resulting negative
value.

Kris

Received on Thu Oct 07 2004 - 15:01:15 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC