Beyond the reporting problem of the disk in OpenBSD I'm going ahead with my
analysis.
I'm performing an H3 test and H5 test on the CRC disk (backup #2) by a copy
machine.
H3 test result is successful. I'm waiting for H5 test result and I am enough
curious.
It shouldnt be a problem of disk
Thank you!
On 2023-03-24 14:10:50-0600, Todd C. Miller wrote:
> On Fri, 24 Mar 2023 13:10:08 -0600, "Luke A. Call" wrote:
>
> > Hi. When I run this on the binary of a test in my Rust
> > application, then run these commands in gdb, I get the following output
> > which ends with Segmentation
On Fri, 24 Mar 2023 13:10:08 -0600, "Luke A. Call" wrote:
> Hi. When I run this on the binary of a test in my Rust
> application, then run these commands in gdb, I get the following output
> which ends with Segmentation Fault:
The in-tree gdb is old, you should try the egdb package instead.
-
Hi. When I run this on the binary of a test in my Rust
application, then run these commands in gdb, I get the following output
which ends with Segmentation Fault:
nemodel-ac769fda48f1a333
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General
Just responding to this for completeness as I have some more information
on my side
On 3/24/23 07:21, Stuart Henderson wrote:
On 2023-03-23, Kaya Saman wrote:
Unfortunately I haven't been well for a long time hence the delay in
upgrade and at first found it a little difficult but the way
On 2023/03/24 18:06:03 +0800, Werner Boninsegna wrote:
> Hello,
>
> fake /dev/random means I created a file with a string of text such as
> "1234567890". This was a workaround to get the application running.
...
> Your suggestion is to chroot into /var/www and run "MAKEDEV random" ?
If you
Hello,
fake /dev/random means I created a file with a string of text such as
"1234567890". This was a workaround to get the application running.
Your suggestion is to chroot into /var/www and run "MAKEDEV random" ?
I will give it a try.
Werner
On 3/24/2023 3:27 PM, Stuart Henderson wrote:
Hi Jan,
Sorry for the missing clarifications on my settings.
>> Why would another disk have the same UID and how is that obvious?
I use hardware copy machines for all my storage devices, since 2012.
>> Your problem is a HW failure, not a clash of names.
What I mean is when I try to insert the
On 2023-03-23, Werner Boninsegna wrote:
> Please note that I had to "fake" /dev/random, as I couldn't figure out
> how to set such a device in the chroot environment.
I have no idea what a "fake" /dev/random looks like but that sounds a
lot less safe than running the cgi script outside the
On 2023-03-23, Kaya Saman wrote:
> Unfortunately I haven't been well for a long time hence the delay in
> upgrade and at first found it a little difficult but the way forward
> after a bit of reading around was to go to 7.1-release then 7.2 and
> finally jump back to Current which I believe is
On Mar 24 04:34:42, my2...@aol.com wrote:
> sd1(umass0:1:0) Check Condition (error 0x70) on opcode 0x2a
>SENSE KEY: Aborted Command
> ASC/ASCQ: information Unit iuCRC Error Detected
>
> sd1 was the original disk which the second backup disk was copy from.
> And obviously the faulty sd3
11 matches
Mail list logo
