Re: what to do about "cannot dump to dumpdev hd(1/41): space for
- From: b.hutchman@xxxxxxxxx
- Date: Mon, 15 Sep 2008 10:09:03 -0700 (PDT)
First thing: What was the SCSI controller originally used on the 5.0.5 systemYes, the QLogic controller is the same ... all I did was build 5.0.7
when the SCSI drive was the root drive? If it is the QLogic drive, you should
on another machines IDE and put the IDE into the old machine with the
messed up SCSI disk.
Sounds okay so far. If the SCSI disk is from a 5.0.5 system, the activeI was able to mount /dev/part0 to /mnt and I did do it read only.
fdisk partition will be the boot partition with the root file system.
Division 0 is boot, division 1 is swap and division 2 is root. Past 2
anything goes (name wise). So you should be able to mount /dev/part0
on /mnt with the command: "mount /dev/part0 /mnt." I suggest that you
add "-r" for read only on the mount command until you know what you are
looking at (file system wise).
I looks to me that my /dev/part0 division is the boot partition/
division.
The two HTFS divisions have messed up filesystems ... these are /dev/
part4 & /dev/part5
When I do a fsck -ofull on these, they both say something like
"WARNING the filesystem is larger than it container" or something like
that (I'm at work and not at the machine in question). Both
filesystems give this warning and the reported size of the filesystem
is about twice what it says the division is.
When asked to continue I said no.
The "cannot dump to dumpdev hd(1/41)..." is not the problem but a symptom.Not sure what is causing it to panic. I think the hard disk my have
What your subject infers is that the system is panicking and when it
tries to dump memory, it can't.
problems as when I did the mkdev hd it complained about bad block
found etc.
First: If you have bad tracks in the swap space hd(1/41) the first time
the kernel tries to read a block and gets an "un-recoverable SCSI read
error" reading the block the system will panic. This is a safety feature.
When swap is corrupted, the kernel can't guarantee that data swapped in
or out is uncorrupted and so it panics the system to shut it down and avoid
potentially writing corrupted data to file.
Unlike unreadable tracks in the root or other file systems, unreadable
tracks in the swap will not be logged to /usr/adm/syslog and you won't
be warned about them.
The only fix for unreadable tracks in the swap that works is to run the SCSI
controller's "verify" function to spare out bad tracks at the controller level
before the OS sees them. All Adaptec controllers have a verify function.
Look for it on your QLogic (I don't use them so I can't tell you if it exists
on QLogic).
There is an option to go into some BIOS type SCSI menu before the OS
boots. Is this what you are talking about?
OK, that is what I wanted to try but didn't know the syntax or how to
Second: The error "cannot dump to dumpdev..." can be eliminated by telling
the kernel to not dump memory on a kernel panic. This is done by adding
"dumpdev=none" to the defbootstr either by booting with defbootstr dumpdev=none
at the Boot: prompt or by editing boot partition /etc/default/boot file and
inserting it in the defbootstr line:
vi /stand/etc/default/boot: <- example only! It gets over written from
/etc/default/boot on /etc/shutdown.
do it from the Boot : prompt since I don't get far enough to login
before the panic.
I'm able to do that now. What was freaking me out is I 'd like to
#ScoAdminInit BOOTMNT {RO RW NO} RO
#
DEFBOOTSTR=hd(40)unix swap=hd(41) dumpdev=none root=hd(42) hd=Sdsk
AUTOBOOT=YES
Back in the "old days" when swap was 1.5 * system RAM, it was okay to
dump to hd(41). But since migrating from 3.2v4.2 with 128-256M
system RAM to SCO 5.0.5 with 1-2G system RAM where the goal is to prevent
any use of swap for moving parts of running jobs from memory to swap, the
swap partition is commonly set to some fraction of system memory just for
grins and the DEFBOOTSTR dump=hd(41) is changed to dumpdev=none.
The scsi drive is hd1a. A few of the partitions divvy showed had HTFS
filesystems. What device name can I use to try to mount these to /mnt
so I can look at them and try to find root and free some space?
As you indicated that you named them part0, part1, part2, etc...:
find a inittab or something that shows what the layout of the
divisions/partitions originally was.
Shouldn't I be able to grep the /dev/part4 or /dev/part5 for the
existance of this file and maybe cat it so I can now what to properly
name things with divvy?
No, there is only one partition. I'll try to post the divvy output
Why don't you post the divvy table you see when you run "divvy /dev/hd10"
so that we can see what you see.
Note that if you have more then one UNIX partition on the disk then you
need to run divvy for each partition:
sometime.
If I recall, I only see partition 4 which has all the things I named
part0-part7 mentioned earlier.
.
- References:
- what to do about "cannot dump to dumpdev hd(1/41): space for only 0 pages"
- From: b . hutchman
- Re: what to do about "cannot dump to dumpdev hd(1/41): space for
- From: Steve M. Fabac, Jr.
- what to do about "cannot dump to dumpdev hd(1/41): space for only 0 pages"
- Prev by Date: Re: what to do about "cannot dump to dumpdev hd(1/41): space for only 0 pages"
- Next by Date: Re: what to do about "cannot dump to dumpdev hd(1/41): space for
- Previous by thread: Re: what to do about "cannot dump to dumpdev hd(1/41): space for
- Next by thread: Re: what to do about "cannot dump to dumpdev hd(1/41): space for only 0 pages"
- Index(es):
Relevant Pages
|
Loading