Re: hidden services stopped working
Ok, I'm not sure where how this thread went sideways quite so quickly but just to be clear I'm running as of right now the most current snapshot available on ftp5.usa and the only things I have installed are lynx and tor, I have made sure the system time is correct and turn tor's log doesn't throw any errors at all, and all clearnet address connect just fine, I've tried looking through dameon, messages, and pflog for any errors or misrouted packets respectively, this setup was working just fine and has been for quite a while until a few days ago, I'm not trying to gripe or install anything else I know I'm using snapshots and what that means I'm simply asking for help in other ways I can apprach this problem to try and find the solution since I was definitely call myself a noob or if maybe someone knew of some changes between the snapshot versions that might be related. If I can provide any other information that someone thinks will help I'm more than happy to do so. P.S.- Sorry for the epic run on sentence. >> >> What do you mean by "checking the time"? It just jumps forward for about >> 150s and immediately restores. So it's not so visible. Though it makes >> Tor to break all built circuits. Have a look at your Tor log with >> `notice` debug level. There are probably reports like this: >> >> "Your system clock just jumped 150 seconds forward; assuming established >> circuits no longer work." > > I am really impressed by the analytical skills I observe here. > > I observe: "the system is complex, I can't figure it out, I'll blame > everything, and use more stuff I don't understand". > > Maybe the fortress fell over because you didn't have enough Lego.
Re: hidden services stopped working
> a...@riseup.net: > > Thanks for the reply and the help Ivan but I'm actually already doing > > exactly > > what you suggested. Checking the time is one of the first things I thought > > of > > but this is not that unfortunately. I don't have this problem on 5.9 myself > > and even snapshots were fine up until the update. Your problem is > > interesting though. > > Let me know if you come accross anything new on that, again thanks for you > > time on this. > > What do you mean by "checking the time"? It just jumps forward for about > 150s and immediately restores. So it's not so visible. Though it makes > Tor to break all built circuits. Have a look at your Tor log with > `notice` debug level. There are probably reports like this: > > "Your system clock just jumped 150 seconds forward; assuming established > circuits no longer work." I am really impressed by the analytical skills I observe here. I observe: "the system is complex, I can't figure it out, I'll blame everything, and use more stuff I don't understand". Maybe the fortress fell over because you didn't have enough Lego.
Re: hidden services stopped working
Theo de Raadt: > I am really impressed by the analytical skills I observe here. > > I observe: "the system is complex, I can't figure it out, I'll blame > everything, and use more stuff I don't understand". The problem is definely with ntpd because ntpd reports about invalid-then-valid peers to syslog right before Tor's complaints about timewrap. I don't see anything wrong about proposing a dirty fix that can solve the problem for a while. > Maybe the fortress fell over because you didn't have enough Lego. Maybe. -- Ivan Markin
Re: hidden services stopped working
Thanks for the reply and the help Ivan but I'm actually already doing exactly
what you suggested. Checking the time is one of the first things I thought of
but this is not that unfortunately. I don't have this problem on 5.9 myself
and even snapshots were fine up until the update. Your problem is
interesting though.
Let me know if you come accross anything new on that, again thanks for you
time on this.
>> connections taken from the wiki @ https://trac.torproject.org/projects/
>> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
>> divert-to rules istead of the rdr-to rules everything else is exactly
>> the same. It all worked fine up to the recent update. After a few days
>> and a few snapshot versions I can't seem to troubleshoot what's changed
>> or where it's failing. No errors or blocks in syslog or pflog
>> repectively.
>> Clearnet works fine and is all routed through tor and using tor-resolve
>> on hidden services resolves the address just fine but trying to connect
>> through irc or web browser to hidden services fails after timeout. Any
>> help would be greatly appreciated. Attached a ktrace of lynx trying to
>> connect to the duckduckgo hidden service. Thanks in advance guys!
>> P.S. Triple checked pf rules and entire tor config, system time, and
>> virtual address allocation
>
> I've encountered recently that system time jumps repeatedly thus
> breaking all curcuits and even more time-sensitive Onion Services as
> well. This is a problem that I'm now investigating.
> As you said, you're using snapshot version. But this problem also
> present in 5.9 release branch and started around the same time. Then it
> should not have roots in the recent code.
>
> At the moment the problem narrows down to `ntpd.conf` in the default
> install. According to this [1] commit, `ntpd` is enabled by default and
> uses contraints over TLS from `www.google.com` (do we trust Google
> now??). Same NTP peers work fine on another non-OpenBSD machines so my
> best guess at the moment that time taken from `www.google.com` is wrong
> (or the fetching method). Maybe Google changed their time logic.
>
> Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
> option) and thus get different Google IP each time (Google tries to
> resolve IP addresses that are nearby). Then ntpd takes average of these
> clocks (different IPs) according to the manpage.
>
> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
> [3] to fetch time over TLS. It works fine for me for several days by now.
>
>
> [1]
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12&r2=1.13
> [2] /etc/rc.d/ntpd stop
> rcctl disable ntpd
> [3] https://github.com/ioerror/tlsdate
>
> --
> Ivan Markin
Re: hidden services stopped working
a...@riseup.net: > Thanks for the reply and the help Ivan but I'm actually already doing exactly > what you suggested. Checking the time is one of the first things I thought of > but this is not that unfortunately. I don't have this problem on 5.9 myself > and even snapshots were fine up until the update. Your problem is > interesting though. > Let me know if you come accross anything new on that, again thanks for you > time on this. What do you mean by "checking the time"? It just jumps forward for about 150s and immediately restores. So it's not so visible. Though it makes Tor to break all built circuits. Have a look at your Tor log with `notice` debug level. There are probably reports like this: "Your system clock just jumped 150 seconds forward; assuming established circuits no longer work." -- Ivan Markin
Re: hidden services stopped working
Theo de Raadt: >> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate` >> [3] to fetch time over TLS. It works fine for me for several days by now. > > That is the worst possible advice ever. > > You are far better off letting your machines free-run. Why it's so wrong? ares, using tlsdate to sync time is not required. -- Ivan Markin
Re: hidden services stopped working
Hi ares,
a...@riseup.net:
> After a snapshot update on the 26th for amd64 I have lost the ability to
> connect to hidden services. I have pf rules to transparently proxy all
> connections taken from the wiki @ https://trac.torproject.org/projects/
> tor/wiki/doc/TransparentProxy#BSDPF. With the exception of using
> divert-to rules istead of the rdr-to rules everything else is exactly
> the same. It all worked fine up to the recent update. After a few days
> and a few snapshot versions I can't seem to troubleshoot what's changed
> or where it's failing. No errors or blocks in syslog or pflog repectively.
> Clearnet works fine and is all routed through tor and using tor-resolve
> on hidden services resolves the address just fine but trying to connect
> through irc or web browser to hidden services fails after timeout. Any
> help would be greatly appreciated. Attached a ktrace of lynx trying to
> connect to the duckduckgo hidden service. Thanks in advance guys!
> P.S. Triple checked pf rules and entire tor config, system time, and
> virtual address allocation
I've encountered recently that system time jumps repeatedly thus
breaking all curcuits and even more time-sensitive Onion Services as
well. This is a problem that I'm now investigating.
As you said, you're using snapshot version. But this problem also
present in 5.9 release branch and started around the same time. Then it
should not have roots in the recent code.
At the moment the problem narrows down to `ntpd.conf` in the default
install. According to this [1] commit, `ntpd` is enabled by default and
uses contraints over TLS from `www.google.com` (do we trust Google
now??). Same NTP peers work fine on another non-OpenBSD machines so my
best guess at the moment that time taken from `www.google.com` is wrong
(or the fetching method). Maybe Google changed their time logic.
Another hint is that these OpenBSD machines do DNS over Tor ('DNSPort'
option) and thus get different Google IP each time (Google tries to
resolve IP addresses that are nearby). Then ntpd takes average of these
clocks (different IPs) according to the manpage.
As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate`
[3] to fetch time over TLS. It works fine for me for several days by now.
[1]
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/ntpd.conf.diff?r1=1.12&r2=1.13
[2] /etc/rc.d/ntpd stop
rcctl disable ntpd
[3] https://github.com/ioerror/tlsdate
--
Ivan Markin
Re: hidden services stopped working
> As a quick fix I recommend you to disable `ntpd` [2] and use `tlsdate` > [3] to fetch time over TLS. It works fine for me for several days by now. That is the worst possible advice ever. You are far better off letting your machines free-run.
Re: Flaw in ipsec.conf(5)?
On Fri, May 27, 2016 at 01:21:55PM +0200, Bruno Flueckiger wrote:
> After discussing this with Philipp Buehler off list I have reworked my
> diff to make things easier in the example.
>
> The paragraph which contains set skip on enc0 just before the ruleset
> is removed. All filtering in the rule set is done on sk0, skipping enc0
> entirely.
>
> The new rule set looks like this:
>
> block on sk0
> set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \
> port {500, 4500}
> pass out on sk0 proto udp from 192.168.3.1 to 192.168.3.2 \
> port {500, 4500}
>
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \
> keep state (if-bound)
> pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \
> keep state (if-bound)
>
what then is the point of this section? to tell us to not filter
ipsec traffic?
what really needs to happen is for developers concerned with ipsec to
either recognise a change and adjust the filter rules accordingly, or
to say the idea of filtering enc traffic no longer makes sense and to
remove the section. or to tell you what's in ipsec.conf(5) is correct,
and why.
until that happens, the text will remain, i think.
jmc
>
> Index: sbin/ipsecctl/ipsec.conf.5
> ===
> RCS file: /cvs/src/sbin/ipsecctl/ipsec.conf.5,v
> retrieving revision 1.151
> diff -u -p -r1.151 ipsec.conf.5
> --- sbin/ipsecctl/ipsec.conf.59 Dec 2015 21:41:50 - 1.151
> +++ sbin/ipsecctl/ipsec.conf.527 May 2016 11:07:55 -
> @@ -493,20 +493,12 @@ Match traffic of phase 2 SAs using the
> keyword.
> .El
> .Pp
> -If the filtering rules specify to block everything by default,
> -the following rule
> -would ensure that IPsec traffic never hits the packet filtering engine,
> -and is therefore passed:
> -.Bd -literal -offset indent
> -set skip on enc0
> -.Ed
> -.Pp
> In the following example, all traffic is blocked by default.
> IPsec-related traffic from gateways {192.168.3.1, 192.168.3.2} and
> networks {10.0.1.0/24, 10.0.2.0/24} is permitted.
> .Bd -literal -offset indent
> block on sk0
> -block on enc0
> +set skip on enc0
>
> pass in on sk0 proto udp from 192.168.3.2 to 192.168.3.1 \e
> port {500, 4500}
> @@ -516,13 +508,9 @@ pass out on sk0 proto udp from 192.168.3
> pass in on sk0 proto esp from 192.168.3.2 to 192.168.3.1
> pass out on sk0 proto esp from 192.168.3.1 to 192.168.3.2
>
> -pass in on enc0 proto ipencap from 192.168.3.2 to 192.168.3.1 \e
> - keep state (if-bound)
> -pass out on enc0 proto ipencap from 192.168.3.1 to 192.168.3.2 \e
> - keep state (if-bound)
> -pass in on enc0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> +pass in on sk0 from 10.0.2.0/24 to 10.0.1.0/24 \e
> keep state (if-bound)
> -pass out on enc0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> +pass out on sk0 from 10.0.1.0/24 to 10.0.2.0/24 \e
> keep state (if-bound)
> .Ed
> .Pp
Re: CRYPTO volume created, but appears as full
On Sat, May 28, 2016 at 9:15 AM, Robert Campbell wrote: >... > # bioctl -c C -l sd0a softraid0 > New passphrase: > Re-type passphrase: > sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed > sd3: 114470MB, 512 bytes/sector, 234435953 sectors > softraid0: CRYPTO volume attached as sd3 > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 > uid 0 on /: file system full > > /: write failed, file system is full > dd: /dev/rsd3c: No space left on device > 1+0 records in > 0+0 records out > 0 bytes transferred in 0.007 secs (0 bytes/sec) The FAQ has another command between the bioctl and the dd...to create the device in /dev. /dev/rsd3c didn't exist when you ran the dd, so instead of opening and writing to a device, you created a normal file named "rsd3c" on the ramdisk, thus the error messages about "file system is full". Philip Guenther
Re: hardware recommendation for openbsd-based thin client?
i don't have experience with the compute sticks, but i would start with updating the BIOS. https://downloadcenter.intel.com/download/25917/BIOS-Update-SCCHTAX5-86A- noah pugsley, 26 May 2016 20:59: > bios0: vendor Intel Corp. version "SCCHTAX5.86A.0014.2015.1119.1410" date > 11/19/2015 > bios0: Intel Corporation STK1AW32SC -f -- i have an exceptionally high q.i.
"Cleared:" in pfctl interface statistics
what is the purpose of the Cleared line of the interface statistics? if i read pfctl(8) correctly, only tables can have their statistics cleared/zeroed (the table command is "zero", and not "clear", perhaps because the latter could evoke "removing all elements of the table", although in other parts of the manpage "flush" is used for this kind of operation) # pfctl -vvsI -i re0 re0 Cleared: Thu Jan 1 01:00:01 1970 References: [ States: 0 Rules: 1 ] In4/Pass:[ Packets: 59988900 Bytes: 74459951479] In4/Block: [ Packets: 13991 Bytes: 1645774] Out4/Pass: [ Packets: 39058098 Bytes: 5850353660 ] Out4/Block: [ Packets: 3167 Bytes: 467994 ] In6/Pass:[ Packets: 18 Bytes: 1152 ] In6/Block: [ Packets: 0 Bytes: 0 ] Out6/Pass: [ Packets: 0 Bytes: 0 ] Out6/Block: [ Packets: 0 Bytes: 0 ] # pfctl -F info pf: statistics cleared # pfctl -vvsI -i re0 re0 Cleared: Thu Jan 1 01:00:01 1970 References: [ States: 0 Rules: 1 ] In4/Pass:[ Packets: 60374772 Bytes: 74945788280] In4/Block: [ Packets: 14028 Bytes: 1647622] Out4/Pass: [ Packets: 39392791 Bytes: 6029106115 ] Out4/Block: [ Packets: 3185 Bytes: 468786 ] In6/Pass:[ Packets: 18 Bytes: 1152 ] In6/Block: [ Packets: 0 Bytes: 0 ] Out6/Pass: [ Packets: 0 Bytes: 0 ] Out6/Block: [ Packets: 0 Bytes: 0 ] -f -- he's teflon brain (nothing sticks).
Re: CRYPTO volume created, but appears as full
Stefan Sperling: > On Sat, May 28, 2016 at 06:03:48PM +, Ivan Markin wrote: >> Sebastien Marie: >>> Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the >>> /dev/sd* aren't created by default. >> >> Why it is so? Can this be found somewhere in documentation? > > If the ramdisk shipped with all possible device nodes, the small > ramdisk filesystem would run out of inodes. > > The installer script compensates for this by creating device nodes it > knows will be needed, so normally you don't have to think about this. > Because the install script does not support FDE installs at present, > the /dev/rsd3c device node is not created automatically. > Thanks for the explanation! It would be great if someone can add this note to the FAQ [1]. [1] https://www.openbsd.org/faq/faq14.html#softraidFDE -- Ivan Markin
Re: CRYPTO volume created, but appears as full
Sebastien Marie: > Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the > /dev/sd* aren't created by default. Why it is so? Can this be found somewhere in documentation? -- Ivan Markin
Re: CRYPTO volume created, but appears as full
On Sat, May 28, 2016 at 08:03:47PM +0200, Stefan Sperling wrote: > On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote: > > I followed the steps in the FAQ for setting up full disk encryption. > > Everything goes according to plan until I attempt to write zeros to the > > first megabyte of the new pseudo-device; as you can see below, dd informs > > me that the file system is full, that there is no space left on the device. > > Interestingly, the last line of dmesg is also "uid 0 on /: file system > > full". I've retried this with 5.9 and -current, but the outcome is the > > same. I've also tried rebooting after disklabel and bioctl. I have pasted > > below the relevant sequence, followed by the full dmesg. > > > # bioctl -c C -l sd0a softraid0 > > New passphrase: > > Re-type passphrase: > > sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed > > sd3: 114470MB, 512 bytes/sector, 234435953 sectors > > softraid0: CRYPTO volume attached as sd3 > > Here you need to do this first: > > cd /dev > sh MAKEDEV sd3 That's not the first time someone is bitten by this. I tweaked the FDE rundown a little and it now contains a line to that effect. Sorry for the inconvenience. > > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 > > uid 0 on /: file system full > > If you skip the above step, /dev/rsd3c is created as a regular file and fills > up the root fs.
Re: CRYPTO volume created, but appears as full
On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote: > I followed the steps in the FAQ for setting up full disk encryption. > Everything goes according to plan until I attempt to write zeros to the > first megabyte of the new pseudo-device; as you can see below, dd informs > me that the file system is full, that there is no space left on the device. > Interestingly, the last line of dmesg is also "uid 0 on /: file system > full". I've retried this with 5.9 and -current, but the outcome is the > same. I've also tried rebooting after disklabel and bioctl. I have pasted > below the relevant sequence, followed by the full dmesg. > # bioctl -c C -l sd0a softraid0 > New passphrase: > Re-type passphrase: > sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed > sd3: 114470MB, 512 bytes/sector, 234435953 sectors > softraid0: CRYPTO volume attached as sd3 Here you need to do this first: cd /dev sh MAKEDEV sd3 > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 > uid 0 on /: file system full If you skip the above step, /dev/rsd3c is created as a regular file and fills up the root fs.
Re: CRYPTO volume created, but appears as full
> On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote: > > I followed the steps in the FAQ for setting up full disk encryption. > > Everything goes according to plan until I attempt to write zeros to the > > first megabyte of the new pseudo-device; as you can see below, dd informs > > me that the file system is full, that there is no space left on the device. > > Interestingly, the last line of dmesg is also "uid 0 on /: file system > > full". I've retried this with 5.9 and -current, but the outcome is the > > same. I've also tried rebooting after disklabel and bioctl. I have pasted > > below the relevant sequence, followed by the full dmesg. > > > # bioctl -c C -l sd0a softraid0 > > New passphrase: > > Re-type passphrase: > > sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed > > sd3: 114470MB, 512 bytes/sector, 234435953 sectors > > softraid0: CRYPTO volume attached as sd3 > > Here you need to do this first: > > cd /dev > sh MAKEDEV sd3 > > > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 > > uid 0 on /: file system full > > If you skip the above step, /dev/rsd3c is created as a regular file and fills > up the root fs. I'll tell everyone the secret. The ramdisk does not contain disk device nodes. We potentially need too many. So it creates them on the fly, in the script. As soon as you go into do-things-by-hand, you are on your own.
Re: CRYPTO volume created, but appears as full
On Sat, May 28, 2016 at 06:03:48PM +, Ivan Markin wrote: > Sebastien Marie: > > Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the > > /dev/sd* aren't created by default. > > Why it is so? Can this be found somewhere in documentation? If the ramdisk shipped with all possible device nodes, the small ramdisk filesystem would run out of inodes. The installer script compensates for this by creating device nodes it knows will be needed, so normally you don't have to think about this. Because the install script does not support FDE installs at present, the /dev/rsd3c device node is not created automatically.
Re: CRYPTO volume created, but appears as full
On Sat, May 28, 2016 at 06:15:35PM +0200, Robert Campbell wrote: [...] > # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 > uid 0 on /: file system full > > /: write failed, file system is full > dd: /dev/rsd3c: No space left on device > 1+0 records in > 0+0 records out > 0 bytes transferred in 0.007 secs (0 bytes/sec) > [...] > OpenBSD 6.0-beta (RAMDISK_CD) #1915: Wed May 25 12:32:35 MDT 2016 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD Do you run these commands on the ramdisk (bsd.rd) ? If yes, all the /dev/sd* aren't created by default. You could check that with: # ls -l /dev/rsd3c I think you create a new (regular) file /dev/rsd3c in / partition (and so filling / partition). To make sd3 device: # cd /dev && ./MAKEDEV sd3 -- Sebastien Marie
Re: CRYPTO volume created, but appears as full
Robert Campbell: > I followed the steps in the FAQ for setting up full disk encryption. > Everything goes according to plan until I attempt to write zeros to the > first megabyte of the new pseudo-device; as you can see below, dd informs > me that the file system is full, that there is no space left on the device. > Interestingly, the last line of dmesg is also "uid 0 on /: file system > full". I've retried this with 5.9 and -current, but the outcome is the > same. I've also tried rebooting after disklabel and bioctl. I have pasted > below the relevant sequence, followed by the full dmesg. I've experienced same behavior. It always happened when sd(4) driver is in use and never with wd(4). I managed to enable FDE using random disklabel(8) tricks. This is probably a bug in sd(4). Try to initialize your disk with standard disklabel without CRYPTO first (e.g. via installation program then exit to shell). Then perform the steps from FDE guide. -- Ivan Markin
Re: hardware recommendation for openbsd-based thin client?
I have a Shuttle DS437 and DS57U7 for desktop. Fanless, small, and the former in particular is pretty affordable. These are sold as barebones so you only add the components you need -- in your case, probably nothing but RAM. Do note that the case must stand upright, so they're not as convenient as an APU lying flat in an environment where random people can knock things over.
CRYPTO volume created, but appears as full
I followed the steps in the FAQ for setting up full disk encryption. Everything goes according to plan until I attempt to write zeros to the first megabyte of the new pseudo-device; as you can see below, dd informs me that the file system is full, that there is no space left on the device. Interestingly, the last line of dmesg is also "uid 0 on /: file system full". I've retried this with 5.9 and -current, but the outcome is the same. I've also tried rebooting after disklabel and bioctl. I have pasted below the relevant sequence, followed by the full dmesg. # dd if=/dev/random of=/dev/rsd0c bs=1m dd: /dev/rsd0c: short write on character device dd: /dev/rsd0c: end of device 114474+0 records in 114473+1 records out 120034123776 bytes transferred in 3217.122 secs (37311023 bytes/sec) # fdisk -iy sd0 Writing MBR at offset 0. # disklabel -E sd0 Label editor (enter '?' for help at any prompt) > a a offset: [64] size: [234436481] * FS type: [4.2BSD] RAID > w > q No label changes. # bioctl -c C -l sd0a softraid0 New passphrase: Re-type passphrase: sd3 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed sd3: 114470MB, 512 bytes/sector, 234435953 sectors softraid0: CRYPTO volume attached as sd3 # dd if=/dev/zero of=/dev/rsd3c bs=1m count=1 uid 0 on /: file system full /: write failed, file system is full dd: /dev/rsd3c: No space left on device 1+0 records in 0+0 records out 0 bytes transferred in 0.007 secs (0 bytes/sec) DMESG: OpenBSD 6.0-beta (RAMDISK_CD) #1915: Wed May 25 12:32:35 MDT 2016 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 4261072896 (4063MB) avail mem = 4130086912 (3938MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdffb7020 (7 entries) bios0: vendor coreboot version "88a4f96" date 03/07/2016 bios0: PC Engines apu2 acpi0 at bios0: rev 2 acpi0: tables DSDT FACP SSDT APIC HEST SSDT SSDT HPET acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.28 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF LUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPC NT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8, ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1 cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16- way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfec2, version 21, 32 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PBR4) acpiprt2 at acpi0: bus 1 (PBR5) acpiprt3 at acpi0: bus 2 (PBR6) acpiprt4 at acpi0: bus 3 (PBR7) acpiprt5 at acpi0: bus 4 (PBR8) acpicpu at acpi0 not configured "PNP0C0C" at acpi0 not configured "PNP0501" at acpi0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 16h Root Complex" rev 0x00 pchb1 at pci0 dev 2 function 0 "AMD AMD64 16h Host" rev 0x00 ppb0 at pci0 dev 2 function 2 "AMD AMD64 16h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 em0 at pci1 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:0d:b9:41:5f: 30 ppb1 at pci0 dev 2 function 3 "AMD AMD64 16h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 em1 at pci2 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:0d:b9:41:5f: 31 ppb2 at pci0 dev 2 function 4 "AMD AMD64 16h PCIE" rev 0x00: msi pci3 at ppb2 bus 3 em2 at pci3 dev 0 function 0 "Intel I210" rev 0x03: msi, address 00:0d:b9:41:5f: 32 ppb3 at pci0 dev 2 function 5 "AMD AMD64 16h PCIE" rev 0x00: msi pci4 at ppb3 bus 4 vendor "Atheros", unknown product 0x003c (class network subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not configured "AMD CCP" rev 0x00 at pci0 dev 8 function 0 not configured xhci0 at pci0 dev 16 function 0 "AMD Bolton xHCI" rev 0x11: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: apic 4 int 19, AHC I 1.3 ahci0: port 0: 6.0Gb/s scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5002538d40b63943 sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin ehci0 at pci0 dev 19 function 0 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 18 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1 "AMD Hudson-2 SMBus" rev 0x42 at pci0 dev 20 function 0 not configured "AMD Hudson-2 LPC" rev 0x11 at pci0 dev 20 function 3 not configured sdhc0 at pci0 dev 20 function 7 "AMD Bolton SD/MMC" rev 0x01: apic 4 int 16 sdhc0: SDHC 2.0, 63 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma pchb2 at pci0 dev
Re: hardware recommendation for openbsd-based thin client?
On 2016-05-28, Carson Chittom wrote: > Stuart Henderson writes: > >> On 2016-05-27, Marko Cupać wrote: >>> Hi, >>> >>> I have just noticed that pcengines has alix models with VGA ports: >>> >>> http://www.pcengines.ch/alix3d3.htm >>> http://www.pcengines.ch/alix1e.htm >>> >>> Anyone tried OpenBSD on them? >> >> Yep. It worked, including X - I used one with autologin to a browser to >> display a job schedule on a wallscreen. This was some years ago though, >> I wouldn't buy one for that job now. > > OK, I'll bite: what *would* you buy for that job now? Depends. And caveat: for that particular job I wouldn't care about accelerated X and would be willing to use the framebuffer. If I was buying just one and wanted higher chances of it working I'd probably look at a broadwell NUC, but they're expensive. If it was something where I could afford to buy one to try with a higher risk of it not working I'd probably get some braswell box (NUC, asrock beebox, etc) to play with as they're a lot cheaper, and offer it to a developer working in that area if it didn't work out at all. Last time I needed a bunch of machines for a somewhat similar task I *did* need accelerated X, didn't quite negotiate the minefield of graphics chip models and started with a N2830 NUC which wasn't accelerated. Then switched to Haswell NUCs which are working nicely, but they were just going EoL and we only just managed to scrape together enough stock from among a couple of distributors for the deployment ;) BTW I just tried booting that Bay Trail N2830 and it's now working nicely in -current.
Re: I need to get a Russian keyboard
On 28 May 2016 at 02:33, Brandon Vincent wrote: > When I saw this thread, I was reminded of my attempts to get a > keyboard as cool (although inaccurate) as the one in Tomorrow Never > Dies (1997). > I once knew a feller called Tom Morrow who was a draper by trade. He had a roll of white cotton fabric and a supply of carmine, but he refused to sell me red cloth.
Re: hardware recommendation for openbsd-based thin client?
Stuart Henderson writes: > On 2016-05-27, Marko Cupać wrote: >> Hi, >> >> I have just noticed that pcengines has alix models with VGA ports: >> >> http://www.pcengines.ch/alix3d3.htm >> http://www.pcengines.ch/alix1e.htm >> >> Anyone tried OpenBSD on them? > > Yep. It worked, including X - I used one with autologin to a browser to > display a job schedule on a wallscreen. This was some years ago though, > I wouldn't buy one for that job now. OK, I'll bite: what *would* you buy for that job now?
Re: the balance between OpenBSD and life
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 05/28/16 14:24, Teng Zhang wrote: > I can't adjust the time for OpenBSD and my life appropriately. > Could you please share your experience with me about how you adjust > your time between OpenBSD and your life. That is a very, very odd question to ask. In my experience, keeping an OpenBSD system (or multitudes) running requires significantly less effort than most Unixish systems I've encountered. If you feel that OpenBSD is consuming too much of your time, I would recommend checking what it is you're doing wrong. Following outdated HOWTOs that insist that upgrades of both base system and ports (pakcages) must be done by cvs checkout and rebuild on each individual system, perhaps? That's just a wild guess, or course. On the other hand, if you're aiming to master the internals of the system, you should expect to spend significant time studying, experimenting, making mistakes and fixing them. > thanks for any reply. I'm sure replies will be more constructive if you offer up some more information about the actual problem. - -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. iQIcBAEBCAAGBQJXSag7AAoJELJiGF9h4DyeqOYQALiGrmanTSLTzAHHTEx59Gn6 7pCzq8KWAgu+d5J2nWXiVD3TXhbKr/+lLr6L8eGOu6VYLOJwoMjWExtZNYRun3O3 htawgHvJKhmWYcP+/nUBow2Tglq7a4fyUp3Om1c6HKRqDz0UuRteRCbcknuuHOGs WWzgUj0ktYU1xrkvApzV34sCXEtkf2mhnuWFWAErZZK5DBpTH+TmCZnautKCNdJA jKQUQM0EB2JWp1VCFqLoYAIlZhUCYC0i6n8XiHQPpZFRDFGRE3OeRgVZq22rmYbD NFBQ+JmGh5MXmlVMte4VWNouRENkrbaLFzDOhQA0jM6LKVD2YzIiWYxv9pOSO+DC Fvj4qfavbRBhkmtBD3C74Vd4h2a28niCKih1FDU+70DXzNSCNVaqvM1g5dS5iRrb ggyav+v089qPmCf8YSaVd5ImOQy0JSreJOzftB3ykWIQ3Ei5uehiuJvEQx4fFq1K aH+3HY5GzixCQzffgD83dekOuv0IBFGNOYsIpE/0RSdu4UNjNZFxhgn00aS70uEg VhtKOlppDyp/BBHgk7oHi/8t0/Dl065Xb/MKg8CNQicjWEX++14Cm6U3tLkai50N COCQgkLYLYrfCm6Z6UfE48HONDI6a16B5BhWxkUkwfOZnUun2uSCFp6MpQY5GhEf t8bbAF1uS+hbJlM5BfB2 =hu0v -END PGP SIGNATURE-
Re: the balance between OpenBSD and life
Lmao. kk, i just use snapshots and packages, no compilation, no headache. 2016-05-28 15:24 GMT+03:00 Teng Zhang : > I can't adjust the time for OpenBSD and my life appropriately. Could you > please share your experience with me about how you adjust your time between > OpenBSD and your life. > thanks for any reply.
Re: the balance between OpenBSD and life
On Sat, May 28, 2016 at 8:24 AM, Teng Zhang wrote: > I can't adjust the time for OpenBSD and my life appropriately. Could you > please share your experience with me about how you adjust your time between > OpenBSD and your life. > thanks for any reply. I am not at all sure what you mean by "appropriately", but one trick might be to limit posts to the lists to constructive topics? -- Raul
the balance between OpenBSD and life
I can't adjust the time for OpenBSD and my life appropriately. Could you please share your experience with me about how you adjust your time between OpenBSD and your life. thanks for any reply.
