DUMPFS setup

[David McKenna]

 Hi All,

 I'm trying to setup  DUMPFS to use a 4GB partition to dump the system to. Used DUMPFS32_61.wpi to install, and created a 4095MB partition called SADUMP on a 512GB drive per the instructions (see attached DFSEE window). Formatted first as JFS (to force type 07), then formatted with dumpfs, again per the instructions. Used Y: as the drive letter. Set TRAPDUMP=R0,Y: in CONFIG.SYS.

 Rebooted, and hit <ctrl><alt><num-lock><num-lock> and I get a message that says the dump partition does not exist. Any idea what I might have done wrong?

 The instructions don't say so, but I wonder if the dump partition must be on the same disk as the boot partition? In this case it is not. I have an X: drive (2GB) on the boot disk that works as a dump partition only if I use 'memlimit' to limit memory to less than 2GB, but I want to get away from that if possible so I can capture unexpected traps when they happen.

Regards,

EDIT: Forgot to mention - the disk the Y: partition is on is an NVMe drive. Could that be the problem?

[Paul Smedley]

I've always just followed the instructions at https://www.arcanoae.com/wiki/how-to-get-a-trap-dump/

[David McKenna]

 Hi Paul,

  Yes, that is what I have been doing up to now,and it works, but would like to get DUMPFS working (if I can).

Regards,

[Tom]

Isn't dumpfs32 from Lars Erdmann? Then he can probably help you with any problems.

[Dave Yeo]

EDIT: Forgot to mention - the disk the Y: partition is on is an NVMe drive. Could that be the problem?

IIRC, at least the regular trap mechanism doesn't support NVMe drives. Can you use part of your ram disk?
To quote Paul's Arca Noae link,

Code: [Select]

The dump volume may be on any fixed disk accessible by the system’s AHCI disk controller or by the BIOS. For ArcaOS 5.0.7 and later, the dump volume may be on the RAM disk. Dump files cannot be written to removable media such as USB flash drives. In most cases dump files cannot be written to NVME devices.

Lars will hopefully show up and comment.

[Lars]

If the trap dump setup was properly followed (need to update config.sys manually with the TRAPDUMP keyword installer does not do that) and it still does not work, then I would go with Dave's comment:
need to move the partition to an AHCI or PATA managed Disk (or a RAM disk if you use latest ArcaOS).
As an additional check just in case something went wrong: the OS2DUMP module in the root dir should have size 10525 bytes. That's the specialized OS2DUMP that it needs for DUMPFS.IFS to work.

If you use a RAM disk, you will need need to format the partition on each system start (via startup batch file). In that case, also do not forget to first format to JFS and then to DUMPFS (as you had been doing manually).

[David McKenna]

 OK, thanks Dave and Lars... I was afraid it might be the NVMe drive. If ArcaOS 5.1 is ever actually released I was planning on running exclusively on NVMe, so guess I should try to set up with a RAM drive.

  Do either of you know if this is something that could be added to the NVMe driver, or is it a kernel limitation? I could raise an issue at the Arca bug tracker...

Regards,

[OS4User]

As an additional check just in case something went wrong: the OS2DUMP module in the root dir should have size 10525 bytes. That's the specialized OS2DUMP that it needs for DUMPFS.IFS to work.

I also checked the ability of my system to create a dump  (Os4Krnl, OS4Dump)

Dumping is ok  but  I cannot delete dump file  -  fc/2 said:

Code: [Select]

╔════════════════════════════════════╗
║ Disk write protected, cannot write ║
║          Q:\DUMPDATA.001           ║
║  [ Retry ]  [ Skip ]  [ Cancel ]   ║
╚════════════════════════════════════╝
but it seems to me that the deletion worked on earlier versions of dumpfs.ifs

[Alex Taylor]

OK, thanks Dave and Lars... I was afraid it might be the NVMe drive. If ArcaOS 5.1 is ever actually released I was planning on running exclusively on NVMe, so guess I should try to set up with a RAM drive.

  Do either of you know if this is something that could be added to the NVMe driver, or is it a kernel limitation? I could raise an issue at the Arca bug tracker...

I suggest you open an issue on the bug tracker, yes (and include a testlog).  That's generally the best way to get a problem addressed.

[Lars]

As an additional check just in case something went wrong: the OS2DUMP module in the root dir should have size 10525 bytes. That's the specialized OS2DUMP that it needs for DUMPFS.IFS to work.

I also checked the ability of my system to create a dump  (Os4Krnl, OS4Dump)

Dumping is ok  but  I cannot delete dump file  -  fc/2 said:

Code: [Select]

╔════════════════════════════════════╗
║ Disk write protected, cannot write ║
║          Q:\DUMPDATA.001           ║
║  [ Retry ]  [ Skip ]  [ Cancel ]   ║
╚════════════════════════════════════╝
but it seems to me that the deletion worked on earlier versions of dumpfs.ifs

I doubt that it worked before. In any case, deletion does not work but of course, copying does (from but even to the dump partition!)
Deletion does not really make sense as a subsequent dump will just completely overwrite the existing dump (without the need to reformat the partition).

[Lars]

OK, thanks Dave and Lars... I was afraid it might be the NVMe drive. If ArcaOS 5.1 is ever actually released I was planning on running exclusively on NVMe, so guess I should try to set up with a RAM drive.

  Do either of you know if this is something that could be added to the NVMe driver, or is it a kernel limitation? I could raise an issue at the Arca bug tracker...

Regards,

On second thought, I think that the OS2DUMP that comes with DUMPFS is a real mode executable that uses the good old BIOS calls to write to the disk (it effectively copies contiguous memory pages to contiguous disk sectors, 8 disk sectors per memory page). I cannot see how a disk driver would be involved in this. I don't know if the OS2DUMP that comes with ArcaOS is any smarter and does a better job in finding the partition to write to.

[Lars]

... and on third thought, maybe most or all NVMe manufacturers finally decided to drop legacy BIOS support for their controllers (maybe that is what AN means when they are saying: dumping to NVMe managed disk only works sometimes). In that case, there is nothing that can be done or to write an OS2DUMP module that uses UEFI functionality to perform this job.

[David McKenna]

 Lars,

... and on third thought, maybe most or all NVMe manufacturers finally decided to drop legacy BIOS support for their controllers (maybe that is what AN means when they are saying: dumping to NVMe managed disk only works sometimes). In that case, there is nothing that can be done or to write an OS2DUMP module that uses UEFI functionality to perform this job.

 And that might be why I can't boot ArcaOS from an NVMe drive on this machine using the CSM...

Regards,

[Lars]

Yes, that makes sense. If NVMe controllers no longer offer legacy BIOS support, then they will also not hook into the real mode BIOS hard disk interrupt (int 13h) to offer their service to read and write disk sectors (on the disks that they support).

But the initial boot process is entirely done by that legacy BIOS support until eventually the OS will tell the ADD drivers (be it DANIS506.ADD or OS2AHCI.ADD or OS2NVME.ADD) that they can take over and reprogram the HW to their liking.

And as you say: CSM is equivalent to saying "legacy BIOS".

[Eugene Tucker]

Well it seems to me that a lot of this may be in the UEFI them selves because I have tried to update my ASRock B450 M with my NVME drive and it will not recognize it or run Arca OS 5.07 or even install to a NVME. I did update the UEFI to the latest and no change. Strangely SATA SSD's work fine.