[RESOLVED] Re: FreeBSD 13.0-CURRENT r346362 + webcamd -- no /dev/video*

[Boris Samorodov]

Hi All,

The problem is resolved with the help of Tom Rushworth (via private
emails) by starting hald. I had not run it and this dependency is noted
at WEBCAMD(8) neither.

Hope this info may be helpful.


21.04.2019 18:48, Boris Samorodov пишет:
> Hi All,
> 
> I use a fresh FreeBSD-current system and webcamd but get no /dev/video*
> device:
> -
> %uname -a
> FreeBSD latt.bsnet 13.0-CURRENT FreeBSD 13.0-CURRENT r346362 PKG64X  amd64
> 
> % ls -l /dev/cuse
> crw-rw  1 root  operator  0x77 21 апр.  18:04 /dev/cuse
> 
> % pkg info -x webcamd
> webcamd-4.20.0.1_2
> 
> % ps auwx | grep webcamd
> root833   0,0  0,0   20560   8108  -  S /usr/local/sbin/webcamd -i 0 -d ugen0.5 -H -B -U webcamd -G webcamd
> 
> % webcamd
> [...]
> webcamd [-d ugen0.5] -N
> GenesysLogic-Technology-Co---Ltd--USB2-0-UVC-PC-Camera -S unknown -M 0
> 
> % ls -l /dev/video*
> ls: /dev/video: No such file or directory
> 
> % pwcview
> Failed to access webcam: No such file or directory
> ***
> Make sure you have connected your webcam to the root hub
> or to a USB 1.1 hub, also check your dmesg for any errors.
> ***
> 
> 
> Any help is appreciated. Thank you.
> 

___
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: FreeBSD 13.0-CURRENT r346362 + webcamd -- no /dev/video*

[Boris Samorodov]

Hi Damjan and aLL!

21.04.2019 19:54, Damjan Jovanovic пишет:
> On Sun, Apr 21, 2019 at 5:51 PM Boris Samorodov  wrote:
> 
>> Hi All,
>>
>> I use a fresh FreeBSD-current system and webcamd but get no /dev/video*
>> device:
>> -
>> %uname -a
>> FreeBSD latt.bsnet 13.0-CURRENT FreeBSD 13.0-CURRENT r346362 PKG64X  amd64
>>
>> % ls -l /dev/cuse
>> crw-rw  1 root  operator  0x77 21 апр.  18:04 /dev/cuse
>>
>> % pkg info -x webcamd
>> webcamd-4.20.0.1_2
>>
>> % ps auwx | grep webcamd
>> root833   0,0  0,0   20560   8108  -  S> /usr/local/sbin/webcamd -i 0 -d ugen0.5 -H -B -U webcamd -G webcamd
>>
>> % webcamd
>> [...]
>> webcamd [-d ugen0.5] -N
>> GenesysLogic-Technology-Co---Ltd--USB2-0-UVC-PC-Camera -S unknown -M 0
>>
>> % ls -l /dev/video*
>> ls: /dev/video: No such file or directory
>>
>> % pwcview
>> Failed to access webcam: No such file or directory
>> ***
>> Make sure you have connected your webcam to the root hub
>> or to a USB 1.1 hub, also check your dmesg for any errors.
>> ***
>> 
>>
>> Any help is appreciated. Thank you.
>>
>> --
>>
>>
> I was doing some webcamd development just a few days ago and might be able
> to help.
> 
> Does your camera work in Linux? If so, on what version?


Interesting question! I've just tried lubuntu 18.04.2 and it works fine.

-- 
WBR, bsam
___
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 13.0-CURRENT r346362 + webcamd -- no /dev/video*

[Boris Samorodov]

Hi All,

I use a fresh FreeBSD-current system and webcamd but get no /dev/video*
device:
-
%uname -a
FreeBSD latt.bsnet 13.0-CURRENT FreeBSD 13.0-CURRENT r346362 PKG64X  amd64

% ls -l /dev/cuse
crw-rw  1 root  operator  0x77 21 апр.  18:04 /dev/cuse

% pkg info -x webcamd
webcamd-4.20.0.1_2

% ps auwx | grep webcamd
root833   0,0  0,0   20560   8108  -  Shttps://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: base packages and 12 -> 13 upgrade

[Boris Samorodov]

On 03.11.2018 18:05, Mikaël Urankar wrote:

Le sam. 3 nov. 2018 à 15:45, Boris Samorodov  a écrit :


Hi All,

A have a base package server and upgraded some of my home servers
to use base packages. Now when the package builder builds packages
for 13-current, what is the procedure to upgrade base packages from
12 to 13?

Whenever I try to install/upgrade packages I get:
---
pkg-static: wrong architecture: FreeBSD:13:amd64 instead of FreeBSD:12:amd64
pkg-static: repository FreeBSD-base contains packages with wrong ABI:
FreeBSD:13:amd64


I think you need to do something like that:
env ABI=FreeBSD:13:amd64 pkg update
env ABI=FreeBSD:13:amd64 pkg upgrade


Yep! That was it. Thank you.

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

base packages and 12 -> 13 upgrade

[Boris Samorodov]

Hi All,

A have a base package server and upgraded some of my home servers
to use base packages. Now when the package builder builds packages
for 13-current, what is the procedure to upgrade base packages from
12 to 13?

Whenever I try to install/upgrade packages I get:
---
pkg-static: wrong architecture: FreeBSD:13:amd64 instead of FreeBSD:12:amd64
pkg-static: repository FreeBSD-base contains packages with wrong ABI: 
FreeBSD:13:amd64

---

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: make packages fails recent -current

[Boris Samorodov]

On 11.09.2018 16:20, Andreas Nilsson wrote:

On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar 
wrote:


2018-09-10 17:45 GMT+02:00 Andreas Nilsson :


Hello,

I have for about a week been trying to get new (base)packages built. make
buildworld/buildkernel works as expected, however make packages has been
failing:

===> Creating FreeBSD-runtime-12.0.s20180910124534
pkg: duplicate directory listing: /boot, ignoring
pkg: duplicate directory listing: /etc, ignoring
...
pkg: duplicate directory listing: /etc/syslog.d, ignoring
pkg: duplicate directory listing: /root, ignoring
pkg: duplicate directory listing: /root, ignoring
pkg: duplicate directory listing: /root, ignoring
pkg: Plist error, @config /root/.cshrc: not a regular file
pkg: Plist error, @config /root/.profile: not a regular file
pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring
pkg: duplicate directory listing: /usr/lib, ignoring
pkg: duplicate directory listing: /usr/lib/dtrace, ignoring
pkg: duplicate directory listing: /usr/lib/dtrace, ignoring
pkg: duplicate directory listing: /usr/lib32, ignoring
...

Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode
for
building. I'm currently building from scratch just to rule out metamode.



See
https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html



Thanks, that would explain it. Although even after installing
pkg-devel-1.10.99.8 it still fails. Guess I'll have to wait for it to
trickle into the packages.


The rev. 479255 was an update to version 1.10.99.9.

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serv
___
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

[Boris Samorodov]

20.05.2018 16:03, Johannes Lundberg пишет:
> On Sun, May 20, 2018 at 1:36 PM, Boris Samorodov <b...@passap.ru> wrote:
> 
>> 18.05.2018 20:58, Niclas Zeising пишет:
>>
>>> Is there anyone still using the drm2 driver on 12-CURRENT?  If so, what
>>> is preventing you from switching to the port?
>>
>> I use base packages and can not use port:
>> https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html
> 
> If we remove drm.ko from base (which is suggested)  you would be able to
> install the drm-stable/next-kmod packages without conflict.

Great, thanks.

-- 
WBR, bsam
___
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

[Boris Samorodov]

18.05.2018 20:58, Niclas Zeising пишет:

> Is there anyone still using the drm2 driver on 12-CURRENT?  If so, what
> is preventing you from switching to the port?

I use base packages and can not use port:
https://lists.freebsd.org/pipermail/freebsd-current/2018-May/069329.html

-- 
WBR, bsam
___
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: pkg, drm-next-kmod and base packages

[Boris Samorodov]

10.05.2018 19:05, Andreas Nilsson пишет:
> On Thu, May 10, 2018 at 5:30 PM, Theron <theron.tar...@gmail.com> wrote:
> 
>> On 05/10/18 03:45, Johannes Dieterich wrote:
>>
>>> Hi
>>>
>>> On Wednesday, May 9, 2018, Boris Samorodov wrote:
>>>
>>>> Hi All,
>>>>
>>>> I use self-built base packages. How can I test/use drm-next-kmod?
>>>> Packages for kernel and drm-nex-kmod are in conflict:
>>>> -
>>>> Checking integrity... done (1 conflicting)
>>>>- drm-next-kmod-4.11.g20180224 [FreeBSD] conflicts with
>>>> FreeBSD-kernel-pkg64x-12.0.s20180509041454 [installed] on
>>>> /boot/modules/drm.ko
>>>> Checking integrity... done (0 conflicting)
>>>> -
>>>>
>>> Since I don't have a system with pkgbase configured, is there a way to
>>> figure out what files conflict?
>>>
>> The pkg output indicates that /boot/modules/drm.ko is the conflicting file.
>>
>>> It surprises me that there are any since we do not override anything
>>> normally (some kernel modules are indeed overlapping but they get installed
>>> in different directories).
>>>
>> On a non-pkgbase -CURRENT system, drm.ko and drm2.ko from base are in
>> /boot/kernel/, while drm.ko from drm-stable-kmod is in /boot/modules/.  Any
>> kernel modules from base being placed outside of /boot/kernel is not what I
>> would expect for a non-pkgbase system; is there a reason pkgbase should not
>> follow this rule?
>
> I recently converted my system to pkgbase, but I have no such package as
> FreeBSD-kernel-pkg64x. How  and from where did you get the sources?

That is my custom kernel. I build that one and GENERIC plus their
counterparts with debug symbols per each build.

> I seem to remember that the git repo FreeBSDDesktop
> <https://github.com/FreeBSDDesktop>/freebsd-base-graphics
> <https://github.com/FreeBSDDesktop/freebsd-base-graphics> shipped the
> module in /boot/modules. If you are using that git repo, you do not need
> the port.

Actually my point is that pkg-base packages and ports packages are in
conflict and cannot coexist currently.

> Best regards
> Andreas

-- 
WBR, bsam
___
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, drm-next-kmod and base packages

[Boris Samorodov]

Hi All,

I use self-built base packages. How can I test/use drm-next-kmod?
Packages for kernel and drm-nex-kmod are in conflict:
-
╰→ sudo pkg install drm-next-kmod-4.11.g20180224

Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating passap repository catalogue...
passap repository is up to date.
All repositories are up to date.
Checking integrity... done (1 conflicting)
  - drm-next-kmod-4.11.g20180224 [FreeBSD] conflicts with
FreeBSD-kernel-pkg64x-12.0.s20180509041454 [installed] on
/boot/modules/drm.ko
Checking integrity... done (0 conflicting)
The following 3 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
FreeBSD-kernel-pkg64x-12.0.s20180509041454

New packages to be INSTALLED:
drm-next-kmod: 4.11.g20180224 [FreeBSD]
gpu-firmware-kmod: g20180206_1 [FreeBSD]

Number of packages to be removed: 1
Number of packages to be installed: 2

The operation will free 91 MiB.

Proceed with this action? [y/N]:
-

-- 
WBR, bsam
___
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: IGNORE_OSVERSION=yes -- can't install pkg

[Boris Samorodov]

05.05.2018 18:26, Chris H пишет:
> On Fri, 04 May 2018 22:57:52 -0700  said
> 
>> I just setup a jail from a 12-CURRENT I built awhile ago. It has no ports
>> tree. So I'm attempting
>> to install svnlite. issuing pkg search svnlite returns
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from
>> pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest,
>> please wait...
>> Verifying signature with trusted certificate
>> pkg.freebsd.org.2013102301...
>> done
>> [12current.localhost] Installing pkg-1.10.5...
>> Newer FreeBSD version for package pkg:
>> To ignore this error set IGNORE_OSVERSION=yes
>> - package: 1200062
>> - running kernel: 1200054
>> Allow missmatch now?[Y/n]:
>>
>> Umm, what? Should I ignore this error? If so, why is there an error at
>> all?
>> I answered no. Guess I won't be able to use pkg(8) on this jail(8). :-(
>>
>> --Chris
> OK the only reference[1] I can find regarding this, indicates that
> answering "Y"
> to Allow missmatch now? resulted in an ABI mismatch that caused pkg(8)
> to be
> unusable.
> This is on an older version of 12, so I don't have anything that might have
> appeared in UPDATING. I really need this jail to resolve accumulating
> pr(1)'s
> on ports(7) I maintain.

FreeBSD project has packages for the latest HEAD. But you may build your
own packages via poudriere. First, build the needed base system, then
build needed packages.

-- 
WBR, bsam
___
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: CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

[Boris Samorodov]

Hi Oliver, All!

17.01.2018 14:01, O. Hartmann пишет:
> On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
> 2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
> devel/openjdk8's error as follows:
> 
> [...]
> In file included
> from 
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
>  
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
> error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
> %1,(%3)"

There is an open PR on the matter:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225054

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Boris Samorodov]

10.01.2018 21:53, Baptiste Daroussin пишет:
> On Wed, Jan 10, 2018 at 09:29:04PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> I use self built base packages. Seems that I have a problem with pkg.
>> Today I've got this:
>> ===
>> % sudo pkg update -f
>> Updating FreeBSD-base repository catalogue...
>> Fetching meta.txz: 100%268 B   0.3kB/s00:01
>> Fetching packagesite.txz: 100%   29 KiB  29.4kB/s00:01
>> Processing entries:   0%
>> pkg: Newer FreeBSD version for package FreeBSD-libulog:
>> - package: 1200055
>> - running kernel: 1200054
>> pkg: repository FreeBSD-base contains packages for wrong OS version:
>> FreeBSD:12:amd64
>> Processing entries: 100%
>> Unable to update repository FreeBSD-base
>> [...]
>>
>> % uname -aKU
>> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan
>>  9 14:32:13 MSK 2018
>> bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64
>> 1200054 1200054
>>
>> % pkg -v
>> 1.10.4
>>
> hum
> 
> pkg now has a mechanism to protect from installing too new package (aka 
> packages
> built on a more recent system than the system you are running on.
> 
> While this is great for ports this is a bit painful for upgrading base 
> packages
> when building on current
> 
> One has to specify pkg -o OSVERSION=1200055 to allow packages built on 1200055
> to install on 1200054.

Baptiste, thank you for the quick response!

The problem has been solved by:
% sudo pkg -o OSVERSION=1200055 update -r FreeBSD-base

> I need to figure out a mechanism to make this simpler to handle to upgrade of
> base system while keeping this safety belt for users.

Well, as for me, the above mentioned workaround is just fine.

> Any idea is welcome
> 
> Best regards,
> Bapt
> 

-- 
WBR, bsam



signature.asc
Description: OpenPGP digital signature

[self base packages] pkg: packages for wrong OS version: FreeBSD:12:amd64

[Boris Samorodov]

Hi All,

I use self built base packages. Seems that I have a problem with pkg.
Today I've got this:
===
% sudo pkg update -f
Updating FreeBSD-base repository catalogue...
Fetching meta.txz: 100%268 B   0.3kB/s00:01
Fetching packagesite.txz: 100%   29 KiB  29.4kB/s00:01
Processing entries:   0%
pkg: Newer FreeBSD version for package FreeBSD-libulog:
- package: 1200055
- running kernel: 1200054
pkg: repository FreeBSD-base contains packages for wrong OS version:
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD-base
[...]

% uname -aKU
FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r327719: Tue Jan
 9 14:32:13 MSK 2018
bsam@builder.bsnet:/usr/obj/usr/src/amd64.amd64/sys/PKG64X  amd64
1200054 1200054

% pkg -v
1.10.4
===

-- 
WBR, bsam
___
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"

base packages and subdirs with no regular files

[Boris Samorodov]

Hi All!

I use base package for more then a year now. It works mostly fine.
However today I noticed that (some?) blank subdirectories are not
removed while updating:
---
% LANG=C ls -l /usr/lib/clang
drwxr-xr-x  4 root  wheel  4 Dec 22  2016 3.9.1
drwxr-xr-x  4 root  wheel  4 Mar  3  2017 4.0.0
drwxr-xr-x  4 root  wheel  4 Aug 28 14:50 5.0.0
drwxr-xr-x  4 root  wheel  4 Dec  8 13:09 5.0.1
---

All previous (to 5.0.1) clang version dirs contain only directories,
no regular files:
---
% LANG=C ls -l /usr/lib/clang/5.0.0
total 25
drwxr-xr-x  3 root  wheel  3 Dec  8 13:09 include
drwxr-xr-x  3 root  wheel  3 Aug 28 14:50 lib

% LANG=C ls -l /usr/lib/clang/5.0.0/include
total 1
drwxr-xr-x  2 root  wheel  2 Dec  8 13:09 sanitizer

% LANG=C ls -l /usr/lib/clang/5.0.0/include/sanitizer
total 0
---

I use my personal base package builder and just "pkg upgrade"
for, well, upgrades.

-- 
WBR, bsam
___
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"

[base packages] [r325303 -> r325351] install: hcsecd.conf: Permission denied

[Boris Samorodov]

Hi All,

I create packages (as an ordinary user with command "make packages")
for HEAD once a day. Today I've got a regression:
--- rev. 325351 regression ---
install -U -M /usr/obj/usr/src/amd64.amd64/worldstage//METALOG -D
/usr/obj/usr/src/amd64.amd64/worldstage -T package=runtime -o root  -g
wheel -m 600  hcsecd.conf
/usr/obj/usr/src/amd64.amd64/worldstage/etc/bluetooth/hcsecd.conf
install: hcsecd.conf: Permission denied
*** Error code 71

Stop.
make[9]: stopped in /usr/src/etc/bluetooth
---

Files in question are:
---
% ls -ld /usr/obj/usr/src/amd64.amd64/worldstage/etc/bluetooth
drwxr-xr-x  2 bsam  wheel  512  3 нояб. 06:35
/usr/obj/usr/src/amd64.amd64/worldstage/etc/bluetooth

% ls -l /usr/obj/usr/src/amd64.amd64/worldstage/etc/bluetooth
total 12
-rw---  1 bsam  wheel  1343  3 нояб. 06:35 hcsecd.conf
-rw-r--r--  1 bsam  wheel   305  3 нояб. 06:35 hosts
-r--r--r--  1 bsam  wheel  1110  3 нояб. 06:35 protocols
---

Yesterday rev. 325303 worked fine.

-- 
WBR, bsam
___
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: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

[Boris Samorodov]

26.10.2017 20:51, Benjamin Kaduk пишет:
> On Thu, Oct 26, 2017 at 08:47:06PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Since a few days I can't update repository (info and cleanup works,
>> but not update and commit) both at local and remote systems.
>>
>> Is it my personal problem/misconfig?
>>
>> ---
>> % svnlite up
>> Updating '.':
>> svn: E170013: Unable to connect to a repository at URL
>> 'svn+ssh://svn.freebsd.org/ports/head'
> 
> For ssh access, you probably are better off with repo.freebsd.org, per
> the committer's guide.

Great, that worked. Thank you, Ben.

-- 
WBR, bsam
___
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: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

[Boris Samorodov]

26.10.2017 20:49, Kurt Jaeger пишет:
> Hi!
> 
>> Since a few days I can't update repository (info and cleanup works,
>> but not update and commit) both at local and remote systems.
>>
>> Is it my personal problem/misconfig?
> 
> At least it works here (.de).
> 
> Maybe this *is* a SSH issue ?
> 
>> svn: E210002: To better debug SSH connection problems, remove the -q
>> option from 'ssh' in the [tunnels] section of your Subversion
>> configuration file.
>> svn: E210002: Network connection closed unexpectedly
> 
> Can you try to ssh to svn.freebsd.org ? What does it show ?
> 

% ssh svn.freebsd.org
ssh_exchange_identification: read: Connection reset by peer

BTW, ssh to freefall.freebsd.org works.

-- 
WBR, bsam
___
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"

svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn.freebsd.org/ports/head'

[Boris Samorodov]

Hi All,

Since a few days I can't update repository (info and cleanup works,
but not update and commit) both at local and remote systems.

Is it my personal problem/misconfig?

---
% svnlite up
Updating '.':
svn: E170013: Unable to connect to a repository at URL
'svn+ssh://svn.freebsd.org/ports/head'
svn: E210002: To better debug SSH connection problems, remove the -q
option from 'ssh' in the [tunnels] section of your Subversion
configuration file.
svn: E210002: Network connection closed unexpectedly

% uname -a
FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #65 r325004M: Thu
Oct 26 05:11:56 MSK 2017
bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64

% svnlite info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn+ssh://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn+ssh://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 451243
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 451242
Last Changed Date: 2017-10-04 22:15:41 +0300 (ср, 04 окт. 2017)
---

Thank you.
-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

25.10.2017 01:14, Ian Lepore пишет:

> Can you show the /var/db/ntpd.drift file contents of the host and
> guest?  Ideally, now that it's stable, the two values should be very
> close.  If they're not, maybe this isn't the right fix.

Sorry, no. :-( I experimented with the host and bhyve vm now has
unstable ntp values (stepping). I'll try to revert all my changes
and report back in a couple of days.

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

Hi Ian, All!

22.10.2017 01:15, Ian Lepore пишет:
> On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
>> Ian Lepore writes:
>>>
>>> Beyond that, I'm not sure what else to try.  It might be necessary to
>>> get some bhyve developers involved (I know almost nothing about it).
>> NTPD behaves more normally on uniprocessor VMs.
>>
>> A FreeBSD bhyve-guest running on a freebsd host will select a
>> different timecounter depending on whether it is a multiprocessor or a
>> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
>> timecounter in a uniprocessor.  NTP functions there as expected.
>>
>> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
>> dummy(-100)
>> kern.timecounter.hardware: TSC-low
>>
>> The very same VM, when given two total CPUs, selected HPET (if I
>> recall) and the timekeeping with NTPD was unreliable, with many
>> step-resets to the clock.
>>
> 
> Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
> looks right.  I wonder if this is just a simple roundoff error in
> converting between 10.0MHz and SBT units?  If so, that could be wished
> away easily by using a power-of-2 frequency for the virtual HPET.  I
> wonder if the attached patch is all that's needed?

I suppose the answer is "yes", the patch helped. Here are two samples
(host for bhyve VM without your patch and after patching):
---
https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.1000.txt
https://poudriere.passap.ru/misc/ntpd.jot.log-HPET.frequency.16777216.txt
---

The command was:
% for t in `jot 1000`; do ntpq -pn; sleep 64; done

The patch made the system to stabilize the process.
Ian, thank you!

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

22.10.2017 19:02, Ian Lepore пишет:
> On Sun, 2017-10-22 at 11:31 +0300, Boris Samorodov wrote:
>> 22.10.2017 01:15, Ian Lepore пишет:
>>>
>>> On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
>>>>
>>>> Ian Lepore writes:
>>>>>
>>>>>
>>>>> Beyond that, I'm not sure what else to try.  It might be necessary to
>>>>> get some bhyve developers involved (I know almost nothing about it).
>>>> NTPD behaves more normally on uniprocessor VMs.
>>>>
>>>> A FreeBSD bhyve-guest running on a freebsd host will select a
>>>> different timecounter depending on whether it is a multiprocessor or a
>>>> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
>>>> timecounter in a uniprocessor.  NTP functions there as expected.
>>>>
>>>> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
>>>> dummy(-100)
>>>> kern.timecounter.hardware: TSC-low
>>>>
>>>> The very same VM, when given two total CPUs, selected HPET (if I
>>>> recall) and the timekeeping with NTPD was unreliable, with many
>>>> step-resets to the clock.
>>>>
>>> Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
>>> looks right.  I wonder if this is just a simple roundoff error in
>>> converting between 10.0MHz and SBT units?  If so, that could be wished
>>> away easily by using a power-of-2 frequency for the virtual HPET.  I
>>> wonder if the attached patch is all that's needed?
>> I've tried the patch (at bhyve guest) and nothing has changed. Should
>> the patched system be tested at bhyve guest or bhyve host?
>>
> 
> Oh, I'm sorry, I should have mentioned that's for the host side.

NP, that's OK.

However, the host is busy now, and I'll have an opportunity to test host
only tomorrow evening.

Ian, thank you for your help!

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

22.10.2017 18:22, Rodney W. Grimes пишет:
> [ Charset UTF-8 unsupported, converting... ]
>> 22.10.2017 01:15, Ian Lepore ?:
>>> On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
 Ian Lepore writes:
>
> Beyond that, I'm not sure what else to try. ?It might be necessary to
> get some bhyve developers involved (I know almost nothing about it).
 NTPD behaves more normally on uniprocessor VMs.

 A FreeBSD bhyve-guest running on a freebsd host will select a
 different timecounter depending on whether it is a multiprocessor or a
 uniprocessor.??My uniprocessor bhyve-vm selected TSC-low as the best
 timecounter in a uniprocessor.??NTP functions there as expected.

 kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
 dummy(-100)
 kern.timecounter.hardware: TSC-low

 The very same VM, when given two total CPUs, selected HPET (if I
 recall) and the timekeeping with NTPD was unreliable, with many
 step-resets to the clock.

>>>
>>> Hmm, I just had glance at the code in?sys/amd64/vmm/io/vhpet.c and it
>>> looks right. ?I wonder if this is just a simple roundoff error in
>>> converting between 10.0MHz and SBT units? ?If so, that could be wished
>>> away easily by using a power-of-2 frequency for the virtual HPET. ?I
>>> wonder if the attached patch is all that's needed?
>> I've tried the patch (at bhyve guest) and nothing has changed. Should
>> the patched system be tested at bhyve guest or bhyve host?
> 
> I believe the suggested patch would have to be made to the bhyve
> host

OK, I'd do it tomorrow and report back.

>.  Also on the host and guest what are the values of
>   sysctl kern.timecounter.tc.HPET
>   sysctl kern.timecounter.tc.i8254

Here they are:
---
bhyve-host% sysctl kern.timecounter.tc.HPET
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 14318180
kern.timecounter.tc.HPET.counter: 2138094157
kern.timecounter.tc.HPET.mask: 4294967295

bhyve-host% sysctl kern.timecounter.tc.i8254
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 54883
kern.timecounter.tc.i8254.mask: 65535
---
bhyve-guest% sysctl kern.timecounter.tc.HPET
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 1000
kern.timecounter.tc.HPET.counter: 969429421
kern.timecounter.tc.HPET.mask: 4294967295

bhyve-guest% sysctl kern.timecounter.tc.i8254
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182
kern.timecounter.tc.i8254.counter: 39893
kern.timecounter.tc.i8254.mask: 65535
---

> Getting good ntpd behavior in a VM guest of any kind is sometimes a
> non trivial thing to do.

As a side note, I have a CentOS-7 bhyve VM at the same host.
And it was enough to run chronyd with default config. Which stepped
twice and is stable (no messages) for several days, current log:
---
Oct 19 16:01:03 c.vpn systemd[1]: Starting NTP client/server...
Oct 19 16:01:03 c.vpn chronyd[27043]: chronyd version 3.1 starting
(+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND
+ASYNCDNS +IPV6 +DEBUG)
Oct 19 16:01:03 c.vpn chronyd[27043]: Frequency 0.000 +/- 100.000
ppm read from /var/lib/chrony/drift
Oct 19 16:01:03 c.vpn systemd[1]: Started NTP client/server.
Oct 19 16:01:07 c.vpn chronyd[27043]: Selected source XX.XX.XX.1
Oct 19 16:01:07 c.vpn chronyd[27043]: System clock wrong by -44.392782
seconds, adjustment started
Oct 19 16:00:23 c.vpn chronyd[27043]: System clock was stepped by
-44.392782 seconds
Oct 19 16:00:34 c.vpn chronyd[27043]: System clock was stepped by
0.01 seconds
---

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

22.10.2017 01:15, Ian Lepore пишет:
> On Sat, 2017-10-21 at 17:07 -0400, Michael Voorhis wrote:
>> Ian Lepore writes:
>>>
>>> Beyond that, I'm not sure what else to try.  It might be necessary to
>>> get some bhyve developers involved (I know almost nothing about it).
>> NTPD behaves more normally on uniprocessor VMs.
>>
>> A FreeBSD bhyve-guest running on a freebsd host will select a
>> different timecounter depending on whether it is a multiprocessor or a
>> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
>> timecounter in a uniprocessor.  NTP functions there as expected.
>>
>> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
>> dummy(-100)
>> kern.timecounter.hardware: TSC-low
>>
>> The very same VM, when given two total CPUs, selected HPET (if I
>> recall) and the timekeeping with NTPD was unreliable, with many
>> step-resets to the clock.
>>
> 
> Hmm, I just had glance at the code in sys/amd64/vmm/io/vhpet.c and it
> looks right.  I wonder if this is just a simple roundoff error in
> converting between 10.0MHz and SBT units?  If so, that could be wished
> away easily by using a power-of-2 frequency for the virtual HPET.  I
> wonder if the attached patch is all that's needed?
I've tried the patch (at bhyve guest) and nothing has changed. Should
the patched system be tested at bhyve guest or bhyve host?

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

22.10.2017 00:07, Michael Voorhis пишет:
> Ian Lepore writes:
>> Beyond that, I'm not sure what else to try.  It might be necessary to
>> get some bhyve developers involved (I know almost nothing about it).
> 
> NTPD behaves more normally on uniprocessor VMs.
> 
> A FreeBSD bhyve-guest running on a freebsd host will select a
> different timecounter depending on whether it is a multiprocessor or a
> uniprocessor.  My uniprocessor bhyve-vm selected TSC-low as the best
> timecounter in a uniprocessor.  NTP functions there as expected.
> 
> kern.timecounter.choice: TSC-low(1000) ACPI-fast(900) HPET(950) i8254(0) 
> dummy(-100)
> kern.timecounter.hardware: TSC-low
> 
> The very same VM, when given two total CPUs, selected HPET (if I
> recall) and the timekeeping with NTPD was unreliable, with many
> step-resets to the clock.

Yep, the same here. I've switched to TSC-low at Bhyve guest and there
is no stepping per 24 hours.

-- 
WBR, bsam
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

20.10.2017 21:04, Ian Lepore пишет:
> On Fri, 2017-10-20 at 20:20 +0300, Boris Samorodov wrote:
>> (CC to freebsd-virtualization@)
>>
>> 20.10.2017 19:32, Ian Lepore пишет:
>>>
>>> On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote:
>>>>
>>>> 20.10.2017 18:31, Boris Samorodov пишет:
>>>>>
>>>>>
>>>>> 20.10.2017 18:12, Ian Lepore пишет:
>>>>>>
>>>>>>
>>>>>> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I have got a host:
>>>>>>> ---
>>>>>>> bhyve-host% uname -a
>>>>>>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
>>>>>>> 25 05:25:26 MSK 2017
>>>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
>>>>>>> ---
>>>>>>>
>>>>>>> And a bhyve vm:
>>>>>>> ---
>>>>>>> bhyve-vm: uname -a
>>>>>>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
>>>>>>> Oct 20 05:12:17 MSK 2017
>>>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
>>>>>>> ---
>>>>>>>
>>>>>>> The only difference at kernel configs is a colored console. :-)
>>>>>>>
>>>>>>> And here I get some weird (is it?) result at the VM (I expect ntpd to be
>>>>>>> more stable):
>>>>>>> ---
>>>>>>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>>>>>  remote   refid  st t when poll reach   delay   offset
>>>>>>> jitter
>>>>>>> ==
>>>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
>>>>>>> 316.407
>>>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
>>>>>>> 358.395
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
>>>>>>> 181.405
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
>>>>>>> 214.868
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
>>>>>>> 214.868
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
>>>>>>> 268.618
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
>>>>>>> 333.175
>>>>>>>  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
>>>>>>> 0.000
>>>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
>>>>>>> 0.004
>>>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
>>>>>>> 68.800
>>>>>>> ---
>>>>>>>
>>>>>>> At the same time host's results are very stable:
>>>>>>> ---
>>>>>>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>>>>>  remote   refid  st t when poll reach   delay   offset
>>>>>>> jitter
>>>>>>> ==
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
>>>>>>> 0.106
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
>>>>>>> 0.459
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
>>>>>>> 0.940
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
>>>>>>> 0.940
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
>>>>>>> 1.566
>>>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
>>>>>>> 1.

Re: host, bhyve vm and ntpd

[Boris Samorodov]

(CC to freebsd-virtualization@)

20.10.2017 19:32, Ian Lepore пишет:
> On Fri, 2017-10-20 at 18:36 +0300, Boris Samorodov wrote:
>> 20.10.2017 18:31, Boris Samorodov пишет:
>>>
>>> 20.10.2017 18:12, Ian Lepore пишет:
>>>>
>>>> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I have got a host:
>>>>> ---
>>>>> bhyve-host% uname -a
>>>>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
>>>>> 25 05:25:26 MSK 2017
>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
>>>>> ---
>>>>>
>>>>> And a bhyve vm:
>>>>> ---
>>>>> bhyve-vm: uname -a
>>>>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
>>>>> Oct 20 05:12:17 MSK 2017
>>>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
>>>>> ---
>>>>>
>>>>> The only difference at kernel configs is a colored console. :-)
>>>>>
>>>>> And here I get some weird (is it?) result at the VM (I expect ntpd to be
>>>>> more stable):
>>>>> ---
>>>>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>>>  remote   refid  st t when poll reach   delay   offset
>>>>> jitter
>>>>> ==
>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
>>>>> 316.407
>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
>>>>> 358.395
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
>>>>> 181.405
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
>>>>> 214.868
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
>>>>> 214.868
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
>>>>> 268.618
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
>>>>> 333.175
>>>>>  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
>>>>> 0.000
>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
>>>>> 0.004
>>>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
>>>>> 68.800
>>>>> ---
>>>>>
>>>>> At the same time host's results are very stable:
>>>>> ---
>>>>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>>>  remote   refid  st t when poll reach   delay   offset
>>>>> jitter
>>>>> ==
>>>>>
>>>>>
>>>>>
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
>>>>> 0.106
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
>>>>> 0.459
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
>>>>> 0.940
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
>>>>> 0.940
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
>>>>> 1.566
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
>>>>> 1.739
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
>>>>> 2.365
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
>>>>> 3.110
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
>>>>> 3.929
>>>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
>>>>> 4.722
>>>>> ---
>>>>>
>>>>> The network is organized via bridge -- host igb and vm tap interfaces
>>>>> are members of one bridge.
>>>>>
>>>>> Are those results expected? Does it smell like a bug? Should I dig
>>>>> furter?
>>>>>
>>>> So it is repe

Re: host, bhyve vm and ntpd

[Boris Samorodov]

20.10.2017 18:31, Boris Samorodov пишет:
> 20.10.2017 18:12, Ian Lepore пишет:

>> So it is repeatedly stepping the clock in the VM? (Set
>> kern.timecounter.stepwarnings=1 to log steps).
> No kernel/ntpd messages for 20 minutes after setting this sysctl.

Sorry for multiply answers. The kernel message has just arrived:
---
Oct 20 18:31:25 builder kernel: Time stepped from 1508513486.200998799
to 1508513485.31729 (1508513485.316858000)
---

So, you are right, the time is stepped.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: host, bhyve vm and ntpd

[Boris Samorodov]

20.10.2017 18:31, Boris Samorodov пишет:
> 20.10.2017 18:12, Ian Lepore пишет:
>> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
>>> Hi All,
>>>
>>> I have got a host:
>>> ---
>>> bhyve-host% uname -a
>>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
>>> 25 05:25:26 MSK 2017
>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
>>> ---
>>>
>>> And a bhyve vm:
>>> ---
>>> bhyve-vm: uname -a
>>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
>>> Oct 20 05:12:17 MSK 2017
>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
>>> ---
>>>
>>> The only difference at kernel configs is a colored console. :-)
>>>
>>> And here I get some weird (is it?) result at the VM (I expect ntpd to be
>>> more stable):
>>> ---
>>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>  remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> ==
>>>  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
>>> 316.407
>>>  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
>>> 358.395
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
>>> 181.405
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
>>> 214.868
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
>>> 214.868
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
>>> 268.618
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
>>> 333.175
>>>  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
>>> 0.000
>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
>>> 0.004
>>>  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
>>> 68.800
>>> ---
>>>
>>> At the same time host's results are very stable:
>>> ---
>>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>>  remote   refid  st t when poll reach   delay   offset
>>> jitter
>>> ==
>>>
>>>
>>>
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
>>> 0.106
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
>>> 0.459
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
>>> 0.940
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
>>> 0.940
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
>>> 1.566
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
>>> 1.739
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
>>> 2.365
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
>>> 3.110
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
>>> 3.929
>>> *XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
>>> 4.722
>>> ---
>>>
>>> The network is organized via bridge -- host igb and vm tap interfaces
>>> are members of one bridge.
>>>
>>> Are those results expected? Does it smell like a bug? Should I dig
>>> furter?
>>>
>>
>> So it is repeatedly stepping the clock in the VM? (Set
>> kern.timecounter.stepwarnings=1 to log steps).
> 
> No kernel/ntpd messages for 20 minutes after setting this sysctl.
> 
>>  That is usually a sign
>> that the chosen timecounter is running at a different frequency than it
>> claimed to be when it registered itself -- the host may not be
>> emulating the timer hardware properly in the guest.  What is the output
>> of sysctl kern.timecounter in the vm?
> 
> ---
> bhyve-vm% sysctl kern.timecounter
> 
> kern.timecounter.tsc_shift: 1
> kern.timecounter.smp_tsc_adjust: 0
> kern.timecounter.smp_tsc: 0
> kern.timecounter.invariant_tsc: 1
> kern.timecounter.fast_gettime: 1
> kern.timecounter.tick: 1
> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100)
> dummy(-100)
> kern.time

Re: host, bhyve vm and ntpd

[Boris Samorodov]

20.10.2017 18:12, Ian Lepore пишет:
> On Fri, 2017-10-20 at 14:46 +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> I have got a host:
>> ---
>> bhyve-host% uname -a
>> FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
>> 25 05:25:26 MSK 2017
>> bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
>> ---
>>
>> And a bhyve vm:
>> ---
>> bhyve-vm: uname -a
>> FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
>> Oct 20 05:12:17 MSK 2017
>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
>> ---
>>
>> The only difference at kernel configs is a colored console. :-)
>>
>> And here I get some weird (is it?) result at the VM (I expect ntpd to be
>> more stable):
>> ---
>> bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>  remote   refid  st t when poll reach   delay   offset
>> jitter
>> ==
>>  XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
>> 316.407
>>  XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
>> 358.395
>> *XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
>> 181.405
>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
>> 214.868
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
>> 214.868
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
>> 268.618
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
>> 333.175
>>  XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
>> 0.000
>>  XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
>> 0.004
>>  XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
>> 68.800
>> ---
>>
>> At the same time host's results are very stable:
>> ---
>> bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
>>  remote   refid  st t when poll reach   delay   offset
>> jitter
>> ==
>>
>>
>>
>> *XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
>> 0.106
>> *XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
>> 0.459
>> *XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
>> 0.940
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
>> 0.940
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
>> 1.566
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
>> 1.739
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
>> 2.365
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
>> 3.110
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
>> 3.929
>> *XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
>> 4.722
>> ---
>>
>> The network is organized via bridge -- host igb and vm tap interfaces
>> are members of one bridge.
>>
>> Are those results expected? Does it smell like a bug? Should I dig
>> furter?
>>
> 
> So it is repeatedly stepping the clock in the VM? (Set
> kern.timecounter.stepwarnings=1 to log steps).

No kernel/ntpd messages for 20 minutes after setting this sysctl.

>  That is usually a sign
> that the chosen timecounter is running at a different frequency than it
> claimed to be when it registered itself -- the host may not be
> emulating the timer hardware properly in the guest.  What is the output
> of sysctl kern.timecounter in the vm?

---
bhyve-vm% sysctl kern.timecounter

kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 0
kern.timecounter.invariant_tsc: 1
kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(-100)
dummy(-100)
kern.timecounter.hardware: HPET
kern.timecounter.alloweddeviation: 5
kern.timecounter.stepwarnings: 1
kern.timecounter.tc.ACPI-fast.quality: 900
kern.timecounter.tc.ACPI-fast.frequency: 3579545
kern.timecounter.tc.ACPI-fast.counter: 4161213491
kern.timecounter.tc.ACPI-fast.mask: 4294967295
kern.timecounter.tc.HPET.quality: 950
kern.timecounter.tc.HPET.frequency: 1000
kern.timecounter.tc.HPET.counter: 3518036865
kern.timecounter.tc.HPET.mask: 4294967295
kern.timecounter.tc.i8254.quality: 0
kern.timecounter.tc.i8254.frequency: 1193182

host, bhyve vm and ntpd

[Boris Samorodov]

Hi All,

I have got a host:
---
bhyve-host% uname -a
FreeBSD sm.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #3 r322868: Fri Aug
25 05:25:26 MSK 2017
bsam@builder.bsnet:/usr/obj/usr/src/sys/GENERIC-FAST  amd64 amd64
---

And a bhyve vm:
---
bhyve-vm: uname -a
FreeBSD builder.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #58 r324782: Fri
Oct 20 05:12:17 MSK 2017
bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64 amd64
---

The only difference at kernel configs is a colored console. :-)

And here I get some weird (is it?) result at the VM (I expect ntpd to be
more stable):
---
bhyve-vm% for t in `jot 10`; do ntpq -pn; sleep 64; done
 remote   refid  st t when poll reach   delay   offset
jitter
==
 XX.XX.XX.1  XX.XX.XX.245 4 u9   6430.605   -1.202
316.407
 XX.XX.XX.1  XX.XX.XX.245 4 u7   6470.605   -1.202
358.395
*XX.XX.XX.1  XX.XX.XX.245 4 u5   64   170.615  -328.42
181.405
*XX.XX.XX.1  XX.XX.XX.245 4 u3   64   370.615  -328.42
214.868
*XX.XX.XX.1  XX.XX.XX.245 4 u   67   64   370.615  -328.42
214.868
*XX.XX.XX.1  XX.XX.XX.245 4 u   63   64   770.615  -328.42
268.618
*XX.XX.XX.1  XX.XX.XX.245 4 u   60   64  1770.615  -328.42
333.175
 XX.XX.XX.1  .STEP.  16 u 1910   6400.0000.000
0.000
 XX.XX.XX.1  XX.XX.XX.245 4 u   27   6410.703  -262.63
0.004
 XX.XX.XX.1  XX.XX.XX.245 4 u   31   6410.649  -331.43
68.800
---

At the same time host's results are very stable:
---
bhyve-host% for t in `jot 10`; do ntpq -pn; sleep 64; done
 remote   refid  st t when poll reach   delay   offset
jitter
==



*XX.XX.XX.1  XX.XX.XX.245 4 u1   6410.4010.176
0.106
*XX.XX.XX.1  XX.XX.XX.245 4 u6   6430.4010.176
0.459
*XX.XX.XX.1  XX.XX.XX.245 4 u3   6470.4010.176
0.940
*XX.XX.XX.1  XX.XX.XX.245 4 u   67   6470.4010.176
0.940
*XX.XX.XX.1  XX.XX.XX.245 4 u   64   64   170.4010.176
1.566
*XX.XX.XX.1  XX.XX.XX.245 4 u   60   64   370.4481.275
1.739
*XX.XX.XX.1  XX.XX.XX.245 4 u   55   64   770.4481.275
2.365
*XX.XX.XX.1  XX.XX.XX.245 4 u   53   64  1770.4481.275
3.110
*XX.XX.XX.1  XX.XX.XX.245 4 u   50   64  3770.4481.275
3.929
*XX.XX.XX.1  XX.XX.XX.245 4 u   45   64  3770.4438.750
4.722
---

The network is organized via bridge -- host igb and vm tap interfaces
are members of one bridge.

Are those results expected? Does it smell like a bug? Should I dig
furter?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [tzsetup] can't set up local timezone if CMOS is set to UTC

[Boris Samorodov]

08.08.2017 00:48, Marius Strobl пишет:

On Mon, Aug 07, 2017 at 09:51:15AM +0300, Boris Samorodov wrote:

07.08.2017 09:44, Boris Samorodov ?:

Hi Marius, All,

Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and
choose YES (CMOS clock is set to UTC), the program just quits.
Yea, my clocks are at UTC but I want to get time at local timezone. :-)

I've found a recent commit to tzsetup, is it the cause?


Hm. There is a log message at r322097:
---
- Make the initial UTC dialog actually work by giving the relevant files
the necessary treatment and then exit when choosing "Yes" there instead
of moving on to the time zone menu regardless.
---

I must misunderstand something.

So my question is: how to set up local time zone if CMOS is set to UTC?


Yeah, I hadn't thought of the case where one would like to set up
a configuration in which the RTC is using UTC but the timezone is
not.


I've used this configuration, well, almost forever. ;-)
As Kevin has already said and my habit is to set a unix machine CMOS
to UTC.


So I've reverted the corresponding part of r322097 for now


Confirmed, tzsetup works as expected (at least for me). Thank you for
quick fix and response.


as
I don't see an obvious way to give /etc/wall_cmos_clock appropriate
treatment in all 3 relevant cases (UTC/UTC, !UTC/UTC and !UTC/!UTC
regarding RTC/timezone) for all interactive and non-interactive
ways of using tzsetup(8).


--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [tzsetup] can't set up local timezone if CMOS is set to UTC

[Boris Samorodov]

07.08.2017 10:54, Trond Endrestøl пишет:

On Mon, 7 Aug 2017 09:51+0300, Boris Samorodov wrote:


So my question is: how to set up local time zone if CMOS is set to UTC?


My timezone is Europe/Oslo, adjust to fit your timezone:

rm -f /etc/wall_cmos_clock
cp -p /usr/share/zoneinfo/Europe/Oslo /etc/localtime
echo Europe/Oslo > /var/db/zoneinfo


Done. Got UTC time marked as local time.
(Five minutes later) Ntpdate fixed it, now local time is OK.
Thank you, Trond.

And (seems to be) the final question: can that be done via
tzsetup (as it used to be)?

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [tzsetup] can't set up local timezone if CMOS is set to UTC

[Boris Samorodov]

07.08.2017 09:44, Boris Samorodov пишет:

Hi Marius, All,

Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and
choose YES (CMOS clock is set to UTC), the program just quits.
Yea, my clocks are at UTC but I want to get time at local timezone. :-)

I've found a recent commit to tzsetup, is it the cause?


Hm. There is a log message at r322097:
---
- Make the initial UTC dialog actually work by giving the relevant files
  the necessary treatment and then exit when choosing "Yes" there instead
  of moving on to the time zone menu regardless.
---

I must misunderstand something.

So my question is: how to set up local time zone if CMOS is set to UTC?

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

[tzsetup] can't set up local timezone if CMOS is set to UTC

[Boris Samorodov]

Hi Marius, All,

Subj at today's amd64-HEAD. If I use command "sudo tzsetup" and
choose YES (CMOS clock is set to UTC), the program just quits.
Yea, my clocks are at UTC but I want to get time at local timezone. :-)

I've found a recent commit to tzsetup, is it the cause?

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [base pkg] update !GENERIC kernel

[Boris Samorodov]

20.07.2017 02:05, Ben Woods пишет:
> On Wed, 19 Jul 2017 at 7:37 pm, Boris Samorodov <b...@passap.ru> wrote:
> 
>> Hi All,
>>
>> I use self-made base packages for an ARM board. The kernel I use
>> is IMX6 one. While pkg update I get this:
>> ---
>> [271/302] Upgrading FreeBSD-kernel-imx6-debug from 12.0.s20170718113533
>> to 12.0.s20170719070514...
>> [271/302] Extracting FreeBSD-kernel-imx6-debug-12.0.s20170719070514:
>> 100%
>> kldxref: //boot/kernel: No such file or directory
>> pkg: POST-INSTALL script failed
>> [272/302] Upgrading FreeBSD-kernel-imx6 from 12.0.s20170718113533 to
>> 12.0.s20170719070514...
>> [272/302] Extracting FreeBSD-kernel-imx6-12.0.s20170719070514: 100%
>>
>> kldxref: //boot/kernel: No such file or directory
>> pkg: POST-INSTALL script failed
>> ---
>>
>> All is fine except those messages.
>>
>> There is no /boot/kernel, but there is /boot/kernel.IMX6. The kernel
>> is defined at /boot/loader.conf:
>> ---
>> kernel="kernel.IMX6"
>> ---
>>
>> Seems that for now pkg can't handle non-default kernel. Should I just
>> ignore those messages? Or should I run some post-update commands/scripts
>> by hand?
> 
> 
> I had the same problem on my machine using pkg-base with a non-default
> named kernel package.
> 
> As a workaround, I created a symlink at /boot/kernel pointing to the
> correct kernel directory. This seemed to fix the problem, but required this
> manual intervention.

Yep, I've end up doing the same. Thank you.

> It would be good if this wasn't required, and the kernel package used the
> kernel parameter in loader.conf to determine where to run the post-install
> script.

-- 
WBR, bsam
___
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"

[base pkg] update !GENERIC kernel

[Boris Samorodov]

Hi All,

I use self-made base packages for an ARM board. The kernel I use
is IMX6 one. While pkg update I get this:
---
[271/302] Upgrading FreeBSD-kernel-imx6-debug from 12.0.s20170718113533 
to 12.0.s20170719070514...
[271/302] Extracting FreeBSD-kernel-imx6-debug-12.0.s20170719070514: 
100%

kldxref: //boot/kernel: No such file or directory
pkg: POST-INSTALL script failed
[272/302] Upgrading FreeBSD-kernel-imx6 from 12.0.s20170718113533 to 
12.0.s20170719070514...
[272/302] Extracting FreeBSD-kernel-imx6-12.0.s20170719070514: 100% 


kldxref: //boot/kernel: No such file or directory
pkg: POST-INSTALL script failed
---

All is fine except those messages.

There is no /boot/kernel, but there is /boot/kernel.IMX6. The kernel
is defined at /boot/loader.conf:
---
kernel="kernel.IMX6"
---

Seems that for now pkg can't handle non-default kernel. Should I just
ignore those messages? Or should I run some post-update commands/scripts
by hand?

BTW, I did not find any evidence of POST-INSTALL scripts at the .txz
file. Are they hard-coded at pkg?

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

10.07.2017 23:58, Ronald Klop пишет:
> On Mon, 10 Jul 2017 21:53:11 +0200, Boris Samorodov <b...@passap.ru> wrote:
> 
>> 10.07.2017 22:21, Toomas Soome пишет:
>>>
>>>> On 10. juuli 2017, at 21:24, Boris Samorodov <b...@passap.ru> wrote:
>>>>
>>>> 10.07.2017 21:05, Allan Jude пишет:
>>>>> On 2017-07-09 14:40, Boris Samorodov wrote:
>>>>>> 08.07.2017 18:56, Boris Samorodov пишет:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I tied to install a new FreeBSD-amd-12 system from official USB
>>>>>>> installation memstick.img. Auto-UFS (GPT) installs fine and the
>>>>>>> system
>>>>>>> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
>>>>>>> At the very beginning it gives something like "gpt sector 
>>>>>>> error,
>>>>>>> gpt sector 1 error, can't find zroot..."
>>>>>>>
>>>>>>> Is it a known error / should I give more (precise) errors?
>>>>>>>
>>>>>>> I tried two recent images with the same result:
>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
>>>>>>>
>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img
>>>>>>>
>>>>>>
>>>>>> It turned out GPT and zfs are not usable at this machine.
>>>>>> MBR / ZFS works fine.
>>>>>>
>>>>>> I'll stick with that.
>>>>>
>>>>> What type of machine is it?
>>>>
>>>> It's a PC circa 2009 with MB ASUS P5QL/EPU:
>>>> ---
>>>> CPU: Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz (2799.52-MHz
>>>> K8-class CPU)
>>>>  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
>>>>
>>>>
>>>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>>>
>>>>
>>>>
>>>>
>>>> Features2=0xc08e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
>>>>
>>>>
>>>>  AMD Features=0x20100800<SYSCALL,NX,LM>
>>>>  AMD Features2=0x1
>>>>  VT-x: HLT,PAUSE
>>>>  TSC: P-state invariant, performance statistics
>>>> real memory  = 4294967296 (4096 MB)
>>>> avail memory = 3324891136 (3170 MB)
>>>> Event timer "LAPIC" quality 100
>>>> ACPI APIC Table: 
>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>> FreeBSD/SMP: 1 package(s) x 2 core(s)
>>>> ---
>>>>
>>>> -- 
>>>> WBR, bsam
>>>
>>> Of course it really can not be that the BIOS has something against
>>> combination of GPT+ZFS, but this combination may trigger some sort of
>>> bug/misbehavior. I have seen some pretty weird issues and have work
>>> in process to have a bit more fool proof approach, but I haven't had
>>> time yet to finalize it properly.
>>
>> Yep, UFS+GPT works fine here.
>>
>> Just for archieves: errors for ZFS + GPT
>> ---
>> gptzfsboot: error 128 lba 3907027040
>> gptzfsboot: error 128 lba 1
>> gptzfsboot: no zfs pools located, can't boot
>> ---
>>
>> The disk is:
>> ---
>> 512 # sectorsize
>> 2000397852160   # mediasize in bytes (1.8T)
>> 3907027055  # mediasize in sectors
>> 0   # stripesize
>> 0   # stripeoffset
>> 3876018 # Cylinders according to firmware.
>> 16  # Heads according to firmware.
>> 63  # Sectors according to firmware.
>> WD-WMAUR0112162 # Disk ident.
>> Not_Zoned   # Zone Mode
>> ---
>>
>> UEFI is not available at the motherboard.
>>
>>> Namely, what I have found is that in some systems the INT13 ah=08 can
>>> result with unexpected results - error from command reported or disk
>>> count not reported etc - something not really expected. It also may
>>> have to do about what other devices are there. And also if the system
>>> has plain BIOS or BIOS emulated on UEFI.
>>
> 
> This looks similar to:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
> Please add your information if you think it is the same issue. Or try
> the workaround and see if it helps.

Yes, the problem seems to be the same. A comment is added.

Thank you for the link.

-- 
WBR, bsam
___
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: [SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

10.07.2017 23:02, Toomas Soome пишет:
> 
>> On 10. juuli 2017, at 22:53, Boris Samorodov <b...@passap.ru> wrote:
>>
>> 10.07.2017 22:21, Toomas Soome пишет:
>>>
>>>> On 10. juuli 2017, at 21:24, Boris Samorodov <b...@passap.ru> wrote:
>>>>
>>>> 10.07.2017 21:05, Allan Jude пишет:
>>>>> On 2017-07-09 14:40, Boris Samorodov wrote:
>>>>>> 08.07.2017 18:56, Boris Samorodov пишет:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I tied to install a new FreeBSD-amd-12 system from official USB
>>>>>>> installation memstick.img. Auto-UFS (GPT) installs fine and the system
>>>>>>> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
>>>>>>> At the very beginning it gives something like "gpt sector  error,
>>>>>>> gpt sector 1 error, can't find zroot..."
>>>>>>>
>>>>>>> Is it a known error / should I give more (precise) errors?
>>>>>>>
>>>>>>> I tried two recent images with the same result:
>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
>>>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img
>>>>>>
>>>>>> It turned out GPT and zfs are not usable at this machine.
>>>>>> MBR / ZFS works fine.
>>>>>>
>>>>>> I'll stick with that.
>>>>>
>>>>> What type of machine is it?
>>>>
>>>> It's a PC circa 2009 with MB ASUS P5QL/EPU:
>>>> ---
>>>> CPU: Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz (2799.52-MHz
>>>> K8-class CPU)
>>>> Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
>>>>
>>>>
>>>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>>>
>>>>
>>>>
>>>> Features2=0xc08e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
>>>>
>>>> AMD Features=0x20100800<SYSCALL,NX,LM>
>>>> AMD Features2=0x1
>>>> VT-x: HLT,PAUSE
>>>> TSC: P-state invariant, performance statistics
>>>> real memory  = 4294967296 (4096 MB)
>>>> avail memory = 3324891136 (3170 MB)
>>>> Event timer "LAPIC" quality 100
>>>> ACPI APIC Table: 
>>>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>>>> FreeBSD/SMP: 1 package(s) x 2 core(s)
>>>> ---
>>>>
>>>> -- 
>>>> WBR, bsam
>>>
>>> Of course it really can not be that the BIOS has something against 
>>> combination of GPT+ZFS, but this combination may trigger some sort of 
>>> bug/misbehavior. I have seen some pretty weird issues and have work in 
>>> process to have a bit more fool proof approach, but I haven't had time yet 
>>> to finalize it properly.
>>
>> Yep, UFS+GPT works fine here.
>>
>> Just for archieves: errors for ZFS + GPT
>> ---
>> gptzfsboot: error 128 lba 3907027040
>> gptzfsboot: error 128 lba 1
> 
> Hm, 128 is 0x80 == Disk timeout. So it can be result from the missing device 
> (bad USB connection or missing floppy drive). What our INT13 related code is 
> currently missing, is the reset on error calls - to try to get the IO system 
> back to stable state. Or to be exact - the reset is not always used.

Actually, it's the same SATA cable/disk which works for UFS/ZFS.

> rgds,
> toomas
> 
>> gptzfsboot: no zfs pools located, can't boot
>> ---
>>
>> The disk is:
>> ---
>>512 # sectorsize
>>2000397852160   # mediasize in bytes (1.8T)
>>3907027055  # mediasize in sectors
>>0   # stripesize
>>0   # stripeoffset
>>3876018 # Cylinders according to firmware.
>>16  # Heads according to firmware.
>>63  # Sectors according to firmware.
>>WD-WMAUR0112162 # Disk ident.
>>Not_Zoned   # Zone Mode
>> ---
>>
>> UEFI is not available at the motherboard.
>>
>>> Namely, what I have found is that in some systems the INT13 ah=08 can 
>>> result with unexpected results - error from command reported or disk count 
>>> not reported etc - something not really expected. It also may have to do 
>>> about what other devices are there. And also if the system has plain BIOS 
>>> or BIOS emulated on UEFI.
>>
-- 
WBR, bsam
___
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: [SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

10.07.2017 22:21, Toomas Soome пишет:
> 
>> On 10. juuli 2017, at 21:24, Boris Samorodov <b...@passap.ru> wrote:
>>
>> 10.07.2017 21:05, Allan Jude пишет:
>>> On 2017-07-09 14:40, Boris Samorodov wrote:
>>>> 08.07.2017 18:56, Boris Samorodov пишет:
>>>>> Hi All,
>>>>>
>>>>> I tied to install a new FreeBSD-amd-12 system from official USB
>>>>> installation memstick.img. Auto-UFS (GPT) installs fine and the system
>>>>> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
>>>>> At the very beginning it gives something like "gpt sector  error,
>>>>> gpt sector 1 error, can't find zroot..."
>>>>>
>>>>> Is it a known error / should I give more (precise) errors?
>>>>>
>>>>> I tried two recent images with the same result:
>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
>>>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img
>>>>
>>>> It turned out GPT and zfs are not usable at this machine.
>>>> MBR / ZFS works fine.
>>>>
>>>> I'll stick with that.
>>>
>>> What type of machine is it?
>>
>> It's a PC circa 2009 with MB ASUS P5QL/EPU:
>> ---
>> CPU: Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz (2799.52-MHz
>> K8-class CPU)
>>  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
>>
>>
>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>
>>
>>
>> Features2=0xc08e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>
>>
>>  AMD Features=0x20100800<SYSCALL,NX,LM>
>>  AMD Features2=0x1
>>  VT-x: HLT,PAUSE
>>  TSC: P-state invariant, performance statistics
>> real memory  = 4294967296 (4096 MB)
>> avail memory = 3324891136 (3170 MB)
>> Event timer "LAPIC" quality 100
>> ACPI APIC Table: 
>> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
>> FreeBSD/SMP: 1 package(s) x 2 core(s)
>> ---
>>
>> -- 
>> WBR, bsam
> 
> Of course it really can not be that the BIOS has something against 
> combination of GPT+ZFS, but this combination may trigger some sort of 
> bug/misbehavior. I have seen some pretty weird issues and have work in 
> process to have a bit more fool proof approach, but I haven't had time yet to 
> finalize it properly.

Yep, UFS+GPT works fine here.

Just for archieves: errors for ZFS + GPT
---
gptzfsboot: error 128 lba 3907027040
gptzfsboot: error 128 lba 1
gptzfsboot: no zfs pools located, can't boot
---

The disk is:
---
512 # sectorsize
2000397852160   # mediasize in bytes (1.8T)
3907027055  # mediasize in sectors
0   # stripesize
0   # stripeoffset
3876018 # Cylinders according to firmware.
16  # Heads according to firmware.
63  # Sectors according to firmware.
WD-WMAUR0112162 # Disk ident.
Not_Zoned   # Zone Mode
---

UEFI is not available at the motherboard.

> Namely, what I have found is that in some systems the INT13 ah=08 can result 
> with unexpected results - error from command reported or disk count not 
> reported etc - something not really expected. It also may have to do about 
> what other devices are there. And also if the system has plain BIOS or BIOS 
> emulated on UEFI.

-- 
WBR, bsam
___
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: [SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

10.07.2017 21:05, Allan Jude пишет:
> On 2017-07-09 14:40, Boris Samorodov wrote:
>> 08.07.2017 18:56, Boris Samorodov пишет:
>>> Hi All,
>>>
>>> I tied to install a new FreeBSD-amd-12 system from official USB
>>> installation memstick.img. Auto-UFS (GPT) installs fine and the system
>>> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
>>> At the very beginning it gives something like "gpt sector  error,
>>> gpt sector 1 error, can't find zroot..."
>>>
>>> Is it a known error / should I give more (precise) errors?
>>>
>>> I tried two recent images with the same result:
>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img
>>
>> It turned out GPT and zfs are not usable at this machine.
>> MBR / ZFS works fine.
>>
>> I'll stick with that.
> 
> What type of machine is it?

It's a PC circa 2009 with MB ASUS P5QL/EPU:
---
CPU: Intel(R) Core(TM)2 Duo CPU E7400  @ 2.80GHz (2799.52-MHz
K8-class CPU)
  Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10


Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>



Features2=0xc08e3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,OSXSAVE>

  AMD Features=0x20100800<SYSCALL,NX,LM>
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics
real memory  = 4294967296 (4096 MB)
avail memory = 3324891136 (3170 MB)
Event timer "LAPIC" quality 100
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
---

-- 
WBR, bsam



signature.asc
Description: OpenPGP digital signature

Re: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 19:08, Benjamin Kaduk пишет:

> (BTW, I think there is not agreement as to whether vmrun.sh should
> be used in general use, or alternate solutions for VM managemnet.)

As a side note: I used the process written at TH...

-- 
WBR, bsam
___
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"

[SOLVED] [memstick install] auto-zfs error

[Boris Samorodov]

08.07.2017 18:56, Boris Samorodov пишет:
> Hi All,
> 
> I tied to install a new FreeBSD-amd-12 system from official USB
> installation memstick.img. Auto-UFS (GPT) installs fine and the system
> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
> At the very beginning it gives something like "gpt sector  error,
> gpt sector 1 error, can't find zroot..."
> 
> Is it a known error / should I give more (precise) errors?
> 
> I tried two recent images with the same result:
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img

It turned out GPT and zfs are not usable at this machine.
MBR / ZFS works fine.

I'll stick with that.

-- 
WBR, bsam
___
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: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 19:08, Benjamin Kaduk пишет:
> On Sun, Jul 09, 2017 at 06:58:09PM +0300, Boris Samorodov wrote:
>> 09.07.2017 18:48, Boris Samorodov пишет:
>>> 09.07.2017 18:37, Benjamin Kaduk пишет:
>>>>
>>>> Documentation looks okay, as -I  is documented during
>>>> the install stage, and is not supposed to be needed during
>>>> normal operation.
>>>>
>>>> The quoted error message from vmrun.sh happens when it thinks you
>>>> need to install on the given filesystem image
>>>> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
>>>> so it might be worth checking that your guest.img contains a valid
>>>> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
>>>> prepared to handle that?)
>>>
>>> Yes, I used AutoZFS installer function to install FreeBSD.
>>
>> -
>> % sudo mdconfig -f quest.img
>> mdo0
>>
>> % gpart show md0
>> =>  40  16777136  md0  GPT  (8.0G)
>> 40  10241  freebsd-boot  (512K)
>>   1064   984   - free -  (492K)
>>   2048   41943042  freebsd-swap  (2.0G)
>>4196352  125788163  freebsd-zfs  (6.0G)
>>   16775168  2008   - free -  (1.0M)
>> -
>>
>> So, that seems the same bug as at my previous email:
>> https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066514.html
> 
> Is it?  I refer to this part of vmrun.sh:
> 
>   file -s ${first_diskdev} | grep "boot sector" > /dev/null
>   rc=$?
>   if [ $rc -ne 0 ]; then
>   file -s ${first_diskdev} | grep ": Unix Fast File sys" > 
> /dev/null
>   rc=$?
>   fi
>   if [ $rc -ne 0 ]; then
>   need_install=1
>   else
>   need_install=0
>   fi
> 
> Which is not expected to be particularly robust.
> (BTW, I think there is not agreement as to whether vmrun.sh should
> be used in general use, or alternate solutions for VM managemnet.)

OK, normal bhyveload/bhyve ended up at a successful boot.
Benjamin, thank you for your comments and help!

-- 
WBR, bsam
___
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: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 18:48, Boris Samorodov пишет:
> 09.07.2017 18:37, Benjamin Kaduk пишет:
>> On Sun, Jul 09, 2017 at 01:02:26PM +0300, Boris Samorodov wrote:
>>> Hi All,
>>>
>>> I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
>>> a FreeBSD Guest". All is good up until the last command at the section.
>>> When I try to launch the installed client, I get:
>>> -
>>> # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
>>> guest.img guestname
>>> Launching virtual machine "guestname" ...
>>> Installation CDROM image "./release.iso" is not readable
>>>
>>> % uname -a
>>> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
>>> Jul  9 07:10:56 MSK 2017
>>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
>>> -
>>>
>>> Is it a bug at vmrun.sh or documentation?
>>
>> Documentation looks okay, as -I  is documented during
>> the install stage, and is not supposed to be needed during
>> normal operation.
>>
>> The quoted error message from vmrun.sh happens when it thinks you
>> need to install on the given filesystem image
>> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
>> so it might be worth checking that your guest.img contains a valid
>> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
>> prepared to handle that?)
> 
> Yes, I used AutoZFS installer function to install FreeBSD.

-
% sudo mdconfig -f quest.img
mdo0

% gpart show md0
=>  40  16777136  md0  GPT  (8.0G)
40  10241  freebsd-boot  (512K)
  1064   984   - free -  (492K)
  2048   41943042  freebsd-swap  (2.0G)
   4196352  125788163  freebsd-zfs  (6.0G)
  16775168  2008   - free -  (1.0M)
-

So, that seems the same bug as at my previous email:
https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066514.html

-- 
WBR, bsam
___
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: [bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

09.07.2017 18:37, Benjamin Kaduk пишет:
> On Sun, Jul 09, 2017 at 01:02:26PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
>> a FreeBSD Guest". All is good up until the last command at the section.
>> When I try to launch the installed client, I get:
>> -
>> # sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
>> guest.img guestname
>> Launching virtual machine "guestname" ...
>> Installation CDROM image "./release.iso" is not readable
>>
>> % uname -a
>> FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
>> Jul  9 07:10:56 MSK 2017
>> bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
>> -
>>
>> Is it a bug at vmrun.sh or documentation?
> 
> Documentation looks okay, as -I  is documented during
> the install stage, and is not supposed to be needed during
> normal operation.
> 
> The quoted error message from vmrun.sh happens when it thinks you
> need to install on the given filesystem image
> (if [ $force_install -eq 1 -o $need_install -eq 1 ];)
> so it might be worth checking that your guest.img contains a valid
> FFS filesystem on it.  (Hmm, maybe you used ZFS and vmrun.sh isn't
> prepared to handle that?)

Yes, I used AutoZFS installer function to install FreeBSD.

-- 
WBR, bsam
___
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"

[bhyve] FreeBSD guest, Handbook, vmrun.sh

[Boris Samorodov]

Hi All,

I try to create a FreeBSD guest as per TH, section "21.7.2. Creating
a FreeBSD Guest". All is good up until the last command at the section.
When I try to launch the installed client, I get:
-
# sh /usr/share/examples/bhyve/vmrun.sh -c 4 -m 1024M -t tap0 -d
guest.img guestname
Launching virtual machine "guestname" ...
Installation CDROM image "./release.iso" is not readable

% uname -a
FreeBSD latt.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r320821: Sun
Jul  9 07:10:56 MSK 2017
bsam@builder.bsnet:/usr/obj/usr/src/sys/PKG64X  amd64
-

Is it a bug at vmrun.sh or documentation?

-- 
WBR, bsam
___
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, repos and cached certificates

[Boris Samorodov]

Hi All,

I use own pkg base repository. Today I tried to install packages
on a new system. However, pkg refused to use my repo, since it's
certificate is expired (several days). That's good.

However, pkg happily update packages at other systems. So, seems
that pkg does not perform checks / validates known certificates.
Which seems not as good.

Thanks,
-- 
WBR, bsam
___
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"

[memstick install] auto-zfs error

[Boris Samorodov]

Hi All,

I tied to install a new FreeBSD-amd-12 system from official USB
installation memstick.img. Auto-UFS (GPT) installs fine and the system
boots fine. However, ZFS-Auto install succeeds, but is not loaded.
At the very beginning it gives something like "gpt sector  error,
gpt sector 1 error, can't find zroot..."

Is it a known error / should I give more (precise) errors?

I tried two recent images with the same result:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img

Thanks all,
-- 
WBR, bsam
___
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: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory

[Boris Samorodov]

05.07.2017 22:29, Bryan Drewery пишет:

> Parallel install should be working just fine.  It is a supported feature
> of installworld.  What was the issue exactly?

https://lists.freebsd.org/pipermail/freebsd-current/2017-June/066408.html

As I understand, it was an installworld while base packages building.

But I suspect that META_MODE may be to blame. I've shitched it off
since then.

-- 
WBR, bsam



signature.asc
Description: OpenPGP digital signature

Re: [base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory

[Boris Samorodov]

27.06.2017 20:06, Trond Endrestøl пишет:

> Try running make installworld without -j N.
> Serial installworld was successful at my end.

Thank you, that helped.

-- 
WBR, bsam
___
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"

[base package build] [fail] r320347 -> r320392: install: builddir/Africa/Abidjan: No such file or directory

[Boris Samorodov]

Hi,

I regularly build base packages for FreeBSD-HEAD-amd64. After jump from
r320347 to r320392 (build world/kernel are fine) I get an error while
package building (make -C /usr/src packages):
-
--- realinstall_subdir_share ---
--- realinstall_subdir_share/zoneinfo ---
install: builddir/Africa/Abidjan: No such file or directory
*** [install-zoneinfo] Error code 71
-

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: Insta-panic for amd64 on reboot after upgrade from r320307 -> r320324

[Boris Samorodov]

25.06.2017 16:21, Konstantin Belousov пишет:
> On Sun, Jun 25, 2017 at 06:05:21AM -0700, David Wolfskill wrote:
>> On Sun, Jun 25, 2017 at 03:52:23PM +0300, Konstantin Belousov wrote:
>>> ...
> The layout of the struct vm_map_entry was changed, the faulted address
> is somewhat consistent with ABI mismatch.

 Kinky. :-}
>>> Do you use any third-party modules ?
>>
>> On the laptop, I use x11/nvidia-driver-340; on the build machine, no.
>>
>> I think we should focus on the build machine -- it runs a GENERIC kernel
>> without ports (3rd-party) modules.
> Ok.
> 
>>
>> #cat /etc/src-env.conf 
>> WITH_META_MODE=yes
> 
> So can you _remove_ all kernel object files and rebuild anew with the
> clean build dir, please ?

I also use WITH_META_MODE=yes. And full rebuild helped here too.

Thank you.

-- 
WBR, bsam
___
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: r320307 -> r320324: kernel does not load

[Boris Samorodov]

(cc: kib@)

Hi Kostik,

FYI: I've looked though last source changes and it looks like
your commit(s) may be related.

25.06.2017 13:54, Boris Samorodov пишет:
> Hi All,
> 
> I use self-built base packages for system updates. The jump from
> r320307 to r320324 leads to fatal trap 12 at the very beginning:
> https://goo.gl/Pgujga (sorry for the poor photo quality)
> 
> Revert to r320307, and the system boots fine.

-- 
WBR, bsam
___
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"

r320307 -> r320324: kernel does not load

[Boris Samorodov]

Hi All,

I use self-built base packages for system updates. The jump from
r320307 to r320324 leads to fatal trap 12 at the very beginning:
https://goo.gl/Pgujga (sorry for the poor photo quality)

Revert to r320307, and the system boots fine.

-- 
WBR, bsam
___
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: [bsd.linker.mk] line 42: Unable to determine linker type from LD=ld

[Boris Samorodov]

23.06.2017 17:19, Boris Samorodov пишет:
> Hi All, Bryan!
> 
> Since bsd.linker.mk introduction I can't manage to create
> FreeBSD base packages. The process stops at the very beginning:
> -
> --- packages ---
> --- packages ---
> make -C /usr/src PKG_VERSION=12.0.s20170623140202 real-packages
> --- real-packages ---
> --- stage-packages ---
> mkdir -p /tmp/install.DQDhLPed
> progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp  date
> echo egrep find grep id install   ln make mkdir mtree mv pwd_mkdb  rm
> sed services_mkdb sh strip sysctl test true uname wc zic tzsetup
> makewhatis; do  if progpath=
> `which $prog`; then  echo $progpath;  else  echo "Required tool $prog
> not found in PATH." >&2;  exit 1;  fi;  done);  libs=$(ldd -f "%o %p\n"
> -f "%o %p\n" $progs 2>/dev/null | sort -u |  while read line; do  $line;
>  if [ "$2 $3" != "not
> found" ]; then  echo $2;  else  echo "Required library $1 not found."
>> &2;  exit 1;  fi;  done);  cp $libs $progs /tmp/install.DQDhLPed
> cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.DQDhLPed/locale
> mkdir -p /usr/obj/usr/src/amd64.amd64/worldstage/
> echo "#mtree 2.0" > /usr/obj/usr/src/amd64.amd64/worldstage//METALOG
> cd /usr/src; COMPILER_VERSION=4  COMPILER_FEATURES=c++11
> COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126
> MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> CC="cc -target x86_64-unknown-freebsd12.0 --sysroo
> t=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tm
> p -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
> NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/lega
> cy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/tmp/install.DQDhLPed
>  LD_LIBRARY_PATH=/tmp/install.DQDhLPed
> PATH_LOCALE=/tmp/install.DQDhLPed/locale make -f Makefile.inc1
> INSTALL="install -U -M /usr/obj/usr/src/amd64
> .amd64/worldstage//METALOG -D /usr/obj/usr/src/amd64.amd64/worldstage"
> MTREE_CMD="mtree -W" __MAKE_SHELL=/tmp/install.DQDhLPed/sh -DNO_ROOT
> METALOG=/usr/obj/usr/src/amd64.amd64/worldstage//METALOG restage;
> COMPILER_VERSION=4  COMPIL
> ER_FEATURES=c++11  COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126
> MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> CC="cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/t
> mp/usr/bin" CXX="c++  -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp
> -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as"
> AR="ar" LD="ld" LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib
> STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/o
> bj/usr/src/tmp/usr/bin:/tmp/install.DQDhLPed
> LD_LIBRARY_PATH=/tmp/install.DQDhLPed
> PATH_LOCALE=/tmp/install.DQDhLPed/locale rm -rf /tmp/install.DQDhLPed
> sh: head: not found
> make[6]: "/usr/src/share/mk/bsd.linker.mk" line 42: Unable to determine
> linker type from LD=ld
> *** Error code 1
> 
> Stop.
> -
> 
Yes! Awesome!! Thank you for quick reaction and the fix.

-- 
WBR, bsam
___
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"

[bsd.linker.mk] line 42: Unable to determine linker type from LD=ld

[Boris Samorodov]

Hi All, Bryan!

Since bsd.linker.mk introduction I can't manage to create
FreeBSD base packages. The process stops at the very beginning:
-
--- packages ---
--- packages ---
make -C /usr/src PKG_VERSION=12.0.s20170623140202 real-packages
--- real-packages ---
--- stage-packages ---
mkdir -p /tmp/install.DQDhLPed
progs=$(for prog in [ awk cap_mkdb cat chflags chmod chown cmp cp  date
echo egrep find grep id install   ln make mkdir mtree mv pwd_mkdb  rm
sed services_mkdb sh strip sysctl test true uname wc zic tzsetup
makewhatis; do  if progpath=
`which $prog`; then  echo $progpath;  else  echo "Required tool $prog
not found in PATH." >&2;  exit 1;  fi;  done);  libs=$(ldd -f "%o %p\n"
-f "%o %p\n" $progs 2>/dev/null | sort -u |  while read line; do  $line;
 if [ "$2 $3" != "not
found" ]; then  echo $2;  else  echo "Required library $1 not found."
>&2;  exit 1;  fi;  done);  cp $libs $progs /tmp/install.DQDhLPed
cp -R ${PATH_LOCALE:-"/usr/share/locale"} /tmp/install.DQDhLPed/locale
mkdir -p /usr/obj/usr/src/amd64.amd64/worldstage/
echo "#mtree 2.0" > /usr/obj/usr/src/amd64.amd64/worldstage//METALOG
cd /usr/src; COMPILER_VERSION=4  COMPILER_FEATURES=c++11
COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126
MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
CC="cc -target x86_64-unknown-freebsd12.0 --sysroo
t=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -target
x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -target
x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tm
p -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/lega
cy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/tmp/install.DQDhLPed
 LD_LIBRARY_PATH=/tmp/install.DQDhLPed
PATH_LOCALE=/tmp/install.DQDhLPed/locale make -f Makefile.inc1
INSTALL="install -U -M /usr/obj/usr/src/amd64
.amd64/worldstage//METALOG -D /usr/obj/usr/src/amd64.amd64/worldstage"
MTREE_CMD="mtree -W" __MAKE_SHELL=/tmp/install.DQDhLPed/sh -DNO_ROOT
METALOG=/usr/obj/usr/src/amd64.amd64/worldstage//METALOG restage;
COMPILER_VERSION=4  COMPIL
ER_FEATURES=c++11  COMPILER_TYPE=clang  COMPILER_FREEBSD_VERSION=126
MAKEOBJDIRPREFIX=/usr/obj  MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
CC="cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/t
mp/usr/bin" CXX="c++  -target x86_64-unknown-freebsd12.0
--sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp
-target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as"
AR="ar" LD="ld" LLVM_LINK=""  NM=nm OBJCOPY="objcopy"  RANLIB=ranlib
STRINGS=  SIZE="size"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/o
bj/usr/src/tmp/usr/bin:/tmp/install.DQDhLPed
LD_LIBRARY_PATH=/tmp/install.DQDhLPed
PATH_LOCALE=/tmp/install.DQDhLPed/locale rm -rf /tmp/install.DQDhLPed
sh: head: not found
make[6]: "/usr/src/share/mk/bsd.linker.mk" line 42: Unable to determine
linker type from LD=ld
*** Error code 1

Stop.
-

-- 
WBR, bsam
___
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: ino64, java and intellij products problem

[Boris Samorodov]

01.06.2017 00:29, Konstantin Belousov пишет:
> On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Seems that after ino64 transition some java programs stopped
>> to fully function. I.e. java/intellij (IntellJ IDEA and Co)
>> starts but does not show any files.
>>
>> I'm not sure if it's a java or IntelliJ problem. Any help to
>> diagnose the culprit is welcome.
> 
> Is it after full rebuild of all ports for post-ino64, or with all ports
> built on pre-ino64 ?  (Mixes are not supported and not supposed to work).

Hm. I've rebuild all required ports:
---
% pkg info -d intellij-2017.1.3
intellij-2017.1.3:
python27-2.7.13_3
openjdk8-8.131.11
intellij-pty4j-0.5_1
intellij-fsnotifier-20160221_2
---

But sure not *all* ports.

> Check java programs for JNI calls which return struct stat or struct
> dirent to java code, and java code which knows the layout.  It is, e.g.,
> the problem with Firefox and its javascript, but there the recompilation
> seems to work.

OK, thanks. I'll wait for FreeBSD cluster[*] to build post-ino64
packages, reinstall all of them and see what's next.

[*] Seems to occur RSN.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

ino64, java and intellij products problem

[Boris Samorodov]

Hi All,

Seems that after ino64 transition some java programs stopped
to fully function. I.e. java/intellij (IntellJ IDEA and Co)
starts but does not show any files.

I'm not sure if it's a java or IntelliJ problem. Any help to
diagnose the culprit is welcome.

Thanks.
-- 
WBR, bsam
___
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: ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

[Boris Samorodov]

24.05.2017 18:09, Dimitry Andric пишет:
> On 24 May 2017, at 14:58, Boris Samorodov <b...@passap.ru> wrote:
>>
>> JFYI: Today I've got a bunch (as much as 63) of cftconvert errors
>> while make buildkernel. There were no such errors tomorrow. The building
>> machine is FreeBSD-amd64-r317665.
>>
>> Errors are not fatal, so the kernel has build successfully. I didn't
>> dare to try to install it yet.
> 
> These messages have been occurring for a long time now (years?), and
> can be safely ignored.

Hi Dimitry,

I suspected something like this. I have WITH_META_MODE defined so it may
be why I do see those messages rarely.

Thank you.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve



signature.asc
Description: OpenPGP digital signature

Re: base packages, ino64 and upgrade

[Boris Samorodov]

24.05.2017 16:00, Glen Barber пишет:
> On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Does anyone know the procedure to upgrade for those using base packages?
> 
> 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is
> called), reboot, 'pkg upgrade'.

OK, thanks. I'll try in the evening.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve



signature.asc
Description: OpenPGP digital signature

ERROR: ctfconvert: [...] has too many members: 1911 > 1023 _and_ ERROR: rc = -1 No entry found [dwarf_next_cu_header_c(61)]

[Boris Samorodov]

Hi All,

JFYI: Today I've got a bunch (as much as 63) of cftconvert errors
while make buildkernel. There were no such errors tomorrow. The building
machine is FreeBSD-amd64-r317665.

Errors are not fatal, so the kernel has build successfully. I didn't
dare to try to install it yet.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

base packages, ino64 and upgrade

[Boris Samorodov]

Hi All,

Does anyone know the procedure to upgrade for those using base packages?

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

misc/mc, diff and compare two files

[Boris Samorodov]

Hi All,

FYI: For those who use FreeBSD-HEAD, misc/mc and it's awesome "compare
two files" feature:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219277

HTH
--
WBR, bsam
___
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: r316958: booting a server takes >10 minutes!

[Boris Samorodov]

15.04.2017 14:53, O. Hartmann пишет:

Recent CURRENT running on a server makes the system booting in multiuser mode 
booting
incredibly slow! On a machine, before I interrupted the booting process hanging 
in
starting postgresql 9.6.2 server, it took > 10 minutes.


Same here. BTW, the command "service -e" runs forever and eats CPU.

I had to kill sendmail and dbus (which were chewing CPU) and then
"service -e" run fine.

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
"It is not necessary to change. Survival is not mandatory."
___
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 packages and subdirectories

[Boris Samorodov]

Hi All,

I've created my base repo and installed the OS from packages.
All in all it all went rather smooth!

As for pkg it seems to not pay attention to base library subdirs:
-
# pkg check -Ba

Checking all packages:   3%
(FreeBSD-kernel-sm-12.0.s20170128125723) /boot/kernel/kernel - required 
shared library hack.pico not found

Checking all packages:  35%
(FreeBSD-runtime-12.0.s20170128125723) /sbin/ping - required shared 
library libcap_dns.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/bin/kdump - required shared 
library libcap_grp.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/bin/kdump - required shared 
library libcap_pwd.so.0 not found
(FreeBSD-runtime-12.0.s20170128125723) /usr/sbin/tcpdump - required 
shared library libcap_dns.so.0 not found

Checking all packages:  36%
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_dns/dns_test - required shared 
library libcap_dns.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_grp/grp_test - required shared 
library libcap_grp.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_pwd/pwd_test - required shared 
library libcap_pwd.so.0 not found
(FreeBSD-tests-12.0.s20170128125723) 
/usr/tests/lib/libcasper/services/cap_sysctl/sysctl_test - required 
shared library libcap_sysctl.so.0 not found

Checking all packages: 100%

# ldd `which ping`
/sbin/ping:
libm.so.5 => /lib/libm.so.5 (0x800828000)
libcasper.so.0 => /lib/libcasper.so.0 (0x800a52000)
libcap_dns.so.0 => /lib/casper/libcap_dns.so.0 (0x800c57000)
libipsec.so.4 => /lib/libipsec.so.4 (0x800e5b000)

# ls -l /lib/casper
total 51
-r--r--r--  1 root  wheel  16584 28 янв.  15:58 libcap_dns.so.0
-r--r--r--  1 root  wheel  15968 28 янв.  15:58 libcap_grp.so.0
-r--r--r--  1 root  wheel  15872 28 янв.  15:58 libcap_pwd.so.0
-r--r--r--  1 root  wheel   6904 28 янв.  15:58 libcap_random.so.0
-r--r--r--  1 root  wheel   8912 28 янв.  15:58 libcap_sysctl.so.0
-----

--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: Does someone keep track of how long it takes to buildworld/kernel?

[Boris Samorodov]

13.01.2017 23:23, Eric Joyner пишет:
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.

For me "forever" today was less then 3 minutes. ;-)
Here is some stats:
---
% cd /usr/obj
% grep "World build" bw.amd64.log*
bw.amd64.log:>>> World build started on Fri Jan 13 17:42:07 MSK 2017
bw.amd64.log:>>> World build completed on Fri Jan 13 17:44:45 MSK 2017
bw.amd64.log.0:>>> World build started on Thu Jan 12 20:55:07 MSK 2017
bw.amd64.log.0:>>> World build completed on Thu Jan 12 21:00:37 MSK 2017
bw.amd64.log.1:>>> World build started on Thu Jan 12 11:54:28 MSK 2017
bw.amd64.log.1:>>> World build completed on Thu Jan 12 11:59:43 MSK 2017
bw.amd64.log.2:>>> World build started on Wed Jan 11 14:41:59 MSK 2017
bw.amd64.log.2:>>> World build completed on Wed Jan 11 14:46:36 MSK 2017
bw.amd64.log.3:>>> World build started on Wed Jan 11 13:15:03 MSK 2017
bw.amd64.log.3:>>> World build completed on Wed Jan 11 13:59:01 MSK 2017
bw.amd64.log.4:>>> World build started on Sun Jan  8 17:21:15 MSK 2017
bw.amd64.log.4:>>> World build completed on Sun Jan  8 17:30:30 MSK 2017
bw.amd64.log.5:>>> World build started on Sat Jan  7 21:27:06 MSK 2017
bw.amd64.log.5:>>> World build completed on Sat Jan  7 23:37:25 MSK 2017
bw.amd64.log.6:>>> World build started on Thu Dec 22 13:19:08 MSK 2016
bw.amd64.log.6:>>> World build completed on Thu Dec 22 13:40:22 MSK 2016
---

With "WITH_META_MODE=yes" at /etc/src-env.conf it's rather sane time.
But not if clang or like changes. :-(

The machine is:
---
FreeBSD 12.0-CURRENT #39 r312075: Fri Jan 13 17:47:05 MSK 2017
bsam@bb055.bsnet:/usr/obj/usr/src/sys/BB64X amd64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on
LLVM 3.9.1)
VT(vga): resolution 640x480
info: [drm] Initialized drm 1.1.0 20060810
CPU: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz (3092.27-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
Features=0xbfebfbff
Features2=0x1d9ae3bf
  AMD Features=0x28100800
  AMD Features2=0x1
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8136523776 (7759 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
[...]
ada1 at ahcich4 bus 0 scbus2 target 0 lun 0
ada1:  ACS-2 ATA SATA 3.x device
ada1: Serial Number Z1D5Y0X8
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 953869MB (1953525168 512 byte sectors)
ada1: quirks=0x1<4K>
---

HTH & WBR
-- 
bsam
___
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: should aarch64 cross-build work at amd64?

[Boris Samorodov]

28.09.2016 07:22, Glen Barber пишет:
> On Tue, Sep 27, 2016 at 09:46:29PM -0600, Ross Alexander wrote:
>> On Fri, 23 Sep 2016 22:19:15 +, Glenn Barber wrote:
>>
>>> On Sat, Sep 24, 2016 at 12:54:05AM +0300, Boris Samorodov wrote:
>>>> 24.09.2016 00:44, Boris Samorodov ?:
>>>>> 24.09.2016 00:39, Glen Barber ?:
>>>>>> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote:
>>>>>>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177:
>>>>>>> In-tree binutils does not support the aarch64 architecture. Install the
>>>>>>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX.
>>>>>>
>>>>>> These lines are relevant.
>>>>>
>>>>> Ops. Thank you.
>>>>
>>>> The error when aarch64-binutils are installed:
>>>> -
>>>> % sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m
>>>> svn+https -J 8
>>>
>>> Try with 'arm64.aarch64'.
>>> Glen
>>
>> Glen,
>>
>> The more I read this, the less I understand.  I've built and install'd
>> aarch64-binutils on my poud box, then created an "-x -a arm64.aarch64 -m svn"
>> jail - which worked fine - but that jail won't build anything.  No
>> /usr/bin/ld, so toolchain is borked, so can't build ports-mgmt/pkg.
>> What utterly obvious thing have I missed?  I've spent hours trying to
>> fake out the nxb-bin stuff, or to find some other point of entry, no
>> joy.
>>
>> FreeBSD aubey2.bogons 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r306286:
>> Fri Sep 23 21:32:37 MDT 2016
>> toor@aubey2.bogons:/usr/obj/usr/src/sys/GENERIC amd64
>>
>> poudriere-devel-3.1.99.20160624_2
>>
>> qemu-user-static-2.6.90.g20160728
>>
>> aarch64-binutils-2.25.1_3,1
>>
>> # /usr/sbin/binmiscctl lookup aarch64
>> name: aarch64
>> interpreter: /usr/local/bin/qemu-aarch64-static
>> flags: ENABLED USE_MASK
>> magic size: 20
>> magic offset: 0
>> magic: 0x7f 0x45 0x4c 0x46  0x02 0x01 0x01 0x00  0x00 0x00 0x00 0x00
>>0x00 0x00 0x00 0x00  0x02 0x00 0xb7 0x00
>>mask:  0xff 0xff 0xff 0xff  0xff 0xff 0xff 0x00  0xff 0xff 0xff 0xff
>>       0xff 0xff 0xff 0xff  0xfe 0xff 0xff 0xff
>>
>> failing jail is "11-stab-arm64 11.0-PRERELEASE r306344 arm64.aarch64 svn 
>> 2016-09-26 18:54:15 /usr/local/pd/jails/11-stab-arm64"
>>
> 
> You should not need to use binmiscctl and QEMU.  Try:
> 
>  # poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m \
> svn+https

Last time I tried the needed option for arch was "-a arm64.aarch64".
Glen, it was you who helped me to fugure out the option. :-)

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve



signature.asc
Description: OpenPGP digital signature

Re: should aarch64 cross-build work at amd64?

[Boris Samorodov]

24.09.2016 01:19, Glen Barber пишет:
> On Sat, Sep 24, 2016 at 12:54:05AM +0300, Boris Samorodov wrote:
>> 24.09.2016 00:44, Boris Samorodov пишет:
>>> 24.09.2016 00:39, Glen Barber пишет:
>>>> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote:
>>>>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177:
>>>>> In-tree binutils does not support the aarch64 architecture. Install the
>>>>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX.
>>>>
>>>> These lines are relevant.
>>>
>>> Ops. Thank you.
>>
>> The error when aarch64-binutils are installed:
>> -
>> % sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m
>> svn+https -J 8
> 
> Try with 'arm64.aarch64'.

Glen, you've made my day... well, night! It's compiling now.
Thank you!

-- 
WBR, bsam
___
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: should aarch64 cross-build work at amd64?

[Boris Samorodov]

24.09.2016 00:44, Boris Samorodov пишет:
> 24.09.2016 00:39, Glen Barber пишет:
>> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote:
>>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177:
>>> In-tree binutils does not support the aarch64 architecture. Install the
>>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX.
>>
>> These lines are relevant.
> 
> Ops. Thank you.

The error when aarch64-binutils are installed:
-
% sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m
svn+https -J 8
[00:00:00] >> Cross-building ports for arm.aarch64 on amd64 requires
QEMU
[00:00:00] >> Creating HEAD-aarch64 fs... done
[00:00:01] >> Checking out the sources from svn... done
[00:03:41] >> Starting make buildworld with 8 jobs
--- buildworld ---
make[1]: "/poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1" line 146:
SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not
bootstrapping a cross-compiler.
make[1]: "/poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1" line 371:
Unknown target aarch64:arm.
*** [buildworld] Error code 1
-

-- 
WBR, bsam
___
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: should aarch64 cross-build work at amd64?

[Boris Samorodov]

24.09.2016 00:39, Glen Barber пишет:
> On Sat, Sep 24, 2016 at 12:35:30AM +0300, Boris Samorodov wrote:
>> make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177:
>> In-tree binutils does not support the aarch64 architecture. Install the
>> aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX.
> 
> These lines are relevant.

Ops. Thank you.

-- 
WBR, bsam

___
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"

should aarch64 cross-build work at amd64?

[Boris Samorodov]

Hi All!

I've just created an armv6 jail by poudriere at FreeBSD-current-amd64.
It works fine:
---
% poudriere jail -l
JAILNAME   VERSION  ARCH  METHOD   TIMESTAMP
  PATH
HEAD-armv6 12.0-CURRENT r306267 arm.armv6 svn+https2016-09-23
17:38:10 /poudriere/jails/HEAD-armv6
---


Then I tried to create an aarch64 jail which failed. Should it work?

-
% uname -a
FreeBSD bb055.bsnet 12.0-CURRENT FreeBSD 12.0-CURRENT #19 r306268: Fri
Sep 23 20:13:21 MSK 2016 bsam@bb055.bsnet:/usr/obj/usr/src/sys/BB64X
 amd64

% sudo binmiscctl lookup aarch64
name: aarch64
interpreter: /usr/local/bin/qemu-aarch64-static
flags: ENABLED USE_MASK
magic size: 20
magic offset: 0
magic: 0x7f 0x45 0x4c 0x46  0x02 0x01 0x01 0x00  0x00 0x00 0x00 0x00
   0x00 0x00 0x00 0x00  0x02 0x00 0xb7 0x00
mask:  0xff 0xff 0xff 0xff  0xff 0xff 0xff 0x00  0xff 0xff 0xff 0xff
   0xff 0xff 0xff 0xff  0xfe 0xff 0xff 0xff

% sudo poudriere jail -c -j HEAD-aarch64 -a arm.aarch64 -v head -m
svn+https -J 8

[00:00:00] >> Cross-building ports for arm.aarch64 on amd64 requires
QEMU
[00:00:00] >> Creating HEAD-aarch64 fs... done
[00:00:00] >> Checking out the sources from svn... done
[00:03:32] >> Starting make buildworld with 8 jobs
--- buildworld ---
make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 146:
SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not
bootstrapping a cross-compiler.
make[1]: /poudriere/jails/HEAD-aarch64/usr/src/Makefile.inc1 line 177:
In-tree binutils does not support the aarch64 architecture. Install the
aarch64-binutils port or package or set CROSS_BINUTILS_PREFIX.
*** [buildworld] Error code 1

make: stopped in /poudriere/jails/HEAD-aarch64/usr/src
.ERROR_TARGET='buildworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
.CURDIR='/poudriere/jails/HEAD-aarch64/usr/src'
.MAKE='make'
.OBJDIR='/poudriere/jails/HEAD-aarch64/usr/src'
.TARGETS='buildworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/poudriere/jails/HEAD-aarch64/usr/src/share/mk'
MAKE_VERSION='20160818'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/poudriere/jails/HEAD-aarch64/usr/src'
OBJTOP='/poudriere/jails/HEAD-aarch64/usr/src'
1 error

make: stopped in /poudriere/jails/HEAD-aarch64/usr/src
.ERROR_TARGET='buildworld'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
.CURDIR='/poudriere/jails/HEAD-aarch64/usr/src'
.MAKE='make'
.OBJDIR='/poudriere/jails/HEAD-aarch64/usr/src'
.TARGETS='buildworld'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/poudriere/jails/HEAD-aarch64/usr/src/share/mk'
MAKE_VERSION='20160818'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/poudriere/jails/HEAD-aarch64/usr/src'
OBJTOP='/poudriere/jails/HEAD-aarch64/usr/src'
[00:03:32] >> Error: Failed to 'make buildworld'
[00:03:32] >> Error while creating jail, cleaning up.
[00:03:32] >> Removing HEAD-aarch64 jail... done
%
-

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

19.05.16 16:43, Andriy Gapon пишет:
> On 19/05/2016 16:40, Boris Samorodov wrote:
>> 19.05.16 14:04, Andriy Gapon пишет:
>>> On 19/05/2016 13:50, Boris Samorodov wrote:
>>>> 19.05.16 09:28, K. Macy пишет:
>>>>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>>>>> did an IFC to r300176 and boot will hang right ater printing out
>>>>> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
>>>>> shell as hanging in piperead. Diffing between those two revisions I
>>>>> don't see any obvious offenders so I'm hoping that individuals who
>>>>> have committed in the last 24 hours will have some idea of their
>>>>> changes having such an impact.
>>>>
>>>> For me (BIOS boot at DELL notebook) is broken after jump
>>>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>>>> Here is a photo (sorry for the quality):
>>>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>>>
>>>> Boot with r300062 works fine.
>>>
>>> A wild guess (not really), try to revert r300113
>>
>> Tried that, conflict on reverting this single revision and an error
>> compiling kernel. (No more details, sorry, busy at work for now)
>>
> 
> Alexander has committed a fix, so upgrading to the latest version can be a
> better strategy now.

Yep, I've updated the kernel to r300212 and it works.

Thanks all!
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

19.05.16 14:04, Andriy Gapon пишет:
> On 19/05/2016 13:50, Boris Samorodov wrote:
>> 19.05.16 09:28, K. Macy пишет:
>>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>>> did an IFC to r300176 and boot will hang right ater printing out
>>> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
>>> shell as hanging in piperead. Diffing between those two revisions I
>>> don't see any obvious offenders so I'm hoping that individuals who
>>> have committed in the last 24 hours will have some idea of their
>>> changes having such an impact.
>>
>> For me (BIOS boot at DELL notebook) is broken after jump
>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>> Here is a photo (sorry for the quality):
>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>
>> Boot with r300062 works fine.
> 
> A wild guess (not really), try to revert r300113

Tried that, conflict on reverting this single revision and an error
compiling kernel. (No more details, sorry, busy at work for now)

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

19.05.16 14:05, Konstantin Belousov пишет:
> On Thu, May 19, 2016 at 01:50:47PM +0300, Boris Samorodov wrote:
>> 19.05.16 09:28, K. Macy пишет:
>>> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
>>> did an IFC to r300176 and boot will hang right ater printing out
>>> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
>>> shell as hanging in piperead. Diffing between those two revisions I
>>> don't see any obvious offenders so I'm hoping that individuals who
>>> have committed in the last 24 hours will have some idea of their
>>> changes having such an impact.
>>
>> For me (BIOS boot at DELL notebook) is broken after jump
>> from r300062 to r300158. CapsLock works, but ^T shows nothing.
>> Here is a photo (sorry for the quality):
>> ftp://ftp.wart.ru/pub/misc/boot_broken.jpg
>>
>> Boot with r300062 works fine.
> 
> Break into ddb and show the 'ps' command output.

Here are some photoes: ftp://ftp.wart.ru/pub/misc/Boot/
Notes:
1. The third one is none-readable. :-( I'll redo it if needed
(but not right now).
2. The last but one screens are nearly identical (modulo integers)
and were skipped.

BTW, if detach all devices from the notebook (external screen,
wired network, usb extentions) the notebook can boot ones out of
10 times.

HTH
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

19.05.16 09:28, K. Macy пишет:
> I did an IFC on my drm-next-4.6 branch yesterday at r300069. I just
> did an IFC to r300176 and boot will hang right ater printing out
> "setting hostid: ". ^T just shows sh [piperd]. ddb just shows the
> shell as hanging in piperead. Diffing between those two revisions I
> don't see any obvious offenders so I'm hoping that individuals who
> have committed in the last 24 hours will have some idea of their
> changes having such an impact.

For me (BIOS boot at DELL notebook) is broken after jump
from r300062 to r300158. CapsLock works, but ^T shows nothing.
Here is a photo (sorry for the quality):
ftp://ftp.wart.ru/pub/misc/boot_broken.jpg

Boot with r300062 works fine.
-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: extremely slow to get to loader

[Boris Samorodov]

27.04.16 16:30, Allan Jude пишет:
> On April 27, 2016 2:50:13 PM GMT+02:00, Boris Samorodov <b...@passap.ru> 
> wrote:
>> 24.04.16 20:46, Larry Rosenman пишет:
>>> On 2016-04-21 20:56, Johannes Dieterich wrote:
>>>> On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude <allanj...@freebsd.org>
>>>> wrote:
>>>>> On 2016-04-21 10:46, Johannes Dieterich wrote:
>>>>>> Dear all,
>>>>>>
>>>>>> with r298385, I observe extremely long times from turning on my
>> laptop
>>>>>> to reach loader. This is a regression compared to a roughly 1 week
>> old
>>>>>> CURRENT.
>>>>>>
>>>>>> This is an AMD A12-8800B laptop booting in legacy mode into a
>>>>>> ZFS+GELI setup.
>>>>>>
>>>>>> Please let me know how I can help to solve this issue.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Johannes
>>>>>> ___
>>>>>> 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"
>>>>>>
>>>>>
>>>>> Can you describe where exactly it is slow?
>>>> Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes
>>>> before it eventually continues.
>>>>
>>>>> Once you get to the loader menu (the beastie menu), can you choose
>> the
>>>>> option to go to the loader prompt, and type:
>>>>> bcachestat
>>>>>
>>>>> And provide the output of that.
>>>> Here we go (w/o mistakes I hope...):
>>>> cache blocks: 32768
>>>> cache blocksz: 572
>>>> unit cache blocks: 32768
>>>> cached units: 1
>>>> 1162 ops 0 bypasses 12109 hits 739 misses
>>>>
>>>> Thanks so much for the response!
>>>>
>>>> Johannes
>>> I'm seeing similar, PLUS the kernel seems(!) to not continue on to
>> the
>>> RC scripts
>>> after mount root.
>>>
>>> (BIOS BOOT).
>>>
>>> I reverted to an older kernel and boot block and zfsloader to get up.
>>>
>>>
>> Seems, I'm at the same boat. The system is a remote Supermicro server:
>> --- ping after reboot ---
>> % ping -i 60 srv
>> PING srv (X.X.X.X): 56 data bytes
>> 64 bytes from X.X.X.X: icmp_seq=0 ttl=59 time=2.526 ms
>> 64 bytes from X.X.X.X: icmp_seq=14 ttl=59 time=2.735 ms
>> --- dmesg messages ---
>> [...]
>> Apr 27 14:59:34 srv shutdown: reboot by bsam:
>> Apr 27 14:59:35 srv kernel: .
>> Apr 27 14:59:56 srv syslogd: exiting on signal 15
>> Apr 27 15:12:33 srv syslogd: kernel boot file is /boot/kernel/kernel
>> Apr 27 15:12:33 srv kernel: Copyright (c) 1992-2016 The FreeBSD
>> Project.
>> Apr 27 15:12:33 srv kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
>> 1989, 1991, 1992, 1993, 1994
>> Apr 27 15:12:33 srv kernel: The Regents of the University of
>> California.
>> All rights reserved.
>> Apr 27 15:12:33 srv kernel: FreeBSD is a registered trademark of The
>> FreeBSD Foundation.
>> Apr 27 15:12:33 srv kernel: FreeBSD 11.0-CURRENT #41 r298696: Wed Apr
>> 27
>> 14:50:53 MSK 2016
>> [...]
>> --
>>
>> This is a zfs-root system with geli-enabled swap partitions.
>> Other than boot the system seem to be fine.
> 
> Please try https://reviews.freebsd.org/D6109 and see if it fixes the problem.

Yep, fixed. Thank you!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: no smtp service after upgrade

[Boris Samorodov]

27.04.16 17:08, Chagin Dmitry пишет:
> On Wed, Apr 27, 2016 at 04:34:29PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> There is no smtp service after recent update:
>> -
>> % sockstat -4l
>> USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN
>> ADDRESS
>> root sshd   879   4  tcp4   *:22  *:*
>> root syslogd663   7  udp4   *:514 *:*
>> -
>>
>> I use (almost) default mail configuration.
>> -
>> % grep mail /etc/rc.conf{,.local}
>> %
>> -
>>
>> I've notice a huge etc updates at update. Seems they may be related.
>>
> the same here, chmod +x /etc/rc.d/sendmail 

Yep. Thanks!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

no smtp service after upgrade

[Boris Samorodov]

Hi All,

There is no smtp service after recent update:
-
% sockstat -4l
USER COMMANDPID   FD PROTO  LOCAL ADDRESS FOREIGN
ADDRESS
root sshd   879   4  tcp4   *:22  *:*
root syslogd663   7  udp4   *:514 *:*
-

I use (almost) default mail configuration.
-
% grep mail /etc/rc.conf{,.local}
%
-

I've notice a huge etc updates at update. Seems they may be related.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: extremely slow to get to loader

[Boris Samorodov]

24.04.16 20:46, Larry Rosenman пишет:
> On 2016-04-21 20:56, Johannes Dieterich wrote:
>> On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude <allanj...@freebsd.org>
>> wrote:
>>> On 2016-04-21 10:46, Johannes Dieterich wrote:
>>>> Dear all,
>>>>
>>>> with r298385, I observe extremely long times from turning on my laptop
>>>> to reach loader. This is a regression compared to a roughly 1 week old
>>>> CURRENT.
>>>>
>>>> This is an AMD A12-8800B laptop booting in legacy mode into a
>>>> ZFS+GELI setup.
>>>>
>>>> Please let me know how I can help to solve this issue.
>>>>
>>>> Thanks,
>>>>
>>>> Johannes
>>>> ___
>>>> 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"
>>>>
>>>
>>> Can you describe where exactly it is slow?
>> Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes
>> before it eventually continues.
>>
>>> Once you get to the loader menu (the beastie menu), can you choose the
>>> option to go to the loader prompt, and type:
>>> bcachestat
>>>
>>> And provide the output of that.
>> Here we go (w/o mistakes I hope...):
>> cache blocks: 32768
>> cache blocksz: 572
>> unit cache blocks: 32768
>> cached units: 1
>> 1162 ops 0 bypasses 12109 hits 739 misses
>>
>> Thanks so much for the response!
>>
>> Johannes
> I'm seeing similar, PLUS the kernel seems(!) to not continue on to the
> RC scripts
> after mount root.
> 
> (BIOS BOOT).
> 
> I reverted to an older kernel and boot block and zfsloader to get up.
> 
> 
Seems, I'm at the same boat. The system is a remote Supermicro server:
--- ping after reboot ---
% ping -i 60 srv
PING srv (X.X.X.X): 56 data bytes
64 bytes from X.X.X.X: icmp_seq=0 ttl=59 time=2.526 ms
64 bytes from X.X.X.X: icmp_seq=14 ttl=59 time=2.735 ms
--- dmesg messages ---
[...]
Apr 27 14:59:34 srv shutdown: reboot by bsam:
Apr 27 14:59:35 srv kernel: .
Apr 27 14:59:56 srv syslogd: exiting on signal 15
Apr 27 15:12:33 srv syslogd: kernel boot file is /boot/kernel/kernel
Apr 27 15:12:33 srv kernel: Copyright (c) 1992-2016 The FreeBSD Project.
Apr 27 15:12:33 srv kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
Apr 27 15:12:33 srv kernel: The Regents of the University of California.
All rights reserved.
Apr 27 15:12:33 srv kernel: FreeBSD is a registered trademark of The
FreeBSD Foundation.
Apr 27 15:12:33 srv kernel: FreeBSD 11.0-CURRENT #41 r298696: Wed Apr 27
14:50:53 MSK 2016
[...]
--

This is a zfs-root system with geli-enabled swap partitions.
Other than boot the system seem to be fine.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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"

11.0-CURRENT-amd64 r293444: bhyveload => Segmentation fault

[Boris Samorodov]

Hi All,

Bhyve works with virtual machines which have already been created,
but can not create new ones:
-
# bhyveload -m 4G -d
/vm/.iso/FreeBSD-11.0-CURRENT-amd64-20151130-r291495-disc1.iso test


Consoles: userboot

FreeBSD/amd64 User boot, Revision 1.1
(bsam@sm.bsnet, Sat Jan  9 02:04:09 MSK 2016)
Segmentation fault (core dumped)
-

Any help is appreciated.
Thank you.

-- 
WBR, bsam
___
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: 11.0-CURRENT-amd64 r293444: bhyveload => Segmentation fault

[Boris Samorodov]

10.01.16 00:39, Allan Jude пишет:
> On 2016-01-09 16:20, Boris Samorodov wrote:
>> 09.01.16 23:51, Allan Jude пишет:
>>> On 2016-01-09 15:48, Boris Samorodov wrote:
>>>> Hi All,
>>>>
>>>> Bhyve works with virtual machines which have already been created,
>>>> but can not create new ones:
>>>> -
>>>> # bhyveload -m 4G -d
>>>> /vm/.iso/FreeBSD-11.0-CURRENT-amd64-20151130-r291495-disc1.iso test
>>>>
>>>>
>>>> Consoles: userboot
>>>>
>>>> FreeBSD/amd64 User boot, Revision 1.1
>>>> (bsam@sm.bsnet, Sat Jan  9 02:04:09 MSK 2016)
>>>> Segmentation fault (core dumped)
>>>> -
>>>>
>>>> Any help is appreciated.
>>>> Thank you.
>>>>
>>>
>>> This was a but I accidentally introduced during the ZFS boot environment
>>> work. It has been fixed in head already, just update and rebuild
>>> sys/boot/userboot
>>
>> Great, thank you!
>>
>> Quick "svn up /usr/src && cd /sys/boot/userboot && make && sudo make
>> install" didn't help, but backtrace of core has changed. I'll try a
>> full rebuild.
> 
> Can you provide the backtrace?

I've landed the machine to another person/task. After it finishes it
will auto-refresh the world. If core is reproduced, I'll send it to you.

Thank you for you help and fast responses!

-- 
WBR, bsam
___
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: 11.0-CURRENT-amd64 r293444: bhyveload => Segmentation fault

[Boris Samorodov]

09.01.16 23:51, Allan Jude пишет:
> On 2016-01-09 15:48, Boris Samorodov wrote:
>> Hi All,
>>
>> Bhyve works with virtual machines which have already been created,
>> but can not create new ones:
>> -
>> # bhyveload -m 4G -d
>> /vm/.iso/FreeBSD-11.0-CURRENT-amd64-20151130-r291495-disc1.iso test
>>
>>
>> Consoles: userboot
>>
>> FreeBSD/amd64 User boot, Revision 1.1
>> (bsam@sm.bsnet, Sat Jan  9 02:04:09 MSK 2016)
>> Segmentation fault (core dumped)
>> -
>>
>> Any help is appreciated.
>> Thank you.
>>
> 
> This was a but I accidentally introduced during the ZFS boot environment
> work. It has been fixed in head already, just update and rebuild
> sys/boot/userboot

Great, thank you!

Quick "svn up /usr/src && cd /sys/boot/userboot && make && sudo make
install" didn't help, but backtrace of core has changed. I'll try a
full rebuild.

-- 
WBR, bsam
___
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: 11.0-CURRENT-amd64 r293444: bhyveload => Segmentation fault

[Boris Samorodov]

10.01.16 01:07, Boris Samorodov пишет:
> 10.01.16 00:39, Allan Jude пишет:
>> On 2016-01-09 16:20, Boris Samorodov wrote:
>>> 09.01.16 23:51, Allan Jude пишет:
>>>> On 2016-01-09 15:48, Boris Samorodov wrote:
>>>>> Hi All,
>>>>>
>>>>> Bhyve works with virtual machines which have already been created,
>>>>> but can not create new ones:
>>>>> -
>>>>> # bhyveload -m 4G -d
>>>>> /vm/.iso/FreeBSD-11.0-CURRENT-amd64-20151130-r291495-disc1.iso test
>>>>>
>>>>>
>>>>> Consoles: userboot
>>>>>
>>>>> FreeBSD/amd64 User boot, Revision 1.1
>>>>> (bsam@sm.bsnet, Sat Jan  9 02:04:09 MSK 2016)
>>>>> Segmentation fault (core dumped)
>>>>> -
>>>>>
>>>>> Any help is appreciated.
>>>>> Thank you.
>>>>>
>>>>
>>>> This was a but I accidentally introduced during the ZFS boot environment
>>>> work. It has been fixed in head already, just update and rebuild
>>>> sys/boot/userboot
>>>
>>> Great, thank you!
>>>
>>> Quick "svn up /usr/src && cd /sys/boot/userboot && make && sudo make
>>> install" didn't help, but backtrace of core has changed. I'll try a
>>> full rebuild.
>>
>> Can you provide the backtrace?
> 
> I've landed the machine to another person/task. After it finishes it
> will auto-refresh the world. If core is reproduced, I'll send it to you.

OK, I reproduced the core. It was my fault: vm-bhyve install command
should be used with just the name of the iso. While I tried to use the
absolute path and got a core.

> Thank you for you help and fast responses!

-- 
WBR, bsam
___
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: Panic while waiting on wlan0

[Boris Samorodov]

Hi!,

23.11.15 01:38, Adrian Chadd пишет:
> hi,
> 
> iwm needs a maintainer and a lot of work. :)

Agreed. :-)

WTB, I've just upgraded to r291221 and this seems to fix those problems.

> On 22 November 2015 at 13:46, Boris Samorodov <b...@passap.ru> wrote:
>> 22.11.15 22:54, Sergey Manucharian пишет:
>>>> On 22 November 2015 at 04:31, Florian Limberger
>>>> <f...@snakeoilproductions.net> wrote:
>>>>> On 17.11.15 17:42, Adrian Chadd wrote:
>>>>>>
>>>>>> try updating to head as of today. Some callout issues were fixed.
>>>>>
>>>>> The crashes are fixed alright, thank you.  I still have a rather difficult
>>>>> to reproduce issue, where the wpa_supplicant hangs in SCANNING state
>>>>> indefinitely, even if the Notebook is very near to the AP.  I’ve had this
>>>>> issue occasionally before, but since the crashes started it has become 
>>>>> more
>>>>> frequent.  Is there anything I can do to debug the behaviour?  Until now I
>>>>> have only observed it in wpa_supplicant and have no idea how I might
>>>>> proceed.
>>>>>
>>>> Excerpts from Adrian Chadd's message from Sun 22-Nov-15 08:52:
>>>>
>>>> Do this:
>>>>
>>>> * compile in IEEE80211_DEBUG;
>>>> * do "wlandebug +scan"
>>>>
>>>> That way we can see if net80211 is refusing to continue scanning.
>>>
>>> I have a similar well-reproducable crash on my ThinkPad with "iwn"
>>> driver and "iwn6000fw" when I try to restart wlan:
>>>
>>>  # service netif restart
>>>
>>> Otherwise it works fine, no problem at all.
>>
>> After upgrade from FreeBSD-amd64-HEAD-r290730 to r291148 I've got a
>> panic with wlan0 (iwm though):
>> ftp://ftp.wart.ru/pub/misc/panic-iwn-1.jpg
>> ftp://ftp.wart.ru/pub/misc/panic-iwn-2.jpg
>>
>> % kldstat | grep iwm
>> 121 0x822c5000 21a18if_iwm.ko
>> 131 0x822e7000 ab9e0iwm7265fw.ko

--
WBR, bsam
___
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: Panic while waiting on wlan0

[Boris Samorodov]

22.11.15 22:54, Sergey Manucharian пишет:
>> On 22 November 2015 at 04:31, Florian Limberger
>>  wrote:
>>> On 17.11.15 17:42, Adrian Chadd wrote:

 try updating to head as of today. Some callout issues were fixed.
>>>
>>> The crashes are fixed alright, thank you.  I still have a rather difficult
>>> to reproduce issue, where the wpa_supplicant hangs in SCANNING state
>>> indefinitely, even if the Notebook is very near to the AP.  I’ve had this
>>> issue occasionally before, but since the crashes started it has become more
>>> frequent.  Is there anything I can do to debug the behaviour?  Until now I
>>> have only observed it in wpa_supplicant and have no idea how I might
>>> proceed.
>>>
>> Excerpts from Adrian Chadd's message from Sun 22-Nov-15 08:52:
>>
>> Do this:
>>
>> * compile in IEEE80211_DEBUG;
>> * do "wlandebug +scan"
>>
>> That way we can see if net80211 is refusing to continue scanning.
> 
> I have a similar well-reproducable crash on my ThinkPad with "iwn"
> driver and "iwn6000fw" when I try to restart wlan:
>  
>  # service netif restart
> 
> Otherwise it works fine, no problem at all.

After upgrade from FreeBSD-amd64-HEAD-r290730 to r291148 I've got a
panic with wlan0 (iwm though):
ftp://ftp.wart.ru/pub/misc/panic-iwn-1.jpg
ftp://ftp.wart.ru/pub/misc/panic-iwn-2.jpg

% kldstat | grep iwm
121 0x822c5000 21a18if_iwm.ko
131 0x822e7000 ab9e0iwm7265fw.ko

-- 
WBR, bsam
___
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: 11.0-CURRENT r290273: installer fails with "out of swap space" error

[Boris Samorodov]

03.11.2015 23:50, Maxim Pugachev пишет:

> I tried to install r29273 into Parallels VM, but got an error on
> "distextract" stage. Here is the last messages from bsdinstall_log:
> 
> DEBUG: f_debug_init: ARGV=[distextract] GETOPTS_STDARGS=[dD:]
> DEBUG: f_debug_init: debug=[1] debugFile=[/tmp/bsdinstall_log]
> DEBUG: Running installation step: distextract
> Killed
> 
> Last message from /var/log/messages:
> 
> Nov  3 20:02:9  kernel: pid 967 (distextract), uid 0, was killed: out
> of swap space
> 
> My VM has 2 gigs of memory, vmstat tells that I have ~537M free
> (swapinfo tells nothing). I dunno is it a bug or I'm doing something
> wrong.

I've also come across with this recently.

Don't remember all the details, something like this:
. install CURRENT to bhyve using 1G memory, get out of swap error;
. set 2G memory, got the same error, didn't try more memory (seemed
  not sane to).

Took a look at the boot environment and found out that something was
wrong (with the filesystem). Unfortunately, I do not recall now what
was it. :-( Something like too small /tmp, no /tmp at all, something
else...

But definitely the error message was misleading and not the case of
the failure.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [HEADSUP] OpenSSL updated to 1.0.2d

[Boris Samorodov]

02.11.2015 06:05, Jason Unovitch пишет:
> On Nov 1, 2015 10:06 AM, "Boris Samorodov" <b...@passap.ru> wrote:
>> 30.10.2015 23:57, Jung-uk Kim пишет:
>>
>>> OpenSSL on head has been updated to 1.0.2d.  Please make sure to
>>> recompile all binaries depending on libcrypto.so.7 or libssl.so.7.
>>
>> Great, thanks!
>>
>> How do those who use FreeBSD official packages supposed to upgrade
>> packages?
> 
> This is on head so it should be the same process as any other source based
> upgrade per the handbook.
> 
> https:// <https://www.freebsd.org/doc/handbook/makeworld.html>
> www.freebsd.org <https://www.freebsd.org/doc/handbook/makeworld.html>
> /doc/handbook/ <https://www.freebsd.org/doc/handbook/makeworld.html>
> makeworld.html <https://www.freebsd.org/doc/handbook/makeworld.html>
> 
> The 'make delete-old-libs' step would have to wait until after the official
> 11-CURRENT package builders have been updated to a revision after this
> change and a 'pkg upgrade' installs everything from that build.

Jason, thanks. Seems that "pkg upgrade -f" should DTRT.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: [HEADSUP] OpenSSL updated to 1.0.2d

[Boris Samorodov]

30.10.2015 23:57, Jung-uk Kim пишет:

> OpenSSL on head has been updated to 1.0.2d.  Please make sure to
> recompile all binaries depending on libcrypto.so.7 or libssl.so.7.

Great, thanks!

How do those who use FreeBSD official packages supposed to upgrade
packages?

-- 
WBR, bsam
___
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: upgrading current - graphics bug

[Boris Samorodov]

07.03.2015 19:07, David S пишет:
 FWIW the nVidia driver docs indicate that you should
 comment, or remove the reference to dri in xorg.conf
 #Load  dri
 but that dri2 is fine. Don't know that that has anything to
 do with your issue. But thought I'd mention it FWIW.
 
 thanks, i missed that part. i took it out of xorg.conf and will see 
 next time i upgrade if it helps.

I'm not sure why this step is recommended, because dri is auto-loaded
anyway:
-
[41.540] (II) LoadModule: dri
[41.541] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so
[41.569] (II) Module dri: vendor=X.Org Foundation
[41.569]compiled for 1.12.4, module version = 1.0.0
[41.569]ABI class: X.Org Server Extension, version 6.0
[41.569] (II) Loading extension XFree86-DRI
[41.569] (II) LoadModule: dri2
[41.570] (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so
[41.582] (II) Module dri2: vendor=X.Org Foundation
[41.582]compiled for 1.12.4, module version = 1.2.0
[41.582]ABI class: X.Org Server Extension, version 6.0
[41.582] (II) Loading extension DRI2
[41.582] (II) LoadModule: nvidia
[41.582] (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so
[41.720] (II) Module nvidia: vendor=NVIDIA Corporation
[41.720]compiled for 4.0.2, module version = 1.0.0
[41.720]Module class: X.Org Video Driver
[41.818] (II) NVIDIA dlloader X Driver  304.123  Wed Jul  2 10:50:21
PDT 2014
-

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: make installworld commands used to generate manifest for makefs?

[Boris Samorodov]

06.09.2014 09:51, Kevin Oberman пишет:
 On Thu, Sep 4, 2014 at 8:36 AM, Boris Samorodov b...@passap.ru wrote:
 
 03.09.2014 21:01, Nenhum_de_Nos пишет:


 On September 3, 2014 12:02:24 PM GMT-03:00, Boris Samorodov 
 b...@passap.ru wrote:
 28.08.2014 23:02, Craig Rodrigues пишет:

 I did this:

 make -DDB_FROM_SRC -DNO_ROOT installkernel DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT installworld DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT distribution DESTDIR=/tmp/test4

 /tmp/test4/METALOG was created, but it did not seem to have
 /boot/kernel/kernel or
 any kernel modules.  Is that expected?

 For a new installation installworld should be done first (it creates
 the needed directory infrastructure). And then one may do
 installkernel.

 As I read from so much time ago to install first kernel, starting from
 which FreeBSD version I should change?

 It seems to be true for ages. Take a look at /usr/src/Makefile,
 section To cross-install current onto a separate partition.

 --
 WBR, Boris Samorodov (bsam)
 FreeBSD Committer, http://www.FreeBSD.org The Power To Serve

 
 Please understand that this is true when doing a cross-install where a
 system with the required directory structure to install a kernel is not yet
 present.

Sure. It was the case for the OP.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: make installworld commands used to generate manifest for makefs?

[Boris Samorodov]

03.09.2014 21:01, Nenhum_de_Nos пишет:
 
 
 On September 3, 2014 12:02:24 PM GMT-03:00, Boris Samorodov b...@passap.ru 
 wrote:
 28.08.2014 23:02, Craig Rodrigues пишет:

 I did this:

 make -DDB_FROM_SRC -DNO_ROOT installkernel DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT installworld DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT distribution DESTDIR=/tmp/test4

 /tmp/test4/METALOG was created, but it did not seem to have
 /boot/kernel/kernel or
 any kernel modules.  Is that expected?

 For a new installation installworld should be done first (it creates
 the needed directory infrastructure). And then one may do
 installkernel.
 
 As I read from so much time ago to install first kernel, starting from which 
 FreeBSD version I should change? 

It seems to be true for ages. Take a look at /usr/src/Makefile,
section To cross-install current onto a separate partition.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: make installworld commands used to generate manifest for makefs?

[Boris Samorodov]

28.08.2014 23:02, Craig Rodrigues пишет:

 I did this:
 
 make -DDB_FROM_SRC -DNO_ROOT installkernel DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT installworld DESTDIR=/tmp/test4
 make -DDB_FROM_SRC -DNO_ROOT distribution DESTDIR=/tmp/test4
 
 /tmp/test4/METALOG was created, but it did not seem to have
 /boot/kernel/kernel or
 any kernel modules.  Is that expected?

For a new installation installworld should be done first (it creates
the needed directory infrastructure). And then one may do
installkernel.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [make xdev, libatf]: error: cstdarg: No such file or directory

[Boris Samorodov]

Hi Sean, All,

Sean, thanks for your help.

25.07.2014 22:00, Sean Bruno пишет:
 On Fri, 2014-07-25 at 20:40 +0400, Boris Samorodov wrote:

 Here are errors I get with sources at r269089.

 I am at 269090.  make xdev TARGET=mips TARGET_ARCH=mips64 just finished
 for me.  At this point, drop the rest of the options from the build as
 dim, bsdimp and sjg have fixed most of the issues requiring that.

Uboot (at least the version supported by crochet) needs gcc to build.

 There is a fatal depend bug of some kind occuring if /usr/obj/ has
 builds in it.  Try removing /usr/obj/* and then build again.

That didn't help, the same error.

And a discussion at arm@ ML shows that there are problems with xdev gcc
build at recent HEAD.

 -
 % uname -a
 FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed
 Jul 23 23:24:47 SAMT 2014
 bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X  amd64

 % sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1
 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1
 WITHOUT_CLANG_IS_CC=1 xdev
 [...]
 === lib/atf (obj,depend,all,install)
 === lib/atf/libatf-c (obj)
 === lib/atf/libatf-c++ (obj)
 === lib/atf/libatf-c (depend)
 === lib/atf/libatf-c++ (depend)
 rm -f .depend
 CC='cc -isystem //usr/armv6-freebsd/usr/include
 -L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-freebsd/
 -B//usr/armv6-fr
 eebsd/usr/libexec  -B//usr/armv6-freebsd/usr/bin
 -B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a-DHAVE_CONFIG_H
 -DATF_A
 RCH='arm' -DATF_BUILD_CC='cc -isystem //usr/armv6-freebsd/usr/include
 -L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-
 freebsd/ -B//usr/armv6-freebsd/usr/libexec
 -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
 -DATF_BUILD_CFLAGS='
 -O -pipe  ' -DATF_BUILD_CPP='cpp -isystem
 //usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib
 --sysroot=//usr/ar
 mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec
 -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
 -DATF_BUILD_CPPF
 LAGS='' -DATF_BUILD_CXX='c++ -isystem //usr/armv6-freebsd/usr/include
 -L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-
 freebsd/ -B//usr/armv6-freebsd/usr/libexec
 -B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
 -DATF_BUILD_CXXFLAGS
 ='-O -pipe  ' -DATF_CONFDIR='/etc/atf'
 -DATF_C_TESTS_BASE='/usr/tests/lib/atf/libatf-c'
 -DATF_INCLUDEDIR='/usr/include
 ' -DATF_LIBDIR='/usr/lib' -DATF_LIBEXECDIR='/usr/libexec'
 -DATF_MACHINE='armv6' -DATF_M4='/usr/bin/m4' -DATF_PKGDATADI
 R='/usr/share/atf' -DATF_SHELL='/bin/sh' -DATF_WORKDIR='/tmp'
 -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li
 batf-c -I. -DHAVE_CONFIG_H
 /usr/src/contrib/atf/atf-c++/detail/application.cpp
 /usr/src/contrib/atf/atf-c++/build.cpp /
 usr/src/contrib/atf/atf-c++/check.cpp
 /usr/src/contrib/atf/atf-c++/config.cpp
 /usr/src/contrib/atf/atf-c++/detail/env.cpp /usr
 /src/contrib/atf/atf-c++/detail/exceptions.cpp
 /usr/src/contrib/atf/atf-c++/detail/fs.cpp
 /usr/src/contrib/atf/atf-c++/detail/
 process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp
 /usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u
 tils.cpp
 /usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error:
 cstdarg: No such file or directory
 /usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error:
 cstdio: No such file or directory
 /usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error:
 cstdlib: No such file or directory
 [...]
 -

 
 


-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

[make xdev, libatf]: error: cstdarg: No such file or directory

[Boris Samorodov]

Hi All!

Here are errors I get with sources at r269089.

-
% uname -a
FreeBSD bb052.bsnet 11.0-CURRENT FreeBSD 11.0-CURRENT #113 r269019: Wed
Jul 23 23:24:47 SAMT 2014
bsam@bb052.bsnet:/usr/obj/usr/src/sys/BB64X  amd64

% sudo make -C /usr/src TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1
WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1
WITHOUT_CLANG_IS_CC=1 xdev
[...]
=== lib/atf (obj,depend,all,install)
=== lib/atf/libatf-c (obj)
=== lib/atf/libatf-c++ (obj)
=== lib/atf/libatf-c (depend)
=== lib/atf/libatf-c++ (depend)
rm -f .depend
CC='cc -isystem //usr/armv6-freebsd/usr/include
-L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-freebsd/
-B//usr/armv6-fr
eebsd/usr/libexec  -B//usr/armv6-freebsd/usr/bin
-B//usr/armv6-freebsd/usr/lib' mkdep -f .depend -a-DHAVE_CONFIG_H
-DATF_A
RCH='arm' -DATF_BUILD_CC='cc -isystem //usr/armv6-freebsd/usr/include
-L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-
freebsd/ -B//usr/armv6-freebsd/usr/libexec
-B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
-DATF_BUILD_CFLAGS='
-O -pipe  ' -DATF_BUILD_CPP='cpp -isystem
//usr/armv6-freebsd/usr/include -L//usr/armv6-freebsd/usr/lib
--sysroot=//usr/ar
mv6-freebsd/ -B//usr/armv6-freebsd/usr/libexec
-B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
-DATF_BUILD_CPPF
LAGS='' -DATF_BUILD_CXX='c++ -isystem //usr/armv6-freebsd/usr/include
-L//usr/armv6-freebsd/usr/lib  --sysroot=//usr/armv6-
freebsd/ -B//usr/armv6-freebsd/usr/libexec
-B//usr/armv6-freebsd/usr/bin -B//usr/armv6-freebsd/usr/lib'
-DATF_BUILD_CXXFLAGS
='-O -pipe  ' -DATF_CONFDIR='/etc/atf'
-DATF_C_TESTS_BASE='/usr/tests/lib/atf/libatf-c'
-DATF_INCLUDEDIR='/usr/include
' -DATF_LIBDIR='/usr/lib' -DATF_LIBEXECDIR='/usr/libexec'
-DATF_MACHINE='armv6' -DATF_M4='/usr/bin/m4' -DATF_PKGDATADI
R='/usr/share/atf' -DATF_SHELL='/bin/sh' -DATF_WORKDIR='/tmp'
-I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../li
batf-c -I. -DHAVE_CONFIG_H
/usr/src/contrib/atf/atf-c++/detail/application.cpp
/usr/src/contrib/atf/atf-c++/build.cpp /
usr/src/contrib/atf/atf-c++/check.cpp
/usr/src/contrib/atf/atf-c++/config.cpp
/usr/src/contrib/atf/atf-c++/detail/env.cpp /usr
/src/contrib/atf/atf-c++/detail/exceptions.cpp
/usr/src/contrib/atf/atf-c++/detail/fs.cpp
/usr/src/contrib/atf/atf-c++/detail/
process.cpp /usr/src/contrib/atf/atf-c++/tests.cpp
/usr/src/contrib/atf/atf-c++/detail/text.cpp /usr/src/contrib/atf/atf-c++/u
tils.cpp
/usr/src/contrib/atf/atf-c++/detail/application.cpp:38:19: error:
cstdarg: No such file or directory
/usr/src/contrib/atf/atf-c++/detail/application.cpp:39:18: error:
cstdio: No such file or directory
/usr/src/contrib/atf/atf-c++/detail/application.cpp:40:19: error:
cstdlib: No such file or directory
[...]
-

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

ATTN: [zfs boot]: ZFS: unsupported compression algorithm 15

[Boris Samorodov]

Hi All,

Just FIY since nothing relevant was found at google.

I was upgrading my CURRENT system to rev r268233 from a one-or-two
weeks old system. The system was created years ago and had rather
old zfsboot code. So, after upgrading and rebooting I got the error
right after BIOS POST...:
-
ZFS: unsupported compression algorithm 15
-

... and instant reboot.

OK, I've booted from a USB stick, run the command (the system in
question is at /dev/ada1 and the system at USB stick is rather new
CURRENT also):
-
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
-

Now my system is fine again:
-
% uname -a

FreeBSD bsam.int.wart.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #73 r268233:
Fri Jul  4 06:41:28 SAMT 2014
b...@bsam.int.wart.ru:/usr/obj/usr/src/sys/BB64X  amd64
-

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ATTN: [zfs boot]: ZFS: unsupported compression algorithm 15

[Boris Samorodov]

08.07.2014 19:25, Allan Jude пишет:
 On 07/08/2014 10:47, Boris Samorodov wrote:
 Hi All,

 Just FIY since nothing relevant was found at google.

 I was upgrading my CURRENT system to rev r268233 from a one-or-two
 weeks old system. The system was created years ago and had rather
 old zfsboot code. So, after upgrading and rebooting I got the error
 right after BIOS POST...:
 -
 ZFS: unsupported compression algorithm 15
 -

 ... and instant reboot.

 OK, I've booted from a USB stick, run the command (the system in
 question is at /dev/ada1 and the system at USB stick is rather new
 CURRENT also):
 -
 # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
 -

 Now my system is fine again:
 -
 % uname -a

 FreeBSD bsam.int.wart.ru 11.0-CURRENT FreeBSD 11.0-CURRENT #73 r268233:
 Fri Jul  4 06:41:28 SAMT 2014
 b...@bsam.int.wart.ru:/usr/obj/usr/src/sys/BB64X  amd64
 -

 
 Did you do a 'zpool upgrade' when you updated your system? The new
 features shouldn't be enabled without you having done that.

Nope. My commands (from remote console):
-
# make -C /usr/src installkernel
# make -C /usr/src installworld
# mergemaster
# make -C /usr/src delete-old
# make -C /usr/src delete-old-libs
# shutdown -r now  exit
BOOM!
-

 When you DO 'zpool upgrade' it specifically warns you to update the boot
 code for this reason.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [arm cross-compiling, clang] Error: selected processor does not support `ldrexd r2,r3,[r1]'

[Boris Samorodov]

19.05.2014 01:25, Ian Lepore пишет:
 On Mon, 2014-05-19 at 00:08 +0400, Boris Samorodov wrote:

 It's definitely not my day -- crochet build failed with:
 -
 --- all_subdir_libllvmarmcodegen ---
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15:
 error: no member named
  'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64TPseudoWB_fixed'?
 case ARM::VLD1d64TPseudoWB_fixed:
  ~^~
   VST1d64TPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here
 VST1d64TPseudoWB_fixed  = 1953,
 ^
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15:
 error: no member named
  'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64QPseudoWB_fixed'?
 case ARM::VLD1d64QPseudoWB_fixed:
  ~^~
   VST1d64QPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here
 VST1d64QPseudoWB_fixed  = 1947,
 -
 
 I've seen others report this error recently, and it was caused by an
 update to clang.  There's a dependency glitch so that some header files
 don't get regenerated correctly; I think that has been fixed, but to get
 the fix in place you have to clean out obj/arm.armv6 and build fresh.

Ian, thanks -- that helped!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [arm cross-compiling, clang] Error: selected processor does not support `ldrexd r2,r3,[r1]'

[Boris Samorodov]

19.05.2014 16:06, Boris Samorodov пишет:
 19.05.2014 01:25, Ian Lepore пишет:
 On Mon, 2014-05-19 at 00:08 +0400, Boris Samorodov wrote:
 
 It's definitely not my day -- crochet build failed with:
 -
 --- all_subdir_libllvmarmcodegen ---
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15:
 error: no member named
  'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64TPseudoWB_fixed'?
 case ARM::VLD1d64TPseudoWB_fixed:
  ~^~
   VST1d64TPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared here
 VST1d64TPseudoWB_fixed  = 1953,
 ^
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15:
 error: no member named
  'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64QPseudoWB_fixed'?
 case ARM::VLD1d64QPseudoWB_fixed:
  ~^~
   VST1d64QPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared here
 VST1d64QPseudoWB_fixed  = 1947,
 -

 I've seen others report this error recently, and it was caused by an
 update to clang.  There's a dependency glitch so that some header files
 don't get regenerated correctly; I think that has been fixed, but to get
 the fix in place you have to clean out obj/arm.armv6 and build fresh.
 
 Ian, thanks -- that helped!

Just a note: (crochet) buildworld finished successfully. However
buildkernel fails at the very beginning with Malformed conditional
(${MK_ARM_EABI} != no) -- just as Michael Tuexen reported at arm@.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [arm cross-compiling, clang] Error: selected processor does not support `ldrexd r2, r3, [r1]'

[Boris Samorodov]

19.05.2014 19:59, Warner Losh пишет:
 
 On May 19, 2014, at 6:57 AM, Boris Samorodov b...@passap.ru wrote:
 
 19.05.2014 16:06, Boris Samorodov пишет:
 19.05.2014 01:25, Ian Lepore пишет:
 On Mon, 2014-05-19 at 00:08 +0400, Boris Samorodov wrote:

 It's definitely not my day -- crochet build failed with:
 -
 --- all_subdir_libllvmarmcodegen ---
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3687:15:
 error: no member named
 'VLD1d64TPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64TPseudoWB_fixed'?
case ARM::VLD1d64TPseudoWB_fixed:
 ~^~
  VST1d64TPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1969:5: note: 'VST1d64TPseudoWB_fixed' declared 
 here
VST1d64TPseudoWB_fixed  = 1953,
^
 /usr/src/lib/clang/libllvmarmcodegen/../../../contrib/llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:3704:15:
 error: no member named
 'VLD1d64QPseudoWB_fixed' in namespace 'llvm::ARM'; did you mean
 'VST1d64QPseudoWB_fixed'?
case ARM::VLD1d64QPseudoWB_fixed:
 ~^~
  VST1d64QPseudoWB_fixed
 ./ARMGenInstrInfo.inc.h:1963:5: note: 'VST1d64QPseudoWB_fixed' declared 
 here
VST1d64QPseudoWB_fixed  = 1947,
 -

 I've seen others report this error recently, and it was caused by an
 update to clang.  There's a dependency glitch so that some header files
 don't get regenerated correctly; I think that has been fixed, but to get
 the fix in place you have to clean out obj/arm.armv6 and build fresh.

 Ian, thanks -- that helped!

 Just a note: (crochet) buildworld finished successfully. However
 buildkernel fails at the very beginning with Malformed conditional
 (${MK_ARM_EABI} != no) -- just as Michael Tuexen reported at arm@.
 
 I have a fix pending for that, but there’s other problems building arm 
 kernels/modules at
 the moment I’m sorting out before pushing that in.

Thank you!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org