Re: can't boot from USB3.0 flash memory

[Christoph R. Murauer]

> On 27 November 2015 at 12:31:32, Ville Valkonen 
> wrote:
>
> Thanks for your good hints:)
>
> some laptop pc have this problem :<

 [ ... ]

> manula is almost good. but, some same problem issues didn't share on.
> mailing list is good means. but latest machine problems are stacked
> and
> no improvement.

I am no developer but have you already posted a dmesg (inline in the
email ?).

See http://www.openbsd.org/mail.html section Include important
information.

*The dmesg(8) tells us exactly what is IN your machine, not what
stickers are on the outside.*

How to get a dmesg - simple read the FAQ 4.10.

> who makes driver or good improvement. but beginer and newest user
> didn't
> know how to get answer.

I am also a new user and have no problems to get a answer, as long as
you ask the right questions and, provided the needed infrmations.

> dmesg is no answer. who get kernel panic... "how to get debuging..."
> (these todo couldn't get answer...)

dmesg would be no answer for you - but for developers it helps. Kernel
panic, debugging - start reading FAQ 7.6 about serial consoles and
http://www.openbsd.org/report.html section How to create a problem
report.

> some mailing list responses are like "read man" "man 4 ..." :<
> and get no answer...

Sure, there are people out there who wrote the FAQ, there are people
out there who wrote the text for the mailinglist page ... and, there
are users out there, which are simple not interested to read existing
informations.

If you ask a question like, I have problem X and readed manual page Y
but I simple don't understand it - I think, you will get a answer. If
you expect, that others do your work - you will be very disappointed
about what you get.

> if "no answer", say "no answer" or "I don't know".
> problem must store and announcement.

See the above.

> Just my complaint.
>
> Theo de raadt is greatest programer. I love him.

I think, he will be very happy if you read the FAQ and provide the
minimum informations which are needed to answer your questions.

The kernels of *BSD include nonfree firmware blobs?

[français]

The Free Software Foundation (FSF) says that:

"FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
programs in their ports system. In addition, their kernels include nonfree
firmware blobs.

Nonfree firmware programs used with Linux, the kernel, are called
“blobs”,
and that's how we use the term. In BSD parlance, the term “blob” means
something else: a nonfree driver. OpenBSD and perhaps other BSD
distributions (called “projects” by BSD developers) have the policy of
not
including those. That is the right policy, as regards drivers; but when the
developers say these distributions “contain no blobs”, it causes a
misunderstanding. They are not talking about firmware blobs.

No BSD distribution has policies against proprietary binary-only firmware
that might be loaded even by free drivers."

The affirmations of FSF that I cited above are falses?

With spying revelations, it is well-known that non-free firmware can contain
backdoors. ( just one recent example:
http://www.wired.com/2015/02/nsa-firmware-hacking/ )

I would feel a lot safer if the kernel and packages were fully free,
containing no non-free drivers nor non-free "firmware".









--
View this message in context:
http://openbsd-archive.7691.n7.nabble.com/The-kernels-of-BSD-include-nonfree-
firmware-blobs-tp283900.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: The kernels of *BSD include nonfree firmware blobs?

[Peter Hessler]

this has been discussed ad-nauseam, please search the archives.

(ps: do not respond to this, we are not interested in having this
discussion again)


On 2015 Nov 27 (Fri) at 08:33:00 -0700 (-0700), fran??ais wrote:
:The Free Software Foundation (FSF) says that:
:
:"FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
:programs in their ports system. In addition, their kernels include nonfree
:firmware blobs.
:
:Nonfree firmware programs used with Linux, the kernel, are called
:???blobs???,
:and that's how we use the term. In BSD parlance, the term ???blob??? means
:something else: a nonfree driver. OpenBSD and perhaps other BSD
:distributions (called ???projects??? by BSD developers) have the policy of
:not
:including those. That is the right policy, as regards drivers; but when the
:developers say these distributions ???contain no blobs???, it causes a
:misunderstanding. They are not talking about firmware blobs.
:
:No BSD distribution has policies against proprietary binary-only firmware
:that might be loaded even by free drivers."
:
:The affirmations of FSF that I cited above are falses?
:
:With spying revelations, it is well-known that non-free firmware can contain
:backdoors. ( just one recent example:
:http://www.wired.com/2015/02/nsa-firmware-hacking/ )
:
:I would feel a lot safer if the kernel and packages were fully free,
:containing no non-free drivers nor non-free "firmware".

Re: The kernels of *BSD include nonfree firmware blobs?

[Michael McConville]

Drivers run on the CPU, firmware runs on the peripheral device (e.g. the
network card or hard drive). BSDs reject driver blobs because they run
with the same privilege and in the same address space as the rest of the
kernel. Because of this, they can meddle with or corrupt the kernel.

Before asking questions like this in the future:

 1. Do more research
 2. Don't use such inflammatory phrasing

français wrote:
> The Free Software Foundation (FSF) says that:
> 
> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
> programs in their ports system. In addition, their kernels include nonfree
> firmware blobs.
> 
> Nonfree firmware programs used with Linux, the kernel, are called
> “blobs”,
> and that's how we use the term. In BSD parlance, the term “blob” means
> something else: a nonfree driver. OpenBSD and perhaps other BSD
> distributions (called “projects” by BSD developers) have the policy of
> not
> including those. That is the right policy, as regards drivers; but when the
> developers say these distributions “contain no blobs”, it causes a
> misunderstanding. They are not talking about firmware blobs.
> 
> No BSD distribution has policies against proprietary binary-only firmware
> that might be loaded even by free drivers."
> 
> The affirmations of FSF that I cited above are falses?
> 
> With spying revelations, it is well-known that non-free firmware can contain
> backdoors. ( just one recent example:
> http://www.wired.com/2015/02/nsa-firmware-hacking/ )
> 
> I would feel a lot safer if the kernel and packages were fully free,
> containing no non-free drivers nor non-free "firmware".

Re: The kernels of *BSD include nonfree firmware blobs?

[Peter N. M. Hansteen]

On 11/27/15 16:33, français wrote:

The Free Software Foundation (FSF) says that:

"FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
programs in their ports system. In addition, their kernels include nonfree
firmware blobs.


The FSF should have access to people who could do a bit of fact 
checking, but it's possible they don't actually care all that much about 
accuracy. The three projects all have their own approach to this 
problem, and with minimal search effort you or the FSF would have been 
able to find complete descriptions of how OpenBSD at least handles the 
situation.


Go search the archives, nothing much has changed since the first time 
this issue came up on misc. And I remember this actually being a topic 
of one of Theo's presentations and possibly others. Seek and you shall find.


--
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.

Re: The kernels of *BSD include nonfree firmware blobs?

[français]

Theo de Raadt wrote
>> The Free Software Foundation (FSF) says that:
>>
>> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining
>> nonfree
>> programs in their ports system. In addition, their kernels include
>> nonfree
>> firmware blobs.
>
>> Nonfree firmware programs used with Linux, the kernel, are called
>> "blobs" and that's how we use the term. In BSD parlance, the term "blob"
>> means
>> something else: a nonfree driver. OpenBSD and perhaps other BSD
>> distributions (called "projects" by BSD developers) have the policy of
>> not including those. That is the right policy, as regards drivers; but
>> when the
>> developers say these distributions "contain no blobs", it causes a
>> misunderstanding. They are not talking about firmware blobs.
>>
>> No BSD distribution has policies against proprietary binary-only firmware
>> that might be loaded even by free drivers."
>
> GNU software contains large volumes of source code to ensure their
> code runs on Windows and other proprietary platforms.
>
> Large means nearly a hundred thousand lines of #ifdef spaghetti spread
> throughout their code base, which would otherwise not be there.  If
> the spaghetti wasn't there, the code quality would almost assuredly
> be higher for everyone else on free software.  Instead, the GNU project
> insists that support for Windows and other commercial systems remain,
> requiring all source code contributors to work around that practice,
> and continue maintainance.
>
> As we learned from OpenSSL in the last two years, #ifdef support for
> dated commercial platforms comes with great risk, and rarely any
> benefit.
>
> We call that hypocrisy:
>
> the practice of claiming to have moral standards or beliefs to
> which one's own behavior does not conform"
>
>> The affirmations of FSF that I cited above are falses?
>
> It is true RMS said the above.  But it is also true the FSF does not
> follow that same guidance to the full extent possible regarding their
> own software.
>
> And there is another mistake in the FSF guidance you quoted.  Red Hat
> Debian, Ubuntu, and most other Linux distributions.  That's called not
> pissing off your financial contribution base.
>
> Apparently we are not allowed to have free choice as to how we make
> software available, but must follow guidance of some external entity?
>
> RMS has an axe to grind -- that is the real truth you are hunting for.
>
>> With spying revelations, it is well-known that non-free firmware can
>> contain
>> backdoors. ( just one recent example:
>> http://www.wired.com/2015/02/nsa-firmware-hacking/ )
>>
>> I would feel a lot safer if the kernel and packages were fully free,
>> containing no non-free drivers nor non-free "firmware".
>
> Nice tie in.  Unfortunately, beggars can't be choosers.  You should
> run some other software then.






I wanted ask the following:

The FSF say the true about *BSD when say that *BSD include instructions for
obtaining nonfree programs in their ports system?

The FSF say the true about *BSD when say also that:

In addition, their kernels include nonfree firmware blobs?

Is true that:

Nonfree firmware programs used with Linux, the kernel, are called
“blobs”,
and that's how we the FSF use the term?

In BSD parlance, the term “blob” means something else: a nonfree driver?

OpenBSD and perhaps other BSD distributions (called “projects” by BSD
developers) have the policy of not including those?

 That is the right policy, as regards drivers?

But when the developers say these distributions “contain no blobs”, it
causes a misunderstanding?

Is true that they are not talking about firmware blobs?



--
View this message in context:
http://openbsd-archive.7691.n7.nabble.com/The-kernels-of-BSD-include-nonfree-
firmware-blobs-tp283900p283907.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: The kernels of *BSD include nonfree firmware blobs?

[Peter N. M. Hansteen]

On 11/27/15 17:32, français wrote:

I wanted ask the following:

The FSF say the true about *BSD when say that *BSD include instructions for
obtaining nonfree programs in their ports system?


Please start with http://www.openbsd.org/lyrics.html#39 (the OpenBSD 3.9 
theme song), and look at the date on http://www.openbsd.org/39.html - 
that's a good time frame (plus or minus a few months) to find the 
answers to your questions in mailing list archives. Almost ten years 
later, the situation isn't all that different, and the OpenBSD approach 
certainly hasn't changed.


Now will you please do a bit of reading?

HTH, HAND
--
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.

Re: can't boot from USB3.0 flash memory

[freeunix]

On 27 November 2015 at 12:31:32, Ville Valkonen  
wrote:


Thanks for your good hints:)

some laptop pc have this problem :<

into BIOS setup. disable wifi and any section.
it'll be this problem has come:<

Lenovo G50-80, Fujitsu LifeBook, and any

Now. Just, I check up run OpenBSD on any user's laptop PC.
HP machines too.

to some people.
OpenBSD is greatest Operating System. but OpenBSD have some problems.(no 
security hole)

manula is almost good. but, some same problem issues didn't share on.
mailing list is good means. but latest machine problems are stacked and 
no improvement.


who makes driver or good improvement. but beginer and newest user didn't 
know how to get answer.

dmesg is no answer. who get kernel panic... "how to get debuging..."
(these todo couldn't get answer...)

some mailing list responses are like "read man" "man 4 ..." :<
and get no answer...

if "no answer", say "no answer" or "I don't know".
problem must store and announcement.

Just my complaint.

Theo de raadt is greatest programer. I love him.

Re: Install snapshot failes

[Michael McConville]

Carsten Kunze wrote:
> installing a todays amd64 snapshot with image install58.fs ends with
> "installboot: No blocks to load". What can be the problem?

There were some slightly unstable changes made to installboot yesterday.
It'll probably be fixed quickly. I'd wait and install a newer snapshot
soon.

Re: The kernels of *BSD include nonfree firmware blobs?

[français]

> The Free Software Foundation (FSF) says that:
> 
> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining
> nonfree
> programs in their ports system. In addition, their kernels include nonfree
> firmware blobs.
 
> Nonfree firmware programs used with Linux, the kernel, are called
> "blobs" and that's how we use the term. In BSD parlance, the term "blob"
> means
> something else: a nonfree driver. OpenBSD and perhaps other BSD
> distributions (called "projects" by BSD developers) have the policy of
> not including those. That is the right policy, as regards drivers; but
> when the
> developers say these distributions "contain no blobs", it causes a
> misunderstanding. They are not talking about firmware blobs.
> 
> No BSD distribution has policies against proprietary binary-only firmware
> that might be loaded even by free drivers."

GNU software contains large volumes of source code to ensure their
code runs on Windows and other proprietary platforms.

Large means nearly a hundred thousand lines of #ifdef spaghetti spread
throughout their code base, which would otherwise not be there.  If
the spaghetti wasn't there, the code quality would almost assuredly
be higher for everyone else on free software.  Instead, the GNU project
insists that support for Windows and other commercial systems remain,
requiring all source code contributors to work around that practice,
and continue maintainance.

As we learned from OpenSSL in the last two years, #ifdef support for
dated commercial platforms comes with great risk, and rarely any
benefit.

We call that hypocrisy:

the practice of claiming to have moral standards or beliefs to
which one's own behavior does not conform"

The project FreeBSD still embrace the Blob?



--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/The-kernels-of-BSD-include-nonfree-firmware-blobs-tp283900p283910.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: The kernels of *BSD include nonfree firmware blobs?

[Theo de Raadt]

> The Free Software Foundation (FSF) says that:
> 
> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
> programs in their ports system. In addition, their kernels include nonfree
> firmware blobs.
 
> Nonfree firmware programs used with Linux, the kernel, are called
> "blobs" and that's how we use the term. In BSD parlance, the term "blob" means
> something else: a nonfree driver. OpenBSD and perhaps other BSD
> distributions (called "projects" by BSD developers) have the policy of
> not including those. That is the right policy, as regards drivers; but when 
> the
> developers say these distributions "contain no blobs", it causes a
> misunderstanding. They are not talking about firmware blobs.
> 
> No BSD distribution has policies against proprietary binary-only firmware
> that might be loaded even by free drivers."

GNU software contains large volumes of source code to ensure their
code runs on Windows and other proprietary platforms.

Large means nearly a hundred thousand lines of #ifdef spaghetti spread
throughout their code base, which would otherwise not be there.  If
the spaghetti wasn't there, the code quality would almost assuredly
be higher for everyone else on free software.  Instead, the GNU project
insists that support for Windows and other commercial systems remain,
requiring all source code contributors to work around that practice,
and continue maintainance.

As we learned from OpenSSL in the last two years, #ifdef support for
dated commercial platforms comes with great risk, and rarely any
benefit.

We call that hypocrisy:

the practice of claiming to have moral standards or beliefs to
which one's own behavior does not conform"

> The affirmations of FSF that I cited above are falses?

It is true RMS said the above.  But it is also true the FSF does not
follow that same guidance to the full extent possible regarding their
own software.

And there is another mistake in the FSF guidance you quoted.  Red Hat
Debian, Ubuntu, and most other Linux distributions.  That's called not
pissing off your financial contribution base.

Apparently we are not allowed to have free choice as to how we make
software available, but must follow guidance of some external entity?

RMS has an axe to grind -- that is the real truth you are hunting for.

> With spying revelations, it is well-known that non-free firmware can contain
> backdoors. ( just one recent example:
> http://www.wired.com/2015/02/nsa-firmware-hacking/ )
> 
> I would feel a lot safer if the kernel and packages were fully free,
> containing no non-free drivers nor non-free "firmware".

Nice tie in.  Unfortunately, beggars can't be choosers.  You should
run some other software then.

Re: can't boot from USB3.0 flash memory

[Ville Valkonen]

On 26 November 2015 at 15:26,  wrote:

> I have USB3.0 flash memory.(SANDISK)
> "OpenBSD 5.8 amd64/i386 on USB3.0"
>
> 1.USB3.0 flash memory connect to USB2.0/1.0
> boot: It's fine.
> 2.USB3.0 flash memory connect to USB3.0
> boot: can't boot!
>
> anyone don't need boot from USB3.0?
>

Hi,

do you happen to have an HP machine? Many of those have BIOS issues with
USB boot devices.

--
Regards,
Ville Valkonen

Re: random.seed question

[Craig Skinner]

On 2015-11-26 Thu 15:54 PM |, Paul de Weerd wrote:
> 
> I'd recommend sticking something in rc.local or creating an @reboot
> cronjob that updates the /etc/random.seed.  May not be ideal (the
> entropy may not be very strong - I don't know if there is much
> difference between just after boot or just before shutdown in this
> regard), but at least it's easier to carry from release to release.
> 

If randomly loosing power is the cause of the shutdown,
then he can't schedule it just before shutdown.
rc.shutdown(8) won't often help.

Both @hourly & @reboot cronjobs (for when power cycles mutliple times
per hour) might help.

-- 
Why is 'hour' not spelt 'hor' in America?

Re: Wireless PCI hardware

[Tati Chevron]

On Fri, Nov 27, 2015 at 10:59:53AM +, Kevin Chadwick wrote:

>I want OpenBSD in hostap mode with PCI or PCIe ath / athn driver.

Be aware that hostap mode is not particularly reliable, usable, or with
good peformance at the moment.


What does at the moment mean?


I've not had chance to really test hostap mode with a real workload on 5.8 yet, 
but I did test it using ath, athn, and ral with every -release up to 5.7 since 
I've had the hardware.  I saw very little if any change in performance, which 
was not surprising as the code has not changed much..


I've only just upgraded to 5.8 and I did notice whatsapp not being
quite so snappy but 5.6 seemed (no real testing) both reliable and
usable for us?


I experienced slow performance, the transmission mode dropping under heavy 
loads, and random hangs.

Incidentally, the existing code for many wireless chipsets doesn't set the 
usable channels correctly, based on the regdomain.  The only way to prevent 
usage of unavailable channels seems to be by modifying the source.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: can't boot from USB3.0 flash memory

[Tati Chevron]

On Fri, Nov 27, 2015 at 02:31:32PM +0200, Ville Valkonen wrote:

On 26 November 2015 at 15:26,  wrote:


I have USB3.0 flash memory.(SANDISK)
"OpenBSD 5.8 amd64/i386 on USB3.0"

1.USB3.0 flash memory connect to USB2.0/1.0
boot: It's fine.
2.USB3.0 flash memory connect to USB3.0
boot: can't boot!

anyone don't need boot from USB3.0?



Hi,

do you happen to have an HP machine?


Didn't you read the attached dmesg?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: Wireless PCI hardware

[lists]

> > What usb are you using as
> > the ones i tried a while back weren't much good though there have been
> > changes to the drivers since so probably worth trying again?

USB wireless devices are usually quite flaky at the miniUSB connector
end (or need re-soldering, and cables malfunction over time), rarely
have hostap mode, and are a total nuisance to use.

My netbook (2010) arrived with Atheros AR-9285 which is athn(4) miniPCIe
half length, you can surely find similar devices online cheap and stick
it in a PCI to PCIe adaptor (electrical converter only).  It works OK
in hostap mode verified and using it frequently.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/athn.4

> For USB I am using the run(4) driver for Ralink 802.11n product 
> Netsys98N but my head hurts a bit while using it.

The run(4) devices do NOT currently support hostap mode.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/run.4

You can look for a TP-Link (cheap) high power device with an Atheros
chipset, these are usually noisy but still work above average.  I have
a TL-WN7200ND, it is run(4) and works fine in client only mode.

You're most probably imagining the headache part or you have some sort
of astigmatism (or another eye focus related condition you're unaware
of), go "see" an optician who can also fix your wireless power rating
psychosomatic (look and) feel.

> Not so good for 
> long-term use. :-) Works extremely well though, very long-range. But 
> still, looking for PCI/PCIe.
> 
> http://www.dx.com/p/netsys-98n-2-4ghz-4200mw-high-power-802-11b-g-n-150mbps-usb-wi-fi-wireless-network-adapter-93722#.Vled1noy30M

This is very likely false rating as the USB 2.0 port is rated 500 mA at
5 V DC (which usually drops to 4.75 V under full load) delivering up to
2500 mW at maximum power drain.  Probably would be interesting to
actually ask the maker what's this stupid lie and see what they come up
with.  Also with these phoney devices, the 9 dBi antennas are usually
just 5 dBi in a longer plastic casing, an incredibly brain damaged trick.

https://en.wikipedia.org/wiki/USB

Install snapshot failes

[Carsten Kunze]

Hello,

installing a todays amd64 snapshot with image install58.fs ends with 
"installboot: No blocks to load". What can be the problem?

Carsten

Re: The kernels of *BSD include nonfree firmware blobs?

[Eric Furman]

Pen and paper and inconspicuous drop spots.

On Fri, Nov 27, 2015, at 10:33 AM, français wrote:
> The Free Software Foundation (FSF) says that:
>
> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining
> nonfree
> programs in their ports system. In addition, their kernels include
> nonfree
> firmware blobs.
>
> Nonfree firmware programs used with Linux, the kernel, are called
> “blobs”,
> and that's how we use the term. In BSD parlance, the term “blob” means
> something else: a nonfree driver. OpenBSD and perhaps other BSD
> distributions (called “projects” by BSD developers) have the policy of
> not
> including those. That is the right policy, as regards drivers; but when
> the
> developers say these distributions “contain no blobs”, it causes a
> misunderstanding. They are not talking about firmware blobs.
>
> No BSD distribution has policies against proprietary binary-only firmware
> that might be loaded even by free drivers."
>
> The affirmations of FSF that I cited above are falses?
>
> With spying revelations, it is well-known that non-free firmware can
> contain
> backdoors. ( just one recent example:
> http://www.wired.com/2015/02/nsa-firmware-hacking/ )
>
> I would feel a lot safer if the kernel and packages were fully free,
> containing no non-free drivers nor non-free "firmware".
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
>
http://openbsd-archive.7691.n7.nabble.com/The-kernels-of-BSD-include-nonfree-
> firmware-blobs-tp283900.html
> Sent from the openbsd user - misc mailing list archive at Nabble.com.

Macbook Pro 11,1 - dmesg

[Bryan C. Everly]

I have it up and running.  It runs pretty hot and in Gnome, the settings
app crashes before it can load (as does the power management app).
Guessing that the Apple SMC voodoo is probably not supported.

Here's my dmesg:

OpenBSD 5.8-current (GENERIC.MP) #1663: Wed Nov 25 13:59:58 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error
ff
real mem = 17065656320 (16275MB)
avail mem = 16544329728 (15777MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0x8ad14000 (43 entries)
bios0: vendor Apple Inc. version "MBP111.88Z.0138.B16.1509081438" date
09/08/2015
bios0: Apple Inc. MacBookPro11,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT SSDT SSDT MCFG DMAR
acpi0: wakeup devices P0P2(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4)
ARPT(S4) RP05(S3) RP06(S3) XHC1(S3) ADP1(S3) LID0(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz, 2700.46 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
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 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz, 2700.00 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz, 2700.01 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-4558U CPU @ 2.80GHz, 2700.01 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEA
DLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,
BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xe000, bus 0-155
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 5 (RP05)
acpiprt6 at acpi0: bus 4 (RP06)
acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33),
C1(1000@1 mwait.1), PSS
acpibat0 at acpi0: BAT0 model "3545797981023400290" type
3545797981528607052 oem "3545797981528673619"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpivideo0 at acpi0: IGPU
acpivout0 at acpivideo0: DD01
cpu0: Enhanced SpeedStep 2700 MHz: speeds: 2801, 2800, 2700, 2400, 2200,
2000, 1700, 1500, 1300, 1100, 900, 756 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel Iris Graphics 5100" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 2560x1600
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 3 function 0 "Intel Core 4G HD Audio" rev 0x09: msi
xhci0 

Re: The kernels of *BSD include nonfree firmware blobs?

[David Coppa]

Il 27/nov/2015 21:43, "bofh"  ha scritto:
>
> Do you understand your question has been answered over and over again, and
> is not relevant here?
>
> Why do you continue by asking about blobs in FreeBSD?
>

Because he's a troll.

Stop feeding him, please.

Re: The kernels of *BSD include nonfree firmware blobs?

[Giancarlo Razzolini]

Em 27-11-2015 18:35, bofh escreveu:
> Why do you continue by asking about blobs in FreeBSD?
Troll Detected. Troll Fed. End of Thread.

Re: MacbookPro 11,1

[Bryan C. Everly]

Hi guys,

I got a rough cut of my how-to up on my blog.  I'd appreciate any feedback
/ suggestions:

http://functionallyparanoid.com/2015/11/27/hidpi/


Thanks,
Bryan

On Thu, Nov 26, 2015 at 12:25 PM, Bryan Vyhmeister 
wrote:

> On Thu, Nov 26, 2015 at 09:00:48AM +0100, Joerg Jung wrote:
> > Can you send a dmesg for this Air7,2 please?
>
> Here's my dmesg from today's snapshot for the MacBookAir7,2.
>
> Bryan
>
>
>
> OpenBSD 5.8-current (GENERIC.MP) #1667: Thu Nov 26 08:27:08 MST 2015
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> RTC BIOS diagnostic error
> ff
> real mem = 8469352448 (8077MB)
> avail mem = 8208547840 (7828MB)
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afad000 (32 entries)
> bios0: vendor Apple Inc. version "MBA71.88Z.0166.B06.1506051511" date
> 06/05/2015
> bios0: Apple Inc. MacBookAir7,2
> acpi0 at bios0: rev 2
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT
> SSDT SSDT MCFG DMAR
> acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3)
> RP03(S4) ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.32 MHz
> cpu0:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITS
C,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,SENSOR,AR
AT
> 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 100MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
> cpu1 at mainbus0: apid 2 (application processor)
> cpu1: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 MHz
> cpu1:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITS
C,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,SENSOR,AR
AT
> cpu1: 256KB 64b/line 8-way L2 cache
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 1 (application processor)
> cpu2: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 MHz
> cpu2:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITS
C,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,SENSOR,AR
AT
> cpu2: 256KB 64b/line 8-way L2 cache
> cpu2: smt 1, core 0, package 0
> cpu3 at mainbus0: apid 3 (application processor)
> cpu3: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 MHz
> cpu3:
>
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX
,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT
,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITS
C,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,SENSOR,AR
AT
> cpu3: 256KB 64b/line 8-way L2 cache
> cpu3: smt 1, core 1, package 0
> ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
> acpiec0 at acpi0
> acpimcfg0 at acpi0 addr 0xe000, bus 0-155
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus -1 (PEG0)
> acpiprt2 at acpi0: bus 1 (RP01)
> acpiprt3 at acpi0: bus 2 (RP02)
> acpiprt4 at acpi0: bus 3 (RP03)
> acpiprt5 at acpi0: bus 5 (RP05)
> acpiprt6 at acpi0: bus 4 (RP06)
> acpicpu0 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33),
> C1(1000@1 mwait.1), PSS
> acpibat0 at acpi0: BAT0 model "3545797981023400290" type
> 3545797981528607052 oem "3545797981528608836"
> acpiac0 at acpi0: AC unit online
> acpibtn0 at acpi0: LID0
> acpibtn1 at acpi0: PWRB
> acpibtn2 at acpi0: SLPB
> acpivideo0 at acpi0: IGPU
> acpivout0 at acpivideo0: DD01
> 

Re: The kernels of *BSD include nonfree firmware blobs?

[Eduardo Meyer]

On Fri, Nov 27, 2015 at 6:35 PM, bofh  wrote:

> Do you understand your question has been answered over and over again, and
> is not relevant here?
>
> Why do you continue by asking about blobs in FreeBSD?
>

My guess is, he has a Nero syndrom and is just trying to light a fire, but
nobody other than Theo seem to be patient enough or likely wanting to to
bring up some gas.

Dear français, respectfully, you should ask FreeBSD related stuff like that
on FreeBSD's misc and should ask IBM, Red Hat and Canonical (or any any
other relevant Linux system, including Google's) how acurate this statement
looks nowadays. You would get a much more interesting discussion, but
please ask it in the proper lists, individually.

--
===
Eduardo Meyer
pessoal: dudu.me...@gmail.com
profissional: ddm.farmac...@saude.gov.br

Re: Install snapshot failes

[Stefan Sperling]

On Fri, Nov 27, 2015 at 09:22:53PM +0100, Carsten Kunze wrote:
> Only install58.fs itself did boot so there is only the dmesg if the standard 
> installer image. That doesn't use softraid.
> 
> As suggested I wait for the next snapshot. If the issue with installboot is 
> still there I'll send a dmesg.

OK, thanks!

The softraid problems should be fixed in HEAD now.
It's just unclear if your problem was caused by something else.

Request for a package & a feature

[Loïc BLOT]

Hello @misc
this evening i would thanks all OpenBSD team for their great OS for
Security & Networking. I'm using OpenBSD as a router at home on my
Orange FTTH link and it works great.

As an improvement i would request developpers/ports maintainer three
features:

1. On every OpenBSD i need to make a kernel patch to set the vlan
priority on my PPPoE packets (because of orange restrictions using a
custom priority on PPPoE instead of standard). I looked at the code and
pf.prio is only used on ICMP & TCP as i see. Is this possible to extend
to PPPoE ? This could be great.

Orange has now PPPoE but provide DHCPv4 + DHCPv6/PD feature to connect
to their network as a replacement (it's in test ATM but available now
for somes who use a custom router, instead of the Livebox). I see two
missing things in OpenBSD embedded tools
2. isc-dhcp-client package provide the feature permitting to add custom
options when using dhclient. Is this possible to have a such feature in
the base dhclient instead of having only some restricted features ?

3. OpenBSD doesn't have a DHCPv6/PD client and It's commonly used by
operators. Also, dibbler is not available in ports, whereas it works
perfect if you add a little portability patch to fix some paths
/var/lib => /var/db . Is this possible to import dibbler in ports tree
for next OpenBSD release, or if you get some time to have a DHCPv6/PD
OpenBSD tool (with custom options :D) ?

Thanks for reading
-- 
Best regards,
Loïc BLOT, 
UNIX systems, security and network engineer
http://www.unix-experience.fr

athn0: device timeout

[bluesun08]

Hi,

i have a TP-Link TL-WN722N Wlan-Stick.

dmesg says: athn0: AR9271 rev 1 (1T1R), ROM rev 13, address
c4:e9:84:dc:44:ba

But after booting i get the following error message and the stick don't work
any more:

athn0: device timeout

What could be the problem here?






--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/athn0-device-timeout-tp283934.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: Install snapshot failes

[Stefan Sperling]

On Fri, Nov 27, 2015 at 03:05:07PM +0100, Carsten Kunze wrote:
> Hello,
> 
> installing a todays amd64 snapshot with image install58.fs ends with 
> "installboot: No blocks to load". What can be the problem?
> 
> Carsten
> 

Carsten, a dmesg please, *every time* you report an issue.
We need to know how your system is set up and dmesg output will
usually tell us what we need to know.

In this particular case I would like to know if you're booting off
softraid or not. A dmesg would have told me.

Re: The kernels of *BSD include nonfree firmware blobs?

[bofh]

Do you understand your question has been answered over and over again, and
is not relevant here?

Why do you continue by asking about blobs in FreeBSD?

Re: Install snapshot failes

[Carsten Kunze]

Hi Stefan,

> Carsten, a dmesg please, *every time* you report an issue.
> We need to know how your system is set up and dmesg output will
> usually tell us what we need to know.
> 
> In this particular case I would like to know if you're booting off
> softraid or not. A dmesg would have told me.

the sysem doesn't boot since there is no boot block.

Only install58.fs itself did boot so there is only the dmesg if the standard 
installer image. That doesn't use softraid.

As suggested I wait for the next snapshot. If the issue with installboot is 
still there I'll send a dmesg.

Carsten

Re: Request for a package & a feature

[Michael McConville]

Loïc BLOT wrote:
> 3. OpenBSD doesn't have a DHCPv6/PD client and It's commonly used by
> operators. Also, dibbler is not available in ports, whereas it works
> perfect if you add a little portability patch to fix some paths
> /var/lib => /var/db . Is this possible to import dibbler in ports tree
> for next OpenBSD release, or if you get some time to have a DHCPv6/PD
> OpenBSD tool (with custom options :D) ?

Does the wide-dhcpv6 port do what you want?

Re: startx fail on Lenovo G50-80 amd64

[Doug Hogan]

On Fri, Nov 27, 2015 at 09:47:23AM +, freeu...@ruggedinbox.com wrote:
> I installed OpenBSD 5.8 on USB flash memory. It's fine:)
> Then Lenovo G50-80 could booting. but, startx fail and xdm was fail.

I would focus on startx.

> 1.background is blank(black) screen, mouse icon(X and arrow) couldn't move.

Was there an error message in the console about the mouse?

> 3.X will draw window manager's background, but behave was strange.

What WM are you using?

> 5.couldn't get X.0.log

If you startx, let it load and then either kill it or switch back to the
console, does it show any errors?  Are there any /var/log/Xorg.*.log
files?

> dmesg|grep drm:

Could you post the full dmesg?  In our dmesg archive, I see someone
report that their Lenovo G50-80 works more than your report indicates.
However, theirs didn't load inteldrm properly and yours did.  I can't
compare the two dmesgs since you snipped it.

> xorg.conf:

Can you try it without a xorg.conf file?  It's usually not necessary.
In general, try to make things simpler to debug by using startx, no
xorg.conf file, a simple WM like cwm and try to find a way to get us a
log file or error message.

If possible, could you try installing an amd64 snapshot from tomorrow to
see if it was fixed between 5.8 and -current?

Re: OpenBSD as a pentester PC?

[Mohammad BadieZadegan]

Thanks so much Bryan,
Maybe the important tools for every pentesters are:

1. Metasploit
2. Fuzzers (ex. Spike, Sulley,..)

You can download Spike fuzzer source at
https://www.immunitysec.com/downloads/SPIKE2.9.tgz
Thanks alot, Regards.

On Thu, Nov 26, 2015 at 4:04 PM, Bryan Everly 
wrote:

> I have been slowly trying to add such tools to the ports tree. If you
> can give me a list of the ones you are interested in from most
> important to least I will see what I can do.
>
> Thanks,
> Bryan
>
> > On Nov 26, 2015, at 4:50 AM, Mohammad BadieZadegan 
> wrote:
> >
> > Hi every OpenBSD user,
> > I have OpenBSD on my Notebook since 2 years ago and I don't want to
> switch
> > other OS for my business pentest project.
> > I need some pentest tools for my project like metasploit, fuzzers, ..etc
> > but I could not find them on OpenBSD package list
> > !
> > By default does OpenBSD support metasploit installing (or any attack
> tools)
> > or defer them for security purpose?
> > I want to have one OS on my note book for all purpose(business+home).
> > Is that I must switch to other OS? (That I don't like at all!)
> > Regards.
> >
> > --
> > [image: ( openbsd.pro  933k.ir )] 
> >
>



-- 
[image: ( openbsd.pro  933k.ir )] 

Re: can't boot from USB3.0 flash memory

[Ville Valkonen]

gmail didn't show any attachment.
On Nov 27, 2015 3:20 PM, "Tati Chevron"  wrote:

> On Fri, Nov 27, 2015 at 02:31:32PM +0200, Ville Valkonen wrote:
>
>> On 26 November 2015 at 15:26,  wrote:
>>
>> I have USB3.0 flash memory.(SANDISK)
>>> "OpenBSD 5.8 amd64/i386 on USB3.0"
>>>
>>> 1.USB3.0 flash memory connect to USB2.0/1.0
>>> boot: It's fine.
>>> 2.USB3.0 flash memory connect to USB3.0
>>> boot: can't boot!
>>>
>>> anyone don't need boot from USB3.0?
>>>
>>>
>> Hi,
>>
>> do you happen to have an HP machine?
>>
>
> Didn't you read the attached dmesg?
>
> --
> Tati Chevron
> Perl and FORTRAN specialist.
> SWABSIT development and migration department.
> http://www.swabsit.com

Re: can't boot from USB3.0 flash memory

[Tati Chevron]

Didn't you read the attached dmesg?

On Fri, Nov 27, 2015 at 04:44:11PM +0200, Ville Valkonen wrote:

gmail didn't show any attachment.


That's funny, I didn't receive it either.

It's almost as if there wasn't a dmesg attached, isn't it?

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: can't boot from USB3.0 flash memory

[Christoph R. Murauer]

See http://www.openbsd.org/mail.html

*The only mailing list that allows attachments is the ports list, they
will be removed from messages on the other mailing lists.*


> gmail didn't show any attachment.
> On Nov 27, 2015 3:20 PM, "Tati Chevron"  wrote:
>
>> On Fri, Nov 27, 2015 at 02:31:32PM +0200, Ville Valkonen wrote:
>>
>>> On 26 November 2015 at 15:26,  wrote:
>>>
>>> I have USB3.0 flash memory.(SANDISK)
 "OpenBSD 5.8 amd64/i386 on USB3.0"

 1.USB3.0 flash memory connect to USB2.0/1.0
 boot: It's fine.
 2.USB3.0 flash memory connect to USB3.0
 boot: can't boot!

 anyone don't need boot from USB3.0?


>>> Hi,
>>>
>>> do you happen to have an HP machine?
>>>
>>
>> Didn't you read the attached dmesg?
>>
>> --
>> Tati Chevron
>> Perl and FORTRAN specialist.
>> SWABSIT development and migration department.
>> http://www.swabsit.com

Re: Wireless PCI hardware

[Kevin Chadwick]

> >I want OpenBSD in hostap mode with PCI or PCIe ath / athn driver.  
> 
> Be aware that hostap mode is not particularly reliable, usable, or with
> good peformance at the moment.

What does at the moment mean?

I've only just upgraded to 5.8 and I did notice whatsapp not being
quite so snappy but 5.6 seemed (no real testing) both reliable and
usable for us?

-- 

KISSIS - Keep It Simple So It's Securable

startx fail on Lenovo G50-80 amd64

[freeunix]

I installed OpenBSD 5.8 on USB flash memory. It's fine:)
Then Lenovo G50-80 could booting. but, startx fail and xdm was fail.

1.background is blank(black) screen, mouse icon(X and arrow) couldn't 
move.

2.XDM: put username and password on keyborad. can login.
3.X will draw window manager's background, but behave was strange.
4.Open xterm. no drawing terminal window. just input "halt -p" on 
keyboard.

It work.
5.couldn't get X.0.log

before mailing list disscuss "startx fail on Lenovo G50-70 amd64",
but no meaningful answer.

dmesg|grep drm:
inteldrm at pci0 dev 2 function 0 "Intel HD Graphics 5500" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1366x768
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)

xorg.conf:
#video driver
Driver "Intel" #or "vesa"
BusID "PCI:0:2:0"

#screen
Depth 16 #or 24
Modes "1366x768" #or "1360x768"

Re: Install from snapshot unable boot

[Antoine Jacoutot]

On Fri, Nov 27, 2015 at 08:58:33AM +0100, Rolf Sommerhalder wrote:
> The current snapshot fails to install from .iso at the very last step
> at writing the boot info to disk on VirtualBox.
> 
> http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/i386/BUILDINFO
> Build date: 1448569476 - Thu Nov 26 20:24:36 UTC 2015
> 
> Using "the same procedure", install from an older i386 snapshot from 5
> Nov 2015, followed by an update to the current snapshot using bsd.rd,
> works as usual.

Yeah, that's because of pledge(2):
installboot(19095): syscall 54 "ioctl"

-- 
Antoine

Install from snapshot unable boot

[Rolf Sommerhalder]

The current snapshot fails to install from .iso at the very last step
at writing the boot info to disk on VirtualBox.

http://mirror.switch.ch/ftp/pub/OpenBSD/snapshots/i386/BUILDINFO
Build date: 1448569476 - Thu Nov 26 20:24:36 UTC 2015

Using "the same procedure", install from an older i386 snapshot from 5
Nov 2015, followed by an update to the current snapshot using bsd.rd,
works as usual.

Re: Install from snapshot unable boot

[Rolf Sommerhalder]

On Fri, Nov 27, 2015 at 9:01 AM, Antoine Jacoutot  wrote:
> Yeah, that's because of pledge(2):
> installboot(19095): syscall 54 "ioctl"

Thank for your confirmation. I did not spot the error message above,
but saw a commit from Theo last night related to installboot. So I
thought this might be connected, and maybe relevant feedback.

Re: Wireless PCI hardware

[Alexander Salmin]

On 2015-11-27 08:48, Tati Chevron wrote:

On Fri, Nov 27, 2015 at 12:08:37AM +0100, Alexander Salmin wrote:

I want OpenBSD in hostap mode with PCI or PCIe ath / athn driver.


Be aware that hostap mode is not particularly reliable, usable, or with
good peformance at the moment.


That's OK, my purpose is not production.

- TP-Link TL-WN851ND


Works on OpenBSD.

I also got information off-list that also TP-Link TL-WN881ND works well.
I found a store which has both of them, so I'll go buy these today and see.

Thanks everyone.

Alexander

Re: Install from snapshot unable boot

[Theo Buehler]

On Fri, Nov 27, 2015 at 09:12:11AM +0100, Rolf Sommerhalder wrote:
> On Fri, Nov 27, 2015 at 9:01 AM, Antoine Jacoutot  
> wrote:
> > Yeah, that's because of pledge(2):
> > installboot(19095): syscall 54 "ioctl"
> 
> Thank for your confirmation. I did not spot the error message above,
> but saw a commit from Theo last night related to installboot. So I
> thought this might be connected, and maybe relevant feedback.
> 

To be able to pledge installboot as it currently stands, two ioctl's
would need to be whitelisted in pledge "disklabel".  I don't know if
this would be an acceptable policy, though.  Tested on amd64, FWIW:

$ /usr/bin/doas installboot -v sd1
Password:
Using / as root
installing bootstrap on /dev/rsd1c
using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
sd1: softraid volume with 1 disk(s)
sd1: installing boot loader on softraid volume
/usr/mdec/boot is 5 blocks x 16384 bytes
sd0a: installing boot blocks on /dev/rsd0c, part offset 144
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 625137281
/usr/mdec/biosboot will be written at sector 64
$

Index: sys/kern/kern_pledge.c
===
RCS file: /var/cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.124
diff -u -p -r1.124 kern_pledge.c
--- sys/kern/kern_pledge.c  25 Nov 2015 15:53:01 -  1.124
+++ sys/kern/kern_pledge.c  27 Nov 2015 09:21:08 -
@@ -1178,7 +1178,9 @@ pledge_ioctl(struct proc *p, long com, s
case DIOCGPDINFO:
case DIOCRLDINFO:
case DIOCWDINFO:
+   case BIOCDISK:
case BIOCINQ:
+   case BIOCINSTALLBOOT:
case BIOCVOL:
if (fp->f_type == DTYPE_VNODE &&
((vp->v_type == VCHR &&