NEW: net/bitcoin

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

NEW: net/bitcoin

Rafael Sadowski
Hi ports@

Attached is a new port for bitcoin. Long time ago pascal@ started
working on bitcoin in openbsd-wip. I've finished this work and run a full
bitcoin node over weeks without problems so far:

https://twitter.com/sizeofvoid/status/976586173538885632

$ cat net/bitcoin/pkg/DESCR

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.

Ok? Comments?

Greetings to the hackerroom.

Rafael Sadowski

bitcoin.tar.gz (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
*ping*

On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:

> Hi ports@
>
> Attached is a new port for bitcoin. Long time ago pascal@ started
> working on bitcoin in openbsd-wip. I've finished this work and run a full
> bitcoin node over weeks without problems so far:
>
> https://twitter.com/sizeofvoid/status/976586173538885632
>
> $ cat net/bitcoin/pkg/DESCR
>
> Bitcoin is an experimental new digital currency that enables instant
> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> technology to operate with no central authority: managing transactions
> and issuing money are carried out collectively by the network.
> Bitcoin is also the name of the open source software which enables
> the use of this currency.
>
> Ok? Comments?
>
> Greetings to the hackerroom.
>
> Rafael Sadowski


Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Brian Callahan-3

On 05/05/18 07:29, Rafael Sadowski wrote:

> *ping*
>
> On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
>> Hi ports@
>>
>> Attached is a new port for bitcoin. Long time ago pascal@ started
>> working on bitcoin in openbsd-wip. I've finished this work and run a full
>> bitcoin node over weeks without problems so far:
>>
>> https://twitter.com/sizeofvoid/status/976586173538885632
>>
>> $ cat net/bitcoin/pkg/DESCR
>>
>> Bitcoin is an experimental new digital currency that enables instant
>> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
>> technology to operate with no central authority: managing transactions
>> and issuing money are carried out collectively by the network.
>> Bitcoin is also the name of the open source software which enables
>> the use of this currency.
>>
>> Ok? Comments?
>>
>> Greetings to the hackerroom.
>>
>> Rafael Sadowski
>

It reads and builds ok, and bitcoin-qt even launches.
I am not going to download the 200GB (!!!) that it wants me to, so
that's as far as I can test.
portcheck -N complains about hardcoded paths in pkg/bitcoind.rc

One thought from me: is there no hope for this to build on !CLANG_ARCHS?
(You only have COMPILER=base-clang ports-clang). Maybe that is the right
way to go, since I'm guessing you wouldn't want to run this on a machine
that doesn't have clang available to it since it's probably far too slow.

In that case, you don't need that CXXFLAGS line.

~Brian

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote:

>
> On 05/05/18 07:29, Rafael Sadowski wrote:
> > *ping*
> >
> > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> > > Hi ports@
> > >
> > > Attached is a new port for bitcoin. Long time ago pascal@ started
> > > working on bitcoin in openbsd-wip. I've finished this work and run a full
> > > bitcoin node over weeks without problems so far:
> > >
> > > https://twitter.com/sizeofvoid/status/976586173538885632
> > >
> > > $ cat net/bitcoin/pkg/DESCR
> > >
> > > Bitcoin is an experimental new digital currency that enables instant
> > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> > > technology to operate with no central authority: managing transactions
> > > and issuing money are carried out collectively by the network.
> > > Bitcoin is also the name of the open source software which enables
> > > the use of this currency.
> > >
> > > Ok? Comments?
> > >
> > > Greetings to the hackerroom.
> > >
> > > Rafael Sadowski
> >
>
> It reads and builds ok, and bitcoin-qt even launches.
> I am not going to download the 200GB (!!!) that it wants me to, so that's as
> far as I can test.
> portcheck -N complains about hardcoded paths in pkg/bitcoind.rc
>
> One thought from me: is there no hope for this to build on !CLANG_ARCHS?
> (You only have COMPILER=base-clang ports-clang). Maybe that is the right way
> to go, since I'm guessing you wouldn't want to run this on a machine that
> doesn't have clang available to it since it's probably far too slow.
>
> In that case, you don't need that CXXFLAGS line.
>

It doesn't build with ports-gcc and you already said it: "... you
wouldn't want to run this on a machine that doesn't have clang available
to it since it's probably far too slow."

Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}?

Thanks for test and review!

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
anyone?

On Sun May 06, 2018 at 09:21:50PM +0200, Rafael Sadowski wrote:

> On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote:
> >
> > On 05/05/18 07:29, Rafael Sadowski wrote:
> > > *ping*
> > >
> > > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> > > > Hi ports@
> > > >
> > > > Attached is a new port for bitcoin. Long time ago pascal@ started
> > > > working on bitcoin in openbsd-wip. I've finished this work and run a full
> > > > bitcoin node over weeks without problems so far:
> > > >
> > > > https://twitter.com/sizeofvoid/status/976586173538885632
> > > >
> > > > $ cat net/bitcoin/pkg/DESCR
> > > >
> > > > Bitcoin is an experimental new digital currency that enables instant
> > > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> > > > technology to operate with no central authority: managing transactions
> > > > and issuing money are carried out collectively by the network.
> > > > Bitcoin is also the name of the open source software which enables
> > > > the use of this currency.
> > > >
> > > > Ok? Comments?
> > > >
> > > > Greetings to the hackerroom.
> > > >
> > > > Rafael Sadowski
> > >
> >
> > It reads and builds ok, and bitcoin-qt even launches.
> > I am not going to download the 200GB (!!!) that it wants me to, so that's as
> > far as I can test.
> > portcheck -N complains about hardcoded paths in pkg/bitcoind.rc
> >
> > One thought from me: is there no hope for this to build on !CLANG_ARCHS?
> > (You only have COMPILER=base-clang ports-clang). Maybe that is the right way
> > to go, since I'm guessing you wouldn't want to run this on a machine that
> > doesn't have clang available to it since it's probably far too slow.
> >
> > In that case, you don't need that CXXFLAGS line.
> >
>
> It doesn't build with ports-gcc and you already said it: "... you
> wouldn't want to run this on a machine that doesn't have clang available
> to it since it's probably far too slow."
>
> Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}?
>
> Thanks for test and review!
>

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Joseph Mayer
In reply to this post by Rafael Sadowski
2018-05-07 3:21 GMT+08:00 Rafael Sadowski <[hidden email]>:
> It doesn't build with ports-gcc

I got it built using ports not too long ago.

What issues did you get trying to build it using gcc-ports (GCC 4.9.4)?

The only issue was the difficulty of install Berkeley DB, which can be
resolved by either building and installing (how?) or something like
--disable-wallet, as only the wallet subfunctionality uses it anyhow,
not the central router.

Do you build the QT and wallet parts?

> and you already said it: "... you wouldn't want to run this on a
> machine that doesn't have clang available to it since it's probably
> far too slow."

Clang may be working well for many projects, this one included, but
there are also projects today where Clang consistently performs
disastrously, so GCC will remain having a valid niche, maybe for very
long.

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
On Fri May 18, 2018 at 11:47:48AM -0400, Joseph Mayer wrote:
> 2018-05-07 3:21 GMT+08:00 Rafael Sadowski <[hidden email]>:
> > It doesn't build with ports-gcc
>
> I got it built using ports not too long ago.
>
> What issues did you get trying to build it using gcc-ports (GCC 4.9.4)?

Please find attached my GCC output. The same linker call works with
clang but not with ports-gcc.

>
> The only issue was the difficulty of install Berkeley DB, which can be
> resolved by either building and installing (how?) or something like
> --disable-wallet, as only the wallet subfunctionality uses it anyhow,
> not the central router.
>
> Do you build the QT and wallet parts?

Please check the ports Makefile.

>
> > and you already said it: "... you wouldn't want to run this on a
> > machine that doesn't have clang available to it since it's probably
> > far too slow."
>
> Clang may be working well for many projects, this one included, but
> there are also projects today where Clang consistently performs
> disastrously, so GCC will remain having a valid niche, maybe for very
> long.
>
It's about architectures not projects.

bitcoin.gcc48.link.error (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
In reply to this post by Rafael Sadowski
3rd ping, or 4rd? Could anyone sacrifice themselves, please.

It's not evil! It's NOT mining. ;)

On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:

> Hi ports@
>
> Attached is a new port for bitcoin. Long time ago pascal@ started
> working on bitcoin in openbsd-wip. I've finished this work and run a full
> bitcoin node over weeks without problems so far:
>
> https://twitter.com/sizeofvoid/status/976586173538885632
>
> $ cat net/bitcoin/pkg/DESCR
>
> Bitcoin is an experimental new digital currency that enables instant
> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> technology to operate with no central authority: managing transactions
> and issuing money are carried out collectively by the network.
> Bitcoin is also the name of the open source software which enables
> the use of this currency.
>
> Ok? Comments?
>
> Greetings to the hackerroom.
>
> Rafael Sadowski


Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Thomas Frohwein-2
I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps.

On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <[hidden email]> wrote:

>3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>
>It's not evil! It's NOT mining. ;)
>
>On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
>> Hi ports@
>>
>> Attached is a new port for bitcoin. Long time ago pascal@ started
>> working on bitcoin in openbsd-wip. I've finished this work and run a
>full
>> bitcoin node over weeks without problems so far:
>>
>> https://twitter.com/sizeofvoid/status/976586173538885632
>>
>> $ cat net/bitcoin/pkg/DESCR
>>
>> Bitcoin is an experimental new digital currency that enables instant
>> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
>> technology to operate with no central authority: managing
>transactions
>> and issuing money are carried out collectively by the network.
>> Bitcoin is also the name of the open source software which enables
>> the use of this currency.
>>
>> Ok? Comments?
>>
>> Greetings to the hackerroom.
>>
>> Rafael Sadowski

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Thomas Frohwein-2
On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email] wrote:
> I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps.
>
> On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <[hidden email]> wrote:
> >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> >
> >It's not evil! It's NOT mining. ;)

I installed it and tried to sync the 200GB blockchain to my external HDD
(because that's the only one that got this much space available). It
synced fine for 1-2 days with the bitcoin-qt client, but then at about
30-40% of the blockchain synced, it now starts throwing an error:

ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, nPos=6513581)

When this happens, the following lines appear in dmesg:

sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
        SENSE KEY: Media Error
        ASC/ASCQ: Unrecovered Read Error

Fortunately, the drive still seems to be functional otherwise, can be
mounted and fsck -f doesn't see any issues. The dmesg lines reappear
whenever mounting or unmounting said drive until I disconnect and
reconnect the drive from the USB port.

I can't resume syncing the blockchain though because the error appears
again.

Not sure if this is a deficiency of the port or maybe the hard drive
itself...

bitcoin's debug.log (9.5M): https://thfr.info/tmpstor/debug.log

OpenBSD 6.3-current (GENERIC.MP) #36: Wed Jun 20 00:03:07 MDT 2018
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7454228480 (7108MB)
avail mem = 7157866496 (6826MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x3f262000 (86 entries)
bios0: vendor American Megatrends Inc. version "1.A0" date 02/27/2018
bios0: MSI MS-7A74
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 WSMT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3892.39 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3890.94 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 23999999 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus -1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus -1 (RP06)
acpiprt15 at acpi0: bus 2 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiprt25 at acpi0: bus -1 (RP14)
acpiprt26 at acpi0: bus -1 (RP15)
acpiprt27 at acpi0: bus -1 (RP16)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PG00, resource for PEG0
acpipwrres1 at acpi0: PG01, resource for PEG1
acpipwrres2 at acpi0: PG02, resource for PEG2
acpipwrres3 at acpi0: WRST
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpipwrres6 at acpi0: WRST
acpipwrres7 at acpi0: WRST
acpipwrres8 at acpi0: WRST
acpipwrres9 at acpi0: WRST
acpipwrres10 at acpi0: WRST
acpipwrres11 at acpi0: WRST
acpipwrres12 at acpi0: WRST
acpipwrres13 at acpi0: WRST
acpipwrres14 at acpi0: WRST
acpipwrres15 at acpi0: WRST
acpipwrres16 at acpi0: WRST
acpipwrres17 at acpi0: WRST
acpipwrres18 at acpi0: WRST
acpipwrres19 at acpi0: WRST
acpipwrres20 at acpi0: WRST
acpipwrres21 at acpi0: WRST
acpipwrres22 at acpi0: WRST
acpipwrres23 at acpi0: FN00, resource for FAN0
acpipwrres24 at acpi0: FN01, resource for FAN1
acpipwrres25 at acpi0: FN02, resource for FAN2
acpipwrres26 at acpi0: FN03, resource for FAN3
acpipwrres27 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 119 degC
acpitz1 at acpi0: critical temperature is 119 degC
acpicmos0 at acpi0
"INT3F0D" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"INT33A1" at acpi0 not configured
acpibtn1 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
"INT340E" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3892 MHz: speeds: 3900, 3700, 3500, 3300, 3100, 2900, 2700, 2500, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x590f rev 0x06
ppb0 at pci0 dev 1 function 0 "Intel Core 6G PCIE" rev 0x06: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67b1 rev 0x80
drm1 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 vendor "ATI", unknown product 0xaac8 rev 0x00: msi
azalia0: no supported codecs
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 630" rev 0x04
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/kbl_dmc_ver1.bin (-22)
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 200 Series xHCI" rev 0x00: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 200 Series Thermal" rev 0x00 at pci0 dev 20 function 2 not configured
"Intel 200 Series MEI" rev 0x00 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 200 Series AHCI" rev 0x00: msi, AHCI 1.3.1
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 6.0Gb/s
ahci0: PHY offline on port 2
ahci0: PHY offline on port 3
ahci0: PHY offline on port 4
ahci0: port 5: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, HITACHI HTS72321, EC1Z> SCSI3 0/direct fixed naa.5000cca61ac0734c
sd0: 152627MB, 512 bytes/sector, 312581808 sectors
sd1 at scsibus1 targ 1 lun 0: <ATA, WDC WDS500G2B0B-, X611> SCSI3 0/direct fixed naa.5001b448b6be5535
sd1: 476940MB, 512 bytes/sector, 976773168 sectors, thin
sd2 at scsibus1 targ 5 lun 0: <ATA, Hitachi HUA72202, JKAO> SCSI3 0/direct fixed naa.5000cca222d7946d
sd2: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb1 at pci0 dev 28 function 0 "Intel 200 Series PCIE" rev 0xf0: msi
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), msi, address 30:9c:23:9c:f7:40
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
pcib0 at pci0 dev 31 function 0 "Intel B250 LPC" rev 0x00
"Intel 200 Series PMC" rev 0x00 at pci0 dev 31 function 2 not configured
azalia1 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x00: msi
azalia1: codecs: Realtek/0x0887, Intel/0x280b, using Realtek/0x0887
audio0 at azalia1
ichiic0 at pci0 dev 31 function 4 "Intel 200 Series SMBus" rev 0x00: apic 2 int 16
iic0 at ichiic0
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
uhidev0 at uhub0 port 3 configuration 1 interface 0 "Logitech USB Laser Mouse" rev 2.00/31.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 8 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 4 configuration 1 interface 0 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev2 at uhub0 port 4 configuration 1 interface 1 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev2: iclass 3/0, 7 report ids
uhid0 at uhidev2 reportid 2: input=1, output=0, feature=0
uhid1 at uhidev2 reportid 3: input=2, output=0, feature=0
ukbd1 at uhidev2 reportid 5: 112 variable keys, 0 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhid2 at uhidev2 reportid 6: input=2, output=0, feature=0
uhid3 at uhidev2 reportid 7: input=0, output=0, feature=7
uhidev3 at uhub0 port 4 configuration 1 interface 2 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev3: iclass 3/0
uhid4 at uhidev3: input=8, output=8, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd3 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> SCSI2 0/direct fixed
sd3: 254538MB, 512 bytes/sector, 521295344 sectors
root on sd3a (48181a026c4a6623.a) swap on sd3b dump on sd3b
initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x148C:0x2358).
error: [drm:pid0:cik_ring_test] *ERROR* radeon: ring 2 test failed (scratch(0x3010C)=0xCAFEDEAD)
radeondrm0: 1024x768, 32bpp
wsdisplay1 at radeondrm0
wsdisplay1: screen 0-5 added (std, vt100 emulation)
lock order reversal:
 1st 0xffffffff81df5a20 &sched_lock (&sched_lock) @ /usr/src/sys/kern/kern_synch.c:444
 2nd 0xffff80000028f270 &dev_priv->irq_lock (&dev_priv->irq_lock) @ /usr/src/sys/dev/pci/drm/i915/intel_lrc.c:1645
lock order "&dev_priv->irq_lock"(mutex) -> "&sched_lock"(sched_lock) first seen at:
#0  witness_checkorder+0x4c0
#1  ___mp_lock+0x70
#2  wakeup_n+0x39
#3  task_add+0x93
#4  gen6_rps_boost+0x129
#5  __i915_wait_request+0x155
#6  i915_wait_request+0x97
#7  i915_gem_object_wait_rendering+0x19c
#8  i915_gem_object_sync+0x6c
#9  i915_gem_object_pin_to_display_plane+0x2e
#10 intel_pin_and_fence_fb_obj+0x1cd
#11 intel_prepare_plane_fb+0xb4
#12 drm_atomic_helper_prepare_planes+0x6b
#13 intel_atomic_commit+0x52
#14 drm_atomic_helper_set_config+0x80
#15 drm_mode_setcrtc+0x36f
#16 drm_do_ioctl+0x221
#17 drmioctl+0xf9
#18 VOP_IOCTL+0x5a
lock order "&sched_lock"(sched_lock) -> "&dev_priv->irq_lock"(mutex) first seen at:
#0  witness_checkorder+0x4c0
#1  _mtx_enter+0x31
#2  gen8_logical_ring_put_irq+0x36
#3  __i915_wait_request+0x367
#4  intel_mmio_flip_work_func+0x3e
#5  taskq_thread+0x6d
chrome[97379]: pledge "rpath", syscall 5
error: [drm:pid28539:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
error: [drm:pid52906:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
umass0 at uhub0 port 17 configuration 1 interface 0 "Western Digital My Book 1230" rev 3.00/10.65 addr 4
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
ses0 at scsibus4 targ 1 lun 1: <WD, SES Device, 1065> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration
trap [higan]56862/240671 type 262: sp 1565e5d471a8 not inside 7f7fffbc1000-7f7ffffc1000
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Logitech Dual Action" rev 2.00/4.14 addr 5
uhidev4: iclass 3/0
uhid5 at uhidev4: input=8, output=7, feature=0
uhid5 detached
uhidev4 detached
chrome[95449]: pledge "rpath", syscall 5
error: [drm:pid28539:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Logitech Dual Action" rev 2.00/4.14 addr 5
uhidev4: iclass 3/0
uhid5 at uhidev4: input=8, output=7, feature=0
uhid5 detached
uhidev4 detached
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Gamepad F310" rev 2.00/40.14 addr 5
uhidev4: iclass 255/93
uhid5 at uhidev4: input=20, output=0, feature=0
uhid5 detached
uhidev4 detached
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Logitech Dual Action" rev 2.00/4.14 addr 5
uhidev4: iclass 3/0
uhid5 at uhidev4: input=8, output=7, feature=0
uhid5 detached
uhidev4 detached
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Gamepad F310" rev 2.00/40.14 addr 5
uhidev4: iclass 255/93
uhid5 at uhidev4: input=20, output=0, feature=0
uhid5 detached
uhidev4 detached
error: [drm:pid28539:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Gamepad F310" rev 2.00/40.14 addr 5
uhidev4: iclass 255/93
uhid5 at uhidev4: input=20, output=0, feature=0
uhid5 detached
uhidev4 detached
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Logitech Dual Action" rev 2.00/4.14 addr 5
uhidev4: iclass 3/0
uhid5 at uhidev4: input=8, output=7, feature=0
uhid5 detached
uhidev4 detached
uhidev4 at uhub0 port 5 configuration 1 interface 0 "Logitech Logitech Dual Action" rev 2.00/4.14 addr 5
uhidev4: iclass 3/0
uhid5 at uhidev4: input=8, output=7, feature=0
WARNING visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11735
WARNING was_visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11732
WARNING visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11735
WARNING was_visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11732
WARNING visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11735
WARNING was_visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11732
WARNING visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11735
WARNING was_visible failed at /usr/src/sys/dev/pci/drm/i915/intel_display.c:11732
error: [drm:pid28539:intel_pipe_update_start] *ERROR* Potential atomic update failure on pipe A
uhid5 detached
uhidev4 detached
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
    SENSE KEY: Media Error
     ASC/ASCQ: Unrecovered Read Error
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
    SENSE KEY: Media Error
     ASC/ASCQ: Unrecovered Read Error
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
syncing disks... done
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
reboo
OpenBSD 6.3-current (GENERIC.MP) #36: Wed Jun 20 00:03:07 MDT 2018
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7454228480 (7108MB)
avail mem = 7157874688 (6826MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x3f262000 (86 entries)
bios0: vendor American Megatrends Inc. version "1.A0" date 02/27/2018
bios0: MSI MS-7A74
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 WSMT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3892.41 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3890.94 MHz
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe0000000, bus 0-255
acpihpet0 at acpi0: 23999999 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus -1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus -1 (RP06)
acpiprt15 at acpi0: bus 2 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiprt25 at acpi0: bus -1 (RP14)
acpiprt26 at acpi0: bus -1 (RP15)
acpiprt27 at acpi0: bus -1 (RP16)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PG00, resource for PEG0
acpipwrres1 at acpi0: PG01, resource for PEG1
acpipwrres2 at acpi0: PG02, resource for PEG2
acpipwrres3 at acpi0: WRST
acpipwrres4 at acpi0: WRST
acpipwrres5 at acpi0: WRST
acpipwrres6 at acpi0: WRST
acpipwrres7 at acpi0: WRST
acpipwrres8 at acpi0: WRST
acpipwrres9 at acpi0: WRST
acpipwrres10 at acpi0: WRST
acpipwrres11 at acpi0: WRST
acpipwrres12 at acpi0: WRST
acpipwrres13 at acpi0: WRST
acpipwrres14 at acpi0: WRST
acpipwrres15 at acpi0: WRST
acpipwrres16 at acpi0: WRST
acpipwrres17 at acpi0: WRST
acpipwrres18 at acpi0: WRST
acpipwrres19 at acpi0: WRST
acpipwrres20 at acpi0: WRST
acpipwrres21 at acpi0: WRST
acpipwrres22 at acpi0: WRST
acpipwrres23 at acpi0: FN00, resource for FAN0
acpipwrres24 at acpi0: FN01, resource for FAN1
acpipwrres25 at acpi0: FN02, resource for FAN2
acpipwrres26 at acpi0: FN03, resource for FAN3
acpipwrres27 at acpi0: FN04, resource for FAN4
acpitz0 at acpi0: critical temperature is 119 degC
acpitz1 at acpi0: critical temperature is 119 degC
acpicmos0 at acpi0
"INT3F0D" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpibtn0 at acpi0: SLPB
"INT33A1" at acpi0 not configured
acpibtn1 at acpi0: PWRB
"PNP0C14" at acpi0 not configured
"INT340E" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 3892 MHz: speeds: 3900, 3700, 3500, 3300, 3100, 2900, 2700, 2500, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x590f rev 0x06
ppb0 at pci0 dev 1 function 0 "Intel Core 6G PCIE" rev 0x06: msi
pci1 at ppb0 bus 1
radeondrm0 at pci1 dev 0 function 0 vendor "ATI", unknown product 0x67b1 rev 0x80
drm1 at radeondrm0
radeondrm0: msi
azalia0 at pci1 dev 0 function 1 vendor "ATI", unknown product 0xaac8 rev 0x00: msi
azalia0: no supported codecs
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 630" rev 0x04
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load firmware i915/kbl_dmc_ver1.bin (-22)
inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel Core GMM" rev 0x00 at pci0 dev 8 function 0 not configured
xhci0 at pci0 dev 20 function 0 "Intel 200 Series xHCI" rev 0x00: msi, xHCI 1.0
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1
"Intel 200 Series Thermal" rev 0x00 at pci0 dev 20 function 2 not configured
"Intel 200 Series MEI" rev 0x00 at pci0 dev 22 function 0 not configured
ahci0 at pci0 dev 23 function 0 "Intel 200 Series AHCI" rev 0x00: msi, AHCI 1.3.1
ahci0: port 0: 3.0Gb/s
ahci0: port 1: 6.0Gb/s
ahci0: PHY offline on port 2
ahci0: PHY offline on port 3
ahci0: PHY offline on port 4
ahci0: port 5: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: <ATA, HITACHI HTS72321, EC1Z> SCSI3 0/direct fixed naa.5000cca61ac0734c
sd0: 152627MB, 512 bytes/sector, 312581808 sectors
sd1 at scsibus1 targ 1 lun 0: <ATA, WDC WDS500G2B0B-, X611> SCSI3 0/direct fixed naa.5001b448b6be5535
sd1: 476940MB, 512 bytes/sector, 976773168 sectors, thin
sd2 at scsibus1 targ 5 lun 0: <ATA, Hitachi HUA72202, JKAO> SCSI3 0/direct fixed naa.5000cca222d7946d
sd2: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb1 at pci0 dev 28 function 0 "Intel 200 Series PCIE" rev 0xf0: msi
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x15: RTL8168H/8111H (0x5400), msi, address 30:9c:23:9c:f7:40
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
pcib0 at pci0 dev 31 function 0 "Intel B250 LPC" rev 0x00
"Intel 200 Series PMC" rev 0x00 at pci0 dev 31 function 2 not configured
azalia1 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x00: msi
azalia1: codecs: Realtek/0x0887, Intel/0x280b, using Realtek/0x0887
audio0 at azalia1
ichiic0 at pci0 dev 31 function 4 "Intel 200 Series SMBus" rev 0x00: apic 2 int 16
iic0 at ichiic0
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vmm0 at mainbus0: VMX/EPT
uhidev0 at uhub0 port 3 configuration 1 interface 0 "Logitech USB Laser Mouse" rev 2.00/31.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 8 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 4 configuration 1 interface 0 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev2 at uhub0 port 4 configuration 1 interface 1 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev2: iclass 3/0, 7 report ids
uhid0 at uhidev2 reportid 2: input=1, output=0, feature=0
uhid1 at uhidev2 reportid 3: input=2, output=0, feature=0
ukbd1 at uhidev2 reportid 5: 112 variable keys, 0 key codes
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhid2 at uhidev2 reportid 6: input=2, output=0, feature=0
uhid3 at uhidev2 reportid 7: input=0, output=0, feature=7
uhidev3 at uhub0 port 4 configuration 1 interface 2 "Holtek USB Keyboard" rev 2.00/1.05 addr 3
uhidev3: iclass 3/0
uhid4 at uhidev3: input=8, output=8, feature=0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
sd3 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 006> SCSI2 0/direct fixed
sd3: 254538MB, 512 bytes/sector, 521295344 sectors
root on sd3a (48181a026c4a6623.a) swap on sd3b dump on sd3b
initializing kernel modesetting (HAWAII 0x1002:0x67B1 0x148C:0x2358).
error: [drm:pid0:cik_ring_test] *ERROR* radeon: ring 2 test failed (scratch(0x3010C)=0xCAFEDEAD)
radeondrm0: 1024x768, 32bpp
wsdisplay1 at radeondrm0
wsdisplay1: screen 0-5 added (std, vt100 emulation)
umass0 at uhub0 port 17 configuration 1 interface 0 "Western Digital My Book 1230" rev 3.00/10.65 addr 4
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
ses0 at scsibus4 targ 1 lun 1: <WD, SES Device, 1065> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration
lock order reversal:
 1st 0xffffffff81df7f00 &sched_lock (&sched_lock) @ /usr/src/sys/kern/kern_synch.c:444
 2nd 0xffff80000028f270 &dev_priv->irq_lock (&dev_priv->irq_lock) @ /usr/src/sys/dev/pci/drm/i915/intel_lrc.c:1645
lock order "&dev_priv->irq_lock"(mutex) -> "&sched_lock"(sched_lock) first seen at:
#0  witness_checkorder+0x4c0
#1  ___mp_lock+0x70
#2  wakeup_n+0x39
#3  task_add+0x93
#4  gen6_rps_boost+0x129
#5  __i915_wait_request+0x155
#6  i915_gem_object_wait_rendering__nonblocking+0x1d6
#7  i915_gem_set_domain_ioctl+0xdb
#8  drm_do_ioctl+0x221
#9  drmioctl+0xf9
#10 VOP_IOCTL+0x5a
#11 vn_ioctl+0x6b
#12 sys_ioctl+0x457
#13 syscall+0x32a
#14 Xsyscall_untramp+0xe4
lock order "&sched_lock"(sched_lock) -> "&dev_priv->irq_lock"(mutex) first seen at:
#0  witness_checkorder+0x4c0
#1  _mtx_enter+0x31
#2  gen8_logical_ring_put_irq+0x36
#3  __i915_wait_request+0x367
#4  intel_mmio_flip_work_func+0x3e
#5  taskq_thread+0x6d
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
    SENSE KEY: Media Error
     ASC/ASCQ: Unrecovered Read Error
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x35
    SENSE KEY: Hardware Error
     ASC/ASCQ: Internal Target Failure
sd4 detached
ses0 detached
scsibus4 detached
umass0 detached
umass0 at uhub0 port 17 configuration 1 interface 0 "Western Digital My Book 1230" rev 3.00/10.65 addr 4
umass0: using SCSI over Bulk-Only
scsibus4 at umass0: 2 targets, initiator 0
sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
ses0 at scsibus4 targ 1 lun 1: <WD, SES Device, 1065> SCSI4 13/enclosure services fixed
ses0: unable to read enclosure configuration

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Bryan Linton
On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]> wrote:

> On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email] wrote:
> > I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps.
> >
> > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <[hidden email]> wrote:
> > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > >
> > >It's not evil! It's NOT mining. ;)
>
> I installed it and tried to sync the 200GB blockchain to my external HDD
> (because that's the only one that got this much space available). It
> synced fine for 1-2 days with the bitcoin-qt client, but then at about
> 30-40% of the blockchain synced, it now starts throwing an error:
>
> ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, nPos=6513581)
>
> When this happens, the following lines appear in dmesg:
>
> sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> SENSE KEY: Media Error
> ASC/ASCQ: Unrecovered Read Error
>
> Fortunately, the drive still seems to be functional otherwise, can be
> mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> whenever mounting or unmounting said drive until I disconnect and
> reconnect the drive from the USB port.
>

This is almost certainly a problem with the drive.  I've had
several hard drives fail over the ~13 years or so I've been using
OpenBSD, and this is exactly the kind of error I see when the
drive is wearing out.

The message means that the kernel could not read a sector on the
drive despite trying to do so.  I've had drives continue to
otherwise work for years after throwing errors like that (though I
made sure to back them up and only used them as "scratch" drives).
Another time I had a drive fail within weeks of throwing an error
like that.

If it's still under warranty, I'd recommend sending it in for
replacement.  If it's not, I'd *highly* recommend backing up
anything on there to another drive.

Sometimes, sectors can be "weak" and if you give the drive enough
time it will be able to read it, so if it can't be backed up
entirely, back up as much as you can, then let the drive sit for a
few days and try again.

Some ports that may help:
        sysutils/ddrescue
        sysutils/testdisk
        sysutils/e2fsprogs (for the "badblocks" program)
        net/rsync (probably obvious, but still worth mentioning)

Modern drives keep "spare sectors" in which to remap failing ones
like this, but they usually only do so when *writing* to the
sector, not when *reading* it.

You could try backing up the drive, then writing zeros to the
entire drive with dd(1) to try to see if it helps.  You could also
try running "badblocks -n" on the drive (from sysutils/e2fsprogs).

        -n    Use non-destructive read-write mode.  By default only a non-
              destructive read-only test is done.  This option must not be
              combined with the -w option, as they are mutually exclusive.

"badblocks -n" will read all sectors on the drive and write back
the same data to the sector.  If it's "weak", and the program can
manage to read the sector, the drive may then remap that sector to
a spare.

But!  How much do you really trust a drive that has started to
fail?  Drives are cheap.  Cheaper than they've ever been.  If this
drive contains the only copy of family photos of your dearly
departed grandmother, are you willing to risk it?

        sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
        sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors

I see a 3TB Western Digital My Book on a very popular online
retailer for only $89.99 USD with free shipping as I type this.

Is the data on that drive worth more than that?  Is the amount of
time you'd spend trying to squeeze a little more life out of the
drive worth it?  How much do you value your free time?  If you
enjoy tinkering with things like this and don't have valuable data
on it, it may be worth trying.  If you'd rather spend that time
outside hiking or seeing friends and family, then it may be more
economical to just buy a new one.  

Ultimately, only you can decide.

> I can't resume syncing the blockchain though because the error appears
> again.
>

While I'm here, I poked around bitcoin's manpage and found this:

 -prune=<n>

              Reduce storage requirements by enabling pruning (deleting) of
              old blocks. This allows the pruneblockchain RPC to be called to
              delete specific blocks, and enables automatic pruning of old
              blocks if a target size in MiB is provided. This mode is
              incompatible with -txindex and -rescan. Warning: Reverting this
              setting requires re-downloading the entire blockchain. (default:
              0 = disable pruning blocks, 1 = allow manual pruning via RPC,
              >550 = automatically prune block files to stay under the
              specified target size in MiB)

I have no idea if this only works *after* downloading the entire
blockchain or not, but it might be worth trying this option and
seeing if it will obviate the need for downloading 200+ GB of
data.

Rafael:
If setting this option works out-of-the-box, it might be worth
making a note of it.  Reading back through the thread, I see some
people saying that they couldn't test or use the port because they
don't have 200 GB of space for it.

If it works, it might be worth adding a note to MESSAGE or a
README since this is probably going to be a common issue for most
people.

> Not sure if this is a deficiency of the port or maybe the hard drive
> itself...
>

As said above, it's almost certainly the drive.  Please be sure to
back up anything important as soon as you can.

--
Bryan

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:

> On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]> wrote:
> > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email] wrote:
> > > I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps.
> > >
> > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <[hidden email]> wrote:
> > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > >
> > > >It's not evil! It's NOT mining. ;)
> >
> > I installed it and tried to sync the 200GB blockchain to my external HDD
> > (because that's the only one that got this much space available). It
> > synced fine for 1-2 days with the bitcoin-qt client, but then at about
> > 30-40% of the blockchain synced, it now starts throwing an error:
> >
> > ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, nPos=6513581)
> >
> > When this happens, the following lines appear in dmesg:
> >
> > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > SENSE KEY: Media Error
> > ASC/ASCQ: Unrecovered Read Error
> >
> > Fortunately, the drive still seems to be functional otherwise, can be
> > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > whenever mounting or unmounting said drive until I disconnect and
> > reconnect the drive from the USB port.
> >
>
> This is almost certainly a problem with the drive.  I've had
> several hard drives fail over the ~13 years or so I've been using
> OpenBSD, and this is exactly the kind of error I see when the
> drive is wearing out.
>
> The message means that the kernel could not read a sector on the
> drive despite trying to do so.  I've had drives continue to
> otherwise work for years after throwing errors like that (though I
> made sure to back them up and only used them as "scratch" drives).
> Another time I had a drive fail within weeks of throwing an error
> like that.
>
> If it's still under warranty, I'd recommend sending it in for
> replacement.  If it's not, I'd *highly* recommend backing up
> anything on there to another drive.
>
> Sometimes, sectors can be "weak" and if you give the drive enough
> time it will be able to read it, so if it can't be backed up
> entirely, back up as much as you can, then let the drive sit for a
> few days and try again.
>
> Some ports that may help:
> sysutils/ddrescue
> sysutils/testdisk
> sysutils/e2fsprogs (for the "badblocks" program)
> net/rsync (probably obvious, but still worth mentioning)
>
> Modern drives keep "spare sectors" in which to remap failing ones
> like this, but they usually only do so when *writing* to the
> sector, not when *reading* it.
>
> You could try backing up the drive, then writing zeros to the
> entire drive with dd(1) to try to see if it helps.  You could also
> try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
>
> -n    Use non-destructive read-write mode.  By default only a non-
>               destructive read-only test is done.  This option must not be
>               combined with the -w option, as they are mutually exclusive.
>
> "badblocks -n" will read all sectors on the drive and write back
> the same data to the sector.  If it's "weak", and the program can
> manage to read the sector, the drive may then remap that sector to
> a spare.
>
> But!  How much do you really trust a drive that has started to
> fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> drive contains the only copy of family photos of your dearly
> departed grandmother, are you willing to risk it?
>
> sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
> sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
>
> I see a 3TB Western Digital My Book on a very popular online
> retailer for only $89.99 USD with free shipping as I type this.
>
> Is the data on that drive worth more than that?  Is the amount of
> time you'd spend trying to squeeze a little more life out of the
> drive worth it?  How much do you value your free time?  If you
> enjoy tinkering with things like this and don't have valuable data
> on it, it may be worth trying.  If you'd rather spend that time
> outside hiking or seeing friends and family, then it may be more
> economical to just buy a new one.  
>
> Ultimately, only you can decide.
>
> > I can't resume syncing the blockchain though because the error appears
> > again.
> >
>
> While I'm here, I poked around bitcoin's manpage and found this:
>
>  -prune=<n>
>
>               Reduce storage requirements by enabling pruning (deleting) of
>               old blocks. This allows the pruneblockchain RPC to be called to
>               delete specific blocks, and enables automatic pruning of old
>               blocks if a target size in MiB is provided. This mode is
>               incompatible with -txindex and -rescan. Warning: Reverting this
>               setting requires re-downloading the entire blockchain. (default:
>               0 = disable pruning blocks, 1 = allow manual pruning via RPC,
>               >550 = automatically prune block files to stay under the
>               specified target size in MiB)
>
> I have no idea if this only works *after* downloading the entire
> blockchain or not, but it might be worth trying this option and
> seeing if it will obviate the need for downloading 200+ GB of
> data.
>
> Rafael:
> If setting this option works out-of-the-box, it might be worth
> making a note of it.  Reading back through the thread, I see some
> people saying that they couldn't test or use the port because they
> don't have 200 GB of space for it.
>
> If it works, it might be worth adding a note to MESSAGE or a
> README since this is probably going to be a common issue for most
> people.
>
> > Not sure if this is a deficiency of the port or maybe the hard drive
> > itself...
> >
>
> As said above, it's almost certainly the drive.  Please be sure to
> back up anything important as soon as you can.
>
> --
> Bryan
>
Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
Bryan, your problem is a storage issue not an bitcoin(d).

Please find attached a new tarball with following changes/improvements:

- Update from bitcoin-0.16.0 to bitcoin-0.16.1
- Replace MESSAGE by README:
-- RPC user and password
-- Storage requirements

Still waiting for a final okay

bitcoin-0.16.1.tar.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:

> On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> > On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]> wrote:
> > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email] wrote:
> > > > I think the blockchain size is a deterrent. I can test it when I'm back from traveling in ~ 10 days and have access to additional GB on my external drive, in case that helps.
> > > >
> > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <[hidden email]> wrote:
> > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > > >
> > > > >It's not evil! It's NOT mining. ;)
> > >
> > > I installed it and tried to sync the 200GB blockchain to my external HDD
> > > (because that's the only one that got this much space available). It
> > > synced fine for 1-2 days with the bitcoin-qt client, but then at about
> > > 30-40% of the blockchain synced, it now starts throwing an error:
> > >
> > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, nPos=6513581)
> > >
> > > When this happens, the following lines appear in dmesg:
> > >
> > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > > SENSE KEY: Media Error
> > > ASC/ASCQ: Unrecovered Read Error
> > >
> > > Fortunately, the drive still seems to be functional otherwise, can be
> > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > > whenever mounting or unmounting said drive until I disconnect and
> > > reconnect the drive from the USB port.
> > >
> >
> > This is almost certainly a problem with the drive.  I've had
> > several hard drives fail over the ~13 years or so I've been using
> > OpenBSD, and this is exactly the kind of error I see when the
> > drive is wearing out.
> >
> > The message means that the kernel could not read a sector on the
> > drive despite trying to do so.  I've had drives continue to
> > otherwise work for years after throwing errors like that (though I
> > made sure to back them up and only used them as "scratch" drives).
> > Another time I had a drive fail within weeks of throwing an error
> > like that.
> >
> > If it's still under warranty, I'd recommend sending it in for
> > replacement.  If it's not, I'd *highly* recommend backing up
> > anything on there to another drive.
> >
> > Sometimes, sectors can be "weak" and if you give the drive enough
> > time it will be able to read it, so if it can't be backed up
> > entirely, back up as much as you can, then let the drive sit for a
> > few days and try again.
> >
> > Some ports that may help:
> > sysutils/ddrescue
> > sysutils/testdisk
> > sysutils/e2fsprogs (for the "badblocks" program)
> > net/rsync (probably obvious, but still worth mentioning)
> >
> > Modern drives keep "spare sectors" in which to remap failing ones
> > like this, but they usually only do so when *writing* to the
> > sector, not when *reading* it.
> >
> > You could try backing up the drive, then writing zeros to the
> > entire drive with dd(1) to try to see if it helps.  You could also
> > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> >
> > -n    Use non-destructive read-write mode.  By default only a non-
> >               destructive read-only test is done.  This option must not be
> >               combined with the -w option, as they are mutually exclusive.
> >
> > "badblocks -n" will read all sectors on the drive and write back
> > the same data to the sector.  If it's "weak", and the program can
> > manage to read the sector, the drive may then remap that sector to
> > a spare.
> >
> > But!  How much do you really trust a drive that has started to
> > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> > drive contains the only copy of family photos of your dearly
> > departed grandmother, are you willing to risk it?
> >
> > sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4 0/direct fixed
> > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> >
> > I see a 3TB Western Digital My Book on a very popular online
> > retailer for only $89.99 USD with free shipping as I type this.
> >
> > Is the data on that drive worth more than that?  Is the amount of
> > time you'd spend trying to squeeze a little more life out of the
> > drive worth it?  How much do you value your free time?  If you
> > enjoy tinkering with things like this and don't have valuable data
> > on it, it may be worth trying.  If you'd rather spend that time
> > outside hiking or seeing friends and family, then it may be more
> > economical to just buy a new one.  
> >
> > Ultimately, only you can decide.
> >
> > > I can't resume syncing the blockchain though because the error appears
> > > again.
> > >
> >
> > While I'm here, I poked around bitcoin's manpage and found this:
> >
> >  -prune=<n>
> >
> >               Reduce storage requirements by enabling pruning (deleting) of
> >               old blocks. This allows the pruneblockchain RPC to be called to
> >               delete specific blocks, and enables automatic pruning of old
> >               blocks if a target size in MiB is provided. This mode is
> >               incompatible with -txindex and -rescan. Warning: Reverting this
> >               setting requires re-downloading the entire blockchain. (default:
> >               0 = disable pruning blocks, 1 = allow manual pruning via RPC,
> >               >550 = automatically prune block files to stay under the
> >               specified target size in MiB)
> >
> > I have no idea if this only works *after* downloading the entire
> > blockchain or not, but it might be worth trying this option and
> > seeing if it will obviate the need for downloading 200+ GB of
> > data.
> >
> > Rafael:
> > If setting this option works out-of-the-box, it might be worth
> > making a note of it.  Reading back through the thread, I see some
> > people saying that they couldn't test or use the port because they
> > don't have 200 GB of space for it.
> >
> > If it works, it might be worth adding a note to MESSAGE or a
> > README since this is probably going to be a common issue for most
> > people.
> >
> > > Not sure if this is a deficiency of the port or maybe the hard drive
> > > itself...
> > >
> >
> > As said above, it's almost certainly the drive.  Please be sure to
> > back up anything important as soon as you can.
> >
> > --
> > Bryan
> >
>
> Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
> Bryan, your problem is a storage issue not an bitcoin(d).
>
> Please find attached a new tarball with following changes/improvements:
>
> - Update from bitcoin-0.16.0 to bitcoin-0.16.1
> - Replace MESSAGE by README:
> -- RPC user and password
> -- Storage requirements
>
> Still waiting for a final okay

For all fast cowboys, there is a quoting issue reported by David Hill.
Please change MAKE_FLAGS to:

MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}" CXXFLAGS="${CXXFLAGS}"

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Fabian Raetz
Hi

i've been running a bitcoin node for the last two weeks and everything
seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
used it in combination with lnd [0] (in testnet)

Please find the attached diff with two small improvements to the rc file:
- add daemon_timeout=300. The daemon need time to shutdown successfully
(syncing to disk). 300 sec. was choosen randomly but this value worked for
me in several restarts.
- remove pid_file. It works even without specifying it.

With this, the port looks ok to me :)

Cheer,
Fabian

[0] https://github.com/lightningnetwork/lnd

Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
[hidden email]>:

> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> > > On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]>
> wrote:
> > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email]
> wrote:
> > > > > I think the blockchain size is a deterrent. I can test it when I'm
> back from traveling in ~ 10 days and have access to additional GB on my
> external drive, in case that helps.
> > > > >
> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
> [hidden email]> wrote:
> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > > > >
> > > > > >It's not evil! It's NOT mining. ;)
> > > >
> > > > I installed it and tried to sync the 200GB blockchain to my external
> HDD
> > > > (because that's the only one that got this much space available). It
> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
> about
> > > > 30-40% of the blockchain synced, it now starts throwing an error:
> > > >
> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
> CAutoFile::read:fread failed: unspecified iostream_category error at
> CBlockDiskPos(nFile=613, nPos=6513581)
> > > >
> > > > When this happens, the following lines appear in dmesg:
> > > >
> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > > >   SENSE KEY: Media Error
> > > >   ASC/ASCQ: Unrecovered Read Error
> > > >
> > > > Fortunately, the drive still seems to be functional otherwise, can be
> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > > > whenever mounting or unmounting said drive until I disconnect and
> > > > reconnect the drive from the USB port.
> > > >
> > >
> > > This is almost certainly a problem with the drive.  I've had
> > > several hard drives fail over the ~13 years or so I've been using
> > > OpenBSD, and this is exactly the kind of error I see when the
> > > drive is wearing out.
> > >
> > > The message means that the kernel could not read a sector on the
> > > drive despite trying to do so.  I've had drives continue to
> > > otherwise work for years after throwing errors like that (though I
> > > made sure to back them up and only used them as "scratch" drives).
> > > Another time I had a drive fail within weeks of throwing an error
> > > like that.
> > >
> > > If it's still under warranty, I'd recommend sending it in for
> > > replacement.  If it's not, I'd *highly* recommend backing up
> > > anything on there to another drive.
> > >
> > > Sometimes, sectors can be "weak" and if you give the drive enough
> > > time it will be able to read it, so if it can't be backed up
> > > entirely, back up as much as you can, then let the drive sit for a
> > > few days and try again.
> > >
> > > Some ports that may help:
> > >     sysutils/ddrescue
> > >     sysutils/testdisk
> > >     sysutils/e2fsprogs (for the "badblocks" program)
> > >     net/rsync (probably obvious, but still worth mentioning)
> > >
> > > Modern drives keep "spare sectors" in which to remap failing ones
> > > like this, but they usually only do so when *writing* to the
> > > sector, not when *reading* it.
> > >
> > > You could try backing up the drive, then writing zeros to the
> > > entire drive with dd(1) to try to see if it helps.  You could also
> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> > >
> > >     -n    Use non-destructive read-write mode.  By default only a non-
> > >               destructive read-only test is done.  This option must
> not be
> > >               combined with the -w option, as they are mutually
> exclusive.
> > >
> > > "badblocks -n" will read all sectors on the drive and write back
> > > the same data to the sector.  If it's "weak", and the program can
> > > manage to read the sector, the drive may then remap that sector to
> > > a spare.
> > >
> > > But!  How much do you really trust a drive that has started to
> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> > > drive contains the only copy of family photos of your dearly
> > > departed grandmother, are you willing to risk it?
> > >
> > >     sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4
> 0/direct fixed
> > >     sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> > >
> > > I see a 3TB Western Digital My Book on a very popular online
> > > retailer for only $89.99 USD with free shipping as I type this.
> > >
> > > Is the data on that drive worth more than that?  Is the amount of
> > > time you'd spend trying to squeeze a little more life out of the
> > > drive worth it?  How much do you value your free time?  If you
> > > enjoy tinkering with things like this and don't have valuable data
> > > on it, it may be worth trying.  If you'd rather spend that time
> > > outside hiking or seeing friends and family, then it may be more
> > > economical to just buy a new one.
> > >
> > > Ultimately, only you can decide.
> > >
> > > > I can't resume syncing the blockchain though because the error
> appears
> > > > again.
> > > >
> > >
> > > While I'm here, I poked around bitcoin's manpage and found this:
> > >
> > >  -prune=<n>
> > >
> > >               Reduce storage requirements by enabling pruning
> (deleting) of
> > >               old blocks. This allows the pruneblockchain RPC to be
> called to
> > >               delete specific blocks, and enables automatic pruning of
> old
> > >               blocks if a target size in MiB is provided. This mode is
> > >               incompatible with -txindex and -rescan. Warning:
> Reverting this
> > >               setting requires re-downloading the entire blockchain.
> (default:
> > >               0 = disable pruning blocks, 1 = allow manual pruning via
> RPC,
> > >               >550 = automatically prune block files to stay under the
> > >               specified target size in MiB)
> > >
> > > I have no idea if this only works *after* downloading the entire
> > > blockchain or not, but it might be worth trying this option and
> > > seeing if it will obviate the need for downloading 200+ GB of
> > > data.
> > >
> > > Rafael:
> > > If setting this option works out-of-the-box, it might be worth
> > > making a note of it.  Reading back through the thread, I see some
> > > people saying that they couldn't test or use the port because they
> > > don't have 200 GB of space for it.
> > >
> > > If it works, it might be worth adding a note to MESSAGE or a
> > > README since this is probably going to be a common issue for most
> > > people.
> > >
> > > > Not sure if this is a deficiency of the port or maybe the hard drive
> > > > itself...
> > > >
> > >
> > > As said above, it's almost certainly the drive.  Please be sure to
> > > back up anything important as soon as you can.
> > >
> > > --
> > > Bryan
> > >
> >
> > Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
> > Bryan, your problem is a storage issue not an bitcoin(d).
> >
> > Please find attached a new tarball with following changes/improvements:
> >
> > - Update from bitcoin-0.16.0 to bitcoin-0.16.1
> > - Replace MESSAGE by README:
> > -- RPC user and password
> > -- Storage requirements
> >
> > Still waiting for a final okay
>
> For all fast cowboys, there is a quoting issue reported by David Hill.
> Please change MAKE_FLAGS to:
>
> MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}"
> CXXFLAGS="${CXXFLAGS}"
>
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Fabian Raetz
add here's the missing diff xD

Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
[hidden email]>:

> Hi
>
> i've been running a bitcoin node for the last two weeks and everything
> seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
> used it in combination with lnd [0] (in testnet)
>
> Please find the attached diff with two small improvements to the rc file:
> - add daemon_timeout=300. The daemon need time to shutdown successfully
> (syncing to disk). 300 sec. was choosen randomly but this value worked for
> me in several restarts.
> - remove pid_file. It works even without specifying it.
>
> With this, the port looks ok to me :)
>
> Cheer,
> Fabian
>
> [0] https://github.com/lightningnetwork/lnd
>
> Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
> [hidden email]>:
>
>> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
>> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
>> > > On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]>
>> wrote:
>> > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email]
>> wrote:
>> > > > > I think the blockchain size is a deterrent. I can test it when
>> I'm back from traveling in ~ 10 days and have access to additional GB on my
>> external drive, in case that helps.
>> > > > >
>> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
>> [hidden email]> wrote:
>> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>> > > > > >
>> > > > > >It's not evil! It's NOT mining. ;)
>> > > >
>> > > > I installed it and tried to sync the 200GB blockchain to my
>> external HDD
>> > > > (because that's the only one that got this much space available). It
>> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
>> about
>> > > > 30-40% of the blockchain synced, it now starts throwing an error:
>> > > >
>> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
>> CAutoFile::read:fread failed: unspecified iostream_category error at
>> CBlockDiskPos(nFile=613, nPos=6513581)
>> > > >
>> > > > When this happens, the following lines appear in dmesg:
>> > > >
>> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>> > > >   SENSE KEY: Media Error
>> > > >   ASC/ASCQ: Unrecovered Read Error
>> > > >
>> > > > Fortunately, the drive still seems to be functional otherwise, can
>> be
>> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
>> > > > whenever mounting or unmounting said drive until I disconnect and
>> > > > reconnect the drive from the USB port.
>> > > >
>> > >
>> > > This is almost certainly a problem with the drive.  I've had
>> > > several hard drives fail over the ~13 years or so I've been using
>> > > OpenBSD, and this is exactly the kind of error I see when the
>> > > drive is wearing out.
>> > >
>> > > The message means that the kernel could not read a sector on the
>> > > drive despite trying to do so.  I've had drives continue to
>> > > otherwise work for years after throwing errors like that (though I
>> > > made sure to back them up and only used them as "scratch" drives).
>> > > Another time I had a drive fail within weeks of throwing an error
>> > > like that.
>> > >
>> > > If it's still under warranty, I'd recommend sending it in for
>> > > replacement.  If it's not, I'd *highly* recommend backing up
>> > > anything on there to another drive.
>> > >
>> > > Sometimes, sectors can be "weak" and if you give the drive enough
>> > > time it will be able to read it, so if it can't be backed up
>> > > entirely, back up as much as you can, then let the drive sit for a
>> > > few days and try again.
>> > >
>> > > Some ports that may help:
>> > >     sysutils/ddrescue
>> > >     sysutils/testdisk
>> > >     sysutils/e2fsprogs (for the "badblocks" program)
>> > >     net/rsync (probably obvious, but still worth mentioning)
>> > >
>> > > Modern drives keep "spare sectors" in which to remap failing ones
>> > > like this, but they usually only do so when *writing* to the
>> > > sector, not when *reading* it.
>> > >
>> > > You could try backing up the drive, then writing zeros to the
>> > > entire drive with dd(1) to try to see if it helps.  You could also
>> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
>> > >
>> > >     -n    Use non-destructive read-write mode.  By default only a non-
>> > >               destructive read-only test is done.  This option must
>> not be
>> > >               combined with the -w option, as they are mutually
>> exclusive.
>> > >
>> > > "badblocks -n" will read all sectors on the drive and write back
>> > > the same data to the sector.  If it's "weak", and the program can
>> > > manage to read the sector, the drive may then remap that sector to
>> > > a spare.
>> > >
>> > > But!  How much do you really trust a drive that has started to
>> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
>> > > drive contains the only copy of family photos of your dearly
>> > > departed grandmother, are you willing to risk it?
>> > >
>> > >     sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4
>> 0/direct fixed
>> > >     sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
>> > >
>> > > I see a 3TB Western Digital My Book on a very popular online
>> > > retailer for only $89.99 USD with free shipping as I type this.
>> > >
>> > > Is the data on that drive worth more than that?  Is the amount of
>> > > time you'd spend trying to squeeze a little more life out of the
>> > > drive worth it?  How much do you value your free time?  If you
>> > > enjoy tinkering with things like this and don't have valuable data
>> > > on it, it may be worth trying.  If you'd rather spend that time
>> > > outside hiking or seeing friends and family, then it may be more
>> > > economical to just buy a new one.
>> > >
>> > > Ultimately, only you can decide.
>> > >
>> > > > I can't resume syncing the blockchain though because the error
>> appears
>> > > > again.
>> > > >
>> > >
>> > > While I'm here, I poked around bitcoin's manpage and found this:
>> > >
>> > >  -prune=<n>
>> > >
>> > >               Reduce storage requirements by enabling pruning
>> (deleting) of
>> > >               old blocks. This allows the pruneblockchain RPC to be
>> called to
>> > >               delete specific blocks, and enables automatic pruning
>> of old
>> > >               blocks if a target size in MiB is provided. This mode is
>> > >               incompatible with -txindex and -rescan. Warning:
>> Reverting this
>> > >               setting requires re-downloading the entire blockchain.
>> (default:
>> > >               0 = disable pruning blocks, 1 = allow manual pruning
>> via RPC,
>> > >               >550 = automatically prune block files to stay under the
>> > >               specified target size in MiB)
>> > >
>> > > I have no idea if this only works *after* downloading the entire
>> > > blockchain or not, but it might be worth trying this option and
>> > > seeing if it will obviate the need for downloading 200+ GB of
>> > > data.
>> > >
>> > > Rafael:
>> > > If setting this option works out-of-the-box, it might be worth
>> > > making a note of it.  Reading back through the thread, I see some
>> > > people saying that they couldn't test or use the port because they
>> > > don't have 200 GB of space for it.
>> > >
>> > > If it works, it might be worth adding a note to MESSAGE or a
>> > > README since this is probably going to be a common issue for most
>> > > people.
>> > >
>> > > > Not sure if this is a deficiency of the port or maybe the hard drive
>> > > > itself...
>> > > >
>> > >
>> > > As said above, it's almost certainly the drive.  Please be sure to
>> > > back up anything important as soon as you can.
>> > >
>> > > --
>> > > Bryan
>> > >
>> >
>> > Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
>> > Bryan, your problem is a storage issue not an bitcoin(d).
>> >
>> > Please find attached a new tarball with following changes/improvements:
>> >
>> > - Update from bitcoin-0.16.0 to bitcoin-0.16.1
>> > - Replace MESSAGE by README:
>> > -- RPC user and password
>> > -- Storage requirements
>> >
>> > Still waiting for a final okay
>>
>> For all fast cowboys, there is a quoting issue reported by David Hill.
>> Please change MAKE_FLAGS to:
>>
>> MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}"
>> CXXFLAGS="${CXXFLAGS}"
>>
>

bitcoin-16.1.patch (681 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
HI ports@, Hi Fabian Raetz!

Thanks for testing over two weeks and tweaks/feedback. Your rc changes
works fine for me.

@ports: Attached new tarball with rc tweaks from Fabian Raetz.

Could I get an okay (ports-wise) to import?

Thanks, Rafael

On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote:

> add here's the missing diff xD
>
> Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
> [hidden email]>:
>
> > Hi
> >
> > i've been running a bitcoin node for the last two weeks and everything
> > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
> > used it in combination with lnd [0] (in testnet)
> >
> > Please find the attached diff with two small improvements to the rc file:
> > - add daemon_timeout=300. The daemon need time to shutdown successfully
> > (syncing to disk). 300 sec. was choosen randomly but this value worked for
> > me in several restarts.
> > - remove pid_file. It works even without specifying it.
> >
> > With this, the port looks ok to me :)
> >
> > Cheer,
> > Fabian
> >
> > [0] https://github.com/lightningnetwork/lnd
> >
> > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
> > [hidden email]>:
> >
> >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> >> > > On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]>
> >> wrote:
> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email]
> >> wrote:
> >> > > > > I think the blockchain size is a deterrent. I can test it when
> >> I'm back from traveling in ~ 10 days and have access to additional GB on my
> >> external drive, in case that helps.
> >> > > > >
> >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
> >> [hidden email]> wrote:
> >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> >> > > > > >
> >> > > > > >It's not evil! It's NOT mining. ;)
> >> > > >
> >> > > > I installed it and tried to sync the 200GB blockchain to my
> >> external HDD
> >> > > > (because that's the only one that got this much space available). It
> >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
> >> about
> >> > > > 30-40% of the blockchain synced, it now starts throwing an error:
> >> > > >
> >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
> >> CAutoFile::read:fread failed: unspecified iostream_category error at
> >> CBlockDiskPos(nFile=613, nPos=6513581)
> >> > > >
> >> > > > When this happens, the following lines appear in dmesg:
> >> > > >
> >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> >> > > >   SENSE KEY: Media Error
> >> > > >   ASC/ASCQ: Unrecovered Read Error
> >> > > >
> >> > > > Fortunately, the drive still seems to be functional otherwise, can
> >> be
> >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> >> > > > whenever mounting or unmounting said drive until I disconnect and
> >> > > > reconnect the drive from the USB port.
> >> > > >
> >> > >
> >> > > This is almost certainly a problem with the drive.  I've had
> >> > > several hard drives fail over the ~13 years or so I've been using
> >> > > OpenBSD, and this is exactly the kind of error I see when the
> >> > > drive is wearing out.
> >> > >
> >> > > The message means that the kernel could not read a sector on the
> >> > > drive despite trying to do so.  I've had drives continue to
> >> > > otherwise work for years after throwing errors like that (though I
> >> > > made sure to back them up and only used them as "scratch" drives).
> >> > > Another time I had a drive fail within weeks of throwing an error
> >> > > like that.
> >> > >
> >> > > If it's still under warranty, I'd recommend sending it in for
> >> > > replacement.  If it's not, I'd *highly* recommend backing up
> >> > > anything on there to another drive.
> >> > >
> >> > > Sometimes, sectors can be "weak" and if you give the drive enough
> >> > > time it will be able to read it, so if it can't be backed up
> >> > > entirely, back up as much as you can, then let the drive sit for a
> >> > > few days and try again.
> >> > >
> >> > > Some ports that may help:
> >> > >     sysutils/ddrescue
> >> > >     sysutils/testdisk
> >> > >     sysutils/e2fsprogs (for the "badblocks" program)
> >> > >     net/rsync (probably obvious, but still worth mentioning)
> >> > >
> >> > > Modern drives keep "spare sectors" in which to remap failing ones
> >> > > like this, but they usually only do so when *writing* to the
> >> > > sector, not when *reading* it.
> >> > >
> >> > > You could try backing up the drive, then writing zeros to the
> >> > > entire drive with dd(1) to try to see if it helps.  You could also
> >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> >> > >
> >> > >     -n    Use non-destructive read-write mode.  By default only a non-
> >> > >               destructive read-only test is done.  This option must
> >> not be
> >> > >               combined with the -w option, as they are mutually
> >> exclusive.
> >> > >
> >> > > "badblocks -n" will read all sectors on the drive and write back
> >> > > the same data to the sector.  If it's "weak", and the program can
> >> > > manage to read the sector, the drive may then remap that sector to
> >> > > a spare.
> >> > >
> >> > > But!  How much do you really trust a drive that has started to
> >> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> >> > > drive contains the only copy of family photos of your dearly
> >> > > departed grandmother, are you willing to risk it?
> >> > >
> >> > >     sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4
> >> 0/direct fixed
> >> > >     sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> >> > >
> >> > > I see a 3TB Western Digital My Book on a very popular online
> >> > > retailer for only $89.99 USD with free shipping as I type this.
> >> > >
> >> > > Is the data on that drive worth more than that?  Is the amount of
> >> > > time you'd spend trying to squeeze a little more life out of the
> >> > > drive worth it?  How much do you value your free time?  If you
> >> > > enjoy tinkering with things like this and don't have valuable data
> >> > > on it, it may be worth trying.  If you'd rather spend that time
> >> > > outside hiking or seeing friends and family, then it may be more
> >> > > economical to just buy a new one.
> >> > >
> >> > > Ultimately, only you can decide.
> >> > >
> >> > > > I can't resume syncing the blockchain though because the error
> >> appears
> >> > > > again.
> >> > > >
> >> > >
> >> > > While I'm here, I poked around bitcoin's manpage and found this:
> >> > >
> >> > >  -prune=<n>
> >> > >
> >> > >               Reduce storage requirements by enabling pruning
> >> (deleting) of
> >> > >               old blocks. This allows the pruneblockchain RPC to be
> >> called to
> >> > >               delete specific blocks, and enables automatic pruning
> >> of old
> >> > >               blocks if a target size in MiB is provided. This mode is
> >> > >               incompatible with -txindex and -rescan. Warning:
> >> Reverting this
> >> > >               setting requires re-downloading the entire blockchain.
> >> (default:
> >> > >               0 = disable pruning blocks, 1 = allow manual pruning
> >> via RPC,
> >> > >               >550 = automatically prune block files to stay under the
> >> > >               specified target size in MiB)
> >> > >
> >> > > I have no idea if this only works *after* downloading the entire
> >> > > blockchain or not, but it might be worth trying this option and
> >> > > seeing if it will obviate the need for downloading 200+ GB of
> >> > > data.
> >> > >
> >> > > Rafael:
> >> > > If setting this option works out-of-the-box, it might be worth
> >> > > making a note of it.  Reading back through the thread, I see some
> >> > > people saying that they couldn't test or use the port because they
> >> > > don't have 200 GB of space for it.
> >> > >
> >> > > If it works, it might be worth adding a note to MESSAGE or a
> >> > > README since this is probably going to be a common issue for most
> >> > > people.
> >> > >
> >> > > > Not sure if this is a deficiency of the port or maybe the hard drive
> >> > > > itself...
> >> > > >
> >> > >
> >> > > As said above, it's almost certainly the drive.  Please be sure to
> >> > > back up anything important as soon as you can.
> >> > >
> >> > > --
> >> > > Bryan
> >> > >
> >> >
> >> > Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
> >> > Bryan, your problem is a storage issue not an bitcoin(d).
> >> >
> >> > Please find attached a new tarball with following changes/improvements:
> >> >
> >> > - Update from bitcoin-0.16.0 to bitcoin-0.16.1
> >> > - Replace MESSAGE by README:
> >> > -- RPC user and password
> >> > -- Storage requirements
> >> >
> >> > Still waiting for a final okay
> >>
> >> For all fast cowboys, there is a quoting issue reported by David Hill.
> >> Please change MAKE_FLAGS to:
> >>
> >> MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}"
> >> CXXFLAGS="${CXXFLAGS}"
> >>
> >


bitcoin-0.16.1p0.tar.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Kirill Bychkov
On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> HI ports@, Hi Fabian Raetz!
>
> Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> works fine for me.
>
> @ports: Attached new tarball with rc tweaks from Fabian Raetz.
>
> Could I get an okay (ports-wise) to import?

Hi! Not an OK yet, sorry.
I guess better comment is needed to explain why this could be
built with clang only.
And since almost all @tag bits are in, it would be nice to use it
in new ports instead of @exec.

>
> Thanks, Rafael
>
> On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote:
>> add here's the missing diff xD
>>
>> Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
>> [hidden email]>:
>>
>> > Hi
>> >
>> > i've been running a bitcoin node for the last two weeks and everything
>> > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
>> > used it in combination with lnd [0] (in testnet)
>> >
>> > Please find the attached diff with two small improvements to the rc file:
>> > - add daemon_timeout=300. The daemon need time to shutdown successfully
>> > (syncing to disk). 300 sec. was choosen randomly but this value worked for
>> > me in several restarts.
>> > - remove pid_file. It works even without specifying it.
>> >
>> > With this, the port looks ok to me :)
>> >
>> > Cheer,
>> > Fabian
>> >
>> > [0] https://github.com/lightningnetwork/lnd
>> >
>> > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
>> > [hidden email]>:
>> >
>> >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
>> >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
>> >> > > On 2018-06-23 09:07:38, Thomas Frohwein <[hidden email]>
>> >> wrote:
>> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +0000, [hidden email]
>> >> wrote:
>> >> > > > > I think the blockchain size is a deterrent. I can test it when
>> >> I'm back from traveling in ~ 10 days and have access to additional GB on
>> my
>> >> external drive, in case that helps.
>> >> > > > >
>> >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
>> >> [hidden email]> wrote:
>> >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>> >> > > > > >
>> >> > > > > >It's not evil! It's NOT mining. ;)
>> >> > > >
>> >> > > > I installed it and tried to sync the 200GB blockchain to my
>> >> external HDD
>> >> > > > (because that's the only one that got this much space available).
>> It
>> >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
>> >> about
>> >> > > > 30-40% of the blockchain synced, it now starts throwing an error:
>> >> > > >
>> >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
>> >> CAutoFile::read:fread failed: unspecified iostream_category error at
>> >> CBlockDiskPos(nFile=613, nPos=6513581)
>> >> > > >
>> >> > > > When this happens, the following lines appear in dmesg:
>> >> > > >
>> >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>> >> > > >   SENSE KEY: Media Error
>> >> > > >   ASC/ASCQ: Unrecovered Read Error
>> >> > > >
>> >> > > > Fortunately, the drive still seems to be functional otherwise, can
>> >> be
>> >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines
>> reappear
>> >> > > > whenever mounting or unmounting said drive until I disconnect and
>> >> > > > reconnect the drive from the USB port.
>> >> > > >
>> >> > >
>> >> > > This is almost certainly a problem with the drive.  I've had
>> >> > > several hard drives fail over the ~13 years or so I've been using
>> >> > > OpenBSD, and this is exactly the kind of error I see when the
>> >> > > drive is wearing out.
>> >> > >
>> >> > > The message means that the kernel could not read a sector on the
>> >> > > drive despite trying to do so.  I've had drives continue to
>> >> > > otherwise work for years after throwing errors like that (though I
>> >> > > made sure to back them up and only used them as "scratch" drives).
>> >> > > Another time I had a drive fail within weeks of throwing an error
>> >> > > like that.
>> >> > >
>> >> > > If it's still under warranty, I'd recommend sending it in for
>> >> > > replacement.  If it's not, I'd *highly* recommend backing up
>> >> > > anything on there to another drive.
>> >> > >
>> >> > > Sometimes, sectors can be "weak" and if you give the drive enough
>> >> > > time it will be able to read it, so if it can't be backed up
>> >> > > entirely, back up as much as you can, then let the drive sit for a
>> >> > > few days and try again.
>> >> > >
>> >> > > Some ports that may help:
>> >> > >     sysutils/ddrescue
>> >> > >     sysutils/testdisk
>> >> > >     sysutils/e2fsprogs (for the "badblocks" program)
>> >> > >     net/rsync (probably obvious, but still worth mentioning)
>> >> > >
>> >> > > Modern drives keep "spare sectors" in which to remap failing ones
>> >> > > like this, but they usually only do so when *writing* to the
>> >> > > sector, not when *reading* it.
>> >> > >
>> >> > > You could try backing up the drive, then writing zeros to the
>> >> > > entire drive with dd(1) to try to see if it helps.  You could also
>> >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
>> >> > >
>> >> > >     -n    Use non-destructive read-write mode.  By default only a
>> non-
>> >> > >               destructive read-only test is done.  This option must
>> >> not be
>> >> > >               combined with the -w option, as they are mutually
>> >> exclusive.
>> >> > >
>> >> > > "badblocks -n" will read all sectors on the drive and write back
>> >> > > the same data to the sector.  If it's "weak", and the program can
>> >> > > manage to read the sector, the drive may then remap that sector to
>> >> > > a spare.
>> >> > >
>> >> > > But!  How much do you really trust a drive that has started to
>> >> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
>> >> > > drive contains the only copy of family photos of your dearly
>> >> > > departed grandmother, are you willing to risk it?
>> >> > >
>> >> > >     sd4 at scsibus4 targ 1 lun 0: <WD, My Book 1230, 1065> SCSI4
>> >> 0/direct fixed
>> >> > >     sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
>> >> > >
>> >> > > I see a 3TB Western Digital My Book on a very popular online
>> >> > > retailer for only $89.99 USD with free shipping as I type this.
>> >> > >
>> >> > > Is the data on that drive worth more than that?  Is the amount of
>> >> > > time you'd spend trying to squeeze a little more life out of the
>> >> > > drive worth it?  How much do you value your free time?  If you
>> >> > > enjoy tinkering with things like this and don't have valuable data
>> >> > > on it, it may be worth trying.  If you'd rather spend that time
>> >> > > outside hiking or seeing friends and family, then it may be more
>> >> > > economical to just buy a new one.
>> >> > >
>> >> > > Ultimately, only you can decide.
>> >> > >
>> >> > > > I can't resume syncing the blockchain though because the error
>> >> appears
>> >> > > > again.
>> >> > > >
>> >> > >
>> >> > > While I'm here, I poked around bitcoin's manpage and found this:
>> >> > >
>> >> > >  -prune=<n>
>> >> > >
>> >> > >               Reduce storage requirements by enabling pruning
>> >> (deleting) of
>> >> > >               old blocks. This allows the pruneblockchain RPC to be
>> >> called to
>> >> > >               delete specific blocks, and enables automatic pruning
>> >> of old
>> >> > >               blocks if a target size in MiB is provided. This mode
>> is
>> >> > >               incompatible with -txindex and -rescan. Warning:
>> >> Reverting this
>> >> > >               setting requires re-downloading the entire blockchain.
>> >> (default:
>> >> > >               0 = disable pruning blocks, 1 = allow manual pruning
>> >> via RPC,
>> >> > >               >550 = automatically prune block files to stay under
>> the
>> >> > >               specified target size in MiB)
>> >> > >
>> >> > > I have no idea if this only works *after* downloading the entire
>> >> > > blockchain or not, but it might be worth trying this option and
>> >> > > seeing if it will obviate the need for downloading 200+ GB of
>> >> > > data.
>> >> > >
>> >> > > Rafael:
>> >> > > If setting this option works out-of-the-box, it might be worth
>> >> > > making a note of it.  Reading back through the thread, I see some
>> >> > > people saying that they couldn't test or use the port because they
>> >> > > don't have 200 GB of space for it.
>> >> > >
>> >> > > If it works, it might be worth adding a note to MESSAGE or a
>> >> > > README since this is probably going to be a common issue for most
>> >> > > people.
>> >> > >
>> >> > > > Not sure if this is a deficiency of the port or maybe the hard
>> drive
>> >> > > > itself...
>> >> > > >
>> >> > >
>> >> > > As said above, it's almost certainly the drive.  Please be sure to
>> >> > > back up anything important as soon as you can.
>> >> > >
>> >> > > --
>> >> > > Bryan
>> >> > >
>> >> >
>> >> > Thanks Bryan Linton for the pruning hint. Thomas, I think, just like
>> >> > Bryan, your problem is a storage issue not an bitcoin(d).
>> >> >
>> >> > Please find attached a new tarball with following changes/improvements:
>> >> >
>> >> > - Update from bitcoin-0.16.0 to bitcoin-0.16.1
>> >> > - Replace MESSAGE by README:
>> >> > -- RPC user and password
>> >> > -- Storage requirements
>> >> >
>> >> > Still waiting for a final okay
>> >>
>> >> For all fast cowboys, there is a quoting issue reported by David Hill.
>> >> Please change MAKE_FLAGS to:
>> >>
>> >> MAKE_FLAGS = CC="${CC}" CXX="${CXX}" CFLAGS="${CFLAGS}"
>> >> CXXFLAGS="${CXXFLAGS}"
>> >>
>> >
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Rafael Sadowski
On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:

> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> > HI ports@, Hi Fabian Raetz!
> >
> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> > works fine for me.
> >
> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
> >
> > Could I get an okay (ports-wise) to import?
>
> Hi! Not an OK yet, sorry.
> I guess better comment is needed to explain why this could be
> built with clang only.
Added "Undefined reference to boost and db4 with GCC" over COMPILER.
Better ideas?

Complete output:

/usr/bin/ar cr leveldb/libmemenv.a leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
/usr/bin/ranlib leveldb/libmemenv.a
/usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread  -Wl,-z,relro -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o  libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib -levent_extra -levent_core -L/usr/local/lib -lzmq
libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium -Wl,-rpath-link,/usr/local/lib                                                                                    
.libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use strlcat()
.libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is that what you want?                                                                                              
.libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, please use strlcpy()                                                                                            
.libs/libzmq.so.4.2: warning: sprintf() is often misused, please use snprintf()
.libs/libevent_core.so.1.1: warning: random() may return deterministic values, is that what you want?                                                                                        
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()':
util.cpp:(.text+0x12ca): undefined reference to `boost::filesystem::path::imbue(std::locale const&)'                                                                                          
util.cpp:(.text+0x12d5): undefined reference to `boost::filesystem::path::imbue(std::locale const&)'                                                                                          
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::string&)':                                          
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98): undefined reference to `boost::program_options::to_internal(std::string const&)'
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `boost::program_options::detail::basic_config_file_iterator<char>::basic_config_file_iterator(std::istream&, std::set<std::string, std::less<std::string>, std::allocator<std::string> > const&, bool)':
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21): undefined reference to `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set<std::string, std::less<std::string>, std::allocator<std::string> > const&, bool)'
libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function `CDBEnv::Verify(std::string const&, bool (*)(std::string const&, std::string&), std::string&)':                                    
db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char const*, std::ostream*, unsigned int)'                                                                            
libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function `CDBEnv::Salvage(std::string const&, bool, std::vector<std::pair<std::vector<unsigned char, std::allocator<unsigned char> >, std::vector<unsigned char, std::allocator<unsigned char> > >, std::allocator<std::pair<std::vector<unsigned char, std::allocator<unsigned char> >, std::vector<unsigned char, std::allocator<unsigned
char> > > > >&)':
db.cpp:(.text+0x6e81): undefined reference to `Db::verify(char const*, char const*, std::ostream*, unsigned int)'                                                                            
collect2: error: ld returned 1 exit status
Error while executing eg++ -o .libs/bitcoind -pthread -Wstack-protector -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium -Wl,-rpath-link,/usr/local/lib                                                                            
gmake[2]: *** [Makefile:3678: bitcoind] Error 2
gmake[2]: Leaving directory '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
gmake[1]: *** [Makefile:9467: all-recursive] Error 1
gmake[1]: Leaving directory '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
gmake: *** [Makefile:735: all-recursive] Error 1
*** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2703 '/usr/ports/pobj/bitcoin-0.16.1/.build_done')                                                                                
*** Error 2 in /usr/ports/net/bitcoin (/usr/ports/infrastructure/mk/bsd.port.mk:2382 'all')

> And since almost all @tag bits are in, it would be nice to use it
> in new ports instead of @exec.

Of course, but it's not worth sending an extra tarball for, is it?
Anyway new tarball attached.

bitcoin-0.16.1p2.tar.gz (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Kirill Bychkov
On Sun, July 8, 2018 20:13, Rafael Sadowski wrote:

> On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
>> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
>> > HI ports@, Hi Fabian Raetz!
>> >
>> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
>> > works fine for me.
>> >
>> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
>> >
>> > Could I get an okay (ports-wise) to import?
>>
>> Hi! Not an OK yet, sorry.
>> I guess better comment is needed to explain why this could be
>> built with clang only.
>
> Added "Undefined reference to boost and db4 with GCC" over COMPILER.
> Better ideas?

OK kirby@
BTW you can use --disable-tests instead of @comments in PLIST

>
> Complete output:
>
> /usr/bin/ar cr leveldb/libmemenv.a
> leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
> /usr/bin/ranlib leveldb/libmemenv.a
> /usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector
> -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread  -Wl,-z,relro
> -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o
> libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la
> libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a
> crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a
> leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib
> -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt
> -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc
> -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib
> -levent_extra -levent_core -L/usr/local/lib -lzmq
> libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector
> -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a
> crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a
> leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto
> -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> -Wl,-rpath-link,/usr/local/lib
> .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use
> strlcat()
> .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is
> that what you want?
> .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused,
> please use strlcpy()
> .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use
> snprintf()
> .libs/libevent_core.so.1.1: warning: random() may return deterministic values,
> is that what you want?
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()':
> util.cpp:(.text+0x12ca): undefined reference to
> `boost::filesystem::path::imbue(std::locale const&)'
> util.cpp:(.text+0x12d5): undefined reference to
> `boost::filesystem::path::imbue(std::locale const&)'
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::string&)':
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
> undefined reference to `boost::program_options::to_internal(std::string
> const&)'
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `boost::program_options::detail::basic_config_file_iterator<char>::basic_config_file_iterator(std::istream&,
> std::set<std::string, std::less<std::string>, std::allocator<std::string> >
> const&, bool)':
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
> undefined reference to
> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set<std::string,
> std::less<std::string>, std::allocator<std::string> > const&, bool)'
> libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> `CDBEnv::Verify(std::string const&, bool (*)(std::string const&,
> std::string&), std::string&)':
> db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char
> const*, std::ostream*, unsigned int)'
> libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> `CDBEnv::Salvage(std::string const&, bool,
> std::vector<std::pair<std::vector<unsigned char, std::allocator<unsigned char>
> >, std::vector<unsigned char, std::allocator<unsigned char> > >,
> std::allocator<std::pair<std::vector<unsigned char, std::allocator<unsigned
> char> >, std::vector<unsigned char, std::allocator<unsigned
> char> > > > >&)':
> db.cpp:(.text+0x6e81): undefined reference to `Db::verify(char const*, char
> const*, std::ostream*, unsigned int)'
> collect2: error: ld returned 1 exit status
> Error while executing eg++ -o .libs/bitcoind -pthread -Wstack-protector
> -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a
> crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a
> leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto
> -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> -Wl,-rpath-link,/usr/local/lib
> gmake[2]: *** [Makefile:3678: bitcoind] Error 2
> gmake[2]: Leaving directory
> '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
> gmake[1]: *** [Makefile:9467: all-recursive] Error 1
> gmake[1]: Leaving directory
> '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
> gmake: *** [Makefile:735: all-recursive] Error 1
> *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2703
> '/usr/ports/pobj/bitcoin-0.16.1/.build_done')
> *** Error 2 in /usr/ports/net/bitcoin
> (/usr/ports/infrastructure/mk/bsd.port.mk:2382 'all')
>
>> And since almost all @tag bits are in, it would be nice to use it
>> in new ports instead of @exec.
>
> Of course, but it's not worth sending an extra tarball for, is it?
> Anyway new tarball attached.
>


Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/bitcoin

Fabian Raetz
Hi,

can we also create a package of the no_x11 flavor?

diff --git a/net/Makefile b/net/Makefile
index 57cfb4eec35..b8781538c32 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -27,6 +27,7 @@
      SUBDIR += bird
      SUBDIR += bird,v6
      SUBDIR += bitcoin
+     SUBDIR += bitcoin,no_x11
      SUBDIR += bitlbee
      SUBDIR += bitlbee,libpurple
      SUBDIR += bitlbee,otr


Cheers,
Fabian

Am So., 8. Juli 2018 um 20:05 Uhr schrieb Kirill Bychkov <
[hidden email]>:

> On Sun, July 8, 2018 20:13, Rafael Sadowski wrote:
> > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
> >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> >> > HI ports@, Hi Fabian Raetz!
> >> >
> >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> >> > works fine for me.
> >> >
> >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
> >> >
> >> > Could I get an okay (ports-wise) to import?
> >>
> >> Hi! Not an OK yet, sorry.
> >> I guess better comment is needed to explain why this could be
> >> built with clang only.
> >
> > Added "Undefined reference to boost and db4 with GCC" over COMPILER.
> > Better ideas?
>
> OK kirby@
> BTW you can use --disable-tests instead of @comments in PLIST
>
> >
> > Complete output:
> >
> > /usr/bin/ar cr leveldb/libmemenv.a
> > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
> > /usr/bin/ranlib leveldb/libmemenv.a
> > /usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector
> > -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread
> -Wl,-z,relro
> > -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind
> bitcoind-bitcoind.o
> > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la
> > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> libbitcoin_consensus.a
> > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> leveldb/libleveldb_sse42.a
> > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib
> > -lboost_system -lboost_filesystem -lboost_program_options-mt
> -lboost_thread-mt
> > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc
> > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core
> -L/usr/local/lib
> > -levent_extra -levent_core -L/usr/local/lib -lzmq
> > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector
> > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> libbitcoin_consensus.a
> > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> leveldb/libleveldb_sse42.a
> > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl
> -lcrypto
> > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> > -Wl,-rpath-link,/usr/local/lib
> > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please
> use
> > strlcat()
> > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values,
> is
> > that what you want?
> > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always
> misused,
> > please use strlcpy()
> > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use
> > snprintf()
> > .libs/libevent_core.so.1.1: warning: random() may return deterministic
> values,
> > is that what you want?
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `SetupEnvironment()':
> > util.cpp:(.text+0x12ca): undefined reference to
> > `boost::filesystem::path::imbue(std::locale const&)'
> > util.cpp:(.text+0x12d5): undefined reference to
> > `boost::filesystem::path::imbue(std::locale const&)'
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> >
> `boost::program_options::detail::basic_config_file_iterator<char>::getline(std::string&)':
> >
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
> > undefined reference to `boost::program_options::to_internal(std::string
> > const&)'
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> >
> `boost::program_options::detail::basic_config_file_iterator<char>::basic_config_file_iterator(std::istream&,
> > std::set<std::string, std::less<std::string>,
> std::allocator<std::string> >
> > const&, bool)':
> >
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
> > undefined reference to
> >
> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set<std::string,
> > std::less<std::string>, std::allocator<std::string> > const&, bool)'
> > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> > `CDBEnv::Verify(std::string const&, bool (*)(std::string const&,
> > std::string&), std::string&)':
> > db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*,
> char
> > const*, std::ostream*, unsigned int)'
> > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> > `CDBEnv::Salvage(std::string const&, bool,
> > std::vector<std::pair<std::vector<unsigned char, std::allocator<unsigned
> char>
> > >, std::vector<unsigned char, std::allocator<unsigned char> > >,
> > std::allocator<std::pair<std::vector<unsigned char,
> std::allocator<unsigned
> > char> >, std::vector<unsigned char, std::allocator<unsigned
> > char> > > > >&)':
> > db.cpp:(.text+0x6e81): undefined reference to `Db::verify(char const*,
> char
> > const*, std::ostream*, unsigned int)'
> > collect2: error: ld returned 1 exit status
> > Error while executing eg++ -o .libs/bitcoind -pthread -Wstack-protector
> > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> libbitcoin_consensus.a
> > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> leveldb/libleveldb_sse42.a
> > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl
> -lcrypto
> > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> > -Wl,-rpath-link,/usr/local/lib
> > gmake[2]: *** [Makefile:3678: bitcoind] Error 2
> > gmake[2]: Leaving directory
> > '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
> > gmake[1]: *** [Makefile:9467: all-recursive] Error 1
> > gmake[1]: Leaving directory
> > '/usr/ports/pobj/bitcoin-0.16.1/bitcoin-0.16.1/src'
> > gmake: *** [Makefile:735: all-recursive] Error 1
> > *** Error 2 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2703
> > '/usr/ports/pobj/bitcoin-0.16.1/.build_done')
> > *** Error 2 in /usr/ports/net/bitcoin
> > (/usr/ports/infrastructure/mk/bsd.port.mk:2382 'all')
> >
> >> And since almost all @tag bits are in, it would be nice to use it
> >> in new ports instead of @exec.
> >
> > Of course, but it's not worth sending an extra tarball for, is it?
> > Anyway new tarball attached.
> >
>
>
>

bitcoin-no_x11.patch (333 bytes) Download Attachment
12