5.6 crashes

[jggimi]

Originally Posted by hulten

Is it fine to boot from the official installation medium (5.6 release), do a clean install and select the software sets from http, pointing to the snapshot (same url as above)? Or should I expect the installation software (5.6 release) to be incompatible with newer software sets (snapshot 2014-12-27)?

You must always use a matching RAMDISK kernel for the system you are upgrading to or installing. From downloading and booting the newer bsd.rd or booting installation media, per your preference. This is because not only do the filesets have different signatures, the install and upgrade scripts change during development. And between 5.6-release and -current as of today the collection of filesets has also changed. (The etc56.tgz and xetc56.tgz filesets are no longer shipped as filesets, they are embedded, and during upgrade are unpacked during your post-upgrade sysmerge(8) step.)

Originally Posted by Carpetsmoker

I have :-)

I only use the tests during burn-in or when a problem indicative of hardware appears. That may be why I have not seen false positives.

[ibara]

Originally Posted by jggimi

This is because not only do the filesets have different signatures

Signify actually takes care of this one; that is now only historically (pre-signify) true.
The rest of what you said is valid though.

[jggimi]

Thanks for the correction, ibara. This also gives me the opportunity to answer another question.

Originally Posted by hulten

However, it gives an "ERR M" ...

This is an error issued by the first stage bootloader. It did not point to a valid second stage bootloader -- the ERR M signifies the second stage bootloader location does not have a valid magic number. Quoting FAQ 14:

This generally means whatever it was that was read in was NOT /boot, usually meaning installboot(8) was run incorrectly, the /boot file was altered, or you have exceeded your BIOS's ability to read a large disk.

[IdOp]

Originally Posted by hulten

I looked carefully at all capacitors, but they all look like nice cylinders without any bulging or leakage.

I'm glad those look good. But, given that both Linux and OpenBSD are crashing (and given the age of the machine) my sense is that the chances that this is due to hardware failing are probably > 50%. If it's not the capacitiors, it could be any other component on the motherboard, or a bad connection, or failing voltage regulation in the power supply, or ... .

If it were my machine (and it's not ...) I would be checking for crashes under any other OS I could conveniently boot on it, including DOS, and even just flipping around in the BIOS setup program and waiting for a crash. With each new software environment under which you can reproduce a crash, the case against the hardware becomes that much stronger.

[hulten]

I have done an official/consistent install through two USB sticks, one with floppy56.fs (that had no support for my network interface) and one with an FFS file system. This circumvented the "ERR M" problem (apparently my BIOS cannot handle large disks). While it took some effort to figure out, a nice side effect is that I now know much more about the boot process and disk partitioning.

IdOp is right that I could do some sensible Bayesian updating on whether it is hardware failure or not by means of more testing. However, I do not have local access to the computer for several months from next Sunday, and I think that it may be useful that some OpenBSD hacker has a look at it at this point, so I did a bug report:

http://marc.info/?l=openbsd-bugs&m=142023435825321&w=2

(Strange thing on marc.info is that sometimes the message cannot be found; refreshing a few times works.)

[shep]

(Strange thing on marc.info is that sometimes the message cannot be found; refreshing a few times works.)

I think marc.info has a slight hang over for the new year. The Nabble mirror appears to be intact
http://openbsd.7691.n7.nabble.com/op...r-misc-f3.html