Re: poudriere: 12-STABLE install fails after r344230

2019-02-18 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Mon, 18 Feb 2019 08:06:54 +0100
"O. Hartmann"  schrieb:

> On Sun, 17 Feb 2019 19:07:53 +0100
> "O. Hartmann"  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Hello,
> > 
> > after the bump of 12-STABE to 1200503 I'm unable to update AMD64 poudriere
> > jails's to this version anymore! Now I run on every box into this error:
> > 
> > [...]
> > 
> > install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> > libnandfs.a /pool/poudriere/jails/12-amd64/usr/lib/ --- _INCSINS ---
> > install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> > libnandfs.h /pool/poudriere/jails/12-amd64/usr/include/ --- _libinstall ---
> > install: libnandfs.a: No such file or directory
> > *** [_libinstall] Error code 71
> > 
> > make[5]: stopped in /pool/sources/12-STABLE/src/lib/libnandfs
> > 
> > For arm64.aarch64 jails with the same build environment this error doesn't
> > show up! The base host is running CURRENT.
> >  
> > What the ... has this libnandfs.a to do?
> > 
> > Since I build 12-STABLE on CURRENT, I use sources
> > at  /pool/sources/12-STABLE/src and I also
> > utilize /usr/local/etc/poudriere.d/12-amd64-poudriere.conf with one line
> > 
> > export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/
> > 
> > to reflect the build tree.
> > 
> > This worked prior to 12-STABLE r344234, it still worls when building and
> > installing for arm64.aarch64 (same host, same CURRENT, same 12-STABLE
> > revision).
> > 
> > How to fix this?
> > 
> > Thanks in advance,
> > 
> > oh
> >   
> [...]
> 
> It seems that the issue occurs on CURRENT. Boxes running 12-STABLE (r344158) 
> or
> 12.0-RELENG (r344247) do not show the problem shown above.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I started again on recent CURRENT (FreeBSD 13.0-CURRENT #190 r344259: Mon Feb 
18 17:48:28 CET
2019 amd64). The sources are located at 

/pool/source/12-STABLE/src

and /usr/local/etc/poudriere.d/poudriere.conf has

export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/

and doing a fresh start, /pool/sources/12-STABLE/obj and its subtrees has been 
deleted.

The name of my 12-STABLE jail is 12-amd64 and therefore, I build the world of 
that jail
by myself from sources located in /pool/sources/12-STABLE/src and build by 
src.conf common to
poudriere and the build process (to keep them in sync):

/usr/local/etc/poudriere.d/12-amd64-src.conf:

[...]
WITH_CLANG_EXTRAS=  YES
WITH_LLDB=  YES
#
#WITH_BSD_GREP= YES
#
#WITH_OFED_EXTRA=YES
#WITH_NAND=  YES
#WITH_CTF=  YES
#
#WITH_SVN=   YES
#
# Enable building openldap support for kerberos.
#WITH_OPENLDAP= YES
#
#WITH_SORT_THREADS=  YES
#
#WITH_EXTRA_TCP_STACKS= YES
#
#WITH_ZONEINFO_LEAPSECONDS_SUPPORT=  YES
#
MALLOC_PRODUCTION=  YES
#
WITHOUT_ASSERT_DEBUG=   YES
#
WITHOUT_DEBUG_FILES=YES
#
WITHOUT_TESTS=  YES
#
WITHOUT_PROFILE=YES
#
#WITHOUT_REPRODUCIBLE_BUILD= YES
#
#  mitigation for CVE-2017-5715 in the kernel build
#WITH_KERNEL_RETPOLINE= YES
[...]

I use those configs also for PKGbase repos, for which the poudriere packages 
should be built.

Now, with a almost vanilla setup, poudriere runs into weird erros different 
from the initial
reportd; first error now occuring see below;

I'm loosing hair over this; installing  poudriere jails from network/internet 
resources is no
option in the isolated environment I have to build things, so I felt really 
comfortable having
such a great opportunity of building my own bindaries from sources for repos 
and poudriere
jails from the very same source. Obviously, this is highly unstable.


Is this considered a bug or is it in general unsupported and "worked by 
accident"?

Regards,

oh
[...]
- --- realinstall_subdir_usr.sbin ---
- --- installdirs-FILESDIR ---
- --- realinstall_subdir_usr.bin ---
- --- _proginstall ---
install -N /pool/sources/12-STABLE/src/etc  -s -o root -g wheel -m 555
bugpoint /pool/poudriere/jails/12-amd64/usr/bin/bugpoint install: bugpoint: No 
such file or
directory 
*** [_proginstall] Error code 71

make[6]: stopped in /pool/sources/12-STABLE/src/usr.bin/clang/bugpoint
1 error

make[6]: stopped in /pool/sources/12-STABLE/src/usr.bin/clang/bugpoint

- --- realinstall_subdir_usr.sbin ---
installing DIRS FILESDIR
install -N /pool/sources/12-STABLE/src/etc  -d -m 075

Re: poudriere: 12-STABLE install fails after r344230

2019-02-17 Thread O. Hartmann
On Sun, 17 Feb 2019 19:07:53 +0100
"O. Hartmann"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hello,
> 
> after the bump of 12-STABE to 1200503 I'm unable to update AMD64 poudriere
> jails's to this version anymore! Now I run on every box into this error:
> 
> [...]
> 
> install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> libnandfs.a /pool/poudriere/jails/12-amd64/usr/lib/ --- _INCSINS ---
> install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
> libnandfs.h /pool/poudriere/jails/12-amd64/usr/include/ --- _libinstall ---
> install: libnandfs.a: No such file or directory
> *** [_libinstall] Error code 71
> 
> make[5]: stopped in /pool/sources/12-STABLE/src/lib/libnandfs
> 
> For arm64.aarch64 jails with the same build environment this error doesn't
> show up! The base host is running CURRENT.
>  
> What the ... has this libnandfs.a to do?
> 
> Since I build 12-STABLE on CURRENT, I use sources
> at  /pool/sources/12-STABLE/src and I also
> utilize /usr/local/etc/poudriere.d/12-amd64-poudriere.conf with one line
> 
> export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/
> 
> to reflect the build tree.
> 
> This worked prior to 12-STABLE r344234, it still worls when building and
> installing for arm64.aarch64 (same host, same CURRENT, same 12-STABLE
> revision).
> 
> How to fix this?
> 
> Thanks in advance,
> 
> oh
> 
[...]

It seems that the issue occurs on CURRENT. Boxes running 12-STABLE (r344158) or
12.0-RELENG (r344247) do not show the problem shown above.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: What is evdev and autoloading?

2019-02-17 Thread O. Hartmann
On Sun, 17 Feb 2019 18:35:25 -0800 (PST)
"Rodney W. Grimes"  wrote:

> > On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote:  
> > > 
> > > 
> > > On 2019-Feb-17, at 10:03, Steve Kargl  > > troutmask.apl.washington.edu> wrote:
> > > 
> > > Anyone have insight into what evdev is?  There appears to
> > > be no manual page.  When I reboot a system with custom
> > > kernel, the system is autoloading evdev.ko, uhid.ko, and
> > > wmt.ko.  I do not need nor what these modules loaded.
> > > How does one prevent this autoloading?
> > > 
> > > Looking via the web lead to:  
>  ^^^
> web lies
> 
> > > 
> > > https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html
> > > So:
> > > 
> > > NAME
> > >evdev - Generic Linux input driver
> > > 
> > > DESCRIPTION
> > > 
> > >   evdev is an Xorg input driver for Linux's generic event devices.
> > > It therefore supports all input  devices  that  the kernel knows
> > > about, including most mice, keyboards, tablets and touchscreens. evdev
> > >   is the default driver on the major Linux distributions.
> > > . . .
> > > 
> > > 
> > > 
> > > but it seems to not have a 13-current entry. It does have
> > > a 12.0-RELEASE entry.
> > >   
> > 
> > Thanks.  Kinda odd that freebsd-current doesn't have a manual
> > page, but FreeBSD-12 does.  
> 
> rgrimes@t400:~ % man evdev
> No manual entry for evdev
> rgrimes@t400:~ % man -k evdev
> apropos: nothing appropriate
> rgrimes@t400:~ % uname -a
> FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC  amd64
> rgrimes@t400:~ % 
> There is no man page for evdev in 12.0-RELEASE
> 
> > 
> > I have a wireless logitech mouse.  It seems that the
> > wireless USB dongle is causing the load of the modules.
> > I still understand why as ums(4) does not should a 
> > dependency on uhid, wmt, or evdev.
> >   
> 

Nor 12-STABLE:

root@freyja:/usr/src # man -k evdev
apropos: nothing appropriate

FreeBSD 12.0-STABLE #290 r344158: Fri Feb 15 14:42:58 CET 2019 amd64

Kind regards,

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


poudriere: 12-STABLE install fails after r344230

2019-02-17 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

after the bump of 12-STABE to 1200503 I'm unable to update AMD64 poudriere 
jails's to this
version anymore! Now I run on every box into this error:

[...]

install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
libnandfs.a /pool/poudriere/jails/12-amd64/usr/lib/ --- _INCSINS ---
install -N /pool/sources/12-STABLE/src/etc  -C -o root -g wheel -m 444
libnandfs.h /pool/poudriere/jails/12-amd64/usr/include/ --- _libinstall ---
install: libnandfs.a: No such file or directory
*** [_libinstall] Error code 71

make[5]: stopped in /pool/sources/12-STABLE/src/lib/libnandfs

For arm64.aarch64 jails with the same build environment this error doesn't show 
up!
The base host is running CURRENT.
 
What the ... has this libnandfs.a to do?

Since I build 12-STABLE on CURRENT, I use sources at  
/pool/sources/12-STABLE/src and I also
utilize /usr/local/etc/poudriere.d/12-amd64-poudriere.conf with one line

export  MAKEOBJDIRPREFIX=/pool/sources/12-STABLE/obj/

to reflect the build tree.

This worked prior to 12-STABLE r344234, it still worls when building and 
installing for
arm64.aarch64 (same host, same CURRENT, same 12-STABLE revision).

How to fix this?

Thanks in advance,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXGmjFAAKCRA4N1ZZPba5
R0eHAQCtf7b9dOncz31poSGGkuKqVK4E3ENMi3c1PdQ3vnAK4QEAxhQSEDhSd8bN
mO9uAFCdhAFZbCXNp4w8h69kJgn8ZwY=
=x3pa
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: icmp (IPv4) issues with VIMAGE JAILs and IPv6

2019-01-31 Thread O. Hartmann
On Tue, 29 Jan 2019 11:36:37 +0300
"Andrey V. Elsukov"  wrote:

> On 28.01.2019 15:44, O. Hartmann wrote:
> > Stopping all jails, destroying all epairs and bridge0 doesn't change
> > anything. The problems occured when IPv6 came into play on the specific
> > host in question.
> > 
> > Does anyone have any ideas? I'm out of ideas.  
> 
> Hi,
> 
> I think I found the problem, the bug was introduced in r342908.
> Can you try attached patch?
> 

Sorry for responding so late.

Thank you for digging into this problem - and finally having resolved it!
Great. After the patch has been apllied, the system worked as expected.

Thanks a lot.


Regards,
Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


syslogd: using IPv6 as hostnames results in "IP mismatch"

2019-01-31 Thread O. Hartmann
Hello out there.

I'm using some dual stack installations and I'd like to configure FreeBSD's
(CURRENT at the moment) syslogd on a syslog-server to handle incoming logging
messages from remote FBSD boxes (mixed, 11.2, 12.0 and CURRENT).

I' facing a very weird situation.

Scenario:

The server has IPv6 fdff:dead:beef::faaf and IP 192.168.168.200.
The test client has IPv6 fdff:dead:beef:: and IP 192.168.168.2.

On the syslog server:

The syslog server's syslogd is configured as (etc/rc.conf):

syslogd -C -v -v -b [fdff:dead:beef::faaf]:514 -b 192.168.168.200:514 \
-a [fdff:dead:beef::]/48:* -a 92.168.168.0/24:*

It's /etc/syslog.conf file contains the following line to make syslogd
receiving syslog messages from the specified client and log those messages in a
separate file (/usr/local/etc/syslog.d/host_X.conf):

+[fdff:dead:beef::],192.168.168.2
*.* /var/log/hosts/host_a.log


On the client (IPv6 fdff:dead:beef:: and IP 192.168.168.2), syslogd
(/etc/rc.conf) is configured via

syslogd -C -v -v -s

and it is configured to log additinaly all messages to the server
via /usr/local/etc/syslog.d/logging.conf:

*.* @[fdff:dead:beef::faaf]
!*

I trigger then a log incident on the client via "logger < /dev/random".

This scenario doens't work - putting syslogd on the server into debug mode, via
adding option -d, the log message from the client is received, but rejected:

[...]
# of validation rule: 2
validate: dgram from IP ffdff:dead:beef::, port 514, name \
  fdff:dead:beef::; 
rejected in rule 1 due to IP mismatch. 
rejected in rule 2 due to address family mismatch. 
Message from fdff:dead:beef:: was ignored.received sa_len = 28 
cvthname(28) len = 28 
cvthname(fdff:dead:beef::)
# of validation rule: 2

While the manpage syslog.onf(5) is specific how to use IPv6 addresses in the
"action" field, preceeded by "@", I've no doubt of the ciorrectnes of the
client's syntax, *.* @[fdff:dead:beef::faaf].

But it seems ambiguous when it comes to the part of the hostname on the
server's side, when prepending the "hostname/program" portion with a "+" when
it comes to IPv6.

If switching the config on the client to:

*.* @192.168.168.200
!*

does let syslogd on the server log the message as expected:

[...]
# of validation rule: 2
validate: dgram from IP 192.168.168.2, port 514, name 192.168.168.2;
rejected in rule 1 due to address family mismatch.
accepted in rule 2.
logmsg: pri 15, flags 0, from 192.168.168.2, msg ��q^Bǩ�^CM-^L
�*^_B�^LM-^A?^L�i[^R�5QM-^MRLvM-^FA}bM-^Y�F��^N�C�M-^\��b�^?�NM-^G-�ޠ��M-^[ƾ44��^V�zݣ}a�B�'M-^^^G�P��g^H�cM-^@J7xg\A��.��M-^UC7o^V���^Ax�^G�\
<^A.#�ns�KwV^N�^ZZ��Ϻ�M-^X�zM-^N^U�M-^Ys2smW^G^S^U�M-^G�<'~�7�^HFz�>DM-^T�V~8^^vW1��^K[�^\i^P�"M-^G�Q�(�m%{M-^@M-
^H�M-^Q�^Q�nW�Y(CT@_/�`�cM-^Nv 
Logging to FILE /var/log/hosts/host_a.log 
received sa_len = 16 
cvthname(2) len = 16 
cvthname(192.168.168.2)
# of validation rule: 2

I also tried on the server's config to avoid the brackets ("[]"),

+fdff:dead:beef::,192.168.168.2
*.* /var/log/hosts/host_a.log

but that seems illogical and it results in the same IP mismatch as reported
further above. 

If it isn't a bug, please point me to the mistake.

Thanks in advance,

oh

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


icmp (IPv4) issues with VIMAGE JAILs and IPv6

2019-01-28 Thread O. Hartmann
I ran into severe problems on CURRENT ( FreeBSD 13.0-CURRENT #193
r343521: Mon Jan 28 10:26:36 CET 2019 amd64), VIMAGE enabled host with jails
utilizing IPv6.

Scenario:

The main host has two Braodcom (bce0|1) NICs. bce0 is the physical NIC attached
to a routed/switched network for the main host. bce1 is also attached
to the same network, but via another port on the switch (Cisco). Gatewaying is
not allowed on the main host. bce1 is also member of bridge0. The main host
hosts a bunch of  vnet/VIMAGE jails (~12): each jail has its "epair" pseudo
NIC, of which the a-part (epairXXa) is owned by the jail and the b-part is
member of the bridge0. NIC bce1 ensures the connection to the physical network.

On all hosts IPV6 is enabled. All host use an ULA IPV6 address. All hosts and
jails use FreeBSD's native IPFW as their IP filter. bridge0 is configured to
not filter on Level 2 (ethernet). IPFW is configured on each jail via rc.conf
and script "WORKSTATION". For example, services are allowed by the
rc.conf-line:

(main host)
firewall_type="WORKSTATION"
firewall_myservices="22/tcp 53/udp 80/tcp 443/tcp ..."
firewall_allowservices="192.168.255.0/24 fdff:dead:beef::/48"
firewall_trusted="192.168.255.2 fdff:dead:beef::34 ..."

and similar for the jails.

Problem:

I can not ping (icmp IPv4) any jail from the main host, any host on the regular
internet (i.e. google.de/google.com and so on) or any jail, nor can I ping from
inside a jail any host or other jail. Since we use some ICINGA2 facilities,
pinging is essential.

The weird part: ping6 is working perfectly! Alos, any non-ICMPv4 connection is
performed well (ssh, http-80, http-443, NFS via 2049 and so on).

Disabling IPFW or switch to "OPEN" on a jail or the main host makes things work
again. 

A very similar setup on a host without jails, using also rc.conf for
configuring the IPFW paketfilter doesn't reveal such a misbehaviour.

The ruleset on a JAIL with ipfw script "WORKSTATION" configured, which is NOT
working (icmp doesn't work as expected), looks like this:

[...]
 service ipfw restart
Flushed all rules.
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
00400 deny ip from any to ::1
00500 deny ip from ::1 to any
00600 allow ipv6-icmp from :: to ff02::/16
00700 allow ipv6-icmp from fe80::/10 to fe80::/10
00800 allow ipv6-icmp from fe80::/10 to ff02::/16
00900 allow ipv6-icmp from any to any icmp6types 1
01000 allow ipv6-icmp from any to any icmp6types 2,135,136
0 check-state :default
01200 allow tcp from me to any established
0 allow tcp from me to any setup keep-state :default
0 allow udp from me to any keep-state :default
0 allow icmp from me to any keep-state :default
0 allow ipv6-icmp from me to any keep-state :default
01700 allow udp from 0.0.0.0 68 to 255.255.255.255 67 out
01800 allow udp from any 67 to me 68 in
01900 allow udp from any 67 to 255.255.255.255 68 in
02000 allow udp from fe80::/10 to me 546 in
02100 allow icmp from any to any icmptypes 8
02200 allow ipv6-icmp from any to any icmp6types 128,129
02300 allow icmp from any to any icmptypes 3,4,11
02400 allow ipv6-icmp from any to any icmp6types 3
02500 allow tcp from 192.168.255.0/24 to me 22
02600 allow tcp from 192.168.255.0/24 to me 80
02700 allow tcp from 192.168.255.0/24 to me 443
02800 allow tcp from fdff:dead:beef::/48 to me 22
02900 allow tcp from fdff:dead:beef::/48 to me 80
03000 allow tcp from fdff:dead:beef::/48 to me 443
65000 count ip from any to any
65100 deny { tcp or udp } from any to any 135-139,445 in
65200 deny { tcp or udp } from any to any 1026,1027 in
65300 deny { tcp or udp } from any to any 1433,1434 in
65400 deny ip from any to 255.255.255.255
65500 deny ip from any to 224.0.0.0/24 in
65500 deny udp from any to any 520 in
65500 deny tcp from any 80,443 to any 1024-65535 in
65500 deny ip from any to any
Firewall rules loaded.
[...]

I can not see the problem here in the configuration :-(

On the main host (owner of bce1 and bridge0), net.link.bridge looks like:

# sysctl net.link.bridge
net.link.bridge.ipfw: 0
net.link.bridge.allow_llz_overlap: 0
net.link.bridge.inherit_mac: 1
net.link.bridge.log_stp: 1
net.link.bridge.pfil_local_phys: 0
net.link.bridge.pfil_member: 0
net.link.bridge.ipfw_arp: 0
net.link.bridge.pfil_bridge: 0
net.link.bridge.pfil_onlyip: 0


Stopping all jails, destroying all epairs and bridge0 doesn't change anything.

The problems occured when IPv6 came into play on the specific host in question.

Does anyone have any ideas? I'm out of ideas.

Thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.

2019-01-21 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Wed, 16 Jan 2019 18:33:36 +0100
Tijl Coosemans  schrieb:

> On Wed, 16 Jan 2019 15:23:40 +0100 "O. Hartmann"  
> wrote:
> > We have an experimental IPV6 network and within this network, FreebSD 
> > CURRENT
> > (r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE
> > boxes are CUPS clients.
> > 
> > The setup, so far, worked with IPv4. Introducing IPv6 addresses on both 
> > server
> > and host results in the error
> > 
> > [Client 1] Unable to encrypt connection: An illegal parameter has been 
> > received.
> > 
> > In file cups/client.conf we address the appropriate printer via
> > 
> > ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host)
> > 
> > This works fine.
> > 
> > But ipps://[::::]/printers/printer_name (IPv6 of the CUPS
> > server host) doesn't work and results in the error on the server as shown 
> > above.
> > 
> > I fiddled also around with the SSLOption parameter in client.conf and 
> > parallel,
> > to match requiremets, in cups/cupsd.conf of the server host - with no 
> > effect.
> > 
> > On the server side, it seems that all the documents I could pick up from
> > cups.org or Apple do not specify any IPv6 address in an "Allow from" 
> > statement:
> > everything seems to be stuck with IPv4. While the cupsd.conf SSLListen 
> > option
> > is for IPv6
> > 
> > SSLListen [fd01:dead:beef::affe]:631
> > 
> > which works, I get an error when trying to put anything IPv6-similar with 
> > the
> > convention with the brackets "[" and "]" in a "Allow from" option in the
> > sections where I need to restrict access. An IPv6 without "[" and "]" seems 
> > to
> > be accepted - but when coemmnting out ANY IPv4 address and leaving only 
> > IPV6 in
> > the "Allow from " statement, no remote connection is allowed.
> > 
> > This drives me nuts. Since the aim will be to have a printing facility 
> > within a
> > IPv6 only network, I feel a bit lost.
> > 
> > Does anyone have had similar problems?  

Hello and my apology for responding so late.

> 
> cupsd.conf(5) does mention "Allow [ipv6-address]" in the section:
> DIRECTIVES VALID WITHIN LOCATION AND LIMIT SECTIONS

I found that, too late, too. The man page is very clear and almost complete on 
that - I
stupidly relied on "internet" findings, which were a bit outdated.

> 
> 
> With client.conf you can configure libcups so it talks to a remote CUPS
> server instead of the local one.  This has been deprecated for years so
> I suspect there hasn't been any development on it and that it simply
> doesn't support IPv6.

Also, I realised that I've inherited config files from ealier installations 
whcih moved
onward on newer setups - so I missed client.conf! Thanks for the hint. After 
deletion of
the file in question, the problems persisted.

> 
> What you're supposed to do instead is run a cupsd on the client and add
> the print server as a network printer (using your ipps URI).  When you
> have to choose the make of the printer choose Raw so you don't need a
> PPD and cupsd will forward the job to the server without doing any
> filtering.  You can set this up on one client and then copy the cups
> configuration in /usr/local/etc/cups to the other clients.  Running a
> local cupsd allows clients to queue print jobs when the print server is
> down.

I had those settings on the client system, too: reference printer is
ipps://host.name/printers/print_queue_name, but not with "RAW" filter. I 
changed that.

While I'm able to print CUPS testpages via the web interface on the CUPS server 
system
itself, I still receive 

[Client 1] Unable to encrypt connection: An illegal parameter has been received.

in the log file on the CUPS server, when the satellite/client system tries to 
connect to
the CUPS print queue.

> 
> Alternatively you can let the print server announce the printer via
> Bonjour/Avahi (Browsing on in cupsd.conf) and run cups-browsed from
> print/cups-filters on the clients which will then detect the print
> server and add a raw print queue automatically.  This can be convenient
> for laptops that move between networks.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für

Re: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)

2019-01-19 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Fri, 18 Jan 2019 14:17:29 -0700
Warner Losh  schrieb:

> On Fri, Jan 18, 2019 at 2:11 PM Emmanuel Vadot 
> wrote:
> 
> > On Fri, 18 Jan 2019 22:50:31 +0300
> > Lev Serebryakov  wrote:
> >  
> > > On 18.01.2019 22:35, Rodney W. Grimes wrote:
> > >  
> > > >>> errm.. you press a key and enter device and or loader path. if it is  
> > not working - the code is there to be fixed.  
> > > >>  And loader looks to "bootme" attribute and try to boot from partition
> > > >> which has one, even if it is loaded from other partition itself.
> > > >>  
> > > >>> GPT does not have the concept of active partition.  
> > > >>  It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't  
> > have  
> > > >> any tools to set these attributes, AFAIK. Same for UEFI boot code.  
> > > >
> > > > The gpart(8) command is used to set/unset these.  
> > >  gpart need booted system. NanoBSD typically have two "system"
> > > partitions, "old" (previous) and "new" (current). After upgrade they
> > > switched (new code is written to "previos" partition and bootable
> > > atteibute is set to it, "active" in case of MBR and "bootme" in case of
> > > GPT).
> > >
> > >   If this new partition has problems and could not be booted, it is hard
> > > to boot from "old" (previous) one. MBR + boot0 could (interactively)
> > > change active partition before system is booted, and this problem could
> > > be solved with one keypress: you select old partition on boot.
> > >
> > > --
> > > // Lev Serebryakov
> > >  
> >
> >  With UEFI Boot* variable you could do :
> >
> >  - Update previous partition and set BootNext to it
> >  - If it fail next boot will be on current partition due to BootOrder
> >  - If it succeed, change the BootOrder to have the new partition first.
> >  
> 
> Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose
> which Boot variable to use to boot. Some will even create new Boot
> variables that they use when you choose a raw device to boot from.
> 
> There's other people that have efi programs that will pop up a menu for you
> to select a particular BootXXXX to use. They then set BootNext and exit.
> I've not used any of these personally.
> 
> But this whole thread tells me we need to rewrite the boot section of our
> handbook.

Oh, yes, please, please!
Thanks in advance!

oh

> 
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXELOUgAKCRA4N1ZZPba5
R7PWAP9zDKuReIghEeO3UNUOPLldsjH0Zr8Ez0DVtaRt0F2WrwD/cWXjOOu5SLD2
NxHq0pKZ5oH0K7NC/4lA45j0Ir9C3wo=
=Y3j1
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


CUPS: [Client 1] Unable to encrypt connection: An illegal parameter has been received.

2019-01-16 Thread O. Hartmann
We have an experimental IPV6 network and within this network, FreebSD CURRENT
(r343087) is acting as a CUPS print server, while a bunch FreeBSD 12-STABLE
boxes are CUPS clients.

The setup, so far, worked with IPv4. Introducing IPv6 addresses on both server
and host results in the error

[Client 1] Unable to encrypt connection: An illegal parameter has been received.

In file cups/client.conf we address the appropriate printer via

ipps://xxx.xxx.xxx.xxx/printers/printer_name (IPv4 of the CUPS server host)

This works fine.

But ipps://[::::]/printers/printer_name (IPv6 of the CUPS
server host) doesn't work and results in the error on the server as shown above.

I fiddled also around with the SSLOption parameter in client.conf and parallel,
to match requiremets, in cups/cupsd.conf of the server host - with no effect.

On the server side, it seems that all the documents I could pick up from
cups.org or Apple do not specify any IPv6 address in an "Allow from" statement:
everything seems to be stuck with IPv4. While the cupsd.conf SSLListen option
is for IPv6

SSLListen [fd01:dead:beef::affe]:631

which works, I get an error when trying to put anything IPv6-similar with the
convention with the brackets "[" and "]" in a "Allow from" option in the
sections where I need to restrict access. An IPv6 without "[" and "]" seems to
be accepted - but when coemmnting out ANY IPv4 address and leaving only IPV6 in
the "Allow from " statement, no remote connection is allowed.

This drives me nuts. Since the aim will be to have a printing facility within a
IPv6 only network, I feel a bit lost.

Does anyone have had similar problems?

Regards,

Oliver

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: kernel panic in wireless-related sysctl walk

2019-01-12 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Thu, 10 Jan 2019 22:22:05 +0100
"O. Hartmann"  schrieb:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Thu, 10 Jan 2019 12:02:15 -0800
> Cy Schubert  schrieb:
> 
> > I'm not able to reproduce this at the moment.
> > 
> >   
> 
> I have a oldish Lenovo R500 Notebook running FreeBSD-12 STABLE. I'm not sure 
> what WiFi
> Interface driver the system is using right now; the WiFi is combined with the 
> NIC to
> form a lagg-interface. I can 100% reproduce the crash described above via 
> "sysctl -a".
> Just in case the phenomenon I discovered shortly after Christmas is of the 
> same source
> as the initial poster has reported, how can I be of help? The system is a 
> "pkg system"
> completely, so I have to switch on debugging without kernel rebuilds. Any 
> advice?
> 
> Kind regards,
> 
> O. Hartmann
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXDe3mAAKCRA4N1ZZPba5
> R27kAQD7rB6h7Y21ycCWxAjYDb98x2k+y/uWsoBCXBfRAvpYswEA7yO9cj7wno8L
> 05KxBEbLbrUjn8cLhowYwe0d14EMeAE=
> =5VUr
> -END PGP SIGNATURE-
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I checked for the problem on last Friday after rebuilding pkgBase with 
12-STABLE - sorry
having not the revision number at hand, it is at work - but after a recent 
update und
trying to bring down the notebook via "sysctl -a" as described didn't work 
anymore. The
driver for an oldish Intel wireless adapter (I can't remember the exact spec, 
its 4500
or 5000 or similar) is iwn.

oh  

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXDm9tQAKCRA4N1ZZPba5
R+4BAQDZ7Z9FrDSQ13ncksBphGPrcT/7pdaaLkXSLntwijUXBwD+LXv0LNOJqIM6
8V6OjgqrH7f5y4BnQK7bnkDE6cegdA8=
=XNpM
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: kernel panic in wireless-related sysctl walk

2019-01-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Thu, 10 Jan 2019 12:02:15 -0800
Cy Schubert  schrieb:

> I'm not able to reproduce this at the moment.
> 
> 

I have a oldish Lenovo R500 Notebook running FreeBSD-12 STABLE. I'm not sure 
what WiFi
Interface driver the system is using right now; the WiFi is combined with the 
NIC to form
a lagg-interface. I can 100% reproduce the crash described above via "sysctl 
-a". Just in
case the phenomenon I discovered shortly after Christmas is of the same source 
as the
initial poster has reported, how can I be of help? The system is a "pkg system"
completely, so I have to switch on debugging without kernel rebuilds. Any 
advice?

Kind regards,

O. Hartmann

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXDe3mAAKCRA4N1ZZPba5
R27kAQD7rB6h7Y21ycCWxAjYDb98x2k+y/uWsoBCXBfRAvpYswEA7yO9cj7wno8L
05KxBEbLbrUjn8cLhowYwe0d14EMeAE=
=5VUr
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: efibootmgr: Cannot translate unix loader path xxx\xxx\xxx to UEFI: No error: 0

2018-12-28 Thread O. Hartmann
On Thu, 27 Dec 2018 08:38:20 -0700
Warner Losh  wrote:

> On Dec 27, 2018 7:42 AM, "O. Hartmann"  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Am Thu, 27 Dec 2018 13:29:44 +0100
> "Hartmann, O."  schrieb:
> 
> 
> > Updated Fujitsu Celsius M740 to its lates UEFI firmware today.
> > After this update, the box won't boot FreeBSD 12-STABLE anymore! With
> > disabled CSM, the firmware doesn't recognise the boot SSD's freebsd-efi
> > partition for UEFI boot anymore - which was no problem before.
> >
> > When trying FreeBSD 13-CURRENT (USB image from 26.12.2018 as of the
> > snapshot site) I receive a malloc arena error when trying to set boot
> > vars via efibootmgr utility. So I tried the recent 12-STABLE snapshot
> > as of 26th December 2018, the same as CURRENT USB Image, and I receive
> > a weird error:
> >
> > efibootmgr -c -l /mnt/EFI/BOOT/BOOTX64.EFI -L FreeBSD
> >
> > efibootmgr: Cannot translate unix loader path
> > '\mnt\EFI\BOOT\BOOTX64.EFI' to UEFI: No error: 0
> >
> > What the heck is that?
> >
> > What does this error mean? No error: 0?
> >
> > The box is unusable.
> >
> >
> > Kind regards,
> >
> > O. Hartmann
> >
> >
> >  
> 
> I found this PR, Bug 229191, from June, 2018:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229191
> 
> It seems the problem has not been fixed. Indeed did I mount the ESP
> via a GEOM label, /dev/gpt/efiboot0.
> 
> 
> There is some code that tries to cope, but I ran out of time before it was
> bulletproof.  You can use nda0p9:/path/in/fs instead. Assuming the esp is
> on /dev/nda0p9.
> 
> Warner
[...]

The workaround (alternative mounting) given in the mentioned PR solved the
problem.

This is the second time I face crude problems with Fujitsu hardware/firmware
and if I wouldn't solved a similar problem this summer for an Esprimo Q956, the
problem would have cost me valuable time. So, my thinking is: couldn't there be
a short paragraph in the handbook?

Regards,

o.h.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: efibootmgr: Cannot translate unix loader path xxx\xxx\xxx to UEFI: No error: 0

2018-12-27 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Thu, 27 Dec 2018 13:29:44 +0100
"Hartmann, O."  schrieb:

> Updated Fujitsu Celsius M740 to its lates UEFI firmware today.
> After this update, the box won't boot FreeBSD 12-STABLE anymore! With
> disabled CSM, the firmware doesn't recognise the boot SSD's freebsd-efi
> partition for UEFI boot anymore - which was no problem before.
> 
> When trying FreeBSD 13-CURRENT (USB image from 26.12.2018 as of the
> snapshot site) I receive a malloc arena error when trying to set boot
> vars via efibootmgr utility. So I tried the recent 12-STABLE snapshot
> as of 26th December 2018, the same as CURRENT USB Image, and I receive
> a weird error:
> 
> efibootmgr -c -l /mnt/EFI/BOOT/BOOTX64.EFI -L FreeBSD
> 
> efibootmgr: Cannot translate unix loader path
> '\mnt\EFI\BOOT\BOOTX64.EFI' to UEFI: No error: 0
> 
> What the heck is that?
> 
> What does this error mean? No error: 0?
> 
> The box is unusable.
> 
> 
> Kind regards,
> 
> O. Hartmann
> 
> 
> 

I found this PR, Bug 229191, from June, 2018:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229191

It seems the problem has not been fixed. Indeed did I mount the ESP
via a GEOM label, /dev/gpt/efiboot0.
- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXCTkaAAKCRA4N1ZZPba5
RwvZAP9tQ8nuYp77A2XB8MLuolpeyBKrO0M79UlnCGfTYlLkOwEArbSpsQ2+aZ0S
I5I1pwuBaTuiV1gJ0E6l4bRxhbUmXgA=
=eYQj
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


bind 9.12.3-P1 dies after change of IP on outbound interface

2018-12-20 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lateley I realise some strange behaviour of the recent dns/bind912 port.

Running named (9.12.3-P1) on a 12-STABLE gateway/router/firewall with outbound 
interface
tun0 to our privider, named seems to crash since the last port upgrade whenver 
the ISP is
changing the IP (using ppp with some linkup/linkdown scripts due to IPv6, 
nothing fancy).

The last sign of live named provides is shown below:

[...]
Dec 20 13:22:46 <3.2> gate named[1120]: socket.c:3251: REQUIRE(sock->references 
== 1)
failed, back trace Dec 20 13:22:46 <3.2> gate named[1120]: #0 0x2c8880 in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #1 0x4b111a in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #2 0x4e35fc in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #3 0x4e9e79 in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #4 0x35554d in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #5 0x354a2f in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #6 0x4d49fa in ??
Dec 20 13:22:46 <3.2> gate named[1120]: #7 0x800dc37c6 in ??
Dec 20 13:22:46 <3.2> gate named[1120]: exiting (due to assertion failure)
Dec 20 13:46:59 <3.5> gate named[3195]: starting BIND 9.12.3-P1 

Prior to the last update of dns/bind912, this router/firewall appliance was 
running more
than a month without having such trouble, even the ISP is randomly changing the 
IPv4/IPv6
addresses spread over the day.

What is wrong?

Kind regards,

O. Hartmann


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXBuVPgAKCRA4N1ZZPba5
RxB8AQDwXm7hVifhDP841aGckXLCCino95lSAtHNLoOz2nBcowD9F4lUyflB/Imq
OvERuSNKeixaDDazKj6KJfNtiE8/0gU=
=H6r2
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


/usr/doc can not be build neither can it be installed

2018-12-18 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello FreeBSD users out there.

My last build and update of /usr/doc was end of May 2017; since then any 
attempt building
the doc from /usr/doc failed on 12-CURRENT to 12-STABLE and now on 13-CURRENT.

I believe all the required ports (following the instructions from fdp-primer 
and other
instructions given by the official web sites providing newest docs) are up to 
date and
the /usr/doc tree is also at its most recent revision (using svn):

# svn info
Path: .
Working Copy Root Path: /usr/doc
URL: https://svn.freebsd.org/doc/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/doc
Repository UUID: c2e8774f-c49f-e111-b436-862b2bbc8956
Revision: 52697
Node Kind: directory
Schedule: normal
Last Changed Author: ryusuke
Last Changed Rev: 52697
Last Changed Date: 2018-12-18 12:49:16 +0100 (Tue, 18 Dec 2018)

Apart from any other language (i.e. German) I'd expect that the en_US version 
would build
at least, but whenever I issue:

cd /usr/doc
make clean
make update
make all

the build ends up in 

[...]

egrep: chapters.ent: No such file or directory
env
XML_CATALOG_FILES="file:///usr/obj/usr/doc/en_US.ISO8859-1/books/handbook/catalog-cwd.xml
file:///usr/doc/en_US.ISO8859-1/share/xml/catalog.xml
file:///usr/doc/share/xml/catalog.xml
file:///usr/local/share/xml/catalog" /usr/local/bin/xmllint --nonet --noent 
--valid
- --dropdtd --xinclude /usr/doc/en_US.ISO8859-1/books/handbook/book.xml >
book.parsed.xml.tmp warning: failed to load external entity
"/usr/doc/en_US.ISO8859-1/books/handbook/mirrors.xml.ftp.index.inc" 
/usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:100:
parser error : Failure to process entity chap.mirrors.ftp.index.inc

^ /usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:100: parser error 
: Entity
'chap.mirrors.ftp.index.inc' not defined  ^ 
warning: failed
to load external entity
"/usr/doc/en_US.ISO8859-1/books/handbook/mirrors.lastmod.inc" 
/usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:102:
parser error : Failure to process entity chap.mirrors.lastmod.inc

^ /usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:102: parser error 
: Entity
'chap.mirrors.lastmod.inc' not defined 

[...]

My first countermeasure was to recompile/reinstall every port possibly 
involved, but that
did not resolve the problem.

A similar situation is with poudriere builds and traditional builds of ports
misc/freebsd-doc-en and misc/freebsd-doc-de. They end up in a similar failure 
on all
systems I've running FBSD 13-CURRENT and 12-STABLE so far.

Can someone please look into this and fix the problem or point me to my 
mistake? I'm out
of clues.

Thanks in advance and kind regards,

O. Hartmann

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXBn4vwAKCRA4N1ZZPba5
RyE5AQDRDVx1geJleKt1o+ZvVmJ4Lye2hJnQIbtW4vVxLF6UmgD/UbF1C8OaTL5H
D6AFqm1Tl+R8iJAjUmIODtn1Nl1KugM=
=/w7c
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


/usr/doc: make fails: parser error : Failure to process ...

2018-12-14 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


I'm loosing hair over trying over and over building the FreeBSD documentation 
from /usr
doc via

cd /usr/doc ; make update ; make all

The tree of /usr/doc is at Revision: 52685 and taken from URL:
https://svn.freebsd.org/doc/head.

I always face on every box around here (FreeBSD 12-STABLE, 13-CURRENT, most 
recent
buildworld as of today, ports tree up to date ...) the same error as shown 
below, and
this is now for a couple of months - if not years.

The last revision I have a complete and full build is 

[...]

The FreeBSD Documentation Project
Revision: 50277

Copyright © 1995-2017 The FreeBSD Documentation Project
Copyright
Legal Notice
Last modified on 2017-05-23 21:06:09 by gjb.
[...]


This message above is taken from the local website, refering to the
installation of /usr/share/doc.

I followed the instructions I could find, I have textproc/docproj installed 
(FOP and
DBLATEX enabled, as it seems they are needed by some PDF tools necessary to aim 
for the
PDF build).

What is wrong?

Thanks in advance and kind regards,

O. Hartmann



[...]
dbook/imagelib/callouts/'" --maxdepth 12000  -o eresources.xml.www.index.inc
- --param 'type' "'www'"  --param 'proto' "'http'"  --param 'target' "'index'"  
--param
transtable.xml
"'/usr/doc/share/xml/transtable.xml'"  /usr/doc/share/xml/mirrors-local.xsl 
/usr/doc/en_US.ISO8859-1/share/xml/mirrors.xml
env
XML_CATALOG_FILES="file:///usr/obj/usr/doc/en_US.ISO8859-1/books/handbook/catalog-cwd.xml
file:///usr/doc/en_US.ISO8859-1/share/xml/catalog.xml
file:///usr/doc/share/xml/catalog.xml
file:///usr/local/share/xml/catalog" /usr/local/bin/xmllint --nonet --noent 
--valid
- --dropdtd --xinclude /usr/doc/en_US.ISO8859-1/books/handbook/book.xml >
book.parsed.xml.tmp warning: failed to load external entity
"/usr/doc/en_US.ISO8859-1/books/handbook/mirrors.xml.ftp.index.inc" 
/usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:100:
parser error : Failure to process entity chap.mirrors.ftp.index.inc

^ /usr/doc/en_US.ISO8859-1/books/handbook/mirrors/chapter.xml:100: parser error 
: Entity
'chap.mirrors.ftp.index.inc' not defined 

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXBNv4wAKCRDS528fyFhY
lIYbAf9n0Lwd8V2UTDmfacHs4VkWur9l3/TlXAKEBOtQuVur+xVhFY7HSTWPdSKh
/H90CgJ2MksyhZk6+z8Z1g9QcGePAf9FeP9PX9+br7acKht7obCK0+IIBLIswQvd
fkOOjy7DGqTqtW0fhyGoHWg4NsipSXzW+/Cles9mwVAPQK9vdnpd
=cNrB
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: WITH_META_MODE: any effect? Tree built twice!

2018-12-13 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 12 Dec 2018 16:25:56 -0800
"Simon J. Gerraty"  schrieb:

Hello,

thanks for your resonse.


> O. Hartmann  wrote:
> > delete-old|-libs afterwards, I started again a build (filemon loaded!). 
> > And, surprise,
> > surprise, compilation of all the long-haul taking LLVM/CLANG stuff starts 
> > again! That
> > is not funny.  
> 
> If you have META_MODE enabled -dM will tell you if meta_oodate
> decided the target needs update - and if so exactly why.
> Eg. a command changed, a file is updated, missing etc.
> 
> If it says nothing, then the target was out-of-date per normal make
> rules.
>  
> > Why do I have to rebuild world twice to get WITH_META_MODE in effect?  
> 
> I don't follow; why do you think that is the case?

I do not think that is the, it in fact the case!
I rebuild first everything after "make cleanworld"; then I did the same again, 
no update,
no nothing done after that build (filemon already loaded as it was prerequisite 
for the
first run!); surprisingly, the build ran again full time starting from scratch!

I'm able to reproduce this behaviour easily: make cleanworld; kldload filemon 
(if not
already loaded); make buildworld buildkernel

After the build has finished, install everything accordingly and reboot. Then 
kldload
filemon and make buildworld buildkernel in /usr/src - and be surprised.

> 
> > These setting dind't change over the past time, except some WITHOUT_ tags.
> > 
> > Are there any unrevealed secrets?  
> 
> If changing any of those knobs impacts CFLAGS etc - then pretty much
> everything will be out-of-date.
> 
> Adding -dM to your build command should be very instructive.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXBKUSAAKCRDS528fyFhY
lJUCAgCMzwlE95D68PBLoQRlR1FtO8M4xqexhueOCLVrFm9RfvrMWM/NjJb7jQGN
y4HgdVlSLfmt1nLFuVXwwBhDOPdoAf4/agCSRz0aOaWceBl0z0qTlaqSyv8g3Oif
sVMeo1jynFFuICbxcqiVSJxlc2nIdH8GEyCKxF5UIeVM7hjpQM/7
=o0WF
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


WITH_META_MODE: any effect? Tree built twice!

2018-12-12 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I just updated sources /usr/src to r341879 (13-CURRENT). To have a clean, new 
build,
performing of "make cleanwolrd cleandir" has been issued and I have set 
WITH_META_MODE=
in /etc/src-env.conf. Loading filemon.ko and rebuilding world and kernel takes 
on my
IvyBridge 2-core box aeons. My other box, a XEON  E3-1245 V2 @ 3.40GH based 
box, once
took ~ 40 minutes to buildword and buildkernel from a clean buildtree (with 
LLVM/CLANG
extras set to be build!), and that system now is also beyond 90 minutes, 
starting
earlier this year. You see, there is a reason to cut down build times.

Well, after rebuilding world/kernel and installing those, mergemaster and make
delete-old|-libs afterwards, I started again a build (filemon loaded!). And, 
surprise,
surprise, compilation of all the long-haul taking LLVM/CLANG stuff starts 
again! That is
not funny.

Why do I have to rebuild world twice to get WITH_META_MODE in effect?

My in-effect settings in /etc/src.conf are as follows:

#
CPUTYPE?=   native
#
CFLAGS+=-O3
# for the kernel
COPTFLAGS+= -O3
#
#CXXFLAGS+= -std=c++11
#
WITH_CLANG_EXTRAS=  YES
WITH_LLDB=  YES
WITH_LLD_IS_LD= YES
# eBPF
WITH_LLVM_TARGET_BPF=   YES
#
WITH_IDEA=  YES
#
#WITH_BSD_GREP= YES
#
WITH_OFED_EXTRA=YES
WITH_NAND=  YES
#WITH_CTF=  YES
#
WITH_SVN=   YES
#
# Enable building openldap support for kerberos.
#WITH_OPENLDAP= YES
#
WITH_SORT_THREADS=  YES
#
WITH_EXTRA_TCP_STACKS=  YES
#
WITH_ZONEINFO_LEAPSECONDS_SUPPORT=  YES
#
MALLOC_PRODUCTION=  YES
#
WITHOUT_ASSERT_DEBUG=   YES
#
WITHOUT_TESTS=  YES
#
WITHOUT_DEBUG_FILES=YES
#
WITHOUT_REPRODUCIBLE_BUILD= YES
#
#  mitigation for CVE-2017-5715 in the kernel build
#WITH_KERNEL_RETPOLINE= YES


These setting dind't change over the past time, except some WITHOUT_ tags.

Are there any unrevealed secrets?

The boxes in question do have 8 GB RAM (two core/4 threads box, base system 
residing on
UFS/FFS 256GB Samsung 850 Pro SSD, two ZFS volumes for /home and /usr/ports 
aboard), and
16 GB RAM (4 cores/8thread XEON box, base system on UFS/FFS 256 GB Samsung 850 
Pro SSD,
ZFS RAIDZ volume of 16 TB as data graveyard). 

Thanks in advance.

oh


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXBEDpQAKCRDS528fyFhY
lMrDAgCnnh1oIWQuNIEb8Es59SGxW5OwQe1KxnRdwOc1lsXJOuBj4lh1pykHavWG
S7iY0/QrXLFNhDsNPhiz0CRqO2MyAf47nIQ4olxb7qmUx3MtatUk8VV37USqwVTA
gm4pYSgySmH0qKb8BN65VJg19VDkbUEKi1zIwZGMlKQSVq0a3+hO
=XMEQ
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r111 build error

2018-12-12 Thread O. Hartmann
t; > >>> clang::MultiLevelTemplateArgumentList
> > >>> const&)) in archive 
> > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: 
> > clang::AnyX86NoCfCheckAttr::clone(clang::ASTContext&)
> > const  
> > >>> referenced by AttrTemplateInstantiate.inc:138
> > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:138)
> > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr
> > >>> const*, clang::ASTContext&, clang::Sema&, 
> > >>> clang::MultiLevelTemplateArgumentList
> > >>> const&)) in archive 
> > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: 
> > clang::MinVectorWidthAttr::clone(clang::ASTContext&)
> > const  
> > >>> referenced by AttrTemplateInstantiate.inc:575
> > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:575)
> > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr
> > >>> const*, clang::ASTContext&, clang::Sema&, 
> > >>> clang::MultiLevelTemplateArgumentList
> > >>> const&)) in archive 
> > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: 
> > clang::NoStackProtectorAttr::clone(clang::ASTContext&)
> > const  
> > >>> referenced by AttrTemplateInstantiate.inc:671
> > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:671)
> > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr
> > >>> const*, clang::ASTContext&, clang::Sema&, 
> > >>> clang::MultiLevelTemplateArgumentList
> > >>> const&)) in archive 
> > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > ld: error: undefined symbol: 
> > clang::CPUSpecificAttr::clone(clang::ASTContext&) const  
> > >>> referenced by AttrTemplateInstantiate.inc:247
> > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/Sema/AttrTemplateInstantiate.inc:247)
> > >>> SemaTemplateInstantiateDecl.o:(clang::sema::instantiateTemplateAttribute(clang::Attr
> > >>> const*, clang::ASTContext&, clang::Sema&, 
> > >>> clang::MultiLevelTemplateArgumentList
> > >>> const&)) in archive 
> > >>> /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: 
> > clang::HeaderSearch::lookupModule(llvm::StringRef,
> > bool)  
> > >>> referenced by GeneratePCH.cpp:51
> > >>> (/usr/src/contrib/llvm/tools/clang/lib/Serialization/GeneratePCH.cpp:51)
> > >>> GeneratePCH.o:(clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&))
> > >>>  in
> > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: clang::Stmt::getLocStart() const  
> > >>> referenced by SelectorLocationsKind.cpp:52
> > >>> (/usr/src/contrib/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:52)
> > >>> SelectorLocationsKind.o:(clang::hasStandardSelectorLocs(clang::Selector,
> > >>> llvm::ArrayRef, llvm::ArrayRef,
> > >>> clang::SourceLocation)) in
> > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: clang::Stmt::getLocStart() const  
> > >>> referenced by SelectorLocationsKind.cpp:52
> > >>> (/usr/src/contrib/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:52)
> > >>> SelectorLocationsKind.o:(clang::hasStandardSelectorLocs(clang::Selector,
> > >>> llvm::ArrayRef, llvm::ArrayRef,
> > >>> clang::SourceLocation)) in
> > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: clang::Stmt::getLocStart() const  
> > >>> referenced by SelectorLocationsKind.cpp:52
> > >>> (/usr/src/contrib/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:52)
> > >>> SelectorLocationsKind.o:(clang::getStandardSelectorLoc(unsigned int,
> > >>> clang::Selector, bool, llvm::ArrayRef, 
> > >>> clang::SourceLocation)) in
> > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: undefined symbol: clang::operator<<(llvm::raw_ostream&,
> > clang::VersionTuple const&)  
> > >>> referenced by AttrImpl.inc:1216
> > >>> (/usr/obj/usr/src/amd64.amd64/lib/clang/libclang/clang/AST/AttrImpl.inc:1216)
> > >>> AttrImpl.o:(clang::AvailabilityAttr::printPretty(llvm::raw_ostream&,
> > >>> clang::PrintingPolicy const&) const) in
> > >>> archive /usr/obj/usr/src/amd64.amd64/lib/clang/libclang/libclang.a
> > 
> > ld: error: too many errors emitted, stopping now (use -error-limit=0 to see 
> > all
> > errors) c++: error: linker command failed with exit code 1 (use -v to see 
> > invocation)
> > *** [clang.full] Error code 1
> > 
> > 
> > 
> > -- 
> > Best regards,
> >  Lev  mailto:l...@freebsd.org
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"  
> 
> 



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXBDT5wAKCRDS528fyFhY
lMU8AgCbP9fRIsLurpP16FzNDWdw+LbVaxg9lQkz9T2S/b/PJeJ0KOSpojBPWZS3
2U/58wnGiXKZqzfQb4F/yhNkToPnAf94cCgtgl1qSlLOIY9gXw+3dkkkf3MNJkV9
ITem1iTJ/2WZXpJf72jO5gBRXVErwGe7IegpWlIqZU4c381KA9b1
=nOjO
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


SDHCI: serious issues with USB SD Card reader/writer

2018-12-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Using the USB attached SD card reader/writer of my Dell screen, since 
13-CURRENT is out
recently I have serious trouble with the assortment of SD cards I use.

While 12-PRE seems to not have any problems, 13-CURRENT (FreeBSD 13.0-CURRENT 
#912
r341770: Sun Dec  9 23:02:16 CET 2018 amd64) has.
The phenomenon looks like when written successfully an image to  a 16 or 32 GB 
SD card
and put in a Samsung 32GB SD card (a Samsung EVO, or the one that comes with 
the Raspberry
Pi 3B+ these days, I have two of them and the problem is on both the same), I 
receive the
console message after trying to "dd" some images onto /dev/da0:

sudo dd if=2018-11-13-raspbian-stretch-full.img of=/dev/da0 bs=1m
dd: /dev/da0: Operation not permitted

This happens even as root.

The console shows:

[...]
ugen0.4:  at usbus0
umass0 on uhub6
umass0:  on 
usbus0
da0 at umass-sim0 bus 0 scbus10 target 0 lun 0
da0:  Removable Direct Access SCSI device
da0: Serial Number 00264001
da0: 40.000MB/s transfers
da0: Attempt to query device size failed: NOT READY, Medium not present
da0: quirks=0x2
[...]
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 10 00 
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read 
error)
(da0:umass-sim0:0:0:0): Error 5, Unretryable error
[...]
GEOM_PART: integrity check failed (da0, MBR)
GEOM_PART: da0 was automatically resized.
  Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
GEOM_PART: da0 was automatically resized.
  Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
GEOM_PART: da0 was automatically resized.
  Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
GEOM_PART: da0 was automatically resized.
  Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
g_access(958): provider diskid/DISK-00264001 has error 6 set
[...]

The CAM error above occurs on a lot of SD cards which worked earlier.

In some cases, the problem disappears after a reboot, but it seems to be 
persistent with
some types of the SD cards. Since I've written all of them in the past with 
12-CURRENT
and the very same SD card reader, I suspect some serious bug in recent updates 
either to
the SCSI subsystem or SDHCI.

I just ordered an alternative USB SD card reader/writer just in case the error 
indicates
a hardware failure.

Kind regards,

O. Hartmann



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXA5TqgAKCRDS528fyFhY
lJ7eAf98BJ7zbDfEd3JqQRykn4iEvLsHPBofzsb+uj9ZS1uJsnk70kMwyIPitdtd
CuHue4UGps2Ozt+KEtaRnAqxuMk4AgCA/K/3Y5lsYu0o6e2p4oKXu323fe8akco1
PxTGVTEsr/0BJEbTrSbOnRqIXY4lF86GspSzSZtnoKM9Av+5EbuO
=/a+G
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

2018-12-03 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mon, 3 Dec 2018 09:26:14 +0100
"O. Hartmann"  schrieb:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Fri, 30 Nov 2018 23:14:07 +0900
> Tomoaki AOKI  schrieb:
> 
> > On Wed, 28 Nov 2018 19:39:21 +0100
> > "O. Hartmann"  wrote:
> >   
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > Am Wed, 28 Nov 2018 15:00:42 +0100
> > > Emmanuel Vadot  schrieb:
> > > 
> > > >  Hi,
> > > > 
> > > > On Wed, 28 Nov 2018 10:51:11 +0100
> > > > "O. Hartmann"  wrote:
> > > > 
> > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > Hash: SHA512
> > > > > 
> > > > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware 
> > > > > is latest,
> > > > > r1.22 from 2013). The E751 is of model series S26391-K326-V100 and 
> > > > > equipted with
> > > > > a Core i5-2520M CPU and supposed to be also equipted with a iGPU HM65 
> > > > > according
> > > > > to the techniscal specifications from Fujitsu.
> > > > > 
> > > > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most 
> > > > > recent I could
> > > > > grap from the download page), the screen becomes distorted 
> > > > > immediately after the
> > > > > kernel has loaded and initialised/booted. The screen is at the 
> > > > > loader's all
> > > > > right so far.
> > > > > 
> > > > > Trying to disable graphics mode via escaping to the loader's prompt 
> > > > > and setting 
> > > > > 
> > > > > set hw.vga.textmode=1
> > > > > 
> > > > > subsequently loading the kernel and then booting, doesn't help. The 
> > > > > screen is
> > > > > distorted again. The notebook seems UEFI only and doesn't boot off 
> > > > > from MBR
> > > > > partioned devices (i.e. NanoBSD I used to use).
> > > > > 
> > > > > Loading /boot/kernel/i915kms.ko
> > > > > 
> > > > > after manually having loaded /boot/kernel/kernel (and not booted yet) 
> > > > > doesn't
> > > > > change anything either.
> > > > > 
> > > > > Booting off and installing Linux (Ubuntu, Mint so far, most revent 
> > > > > verions I can
> > > > > get my hands on) is no problem. The console works fine from the 
> > > > > beginning and so
> > > > > the graphics.
> > > > > 
> > > > > Is there a chance to get a FreeBSD booting the easy way? 
> > > > > 
> > > > > The provided boot images do not contain any of the
> > > > > graphics/drm-stable|next|legacy-kmod stuff, I tried to load 
> > > > > i915kms.ko off
> > > > > from /boot/modules/ (were those modules from the ports are supposed 
> > > > > to reside)
> > > > > but no chance.
> > > > > 
> > > > > Before starting investigating this issue further I'd like to ask 
> > > > > wether there
> > > > > is a general support provided or is that type of notebook dead matter 
> > > > > for
> > > > > FreeBSD of the modern kind?
> > > > > 
> > > > > Thanks in advance,
> > > > > 
> > > > > oh
> > > > > 
> > > > > p.s. please CC me, I'm not subscribing all lists.
> > > > > 
> > > > > - -- 
> > > > > O. Hartmann
> > > > > -BEGIN PGP SIGNATURE-
> > > > > 
> > > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
> > > > > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
> > > > > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
> > > > > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
> > > > > =XD7b
> > > > > -END PGP SIGNATURE-  
> > > > 
> > > >  Could you post a picture somewhere ?
> > > > 
> > > >  I have a laptop which have efifb problem, what I need to do is (at
> > > > loader prompt) :
> > > > 
> > > >  gop set 4 (to switch to a different mode)
> &g

Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

2018-12-03 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 30 Nov 2018 23:14:07 +0900
Tomoaki AOKI  schrieb:

> On Wed, 28 Nov 2018 19:39:21 +0100
> "O. Hartmann"  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Wed, 28 Nov 2018 15:00:42 +0100
> > Emmanuel Vadot  schrieb:
> >   
> > >  Hi,
> > > 
> > > On Wed, 28 Nov 2018 10:51:11 +0100
> > > "O. Hartmann"  wrote:
> > >   
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA512
> > > > 
> > > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware 
> > > > is latest,
> > > > r1.22 from 2013). The E751 is of model series S26391-K326-V100 and 
> > > > equipted with
> > > > a Core i5-2520M CPU and supposed to be also equipted with a iGPU HM65 
> > > > according
> > > > to the techniscal specifications from Fujitsu.
> > > > 
> > > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent 
> > > > I could
> > > > grap from the download page), the screen becomes distorted immediately 
> > > > after the
> > > > kernel has loaded and initialised/booted. The screen is at the loader's 
> > > > all right
> > > > so far.
> > > > 
> > > > Trying to disable graphics mode via escaping to the loader's prompt and 
> > > > setting 
> > > > 
> > > > set hw.vga.textmode=1
> > > > 
> > > > subsequently loading the kernel and then booting, doesn't help. The 
> > > > screen is
> > > > distorted again. The notebook seems UEFI only and doesn't boot off from 
> > > > MBR
> > > > partioned devices (i.e. NanoBSD I used to use).
> > > > 
> > > > Loading /boot/kernel/i915kms.ko
> > > > 
> > > > after manually having loaded /boot/kernel/kernel (and not booted yet) 
> > > > doesn't
> > > > change anything either.
> > > > 
> > > > Booting off and installing Linux (Ubuntu, Mint so far, most revent 
> > > > verions I can
> > > > get my hands on) is no problem. The console works fine from the 
> > > > beginning and so
> > > > the graphics.
> > > > 
> > > > Is there a chance to get a FreeBSD booting the easy way? 
> > > > 
> > > > The provided boot images do not contain any of the
> > > > graphics/drm-stable|next|legacy-kmod stuff, I tried to load i915kms.ko 
> > > > off
> > > > from /boot/modules/ (were those modules from the ports are supposed to 
> > > > reside)
> > > > but no chance.
> > > > 
> > > > Before starting investigating this issue further I'd like to ask wether 
> > > > there is a
> > > > general support provided or is that type of notebook dead matter for 
> > > > FreeBSD of
> > > > the modern kind?
> > > > 
> > > > Thanks in advance,
> > > > 
> > > > oh
> > > > 
> > > > p.s. please CC me, I'm not subscribing all lists.
> > > > 
> > > > - -- 
> > > > O. Hartmann
> > > > -BEGIN PGP SIGNATURE-
> > > > 
> > > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
> > > > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
> > > > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
> > > > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
> > > > =XD7b
> > > > -END PGP SIGNATURE-
> > > 
> > >  Could you post a picture somewhere ?
> > > 
> > >  I have a laptop which have efifb problem, what I need to do is (at
> > > loader prompt) :
> > > 
> > >  gop set 4 (to switch to a different mode)
> > >  gop set 0 (switch to the correct mode)
> > > 
> > >  You can gop list (iirc) to checks the available mode.
> > > 
> > >  The problem is that we are mixing serial and gop in loader.efi and
> > > when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can
> > > mess the graphical mode.
> > >   
> > 
> > Sorry, I have no upload place to put some screenshots. 
> > 
> > The natural resolution of the display is 1280x800 pixel.
> > 
> > When existing to the loader and issuing as recommended the command "gop 
> > list

Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only

2018-12-02 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 30 Nov 2018 14:32:52 +
Gary Palmer  schrieb:

> On Fri, Nov 30, 2018 at 01:12:32PM +0100, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > My ISP is offering IPv6 only "as an experimental feature", so I had to ask 
> > to enable
> > the IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis 
> > for a
> > router/firewall/PBX system, FreeBSD's onboard ppp client is performing the 
> > uplink and
> > authetication and this works well with IPv4 for years for now.
> > 
> > I'm using IPFW as my filtering system, reading the standard 
> > /etc/rc.ipfirewall and add
> > some custom rules regarding my setup.
> > 
> > As far as I know, with the IPv4 stack a IPv4 address is obtained 
> > automatically, so I
> > would expect the same for IPv6.
> > 
> > I'm new to IPv6 and I've trouble with my provider for a long time now, so 
> > there is a
> > slight possibility that my ISP is not truthful on what they say. On the 
> > other hand,
> > there is still a high probability that I do something wrong. I need need to 
> > send this
> > ahead, before continueing.
> > 
> > When booting off, I see the classic tun0 uplink with
> > 
> > MYADDR -> HISADDR
> > 
> > For IPv6, I only see my local linklocal address, fe80::... 
> > 
> > Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: 
> > linklocal address
> > assigned to the variable HISADDR. Somehow, the tun0 never obtains a IPv6 
> > aprefix so
> > far.
> > 
> > Can someone give a tip?  
> 
> I have
> 
> :
> shell /sbin/ifconfig tun0 inet6 -ifdisabled -no_radr accept_rtadv
> shell /sbin/rtsol tun0 &
> 
> in a ppp.linkup file.  The alternative is to use dhcp6c, which also worked
> for my provider.
> 
> (there are other lines in the linkup file also, but I think those are
>  the relevant ones)
> 
> Regards,
> 
> Gary

Thank you very much for this hint! Much appreciated.

With adding those lines to the ppp.linkup script, the outer interface, tun0, 
now obtains
two valid IPv6 addresses - on is always marked temporary, the other is 
comprised from
the MAC of the physical interface from which is tun0 is cloned.

But when the ISP is changing the IPs (both IPv4 and IPv6), without any further
actoin I have a bunch of IPv6 addresses over time associated with tun0. 

The documentation lacks in many aspects how to deal with IPv6, especially when 
it comes
to "well known things from the old IPv4 world". Since DDNS also is still 
something people
use with IPv6, MYADDR6 doesn't carry the IPV6 address obtained after rtsold has 
been
started and rtsol tun0 has been issued as described above (MYADDR6/HISADDR6 are 
assigned
with the linklocal addresses).

Thanks for the help! 

Kind regards,
Oliver


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXARSrgAKCRDS528fyFhY
lHrHAf97f7pFLQtUugVqtQkkcmOwZfDT3hSpJzCKy+2SUBu1p08TRNnO6t2lt+q2
8Bj9edB/Ybbsx/K8LNaYU5IcIZRSAf9nnBNwNvfdqLQ8hm7zLE2mpgroBfaT+Nkk
/iWEqhAaSNA5Msg8jmE32qm7vRippUyEzOeG5l8P/miGHVWCaR6d
=ewBW
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only

2018-12-02 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 30 Nov 2018 16:41:02 +
"Bjoern A. Zeeb"  schrieb:

Sorry for the late reply, had a long weekend off ...

> On 30 Nov 2018, at 15:59, Christoph Moench-Tegeder wrote:
> 
> > ## O. Hartmann (ohartm...@walstatt.org):
> >  
> >> As far as I know, with the IPv4 stack a IPv4 address is obtained
> >> automatically, so I would expect the same for IPv6.  
> >
> > The fun with "automatically" is that there's more than one way...
> > DHCPv6 and NDP (IPV6 Neighbour Discovery Protocol/Router Solicitation)
> > have been mentioned, the third option is IPV6CP (PPP options, just as
> > PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so...  
> 
> No, IPV6CP, to my very best 15 year old memory only negotiates the
> interface identifiers, which are used to generate the link-local addresses.
> There is no negotiation for full prefix/global addresses, hence it is
> different to the IPCP NCP used for IPv4.

In my case. IPV6CP indeed does only negotiate the linklocal addresses (fe80::) 
on my
WAN interface ...
 
> 
> One wants to run rtsol on the link and then depending on the O/M bits possibly
> also DHCPv6 I’d assume.
> 
> There’s a couple of other options and shortcuts, on how to configure global
> addresses (as always, if you know you have a static prefix assigned, one can
> do it by hand for example);  and then there are shortcuts as to when you’d
> perform DAD, which shouldn’t bother the user.  These days there should also
> be options with regards to RFC4941 (privacy extensions for stateless address
> autoconf).

Studying the manpage for ppp(8), one might not get that IPV6CP does only 
negotiate the
IPv6 linklocal address ...

> 
> It may no be uncommon to run the ptp-link with link-local addresses only and
> configure an address from a prefix on lo0 or the internal interface only; but
> I am doubtful FreeBSD’s userland implementation is that sophisticated.
> 
> /bz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXARQZAAKCRDS528fyFhY
lMXRAf9RE7lygi/eqfkL5U+iAWiQYDEmuITolg6sOpyqMVUIKZeg1zA1HQL8Cw70
7vMSc6Rwbvtuz8b8N+chelawH4dxAf9K2Rs9O+cw91PRO0CNN+JcuRnk/gj/ivYo
pn24sPi8MIoXOOecR2WSLg1e0uspStEBGr0kdxPJ0aJBNVu1AuLd
=cnfs
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


ipv6/ppp: FreeBSD obtains linklocal on tun0 only

2018-11-30 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

My ISP is offering IPv6 only "as an experimental feature", so I had to ask to 
enable the
IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a
router/firewall/PBX system, FreeBSD's onboard ppp client is performing the 
uplink and
authetication and this works well with IPv4 for years for now.

I'm using IPFW as my filtering system, reading the standard /etc/rc.ipfirewall 
and add
some custom rules regarding my setup.

As far as I know, with the IPv4 stack a IPv4 address is obtained automatically, 
so I
would expect the same for IPv6.

I'm new to IPv6 and I've trouble with my provider for a long time now, so there 
is a
slight possibility that my ISP is not truthful on what they say. On the other 
hand, there
is still a high probability that I do something wrong. I need need to send this 
ahead,
before continueing.

When booting off, I see the classic tun0 uplink with

MYADDR -> HISADDR

For IPv6, I only see my local linklocal address, fe80::... 

Checking the log of ppp (/var/log/ppp.log), there is also a fe80:: linklocal 
address
assigned to the variable HISADDR. Somehow, the tun0 never obtains a IPv6 
aprefix so far.

Can someone give a tip?

Regards,

oh
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCXAEpSwAKCRDS528fyFhY
lMwHAf9XXmHWMWPjNH/oIMOCG50M7X8tcWrS0aZy7tsJchYBzu6bos/qXXEJHtxs
3XwPOyli0NuAo8i0MEAQMOnnOFyxAf9ey6qPJxC0dYyfJW4QHFyCCCVHEG+HEv9i
vHkpvZrrV0OpuF6ReM0xFiXlZkhrLoptsQ8V859NeWk5K5P+Ox4r
=nsq2
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

2018-11-28 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 28 Nov 2018 15:00:42 +0100
Emmanuel Vadot  schrieb:

>  Hi,
> 
> On Wed, 28 Nov 2018 10:51:11 +0100
> "O. Hartmann"  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is 
> > latest, r1.22
> > from 2013). The E751 is of model series S26391-K326-V100 and equipted with 
> > a Core
> > i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to 
> > the
> > techniscal specifications from Fujitsu.
> > 
> > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I 
> > could grap
> > from the download page), the screen becomes distorted immediately after the 
> > kernel has
> > loaded and initialised/booted. The screen is at the loader's all right so 
> > far.
> > 
> > Trying to disable graphics mode via escaping to the loader's prompt and 
> > setting 
> > 
> > set hw.vga.textmode=1
> > 
> > subsequently loading the kernel and then booting, doesn't help. The screen 
> > is
> > distorted again. The notebook seems UEFI only and doesn't boot off from MBR 
> > partioned
> > devices (i.e. NanoBSD I used to use).
> > 
> > Loading /boot/kernel/i915kms.ko
> > 
> > after manually having loaded /boot/kernel/kernel (and not booted yet) 
> > doesn't change
> > anything either.
> > 
> > Booting off and installing Linux (Ubuntu, Mint so far, most revent verions 
> > I can get
> > my hands on) is no problem. The console works fine from the beginning and 
> > so the
> > graphics.
> > 
> > Is there a chance to get a FreeBSD booting the easy way? 
> > 
> > The provided boot images do not contain any of the
> > graphics/drm-stable|next|legacy-kmod stuff, I tried to load i915kms.ko off
> > from /boot/modules/ (were those modules from the ports are supposed to 
> > reside) but no
> > chance.
> > 
> > Before starting investigating this issue further I'd like to ask wether 
> > there is a
> > general support provided or is that type of notebook dead matter for 
> > FreeBSD of the
> > modern kind?
> > 
> > Thanks in advance,
> > 
> > oh
> > 
> > p.s. please CC me, I'm not subscribing all lists.
> > 
> > - -- 
> > O. Hartmann
> > -BEGIN PGP SIGNATURE-
> > 
> > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
> > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
> > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
> > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
> > =XD7b
> > -END PGP SIGNATURE-  
> 
>  Could you post a picture somewhere ?
> 
>  I have a laptop which have efifb problem, what I need to do is (at
> loader prompt) :
> 
>  gop set 4 (to switch to a different mode)
>  gop set 0 (switch to the correct mode)
> 
>  You can gop list (iirc) to checks the available mode.
> 
>  The problem is that we are mixing serial and gop in loader.efi and
> when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can
> mess the graphical mode.
> 

Sorry, I have no upload place to put some screenshots. 

The natural resolution of the display is 1280x800 pixel.

When existing to the loader and issuing as recommended the command "gop list", 
I get
three modes:

mode 0: 1024x768x32, stride=1024
mode 1: 640x480x32, stride=640
mode 2: 800x600x32, stride=800

Setting mode 1 and 2 via gop set X solves the problem and the screen is, at 
least during
a live session of the latest 12-PRE USB image, readable and looking normal.

As soon as I have an installation media, I'll check whether the screen is 
operable after
installation (and, of course, loader settings as required), or not.

Thanks for the quick help!

Kind regards,

O. Hartmann  

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/7g9AAKCRDS528fyFhY
lGKLAf9uL2wkoLhxrT/ca/EylOlGvOZ/n+9TVCuI1YZyhjHAjQICN863czLtfIvF
pu7OyWNxeWvDS5bvdCol1bpOQ8kUAgCDGZZT3Y2GSALuyfk2L2M4xGb/uegdnlD1
7M9gnnIwQ5bfyZkF1kvN3MGMn3WtnVZduSpjg8SURmkC+1xFDXNl
=XJxh
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot

2018-11-28 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is 
latest, r1.22
from 2013). The E751 is of model series S26391-K326-V100 and equipted with a 
Core
i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to the
techniscal specifications from Fujitsu.

Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I could 
grap from
the download page), the screen becomes distorted immediately after the kernel 
has
loaded and initialised/booted. The screen is at the loader's all right so far.

Trying to disable graphics mode via escaping to the loader's prompt and setting 

set hw.vga.textmode=1

subsequently loading the kernel and then booting, doesn't help. The screen is 
distorted
again. The notebook seems UEFI only and doesn't boot off from MBR partioned 
devices (i.e.
NanoBSD I used to use).

Loading /boot/kernel/i915kms.ko

after manually having loaded /boot/kernel/kernel (and not booted yet) doesn't 
change
anything either.

Booting off and installing Linux (Ubuntu, Mint so far, most revent verions I 
can get my
hands on) is no problem. The console works fine from the beginning and so the 
graphics.

Is there a chance to get a FreeBSD booting the easy way? 

The provided boot images do not contain any of the 
graphics/drm-stable|next|legacy-kmod
stuff, I tried to load i915kms.ko off from /boot/modules/ (were those modules 
from the
ports are supposed to reside) but no chance.

Before starting investigating this issue further I'd like to ask wether there 
is a
general support provided or is that type of notebook dead matter for FreeBSD of 
the
modern kind?

Thanks in advance,

oh

p.s. please CC me, I'm not subscribing all lists.

- -- 
O. Hartmann
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY
lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP
/QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf
vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg
=XD7b
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 9 Oct 2018 23:37:02 -0400
Michael Butler  schrieb:

> On 10/9/18 11:14 PM, Michael Butler wrote:
> > On 10/9/18 5:34 PM, Glen Barber wrote:  
> >> OpenSSL has been updated to version 1.1.1 as of r339270.
> >>
> >> It is important to rebuild third-party packages before running:
> >>
> >>  # make -C /usr/src delete-old && make -C /usr/src delete-old-libs
> >>
> >> Thank you for your patience while this work was in progress, and thank
> >> you to all involved for their hard work in getting things ready for this
> >> update.  
> > 
> > So far, I've found two ports that will no longer build. They are:
> > 
> > net-mgmt/net-snmp
> > security/opencryptoki
> > 
> > I simply chose those that were linked to /usr/lib/libssl.so.8 where the
> > openssl update creates libssl.so.9. There may be more I haven't found yet,  
> 
> add multimedia/ffmpeg to this list ..
> 
>   imb
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

security/libssh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW754oQAKCRDS528fyFhY
lGy4AfkBPCItbFuIsX5HZTWLyCSq8L7rU+4cnb77b8iYeKEBT7pThY1jm9F+ZeSz
uepHL6iZoRqwdiXReasafUeXgSbRAf9jCRsfjIq5xq8Gxgm8AtFdabhEQ0y3Nb2B
zZ349A0UwalA/bL+1SZ3y0RaICnsT4LzngB/Cn3fxCqu0nXDxLKG
=0Rcl
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 9 Oct 2018 23:37:02 -0400
Michael Butler  schrieb:

> On 10/9/18 11:14 PM, Michael Butler wrote:
> > On 10/9/18 5:34 PM, Glen Barber wrote:  
> >> OpenSSL has been updated to version 1.1.1 as of r339270.
> >>
> >> It is important to rebuild third-party packages before running:
> >>
> >>  # make -C /usr/src delete-old && make -C /usr/src delete-old-libs
> >>
> >> Thank you for your patience while this work was in progress, and thank
> >> you to all involved for their hard work in getting things ready for this
> >> update.  
> > 
> > So far, I've found two ports that will no longer build. They are:
> > 
> > net-mgmt/net-snmp
> > security/opencryptoki
> > 
> > I simply chose those that were linked to /usr/lib/libssl.so.8 where the
> > openssl update creates libssl.so.9. There may be more I haven't found yet,  
> 
> add multimedia/ffmpeg to this list ..
> 
>   imb
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

dns/samba-nsupdate
net/liboauth

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW74s5wAKCRDS528fyFhY
lIftAgCn+d7Z0semQwgugPFWnTyuPcIRo0iaPdRQC+DZKndZiPNVEu9hzanPokd5
/kiBWup+5zfTXLHoczuu/1uxCTydAf0Ydn7nXg7imLrBGFHMUoWDe7D3lEipp9oa
glsBP11oUpwQFTDu3gQgHPBn/VqZgsV9koBpkDpQ3otOAVTyJ8YM
=e+AB
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: 12-ALPHA3: (NanoBSD): ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8"

2018-08-30 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Thu, 30 Aug 2018 10:44:25 -0500
Kyle Evans  schrieb:

> On Thu, Aug 30, 2018 at 10:41 AM O. Hartmann  wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Running a NanoBSD with lots of "WITHOUT_" tags reducing the size, it seems 
> > that with
> > one of those excluded build/install opts I also exclude a crucial library, 
> > namely
> > "libibverbs.so.1", since ipfwpcap seems to require it:
> >
> > [...]
> >  root@host-puking-alot:~ # ipfwpcap
> > ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by 
> > "libpcap.so.8"
> >
> > [...]
> >
> > Checking via ldd on "libpcap.so.8" reveals strange things:
> >
> > [...]
> >  root@host-puking-alot:~ # ldd /lib/libpcap.so.8
> > /lib/libpcap.so.8:
> > libibverbs.so.1 => not found (0)
> > libmlx5.so.1 => not found (0)
> > libc.so.7 => /lib/libc.so.7 (0x80024a000)
> > [...]
> >
> > So, I do not have any Mellanox device, therefore I do not build nor install 
> > drivers
> > and or modules (refering to the libmlx5.so.1).
> >  
> 
> You set WITHOUT_OFED=yes, right? That's a default now, so that'll stop
> the dependency on ofed/ bits in libpcap. This is still breakage that
> needs to be fixed, but that should workaround it for you.

Yes, indeed I do.

So, it is a well-known breakage? Good to know.

Sometimes I get confused by OFED and Mellanox stuff - somehow there is no link 
between
those to designators ;-)

Thanks anyway, I'll enable via "WITH_OFED" the build and will see ...
> 
> Thanks,
> 
> Kyle Evans


Regards,

O. Hartmann


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4gUOAAKCRDS528fyFhY
lNX1Af951ILatznC0l0NXH9Kpe83XnFjovVm7/IE+3kkGiXxk+lZvwNyTpER4JCo
bq0x5ZixbjjpeRo0B/7zuRu5LXWVAf9NuXeGq6d92dMU6BxOXf+/iQtKZ82v6fby
dP9vItUlk/QFgmsaBvYdedbhBkO2AkR1u29YdrJybIBqpn/FhTWD
=JYf+
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


12-ALPHA3: (NanoBSD): ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by "libpcap.so.8"

2018-08-30 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Running a NanoBSD with lots of "WITHOUT_" tags reducing the size, it seems that 
with one
of those excluded build/install opts I also exclude a crucial library, namely
"libibverbs.so.1", since ipfwpcap seems to require it:  

[...]
 root@host-puking-alot:~ # ipfwpcap
ld-elf.so.1: Shared object "libibverbs.so.1" not found, required by 
"libpcap.so.8"

[...]

Checking via ldd on "libpcap.so.8" reveals strange things:

[...]
 root@host-puking-alot:~ # ldd /lib/libpcap.so.8
/lib/libpcap.so.8:
libibverbs.so.1 => not found (0)
libmlx5.so.1 => not found (0)
libc.so.7 => /lib/libc.so.7 (0x80024a000)
[...]

So, I do not have any Mellanox device, therefore I do not build nor install 
drivers
and or modules (refering to the libmlx5.so.1).

The kernel is completely monolithic on that appliance in question - I do not 
allow the
loading of kernel modules. 

I guess this is a bug or do I miss something here?

Kind regards,

oh
- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4gQEQAKCRDS528fyFhY
lCpuAf9AaMHdaAeAdkUjcZEihbQJSwXXHtubx9DHFE0jZXoQHEwCgMy9WFNuV+nj
HXluOTCKvleEX1nGH1QgdO2GBGUsAgCdRzR2Iw7iHpQUfQ1cMHGijADLjeLSI6/4
GufHiu3K6ZYIsB1YWUPP/6SEduhYUAVACQpkNI7vMtdDOxQ0B4l2
=thgR
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


pkg-base: how to avoid FreeBSD-$PACKAGE-{profile|development} when using FreeBSD pkg-base

2018-08-25 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


For some experiments on PINE64 we build packages from FreeBSD's base system. The
individual package seems to comprise always from several flavours, the
"regular/production" one, profile/profiling one and development, for instance 
for package
FreeBSD-libxo:

FreeBSD-libxo: 12.0.s20180825090036 [FreeBSD-base]
FreeBSD-libxo-development: 12.0.s20180825090036 [FreeBSD-base]
FreeBSD-libxo-profile: 12.0.s20180825090036 [FreeBSD-base]

When installing packages as recommended on the FreeBSD pkg-base Wiki
(https://wiki.freebsd.org/PkgBase) via

pkg install -g 'FreeBSD-*'

it is implicit that I also get those unwanted "profiling" and "development" 
packages as
well as the supposed to be the "production" ones. Fiddling around whith the 
pattern left
me with some problems, as it seems to me to make the efforts to high to target 
all wanted
packages or avoid development packages. I haven't found a proper way to exclude 
all the
unwanted packages (development, prifile) by the global pattern.

I was thinking that the build box also has to take some load when 
packaging/building all
the profiling/development stuff, so is there a way to avoid building those 
unwanted
packages in the first place?

At the end my PINE64 wnats to install 313 packages. This seems 2/3 unnecessary.

Kind regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4Eh3AAKCRDS528fyFhY
lLavAgCmjKuhajNCNmO53kU7gBdQmTdKnk9rDKFMVOy4WT8mxP6R9YMKJ2MdfVlZ
nM2/J4zktZRhTEIrVtCIBsF/XD7EAgCJfhf+zl7uM4gDod+bEenIDRYdyywNuHW2
Ek0itMr7nMbJCsVQ8BIMm9SorftD4luu7laNIgMUmXUkQe+FxWTc
=4r25
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA

2018-08-25 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm using ezjail-admin from ports (most recent tree, up to date as of today, at 
Revision:
478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25 07:10:45 CEST 
2018 amd64,
the jails sources are at revision 338309).

Updates of the jail's base is taken from /usr/src or another path (in case of 
another
path, ezjail-admin update -i requires the setting of evn MAKEOBJDIRPREFIX= 
some/place).

Updating jails and creating new jails has worked for a while, but recently, 
newly created
jails fail to start because the initial start routine bringing up the jail 
dumps an error
about /bin/sh /etc/rc missing!

Investigating a complete fresh ezajil setup (on ZFS) reveals, that neither in 
fulljail,
newjail or basejail any of the initial rc-srcipts rc or rc.subr is present any 
more! I
stopped looking for other missing scripts since rc and rc.subr are crucial and 
essential
to the system, so I guess there has been introduced a sort of bug recently in 
the way
FreeBSD 12 is going to handle/keep/store rc scripts in the source tree or their
installation and ezjai didn't catch up so far.

I already filed a PR (see Bug 230822), but I'm unsure whether this is a "real" 
bug or I
did just miss some important changes and I didn't catch up.

Thanks in advance,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4EAGAAKCRDS528fyFhY
lLVGAf95kEF2FnVtuDs4XYZs3qDlzlEMNkNtXoHnLYNdIp0Fmvl4a8+GwwswQogD
DdFcBbToJ2ER+mU0i9luAxI6zJ+pAfwLz24/BiZfMaJHz8O015E568w7Ut1YZ5Vf
JyiHLCJnnc7B/ST0f49txNGVXvxfLiRbrrNicHYFxw/DiYtDWLFk
=vabb
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools

2018-08-20 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mon, 20 Aug 2018 21:24:21 +0200
"O. Hartmann"  schrieb:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Building NanoBSD world on CURRENT r338113 fails due to:
> 
> [...]
> cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&  MK_TESTS=no
> UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
> MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
> make  MK_AUTO_OBJ=no  DIRPRFX=rescue/rescue/gbde/ -DRESCUE 
> CRUNCH_CFLAGS=-DRESCUE
> MK_AUTO_OBJ=no   obj make[5]: 
> "/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
> line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.  Copy 
> the header to
> ${WORLDTMP}/legacy in tools/build/Makefile instead.  Error was caused by 
> Makefile
> in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1
> 
> make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
> [...]
> 
> 
> This problem occured during today's source updates since I was able to build 
> the NanoBSD
> image I intend to build yesterday ~ r338060.
> 
> What is going wrong?

It seems the problem has been introduced after r338095, since r338095 builds 
ok, while
r338096 doesn't.

> 
> I've set the following for NanoBSD's build and install:
> 
> # BUILDWORLD ONLY
> # Options to put in make.conf during buildworld only
> CONF_BUILD='
> CFLAGS=-O3 -pipe
> MALLOC_PRODUCTION=YES
> INSTALL_NODEBUG=YES
> '
> # Options to put in make.conf during installworld only
> CONF_INSTALL='
> WITHOUT_TOOLCHAIN=YES
> WITHOUT_CROSS_COMPILER=YES
> WITHOUT_DOCCOMPRESS=YES
> WITHOUT_INSTALLLIB=YES
> WITHOUT_BINUTILS=YES
> #
> #WITHOUT_ACCT=YES
> WITHOUT_AMD=YES
> WITHOUT_APM=YES
> WITHOUT_ASSERT_DEBUG=YES
> WITHOUT_AT=YES
> WITHOUT_ATM=YES
> WITHOUT_BHYVE=YES
> WITHOUT_BLUETOOTH=YES
> WITHOUT_BOOTPARAMD=YES
> WITHOUT_BOOTPD=YES
> WITHOUT_BSDINSTALL=YES
> #WITHOUT_BSD_CPIO=YES
> #WITHOUT_BSNMP=YES
> #WITHOUT_BZIP2=YES
> WITHOUT_CALENDAR=YES
> #WITHOUT_CCD=YES
> WITHOUT_CDDL=YES
> WITHOUT_CLANG_FULL=YES
> WITHOUT_CTM=YES
> #WITHOUT_CUSE=YES
> WITHOUT_CXX=YES
> WITHOUT_DICT=YES
> WITHOUT_DIALOG=YES
> WITHOUT_EXAMPLES=YES
> WITHOUT_EE=YES
> WITHOUT_FINGER=YES
> WITHOUT_FLOPPY=YES
> WITHOUT_FREEBSD_UPDATE=YES
> WITHOUT_FDT=YES
> WITHOUT_GAMES=YES
> WITHOUT_GCOV=YES
> WITHOUT_GDB=YES
> WITHOUT_HAST=YES
> WITHOUT_HTML=YES
> WITHOUT_HYPERV=YES
> #WITHOUT_INET6=YES
> #WITHOUT_INETD=YES
> WITHOUT_IPFILTER=YES
> WITHOUT_ISCSI=YES
> WITHOUT_KDUMP=YES
> WITHOUT_KERNEL_SYMBOLS=YES
> #WITHOUT_LDNS=YES
> WITHOUT_LOCATE=YES
> WITHOUT_LPR=YES
> #WITHOUT_MAIL=YES
> #WITHOUT_MAILWRAPPER=YES
> #WITHOUT_MAKE=YES
> WITHOUT_MAN=YES
> WITHOUT_MAN_UTILS=YES
> WITHOUT_NDIS=YES
> #WITHOUT_NETCAT=YES
> #WITHOUT_NIS=YES
> #WITHOUT_NLS_CATALOGS=YES
> #WITHOUT_NS_CACHING=YES
> WITHOUT_NAND=YES
> WITHOUT_OFED=YES
> WITHOUT_PC_SYSINSTALL=YES
> WITHOUT_PF=YES
> WITHOUT_PKGBOOTSTRAP=YES
> WITHOUT_PMC=YES
> WITHOUT_PORTSNAP=YES
> #WITHOUT_PPP=YES
> WITHOUT_QUOTAS=YES
> WITHOUT_RBOOTD=YES
> WITHOUT_RCMDS=YES
> #WITHOUT_RESCUE=YES
> #WITHOUT_ROUTED=YES
> #WITHOUT_SENDMAIL=YES
> WITHOUT_SHAREDOCS=YES
> WITHOUT_SVNLITE=YES
> WITHOUT_TALK=YES
> #WITHOUT_TCSH=YES
> WITHOUT_TELNET=YES
> WITHOUT_TEXTPROC=YES
> WITHOUT_TFTP=YES
> #WITHOUT_WIRELESS=YES
> WITHOUT_ZFS=YES
> '
> 
> # BUILD and INSTALL!
> # Options to put in make.conf during both build- & installworld.
> # See man src.conf(5) for more details on WITHOUT_ tags.
> CONF_WORLD='
> WITH_KERNEL_RETPOLINE=YES
> WITH_LLVM_TARGET_BPF=YES
> WITHOUT_TESTS=YES
> WITHOUT_TESTS_SUPPORT=YES
> WITHOUT_ASSERT_DEBUG=YES
> WITHOUT_CCD=YES
> #WITHOUT_BINUTILS_BOOTSTRAP=YES
> WITHOUT_DEBUG_FILES=YES
> #WITHOUT_ICONV=YES
> WITHOUT_ISCSI=YES
> WITHOUT_LIB32=YES
> #WITHOUT_LLVM_TARGET_ALL=YES
> WITH_ZONEINFO_LEAPSECONDS_SUPPORT=YES
> WITHOUT_SVN=YES
> WITH_SORT_THREADS=YES
> WITH_EXTRA_TCP_STACKS=YES
> #
> INSTALL_NODEBUG=YES
> '
> 
> 
> 
> - -- 
> O. Hartmann
> 
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
> 
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3sVgAAKCRDS528fyFhY
> lL4MAgCaS8UeE6FwJIeUa5Q+9hf80DJkde+oopttIL2Jz9LcbN1CRU5JTc2jJ9Vb
> vO380RVTNO4M0Ge0M0m2wDCx4xzuAf9YYdjW/xTXbh09YcTlt3l22pn1aaHYrdMk
> pOYA3FUw8xi09cniyQHBOr4mvjKI07GtgLKTEINU3SuS9CmFjCzg
> =vFP+
> -END PGP SIGNATURE-
> __

buildworld failure: Do not include ${SRCTOP}/sys when building bootstrap tools

2018-08-20 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Building NanoBSD world on CURRENT r338113 fails due to:

[...]
cd /pool/sources/CURRENT/src/rescue/rescue/../../sbin/gbde &&  MK_TESTS=no
UPDATE_DEPENDFILE=no  _RECURSING_CRUNCH=1
MAKEOBJDIRPREFIX=/pool/nanobsd/amd64/ALERICH_amd64/pool/sources/CURRENT/src/amd64.amd64/rescue/rescue
make  MK_AUTO_OBJ=no  DIRPRFX=rescue/rescue/gbde/ -DRESCUE 
CRUNCH_CFLAGS=-DRESCUE
MK_AUTO_OBJ=no   obj make[5]: 
"/pool/sources/CURRENT/src/tools/build/mk/Makefile.boot"
line 18: Do not include ${SRCTOP}/sys when building bootstrap tools.  Copy the 
header to
${WORLDTMP}/legacy in tools/build/Makefile instead.  Error was caused by 
Makefile
in /pool/sources/CURRENT/src/sbin/gbde *** [obj_crunchdir_gbde] Error code 1

make[4]: stopped in /pool/sources/CURRENT/src/rescue/rescue
[...]


This problem occured during today's source updates since I was able to build 
the NanoBSD
image I intend to build yesterday ~ r338060.

What is going wrong?

I've set the following for NanoBSD's build and install:

# BUILDWORLD ONLY
# Options to put in make.conf during buildworld only
CONF_BUILD='
CFLAGS=-O3 -pipe
MALLOC_PRODUCTION=YES
INSTALL_NODEBUG=YES
'
# Options to put in make.conf during installworld only
CONF_INSTALL='
WITHOUT_TOOLCHAIN=YES
WITHOUT_CROSS_COMPILER=YES
WITHOUT_DOCCOMPRESS=YES
WITHOUT_INSTALLLIB=YES
WITHOUT_BINUTILS=YES
#
#WITHOUT_ACCT=YES
WITHOUT_AMD=YES
WITHOUT_APM=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_AT=YES
WITHOUT_ATM=YES
WITHOUT_BHYVE=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_BOOTPARAMD=YES
WITHOUT_BOOTPD=YES
WITHOUT_BSDINSTALL=YES
#WITHOUT_BSD_CPIO=YES
#WITHOUT_BSNMP=YES
#WITHOUT_BZIP2=YES
WITHOUT_CALENDAR=YES
#WITHOUT_CCD=YES
WITHOUT_CDDL=YES
WITHOUT_CLANG_FULL=YES
WITHOUT_CTM=YES
#WITHOUT_CUSE=YES
WITHOUT_CXX=YES
WITHOUT_DICT=YES
WITHOUT_DIALOG=YES
WITHOUT_EXAMPLES=YES
WITHOUT_EE=YES
WITHOUT_FINGER=YES
WITHOUT_FLOPPY=YES
WITHOUT_FREEBSD_UPDATE=YES
WITHOUT_FDT=YES
WITHOUT_GAMES=YES
WITHOUT_GCOV=YES
WITHOUT_GDB=YES
WITHOUT_HAST=YES
WITHOUT_HTML=YES
WITHOUT_HYPERV=YES
#WITHOUT_INET6=YES
#WITHOUT_INETD=YES
WITHOUT_IPFILTER=YES
WITHOUT_ISCSI=YES
WITHOUT_KDUMP=YES
WITHOUT_KERNEL_SYMBOLS=YES
#WITHOUT_LDNS=YES
WITHOUT_LOCATE=YES
WITHOUT_LPR=YES
#WITHOUT_MAIL=YES
#WITHOUT_MAILWRAPPER=YES
#WITHOUT_MAKE=YES
WITHOUT_MAN=YES
WITHOUT_MAN_UTILS=YES
WITHOUT_NDIS=YES
#WITHOUT_NETCAT=YES
#WITHOUT_NIS=YES
#WITHOUT_NLS_CATALOGS=YES
#WITHOUT_NS_CACHING=YES
WITHOUT_NAND=YES
WITHOUT_OFED=YES
WITHOUT_PC_SYSINSTALL=YES
WITHOUT_PF=YES
WITHOUT_PKGBOOTSTRAP=YES
WITHOUT_PMC=YES
WITHOUT_PORTSNAP=YES
#WITHOUT_PPP=YES
WITHOUT_QUOTAS=YES
WITHOUT_RBOOTD=YES
WITHOUT_RCMDS=YES
#WITHOUT_RESCUE=YES
#WITHOUT_ROUTED=YES
#WITHOUT_SENDMAIL=YES
WITHOUT_SHAREDOCS=YES
WITHOUT_SVNLITE=YES
WITHOUT_TALK=YES
#WITHOUT_TCSH=YES
WITHOUT_TELNET=YES
WITHOUT_TEXTPROC=YES
WITHOUT_TFTP=YES
#WITHOUT_WIRELESS=YES
WITHOUT_ZFS=YES
'

# BUILD and INSTALL!
# Options to put in make.conf during both build- & installworld.
# See man src.conf(5) for more details on WITHOUT_ tags.
CONF_WORLD='
WITH_KERNEL_RETPOLINE=YES
WITH_LLVM_TARGET_BPF=YES
WITHOUT_TESTS=YES
WITHOUT_TESTS_SUPPORT=YES
WITHOUT_ASSERT_DEBUG=YES
WITHOUT_CCD=YES
#WITHOUT_BINUTILS_BOOTSTRAP=YES
WITHOUT_DEBUG_FILES=YES
#WITHOUT_ICONV=YES
WITHOUT_ISCSI=YES
WITHOUT_LIB32=YES
#WITHOUT_LLVM_TARGET_ALL=YES
WITH_ZONEINFO_LEAPSECONDS_SUPPORT=YES
WITHOUT_SVN=YES
WITH_SORT_THREADS=YES
WITH_EXTRA_TCP_STACKS=YES
#
INSTALL_NODEBUG=YES
'



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3sVgAAKCRDS528fyFhY
lL4MAgCaS8UeE6FwJIeUa5Q+9hf80DJkde+oopttIL2Jz9LcbN1CRU5JTc2jJ9Vb
vO380RVTNO4M0Ge0M0m2wDCx4xzuAf9YYdjW/xTXbh09YcTlt3l22pn1aaHYrdMk
pOYA3FUw8xi09cniyQHBOr4mvjKI07GtgLKTEINU3SuS9CmFjCzg
=vFP+
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


LUA loader: non UEFI boxes have weird ssh output

2018-08-19 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Just updated some boxes to 12-CURRENT r338057 and I face a very strange 
behaviour:

on non-UEFI booting boxes (older Fujitsu and Dell servers from 2008/2009, 
PCengine APU
2C4), logging in via ssh reveals broken output: even top does show nothing, the 
box is
stuck. Calling vi(1) on some files does alos freeze the terminal - no response, 
nothing.
On the PCengine, also applications like Asterisk do not work anymore - not 
output on the
console. The program is running, but stopped servicing. Only the serial console 
to some
of the "ssd-brain-dead" systems work, sshd is dead. This isn't the case on UEFI 
boxes
with the very same revision (r338057).

Is this a coincidence or is this/could this related to the switch to LUA loader?

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3mp7gAKCRDS528fyFhY
lDJaAf9G8h7uEgHkAdWJNjb+QSUpNu1TqF4gqvJ01mVh0eQqtYe8+YTPA5I/8LMb
x7S7HXvRxBSwiL6YB2tNEBgzWTryAgCQ7FzpE1x+gKImVUq+8BYvgCTJEnAYqYlC
79Ib2MRzRU6qxyCi8qiCxoPI/7hCYoO5lbjaVms7ylpJGtMj+wSI
=YIBD
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Sharing compiled builds between multiple 12-CURRENT boxes.

2018-08-19 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sun, 19 Aug 2018 00:34:20 +0200
Dhananjay Balan  schrieb:

> Hi,
> 
> I run 12-CURRENT on few machines, some more powerful that other (all
> of them x86_64, march varies). 
> 
> Is there is a way to avoid building CURRENT on all machines? Rather
> than building everywhere, can I just build it on the big server that I
> have and copy and update my laptop?
> 
> -
> Dhananjay Balan
[...]

Yes, you can.
We do this via a custom build and creating packages as this is introduced at

https://wiki.freebsd.org/PkgBase

But beware! As many others have already stated, take care about to use the 
least common
denominator of achitectural specifications amongst your pools! This means to 
not use any
kind of optimizations for a specific CPU type for pkg-base distributed builds!

Because we build the local OS for fast/server machines always(!) with 
optimisations, the
pkg-base builds are done in a separate way - which is very easy if you've once 
understood
the really neat and great build framework of FreeBSD's!

Instead of building the traditional (probably optimised) system from /usr/src
and /usr/obj, now you've to consider a separate path like 
/pool/sources/CURRENT/src (our
way, since we also try to build packages and object trees for 11.X), then setup 
a small
build script that essentially sets 
 
MAKEOBJDIRPREFIX
KERNCONFDIR
KERNCONF

and especially

__MAKE_CONF
SRCCONF
SRC_ENV_CONF

if you use usually optimisations for the native target build on the building 
host and
more generic binaries for the Intel x86 crap for redistribution.

Doing so, we also perform builds for some ARM64 based experimental boxes.

The next step is then up to you how to distribute. We copy all the pkg stuff 
coming out
of the build cycle to a folder which is accessible by pkg via HTTP(S) - so 
www/apache24
is our platform to redistribute the binaries over the network and even to 
remote sites
(beware of the security implications!). You also can distribute the obj-folder 
(/usr/obj,
or, if using another approach, like /pool/sources/CURRENT/obj) via NFS.

Once you've understood the (easy to learn) concept of building the source tree, 
creating
the packages for pkg-base and having dealt with the more labor for the setting 
of a
distribution server, you can use the most potent server/box on you network for 
building
dedicated distributions

Even a "Release" build is possible as long as there are not pitfalls like they 
occured
during the transition from 11.X to more 12-CURRENT spcific development (i.e. 
LINT).

If you use pkg-base as mentioned above, be aware to setup a proper pkg.conf 
file as
introduced on the Wiki and please be also aware of the fact, that there is at 
the moment
no sharp separation between pkg-base and oridnary pkg for packages - so take the
warinig serious, that pkg delete -a will not only kill all packages, it also 
will kill
all packages installed for the base system!

Once installed you'll see how fast compared to source build the pkg-base 
installation
is (although I still prefer source build, optimised builds ...).

And by the way: depending on the sophistication of your build script for 
dedicated
tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're able 
to also
build optimised binary trees for different CPU types, but you have to deal 
yourself
with the fact that you've to put the binaries into a proper place and then 
delegate the
URI in pkg.conf to the correct branch of your tree. The ABI environmental 
variable
doesn't take care of the "set" you may have used to optimise. But this is 
something
you're able to deal with easily yourself after having setup your basic build
environment.

Regards,

oh   

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY
lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2
PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG
9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM
=/rzO
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

2018-08-15 Thread O. Hartmann
On Tue, 14 Aug 2018 20:41:03 -0700
Pete Wright  wrote:

> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:  
> >> i also attempted to boot using UEFI but the system hangs very early in the
> >> boot process.  i have reverted to legacy mode for now so that i can work,
> >> but am keen to test out any patches or do any other debugging that is
> >> needed.  
> > Hi Pete,
> >
> > Where in the process does it hang with UEFI? I can't help much with
> > any of your other problems, but I am curious about this one. =)  
> sure thing - the last several lines are:
> 
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0

Similar situation same here on a Lenovo ThinkPad E540, except that the netmpa
message occurs prior to "random: fast provider: "Intel Secure Key RNG"


> 
> at this point it hangs.  let me know if you want me to try booting with 
> verbose output to dmesg or something.
> 
> 
> cheers,
> -pete
> 
>

Other UEFI booting systems (oldish Asrock Z77-Pro4/Pro4-M) throw some infos
shortly after booting the kernel which look like the stuff I can see from the
UEFI loader very early - but it is to fast to catch with the naked eye. The
boxes reboot and spinning booting this way. 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: EFIRT on machines with pcid after r337773

2018-08-15 Thread O. Hartmann
On Wed, 15 Aug 2018 01:17:55 +0300
Konstantin Belousov  wrote:

> If you use UEFI boot, have EFIRT compiled in kernel (the case of
> GENERIC) or pre-loaded as module, and efirt is not disabled by a tunable,
> and the machine resets during kernel initialization, try this.
> 
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index d5d795ab502..c9334eab916 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -1188,7 +1188,7 @@ pmap_bootstrap(vm_paddr_t *firstaddr)
>   kernel_pmap->pm_pcids[i].pm_pcid = PMAP_PCID_KERN;
>   kernel_pmap->pm_pcids[i].pm_gen = 1;
>   }
> - PCPU_SET(pcid_next, PMAP_PCID_KERN + 1);
> + PCPU_SET(pcid_next, PMAP_PCID_KERN + 2);
>   PCPU_SET(pcid_gen, 1);
>   /*
>* pcpu area for APs is zeroed during AP startup.
> @@ -2651,8 +2651,8 @@ pmap_pinit0(pmap_t pmap)
>   bzero(>pm_stats, sizeof pmap->pm_stats);
>   pmap->pm_flags = pmap_flags;
>   CPU_FOREACH(i) {
> - pmap->pm_pcids[i].pm_pcid = PMAP_PCID_NONE;
> - pmap->pm_pcids[i].pm_gen = 0;
> + pmap->pm_pcids[i].pm_pcid = PMAP_PCID_KERN + 1;
> + pmap->pm_pcids[i].pm_gen = 1;
>   if (!pti) {
>   __pcpu[i].pc_kcr3 = PMAP_NO_CR3;
>   __pcpu[i].pc_ucr3 = PMAP_NO_CR3;
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Is this patch going to hit the tree soon? Since it seems crucial to UEFI
booting systems having options EFIRT set in the kernel (as GENERIC does).

Regards,

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection

2018-08-14 Thread O. Hartmann
On Tue, 14 Aug 2018 20:41:03 -0700
Pete Wright  wrote:

> On 8/14/18 6:13 PM, Kyle Evans wrote:
> > On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright  wrote:  
> >> i also attempted to boot using UEFI but the system hangs very early in the
> >> boot process.  i have reverted to legacy mode for now so that i can work,
> >> but am keen to test out any patches or do any other debugging that is
> >> needed.  
> > Hi Pete,
> >
> > Where in the process does it hang with UEFI? I can't help much with
> > any of your other problems, but I am curious about this one. =)  
> sure thing - the last several lines are:
> 
> random: fast provider: "Intel Secure Key RNG"
> kbd1 at kbdmux0
> netmap: loaded module
> nexus0

Similar situation same here on a Lenovo ThinkPad E540, except that the netmpa
message occurs prior to "random: fast provider: "Intel Secure Key RNG"


> 
> at this point it hangs.  let me know if you want me to try booting with 
> verbose output to dmesg or something.
> 
> 
> cheers,
> -pete
> 
>

Other UEFI booting systems (oldish Asrock Z77-Pro4/Pro4-M) throw some infos
shortly after booting the kernel which look like the stuff I can see from the
UEFI loader very early - but it is to fast to catch with the naked eye. The
boxes reboot and spinning booting this way. 


Addon: this is with CURRENT r337832

Last known working version for me is: r337718

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: svn commit: r336940 - in head/sys: netinet netinet6 [This broke ci.freebsd.org 's FreeBSD-head-mips*-build 's]

2018-07-30 Thread O. Hartmann
On Mon, 30 Jul 2018 18:44:24 -0700
Mark Millard via svn-src-head  wrote:

> https://ci.freebsd.org/job/FreeBSD-head-mips-build/3577/consoleText shows:
> 
> --- tcp_usrreq.o ---
> cc1: warnings being treated as errors
> /usr/src/sys/netinet/tcp_usrreq.c: In function 'tcp_usr_send':
> /usr/src/sys/netinet/tcp_usrreq.c:905: warning: unused variable
> 'sin' [-Wunused-variable] . . .
> --- tcp_usrreq.o ---
> *** [tcp_usrreq.o] Error code 1
> 
> make[2]: stopped in /usr/obj/usr/src/mips.mips/sys/MALTA
> 1 error
> 
> (Note: -r366935 built correctly as #3576 .)
> 
> 
> 
> https://ci.freebsd.org/job/FreeBSD-head-mips64-build/3624/consoleText shows:
> 
> --- tcp_usrreq.o ---
> cc1: warnings being treated as errors
> /usr/src/sys/netinet/tcp_usrreq.c: In function 'tcp_usr_send':
> /usr/src/sys/netinet/tcp_usrreq.c:905: warning: unused variable
> 'sin' [-Wunused-variable] *** [tcp_usrreq.o] Error code 1
> 
> make[2]: stopped in /usr/obj/usr/src/mips.mips64/sys/MALTA64
> 
> (Note: -r366935 built correctly as #3623 .)
> 
> 
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)

This broke also AMD64 builds.

Regards
oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: console spam during mergemaster

2018-07-29 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sun, 29 Jul 2018 08:58:47 -0400
Michael Butler  schrieb:

> This started a few days ago .. no apparent ill effect but still annoying ..
> 
> *** Creating the temporary root environment in /var/tmp/temproot
>  *** /var/tmp/temproot ready for use
>  *** Creating and populating directory structure in /var/tmp/temproot
> 
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 29: warning: duplicate
> script for target "/var/tmp/temproot/etc/periodic/daily" ignored
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: using
> previous script for "/var/tmp/temproot/etc/periodic/daily" defined here
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: duplicate
> script for target "/var/tmp/temproot/etc/periodic/daily" ignored
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: using
> previous script for "/var/tmp/temproot/etc/periodic/daily" defined here
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 29: warning: duplicate
> script for target "/var/tmp/temproot/etc/periodic/monthly" ignored
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: using
> previous script for "/var/tmp/temproot/etc/periodic/monthly" defined here
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: duplicate
> script for target "/var/tmp/temproot/etc/periodic/monthly" ignored
> make[4]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: using
> previous script for "/var/tmp/temproot/etc/periodic/monthly" defined here
> make[3]: "/usr/src/share/mk/bsd.dirs.mk" line 29: warning: duplicate
> script for target "/var/tmp/temproot/etc/pam.d" ignored
> make[3]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: using
> previous script for "/var/tmp/temproot/etc/pam.d" defined here
> make[3]: "/usr/src/share/mk/bsd.dirs.mk" line 31: warning: duplicate
> script for target "/var/tmp/temproot/etc/pam.d" ignored
> 
>   imb
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

me, too

Regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW127wgAKCRDS528fyFhY
lDBdAf4mFhRmAWPot0FZZ6+/Z8TuTej/zrcxTs5S0sAQOzTHmoFu43huiwUJbs6Z
8DMEik2T+ynJf4ocf1+UxAkyNKgmAf0e7aerKYCqGKg5QCP3zSS3TpdERnxWPVMn
b/LVa0kyJzzU1vnxBhj9LNoCrAlIV27J8JtxNP7db9Csvygaks7/
=e7SV
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: EFI issues

2018-07-29 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sun, 29 Jul 2018 15:17:53 +0400
Roman Bogorodskiy  schrieb:

>   O. Hartmann wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Sun, 29 Jul 2018 12:09:58 +0400
> > Roman Bogorodskiy  schrieb:
> >   
> > >   O. Hartmann wrote:
> > >   
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA512
> > > > 
> > > > Am Sat, 28 Jul 2018 11:29:40 +0400
> > > > Roman Bogorodskiy  schrieb:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > I have a test box that's updated to -CURRENT usually once in a week or
> > > > > two. This box boots using UEFI. After a regular update about two weeks
> > > > > ago it started to panic on boot frequently (not UEFI related), but I
> > > > > could not get a crash dump because my swap partition was too small. 
> > > > > So I
> > > > > moved data to the backup drive, repartitioned the main drive and boot
> > > > > again. This went fine, so I decided to upgrade to fresh -CURRENT from
> > > > > ~Jul 27th. Booting with the new kernel went fine, but after 
> > > > > installworld
> > > > > machine stopped booting, and on the screen I see:
> > > > > 
> > > > > FreeBSD/amd64 EFI loader, ...
> > > > > 
> > > > > ..
> > > > > 
> > > > > BootOrder: 
> > > > > 
> > > > > And then it gets stuck and nothing happens.
> > > > > 
> > > > > As I already have a fresh backup, I decided that it'd be easier to
> > > > > just re-install and copy data back over (maybe I messed up with
> > > > > repartitioning). So I've downloaded a fresh snapshot:
> > > > > 
> > > > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img
> > > > > 
> > > > > And re-installed. In the installer I choose all the same settings that
> > > > > were before: UEFI + GPT, default partition scheme it suggested (efi
> > > > > followed by freebsd-ufs followed by freebsd-swap), just increased the
> > > > > swap size.
> > > > > 
> > > > > And the newly installed system won't boot just like a previous one:
> > > > > 
> > > > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg
> > > > > 
> > > > > Is there a way to recover this?
> > > > > 
> > > > > Roman Bogorodskiy
> > > > 
> > > > Just curious:
> > > > 
> > > > When I installed FreeBSD last time from the recent (2018-07-26) USB 
> > > > flash drive
> > > > on a SSD, the freebsd-swap partition followed immediately after the ESP 
> > > > and/or
> > > > freebsd-boot GPT loader partition. But in most cases I used to use ZFS 
> > > > for
> > > > testing.
> > > 
> > > When I reinstalled it yesterday from -CURRENT snapshot mentioned above,
> > > in guided mode it suggested a similar partitioning schema that I use:
> > >   
> > > =>40  1953525088  ada0  GPT  (932G)
> > >   40  409600 1  efi  (200M)
> > >   409640  1803550720 2  freebsd-ufs  (860G)
> > >   1803960360   148897792 3  freebsd-swap  (71G)
> > >   1952858152  666976- free -  (326M)
> > > 
> > > The only difference it that the freebsd-swap size was 3.5G (and
> > > therefore, freebsd-ufs is large), the order was the same.
> > >   
> > > > Since I had my UEFI adventure of my own these days and received 
> > > > valuable hints
> > > > from the development/maintenance team on some UEFI aspects, it would be 
> > > > of
> > > > interest to know your recent hardware and, more importantly since I see 
> > > > the boot
> > > > order presented in you screenshot, a dump of the efi variable settings. 
> > > > Just for
> > > > curiosity. For that, you have to boot the recent USB flash drive image 
> > > > with
> > > > UEFI-only, then logon as root and perform
> > > > 
> > > > kldload efirt
> > > > 
> > > > and then issue 
> > > > 
> > > > # efibootmgr -v
> > > > 
> > > > In my case, it looks like
> > > 

Re: EFI issues

2018-07-29 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sun, 29 Jul 2018 12:09:58 +0400
Roman Bogorodskiy  schrieb:

>   O. Hartmann wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Sat, 28 Jul 2018 11:29:40 +0400
> > Roman Bogorodskiy  schrieb:
> >   
> > > Hi,
> > > 
> > > I have a test box that's updated to -CURRENT usually once in a week or
> > > two. This box boots using UEFI. After a regular update about two weeks
> > > ago it started to panic on boot frequently (not UEFI related), but I
> > > could not get a crash dump because my swap partition was too small. So I
> > > moved data to the backup drive, repartitioned the main drive and boot
> > > again. This went fine, so I decided to upgrade to fresh -CURRENT from
> > > ~Jul 27th. Booting with the new kernel went fine, but after installworld
> > > machine stopped booting, and on the screen I see:
> > > 
> > > FreeBSD/amd64 EFI loader, ...
> > > 
> > > ..
> > > 
> > > BootOrder: 
> > > 
> > > And then it gets stuck and nothing happens.
> > > 
> > > As I already have a fresh backup, I decided that it'd be easier to
> > > just re-install and copy data back over (maybe I messed up with
> > > repartitioning). So I've downloaded a fresh snapshot:
> > > 
> > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img
> > > 
> > > And re-installed. In the installer I choose all the same settings that
> > > were before: UEFI + GPT, default partition scheme it suggested (efi
> > > followed by freebsd-ufs followed by freebsd-swap), just increased the
> > > swap size.
> > > 
> > > And the newly installed system won't boot just like a previous one:
> > > 
> > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg
> > > 
> > > Is there a way to recover this?
> > > 
> > > Roman Bogorodskiy  
> > 
> > Just curious:
> > 
> > When I installed FreeBSD last time from the recent (2018-07-26) USB flash 
> > drive on a
> > SSD, the freebsd-swap partition followed immediately after the ESP and/or
> > freebsd-boot GPT loader partition. But in most cases I used to use ZFS for 
> > testing.  
> 
> When I reinstalled it yesterday from -CURRENT snapshot mentioned above,
> in guided mode it suggested a similar partitioning schema that I use:
> 
> =>40  1953525088  ada0  GPT  (932G)  
>   40  409600 1  efi  (200M)
>   409640  1803550720 2  freebsd-ufs  (860G)
>   1803960360   148897792 3  freebsd-swap  (71G)
>   1952858152  666976- free -  (326M)
> 
> The only difference it that the freebsd-swap size was 3.5G (and
> therefore, freebsd-ufs is large), the order was the same.
> 
> > Since I had my UEFI adventure of my own these days and received valuable 
> > hints from
> > the development/maintenance team on some UEFI aspects, it would be of 
> > interest to
> > know your recent hardware and, more importantly since I see the boot order 
> > presented
> > in you screenshot, a dump of the efi variable settings. Just for curiosity. 
> > For that,
> > you have to boot the recent USB flash drive image with UEFI-only, then 
> > logon as root
> > and perform
> > 
> > kldload efirt
> > 
> > and then issue 
> > 
> > # efibootmgr -v
> > 
> > In my case, it looks like
> > 
> > [...]
> > [ohartmann]: sudo efibootmgr -v
> > BootCurrent: 0001
> > Timeout: 3 seconds
> > BootOrder  : 0001, 0002, 0003, 0004, 0005, 
> > +Boot0001* FreeBSD-12 \
> >
> > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi)
> > \ ada0p1:/efi/boot/BOOTx64.efi (null) 
> >  Boot0002* Hard Drive  BBS(HD,,0x0)
> >  Boot0003* CD/DVD Drive  BBS(CDROM,,0x0)
> >  Boot0004* USB  BBS(USB,,0x0)
> >  Boot0005* Network Card  BBS(Network,,0x0)
> >  Boot  FreeBSD-12
> > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi)
> > ada0p1:/efi/boot/BOOTx64.efi (null)
> > 
> > 
> > Unreferenced Variables:
> > [...]
> > 
> > Boot is the same as Boot0001 and is defined due to some "bug" Warner 
> > Losh has
> > fixed recently, it is the same as Boot0001  
> 
> Motherboard is (from dmidecode):
> 
> Handle 0x, DMI type 0, 24 bytes
> BIOS Information
> Vendor: American Megatrends Inc.
> Version: 0806
>  

Re: EFI issues

2018-07-29 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sat, 28 Jul 2018 11:29:40 +0400
Roman Bogorodskiy  schrieb:

> Hi,
> 
> I have a test box that's updated to -CURRENT usually once in a week or
> two. This box boots using UEFI. After a regular update about two weeks
> ago it started to panic on boot frequently (not UEFI related), but I
> could not get a crash dump because my swap partition was too small. So I
> moved data to the backup drive, repartitioned the main drive and boot
> again. This went fine, so I decided to upgrade to fresh -CURRENT from
> ~Jul 27th. Booting with the new kernel went fine, but after installworld
> machine stopped booting, and on the screen I see:
> 
> FreeBSD/amd64 EFI loader, ...
> 
> ..
> 
> BootOrder: 
> 
> And then it gets stuck and nothing happens.
> 
> As I already have a fresh backup, I decided that it'd be easier to
> just re-install and copy data back over (maybe I messed up with
> repartitioning). So I've downloaded a fresh snapshot:
> 
> FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img
> 
> And re-installed. In the installer I choose all the same settings that
> were before: UEFI + GPT, default partition scheme it suggested (efi
> followed by freebsd-ufs followed by freebsd-swap), just increased the
> swap size.
> 
> And the newly installed system won't boot just like a previous one:
> 
> https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg
> 
> Is there a way to recover this?
> 
> Roman Bogorodskiy

Just curious:

When I installed FreeBSD last time from the recent (2018-07-26) USB flash drive 
on a SSD,
the freebsd-swap partition followed immediately after the ESP and/or 
freebsd-boot GPT
loader partition. But in most cases I used to use ZFS for testing.

Since I had my UEFI adventure of my own these days and received valuable hints 
from the
development/maintenance team on some UEFI aspects, it would be of interest to 
know your
recent hardware and, more importantly since I see the boot order presented in 
you
screenshot, a dump of the efi variable settings. Just for curiosity. For that, 
you have
to boot the recent USB flash drive image with UEFI-only, then logon as root and 
perform

kldload efirt

and then issue 

# efibootmgr -v

In my case, it looks like

[...]
[ohartmann]: sudo efibootmgr -v
BootCurrent: 0001
Timeout: 3 seconds
BootOrder  : 0001, 0002, 0003, 0004, 0005, 
+Boot0001* FreeBSD-12 \
   
HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi)
 \
   ada0p1:/efi/boot/BOOTx64.efi (null) 
 Boot0002* Hard Drive  BBS(HD,,0x0)
 Boot0003* CD/DVD Drive  BBS(CDROM,,0x0)
 Boot0004* USB  BBS(USB,,0x0)
 Boot0005* Network Card  BBS(Network,,0x0)
 Boot  FreeBSD-12
HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/File(\efi\boot\BOOTx64.efi)
ada0p1:/efi/boot/BOOTx64.efi (null)


Unreferenced Variables:
[...]

Boot is the same as Boot0001 and is defined due to some "bug" Warner Losh 
has fixed
recently, it is the same as Boot0001

Kind regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW11wfgAKCRDS528fyFhY
lMojAf929USx1x7I/sSGLtEWKO8rm9IXf1JEpQ7GSdI6YHid364x7fbrUBhDZYuT
JVanY57Li2oLOXogHtMw6eDUyD+aAf9GTE30LUNRhmcJ7el62Vwpm0oUBG2as52i
+v58EZ9c20yKQKuXt446dhbILyODDPKmc9ykAvnE0TtMiTHk6vRn
=M7vi
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [UEFI] Boot issues on some UEFI implementations

2018-07-27 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 27 Jul 2018 13:59:44 +0300
Toomas Soome  schrieb:

> > On 27 Jul 2018, at 13:02, O. Hartmann  wrote:
> > 
> > On Fri, 27 Jul 2018 08:54:48 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> >>> 
> >>> On Thu, 26 Jul 2018 19:23:43 +0300
> >>> Toomas Soome  wrote:
> >>> 
> >>> (reply inline/at the end)
> >>> 
> >>>   
> >>>>> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> >>>>> 
> >>>>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> >>>>> "Rodney W. Grimes"  >>>>> <mailto:freebsd-...@pdx.rh.cn85.dnsmgr.net>> wrote: 
> >>>>>>>> On 25 Jul 2018, at 12:10, O. Hartmann  
> >>>>>>>> wrote:
> >>>>>>>> 
> >>>>>>>> On Wed, 25 Jul 2018 11:46:07 +0300
> >>>>>>>> Toomas Soome  wrote:
> >>>>>>>>   
> >>>>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann  
> >>>>>>>>>> wrote:
> >>>>>>>>>> 
> >>>>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>>>>>>>>> Toomas Soome  wrote:
> >>>>>>>>>> 
> >>>>>>>>>> 
> >>>>>>>>>> Hello  Toomas Soome,
> >>>>>>>>>> 
> >>>>>>>>>> I CC Allan Jude since I discovered something  weird today regarding
> >>>>>>>>>> the UEFI boot capabilities of USB flash devices and SSDs. See 
> >>>>>>>>>> below.
> >>>>>>>>>>   
> >>>>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann 
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>> 
> >>>>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>>>>>>>>>>> Toomas Soome  wrote:
> >>>>>>>>>>>>   
> >>>>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann 
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>>>>>>>>>>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>>>>>>>>>>>>   
> >>>>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann 
> >>>>>>>>>>>>>>>>  >>>>>>>>>>>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>>>>>>>>>>>>> Hash: SHA512
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>>>>>>>>>>>>> Toomas Soome mailto:tso...@me.com>
> >>>>>>>>>>>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>>
> >>>>>>>>>>>>>>>> schrieb: 
> >>>>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann
> >>>>>>>>>>>>>>>>>>  wrote:
> >>>>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot 
> >>>>>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>> on GPT drives where the first partition begins at block 40
> >>>>>>>>>>>>>>>>>> of the hdd/ssd.
> >>>>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>>>> I have two host in private use ba

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-27 Thread O. Hartmann
On Fri, 27 Jul 2018 08:54:48 +0300
Toomas Soome  wrote:

> > On 27 Jul 2018, at 08:46, O. Hartmann  wrote:
> > 
> > On Thu, 26 Jul 2018 19:23:43 +0300
> > Toomas Soome  wrote:
> > 
> > (reply inline/at the end)
> > 
> >   
> >>> On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> >>> 
> >>> On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> >>> "Rodney W. Grimes"  >>> <mailto:freebsd-...@pdx.rh.cn85.dnsmgr.net>> wrote:   
> >>>>>> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> >>>>>> 
> >>>>>> On Wed, 25 Jul 2018 11:46:07 +0300
> >>>>>> Toomas Soome  wrote:
> >>>>>>   
> >>>>>>>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >>>>>>>> 
> >>>>>>>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>>>>>>> Toomas Soome  wrote:
> >>>>>>>> 
> >>>>>>>> 
> >>>>>>>> Hello  Toomas Soome,
> >>>>>>>> 
> >>>>>>>> I CC Allan Jude since I discovered something  weird today regarding
> >>>>>>>> the UEFI boot capabilities of USB flash devices and SSDs. See below.
> >>>>>>>>   
> >>>>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann 
> >>>>>>>>>> wrote:
> >>>>>>>>>> 
> >>>>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>>>>>>>>> Toomas Soome  wrote:
> >>>>>>>>>>   
> >>>>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann 
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>> 
> >>>>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>>>>>>>>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>>>>>>>>>>   
> >>>>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann  >>>>>>>>>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>>>>>>>>>>> Hash: SHA512
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>>>>>>>>>>> Toomas Soome mailto:tso...@me.com>
> >>>>>>>>>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>>
> >>>>>>>>>>>>>> schrieb:   
> >>>>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann
> >>>>>>>>>>>>>>>>  wrote:
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems
> >>>>>>>>>>>>>>>> on GPT drives where the first partition begins at block 40
> >>>>>>>>>>>>>>>> of the hdd/ssd.
> >>>>>>>>>>>>>>>> 
> >>>>>>>>>>>>>>>> I have two host in private use based on an
> >>>>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
> >>>>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates
> >>>>>>>>>>>>>>>> official available AMI firmware revision, dating to 2013.
> >>>>>>>>>>>>>>>> This is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for
> >>>>>>>>>>>>>>>> the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a
> >>>>>>>>>>>>>>>> BETA revision for the Spectre/Meltdown mitigation is
> >>>>>>>>>>>>>>>> available, but I didn't test that. But please read.
> >>>>>>>>>>>>>>>> 
> >>>>

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-26 Thread O. Hartmann
On Thu, 26 Jul 2018 19:23:43 +0300
Toomas Soome  wrote:

(reply inline/at the end)


> > On 26 Jul 2018, at 16:58, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
> > "Rodney W. Grimes"  > <mailto:freebsd-...@pdx.rh.cn85.dnsmgr.net>> wrote: 
> >>>> On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> >>>> 
> >>>> On Wed, 25 Jul 2018 11:46:07 +0300
> >>>> Toomas Soome  wrote:
> >>>>   
> >>>>>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >>>>>> 
> >>>>>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>>>>> Toomas Soome  wrote:
> >>>>>> 
> >>>>>> 
> >>>>>> Hello  Toomas Soome,
> >>>>>> 
> >>>>>> I CC Allan Jude since I discovered something  weird today regarding the
> >>>>>> UEFI boot capabilities of USB flash devices and SSDs. See below.
> >>>>>>   
> >>>>>>>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> >>>>>>>> 
> >>>>>>>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>>>>>>> Toomas Soome  wrote:
> >>>>>>>>   
> >>>>>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann 
> >>>>>>>>>> wrote:
> >>>>>>>>>> 
> >>>>>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>>>>>>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>>>>>>>>   
> >>>>>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann  >>>>>>>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>>>>>>>>> 
> >>>>>>>>>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>>>>>>>>> Hash: SHA512
> >>>>>>>>>>>> 
> >>>>>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>>>>>>>>> Toomas Soome mailto:tso...@me.com>
> >>>>>>>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>> schrieb: 
> >>>>>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann 
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on
> >>>>>>>>>>>>>> GPT drives where the first partition begins at block 40 of the
> >>>>>>>>>>>>>> hdd/ssd.
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> I have two host in private use based on an
> >>>>>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
> >>>>>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates
> >>>>>>>>>>>>>> official available AMI firmware revision, dating to 2013. This
> >>>>>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
> >>>>>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
> >>>>>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I didn't
> >>>>>>>>>>>>>> test that. But please read.
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu
> >>>>>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
> >>>>>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525).
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall
> >>>>>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned device
> >>>>>>>>>>>>>> fails. The ASRock boards jump immed

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-26 Thread O. Hartmann
On Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> > > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > > 
> > > On Wed, 25 Jul 2018 11:46:07 +0300
> > > Toomas Soome  wrote:
> > >   
> > >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> > >>> 
> > >>> On Tue, 24 Jul 2018 08:53:36 +0300
> > >>> Toomas Soome  wrote:
> > >>> 
> > >>> 
> > >>> Hello  Toomas Soome,
> > >>> 
> > >>> I CC Allan Jude since I discovered something  weird today regarding the
> > >>> UEFI boot capabilities of USB flash devices and SSDs. See below.
> > >>>   
> > >>>>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > >>>>> 
> > >>>>> On Mon, 23 Jul 2018 10:56:04 +0300
> > >>>>> Toomas Soome  wrote:
> > >>>>>   
> > >>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann 
> > >>>>>>> wrote:
> > >>>>>>> 
> > >>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> > >>>>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> > >>>>>>>   
> > >>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann  > >>>>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> > >>>>>>>>> 
> > >>>>>>>>> -BEGIN PGP SIGNED MESSAGE-
> > >>>>>>>>> Hash: SHA512
> > >>>>>>>>> 
> > >>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> > >>>>>>>>> Toomas Soome mailto:tso...@me.com>
> > >>>>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>> schrieb:   
> > >>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann 
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>> 
> > >>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on
> > >>>>>>>>>>> GPT drives where the first partition begins at block 40 of the
> > >>>>>>>>>>> hdd/ssd.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> I have two host in private use based on an
> > >>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge,
> > >>>>>>>>>>> Socket LGA1155). Both boards are equipted with the lates
> > >>>>>>>>>>> official available AMI firmware revision, dating to 2013. This
> > >>>>>>>>>>> is for the Z77-Pro4-M revision 2.0 (2013/7/23) and for the Z77
> > >>>>>>>>>>> Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
> > >>>>>>>>>>> for the Spectre/Meltdown mitigation is available, but I didn't
> > >>>>>>>>>>> test that. But please read.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu
> > >>>>>>>>>>> Esprimo Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for
> > >>>>>>>>>>> 3413-A1x, date 05/25/2018 (or 20180525).
> > >>>>>>>>>>> 
> > >>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall
> > >>>>>>>>>>> the OS using UEFI-only boot method on a GPT partitioned device
> > >>>>>>>>>>> fails. The ASRock boards jump immediately into the firmware,
> > >>>>>>>>>>> the Fujitsu offers some kind of CPU/Memory/HDD test facility.
> > >>>>>>>>>>> 
> > >>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot
> > >>>>>>>>>>> only is implied, the MBR partitioned FreeBSD installation USB
> > >>>>>>>>>>> flash device does boot in UEFI! I guess I can assume this when
> > >>>>>>>>>>> the well known clumsy 80x25 char console suddenly gets 

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-25 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 25 Jul 2018 12:26:13 +0300
Toomas Soome  schrieb:

> > On 25 Jul 2018, at 12:10, O. Hartmann  wrote:
> > 
> > On Wed, 25 Jul 2018 11:46:07 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> >>> 
> >>> On Tue, 24 Jul 2018 08:53:36 +0300
> >>> Toomas Soome  wrote:
> >>> 
> >>> 
> >>> Hello  Toomas Soome,
> >>> 
> >>> I CC Allan Jude since I discovered something  weird today regarding the 
> >>> UEFI
> >>> boot capabilities of USB flash devices and SSDs. See below.
> >>>   
> >>>>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> >>>>> 
> >>>>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>>>> Toomas Soome  wrote:
> >>>>>   
> >>>>>>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>>>>>> 
> >>>>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>>>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>>>>>   
> >>>>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann  >>>>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>>>>>> 
> >>>>>>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>>>>>> Hash: SHA512
> >>>>>>>>> 
> >>>>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>>>>>> Toomas Soome mailto:tso...@me.com>
> >>>>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>> schrieb:   
> >>>>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann 
> >>>>>>>>>>> wrote:
> >>>>>>>>>>> 
> >>>>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on 
> >>>>>>>>>>> GPT
> >>>>>>>>>>> drives where the first partition begins at block 40 of the 
> >>>>>>>>>>> hdd/ssd.
> >>>>>>>>>>> 
> >>>>>>>>>>> I have two host in private use based on an
> >>>>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, 
> >>>>>>>>>>> Socket
> >>>>>>>>>>> LGA1155). Both boards are equipted with the lates official 
> >>>>>>>>>>> available
> >>>>>>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M
> >>>>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8
> >>>>>>>>>>> (2013/7/17). For both boards a BETA revision for the
> >>>>>>>>>>> Spectre/Meltdown mitigation is available, but I didn't test that.
> >>>>>>>>>>> But please read.
> >>>>>>>>>>> 
> >>>>>>>>>>> The third box I realised this problem is a brand new Fujitsu 
> >>>>>>>>>>> Esprimo
> >>>>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>>>>>>>>>> 05/25/2018 (or 20180525).
> >>>>>>>>>>> 
> >>>>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall 
> >>>>>>>>>>> the
> >>>>>>>>>>> OS using UEFI-only boot method on a GPT partitioned device fails.
> >>>>>>>>>>> The ASRock boards jump immediately into the firmware, the Fujitsu
> >>>>>>>>>>> offers some kind of CPU/Memory/HDD test facility.
> >>>>>>>>>>> 
> >>>>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot 
> >>>>>>>>>>> only
> >>>>>>>>>>> is implied, the MBR partitioned FreeBSD installation USB flash
> >>>>>>>>>>> device does boot in UEFI! I guess I can assume this when the well
> >>>>>>>>>>> known clumsy 80x25 char console suddenly g

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-25 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Wed, 25 Jul 2018 07:30:32 -0700 (PDT)
"Rodney W. Grimes"  schrieb:

[...]

> > Yea, i was hoping fstyp command would report the FAT type, but it does not 
> > (request
> > for feature?:)  
> 
> FYI, the file(1) command is very good at disecting a disk image to tell
> you what the MBR looks like, and at looking at partitions if pointed at
> them with the -s option.  It should be able to detect FAT12/16/32.
> 
> root@x230a:/home/ISO/x # file -s /dev/md2s1
> /dev/md2s1: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "BSD4.4  ", root 
> entries
> 512, sectors 1600 (volumes <=32 MB) , sectors/FAT 5, sectors/track 63, heads 
> 1, serial
> number 0xbd4111ee, label: "EFISYS ", FAT (12 bit), followed by FAT

Thanks for this very helpful hint!

> 
> > 
> > However, the more annoying idea would be to install some OS which will boot 
> > with UEFI
> > on this machine, then copy boot1.efi from freebsd to it (the default 
> > program the UEFI
> > will load is ESP:EFI/boot/bootx64.efi  in case of UEFI64 and
> > ESP:EFI/boot/bootia32.efi for EFI32. However, we do not support EFI32.
> > 
> > note that boot1.efi alone will not do much but printing on screen how it 
> > will search
> > for freebsd, but for the purpose of the test it would suffice - that would 
> > give us
> > confirmed working ESP file system (since the other os would be able to 
> > boot) and then
> > we can confirm if boot1.efi itself is OK.  
> 



- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW1i2PwAKCRDS528fyFhY
lFz5Af9MY41hoAND4OoKCOwExAM7oQYVCpHSz+mo94OBVqSCqcnprdvdE2C1+PiN
Uza7lMvB8KVSqcyxuYbIFD0E5A4bAgCk/lzKwE9hTPBt4gdBx4t7N/XPafOEBEGM
8irGozKbAvikSkhAQTMPtwyE+861AvKy2Dw1o+mQo4AfikJI0dgq
=9cKL
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [UEFI] Boot issues on some UEFI implementations

2018-07-25 Thread O. Hartmann
On Wed, 25 Jul 2018 11:46:07 +0300
Toomas Soome  wrote:

> > On 25 Jul 2018, at 10:59, O. Hartmann  wrote:
> > 
> > On Tue, 24 Jul 2018 08:53:36 +0300
> > Toomas Soome  wrote:
> > 
> > 
> > Hello  Toomas Soome,
> > 
> > I CC Allan Jude since I discovered something  weird today regarding the UEFI
> > boot capabilities of USB flash devices and SSDs. See below.
> >   
> >>> On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> >>> 
> >>> On Mon, 23 Jul 2018 10:56:04 +0300
> >>> Toomas Soome  wrote:
> >>>   
> >>>>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>>>> 
> >>>>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>>>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>>>   
> >>>>>>> On 13 Jul 2018, at 17:44, O. Hartmann  >>>>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>>>> 
> >>>>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>>>> Hash: SHA512
> >>>>>>> 
> >>>>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>>>> Toomas Soome mailto:tso...@me.com>
> >>>>>>> <mailto:tso...@me.com <mailto:tso...@me.com>>> schrieb: 
> >>>>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann 
> >>>>>>>>> wrote:
> >>>>>>>>> 
> >>>>>>>>> The problem is some kind of weird. I face UEFI boot problems on GPT
> >>>>>>>>> drives where the first partition begins at block 40 of the hdd/ssd.
> >>>>>>>>> 
> >>>>>>>>> I have two host in private use based on an
> >>>>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> >>>>>>>>> LGA1155). Both boards are equipted with the lates official available
> >>>>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M
> >>>>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8
> >>>>>>>>> (2013/7/17). For both boards a BETA revision for the
> >>>>>>>>> Spectre/Meltdown mitigation is available, but I didn't test that.
> >>>>>>>>> But please read.
> >>>>>>>>> 
> >>>>>>>>> The third box I realised this problem is a brand new Fujitsu Esprimo
> >>>>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>>>>>>>> 05/25/2018 (or 20180525).
> >>>>>>>>> 
> >>>>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall the
> >>>>>>>>> OS using UEFI-only boot method on a GPT partitioned device fails.
> >>>>>>>>> The ASRock boards jump immediately into the firmware, the Fujitsu
> >>>>>>>>> offers some kind of CPU/Memory/HDD test facility.
> >>>>>>>>> 
> >>>>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot only
> >>>>>>>>> is implied, the MBR partitioned FreeBSD installation USB flash
> >>>>>>>>> device does boot in UEFI! I guess I can assume this when the well
> >>>>>>>>> known clumsy 80x25 char console suddenly gets bright and shiny with
> >>>>>>>>> a much higher resoltion as long the GPU supports EFI GOP. Looking
> >>>>>>>>> with gpart at the USB flash drives reveals that the EFI partition
> >>>>>>>>> starts at block 1 of the device and the device has a MBR layout. I
> >>>>>>>>> haven't found a way to force the GPT scheme, when initialised via
> >>>>>>>>> gpart, to let the partitions start at block 1. This might be a naiv
> >>>>>>>>> thinking, so please be patient with me.
> >>>>>>>>> 
> >>>>>>>>> I do not know whether this is a well-known issue. On the ASRock
> >>>>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI and
> >>>>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, having
> >>>&g

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-25 Thread O. Hartmann
On Tue, 24 Jul 2018 08:53:36 +0300
Toomas Soome  wrote:


Hello  Toomas Soome,

I CC Allan Jude since I discovered something  weird today regarding the UEFI
boot capabilities of USB flash devices and SSDs. See below.
 
> > On 24 Jul 2018, at 08:16, O. Hartmann  wrote:
> > 
> > On Mon, 23 Jul 2018 10:56:04 +0300
> > Toomas Soome  wrote:
> >   
> >>> On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> >>> 
> >>> On Fri, 13 Jul 2018 18:44:23 +0300
> >>> Toomas Soome mailto:tso...@me.com>> wrote:
> >>>   
> >>>>> On 13 Jul 2018, at 17:44, O. Hartmann  >>>>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>>>> 
> >>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>> Hash: SHA512
> >>>>> 
> >>>>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>>>> Toomas Soome mailto:tso...@me.com> <mailto:tso...@me.com
> >>>>> <mailto:tso...@me.com>>> schrieb:   
> >>>>>>> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> >>>>>>> 
> >>>>>>> The problem is some kind of weird. I face UEFI boot problems on GPT
> >>>>>>> drives where the first partition begins at block 40 of the hdd/ssd.
> >>>>>>> 
> >>>>>>> I have two host in private use based on an
> >>>>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> >>>>>>> LGA1155). Both boards are equipted with the lates official available
> >>>>>>> AMI firmware revision, dating to 2013. This is for the Z77-Pro4-M
> >>>>>>> revision 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8
> >>>>>>> (2013/7/17). For both boards a BETA revision for the Spectre/Meltdown
> >>>>>>> mitigation is available, but I didn't test that. But please read.
> >>>>>>> 
> >>>>>>> The third box I realised this problem is a brand new Fujitsu Esprimo
> >>>>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>>>>>> 05/25/2018 (or 20180525).
> >>>>>>> 
> >>>>>>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> >>>>>>> using UEFI-only boot method on a GPT partitioned device fails. The
> >>>>>>> ASRock boards jump immediately into the firmware, the Fujitsu offers
> >>>>>>> some kind of CPU/Memory/HDD test facility.
> >>>>>>> 
> >>>>>>> If on both type of vendor/boards CSM is disabled and UEFI boot only is
> >>>>>>> implied, the MBR partitioned FreeBSD installation USB flash device
> >>>>>>> does boot in UEFI! I guess I can assume this when the well known
> >>>>>>> clumsy 80x25 char console suddenly gets bright and shiny with a much
> >>>>>>> higher resoltion as long the GPU supports EFI GOP. Looking with gpart
> >>>>>>> at the USB flash drives reveals that the EFI partition starts at
> >>>>>>> block 1 of the device and the device has a MBR layout. I haven't
> >>>>>>> found a way to force the GPT scheme, when initialised via gpart, to
> >>>>>>> let the partitions start at block 1. This might be a naiv thinking,
> >>>>>>> so please be patient with me.
> >>>>>>> 
> >>>>>>> I do not know whether this is a well-known issue. On the ASRock
> >>>>>>> boards, I tried years ago some LinuxRed Hat and Suse with UEFI and
> >>>>>>> that worked - FreeBSD not. I gave up on that that time. Now, having
> >>>>>>> the very same issues with a new Fujitsu system, leaves me with the
> >>>>>>> impression that FreeBSD's UEFI implementation might have problems I'm
> >>>>>>> not aware of.
> >>>>>>> 
> >>>>>>> Can someone shed some light onto this? 
> >>>>>>>   
> >>>>>> 
> >>>>>> The first thing to check is if the secure boot is disabled. We do not
> >>>>>> support secure boot at all at this time.  
> >>>>> 
> >>>>> Secure boot is in every scenario disabled!
> >>>>>   
> >>>>>> 
> >>>

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-24 Thread O. Hartmann
On Tue, 24 Jul 2018 02:20:00 -0400
Allan Jude  wrote:

> On 2018-07-13 07:00, O. Hartmann wrote:
> > The problem is some kind of weird. I face UEFI boot problems on GPT drives
> > where the first partition begins at block 40 of the hdd/ssd.
> > 
> > I have two host in private use based on an
> > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> > LGA1155). Both boards are equipted with the lates official available AMI
> > firmware revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0
> > (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards
> > a BETA revision for the Spectre/Meltdown mitigation is available, but I
> > didn't test that. But please read.
> > 
> > The third box I realised this problem is a brand new Fujitsu Esprimo Q956,
> > also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or
> > 20180525).
> > 
> > Installing on any kind of HDD or SSD manually or via bsdinstall the OS using
> > UEFI-only boot method on a GPT partitioned device fails. The ASRock boards
> > jump immediately into the firmware, the Fujitsu offers some kind of
> > CPU/Memory/HDD test facility.
> > 
> > If on both type of vendor/boards CSM is disabled and UEFI boot only is
> > implied, the MBR partitioned FreeBSD installation USB flash device does
> > boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> > char console suddenly gets bright and shiny with a much higher resoltion as
> > long the GPU supports EFI GOP. Looking with gpart at the USB flash drives
> > reveals that the EFI partition starts at block 1 of the device and the
> > device has a MBR layout. I haven't found a way to force the GPT scheme,
> > when initialised via gpart, to let the partitions start at block 1. This
> > might be a naiv thinking, so please be patient with me.
> > 
> > I do not know whether this is a well-known issue. On the ASRock boards, I
> > tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> > FreeBSD not. I gave up on that that time. Now, having the very same issues
> > with a new Fujitsu system, leaves me with the impression that FreeBSD's UEFI
> > implementation might have problems I'm not aware of.
> > 
> > Can someone shed some light onto this? 
> > 
> > Thanks in advance,
> > 
> > Oliver 
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> >   
> 
> If you are up for experimenting, see if either of these results in your
> system booting:
> gpart set -a active ada0
> gpart set -a lenovofix ada0
> 
> Although both of these should only impact BIOS boot, not UEFI, you never
> know.
> 
> The other option is to try an ESP (EFI System Partition) that is
> formatted FAT32 instead of FAT12/FAT16)

How can I detect the format of the EFI partition? Suppose I create the EFI
partition via gpart, 12-CURRENT installer or 11.2-RELENG installer, what format
would that EFI partition be (the partition scheme I use is always GPT so far
and as far as I know)? What format is the result, if I would
dd /boot/boot1.efifat to the EFI partition?

>From a first glimpse I guess its FAT12/16, since creating an EFI partition via
gpart myself of 500m and try to newfs_msdos -F 32, I receive an error about
insufficient clusters with no further parameters. I tried to create a 512m
partition fiddling around with the blocksize option -b of newfs_msdos

When created manually /dev/gpt/efiboot0, formatted FAT32 (with -b 512 or -b
1024, I forgot) and preparing/copying the content of /boot/boot1.efifat
(mdconfig mounted ...) with proper folder structure to efi/boot/ on the newly
created FAT32 formatted EFI partition, I struggle then with a quick
installation of FreeBSD using "bsdinstall". Having created according to a pure
ZFS disk swap, gptboot (to be on the secure side if UEFI fails again) and a
zroot ZFS pool, the dumb installer doesn't let me create a filesystem structure
on ZFS for the installation without destroying the initial layout :-( 

So I stopped at that point and tried booting the box with only the FAT32
EFI/ESP partition with the loader copied from boot1.efifat as described. 

The result is annoying, the ESPRIMO Q956 firmware shows up with some kind of
testing tool/shell as reported in the initial posting of mine. I'd have
expected some signs from the FreeBSD UEFI bootloader so far at this point, but
I might be mislead here.

I also have applied the "gpart set -a" commands, without any effect.

> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [UEFI] Boot issues on some UEFI implementations

2018-07-23 Thread O. Hartmann
On Mon, 23 Jul 2018 10:56:04 +0300
Toomas Soome  wrote:

> > On 23 Jul 2018, at 10:27, O. Hartmann  wrote:
> > 
> > On Fri, 13 Jul 2018 18:44:23 +0300
> > Toomas Soome mailto:tso...@me.com>> wrote:
> >   
> >>> On 13 Jul 2018, at 17:44, O. Hartmann  >>> <mailto:o.hartm...@walstatt.org>> wrote:
> >>> 
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA512
> >>> 
> >>> Am Fri, 13 Jul 2018 14:26:51 +0300
> >>> Toomas Soome mailto:tso...@me.com> <mailto:tso...@me.com
> >>> <mailto:tso...@me.com>>> schrieb: 
> >>>>> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> >>>>> 
> >>>>> The problem is some kind of weird. I face UEFI boot problems on GPT
> >>>>> drives where the first partition begins at block 40 of the hdd/ssd.
> >>>>> 
> >>>>> I have two host in private use based on an
> >>>>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> >>>>> LGA1155). Both boards are equipted with the lates official available AMI
> >>>>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
> >>>>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
> >>>>> boards a BETA revision for the Spectre/Meltdown mitigation is available,
> >>>>> but I didn't test that. But please read.
> >>>>> 
> >>>>> The third box I realised this problem is a brand new Fujitsu Esprimo
> >>>>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>>>> 05/25/2018 (or 20180525).
> >>>>> 
> >>>>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> >>>>> using UEFI-only boot method on a GPT partitioned device fails. The
> >>>>> ASRock boards jump immediately into the firmware, the Fujitsu offers
> >>>>> some kind of CPU/Memory/HDD test facility.
> >>>>> 
> >>>>> If on both type of vendor/boards CSM is disabled and UEFI boot only is
> >>>>> implied, the MBR partitioned FreeBSD installation USB flash device does
> >>>>> boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> >>>>> char console suddenly gets bright and shiny with a much higher resoltion
> >>>>> as long the GPU supports EFI GOP. Looking with gpart at the USB flash
> >>>>> drives reveals that the EFI partition starts at block 1 of the device
> >>>>> and the device has a MBR layout. I haven't found a way to force the GPT
> >>>>> scheme, when initialised via gpart, to let the partitions start at block
> >>>>> 1. This might be a naiv thinking, so please be patient with me.
> >>>>> 
> >>>>> I do not know whether this is a well-known issue. On the ASRock boards,
> >>>>> I tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> >>>>> FreeBSD not. I gave up on that that time. Now, having the very same
> >>>>> issues with a new Fujitsu system, leaves me with the impression that
> >>>>> FreeBSD's UEFI implementation might have problems I'm not aware of.
> >>>>> 
> >>>>> Can someone shed some light onto this? 
> >>>>>   
> >>>> 
> >>>> The first thing to check is if the secure boot is disabled. We do not
> >>>> support secure boot at all at this time.
> >>> 
> >>> Secure boot is in every scenario disabled!
> >>>   
> >>>> 
> >>>> If you have efi or bios version running - you can check from either
> >>>> console variable value (it can have efi or vidconsole or comconsole) or
> >>>> better yet, see if efi-version is set (show efi-version) - if efi-version
> >>>> is not set, it is BIOS loader running. Another indirect way is to see
> >>>> lsdev -v, with device paths present, it is uefi:)
> >>> 
> >>> What are you talking about?
> >>> What is the point of entry - running system, loader?
> >>> 
> >>> sysct machdep.bootmethod: BIOS
> >>> 
> >>> This makes me quite sure that the system has booted via BIOS - as I'm sure
> >>> since I've checked that many times. UEFI doesn't work on those systems
> >>> with FreeBSD. I'm not

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-23 Thread O. Hartmann
On Fri, 13 Jul 2018 18:44:23 +0300
Toomas Soome  wrote:

> > On 13 Jul 2018, at 17:44, O. Hartmann  wrote:
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Fri, 13 Jul 2018 14:26:51 +0300
> > Toomas Soome mailto:tso...@me.com>> schrieb:
> >   
> >>> On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> >>> 
> >>> The problem is some kind of weird. I face UEFI boot problems on GPT drives
> >>> where the first partition begins at block 40 of the hdd/ssd.
> >>> 
> >>> I have two host in private use based on an
> >>> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket
> >>> LGA1155). Both boards are equipted with the lates official available AMI
> >>> firmware revision, dating to 2013. This is for the Z77-Pro4-M revision
> >>> 2.0 (2013/7/23) and for the Z77 Pro4 revision 1.8 (2013/7/17). For both
> >>> boards a BETA revision for the Spectre/Meltdown mitigation is available,
> >>> but I didn't test that. But please read.
> >>> 
> >>> The third box I realised this problem is a brand new Fujitsu Esprimo
> >>> Q956, also AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date
> >>> 05/25/2018 (or 20180525).
> >>> 
> >>> Installing on any kind of HDD or SSD manually or via bsdinstall the OS
> >>> using UEFI-only boot method on a GPT partitioned device fails. The ASRock
> >>> boards jump immediately into the firmware, the Fujitsu offers some kind
> >>> of CPU/Memory/HDD test facility.
> >>> 
> >>> If on both type of vendor/boards CSM is disabled and UEFI boot only is
> >>> implied, the MBR partitioned FreeBSD installation USB flash device does
> >>> boot in UEFI! I guess I can assume this when the well known clumsy 80x25
> >>> char console suddenly gets bright and shiny with a much higher resoltion
> >>> as long the GPU supports EFI GOP. Looking with gpart at the USB flash
> >>> drives reveals that the EFI partition starts at block 1 of the device and
> >>> the device has a MBR layout. I haven't found a way to force the GPT
> >>> scheme, when initialised via gpart, to let the partitions start at block
> >>> 1. This might be a naiv thinking, so please be patient with me.
> >>> 
> >>> I do not know whether this is a well-known issue. On the ASRock boards, I
> >>> tried years ago some LinuxRed Hat and Suse with UEFI and that worked -
> >>> FreeBSD not. I gave up on that that time. Now, having the very same
> >>> issues with a new Fujitsu system, leaves me with the impression that
> >>> FreeBSD's UEFI implementation might have problems I'm not aware of.
> >>> 
> >>> Can someone shed some light onto this? 
> >>>   
> >> 
> >> The first thing to check is if the secure boot is disabled. We do not
> >> support secure boot at all at this time.  
> > 
> > Secure boot is in every scenario disabled!
> >   
> >> 
> >> If you have efi or bios version running - you can check from either
> >> console variable value (it can have efi or vidconsole or comconsole) or
> >> better yet, see if efi-version is set (show efi-version) - if efi-version
> >> is not set, it is BIOS loader running. Another indirect way is to see
> >> lsdev -v, with device paths present, it is uefi:)  
> > 
> > What are you talking about?
> > What is the point of entry - running system, loader?
> > 
> > sysct machdep.bootmethod: BIOS
> > 
> > This makes me quite sure that the system has booted via BIOS - as I'm sure
> > since I've checked that many times. UEFI doesn't work on those systems with
> > FreeBSD. I'm not sure antmore, but I tried also Windows 7 on those
> > mainboards booting via UEFI - and I might recall that they failed also. I
> > also recall that there were issues with earlier UEFI versions regarding
> > booting only Windows 8/8.1 - and nothing else, but the fact that Linux
> > worked confuses me a bit.
> > 
> > If this ASRock crap (never ever again this brand!) doesn't work at all -
> > who cares, I intend to purchase new server grade hardware. But the more
> > puzzling issue is with the Fujitsu, which I consider serious and from the
> > behaviour the Fujitsu failure looks exactly like the ASRock - Windows 7
> > works, RedHat 7.5 works (I assume I can trust the Firmware settings when I
> > disable CSM support, that the Firmware will only EFI/UEFI capable loader?
> > Or

Re: [UEFI] Boot issues on some UEFI implementations

2018-07-13 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fri, 13 Jul 2018 14:26:51 +0300
Toomas Soome  schrieb:

> > On 13 Jul 2018, at 14:00, O. Hartmann  wrote:
> > 
> > The problem is some kind of weird. I face UEFI boot problems on GPT drives
> > where the first partition begins at block 40 of the hdd/ssd.
> > 
> > I have two host in private use based on an
> > outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket 
> > LGA1155).
> > Both boards are equipted with the lates official available AMI firmware
> > revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 
> > (2013/7/23)
> > and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA 
> > revision
> > for the Spectre/Meltdown mitigation is available, but I didn't test that. 
> > But
> > please read.
> > 
> > The third box I realised this problem is a brand new Fujitsu Esprimo Q956, 
> > also
> > AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 
> > 20180525).
> > 
> > Installing on any kind of HDD or SSD manually or via bsdinstall the OS using
> > UEFI-only boot method on a GPT partitioned device fails. The ASRock boards 
> > jump
> > immediately into the firmware, the Fujitsu offers some kind of 
> > CPU/Memory/HDD
> > test facility.
> > 
> > If on both type of vendor/boards CSM is disabled and UEFI boot only is 
> > implied,
> > the MBR partitioned FreeBSD installation USB flash device does boot in 
> > UEFI! I
> > guess I can assume this when the well known clumsy 80x25 char console 
> > suddenly
> > gets bright and shiny with a much higher resoltion as long the GPU supports
> > EFI GOP. Looking with gpart at the USB flash drives reveals that the EFI
> > partition starts at block 1 of the device and the device has a MBR layout. I
> > haven't found a way to force the GPT scheme, when initialised via gpart, to 
> > let
> > the partitions start at block 1. This might be a naiv thinking, so please be
> > patient with me.
> > 
> > I do not know whether this is a well-known issue. On the ASRock boards, I
> > tried years ago some LinuxRed Hat and Suse with UEFI and that worked - 
> > FreeBSD
> > not. I gave up on that that time. Now, having the very same issues with a 
> > new
> > Fujitsu system, leaves me with the impression that FreeBSD's UEFI
> > implementation might have problems I'm not aware of.
> > 
> > Can someone shed some light onto this? 
> >   
> 
> The first thing to check is if the secure boot is disabled. We do not support 
> secure
> boot at all at this time.

Secure boot is in every scenario disabled!
 
> 
> If you have efi or bios version running - you can check from either console 
> variable
> value (it can have efi or vidconsole or comconsole) or better yet, see if 
> efi-version
> is set (show efi-version) - if efi-version is not set, it is BIOS loader 
> running.
> Another indirect way is to see lsdev -v, with device paths present, it is 
> uefi:)

What are you talking about?
What is the point of entry - running system, loader?

sysct machdep.bootmethod: BIOS

This makes me quite sure that the system has booted via BIOS - as I'm sure 
since I've
checked that many times. UEFI doesn't work on those systems with FreeBSD. I'm 
not sure
antmore, but I tried also Windows 7 on those mainboards booting via UEFI - and 
I might
recall that they failed also. I also recall that there were issues with earlier 
UEFI
versions regarding booting only Windows 8/8.1 - and nothing else, but the fact 
that Linux
worked confuses me a bit.

If this ASRock crap (never ever again this brand!) doesn't work at all - who 
cares, I
intend to purchase new server grade hardware. But the more puzzling issue is 
with the
Fujitsu, which I consider serious and from the behaviour the Fujitsu failure 
looks
exactly like the ASRock - Windows 7 works, RedHat 7.5 works (I assume I can 
trust the
Firmware settings when I disable CSM support, that the Firmware will only 
EFI/UEFI
capable loader? Or is there a ghosty override somwhere to be expected?). Also 
on ASRock
disabling CSM should ensure not booting a dual-bootstrap-capable system. This 
said, on
the recent Fujitsu, it seems to boil down to a FreeBSD UEFI-firmware interaction
problem, while the ASRock is still under suspicion to be broken by design.  

> 
> GPT partitions can never start from disk absolute sector 1; this is because 
> at sector 0
> there is MBR (for compatibility), sector 1 is GPT table and then sectors 2-33 
> have GPT
> partition table entries, so the first possible data sector is 34 (absolute 
> 34). Thats
> assuming 512B sectors.  For details see UEFI 2

[UEFI] Boot issues on some UEFI implementations

2018-07-13 Thread O. Hartmann
The problem is some kind of weird. I face UEFI boot problems on GPT drives
where the first partition begins at block 40 of the hdd/ssd.

I have two host in private use based on an
outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LGA1155).
Both boards are equipted with the lates official available AMI firmware
revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 (2013/7/23)
and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
for the Spectre/Meltdown mitigation is available, but I didn't test that. But
please read.

The third box I realised this problem is a brand new Fujitsu Esprimo Q956, also
AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 20180525).

Installing on any kind of HDD or SSD manually or via bsdinstall the OS using
UEFI-only boot method on a GPT partitioned device fails. The ASRock boards jump
immediately into the firmware, the Fujitsu offers some kind of CPU/Memory/HDD
test facility.

If on both type of vendor/boards CSM is disabled and UEFI boot only is implied,
the MBR partitioned FreeBSD installation USB flash device does boot in UEFI! I
guess I can assume this when the well known clumsy 80x25 char console suddenly
gets bright and shiny with a much higher resoltion as long the GPU supports
EFI GOP. Looking with gpart at the USB flash drives reveals that the EFI
partition starts at block 1 of the device and the device has a MBR layout. I
haven't found a way to force the GPT scheme, when initialised via gpart, to let
the partitions start at block 1. This might be a naiv thinking, so please be
patient with me.

I do not know whether this is a well-known issue. On the ASRock boards, I
tried years ago some LinuxRed Hat and Suse with UEFI and that worked - FreeBSD
not. I gave up on that that time. Now, having the very same issues with a new
Fujitsu system, leaves me with the impression that FreeBSD's UEFI
implementation might have problems I'm not aware of.

Can someone shed some light onto this? 

Thanks in advance,

Oliver 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Firmware Error (ACPI): Failure looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND

2018-07-13 Thread O. Hartmann
Hello.

The target host is a

Fujitsu Esprimo Q956
Firmware V5.0.0.11 R1.26.0 for A3413-A1x
Date 05/25/2018
BIOS Revision 1.26

FreeBSD 11.2-RELEASE and 12-CURRENT (ISO Image from 9th July 2018, r336134) are
spamming the console with an annoying error:

Jul 13 10:00:32  kernel: Firmware Error (ACPI): Failure looking up
[\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503) Jul 13 10:00:32
kernel: ACPI Error: Method parse/execution failed \_TZ.TZ00._TMP, AE_NOT_FOUND
(20171214/psparse-677) Jul 13 10:00:32  kernel: Firmware Error (ACPI): Failure
looking up [\_SB.PCI0.LPCB.HEC.ECAV], AE_NOT_FOUND (20171214/psargs-503)

The error is repeated endless.

Can this be fixed?

Thanks in advance and kind regards,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


CURRENT: building PkgBase for 11.2-RELENG on CURRENT fails

2018-07-06 Thread O. Hartmann
I fail to buildworld/buildkernel and package FreeBSD 11.2-RELENG on a CURRENT
host (FreeBSD 12.0-CURRENT #165 r336013: Thu Jul  5 21:00:36 CEST 2018 amd64)
with the error shown below.

My aim is to have CURRENT building 11.1 and 11.2 packages for "base" and for
the poudriere jails. This seems to start failing recently and I can not fathom
why. Any ideas?

As the env variables show, the sources are stored
at /pool/sources/11.2-RELENG/src and for the build environment, I point to that
source and obj base.


Kind regards,
Oliver

[...]
+ cd /pool/sources/11.2-RELENG/src
+ env 'MAKEOBJDIRPREFIX=/pool/sources/11.2-RELENG/obj' 'WITH_META_MODE=YES'
  '__MAKE_CONF=/usr/local/etc/config/amd64/11.2-RELENG-make.conf'
  'SRCCONF=/usr/local/etc/config/amd64/11.2-RELENG-src.conf'
  'SRC_ENV_CONF=/usr/local/etc/config/amd64/11.2-RELENG-src-env.conf' make -j9
  'TARGET=amd64'
  'KERNCONFDIR=/usr/local/etc/config/amd64/11.2-RELENG/kernel_conf/' 'KERNCONF=
  GENERIC-NODEBUG ' 'NO_INSTALLEXTRAKERNELS=NO' 'NO_INSTALLKERNEL=NO'
  buildworld buildkernel --- buildworld --- make[1]:
  "/pool/sources/11.2-RELENG/src/Makefile.inc1" line 1517: Unassociated shell
  command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f
  ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v
  _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd
  ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ;
  ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e
  "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U""}/"  -e "s/%KERNELDIR%/kernel/"
  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e
  "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U""}/"  -e
  "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"
  ${SRCDIR}/release/packages/kernel.ucl  >
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;  awk -F\"
  '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2;
  next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl ;
  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create
  -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.ucl  -p
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U""}.plist  -r
  ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o
  ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}" 

make[1]: "/pool/sources/11.2-RELENG/src/Makefile.inc1" line 1517: Unassociated
shell command "@cd ${KSTAGEDIR}/${DISTDIR} ;  awk -f
  ${SRCDIR}/release/scripts/mtree-to-plist.awk  -v kernel=yes -v
  _kernconf=${INSTALLKERNEL}  ${KSTAGEDIR}/kernel.meta ;  cap_arg=`cd
  ${SRCDIR}/etc ; ${MAKE} -VCAP_MKDB_ENDIAN` ;  pwd_arg=`cd ${SRCDIR}/etc ;
  ${MAKE} -VPWD_MKDB_ENDIAN` ;  sed -e "s/%VERSION%/${PKG_VERSION}/"  -e
  "s/%PKGNAME%/kernel-${INSTALLKERNEL:tl}${:U-debug}/"  -e
  "s/%KERNELDIR%/kernel/"  -e "s/%COMMENT%/FreeBSD ${INSTALLKERNEL} kernel
  ${:U-debug}/"  -e "s/%DESC%/FreeBSD ${INSTALLKERNEL} kernel ${:U-debug}/"  -e
  "s/%CAP_MKDB_ENDIAN%/$${cap_arg}/g"  -e "s/%PWD_MKDB_ENDIAN%/$${pwd_arg}/g"
  ${SRCDIR}/release/packages/kernel.ucl  >
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;  awk -F\"
  '  /name/ { printf("===> Creating %s-", $$2); next }  /version/ {print $$2;
  next } '  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl ;
  ${PKG_CMD} -o ABI_FILE=${WSTAGEDIR}/bin/sh -o ALLOW_BASE_SHLIBS=yes  create
  -M ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.ucl  -p
  ${KSTAGEDIR}/${DISTDIR}/kernel.${INSTALLKERNEL}${:U-debug}.plist  -r
  ${KSTAGEDIR}/${DISTDIR}  -o ${REPODIR}/$$(${PKG_CMD} -o
  ABI_FILE=${WSTAGEDIR}/bin/sh config ABI)/${PKG_VERSION}" 

make[1]: Fatal errors encountered -- cannot continue 
make[1]: stopped in /pool/sources/11.2-RELENG/src
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: atomic changes break drm-next-kmod?

2018-07-03 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:

> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
> 
> --- i915_drv.o ---
> In file included from i915_drv.c:30:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
> In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
> In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
> In file included from /usr/src/sys/sys/systm.h:44:
> ./machine/atomic.h:450:29: error: invalid operand for instruction
> ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
> ^
> :1:7: note: instantiated into assembly here
> andq $9223372036854775807,40672(%r14)
>  ^
> 1 error generated.
> *** [i915_drv.o] Error code 1
> 
> make[3]: stopped in
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
> --- i915_gem.o ---
> In file included from i915_gem.c:28:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
> In file included from /usr/src/sys/sys/malloc.h:42:
> In file included from /usr/src/sys/sys/systm.h:44:
> ./machine/atomic.h:449:29: error: invalid operand for instruction
> ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
> ^
> :1:6: note: instantiated into assembly here
> orq $-9223372036854775808,40672(%r14)
> ^~
> 1 error generated.
> *** [i915_gem.o] Error code 1
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < 
r335873,
those kmod compile well.
- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWzuQGgAKCRDS528fyFhY
lKHnAf0fIVHnw1xBVHzogeQQo4v+he17R2ln6l25lNR/pUE1AZOsFzPDamAkqbY+
f1+Usr+P5o7jn26Bh4ob3UmIj25DAf4tJZpeZS4iGZ374lrCAemYFb53+MJ1fClW
aBLI6DVOiBiOt/UpLXZf1whl/dtQvo5yd1xywfYOwi9Jh8teHcNW
=mtMH
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r335282: first stage boot failure on PCengines APU 2C4

2018-06-18 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mon, 18 Jun 2018 07:42:20 -0600
Warner Losh  schrieb:

> On Mon, Jun 18, 2018, 3:01 AM Olivier Cochard-Labbé 
> wrote:
> 
> > On Sun, Jun 17, 2018 at 10:01 AM O. Hartmann 
> > wrote:
> >  
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > >
> > > Running CURRENT as routing and firewalling appliance on a PCengines APU
> > > 2C4 with the
> > > latest (official) SEABios available for this product, NanoBSD (FreeBSD
> > > CURRENT FreeBSD
> > > 12.0-CURRENT #60 r335278: Sun Jun 17 07:57:20 CEST 2018 amd64)is unable  
> > to  
> > > boot recent
> > > OS at the first stage (GPT partitioning, SD card memory).
> > >
> > > ​Hi,  
> >
> >
> > My nanobsd images are based on :
> > [root@apu2]~# uname -a
> > FreeBSD apu2 12.0-CURRENT FreeBSD 12.0-CURRENT  r335286M  amd64
> >
> > And I don't remember to have upgraded its BIOS:
> > [root@apu2]~# kenv smbios.bios.reldate
> > 03/07/2016
> > [root@apu2]~# kenv smbios.system.product
> > apu2
> >
> > But I'm using MBR partitionning on a mSATA disk.
> >  
> 
> Do you know the first version to have this problem? Are you using geli?
> 
> Warner
> 
> >  


Hello, 

if you addressed me (wasn't so clear from your reply on Olivier Cochard-Labbé's
reply to me), I could give you this information (I posted it to Allen Jude in 
response to

svn commit: r335254 - in head/stand/i386: libi386 zfsboot

probably the wrong commit. Please allow me to copy-paste:

[...]

I realised that CURRENT r335222 from Friday, 10th June 2018 booted without 
problems
(NanoBSD, slightly modified to boot off GPT/UEFI partitions, but in general a 
simple
"gpart bootcode -b pmbr -p /boot/gptboot -i 2 mmcsd0" preparation of a dd'd 
image).
Another try with recent r335282 on a APU 2C4, freshly build NanoBSD, fails to 
boot
firststage: the (most recent) SEABios stopps for ever at telling "Booting from 
hard
disk"; were usually a carret starts to spinn there is vast emptyness. Preparing 
the boot
partition with an older bootcode on that very same SD card via "gpart bootcode 
-b pmbr
- - -p /boot/gptboot -i 2 mmcsd0" with an older booted image of CURRENT has 
solved the
problem. The layout of the SD card is as follows, just for the record:

#: gpart show mmcsd0
=>  40  60751792  mmcsd0  GPT  (29G)  
40  1024   2  freebsd-boot  (512K)
  1064   2205944   3  freebsd-ufs  (1.1G)
   2207008   2210127   4  freebsd-ufs  (1.1G)
   4417135   1048576   5  freebsd-ufs  (512M)
   5465711  55286121  - free -  (26G)

[...]

I didn't bi-sect the issue du to time constraints, but if it helps, I could 
try. I
resolved the problem temporarely by writing the bootcode and partition code 
from an older
image.

The APU is serial console only.

Kind regards,

Oliver Hartmann


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWyfUjQAKCRDS528fyFhY
lJZ6AfwOeHnA01kpMxQgEtkIaoCYGoa1wetyss1HvkJj/kolplwJT9mVRKypLjZb
CWxS+ldHyy2lhs9Q1dIrrm64TfVbAgCAc3oZyuOtzoO9+CbMopmUwt5FqFBGn/b0
AI7w7mVu+EzWww/Qx/73E98j6LtZIjB8jpHGc0lqlpDwD6HL5IHt
=mFD0
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


r335282: first stage boot failure on PCengines APU 2C4

2018-06-17 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Running CURRENT as routing and firewalling appliance on a PCengines APU 2C4 
with the
latest (official) SEABios available for this product, NanoBSD (FreeBSD CURRENT 
FreeBSD
12.0-CURRENT #60 r335278: Sun Jun 17 07:57:20 CEST 2018 amd64)is unable to boot 
recent
OS at the first stage (GPT partitioning, SD card memory).

Last known good image without boot issues is FreeBSD 12.0-CURRENT #52 r335222: 
Fri Jun 15
20:24:41 CEST 2018 amd64.

The issue is revealing itself by showing nothing but a static screen telling it 
is
booting from hard disk where usually the rotating indicator popps up.
Booting the  APUwith  my installation USB device and "gpart -b pmbr -p 
/boot/gptboot -i 2
mmcsd0" - which is a quite old image from December 2017 by the way, made the SD 
card
booting again - with r335278 now properly.

At the very moment, I do not dare to check whether the bootcode is broken on 
those boxes
I boot via MBR/GPTBOOT.

Can someone give me some hints how to check this further or is this issue 
already known?

Kind regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWyYU9AAKCRDS528fyFhY
lCraAf4x6/vkz2E6R802qNsE7z3vSv5DudGVRPLZNDBAyWMiMo15N8xa/JJvGyXn
6yO8OpR0bqKYwaBk443KgtlqTBakAfkBDvNcZRsU7R3FwEmZrColDIOWhdZwKT9a
HpZRMiuYLN3ygl+OQJ8tGhoY0twl2FAKbxcLSNPPeHwiURBuqaRy
=kt+a
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


VBox: how can a guest check the underlying version of VBox?

2018-06-11 Thread O. Hartmann
Hello list,

I' apologize for bothering this list with this "non-CURRENT" question, but I
hope I can find here a quick answer.

>From within a running guest I need to check what Vbox version is running the
guest to provide a deployment system with the necessary informations about the
Guest Tools to be installed. The primary "Guests" are Windows 7 on top of
FreeBSD as the host and vice versa, Windows 7 as host and FreeBSD as guest.

Thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


RACK/TCPHPTC: spell error in sources: fatal error missing option TCPHSTS in the build;

2018-06-11 Thread O. Hartmann
In the sources of CURRENT, there is a spell bug:


[...]
src/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:131:1: error:
unknown type name 'fatal' fatal error missing option TCPHSTS in the build;
^
/pool/sources/CURRENT/src/sys/modules/tcp/rack/../../../netinet/tcp_stacks/rack.c:131:12:
error: expected ';' after top level declarator fatal error missing option
TCPHSTS in the build; ^
   ;
[...]

I face this nasty error when I try to compile GENERIC.

Kind regards,

oh

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: rndc: connect failed: 127.0.0.1#953: permission denied

2018-06-09 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sat, 2 Jun 2018 16:07:48 -0700 (PDT)
Don Lewis  schrieb:

> On  2 Jun, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On CURRENT, running on an APU as router/firewall service, out of the blue 
> > after an
> > update I receive this weird message when trying to restart "named" (BIND 
> > 9.12, latest
> > from the ports):
> > 
> > service named restart
> > rndc: connect failed: 127.0.0.1#953:
> > permission denied rndc failed, trying kill: Waiting for PIDS: 871.
> > 
> > Searching the net reveals that possible access rights issues could cause 
> > this problem,
> > but I do not see any. Does somebody see such problems, too and does have a 
> > solution?  
> 
> Do you have a firewall rule that blocks sending to UDP port 953 on
> 127.0.0.1?

Hello.

Sorry for the very late answer.

Your hint was right! I changed some minor confiuration parts and didn't realise 
that I
dropped access granted for 12.0.0.1 in IPFW.

After reinstalling a propper rule everything worked as expected.

Thanks.

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWxv0XAAKCRDS528fyFhY
lAbpAgCgyfLqKwAEu0/MSroRjQKbxM5ouS3dsh5n63GsqPAEvkN3GRekM31c6DUh
1PUIv1wNkgyKTCC5S36hNC08Kkc8AgCJs08D9oNmHSL1D2qOknQauKYQTqxoNQm2
I9nXrwZ83gAYsgKuS+bNZRoupmB/fhPDI5BGku+TGnE2W6rB47Fh
=lISe
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


r334885: dwarf.c:1980:8: error: use of undeclared identifier 'DW_LANG_C11' case DW_LANG_C11:

2018-06-09 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

A recent update of sources rednered building world faulty:

[...]

===> cddl/usr.bin/ctfconvert (obj,all,install)
Building 
/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/cddl/usr.bin/ctfconvert/dwarf.o
- --- dwarf.o ---
/usr/src/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1980:8: error: use of 
undeclared
identifier 'DW_LANG_C11' case DW_LANG_C11:
 ^
/usr/src/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1982:8: error: use of 
undeclared
identifier 'DW_LANG_C_plus_plus_03' case DW_LANG_C_plus_plus_03:
 ^
/usr/src/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1983:8: error: use of 
undeclared
identifier 'DW_LANG_C_plus_plus_11' case DW_LANG_C_plus_plus_11:
 ^
/usr/src/cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:1984:8: error: use of 
undeclared
identifier 'DW_LANG_C_plus_plus_14' case DW_LANG_C_plus_plus_14:
 ^
4 errors generated.
*** [dwarf.o] Error code 1

make[3]: stopped in /usr/src/cddl/usr.bin/ctfconvert
[...]



Since I do not get any email from freeBSD's mailing list, I can not exactly 
tell what
commit caused the problem.

Kind regards,

oh


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWxv8TQAKCRDS528fyFhY
lJGBAf9hOOuXpWXc+STSo8D2Wz4M3A2XX3GU6CHGP/Q1zDXFRcvIDvtAl4Z4Ju3T
lgjxMJhAxlbxNM4ExS+FhEIPW94yAfwJnkhLvIZ78Rsa4NgqmY7maCX2BTXmKGpb
oCRTE+1LdEUmhuI8eMvQm2pYXFultOaN+jSJ6yG+HNvK6XIbDp8w
=VYuc
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


CAM/ growisofs: Segmentation fault, SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)

2018-06-06 Thread O. Hartmann
Hello,

my desperate call for help is according to PR 225291,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225291.

On one of our Workstations (Fujitsu Celsius M740 with Haswell XEON 6-core CPU)
I face the inability to burn larger DVDs, using the port sysutils/dvd+rw-tools.

The recent status of the OS is FreeBSD 12.0-CURRENT #38 r334651: Tue Jun  5
13:33:18 CEST 2018 amd64, but this problem has been present since January, see
PR citet above.

The fact is, that with several DVD burner (all older models), burning DVDs of
larger sizes (> 4 GB) started to fail around December/January and I thought
that might be due to a defect of the hardware. After switching to other
exchange burner models, the same error occured. 

While I was able to finish the job in January after the Seg fault occured, this
is now impossible, even with the DVD burner it worked prior. 

Please have a look at the PR cited above for more details.

Thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


rndc: connect failed: 127.0.0.1#953: permission denied

2018-06-02 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On CURRENT, running on an APU as router/firewall service, out of the blue after 
an update
I receive this weird message when trying to restart "named" (BIND 9.12, latest 
from the
ports):

service named restart
rndc: connect failed: 127.0.0.1#953:
permission denied rndc failed, trying kill: Waiting for PIDS: 871.

Searching the net reveals that possible access rights issues could cause this 
problem,
but I do not see any. Does somebody see such problems, too and does have a 
solution?

Kind regards,

oh

- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWxJDQwAKCRDS528fyFhY
lG99Af9fgYXWu0uXfReqpMXBnGpShdDzY/jh0YPSbARnqcEbCXtrZO/0/JyodF+k
cD1cJL5Q4BLBIM1OpC04vO1Lzw8NAf40fcX/FqXQ1GF9EKOh/8jN443yEs4cF2Of
pPxg89MlGvA67Qn818GjMpPKyJTtpF9nukwpEG3bo8+Te+mEmUxZ
=OvK2
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


create-kernel-packages-extra-flavor-debug: *** Error code 70: Unable to open plist

2018-06-01 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On recent CURRENT with recent CURRENT sources (r334490), building FreeBSD 
packages for
FreeBSD-base fails on arm64.aarch64 with a custom kernel (see below).

WITH_META_MODE is used.

Such problems do not occur when building "make packages" on custom kernels on 
amd64 on
which I have erased all DEBUG facilities or DEBUG options. The same is with a 
customised
PINE64 kernel.

It is strange that the GENERIC kernel can be packaged.

Any ideas?

Kind regards,

oh


[...]
===> Creating FreeBSD-zfs-12.0.s20180601173814
pkg -o
ABI_FILE=/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/bin/sh
- -o ALLOW_BASE_SHLIBS=yes  create
- -M 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/zfs.ucl
- -p 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/zfs.plist
- -r /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage
- -o /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/repo/$(pkg -o
ABI_FILE=/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/bin/sh
config ABI)/12.0.s20180601173814 ===> Creating
FreeBSD-kernel-generic-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-generic-debug-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-pine64-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-pine64-debug-12.0.s20180601173814 pkg: Unable to open plist
file: 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/kernelstage/kernel.PINE64/kernel.PINE64-debug.plist
*** Error code 70

Stop.
make[4]: stopped in /pool/sources/CURRENT/src
*** Error code 1


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWxGVJAAKCRDS528fyFhY
lCnQAfkB6RoR8X791l0FkHfp3mmyu+vH+es09po25LZtZOctka7gJqUYpNEnxYBl
ipqTrPFuypAYlAHPBRFBLO+OJbpoAgCVvRVctYh4nlXJBT72l8M7jewhgqWn/gRc
XPMUuxeqG91eQSxGOsjkBMp7cBNCiXnetV7Kb3BP4cEpCCQ2uaB2
=qJ8C
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-30 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Thu, 24 May 2018 09:10:10 -0700 (PDT)
"Rodney W. Grimes"  schrieb:

> -- Start of PGP signed section.
> > On Thu, May 24, 2018 at 08:22:12AM -0700, Rodney W. Grimes wrote:  
> > > > On Wed, May 23, 2018 at 11:48:38AM +0200, Philip Homburg wrote:  
> > > > > >Also as the Moore's law curve flattens expect the life of these
> > > > > >older, but not so old, machines to live quiet some time.  I
> > > > > >believe we are talking sandy bridge and earlier?  If that is
> > > > > >corret Sandy bridge is still a very viable system.  
> > > > > 
> > > > > I noticed this lack of love for older systems recently. 
> > > > > 
> > > > > I wanted to use an older Dell server to test the 11.2 BETAs and RCs.
> > > > > 
> > > > > Turns out, you can't install FreeBSD using a USB stick image because 
> > > > > the
> > > > > BIOS only support MBR. No idea why MBR support was dropped for the 
> > > > > USB images.
> > > > > 
> > > > > In the end I had to find a CD burner, and after a couple of tries 
> > > > > managed to
> > > > > install from CD.
> > > > > 
> > > > > After that, my ansible playbooks started failing because 
> > > > > /boot/loader.conf 
> > > > > is absent if you boot from zfs in combination with MBR.
> > > > > 
> > > > > Pity. This older server hardware is great for trying out new 
> > > > > releases, play 
> > > > > with zfs, etc.  
> > > > 
> > > > The disc1.iso (as well as bootonly.iso and dvd1.iso) images are now
> > > > built as hybrid images, supporting both MBR and GPT, as well as being
> > > > written to a flash drive (like memstick.img) as well as a CD.  
> > > 
> > > To clarify a minor point here, are the amd64 disc1.iso images or
> > > both the amd64 and i386 disk1.iso images being built as "hybrid"?
> > >   
> > 
> > Only amd64.  i386 does not have UEFI-/GPT-related boot issues.  
> 
> Here is a data point:
> 
> Test system is Dell R710,
> First attempt is with BIOS in Boot mode: Bios 
> Second attempt is with BIOS in Boot mode: UEFI
> 
> Attemtped to boot amd64 version:
> Screen goes white background, text appears (yes, way indented)
> BTX version is 1.02
> Consoles: internal video/keyboard
> _
>  
> That last _ is a blinking cursor, system is hung, does repsond to C-A-del
>  
>  
> Second attempt:
> Works properly
>  
> 
> I am going after Ed Maste's posted build image in the other thread now...
> 
> 
> >   
> > > As this is what I see on my system:
> > > root@x230a:/home/ISO/x # file FreeBSD-11.2-BETA2-*
> > > FreeBSD-11.2-BETA2-amd64-disc1.iso: DOS/MBR boot sector; partition 1 : 
> > > ID=0xee,
> > > start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 1472695 
> > > sectors
> > > FreeBSD-11.2-BETA2-i386-disc1.iso:  ISO 9660 CD-ROM filesystem data
> > > '11_2_BETA2_I386_CD' (bootable) 
> > > > MBR support was initially removed from the memstick installer, as it is
> > > > not compatible with some UEFI implementations.  (Or, at least that is my
> > > > understanding, based on my limited intimate knowledge of UEFI.)
> > > >   
> > 
> > Glen
> >   
> -- End of PGP section, PGP failed!
> 

Today, I tried to eliminate FreeBSD's native KMS drm2 by installing
graphics/drm-stable-kmod (ports tree at revision 471172) on CURRENT (FreeBSD 
12.0-CURRENT
#46 r334401: Wed May 30 23:32:45 CEST 2018 amd64, CUSTOM kernel).

The hardware is a presumably UEFI capable ASROCK Z77-Pro4M (latest firmware 
available
from late 2013) equipted with a XEON IvyBridge:

CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  
Features=0xbfebfbff
  
Features2=0x7fbae3ff
  AMD Features=0x28100800
  AMD Features2=0x1
  Structured Extended Features=0x281
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16295137280 (15540 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs


The box isn't capable of booting FreeBSD in UEFI (while Linux and Windows seems 
to work).
So I'm stuck with BIOS.

Loading i915kms.ko/drm2.ko on the syst

Re: ifa_ifwithnet failed ???

2018-05-27 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Sun, 27 May 2018 03:17:07 +
"Pieper, Jeffrey E"  schrieb:

> I'm seeing this spam dmesg continuously on a build from this afternoon 
> (r334252):
> 
> May 27 03:06:03 u0855 kernel: ifa_ifwithnet failed
> May 27 03:06:03 u0855 syslogd: last message repeated 11 times
> May 27 03:06:03 u0855 kernel: .
> May 27 03:06:05 u0855 kernel: ifa_ifwithnet failed
> May 27 03:06:39 u0855 syslogd: last message repeated 60 times
> May 27 03:08:39 u0855 syslogd: last message repeated 59 times
> 
> 
> Is anyone else seeing this?
> 
> Jeff Pieper
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Me, too, on a router/firewall system running:

FreeBSD 12.0-CURRENT #7 r334236: Sat May 26 08:03:39 CEST 2018

The console is spammed with ifa_ifwithnet failed after first boot but while 
running, the
message disappears or at least the console isn't spammed any more.

oh

-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWwpR/gAKCRDS528fyFhY
lDydAf9r1QPwk6Fd51gNafTBV9Izzzcf6L0HJEyZWOdxZ2+3HmVWAv1jA9heq33q
NjnJRiCYcUo/aOQ0Ms1At0No2trXAfsEy47HzHvCSjVWnJvWJDR22LLpokAZyvfM
XBHZbPSBdLmvW75XSHqVfSzCKKcpy2qeLB19sTIKW3K/RIQkLxAL
=CUlq
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: svn commit: r333175 - in head/sys: kern net netinet netinet6 sys: TRAP 12

2018-05-05 Thread O. Hartmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Thu, 3 May 2018 22:23:52 +0200
"O. Hartmann" <ohartm...@walstatt.org> schrieb:


I'm not familiar with kernel debugging, so there are some struggles.

After compiling a debugging kernel on 

Version String: FreeBSD 12.0-CURRENT #2 r333269: Sat May  5 08:10:32 CEST 2018

Panic String: Lock tcp not exclusively locked @ 
/usr/src/sys/netinet/in_pcb.c:1391


And this is what I can provide you with:


Reading symbols from 
/usr/obj/usr/src/amd64.amd64/sys/WALHALL-DEBUG/kernel.full...done.

Unread portion of the kernel message buffer:
panic: Lock tcp not exclusively locked @ /usr/src/sys/netinet/in_pcb.c:1391

cpuid = 4
time = 1525510291
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e485e670
vpanic() at vpanic+0x1a3/frame 0xfe00e485e6d0
panic() at panic+0x43/frame 0xfe00e485e730
_rw_wunlock_cookie() at _rw_wunlock_cookie+0x137/frame 0xfe00e485e760
in_pcbfree() at in_pcbfree+0x51a/frame 0xfe00e485e7b0
tcp_usr_detach() at tcp_usr_detach+0x15e/frame 0xfe00e485e7f0
sofree() at sofree+0x2f4/frame 0xfe00e485e840
soclose() at soclose+0x387/frame 0xfe00e485e8b0
closef() at closef+0x1f5/frame 0xfe00e485e940
closefp() at closefp+0xa0/frame 0xfe00e485e980
amd64_syscall() at amd64_syscall+0x6d3/frame 0xfe00e485eab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00e485eab0
- --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x80111adda, rsp = 
0x7fffdf3f7228, rbp =
0x7fffdf3f7240 --- KDB: enter: panic

__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:231
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:365
#2  0x80597d5b in db_dump (dummy=, dummy2=,
dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:574
#3  0x80597ae6 in db_command (last_cmdp=, 
cmd_table=, dopager=) at /usr/src/sys/ddb/db_command.c:481 #4
out>0x80597814 in db_command_loop () at 
/usr/src/sys/ddb/db_command.c:534
#5  0x8059b04f in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:250 #6  0x80924463 in kdb_trap (type=3,
code=-61456, tf=) at /usr/src/sys/kern/subr_kdb.c:697 #7
0x80c80ab7 in trap (frame=0xfe00e485e5a0)
at /usr/src/sys/amd64/amd64/trap.c:550 #8   #9  kdb_enter
(why=0x80dd7b54 "panic", msg=) at 
/usr/src/sys/kern/subr_kdb.c:479
#10 0x808db500 in vpanic (fmt=, ap=0xfe00e485e710)
at /usr/src/sys/kern/kern_shutdown.c:851 #11 0x808db593 in panic
(fmt=0x8125bbd8  "\251\312\332\200\377\377\377\377")
at /usr/src/sys/kern/kern_shutdown.c:789 #12 0x808d65b7 in __rw_assert
(c=0xfe00111ee650, what=4, file=0x80dc5157 
"/usr/src/sys/netinet/in_pcb.c",
line=1391) at /usr/src/sys/kern/kern_rwlock.c:1426 #13 _rw_wunlock_cookie
(c=0xfe00111ee650, file=0x80dc5157 "/usr/src/sys/netinet/in_pcb.c",
line=1391) at /usr/src/sys/kern/kern_rwlock.c:362 #14 0x80a68caa in 
in_pcbfree
(inp=0xf80066058b10) at /usr/src/sys/netinet/in_pcb.c:1391 #15 
0x80b09a6e in
tcp_detach (so=, inp=)
at /usr/src/sys/netinet/tcp_usrreq.c:258 #16 tcp_usr_detach (so=)
at /usr/src/sys/netinet/tcp_usrreq.c:289 #17 0x8097c394 in sofree
(so=0xf8001988d358) at /usr/src/sys/kern/uipc_socket.c:1032 #18 
0x8097d487 in
soclose (so=0xf8001988d358) at /usr/src/sys/kern/uipc_socket.c:1126 #19
0x80885ad5 in fo_close (fp=, td=)
at /usr/src/sys/sys/file.h:348 #20 _fdrop (fp=, td=)
at /usr/src/sys/kern/kern_descrip.c:2957 #21 closef (fp=0xf80004ef4eb0,
td=0xf80019891560) at /usr/src/sys/kern/kern_descrip.c:2538 #22 
0x80882920 in
closefp (fdp=0xf80019553450, fd=12, fp=0xf80004ef4eb0, 
td=0xf80019891560,
holdleaders=0) at /usr/src/sys/kern/kern_descrip.c:1208 #23 0x80c82033 
in
syscallenter (td=0xf80019891560)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135 #24 amd64_syscall
(td=0xf80019891560, traced=0) at /usr/src/sys/amd64/amd64/trap.c:945 #25 
 #26 0x00080111adda in ?? () Backtrace stopped: Cannot 
access memory
at address 0x7fffdf3f7228 (kgdb) 




> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am Thu, 3 May 2018 12:53:05 -0700
> "K. Macy" <km...@freebsd.org> schrieb:
> 
> > Can you give any context on what they're doing? In addition - even on
> > a production kernel it's possible to compile in DDB to at least get a
> > backtrace. Your report only gives us enough information to know that  
> 
> Not at the moment. The immediate crash corrupted the /usr/src filesystem so I 
> can not
> recompile a kernel. Every attempt to /etc/netstart the network on the buggy 
> kernel ends
> up in a further destruction, so I stopped at this very moment and hopefully I 

Re: Nvidia issue with CURRENT

2018-04-23 Thread O. Hartmann
On Sun, 22 Apr 2018 14:38:55 +0200
Mariusz Zaborski  wrote:

> Hi,
> 
> Normally I build my CURRENT by myself from Xorg - r332861.
> But I also tried latest SNAPSHOT.
> 
> Thanks,
> Mariusz

All my boxes running with nVidia hardware running most recent CURRENT (compiled
this morning on an almost daily basis) and I'm using the lates official driver
available from nVidia, 390.48.

It happens to be as a natural byproduct of CURRENT that very often the kernel
module of the nVidia driver is out of sync so i made it a habit to recompile
the module from sources whenever I recompile/install a  kernel.

In /etc/src.conf , therefore you should add something similar to (like I added
to mine):

PORTS_MODULES=
PORTS_MODULES+= x11/nvidia-driver
PORTS_MODULES+= emulators/virtualbox-ose-kmod

This is one of the great advantages of having an operating system which you can
compile yourself. 

Regards,

oh

 
> 
> On 22 April 2018 at 14:24, Tommi Pernila  wrote:
> > Hi,
> >
> > are you running which version of CURRENT?
> > E.g. Some snapshot or did you compile from source?
> >
> > -Tommi
> >
> > On Sun, 22 Apr 2018 at 13.47, Mariusz Zaborski 
> > wrote:  
> >>
> >> Hello,
> >>
> >> I upgraded my FreeBSD to CURRENT and nvidia-drvier-390.48. But it's
> >> stop working.
> >> I tried also nvidia-driver-390.25 without luck as well.
> >>
> >> I have loaded nvidia-modeset.ko .
> >>
> >> While I'm rebooting my machine its also core dumping:
> >> https://people.freebsd.org/~oshogbo/nvidia-mail.png .
> >> I'm attaching also Xorg log.
> >>
> >> Is this a known issue?
> >>
> >> Thanks,
> >> Mariusz
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to
> >> "freebsd-current-unsubscr...@freebsd.org"  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


g_handleattr: md0 bio_length 24 len 31 -> EFAULT

2018-03-24 Thread O. Hartmann
Writing out memory (md) backed images of UFS2 filesystems (NanoBSD images, 
created via
the classical manual way, no makefs), my recent CURRENT system dumps the
console full of these error messages:

g_handleattr: md0 bio_length 24 len 31 -> EFAULT

I do not know what they are supposed to mean and I'd like to ask whether 
someone could
shed some light on this.

Thanks,

oh

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpZBRUPhAtYX.pgp
Description: OpenPGP digital signature


Re: /usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: main

2018-03-18 Thread O. Hartmann
stopped in /usr/src/lib/ncurses/form
> *** [all_subdir_lib/ncurses/form] Error code 2
> 
> make[4]: stopped in /usr/src/lib/ncurses
> --- all_subdir_lib/libarchive ---
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/lib/libarchive
> *** [all_subdir_lib/libarchive] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> --- all_subdir_lib/ncurses ---
> --- all_subdir_lib/ncurses/menu ---
> A failure has been detected in another branch of the parallel make
> 
> make[5]: stopped in /usr/src/lib/ncurses/menu
> *** [all_subdir_lib/ncurses/menu] Error code 2
> 
> make[4]: stopped in /usr/src/lib/ncurses
> --- all_subdir_lib/ncurses/ncursesw ---
> A failure has been detected in another branch of the parallel make
> 
> make[5]: stopped in /usr/src/lib/ncurses/ncursesw
> *** [all_subdir_lib/ncurses/ncursesw] Error code 2
> 
> make[4]: stopped in /usr/src/lib/ncurses
> 3 errors
> 
> make[4]: stopped in /usr/src/lib/ncurses
> *** [all_subdir_lib/ncurses] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> --- all_subdir_lib/libprocstat ---
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/lib/libprocstat
> *** [all_subdir_lib/libprocstat] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> --- all_subdir_lib/libunbound ---
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/lib/libunbound
> *** [all_subdir_lib/libunbound] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> --- all_subdir_lib/atf ---
> A failure has been detected in another branch of the parallel make
> 
> make[5]: stopped in /usr/src/lib/atf/libatf-c++
> *** [all_subdir_lib/atf/libatf-c++] Error code 2
> 
> make[4]: stopped in /usr/src/lib/atf
> 1 error
> 
> make[4]: stopped in /usr/src/lib/atf
> *** [all_subdir_lib/atf] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> --- all_subdir_lib/libsqlite3 ---
> A failure has been detected in another branch of the parallel make
> 
> make[4]: stopped in /usr/src/lib/libsqlite3
> *** [all_subdir_lib/libsqlite3] Error code 2
> 
> make[3]: stopped in /usr/src/lib
> 8 errors
> 
> make[3]: stopped in /usr/src/lib
> *** [all_subdir_lib] Error code 2
> 
> make[2]: stopped in /usr/src
> 1 error
> 
> make[2]: stopped in /usr/src
> *** [everything] Error code 2
> 
> make[1]: stopped in /usr/src
> 1 error
> 
> make[1]: stopped in /usr/src
> *** [buildworld] Error code 2
> 
> make: stopped in /usr/src
> 1 error
> 
> make: stopped in /usr/src
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

me, too here.

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpZmiXrll1MY.pgp
Description: OpenPGP digital signature


Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-17 Thread O. Hartmann
Am Sat, 17 Mar 2018 12:44:18 -0700
Mark Millard <marklmi26-f...@yahoo.com> schrieb:


Tried on the APU:


[...]

last pid: 17910;  load averages:  0.26,  0.16,
0.10
up 6+20:51:54  22:28:48 49 processes:  2 running, 46 sleeping, 1 waiting CPU:  
0.5%
user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.1% idle Mem: 27M Active, 
3772K Inact,
98M Laundry, 186M Wired, 32K Buf, 661M Free Swap: 7808M Total, 4204K Used, 
7804M Free

  PID USERNAME   THR PRI NICE   SIZERES   SWAP STATE   C   TIME CPU 
COMMAND
17615 root 1  220 13204K 0K  4064K pause   1   0:00   0.00% 
-csh
() 17002 root 1  200 12104K 0K  3108K wait3   0:00 
  0.00%
login [pam] () 975 root 1  200 14548K  1260K88K 
nanslp  3
0:00   0.00% /usr/local/sbin/smartd -c /usr/local/etc/smartd.conf -p 
/var/run/smartd.pid
989 root 1  200 32264K  8160K28K nanslp  2   0:21   0.00% 
ddclient -
sleeping for 1149 seconds (perl) 11 root 4 155 ki31 0K64K   
  0K
CPU00 652.1H 396.04% [idle] 997 asterisk59  520   133M 62684K   
  0K
select  0 297:57   2.68% /usr/local/sbin/asterisk -n -F -U asterisk 0 root  
  26
-16- 0K   416K 0K swapin  0  60:12   0.56% [kernel] 12 root 
   14
-52- 0K   224K 0K WAIT0  20:39   0.40% [intr] 17618 root
 1
200 13044K  3472K 0K CPU33   0:34   0.12% top -CawSoswap 579 root
1  200 15252K  3116K 0K select  0  37:16   0.05% /usr/sbin/ppp -quiet 
-ddial
-unit0 o2vdsl2 19 root 1 -16- 0K16K 0K -   1   
3:06
0.03% [rand_harvestq] 21 root 3 -16- 0K48K 0K 
psleep  3
1:21   0.02% [pagedaemon] 933 root 1  200 10892K  1688K 0K 
select
2   1:46 0.02% /usr/sbin/powerd

[...]

Sorry for the messy output ...


> On 2018-Mar-17, at 11:26 AM, Andriy Gapon  wrote:
> 
> > On 17/03/2018 18:51, Mark Millard wrote:  
> >> I'll  note that top was a -w that reports:
> >> 
> >>   -w Display approximate swap usage for each process.  
> > 
> > As far as I can tell, this option is quite broken.
> > The "approximate swap usage" it reports is nowhere like it.  
> 
> Too bad. Do you know if it is so messed up that the
> apparent order of "uses more" vs. "uses less" would be
> wrong when the difference in reported figures is fairly
> large? (I'd avoid assuming an order for sufficiently
> small differences [which still might be fairly large].)
> 
> Do you know if the system-wide figures from the summary
> line:
> 
> Swap: 61G Total, 61G Free
> (could also display an in-use figure)
> 
> are also broken as far as in-use would go? Should
> top just be avoided for most swap-in-use information?
> 
> More overall, if anyone knows of such: Is there a
> place to get reasonable swap-in-use information,
> per process and/or system-wide?
> 
> One thing I've wished for is what would be a low bound
> on the overall maximum-in-use figure (system wide), say
> by checking periodically a reasonable in-use figure and
> keeping track of (and reporting) the maximum-observed-so-far
> figure. This kind of background information could be
> used in choosing/adjusting a couple of poudriere-devel
> parameters that control how much parallel activity
> there can be.
> 
> (My local top implementation has an adjustment to also
> display such a system-wide maximum-observed-swap-used
> figure.)
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpymTqRNLYzC.pgp
Description: OpenPGP digital signature


Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-17 Thread O. Hartmann
from 11.x are 
> to be believed I don't know that it was me.  It is possible they have been 
> broken at different times for different reasons.  So I will continue to 
> look.
> 
> Thanks,
> Jeff
> 
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
> > ( dsl-only.net went
> > away in early 2018-Mar)
> >  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpbpcgnv_Wkg.pgp
Description: OpenPGP digital signature


Speed up CD/DVD-based FreeBSD

2018-03-11 Thread O. Hartmann
We have a special case of running FreeBSD (actually a NanoBSD) from a CD/DVD.
The reason behind using a CD/DVD is to prevent manipulations.

Now, after the GUI hass started, the system autologin a user and autostarts
Firefox. But starting Firefox takes ~ 5 - 7 minutes, while the operating system
takes 2 - 3 minutes. As you can imagine, this isn't quite a useful time.

Is there a simple way, considering enough RAM in the box, to speed up the
process? Loading Firefox makes the DVD drive moving the head very often - I
assume this is the fact because I can hear the head scratiching around very
intense.

Does FreeBSD bring tools/facilities onboard to achive what I'm requesting or do
I need an additional port/softwarepackage?

Any considerations are welcome.

Thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

2018-03-10 Thread O. Hartmann
ttp://www.lerctr.org/~ler  
> > > > 
> > > > -- 
> > > > Rod Grimes 
> > > > rgri...@freebsd.org  
> > > 
> > > -- 
> > > Larry Rosenman http://www.lerctr.org/~ler
> > > Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
> > > US Mail: 5708 Sabbia Drive, Round Rock, TX 78665-2106  
> > 
> > 
> > Hi.
> > 
> > I noticed this behavior as well and changed vfs.zfs.arc_max for a smaller 
> > size.
> > 
> > For me it started when I upgraded to 1200058, in this box I'm only using
> > poudriere for building tests.  
> 
> I've noticed that as well.
> 
> I have 16G of RAM and two disks, the first one is UFS with the system
> installation and the second one is ZFS which I use to store media and
> data files and for poudreire.
> 
> I don't recall the exact date, but it started fairly recently. System would
> swap like crazy to a point when I cannot even ssh to it, and can hardly
> login through tty: it might take 10-15 minutes to see a command typed in
> the shell.
> 
> I've updated loader.conf to have the following:
> 
> vfs.zfs.arc_max="4G"
> vfs.zfs.prefetch_disable="1"
> 
> It fixed the problem, but introduced a new one. When I'm building stuff
> with poudriere with ccache enabled, it takes hours to build even small
> projects like curl or gnutls.
> 
> For example, current build:
> 
> [10i386-default] [2018-03-07_07h44m45s] [parallel_build:] Queued: 3  Built: 1 
>  Failed:
> 0  Skipped: 0  Ignored: 0  Tobuild: 2   Time: 06:48:35 [02]: security/gnutls
> | gnutls-3.5.18 build   (06:47:51)
> 
> Almost 7 hours already and still going!
> 
> gstat output looks like this:
> 
> dT: 1.002s  w: 1.000s
>  L(q)  ops/sr/s   kBps   ms/rw/s   kBps   ms/w   %busy Name
> 0  0  0  00.0  0  00.00.0  da0
> 0  1  0  00.0  11280.70.1  ada0
> 1106106439   64.6  0  00.0   98.8  ada1
> 0  1  0  00.0  11280.70.1  ada0s1
> 0  0  0  00.0  0  00.00.0  ada0s1a
> 0  0  0  00.0  0  00.00.0  ada0s1b
> 0  1  0  00.0  11280.70.1  ada0s1d
> 
> ada0 here is UFS driver, and ada1 is ZFS.
> 
> > Regards.
> > -- 
> > Danilo G. Baio (dbaio)  
> 
> 
> 
> Roman Bogorodskiy


This is from a APU, no ZFS, UFS on a small mSATA device, the APU (PCenigine) 
works as a
firewall, router, PBX):

last pid:  9665;  load averages:  0.13,  0.13,  0.11
up 3+06:53:55  00:26:26 19 processes:  1 running, 18 sleeping CPU:  0.3% user,  
0.0%
nice,  0.2% system,  0.0% interrupt, 99.5% idle Mem: 27M Active, 6200K Inact, 
83M
Laundry, 185M Wired, 128K Buf, 675M Free Swap: 7808M Total, 2856K Used, 7805M 
Free
[...]

The APU is running CURRENT ( FreeBSD 12.0-CURRENT #42 r330608: Wed Mar  7 
16:55:59 CET
2018 amd64). Usually, the APU never(!) uses swap, now it is starting to swap 
like hell
for a couple of days and I have to reboot it failty often.

Another box, 16 GB RAM, ZFS, poudriere, the packaging box, is right now 
unresponsible:
after hours of building packages, I tried to copy the repository from one 
location on
the same ZFS volume to another - usually this task takes a couple of minutes 
for ~ 2200
ports. Now, I has taken 2 1/2 hours and the box got stuck, Ctrl-T  on the 
console
delivers:
load: 0.00  cmd: make 91199 [pfault] 7239.56r 0.03u 0.04s 0% 740k

No response from the box anymore.


The problem of swapping like hell and performing slow isn't an issue of the 
past days, it
is present at least since 1 1/2 weeks for now, even more. Since I build ports 
fairly
often, time taken on that specific box has increased from 2 to 3 days for all 
~2200
ports. The system has 16 GB of RAM, IvyBridge 4-core XEON at 3,4 GHz, if this 
information
matters. The box is consuming swap really fast.

Today is the first time the machine got inresponsible (no ssh, no console login 
so far).
Need to coldstart. OS is CURRENT as well.

Regards,

O. Hartmann


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpgUrGw4IbV4.pgp
Description: OpenPGP digital signature


CURRENT: md: g_handleattr: md0 bio_length 24 len 31 -> EFAULT

2018-02-28 Thread O. Hartmann
While writing out a md based disk image (NanoBSD) onto a ZFS based filesystem,
the console is flooded on CURRENT host (FreeBSD 12.0-CURRENT #78 r330019: Mon
Feb 26 16:23:09 CET 2018 amd64) with the message:

g_handleattr: md0 bio_length 24 len 31 -> EFAULT

Writing out the md image of a size of ~ 2,5 GB to ZFS filesystem takes more
than 20 minutes, which is a pain in the arse. ZFS hasn't any neat features
enabled or disabled, so deduplication is disabled, atime is off, checksum is
sha256 and compression is disabled. The box in question is a Haswell XEON, 6
cores, 3,4 GHz clock and 32 GB RAM - so insufficient performance should not be
the issue. 

What am I doing wrong?

Kind regards and thanks in advance,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-22 Thread O. Hartmann
Am Thu, 22 Feb 2018 19:56:26 +0100
"O. Hartmann" <ohartm...@walstatt.org> schrieb:

> Am Thu, 22 Feb 2018 10:53:46 -0700
> Ian Lepore <i...@freebsd.org> schrieb:
> 
> > On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote:  
> > > Am Wed, 21 Feb 2018 20:05:24 +0100
> > > "O. Hartmann" <o.hartm...@walstatt.org> schrieb:
> > > 
> > > > 
> > > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue
> > > > Feb 20 23:06:15 CET
> > > > 2018 amd64) I'm honored by this nice bug when calling top:
> > > > 
> > > > top: sysctl(vfs.bufspace...) expected 8, got 4
> > > > 
> > > > 
> > > > Regards,
> > > > 
> > > > oh
> > > I still can not use "top", it quits with the error mentioned above.
> > > Whats is wrong with
> > > my setup?
> > > 
> > 
> > It seems like the two big candidates must be mismatch between kernel
> > and userland, or maybe 32/64-bit mismatch between the kernel and top.
> > 
> > What's the output of
> > 
> >   uname -pmUK  
> amd64 amd64 1200058 1200058
> 
> >   file `which top`  
> /usr/bin/top: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), 
> dynamically
> linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200058), 
> FreeBSD-style,
> stripped
> >   ldd `which top`  
> /usr/bin/top:
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x800258000)
> libm.so.5 => /lib/libm.so.5 (0x8002bd000)
> libkvm.so.7 => /lib/libkvm.so.7 (0x8002ed000)
> libjail.so.1 => /lib/libjail.so.1 (0x80030)
> libc.so.7 => /lib/libc.so.7 (0x800309000)
> libelf.so.2 => /lib/libelf.so.2 (0x800712000)
> > 
> > -- Ian
> >   
> 
> ... so ...
> 
> @ Mateusz Guzik: I missed your patch - didn't apply clean, was rejected and I
> accidentally build a "usual" kernel. Will try again. 
> 
> At revision 329831, the target line in question is at line 414, not 423 as of 
> your patch
> (old source?).
> 

Stupid me ... 

The patch, Mateusz provided, worked! My sight is some kinf of "bend", so I 
missed the
correct line.

Mateusz provided me with this patch, which solved the issue:

Index: sys/kern/vfs_bio.c
===
--- sys/kern/vfs_bio.c  (revision 329832)
+++ sys/kern/vfs_bio.c  (working copy)
@@ -423,7 +423,7 @@
lvalue = 0;
for (i = 0; i < clean_domains; i++)
lvalue += bdclean[i].bd_bufspace;
-   return (sysctl_handle_int(oidp, , 0, req));
+   return (sysctl_handle_long(oidp, , 0, req));
 }
 #endif


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpi_MwxbTXpK.pgp
Description: OpenPGP digital signature


Re: top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-22 Thread O. Hartmann
Am Thu, 22 Feb 2018 10:53:46 -0700
Ian Lepore <i...@freebsd.org> schrieb:

> On Thu, 2018-02-22 at 18:41 +0100, O. Hartmann wrote:
> > Am Wed, 21 Feb 2018 20:05:24 +0100
> > "O. Hartmann" <o.hartm...@walstatt.org> schrieb:
> >   
> > > 
> > > On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue
> > > Feb 20 23:06:15 CET
> > > 2018 amd64) I'm honored by this nice bug when calling top:
> > > 
> > > top: sysctl(vfs.bufspace...) expected 8, got 4
> > > 
> > > 
> > > Regards,
> > > 
> > > oh  
> > I still can not use "top", it quits with the error mentioned above.
> > Whats is wrong with
> > my setup?
> >   
> 
> It seems like the two big candidates must be mismatch between kernel
> and userland, or maybe 32/64-bit mismatch between the kernel and top.
> 
> What's the output of
> 
>   uname -pmUK
amd64 amd64 1200058 1200058

>   file `which top`
/usr/bin/top: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), 
dynamically linked,
interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200058), FreeBSD-style, 
stripped
>   ldd `which top`
/usr/bin/top:
libncursesw.so.8 => /lib/libncursesw.so.8 (0x800258000)
libm.so.5 => /lib/libm.so.5 (0x8002bd000)
libkvm.so.7 => /lib/libkvm.so.7 (0x8002ed000)
libjail.so.1 => /lib/libjail.so.1 (0x80030)
libc.so.7 => /lib/libc.so.7 (0x800309000)
libelf.so.2 => /lib/libelf.so.2 (0x800712000)
> 
> -- Ian
> 

... so ...

@ Mateusz Guzik: I missed your patch - didn't apply clean, was rejected and I
accidentally build a "usual" kernel. Will try again. 

At revision 329831, the target line in question is at line 414, not 423 as of 
your patch
(old source?).

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpZisRXFpEvJ.pgp
Description: OpenPGP digital signature


Re: top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-22 Thread O. Hartmann
Am Wed, 21 Feb 2018 20:05:24 +0100
"O. Hartmann" <o.hartm...@walstatt.org> schrieb:

> On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 
> 23:06:15 CET
> 2018 amd64) I'm honored by this nice bug when calling top:
> 
> top: sysctl(vfs.bufspace...) expected 8, got 4
> 
> 
> Regards,
> 
> oh

I still can not use "top", it quits with the error mentioned above. Whats is 
wrong with
my setup?

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpElXx3PU815.pgp
Description: OpenPGP digital signature


Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

2018-02-22 Thread O. Hartmann
On Thu, 22 Feb 2018 09:26:20 +0100
Gary Jennejohn <gljennj...@gmail.com> wrote:

> On Thu, 22 Feb 2018 08:37:07 +0100
> "O. Hartmann" <ohartm...@walstatt.org> wrote:
> 
> > On Tue, 20 Feb 2018 12:39:53 +0100
> > Gary Jennejohn <gljennj...@gmail.com> wrote:
> >   
> > > On Mon, 19 Feb 2018 14:18:15 -0800
> > > "Chris H" <bsd-li...@bsdforge.com> wrote:
> > > 
> > > > I'm seeing a number of messages like the following:
> > > > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d
> > > > 
> > > > and was wondering if it's anything to be concerned with, or whether
> > > > fsck(8) is fixing them.
> > > > This began to happen when the power went out on a new install:
> > > > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59
> > > > PST 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
> > > > which hadn't yet been hooked up to the UPS.
> > > > I performed an fsck in single user mode upon power-up. Which ended with
> > > > the mount points being masked CLEAN. I was asked if I wanted to use the
> > > > JOURNAL. I answered Y.
> > > > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd
> > > > thusly: newfs -U -j
> > > > 
> > > > Thank you for all your time, and consideration.
> > > >   
> > > 
> > > fsck fixes these errors only when the user does NOT use the journal.
> > > You should re-do the fsck.
> > > 
> > 
> > When first these mysterious errors occured on several boxes running CURRENT,
> > that was in December 2017 if I'm right, I also whitnessed mysterious and
> > frequent crashes on several SSD driven machines, where this error described
> > above occured.
> > 
> > While the error vanished somehow in the meanwhile while CURRENT proceeds,
> > the crashes continued - on two boxes, I dumped restore the OS on the
> > system's SSD by reformatting the SSD from sratch (UFS2, soft update+
> > journaling). On those boxes the mysterious crashes vanished since then!
> > 
> > On box left so far, my workstation. And this box continous to crash now and
> > started crashing today again while compiling world/kernel.
> > 
> > The fun-part is: even after a clean shutdown, where I can not detect any
> > filesystem inconsistencies and rebooting and, again: no reported
> > inconsistencies on the console/messages/logs, the box crashes spontanously.
> > Now (today) I could trigger the reboot by starting "make -j4 buildworld
> > buildkernel" and after showing the initial compiler statements/build
> > framework statements, the box went to Nirwana. A well known phenomenon
> > right now.
> > 
> > I checked now the consistency of the filesystem, here is the result of
> > the /usr/obj tree, which is a dedicated GPT partition
> > (label: /dev/gpt/usr.obj):
> > 
> > 
> > [...]
> >  root@box1:~ # fsck -fy /dev/gpt/usr.obj
> > ** /dev/gpt/usr.obj
> > ** Last Mounted on /usr/obj
> > ** Phase 1 - Check Blocks and Sizes
> > ** Phase 2 - Check Pathnames
> > UNALLOCATED  I=515  OWNER=root MODE=0
> > SIZE=0 MTIME=Feb 22 07:25 2018 
> > NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new
> > 
> > UNEXPECTED SOFT UPDATE INCONSISTENCY
> > 
> > REMOVE? yes
> > 
> > DIRECTORY CORRUPTED  I=169691  OWNER=root MODE=40775
> > SIZE=1536 MTIME=Feb 22 05:16 2018 
> > DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd
> > 
> > UNEXPECTED SOFT UPDATE INCONSISTENCY
> > 
> > SALVAGE? yes
> > 
> > ** Phase 3 - Check Connectivity
> > ** Phase 4 - Check Reference Counts
> > ** Phase 5 - Check Cyl groups
> > FREE BLK COUNT(S) WRONG IN SUPERBLK
> > SALVAGE? yes
> > 
> > SUMMARY INFORMATION BAD
> > SALVAGE? yes
> > 
> > BLK(S) MISSING IN BIT MAPS
> > SALVAGE? yes
> > 
> > 126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4%
> > fragmentation)
> > 
> > * FILE SYSTEM MARKED DIRTY *
> > 
> > * FILE SYSTEM WAS MODIFIED *
> > 
> > * PLEASE RERUN FSCK *
> > 
> > [...]
> > 
> > When doing a installworld, I pre-emptively perform in single user mode
> > before mounting the partitions a "fsck -yf" two times. In most cases, the
> > filesystem are reported clean, but sometimes especially those under high
> > I/O (/usr/src and mostly /usr/obj on this build machine

Re: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

2018-02-21 Thread O. Hartmann
On Tue, 20 Feb 2018 12:39:53 +0100
Gary Jennejohn  wrote:

> On Mon, 19 Feb 2018 14:18:15 -0800
> "Chris H"  wrote:
> 
> > I'm seeing a number of messages like the following:
> > kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d
> > 
> > and was wondering if it's anything to be concerned with, or whether
> > fsck(8) is fixing them.
> > This began to happen when the power went out on a new install:
> > FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST
> > 2017 root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
> > which hadn't yet been hooked up to the UPS.
> > I performed an fsck in single user mode upon power-up. Which ended with the
> > mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL.
> > I answered Y.
> > FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly:
> > newfs -U -j
> > 
> > Thank you for all your time, and consideration.
> >   
> 
> fsck fixes these errors only when the user does NOT use the journal.
> You should re-do the fsck.
> 

When first these mysterious errors occured on several boxes running CURRENT,
that was in December 2017 if I'm right, I also whitnessed mysterious and
frequent crashes on several SSD driven machines, where this error described
above occured.

While the error vanished somehow in the meanwhile while CURRENT proceeds, the
crashes continued - on two boxes, I dumped restore the OS on the system's SSD
by reformatting the SSD from sratch (UFS2, soft update+ journaling). On those
boxes the mysterious crashes vanished since then!

On box left so far, my workstation. And this box continous to crash now and
started crashing today again while compiling world/kernel.

The fun-part is: even after a clean shutdown, where I can not detect any
filesystem inconsistencies and rebooting and, again: no reported
inconsistencies on the console/messages/logs, the box crashes spontanously. Now
(today) I could trigger the reboot by starting "make -j4 buildworld
buildkernel" and after showing the initial compiler statements/build framework
statements, the box went to Nirwana. A well known phenomenon right now.

I checked now the consistency of the filesystem, here is the result of
the /usr/obj tree, which is a dedicated GPT partition
(label: /dev/gpt/usr.obj):


[...]
 root@box1:~ # fsck -fy /dev/gpt/usr.obj
** /dev/gpt/usr.obj
** Last Mounted on /usr/obj
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
UNALLOCATED  I=515  OWNER=root MODE=0
SIZE=0 MTIME=Feb 22 07:25 2018 
NAME=/usr/src/amd64.amd64/sys/BOX1/config.c.new

UNEXPECTED SOFT UPDATE INCONSISTENCY

REMOVE? yes

DIRECTORY CORRUPTED  I=169691  OWNER=root MODE=40775
SIZE=1536 MTIME=Feb 22 05:16 2018 
DIR=/usr/src/amd64.amd64/sys/BOX1/modules/usr/src/sys/modules/nfsd

UNEXPECTED SOFT UPDATE INCONSISTENCY

SALVAGE? yes

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

126922 files, 848197 used, 1178482 free (89210 frags, 136159 blocks, 4.4%
fragmentation)

* FILE SYSTEM MARKED DIRTY *

* FILE SYSTEM WAS MODIFIED *

* PLEASE RERUN FSCK *

[...]

When doing a installworld, I pre-emptively perform in single user mode before
mounting the partitions a "fsck -yf" two times. In most cases, the filesystem
are reported clean, but sometimes especially those under high I/O (/usr/src and
mostly /usr/obj on this build machine) there are reports of corruption.

As I reported, the very same behaviour occured on three boxes simultanously and
I got rid of it by completely reformatting the SSDs (never had issues so far
with HDD based boxes!). 

I hope I can refurbish this weekend the remaining box and I could report, if
desired, whether this box returns to a healthy state as the others or if my
observation was a simple coincidence of issues ...

Thanks for the patience,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


top: sysctl(vfs.bufspace...) expected 8, got 4

2018-02-21 Thread O. Hartmann
On CURRENT ( 12.0-CURRENT FreeBSD 12.0-CURRENT #196 r329679: Tue Feb 20 
23:06:15 CET 2018
 amd64) I'm honored by this nice bug when calling top:

top: sysctl(vfs.bufspace...) expected 8, got 4


Regards,

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpGq73wGLtKr.pgp
Description: OpenPGP digital signature


Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-13 Thread O. Hartmann
On Sat, 10 Feb 2018 09:54:49 +0100
Marko Zec <z...@fer.hr> wrote:

> On Sat, 10 Feb 2018 08:52:21 +0100
> "O. Hartmann" <ohartm...@walstatt.org> wrote:
> 
> > Am Fri, 09 Feb 2018 16:43:17 +
> > "Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net> schrieb:
> >   
> > > On 9 Feb 2018, at 16:22, O. Hartmann wrote:
> > > 
> > > > Am Thu, 8 Feb 2018 09:31:15 +0100
> > > > "O. Hartmann" <ohartm...@walstatt.org> schrieb:
> > > >
> > > > Is this problem to trivial?  
> > > 
> > > I read through it yesterday and found myself in the position that I
> > > need a whiteboard or paper and pencil or an ASCII art of your
> > > situation.  But by the time I made it to the question I was
> > > basically lost.  Could you massively simplify this and maybe
> > > produce the ASCII art?
> > > 
> > > /bz
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to
> > > "freebsd-current-unsubscr...@freebsd.org"
> > 
> > All right.
> > 
> > I'm not much of an artist and at this very moment, I haven't much
> > experience with neat ASCII art tools. But I'll provide a sketch
> > later, but I also will simplify  the situation.
> > 
> > Consider three "vswitches", basically based on the creation of
> > bridges, bridge0, bridge1, bridge2. Create at least three individual
> > vnet-jails attached to each vbridge. Those jails have epair pseudo
> > devices. The jail itself owns the "a-part" of the epair and the
> > b-part is "member of the bridge". Each jail's epairXXXa has an IP
> > assigned of the network the vswitch is part of. I mention a- and
> > b-part of the epair here, because I thought it could matter, but I
> > think for symmetry reasons it doesn't.
> > 
> > Now consider a further, special jail. This jail is supposed to have
> > three epair devices, each one is reaching into one of the vbridges.
> > This jail is the router/routing jail. Later, this jail should filter
> > via IPFW the traffic between the three vbridges according to rules,
> > but this doesn't matter here, beacuase the basics are not working as
> > expected.
> > 
> > Now the problems. It doesn't matter on which jail of the three
> > vswitches I login, the moment a vbridge has more than two member
> > epairs (one  is alway member of the routing jail, now consider a
> > database jail and a webserver jail), pinging each jail or the routing
> > jail fails. It works sometimes for a couple of ICMP packets and then
> > stops.
> > 
> > If each vbridge has only one member jail, I have NO PROBLEMS
> > traversing accordingly to the static routing rules from one vbridge
> > to any other, say from vbridge1 to vbridge0 or vbridge2 and any
> > permutation of that.
> > 
> > The moment any of the bridges gets an additional member epair
> > interface (so the bridge has at least three members including the on
> > reaching into the virtual router jail) the vbridge seems to operate
> > unpredictable (to me). Pinging jails memeber of that vbridge are
> > unreachable.
> > 
> > Technical information:
> > 
> > The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel)
> > declines packets by default. Each jail is configured to have ipfw
> > "open".
> > 
> > Thanks for the patience.  
> 
> If you could provide a script which sets up the topology you described
> in two lengthy posts then others could reproduce this, and your chances
> of getting useful feedback would certainly increase.
> 
> We also have a graphical tool (https://github.com/imunes/imunes) which
> can set up a topology like you described in a few clicks of a mouse,
> albeit using netgraph and ng_eiface instead of epairs, but I assume this
> is irellevant as long as you are not aiming for maximum packet
> throughputs.  If you attempt to use this tool, note that selecting
> "stpswitch" will create if_bridge instances, whereas "lanswitch"
> creates ng_bridge instances.
> 
> Good luck,
> 
> Marko
> 
> 
> > 
> > Kind regards,
> > 
> > O. Hartmann  
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-c

Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-12 Thread O. Hartmann
On Mon, 12 Feb 2018 09:37:47 +0100
"O. Hartmann" <ohartm...@walstatt.org> wrote:

> On Sat, 10 Feb 2018 11:52:18 +0100
> Olivier Cochard-Labbé <oliv...@freebsd.org> wrote:
> 
> > On Sat, Feb 10, 2018 at 8:52 AM, O. Hartmann <ohartm...@walstatt.org> wrote:
> >   
> > >
> > > The moment any of the bridges gets an additional member epair interface
> > > (so the bridge
> > > has at least three members including the on reaching into the virtual
> > > router jail) the
> > > vbridge seems to operate unpredictable (to me). Pinging jails memeber of
> > > that vbridge
> > > are unreachable.
> > >
> > >
> > ​First idea:
> > Did you try with a more simple setup, like with just 3 jails members of one
> > bridge ?  
> > => I've tried it on a -head, and all 4 members  (3 jails and the host)
> > reach to communicate.
> > 
> > Second idea:
> > Can you check that all epairs have different MAC address each ?​
> > I hit this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176671  
> 
> Wow, that PR is from 2013(!) and it is still not solved?
> 
> > 
> > Regards,
> > 
> > Olivier
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"  
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

After rebooting recent CURRENT, the view with "ifconfig -a ether" looked good
so far, each epair/bridge has its unique MAC.

But then, login on the jails and checking the epair's counterpart owned by the
VIMAGE jail, I found almost EVERY jail has the same MAC, even those jails
members of the same bridge:

[...]
jail 11  on bridge2
epair20129a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500 options=8
ether 02:68:d0:00:07:0a

jail 10 on bridge2
epair20128a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500 options=8
ether 02:68:d0:00:07:0a

jail 9 on bridge 1
epair10250a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500 options=8
ether 02:68:d0:00:07:0a

jail 8 on bridge1
epair10238a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
1500 options=8
ether 02:68:d0:00:07:0a

jail 7 on bridge0
epair238a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8
ether 02:68:d0:00:07:0a

epair251a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8
ether 02:68:d0:00:07:0a

The way I create epairs and put them into a jail's context/domain is straight
forward. In jail.conf, I have more generic setup with variables like:

# DNS Master
ns1 {
$if =   "2";
$ip4_addr = "10.10.0.${if}";
$ip4_cidr = "24";
$ip4_my_default_route = "10.10.0.1";
$vnet_if =  "epair${if}";
$home_bridge =  "${if_bridge_core}";

depend= "vrouter";

allow.raw_sockets=  "1";
}


and in the common portion of jail.conf definitions, I use this:

[...]

vnet =  "new";
vnet.interface ="${vnet_if}a";
persist;

exec.clean;

exec.start= "";
exec.start+="/sbin/ifconfig ${vnet_if}a inet
${ip4_addr}/${ip4_cidr} up"; exec.start+="/bin/sh /etc/rc";
exec.start+="/sbin/route add default ${ip4_my_default_route}";
exec.start+="/sbin/sysctl net.link.bridge.pfil_member=0";
exec.start+="/sbin/sysctl net.link.bridge.pfil_bridge=0";
exec.start+="/sbin/sysctl net.link.bridge.pfil_onlyip=0";

exec.stop=  "/bin/sh /etc/rc.shutdown";

exec.prestart=  "";
exec.prestart+= "ifconfig ${vnet_if} create";
exec.prestart+= "ifconfig ${vnet_if}b up";
exec.prestart+= "ifconfig ${home_bridge} addm ${vnet_if}b up";

exec.poststop=  "ifconfig ${home_bridge} deletem ${vnet_if}b";
exec.poststop+= "ifconfig ${vnet_if}b destroy";

exec.consolelog="/var/log/jail_${name}_console.log";


The big question here is: when a jail with VIMAGE kernel "swallows" a
epair-pseudo device, it leaves the ciontext or visibility of the host. How can
the FreeBSD VIMAGE kernel then know about what former epair's MAC was? Is this
mechanism maybe the culprit? It is just a thought, so I do not want to be
beheaded - I'm not much into system development.


Kind regards,

O. Hartmann
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-12 Thread O. Hartmann
On Sat, 10 Feb 2018 11:52:18 +0100
Olivier Cochard-Labbé <oliv...@freebsd.org> wrote:

> On Sat, Feb 10, 2018 at 8:52 AM, O. Hartmann <ohartm...@walstatt.org> wrote:
> 
> >
> > The moment any of the bridges gets an additional member epair interface
> > (so the bridge
> > has at least three members including the on reaching into the virtual
> > router jail) the
> > vbridge seems to operate unpredictable (to me). Pinging jails memeber of
> > that vbridge
> > are unreachable.
> >
> >  
> ​First idea:
> Did you try with a more simple setup, like with just 3 jails members of one
> bridge ?
> => I've tried it on a -head, and all 4 members  (3 jails and the host)  
> reach to communicate.
> 
> Second idea:
> Can you check that all epairs have different MAC address each ?​
> I hit this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176671

Wow, that PR is from 2013(!) and it is still not solved?

> 
> Regards,
> 
> Olivier
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-12 Thread O. Hartmann
On Sat, 10 Feb 2018 11:52:18 +0100
Olivier Cochard-Labbé <oliv...@freebsd.org> wrote:

> On Sat, Feb 10, 2018 at 8:52 AM, O. Hartmann <ohartm...@walstatt.org> wrote:
> 
> >
> > The moment any of the bridges gets an additional member epair interface
> > (so the bridge
> > has at least three members including the on reaching into the virtual
> > router jail) the
> > vbridge seems to operate unpredictable (to me). Pinging jails memeber of
> > that vbridge
> > are unreachable.
> >
> >  
> ​First idea:
> Did you try with a more simple setup, like with just 3 jails members of one
> bridge ?
> => I've tried it on a -head, and all 4 members  (3 jails and the host)  
> reach to communicate.

Yes, I did.

I used to setup one bridge (bridge0) and three jails. Each jail owns its
epairXXa device with IP assigned. epairXXb of each jail is member of the
bridge. Bridge is up, epairXXb is up.

> 
> Second idea:
> Can you check that all epairs have different MAC address each ?​
> I hit this bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176671

Very good shot! Thanks. No, they do not have all of them unique MAC adrresses
and in some occassions members of the very same bridge have the very same MAC
addresses, mostly the a-part of the epair:

From console:
[...]
ng_ether_ifnet_arrival_event: can't re-name node epair10250a
==>> epair20128a: Ethernet address: 02:ce:d0:00:07:0a
epair20128b: Ethernet address: 02:ce:d0:00:13:0b
epair20128a: link state changed to UP
epair20128b: link state changed to UP
epair20128b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair20128a
==>> epair20129a: Ethernet address: 02:ce:d0:00:07:0a
epair20129b: Ethernet address: 02:ce:d0:00:14:0b
epair20129a: link state changed to UP
epair20129b: link state changed to UP
epair20129b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair20129a

epair20XXX are member of bridge2 and dedicated epairs of jails.

The following is the desastrous picture of bridge1:

[...]
==>> epair235a: Ethernet address: 02:ce:d0:00:07:0a
epair235b: Ethernet address: 02:ce:d0:00:0d:0b
epair235a: link state changed to UP
epair235b: link state changed to UP
epair235b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair235a
==>> epair237a: Ethernet address: 02:ce:d0:00:07:0a
epair237b: Ethernet address: 02:ce:d0:00:0e:0b
epair237a: link state changed to UP
epair237b: link state changed to UP
epair237b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair237a
==>> epair251a: Ethernet address: 02:ce:d0:00:07:0a
epair251b: Ethernet address: 02:ce:d0:00:0f:0b
epair251a: link state changed to UP
epair251b: link state changed to UP
epair251b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair251a
==>> epair238a: Ethernet address: 02:ce:d0:00:07:0a
epair238b: Ethernet address: 02:ce:d0:00:10:0b
epair238a: link state changed to UP
epair238b: link state changed to UP
epair238b: promiscuous mode enabled
ng_ether_ifnet_arrival_event: can't re-name node epair238a
[...]


This is on CURRENT (FreeBSD 12.0-CURRENT #36 r329150: Mon Feb 12 06:30:47 CET
2018 amd64).

I did check on Friday in the bureau and didn't catch it since I was checking on
each jail, but the console log accessed via dmesg revealed the problem very
easily.

I did a check on the 11.1-RELENG-p6 box and I got the same picture there,
different, but very similar setup. 

So I didn't see it in the masses of epairs our setup requires :-(

I'll go now for setting MAC addresses manually and check functionality again.

> 
> Regards,
> 
> Olivier

Kind regards,

Oliver
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-09 Thread O. Hartmann
Am Fri, 09 Feb 2018 16:43:17 +
"Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net> schrieb:

> On 9 Feb 2018, at 16:22, O. Hartmann wrote:
> 
> > Am Thu, 8 Feb 2018 09:31:15 +0100
> > "O. Hartmann" <ohartm...@walstatt.org> schrieb:
> >
> > Is this problem to trivial?  
> 
> I read through it yesterday and found myself in the position that I need 
> a whiteboard or paper and pencil or an ASCII art of your situation.  But 
> by the time I made it to the question I was basically lost.  Could you 
> massively simplify this and maybe produce the ASCII art?
> 
> /bz
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

All right.

I'm not much of an artist and at this very moment, I haven't much experience 
with neat
ASCII art tools. But I'll provide a sketch later, but I also will simplify  the 
situation.

Consider three "vswitches", basically based on the creation of bridges, 
bridge0, bridge1,
bridge2. Create at least three individual vnet-jails attached to each vbridge. 
Those
jails have epair pseudo devices. The jail itself owns the "a-part" of the epair 
and the
b-part is "member of the bridge". Each jail's epairXXXa has an IP assigned of 
the network
the vswitch is part of. I mention a- and b-part of the epair here, because I 
thought it
could matter, but I think for symmetry reasons it doesn't.

Now consider a further, special jail. This jail is supposed to have three epair 
devices,
each one is reaching into one of the vbridges. This jail is the router/routing 
jail.
Later, this jail should filter via IPFW the traffic between the three vbridges 
according
to rules, but this doesn't matter here, beacuase the basics are not working as 
expected.

Now the problems. It doesn't matter on which jail of the three vswitches I 
login, the
moment a vbridge has more than two member epairs (one  is alway member of the 
routing
jail, now consider a database jail and a webserver jail), pinging each jail or 
the
routing jail fails. It works sometimes for a couple of ICMP packets and then 
stops.

If each vbridge has only one member jail, I have NO PROBLEMS traversing 
accordingly to
the static routing rules from one vbridge to any other, say from vbridge1 to 
vbridge0 or
vbridge2 and any permutation of that.

The moment any of the bridges gets an additional member epair interface (so the 
bridge
has at least three members including the on reaching into the virtual router 
jail) the
vbridge seems to operate unpredictable (to me). Pinging jails memeber of that 
vbridge
are unreachable.

Technical information:

The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel) declines 
packets by
default. Each jail is configured to have ipfw "open".

Thanks for the patience.

Kind regards,

O. Hartmann


pgpruzqWVMaOU.pgp
Description: OpenPGP digital signature


Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-09 Thread O. Hartmann
Am Thu, 8 Feb 2018 09:31:15 +0100
"O. Hartmann" <ohartm...@walstatt.org> schrieb:

> Hello,
> 
> I fight with the following problem without any kind of success and I need some
> help and/or advice.
> 
> We are running several CURRENT and 11.1-RELENG-p6 boxes. CURRENT is at the 
> most
> recent version as of today.
> 
> VIMAGE is compiled in into all kernels.
> IPFW is compiled into all kernels and is the one and only firewall used.
> On CURRENT, the host's ipfw is set to "OPEN" (using the rc.-scripts so far). 
> By
> convention, I address the host running the kernel by "host".
> 
> Every jail is created/configured with its own "vnet" cloned network stack
> (vnet=new).
> 
> All hosts do have at least three physical NICs. The host itself is supposed to
> be member of the "friendly" network via a dedicated NIC. The two remaining 
> NICs
> are split into fractions belonging to an "hostile" network on which I'd like 
> to
> place exposed jails (for now), and to the "friendly" network, on which also
> jails will be hosted, but via a dedicated NIC.
> 
> Inbetween those two networks, the host will have a third, intermediate,
> network, call it the "service" network.
> 
> The following will be true for ALL jails created, including the host itself:
> 
> net.link.bridge.pfil_member=0
> net.link.bridge.pfil_bridge=0
> net.link.bridge.pfil_onlyip=0
> 
> First, I clone/create three bridge(4) devices, bridge0 (considered to be the
> "glue" between the "service" jails), bridge1 (considered to be the glue 
> between
> the jails on the friednly network side) and bridge2, which is the glue between
> the jails on the hostile side. bridge1 has eth1 as a member, which provides 
> the
> physical access to the friendly network, eth2 is member of bridge2, which
> provides access to the hostile network.
> 
> By convention, when creating epair(4), the a-portion belongs to the jail 
> itself
> and is assigned with an IPv6 address. The b-portion of the epair(4) is member
> of its bridge according to its realm (friendly, service or hostile network). 
> 
> Additionally, there is a special jail, the router, which has three epair(4)
> devices, the b-portion of the epair is member of the appropriate bridge(4) and
> this router jail has static routes assigned, pointing to the appropriate
> epairXXXa that is suppoesd to be the link into the correct bridge/network. 
> IPFW
> is set to open on this jail (for now). On this special
> jail it is set: net.inet.ip.forwarding=1.
> 
> I hope, the topology is clear so far. All epairs or epair endpoints as well as
> the bridges are UP! Double checked this.
> 
> Jails on bridge0 (service net) have IPs in the range 10.10.0.0/24, the
> b-portion of the routing jail's epair is member of bridge0, as described 
> above,
> and the a-portion of the epair has IP 10.10.0.1. Default route on each jeail
> on bridge0 is set to 10.10.0.1 accordingly.
> 
> Consider a similar setup on the other jails on the friendly and hostile
> network, except the fact that their bridges do have a physical NIC to which
> they may have access to a real network.
> 
> The setup might not be ideal and/or applicable for the purpose of separartion
> of networks virtually, but that shouldn't be the subject here. More important
> is that I assume that I haven't understood some essentials, because the setup
> doens't work as expected. Furthermore, it behaves on FreeBSD 11.1-RELENG-p6
> sometimes completely unpredictable - but in that special case, I think I ran
> IPFW on the host as "WORKSTATION" and dynamic rules may play an important role
> here. But focussing on the CURRENT box, the host's IPFW is set to OPEN.
> 
> With jexec -l hostA I gain access to host A on the "service" bridge0 and I
> want to ping its neighbour, hostB, on the same bridge and in the same net. It
> doesn't work! From the routing jail, I CAN NOT ping any host on bridge0. The
> routing jail has these network settings:
> 
> [... routing jail ...]
>  lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> options=63<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
> inet 127.0.0.1 netmask 0xff00 
> groups: lo
> [epair to bridge0 - service net] 
> epair4000a: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 
> 1500
> options=8
> ether 02:57:d0:00:07:0a
> inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255 
> media: Ethernet 10Gbase-T (10Gbase-T )
> status: active
> groups: epair
> [epair to bridge1, friendly net] 
> epair4001a: flags=8843&l

VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-08 Thread O. Hartmann
Hello,

I fight with the following problem without any kind of success and I need some
help and/or advice.

We are running several CURRENT and 11.1-RELENG-p6 boxes. CURRENT is at the most
recent version as of today.

VIMAGE is compiled in into all kernels.
IPFW is compiled into all kernels and is the one and only firewall used.
On CURRENT, the host's ipfw is set to "OPEN" (using the rc.-scripts so far). By
convention, I address the host running the kernel by "host".

Every jail is created/configured with its own "vnet" cloned network stack
(vnet=new).

All hosts do have at least three physical NICs. The host itself is supposed to
be member of the "friendly" network via a dedicated NIC. The two remaining NICs
are split into fractions belonging to an "hostile" network on which I'd like to
place exposed jails (for now), and to the "friendly" network, on which also
jails will be hosted, but via a dedicated NIC.

Inbetween those two networks, the host will have a third, intermediate,
network, call it the "service" network.

The following will be true for ALL jails created, including the host itself:

net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_onlyip=0

First, I clone/create three bridge(4) devices, bridge0 (considered to be the
"glue" between the "service" jails), bridge1 (considered to be the glue between
the jails on the friednly network side) and bridge2, which is the glue between
the jails on the hostile side. bridge1 has eth1 as a member, which provides the
physical access to the friendly network, eth2 is member of bridge2, which
provides access to the hostile network.

By convention, when creating epair(4), the a-portion belongs to the jail itself
and is assigned with an IPv6 address. The b-portion of the epair(4) is member
of its bridge according to its realm (friendly, service or hostile network). 

Additionally, there is a special jail, the router, which has three epair(4)
devices, the b-portion of the epair is member of the appropriate bridge(4) and
this router jail has static routes assigned, pointing to the appropriate
epairXXXa that is suppoesd to be the link into the correct bridge/network. IPFW
is set to open on this jail (for now). On this special
jail it is set: net.inet.ip.forwarding=1.

I hope, the topology is clear so far. All epairs or epair endpoints as well as
the bridges are UP! Double checked this.

Jails on bridge0 (service net) have IPs in the range 10.10.0.0/24, the
b-portion of the routing jail's epair is member of bridge0, as described above,
and the a-portion of the epair has IP 10.10.0.1. Default route on each jeail
on bridge0 is set to 10.10.0.1 accordingly.

Consider a similar setup on the other jails on the friendly and hostile
network, except the fact that their bridges do have a physical NIC to which
they may have access to a real network.

The setup might not be ideal and/or applicable for the purpose of separartion
of networks virtually, but that shouldn't be the subject here. More important
is that I assume that I haven't understood some essentials, because the setup
doens't work as expected. Furthermore, it behaves on FreeBSD 11.1-RELENG-p6
sometimes completely unpredictable - but in that special case, I think I ran
IPFW on the host as "WORKSTATION" and dynamic rules may play an important role
here. But focussing on the CURRENT box, the host's IPFW is set to OPEN.

With jexec -l hostA I gain access to host A on the "service" bridge0 and I
want to ping its neighbour, hostB, on the same bridge and in the same net. It
doesn't work! From the routing jail, I CAN NOT ping any host on bridge0. The
routing jail has these network settings:

[... routing jail ...]
 lo0: flags=8049 metric 0 mtu 16384
options=63
inet 127.0.0.1 netmask 0xff00 
groups: lo
[epair to bridge0 - service net] 
epair4000a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:07:0a
inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair
[epair to bridge1, friendly net] 
epair4001a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:09:0a
inet 192.168.11.1 netmask 0xff00 broadcast 192.168.11.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair
[epair to bridge2, hostile net] 
epair4002a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:0b:0a
inet 10.10.10.1 netmask 0xfc00 broadcast 10.10.10.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair 

routing:
netstat -Warn
Routing tables

Internet:
DestinationGatewayFlags   UseMtu  Netif Expire

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

2018-02-04 Thread O. Hartmann
Am Sat, 3 Feb 2018 11:17:06 +0100
"O. Hartmann" <o.hartm...@walstatt.org> schrieb:

> Am Sat, 3 Feb 2018 11:10:53 +0300
> Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> 
> > Hello, Oliver!
> > 
> > On Fri, Feb 02, 2018, O. Hartmann wrote:  
> > > On Thu, 1 Feb 2018 12:10:30 +0300
> > > Vladimir Zakharov <zakharov...@gmail.com> wrote:
> > > 
> > > > Hello!
> > > > 
> > > > For some time (about a week) building and installing kernel fails with
> > > > the error "Variable OBJTOP is recursive." when going to build/install
> > > > module from ports.
> > > > 
> > > > Last successful build was at r328426. Next build at r328527 failed and
> > > > still broken at r328649.
> > > > 
> > > > Without PORTS_MODULES building and installing kernel succeeds. Another
> > > > workaround: ignore error and build/install module directly from ports.
> > > > 
> > > 
> > > I have had the very same issue!
> > > 
> > > You need to perform a "installworld" first (just comment out the 
> > > PORTS_MODULES=
> > > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel 
> > > (maybe not
> > > a full buildworld, but I do not know the state of your source tree) and 
> > > perform
> > > a regular installation of the world.  It could be something easier by 
> > > direkctly
> > > install-only the mk-portions, but recently, some changes to world (LLVM) 
> > > made
> > > it worth anyway to buildworld.
> > > 
> > > As recommended by others earlier on this list according to this subject, 
> > > this
> > > procedure makes the problem go away.
> > 
> > Thanks for your answer. Unfortunately, this didn't help.
> >   
> 
> You are correct! I made a mistake and had the portions still commented out. 
> I'm very
> sorry.
> 
> This remains a bug!
> 

This problem has been introduced with

svn commit: r328489 - head/sys/conf

The the appropriate list for reference.

oh
-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpFzlyQrHsoq.pgp
Description: OpenPGP digital signature


Re: CURRENT, CLANG 6: apache24, uid 80: exited on signal 11

2018-02-04 Thread O. Hartmann
Am Sat, 3 Feb 2018 14:04:17 +0100
Dimitry Andric <d...@freebsd.org> schrieb:

> On 3 Feb 2018, at 11:43, O. Hartmann <ohartm...@walstatt.org> wrote:
> > 
> > Am Tue, 30 Jan 2018 00:09:07 +0100
> > Dimitry Andric <d...@freebsd.org> schrieb:  
> >> On 30 Jan 2018, at 00:01, Dimitry Andric <d...@freebsd.org> wrote:  
> >>> On 29 Jan 2018, at 19:39, O. Hartmann <ohartm...@walstatt.org> wrote:  
> >>>> 
> >>>> Last weekend I updated a CURRENT server to recent CURRENT, > r328400 and 
> >>>> performed
> >>>> updates of the ports tree. Since Sunday, I receive segmenatation faults 
> >>>> (SIG 11)
> >>>> when accessing the server, especially with setup of nextcloud, refdb, 
> >>>> phpldapadmin
> >>>> and any other access with LDAP backend (all https).  
> ...
> > Starting program: /usr/local/sbin/httpd -X
> > [Sat Feb 03 11:41:27.704031 2018] [core:warn] [pid 59320:tid 3437628] 
> > (2)No such
> > file or directory: AH00075: Failed to enable the 'httpready' Accept Filter 
> > [Sat Feb 03
> > 11:41:27.704359 2018] [core:warn] [pid 59320:tid 3437628] (2)No such 
> > file or
> > directory: AH00075: Failed to enable the 'dataready' Accept Filter [New LWP 
> > 101096 of
> > process 59320] [New LWP 101105 of process 59320] [New LWP 101109 of process 
> > 59320]
> > [New LWP 101103 of process 59320]
> > [New LWP 101102 of process 59320]
> > [New LWP 101110 of process 59320]
> > [New LWP 101107 of process 59320]
> > [New LWP 101098 of process 59320]
> > [New LWP 101099 of process 59320]
> > [New LWP 101108 of process 59320]
> > [New LWP 101112 of process 59320]
> > [New LWP 101101 of process 59320]
> > [New LWP 101104 of process 59320]
> > [New LWP 101097 of process 59320]
> > [New LWP 101106 of process 59320]
> > [New LWP 10 of process 59320]
> > [New LWP 101100 of process 59320]
> > [LWP 101096 of process 59320 exited]
> > 
> > Thread 11 received signal SIGSEGV, Segmentation fault.
> > [Switching to LWP 101108 of process 59320]
> > 0x000802300382 in ?? () from /usr/local/lib/php/20131226-zts/opcache.so 
> >  
> 
> Run the "backtrace" command there, please.  If it doesn't give any
> function names, try setting WITH_DEBUG=1 in the environment, then
> rebuilding the mod_php56 port (and optionally also the php56 and
> apache24 ports themselves), to add debug info.
> 
> -Dimitry
> 
www/mod_php56: env WITH_DEBUG=1 make reinstall (prior to that, I had to "pkg 
delete" the
port www/mod_php56 first). When having mod_php56 rebuilt with DEBUG on as 
recommended and
performing command sequence to enter gdb, run -X, the Apache 2.4 now crashes 
immediately
and not when the URL is called by the browser triggering the fault. This is 
what I get
then:

bt
#0  0x00080208b382 in ?? () from /usr/local/lib/php/20131226-zts/opcache.so
#1  0x000802088e1a in ?? () from /usr/local/lib/php/20131226-zts/opcache.so
#2  0x000802085f12 in ?? () from /usr/local/lib/php/20131226-zts/opcache.so
#3  0x000802085cf3 in zend_accel_script_optimize ()
from /usr/local/lib/php/20131226-zts/opcache.so #4  0x00080207a393 in ?? ()
from /usr/local/lib/php/20131226-zts/opcache.so #5  0x0008020799d6 in
persistent_compile_file () from /usr/local/lib/php/20131226-zts/opcache.so #6
0x00080195d33c in zend_execute_scripts () from 
/usr/local/libexec/apache24/libphp5.so
#7  0x0008018f47a3 in php_execute_script ()
from /usr/local/libexec/apache24/libphp5.so #8  0x0008019f1015 in ?? ()
from /usr/local/libexec/apache24/libphp5.so #9  0x002563d7 in 
ap_invoke_handler
() #10 0x0029005d in ap_process_async_request () #11 0x00000028ca2d 
in
ap_process_http_connection () #12 0x0026e3b7 in 
ap_run_process_connection ()
#13 0x00080152827f in ?? () from 
/usr/local/libexec/apache24/mod_mpm_event.so
#14 0x000801527e11 in ?? () from 
/usr/local/libexec/apache24/mod_mpm_event.so
#15 0x0008005d2476 in ?? () from /lib/libthr.so.3
#16 0x in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffde1ef000


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpPDWol2DJ2G.pgp
Description: OpenPGP digital signature


Re: CURRENT, CLANG 6: apache24, uid 80: exited on signal 11

2018-02-04 Thread O. Hartmann
Am Sun, 4 Feb 2018 12:28:54 +0100
"O. Hartmann" <ohartm...@walstatt.org> schrieb:

> Am Sat, 3 Feb 2018 14:04:17 +0100
> Dimitry Andric <d...@freebsd.org> schrieb:
> 
> > On 3 Feb 2018, at 11:43, O. Hartmann <ohartm...@walstatt.org> wrote:  
> > > 
> > > Am Tue, 30 Jan 2018 00:09:07 +0100
> > > Dimitry Andric <d...@freebsd.org> schrieb:
> > >> On 30 Jan 2018, at 00:01, Dimitry Andric <d...@freebsd.org> wrote:
> > >>> On 29 Jan 2018, at 19:39, O. Hartmann <ohartm...@walstatt.org> wrote:   
> > >>>  
> > >>>> 
> > >>>> Last weekend I updated a CURRENT server to recent CURRENT, > r328400 
> > >>>> and
> > >>>> performed updates of the ports tree. Since Sunday, I receive 
> > >>>> segmenatation
> > >>>> faults (SIG 11) when accessing the server, especially with setup of 
> > >>>> nextcloud,
> > >>>> refdb, phpldapadmin and any other access with LDAP backend (all 
> > >>>> https).
> > ...  
> > > Starting program: /usr/local/sbin/httpd -X
> > > [Sat Feb 03 11:41:27.704031 2018] [core:warn] [pid 59320:tid 3437628] 
> > > (2)No such
> > > file or directory: AH00075: Failed to enable the 'httpready' Accept 
> > > Filter [Sat Feb
> > > 03 11:41:27.704359 2018] [core:warn] [pid 59320:tid 3437628] (2)No 
> > > such file or
> > > directory: AH00075: Failed to enable the 'dataready' Accept Filter [New 
> > > LWP 101096
> > > of process 59320] [New LWP 101105 of process 59320] [New LWP 101109 of 
> > > process
> > > 59320] [New LWP 101103 of process 59320]
> > > [New LWP 101102 of process 59320]
> > > [New LWP 101110 of process 59320]
> > > [New LWP 101107 of process 59320]
> > > [New LWP 101098 of process 59320]
> > > [New LWP 101099 of process 59320]
> > > [New LWP 101108 of process 59320]
> > > [New LWP 101112 of process 59320]
> > > [New LWP 101101 of process 59320]
> > > [New LWP 101104 of process 59320]
> > > [New LWP 101097 of process 59320]
> > > [New LWP 101106 of process 59320]
> > > [New LWP 10 of process 59320]
> > > [New LWP 101100 of process 59320]
> > > [LWP 101096 of process 59320 exited]
> > > 
> > > Thread 11 received signal SIGSEGV, Segmentation fault.
> > > [Switching to LWP 101108 of process 59320]
> > > 0x000802300382 in ?? () from 
> > > /usr/local/lib/php/20131226-zts/opcache.so
> > 
> > Run the "backtrace" command there, please.  If it doesn't give any
> > function names, try setting WITH_DEBUG=1 in the environment, then
> > rebuilding the mod_php56 port (and optionally also the php56 and
> > apache24 ports themselves), to add debug info.
> > 
> > -Dimitry
> >   
> www/mod_php56: env WITH_DEBUG=1 make reinstall (prior to that, I had to "pkg 
> delete" the
> port www/mod_php56 first). When having mod_php56 rebuilt with DEBUG on as 
> recommended
> and performing command sequence to enter gdb, run -X, the Apache 2.4 now 
> crashes
> immediately and not when the URL is called by the browser triggering the 
> fault. This is
> what I get then:
> 
> bt
> #0  0x00080208b382 in ?? () from 
> /usr/local/lib/php/20131226-zts/opcache.so
> #1  0x000802088e1a in ?? () from 
> /usr/local/lib/php/20131226-zts/opcache.so
> #2  0x000802085f12 in ?? () from 
> /usr/local/lib/php/20131226-zts/opcache.so
> #3  0x000802085cf3 in zend_accel_script_optimize ()
> from /usr/local/lib/php/20131226-zts/opcache.so #4  0x00080207a393 in ?? 
> ()
> from /usr/local/lib/php/20131226-zts/opcache.so #5  0x0008020799d6 in
> persistent_compile_file () from /usr/local/lib/php/20131226-zts/opcache.so #6
> 0x00080195d33c in zend_execute_scripts ()
> from /usr/local/libexec/apache24/libphp5.so #7  0x0008018f47a3 in
> php_execute_script () from /usr/local/libexec/apache24/libphp5.so #8
> 0x0008019f1015 in ?? () from /usr/local/libexec/apache24/libphp5.so #9
> 0x002563d7 in ap_invoke_handler () #10 0x00000029005d in
> ap_process_async_request () #11 0x0028ca2d in 
> ap_process_http_connection () #12
> 0x0026e3b7 in ap_run_process_connection () #13 0x00080152827f in 
> ?? ()
> from /usr/local/libexec/apache24/mod_mpm_event.so #14 0x000801527e11 in 
> ?? ()
> from /usr/local/libexec/apache24/mod_mpm_event.so #15 0x0008005d2476 in 
> ?? ()
> from /lib/libthr.so.3 #16 0x in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffde1ef000
> 
> 

I forgot to mention, that I already have rebuilt www/apache24 via portmaster 
-df and I
also have rebuild all php ports/modules installed including php56 itself (but 
without
debugging, it takes a while on that box).


-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpGqL2iZgMnS.pgp
Description: OpenPGP digital signature


Re: pkg OSVERSION problem

2018-02-04 Thread O. Hartmann
Am Sat, 27 Jan 2018 10:23:28 +0100
"Ronald Klop" <ronald-li...@klop.ws> schrieb:

> On Sat, 27 Jan 2018 08:36:58 +0100, O. Hartmann <ohartm...@walstatt.org>  
> wrote:
> 
> > Am Thu, 25 Jan 2018 21:38:27 +0100
> > Jan Kokemüller <jan.kokemuel...@gmail.com> schrieb:
> >  
> >> On 25.01.2018 21:19, Ronald Klop wrote:  
> >> > I know there should be multiple updates of packages.
> >> > Even with -o OSVERSION it does not give any new pkgs anymore.
> >> > What will help this?  
> >>
> >> I've just had the same issue and solved it by forcefully updating the
> >> package database:
> >>
> >> # pkg -o OSVERSION=1200056 update -f
> >> # pkg -o OSVERSION=1200056 upgrade
> >>
> >>
> >> -Jan
> >> ___
> >> freebsd-current@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to  
> >> "freebsd-current-unsubscr...@freebsd.org"  
> >
> > Thanks,
> >
> > I'll give it a try.
> >
> > regards,
> >
> > Oliver
> >  
> 
> Thanks also. It kicked pkg upgrade into upgrading again, but in the end I  
> missed libdl.so (clang 6?) which was fixed by updating my system to  
> 1200056 anyway. Otherwise Firefox wouldn't start.
> So although the OSVERSION check is annoying it does warn for actual  
> problems.
> 
> Regards,
> Ronald.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I tried and it worked as expected!

Thanks a lot.

Oliver

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpsgu77Zhmpo.pgp
Description: OpenPGP digital signature


Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

2018-02-03 Thread O. Hartmann
Am Sat, 3 Feb 2018 11:10:53 +0300
Vladimir Zakharov <zakharov...@gmail.com> schrieb:

> Hello, Oliver!
> 
> On Fri, Feb 02, 2018, O. Hartmann wrote:
> > On Thu, 1 Feb 2018 12:10:30 +0300
> > Vladimir Zakharov <zakharov...@gmail.com> wrote:
> >   
> > > Hello!
> > > 
> > > For some time (about a week) building and installing kernel fails with
> > > the error "Variable OBJTOP is recursive." when going to build/install
> > > module from ports.
> > > 
> > > Last successful build was at r328426. Next build at r328527 failed and
> > > still broken at r328649.
> > > 
> > > Without PORTS_MODULES building and installing kernel succeeds. Another
> > > workaround: ignore error and build/install module directly from ports.
> > >   
> > 
> > I have had the very same issue!
> > 
> > You need to perform a "installworld" first (just comment out the 
> > PORTS_MODULES=
> > parts of /etc/src.conf or /etc/make.conf, buildworld and buildkernel (maybe 
> > not
> > a full buildworld, but I do not know the state of your source tree) and 
> > perform
> > a regular installation of the world.  It could be something easier by 
> > direkctly
> > install-only the mk-portions, but recently, some changes to world (LLVM) 
> > made
> > it worth anyway to buildworld.
> > 
> > As recommended by others earlier on this list according to this subject, 
> > this
> > procedure makes the problem go away.  
> 
> Thanks for your answer. Unfortunately, this didn't help.
> 

You are correct! I made a mistake and had the portions still commented out. I'm 
very
sorry.

This remains a bug!

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpUOEYTcpLE6.pgp
Description: OpenPGP digital signature


  1   2   3   4   5   6   7   8   9   10   >