Re: Voxer using FreeBSD, BSDNow.tv interview

[Nikolai Lifanov]

On 10/20/14 13:36, Rainer Duffner wrote:
> 
>> Am 20.10.2014 um 10:19 schrieb David Chisnall :
>>
>>
>> I presume that most of the relevant differences are for users / developers 
>> and not sysadmins?  It's worth noting that GNU coreutils, tar, bash, and a 
>> load of other things are in the ports repository.  I wonder if it's worth 
>> having a gnu-userland metaport, perhaps with something like the Solaris 
>> approach of sticking them all in a different tree so that you can just add 
>> that to the start of your PATH and have all of the GNU tools work by 
>> default.  
>>
> 
> 
> They use chef.
> The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD 
> version of it. Well, it least it did the last time I looked. Maybe this got 
> fixed in the meantime.
> Which means that to „bootstrap“ a node, you’ve first got to install pkg on 
> it, install bash, symlink it to /bin/bash and then bootstrap the node.
> Which kind of runs against the concept of doing everything via chef.
> 
> 
> 

Hi from sysutils/ansible maintainer!

The ansible port REINPLACE_CMDs away hardcoded paths at build time. This
way managing FreeBSD "just works". Maybe chef can benefit from the same
approach?

- Nikolai Lifanov

___
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: Voxer using FreeBSD, BSDNow.tv interview

[Nikolai Lifanov]

On 10/20/14 14:43, Baptiste Daroussin wrote:
> On Mon, Oct 20, 2014 at 02:33:20PM -0400, Nikolai Lifanov wrote:
>> On 10/20/14 13:36, Rainer Duffner wrote:
>>>
>>>> Am 20.10.2014 um 10:19 schrieb David Chisnall :
>>>>
>>>>
>>>> I presume that most of the relevant differences are for users / developers 
>>>> and not sysadmins?  It's worth noting that GNU coreutils, tar, bash, and a 
>>>> load of other things are in the ports repository.  I wonder if it's worth 
>>>> having a gnu-userland metaport, perhaps with something like the Solaris 
>>>> approach of sticking them all in a different tree so that you can just add 
>>>> that to the start of your PATH and have all of the GNU tools work by 
>>>> default.  
>>>>
>>>
>>>
>>> They use chef.
>>> The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD 
>>> version of it. Well, it least it did the last time I looked. Maybe this got 
>>> fixed in the meantime.
>>> Which means that to „bootstrap“ a node, you’ve first got to install pkg on 
>>> it, install bash, symlink it to /bin/bash and then bootstrap the node.
>>> Which kind of runs against the concept of doing everything via chef.
>>>
>>>
>>>
>>
>> Hi from sysutils/ansible maintainer!
>>
>> The ansible port REINPLACE_CMDs away hardcoded paths at build time. This
>> way managing FreeBSD "just works". Maybe chef can benefit from the same
>> approach?
>>
> USES=shebangfix is there exactly for that.
> 

I USES=shebangfix, but it only fixes ~40% of path problems (although in
a very neat and easy to use way). Hardcoded etcdir, module directory,
man pages, etc. also need to be changed.

> regards,
> Bapt
> 

___
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: Call for testing: elftoolchain tools

[Nikolai Lifanov]

On 12/18/14 10:12, Ed Maste wrote:
> We have a rather outdated version of binutils in the base system.  As
> part of a project to update our toolchain I've started working on
> using some of the tools from the elftoolchain project.  There is now a
> build knob to enable the use of the following tools:
> 
> * addr2line
> * elfcopy (strip)
> * nm
> * size
> * strings
> 
> The knob (in /etc/src.conf) is:
> WITH_ELFTOOLCHAIN_TOOLS=yes
> 
> The binutils version is still used for as, ld, objcopy, objdump and
> readelf; future projects will handle these.
> 
> The option is being tested in ports exp-runs on amd64 and i386, and
> has had basic sanity testing on arm64 and mips64.
> 
> I'm interested in test reports across a variety of hardware
> architectures and use cases.  If everything works as expected you
> should see no difference -- the tools should be drop-in replacements.
> 
> -Ed
> ___
> 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"
> 

I was running WITH_ELFTOOLCHAIN_TOOLS for a few days on head/amd64 and
clang350-import/amd64. Things build and work as before. I'm not seeing
any behavior differences.

- Nikolai Lifanov

___
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: [Call for testers] DRM device-independent code update to Linux 3.8

[Nikolai Lifanov]

On 02/17/15 18:45, Jean-Sébastien Pédron wrote:
> Hi!
> 
> An update to the DRM subsystem, not including the drivers, is ready for
> wider testing!
> 
> The patch against HEAD is here:
> https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch
> 
> I'm interested in success/failure reports for amd64, powerpc and
> powerpc64 users, for i915 and Radeon GPUs. I already know there is a
> build issue on i386, please wait for the next patch if you are in this case.
> 
> The changes brought by this patch are explained in a blog post:
> http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/
> 
> This is working well for some Radeon users for more than a year.
> However, it only started to work with i915 a month ago, when the i915
> refresh was committed.
> 
> Try your day-to-day applications, try suspend/resume, try all output
> connectors, try OpenGL stuff, try backlight controls, everything :)
> 
> Thank you!
> 

I tried the -h version of the patch with an Nvidia card. I didn't notice
any changes in behavior.

- Nikolai Lifanov

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

xargs -P0 suport

[Nikolai Lifanov]

Hi current@!

Can someone take a look at Bugzilla #199976 please?
It's a pretty trivial patch that adds -P0 support to xargs.

If there is any feedback or the patch is wrong, I can rework it.
I've been running CURRENT with it for a bit now with no problems.

I would like very much for it to make it to 10.2-RELEASE.
It would make it much easier for me to convert some systems to FreeBSD
as many custom scripts that use it will be able to port as-is.

Thank you!

- Nikolai Lifanov

___
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: xargs -P0 suport

[Nikolai Lifanov]

On 05/21/15 23:25, Allan Jude wrote:
> On 2015-05-21 21:55, Nikolai Lifanov wrote:
>> Hi current@!
>>
>> Can someone take a look at Bugzilla #199976 please?
>> It's a pretty trivial patch that adds -P0 support to xargs.
>>
>> If there is any feedback or the patch is wrong, I can rework it.
>> I've been running CURRENT with it for a bit now with no problems.
>>
>> I would like very much for it to make it to 10.2-RELEASE.
>> It would make it much easier for me to convert some systems to FreeBSD
>> as many custom scripts that use it will be able to port as-is.
>>
>> Thank you!
>>
>> - Nikolai Lifanov
>>
>> ___
>> 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"
> 
> This has been submitted for code review
> 
> https://reviews.freebsd.org/D2616
> 
> 

Thanks!

- Nikolai Lifanov
___
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: xargs -P0 suport

[Nikolai Lifanov]

On 05/22/15 13:27, Mateusz Guzik wrote:
> On Fri, May 22, 2015 at 12:32:52PM -0400, Allan Jude wrote:
>> There is some question about if nargs is a sane value for maxprocs in
>> the negative case. 5000 does seem a bit high, and the behaviour can get
>> wonky depending on the order you specify -P and -n together on the
>> command line.
>>
>> Any suggestions?
>>
> 
> GNU xargs imposes no limit whatsoever, but it also supports reallocating
> its process table, while our xargs allocates one upfront and does not
> change it.
> 
> I would say reading hard proc resource limit and using that as the limit
> would do the job just fine.
> 

GNU xargs uses MAX_INT for this limit. Our xargs performs much worse
with it for a reason I haven't investigated. The 5000 number doesn't
seem high and I have workflows that do ' | xargs -n1 -P0 ...'
spawning about this many jobs.

- Nikolai Lifanov

___
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: Packaging the FreeBSD base system with pkg(8)

[Nikolai Lifanov]

On January 28, 2016 1:23:22 PM EST, Glen Barber  wrote:
>On Thu, Jan 28, 2016 at 09:12:53PM +0300, Slawa Olhovchenkov wrote:
>> I see two hudge problem for support upgrades from older RELEASE
>> versions (supported too): key (used for repo signing) change and need
>> to access ports packages to install (installed outdated release can't
>> find pkg packet for install).
>> 
>> Can you more detailed describe current propolsal of new packaging
>> system? pkg is part of base installed packages? Or after installing
>> base packages pkg installed from `ports`? For disc1.iso case.
>> 
>> How handled boot/device.hints and var/db/etcupdate?
>> 
>> How handled boot block updates?
>
>These are all valid questions, but let's take a step back for a bit,
>and
>not put the carriage in front of the horse.
>
>The initial email in this thread was intended to provide an update on
>the status.  Some things, such as file merging, is already in place in
>a few of the packages.  Not all, yet.
>
>Unexpected things are going to happen.  That is the only thing that is
>a guarantee right now.  In other words, implementation (from what is
>now
>in the project branch) may change.  And yes, there needs to be a way to
>upgrade from older releases.
>
>But let's not get too far ahead of ourselves.
>
>Glen

Can we have verbose and/or semi-interactive configuration merge, as offered by 
etcupdate or mergemaster?

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

Re: HEADS UP: clang/llvm/lldb/compiler-rt 3.8.0 imported

[Nikolai Lifanov]

On 2016-03-06 09:28, Larry Rosenman wrote:

On 2016-03-06 08:20, Larry Rosenman wrote:

On Sun, Mar 06, 2016 at 03:15:10PM +0100, Dimitry Andric wrote:

On 06 Mar 2016, at 06:20, Larry Rosenman  wrote:
>
> On 2016-03-05 18:46, Dimitry Andric wrote:
>> On 06 Mar 2016, at 00:30, Dimitry Andric  wrote:
>>> On 05 Mar 2016, at 22:32, Dimitry Andric  wrote:
>>>> I imported the (tentative) 3.8.0 release of clang, llvm, lldb and
>>>> compiler-rt into head, in r296417.  The upstream release is going to be
>>>> very soon now, but I do not expect any changes anymore.
>>>> This was tested with make universe, and a few exp-runs, but there is
>>>> always a chance that you might run into something unexpected, either
>>>> with the base system or ports.  In such cases, please file bugs, and
>>>> make sure you note somewhere in the description that it is related to
>>>> this import.
>>> Please hold off upgrading for now, if you are on amd64, and loading the
>>> aesni.ko module.  It appears that loading this module can cause the
>>> kernel ELF linker to panic, but it is not yet clear why.  This is being
>>> tracked in PR207729 [1].
>> It should be safe again after r296419.  Thanks to Kostik Belousov for
>> the quick fix.  (Clang 3.8.0 generates a different type for unwind
>> sections on amd64, and this was unexpected in the kernel linker.)
>> -Dimitry
>> [1] https://svnweb.freebsd.org/changeset/base/296419
> I'm getting a crash at startup (mi_startup) with a clang 3.8.0 kernel.
>
> Picture at:
> http://www.lerctr.org/~ler/FreeBSD/20160305_225532.jpg

It's pretty hard to make out, but it looks like it is panic'ing in
link_elf_reloc_local().  That should have been fixed with r296419, 
but
maybe there is yet another edge case that wasn't fixed.  Do you have 
a

crash dump and/or a backtrace?  Which modules are you preloading?

-Dimitry



loader,conf:

kern.msgbuf_clear="1"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"
ichsmb_load="YES"
hwpmc_load="YES"
aesni_load="YES"
cryptodev_load="YES"
dtraceall_load="YES"
cpuctl_load="YES"
cuse_load="YES"
coretemp_load="YES"
#hw.usb.quirk.0="0x0bda 0x0129 0x3960 0x3960
UQ_MSC_FORCE_WIRE_BBB,UQ_MSC_FORCE_PROTO_SCSI"
#hw.usb.umass.debug="-1"

I'll see if I can get a better  pic with a backtrace.  This crash is
WAY early, so no dump :(



acpi_dsdt_load="YES"  # DSDT Overriding
acpi_dsdt_name="/boot/dsdt.aml"
#hw.psm.synaptics_support="1"


new pic: http://www.lerctr.org/~ler/FreeBSD/20160306_082426.jpg


I loaded everything in this list other than acpi_dsdt override.

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

Re: HEADS UP: clang/llvm/lldb/compiler-rt 3.8.0 imported

[Nikolai Lifanov]

On 2016-03-06 11:33, Dimitry Andric wrote:

On 06 Mar 2016, at 17:17, Larry Rosenman  wrote:


On 2016-03-06 08:54, Larry Rosenman wrote:

On 2016-03-06 08:49, Larry Rosenman wrote:

On 2016-03-06 08:40, Nikolai Lifanov wrote:

...

I loaded everything in this list other than acpi_dsdt override.
- Nikolai Lifanov

still breaks for me without the dsdt override :(

+list
https://svnweb.freebsd.org/changeset/base/296428 fixes it after 
installing the new boot1.efi


Thanks for the confirmation.  I could reproduce the panic locally, by
preloading the modules from the boot loader.

-Dimitry


I tend to load only what's absolutely necessary for a successful boot 
from loader.conf
and load the rest from kld_list in rc.conf so that single user mode has 
the greatest

chance of working.

- Nikolai Lifanov
___
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: [CFT] packaging the base system with pkg(8)

[Nikolai Lifanov]

On March 13, 2016 10:17:05 AM EDT, Miroslav Lachman <000.f...@quip.cz> wrote:
>Bryan Drewery wrote on 03/13/2016 06:00:
>> On 3/11/16 9:01 AM, Daniel Eischen wrote:
>>> On Fri, 11 Mar 2016, Slawa Olhovchenkov wrote:
>>>
>>>> On Fri, Mar 11, 2016 at 01:05:11PM +0100, Baptiste Daroussin wrote:
>>>>
>>>>> On Tue, Mar 08, 2016 at 05:35:59PM +, David Chisnall wrote:
>>>>>> On 8 Mar 2016, at 15:14, Slawa Olhovchenkov 
>wrote:
>>>>>>>
>>>>>>
>>>>>> In terms of comparing packages, if you’re doing that visually
>then
>>>>>> you are likely to have problems anyway, unless your eyes and
>brain
>>>>>> work far better than most humans.  We can make that much easier
>by
>>>>>> providing libxo output in pkg and allowing you to have a simple
>jq
>>>>>> script that tells you what the differences are.
>>>>>>
>>>>> pkg can already expose the entire content of a package in json or
>ucl
>>>>> via:
>>>>> $ pkg info --raw --raw-format [json|json-conpact|yaml|ucl] name
>>>>
>>>> Exposing  the entire content of a package is not a root of cause.
>>>> Question in comapring of two different setup with different
>behaviour
>>>> and search cause of difference.
>>>>
>>>> Case of only a few monolitic packages is essentiality simple then
>case
>>>> of 1000 combined packages.
>>>
>>> It would be nice to have pkg(8) show packages in tree form, with
>option
>>> to show just top-level meta packages or packages that have no meta.
>>>
>>> Perhaps this is possible, but it's not obvious to me.
>>>
>>
>> https://github.com/freebsd/pkg/blob/master/scripts/pkg_tree.sh
>
>Thank you.
>Can you publish it as a port? I know there is one written in Perl but I
>
>like your sh without dependencies.
>
>Miroslav Lachman
>
>___
>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"

In my opinion, if this script is to land in ports, it should go under share/doc 
or share/examples for ports-mgmt/pkg.


- Nikolai Lifanov
___
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 loaders got fatter in the last few days

[Nikolai Lifanov]

On 03/18/16 13:03, Allan Jude wrote:
> On 2016-03-18 12:33, Guido Falsi wrote:
>> Hi,
>>
>> I have just update one of my machines and noticed the booloaders files
>> got quite fat in the last few days, some by a big margin.
>>
>> on an updated machine(r296993):
>>
>>> ls -l /boot/*boot*
>> -r--r--r--  1 root  wheel8192 Mar 18 16:47 /boot/boot
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot0sio
>> -r--r--r--  1 root  wheel 512 Mar 18 16:47 /boot/boot1
>> -r-xr-xr-x  1 root  wheel   72152 Mar 18 16:47 /boot/boot1.efi
>> -r--r--r--  1 root  wheel  819200 Mar 18 16:47 /boot/boot1.efifat
>> -r--r--r--  1 root  wheel7680 Mar 18 16:47 /boot/boot2
>> -r--r--r--  1 root  wheel1185 Mar 18 16:47 /boot/cdboot
>> -r--r--r--  1 root  wheel   85794 Mar 18 16:47 /boot/gptboot
>> -r--r--r--  1 root  wheel  110546 Mar 18 16:47 /boot/gptzfsboot
>> -r--r--r--  1 root  wheel  358400 Mar 18 16:47 /boot/pxeboot
>> -r--r--r--  1 root  wheel  341248 Mar 18 16:47 /boot/userboot.so
>> -r--r--r--  1 root  wheel   66048 Mar 18 16:47 /boot/zfsboot
>>
>> from a machine I still have not updated(r296719):
>>
>>> ls -l /boot/*boot*
>> -r--r--r--  1 root  wheel8192 Mar 13 21:01 /boot/boot
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot0sio
>> -r--r--r--  1 root  wheel 512 Mar 13 21:01 /boot/boot1
>> -r-xr-xr-x  1 root  wheel   72152 Mar 13 21:01 /boot/boot1.efi
>> -r--r--r--  1 root  wheel  819200 Mar 13 21:01 /boot/boot1.efifat
>> -r--r--r--  1 root  wheel7680 Mar 13 21:01 /boot/boot2
>> -r--r--r--  1 root  wheel1185 Mar 13 21:01 /boot/cdboot
>> -r--r--r--  1 root  wheel   16059 Mar 13 21:01 /boot/gptboot
>> -r--r--r--  1 root  wheel   41511 Mar 13 21:01 /boot/gptzfsboot
>> -r--r--r--  1 root  wheel  288768 Mar 13 21:01 /boot/pxeboot
>> -r--r--r--  1 root  wheel  341208 Mar 13 21:01 /boot/userboot.so
>> -r--r--r--  1 root  wheel   66048 Mar 13 21:01 /boot/zfsboot
>>
>> I noticed because mu gpt boot partition is 64K and gptzfsboot just
>> passed 100K.
>>
>> Is this expected and I'm supposed to repartition or is this an unwanted
>> mistake?
>>
>> Thanks in advance.
>>
> 
> This is a side effect of the loader gaining the ability to boot from
> GELI encrypted partitions.
> 
> You can compile with LOADER_NO_GELI_SUPPORT to disable this to get back
> to a smaller one if you need.
> 
> Maybe we should be putting the GELI enabled boot blocks in a different
> filename? I generally wanted to avoid creating a new version of each
> bootcode with GELI support.
> 
> My goal somewhere down the road is to create a single bootcode that can
> do UFS and ZFS, then maybe we can have gptboot and gptgeliboot or
> something.
> 
> 

Maybe a single gptbootlite for minimum viable case of UFS+nothing fancy?
At some point in the near future users that want additional features
will re-partition and bsdinstall will create larger partitions for boot
and this won't be a problem.

P.S.: Allan, do you plan to enable GELI support for boot1.efi?

- Nikolai Lifanov

___
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-RELEASE pkg base & base.txz file

[Nikolai Lifanov]

On 04/18/16 10:00, Ernie Luzar wrote:
> 11.0 will have pkg base, thats ok, but what does than mean for the
> base.txz file?
> 
> It it going to stay as part of FBSD install?
> 
> I have many scripts for creating jails which depend on the base.txz file.

It's even easier now:

# mkdir -p /usr/jails/new
# pkg -r /usr/jails/new install -r base -g '*'

- Nikolai Lifanov

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

Re: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files

[Nikolai Lifanov]

On 05/10/2016 13:22, John Baldwin wrote:
> On Tuesday, May 10, 2016 05:12:28 PM Glen Barber wrote:
>> On Tue, May 10, 2016 at 10:04:47AM -0700, John Baldwin wrote:
>>> On Tuesday, May 10, 2016 06:32:29 AM Glen Barber wrote:
>>>> On Tue, May 10, 2016 at 08:25:22AM +0200, Thomas Zander wrote:
>>>>> On 10 May 2016 at 08:18, O. Hartmann  wrote:
>>>>>
>>>>>> I haven't figured out so far how far this goes. Lucky for those having
>>>>>> recent /etc/ backups. A pity FreeBSD doens't backup this by default.
>>>>>
>>>>> After having shot myself in the foot some time ago, "zfs snapshot" has
>>>>> become a part of my standard upgrade procedures :-)
>>>>>
>>>>
>>>> No argument that this is valuable, but we cannot rely on filesystem
>>>> specific solutions.  Similar topic came up a few days ago following
>>>> lunch.  It got me thinking of a better way to ensure this kind of thing
>>>> does not require home-grown foot protection from cannons.
>>>>
>>>> It should be fairly trivial to automatically backup /etc (and related)
>>>> when 'distribution' is run, either intentionally or accidentally (or by
>>>> commit mistakes, such as this).
>>>
>>> Saving the output of 'etcupdate diff' nightly might not be a bad first step.
>>>
>>
>> This is also a good way to alleviate such things, however I am unsure
>> how to handle cases where 'etcupdate' would inadvertently run into
>> a conflict.  This was my concern with implementing an "automatic"
>> etcupdate run in the runtime package.
> 
> I mean as part of the nightly jobs we could add one that stores
> 'etcupdate diff' in /var the same as we do with backups of the master.passwd,
> group, and aliases files in /var/backups.  You can then at least use that to
> reconstruct altered /etc files by applying the diffs.  This isn't meant to be
> an automated update run, but just saving a diff as part of the nightly jobs.
> 

That's what I do. The periodic "etcupdate diff" dumps, which I was
already taking despite boot environments helped me work through various
pkgbase issues.

> As far as what to do in runtime packages, presumably there isn't a single
> package with all of etc, but etc files can be split up (ppp.conf in the ppp
> package, etc.) and pkg needs to do its own 3-way merge of changes to conf
> files when upgrading.  (This would be nice for conf files for ports in
> /usr/local/etc as well.)  You still need to figure out how to handle
> conflicts, but if pkg manages /etc files as config files and does a 3-way
> merge of the old package and new package then that will serve to reimplement
> etcupdate as part of 'pkg upgrade'.  Having a 'pkg confdiff' or some such to
> output diffs made to conf files would be the equivalent of 'etcupdate diff'
> in that case (and would be nice as it would apply to conf files in ports as
> well).
> 

Having "pkg confdiff" would be wonderful, for both base and ports.

- Nikolai Lifanov

___
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: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Nikolai Lifanov]

On 06/14/2016 21:05, Marcelo Araujo wrote:
> 2016-06-15 8:17 GMT+08:00 Chris H :
> 
>> On Thu, 9 Jun 2016 17:55:58 +0800 Marcelo Araujo 
>> wrote
>>
>>> Hey,
>>>
>>> Thanks for the CFT Craig.
>>>
>>> 2016-06-09 14:41 GMT+08:00 Xin Li :
>>>


 On 6/8/16 23:10, Craig Rodrigues wrote:
> Hi,
>
> I have worked with Marcelo Araujo to port OpenBSD's ypldap to FreeBSD
> current.
>
> In latest current, it should be possible to put in /etc/rc.conf:
>
> nis_ypldap_enable="YES"
> to activate the ypldap daemon.
>
> When set up properly, it should be possible to log into FreeBSD, and
>> have
> the backend password database come from an LDAP database such
> as OpenLDAP
>
> There is some documentation for setting this up, but it is OpenBSD
 specific:
>
> http://obfuscurity.com/2009/08/OpenBSD-as-an-LDAP-Client
> http://puffysecurity.com/wiki/ypldap.html#2
>
> I did not bother porting the OpenBSD LDAP server to FreeBSD, so that
> information
> does not apply.  I figure that openldap from ports should work fine.
>
> I was wondering if there is someone out there familiar enough with
>> LDAP
> and has a setup they can test this stuff out with, provide feedback,
>> and
> help
> improve the documentation for FreeBSD?

 Looks like it would be a fun weekend project.  I've cc'ed a potential
 person who may be interested in this as well.

 But will this worth the effort? (I think the current implementation
 would do everything with plaintext protocol over wire, so while it
 extends life for legacy applications that are still using NIS/YP, it
 doesn't seem to be something that we should recommend end user to use?)

>>>
>>> I can see two good point to use ypldap that would be basically for users
>>> that needs to migrate from NIS to LDAP or need to make some integration
>>> between legacy(NIS) and LDAP during a transition period to LDAP.
>>>
>>> As mentioned, NIS is 'plain text' not safe by its nature, however there
>> are
>>> still lots of people out there using NIS, and ypldap(8) is a good tool to
>>> help these people migrate to a more safe tool like LDAP.
>>>
>>>

> I would also be interested in hearing from someone who can see if
> ypldap can work against a Microsoft Active Directory setup?

 Cheers,


>>> All my tests were using OpenLDAP, I used the OpenBSD documentation to
>> setup
>>> everything, and the file share/examples/ypldap/ypldap.conf can be a good
>>> start to anybody that wants to start to work with ypldap(8).
>>>
>>> Would be nice hear from other users how was their experience using ypldap
>>> with MS Active Directory and perhaps some HOWTO how they made all the
>> setup
>>> would be amazing to have.
>>>
>>> Also, would be useful to know who are still using NIS and what kind of
>>> setup(user case), maybe even the reason why they are still using it.
>>
>> Honestly, I think the best way to motivate people to do the right thing(tm)
>> Would be to remove Yellow Pages from the tree, entirely. :-)
>> It's been dead for *years*, and as you say, isn't safe, anyway..
>>
> 
> Yes, I have a plan for that, but I don't believe it will happens before
> FreeBSD 12-RELEASE.
> 

Please don't, at least for now. NIS is fast, simple, reliable, and works
on first boot without additional software. I have passwords in
Kerberos, so the usual cons doesn't apply. This is very valuable to me.

It's not hurting anyone. What's the motivation behind removing it?

> 
>>
>> --Chris
>>>
>>>
>>> Best,
>>> --
>>>
>>> --
>>> Marcelo Araujo(__)ara...@freebsd.org
>>> \\\'',)http://www.FreeBSD.org    \/  \ ^
>>> Power To Server. .\. /_)
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "
>> freebsd-current-unsubscr...@freebsd.org"
>>
>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
> 
> 
> 

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

Re: Destroy GPT partition scheme absolutely, how?

[Nikolai Lifanov]

On 09/26/2016 11:08, Gary Jennejohn wrote:
> On Mon, 26 Sep 2016 09:48:22 -0400
> Ernie Luzar  wrote:
> 
>> Hartmann, O. wrote:
>>> I ran into a very nasty and time consuming problem. Creating a NanoBSD
>>> image with a modified script framework creating GPT partitions, I put
>>> the imaes via "dd(1)" on USB flash or SD flash. Because the images are
>>> usually much smaller than the overall capacity of the USB or SD, the OS
>>> (FreeBSD CURRENT, recently built as of this morning) complains about
>>> the second GPT header isn't in the last LBA. Sometimes, my PCengines
>>> APU2 doesn't boot then, a relief is to issue the command > > gpart recover 
>>> da1  
>>>> (in that case, the USB flash drive or SD flash is recognized  
>>> as /dev/da1).  
>>>> But I run into a nasty situation, if the image put to the flash is  
>>> somehow corrupted. Then I tried to write a second, repaired image over
>>> the first one using dd(1) again and do a recovering as mentioned above
>>> - but this is fatal in two ways. First, the corrupted/broken GPT seems
>>> to be "recovered" and put in replacement of the correct one - so I
>>> guess. Performing no recover leaves the image on flash corrupted
>>> anyway.  
>>>> Well, to be honest, I didn't exactly know what is going on here. The  
>>> phenomenon is that I had a problem creating a NANO_DATASIZE= DATA
>>> partition with an empty NANO_DATASIZE which somehow corrupted the
>>> whole image. The image then never booted, complaining,
>>> that /foo/bar/_.mnt was unmounted unleanly.  
>>>> This happened multiple times, even if I tried to overwrite the SD or  
>>> USB flash with /dev/zero or /dev/random data, but I do stop such a dd
>>> after a couple f minutes, since the SD is 32GB in size and the USB
>>> flash drive is 32 GB, 64 GB and 128 GB - a pain in the ass if you want
>>> to write via USB 2.0. But even with overwriting with a good image then
>>> results in a corrupt image on flash drive, complaining about the GPT
>>> second header not in last LBA and the issue with the uncleanly
>>> unmount _.mnt (from the creation process of the NanoBSD image)! > > So I 
>>> guess there is something magic happening. Some informations are
>>> not lost and I suspect the "recovery" moving those foul data into
>>> active places.  
>>>> Using a fresh/new SD or USB resolves the problem. But the question  
>>> remains: how can I destroy any relevant GPT information on a Flash
>>> drive (or even harddisk) to avoid unwanted remains of an foul image
>>> installation? > > First guess was to write the last couple of bytes on such 
>>> a flash drive
>>> by letting dd(1) counting backwards, but I couldn't figure out how to
>>> let dd(1) do such a procedure. The nightmare didn't end, while trying,
>>> the SD flash card died :-(  
>>>> thank you very much for your help and thoughts.
>>>> Kind regards, thanks in advance,
>>>>
>> This little script has been posted before. Maybe it will be what your 
>> looking for. Called gpart.nuke
>>
>> #! /bin/sh
>> echo "What disk do you want"
>> echo "to wipe? For example - da1 :"
>> read disk
>> echo "OK, in 10 seconds I will destroy all data on $disk!"
>> echo "Press CTRL+C to abort!"
>> sleep 10
>> diskinfo ${disk} | while read disk sectorsize size sectors other
>> do
>>   # Delete MBR and partition table.
>>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1
>>   # Delete GEOM metadata.
>>   dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` 
>> count=2
>> done
>>
> 
> I'm surprised that this script works without
>   sysctl kern.geom.debugflags=16
> 

You could just gpart destroy/create/destroy instead of doing arithmetic.

- Nikolai Lifanov

___
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: /usr/share/man/man4/cc.4.gz obsolete?

[Nikolai Lifanov]

On 12/16/2016 04:31, Trond Endrestøl wrote:
> /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run 
> make -C /usr/src check-old.
> 
> make -C /usr/src delete-old removes the file, but 
> make -C /usr/src installworld adds it.
> 
> System is base/head r309889.
> 
> Please make up your mind.
> 

This is installed by cxgbe module directory for if_cc (T6 cards) and
previously removed as an old congestion control page. I put up a review
to fix this: https://reviews.freebsd.org/D8816

- Nikolai




signature.asc
Description: OpenPGP digital signature

Re: Time to increase MAXPHYS?

[Nikolai Lifanov]

On 6/3/17 11:55 PM, Allan Jude wrote:
> On 2017-06-03 22:35, Julian Elischer wrote:
>> On 4/6/17 4:59 am, Colin Percival wrote:
>>> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@
>>> wrote:
 Add better support for larger I/O clusters, including larger physical
 I/O.  The support is not mature yet, and some of the underlying
 implementation
 needs help.  However, support does exist for IDE devices now.
>>> and increased MAXPHYS from 64 kB to 128 kB.  Is it time to increase it
>>> again,
>>> or do we need to wait at least two decades between changes?
>>>
>>> This is hurting performance on some systems; in particular, EC2 "io1"
>>> disks
>>> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized
>>> spinning rust)
>>> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS)
>>> recommends
>>> using a maximum I/O size of 1 MB (and despite NFS not being *physical*
>>> I/O it
>>> seems to still be limited by MAXPHYS).
>>>
>> We increase it in freebsd 8 and 10.3 on our systems,  Only good results.
>>
>> sys/sys/param.h:#define MAXPHYS (1024 * 1024)   /* max raw I/O
>> transfer size */
>>
>> ___
>> 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"
> 
> At some point Warner and I discussed how hard it might be to make this a
> boot time tunable, so that big amd64 machines can have a larger value
> without causing problems for smaller machines.
> 
> ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some
> of the benefit.
> 
> I am preparing some benchmarks and other data along with a patch to
> increase the maximum size of pipe I/O's as well, because using 1MB
> offers a relatively large performance gain there as well.
> 

Hi!

I also migrated to 1mb recordsize. What's the status of your patches
and/or making MAXPHYS a boot-time tunable? I can help test these.

- Nikolai



signature.asc
Description: OpenPGP digital signature

ums stopped autoloading between 242082 and 242090

[Nikolai Lifanov]

Hello.

At some point between revisions 242082 and 242090, my ums driver stopped 
loading automatically, and my mouse only works in X if ums.ko is loaded 
in loader.conf before a full boot and not with kldload later.

I am on amd64. I can help troubleshoot this more.

- Nikolai Lifanov

___
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: ums stopped autoloading between 242082 and 242090

[Nikolai Lifanov]

On 10/25/12 18:32, Garrett Cooper wrote:

On Thu, Oct 25, 2012 at 2:53 PM, Nikolai Lifanov
 wrote:

Hello.

At some point between revisions 242082 and 242090, my ums driver stopped
loading automatically, and my mouse only works in X if ums.ko is loaded in
loader.conf before a full boot and not with kldload later.
I am on amd64. I can help troubleshoot this more.

Which branch?
-Garrett

HEAD, sorry

___
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: ums stopped autoloading between 242082 and 242090

[Nikolai Lifanov]

On 10/26/2012 02:43 AM, Hans Petter Selasky wrote:

On Friday 26 October 2012 00:40:42 Garrett Cooper wrote:

On Thu, Oct 25, 2012 at 3:33 PM, Nikolai Lifanov
 wrote:

...


HEAD, sorry


No worries. Nothing coming to mind in the svn commits immediately, so
it might be a complex interaction issue. I would see if you could
individually roll back commits until you find the problem child.

It could also be accidental fallout from the recent ACPI update...


Hi,

ums.ko is now loaded by devd and /etc/devd/usb.conf.

devd must be enabled in rc.conf.

Before ums was loaded by moused itself.

Also see new rules in /etc/devd.conf:

notify 100 {
 match "system" "DEVFS";
 match "subsystem" "CDEV";
 match "type" "CREATE";
 match "cdev" "ums[0-9]+";

 action "/etc/rc.d/moused quietstart $cdev";
};

notify 100 {
 match "system" "DEVFS";
 match "subsystem" "CDEV";
 match "type" "DESTROY";
 match "cdev" "ums[0-9]+";

 action "/etc/rc.d/moused stop $cdev";
};

Maybe mergemaster was not properly done?

--HPS



You are right, actually.
I was missing these lines.

I don't know what happened to mergemaster, but doing a strict comparison 
instead of going by VCS id fixed it.


- Nikolai Lifanov

___
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: BHyVe on 10-Current r245673

[Nikolai Lifanov]

On 01/29/2013 09:15 AM, G B wrote:
> I am using FreeBSD 10-Current r245673 as a host on an HP p2-1394.
> I have the host OS installed on 1 drive using UFS and a second
> drive using ZFS with a pool named 'tank.'  They layout for zfs for
> my guest install is /tank/guest01.
> 
> When using the command: # bhyveload -d
> /tmp/FreeBSD-9.1-RELEASE-amd64-disk1.iso -m 512 -h /tank/guest01
> guest01 && bhyve -c 2 -a -A -m 512 -g 0 -P -H -s 1,virtio-net,tap0
> -s 2,virtio-blk,diskdev guest01 && sleep 20 && ifconfig tap0 up
> 
> I get the boot screen for FreeBSD 9.1 and after the timed pause it
> fails with: Could not open backing file: No such file or directory 
> ACPI tables require and ioapic Assertion failed: (error == 0),
> function main, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 774. 
> Abort (core dumped) root@localhost:/tmp#
> 
> I am using the bhyveload comamnd from a PDF I found from BSDCan but
> when I used the -m 768 -M 1024 as used in the doc it failed with a
> syntax error, so I switched to using just -m 512.  My .iso is in
> /tmp as indicated in my command with '-d'.
> 
> I'm guessing my command is wrong, but not sure where.  Any help
> would be appreciated.
> 
> Thanks, Gary ___ 
> 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"
> 

> "diskdev" is your actual disk (i.e. -s 
> 2,virtio-blk,/dev/zvol/tank/guest01). Also, you need a zvol if you
> are doing this. Also, "-h" in bhyveload specifies a directory with
> a loader config, kernel, and modules. You definitely don't need it
> with an ".iso" boot.

Also, see examples here:
http://mirrors.nycbug.org/pub/BHyVe/r244024/INSTRUCTIONS-COPYRIGHT.txt
and files here: http://mirrors.nycbug.org/pub/BHyVe/r244024/

Also, check http://callfortesting.org/ for some more examples.

- Nikolai Lifanov
___
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: BHyVe on 10-Current r245673

[Nikolai Lifanov]

On 01/29/2013 09:15 AM, G B wrote:
> I am using FreeBSD 10-Current r245673 as a host on an HP p2-1394.
> I have the host OS installed on 1 drive using UFS and a second
> drive using ZFS with a pool named 'tank.'  They layout for zfs for
> my guest install is /tank/guest01.
> 
> When using the command: # bhyveload -d
> /tmp/FreeBSD-9.1-RELEASE-amd64-disk1.iso -m 512 -h /tank/guest01
> guest01 && bhyve -c 2 -a -A -m 512 -g 0 -P -H -s 1,virtio-net,tap0
> -s 2,virtio-blk,diskdev guest01 && sleep 20 && ifconfig tap0 up
> 
> I get the boot screen for FreeBSD 9.1 and after the timed pause it
> fails with: Could not open backing file: No such file or directory 
> ACPI tables require and ioapic Assertion failed: (error == 0),
> function main, file /usr/src/usr.sbin/bhyve/bhyverun.c, line 774. 
> Abort (core dumped) root@localhost:/tmp#
> 
> I am using the bhyveload comamnd from a PDF I found from BSDCan but
> when I used the -m 768 -M 1024 as used in the doc it failed with a
> syntax error, so I switched to using just -m 512.  My .iso is in
> /tmp as indicated in my command with '-d'.
> 
> I'm guessing my command is wrong, but not sure where.  Any help
> would be appreciated.
> 
> Thanks, Gary ___ 
> 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"
> 

"diskdev" is your actual disk (i.e. -s
2,virtio-blk,/dev/zvol/tank/guest01). Also, you need a zvol if you are
doing this.
Also, "-h" in bhyveload specifies a directory with a loader config,
kernel, and modules. You definitely don't need it with an ".iso" boot.

- Nikolai Lifanov
___
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: wifi and wpa_supplicant

[Nikolai Lifanov]

On 02/04/2013 10:37 AM, CeDeROM wrote:
> Hello :-)
> 
> I am wondering how exactly the wifi interface and wpa_supplicant is
> organized - is there any script at wlan0 interface up that starts
> wpa_supplicant for that interface? Do I have to start wpa_supplicant
> by hand any time I bring interface down and up (it looks yes for me)?
> I have ifconfig_wlan0="WPA DHCP" set in rc.conf so I guess after/when
> interface is up both wpa_supplicant and dhclient should be started..?
> What should I make to wpa_supplicant starts automatically when I bring
> wlan0 up? I am using iwn intel wifi driver.
> 
> Any hints appreciated :-)
> Tomek
> 

If you want to do this automatically outside of rc.conf, take a look at
devd(8).

- Nikolai Lifanov

___
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: wifi and wpa_supplicant

[Nikolai Lifanov]

On 02/04/2013 10:58 AM, CeDeROM wrote:
> Thank you Nikolai! Shouldn't this be a default when
> ifconfig_wlan0="WPA DHCP" in rc.conf? :-)
> 
> Best regards :-)
> Tomek
> 
> On Mon, Feb 4, 2013 at 4:47 PM, Nikolai Lifanov
>  wrote:
>> On 02/04/2013 10:37 AM, CeDeROM wrote:
>>> Hello :-)
>>>
>>> I am wondering how exactly the wifi interface and wpa_supplicant is
>>> organized - is there any script at wlan0 interface up that starts
>>> wpa_supplicant for that interface? Do I have to start wpa_supplicant
>>> by hand any time I bring interface down and up (it looks yes for me)?
>>> I have ifconfig_wlan0="WPA DHCP" set in rc.conf so I guess after/when
>>> interface is up both wpa_supplicant and dhclient should be started..?
>>> What should I make to wpa_supplicant starts automatically when I bring
>>> wlan0 up? I am using iwn intel wifi driver.
>>>
>>> Any hints appreciated :-)
>>> Tomek
>>>
>>
>> If you want to do this automatically outside of rc.conf, take a look at
>> devd(8).
>>
>> - Nikolai Lifanov
>>
>> ___
>> 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"
> 
> 
> 

Well, ifconfig_wlan0="WPA DHCP" should connect you at boot if you have
your wpa_supplicant.conf(5) configured for it.

There is a good writeup for it in the handbook:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html

Also, this should probably have gone to freebsd-users@ and not
freebsd-current@

- Nikolai Lifanov

___
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: r24684: /usr/src/lib/libldns/../../contrib/ldns/buffer.c:10:10: fatal error: 'ldns/config.h' file not found

[Nikolai Lifanov]

On 02/15/2013 01:08 PM, David Wolfskill wrote:
> On Fri, Feb 15, 2013 at 07:01:16PM +0100, O. Hartmann wrote:
>> ...
>> 
>> My boxes are one revision ahead of yours and all of them do not
>> build the recent sources as reported:
>> 
>> FreeBSD 10.0-CURRENT #0 r246825: Fri Feb 15 14:23:40 CET 2013
>> 
>> And by the way, we have amd64 only, no i386. Maybe this makes a
>> diffrence? 
> 
> No, but contrib/ldns wasn't imported until r246827  What's the 
> revision of your sources?
> 
> Note, in particular, 
> <http://docs.FreeBSD.org/cgi/mid.cgi?86txpdptgf.fsf>.
> 
> Peace, david
> 

I can reproduce the same failure on HEAD r246844
(last changed r246838) building for amd64.

- Nikolai Lifanov
___
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: Committing PEFS to CURRENT

[Nikolai Lifanov]

On 10/07/13 12:31, Gleb Kurtsou wrote:
> Hello,
> 
> I would like to ask everybody's opinion regarding committing PEFS to
> CURRENT.
> 
> PEFS is a stacked cryptographic file system for FreeBSD. Development
> started as Google Summer of Code project in 2009. It has been in ports
> since Sept 2011. I maintain the project.
> 
> Conceptually PEFS is similar to nullfs adding encryption layer on top of
> it. But it differs technically by not using vop_bypass. Another popular
> stacked cryptographic file systems include eCryptfs (linux) and encfs
> (fuse). There is also pam_pefs pam module to allow user authentication
> with their PEFS-encrypted home directory password.
> 
> For those interested in high level introduction I would highly recommend
> article by Kris Moore in the BSD Magazine Issue 09/2013(50) -
> http://bsdmag.org/magazine/1848-day-to-day-bsd-administration
> 
> We are very close to branching 10-STABLE now, but patch is
> non-intrusive, it only adds new functionality, enabling PEFS for i386
> and amd64 (platforms it's known to work on). Patch passes make universe.
> 
> Patch is available here:
> https://github.com/glk/freebsd-head/commit/b4d2c4a5f42f88fdd07cb75feba3467e4d4c043c.patch
> 
> Pros/cons:
> 
> - Having PEFS in base would be a huge maintenance help for PCBSD/TrueOS
>   who are already committed to use PEFS in next product releases, e.g.
>   PCBSD provides encrypted home directories.
> 
> - There is steady interest in the project from users (emails, etc).
>   Many of them note that file system is not well known yet.  Moving PEFS
>   to base would greatly increase its exposure.
> 
> - Committing PEFS to base would also simplify maintenance by keeping it
>   in sync with other subsystems, e.g. it will be updated on large scale
>   changes like VM locking.
> 
> - There are no bugs known at the moment. I've been using it to encrypt
>   home directory since day one. pho@ ran stress test suite on it a
>   while back, number of bugs was fixed.
> 
> - PEFS is known to work on amd64 and i386 only. Big endian system and
>   systems with page size larger than 4k are not tested.
> 
> - NOTE! There has been no cryptography review.  I'd like to suggest to
>   add warning about file system and crypto used is experimental and hasn't
>   undergone professional review. Similar to one we had in tmpfs.
> 
> 
> BSD Magazine article:
> http://bsdmag.org/magazine/1848-day-to-day-bsd-administration
> 
> Port:
> http://www.freshports.org/sysutils/pefs-kmod/
> 
> Source code repository:
> https://github.com/glk/pefs
> 
> FreeBSD DevSummit'2011 - pefs presentation slides:
> https://pefs.googlecode.com/files/pefs-devsummit.pdf
> 
> FreeBSD wiki page:
> https://wiki.freebsd.org/PEFS
> 
> 
> I would really appreciate any comments or suggestions.
> 
> 
> Thank you,
> Gleb.

Just a personal note: I hoped that you would commit pefs to base
someday. It works well, and is the type of a core functionality that
would be nice to have as early as the install ISO, before skel is copied
over for the first user. I would be happy if this happened.

- Nikolai Lifanov

___
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: cron(8) improvement

[Nikolai Lifanov]

On 11/05/13 12:31, Allan Jude wrote:
> This came up in discussion on IRC and I thought I should throw it at the
> list so I don't forget.
> 
> A user was asking how to do what linux cron does, where there is a
> directory /etc/cron.d/ that packages and add files to to create crontabs.
> 
> Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
> /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
> useful feature, especially for pkg(8) as it makes it easy and safe to
> programatically add and remove crontabs as part of a package.
> 
> 

Shouldn't we encourage packages to use periodic(8) when possible?

- Nikolai Lifanov

___
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: cron(8) improvement

[Nikolai Lifanov]

On 11/05/13 13:28, Allan Jude wrote:
> On 2013-11-05 13:21, Mark Felder wrote:
>>
>> On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote:
>>> On 11/05/13 12:31, Allan Jude wrote:
>>>> This came up in discussion on IRC and I thought I should throw it at the
>>>> list so I don't forget.
>>>>
>>>> A user was asking how to do what linux cron does, where there is a
>>>> directory /etc/cron.d/ that packages and add files to to create crontabs.
>>>>
>>>> Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and
>>>> /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very
>>>> useful feature, especially for pkg(8) as it makes it easy and safe to
>>>> programatically add and remove crontabs as part of a package.
>>>>
>>>>
>>> Shouldn't we encourage packages to use periodic(8) when possible?
>>>
>> Yes but our default periodic configuration in /etc/crontab is only
>> configured to be as granular as daily. If this is something that should
>> run hourly or at very strange intervals then cron is a better choice.
>>
>> If the application is installing its own user they could install their
>> own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports
>> do this.
>> ___
>> 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"
> I don't have a specific example off the top of my head, but I am sure
> there are some daemons that needs to do something at some interval as
> root. Personally I am not so sure about having a package create a
> crontab automatically. It seems like a POLA violation, but it is also
> something that seems to be expected by some modern applications. I
> assume it is mostly handled by pkg-message currently, and maybe it is
> best to continue that way, but having the additional flexibility may be
> very useful.
> 
> If for nothing else, it would be a lot prettier than the way I currently
> manage crontabs using puppet.
> 

I would be frustrated if a port installed a root cron job without my
intervention. How about an RC extension that dynamically adds these?
Think 'drupal_cron_enable="YES"'. I just think that there should be
something an operator does, either explicitly or through configuration
management, to add a cron job for root. We don't auto-enable daemons, so
we should not auto-add these either.

- Nikolai Lifanov

___
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: 10-RC2 current wireless link aggregation not working correctly

[Nikolai Lifanov]

On 12/17/13 08:06, dan_partelly wrote:
> 
> Hi all,
> 
> I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
> described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. 
> 
> What happens is:
> 
> If I boot the system with the Ethernet cable attached, I correctly get
> lagg0 active port on master- bg0- and the network is working correctly.
> (I mainly test pinging my gateway). When I pull the cable out, lagg0
> device correctly switches to wlan0 as shown by ifconfig (wlan0 is created
> from wpi0), but at the same time I get no more ping replies from my
> gateway. I can leave the system in this state for several minutes as an
> example
> and no replies are coming through. A simple list of interfaces with
> ifconfig with no parameters brigs the network back to life, and I start to
> get back the due ping replyes, this time thrugh wireless link. 
> 
> 
> Please, if possible en-light me on tis problem. I sat at your disposition
> with any info you may deem necessary to get this fixed (if it needs a fix).
> 
> 
> Dan
> 

I can confirm this behavior. It also happens to me.

- Nikolai Lifanov.
___
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: 10-RC2 current wireless link aggregation not working correctly

[Nikolai Lifanov]

On 12/17/13 10:54, Adrian Chadd wrote:
> Hi,
> 
> The MAC of the lagg needs to be the same as the wireless interface.
> 
> I'm going to just state right now that using lagg as the failover
> method for doing wireless/wired integration isn't supported by me. If
> someone wants to make it supported then they need to claim it. :)
> 
> 
> -a
> 
> 
> On 17 December 2013 05:06, dan_partelly  wrote:
>>
>> Hi all,
>>
>> I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
>> described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.
>>
>> What happens is:
>>
>> If I boot the system with the Ethernet cable attached, I correctly get
>> lagg0 active port on master- bg0- and the network is working correctly.
>> (I mainly test pinging my gateway). When I pull the cable out, lagg0
>> device correctly switches to wlan0 as shown by ifconfig (wlan0 is created
>> from wpi0), but at the same time I get no more ping replies from my
>> gateway. I can leave the system in this state for several minutes as an
>> example
>> and no replies are coming through. A simple list of interfaces with
>> ifconfig with no parameters brigs the network back to life, and I start to
>> get back the due ping replyes, this time thrugh wireless link.
>>
>>
>> Please, if possible en-light me on tis problem. I sat at your disposition
>> with any info you may deem necessary to get this fixed (if it needs a fix).
>>
>>
>> Dan
>>

It actually is, in my case.
The macs for em0, wlan0, and lagg0 all match.

I can always do the failover differently, but this used to work with
9.0-RELEASE-9.2-RELEASE.

- Nikolai Lifanov
___
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: 10-RC2 current wireless link aggregation not working correctly

[Nikolai Lifanov]

On 12/17/13 10:54, Adrian Chadd wrote:
> Hi,
> 
> The MAC of the lagg needs to be the same as the wireless interface.
> 
> I'm going to just state right now that using lagg as the failover
> method for doing wireless/wired integration isn't supported by me. If
> someone wants to make it supported then they need to claim it. :)
> 
> 
> -a
> 
> 
> On 17 December 2013 05:06, dan_partelly  wrote:
>>
>> Hi all,
>>
>> I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
>> described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.
>>
>> What happens is:
>>
>> If I boot the system with the Ethernet cable attached, I correctly get
>> lagg0 active port on master- bg0- and the network is working correctly.
>> (I mainly test pinging my gateway). When I pull the cable out, lagg0
>> device correctly switches to wlan0 as shown by ifconfig (wlan0 is created
>> from wpi0), but at the same time I get no more ping replies from my
>> gateway. I can leave the system in this state for several minutes as an
>> example
>> and no replies are coming through. A simple list of interfaces with
>> ifconfig with no parameters brigs the network back to life, and I start to
>> get back the due ping replyes, this time thrugh wireless link.
>>
>>
>> Please, if possible en-light me on tis problem. I sat at your disposition
>> with any info you may deem necessary to get this fixed (if it needs a fix).
>>
>>
>> Dan
>>

Also, this method is still described in the handbook:
https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless

If this isn't supposed to work, then the handbook needs to be updated.

- Nikolai Lifanov

___
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: 10-RC2 current wireless link aggregation not working correctly

[Nikolai Lifanov]

On 12/17/13 12:34, Allan Jude wrote:
> On 2013-12-17 10:54, Adrian Chadd wrote:
>> Hi,
>>
>> The MAC of the lagg needs to be the same as the wireless interface.
>>
>> I'm going to just state right now that using lagg as the failover
>> method for doing wireless/wired integration isn't supported by me. If
>> someone wants to make it supported then they need to claim it. :)
>>
>>
>> -a
>>
>>
>> On 17 December 2013 05:06, dan_partelly  wrote:
>>> Hi all,
>>>
>>> I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
>>> described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.
>>>
>>> What happens is:
>>>
>>> If I boot the system with the Ethernet cable attached, I correctly get
>>> lagg0 active port on master- bg0- and the network is working correctly.
>>> (I mainly test pinging my gateway). When I pull the cable out, lagg0
>>> device correctly switches to wlan0 as shown by ifconfig (wlan0 is created
>>> from wpi0), but at the same time I get no more ping replies from my
>>> gateway. I can leave the system in this state for several minutes as an
>>> example
>>> and no replies are coming through. A simple list of interfaces with
>>> ifconfig with no parameters brigs the network back to life, and I start to
>>> get back the due ping replyes, this time thrugh wireless link.
>>>
>>>
>>> Please, if possible en-light me on tis problem. I sat at your disposition
>>> with any info you may deem necessary to get this fixed (if it needs a fix).
>>>
>>>
>>> Dan
>>>
>>> ___
>>> 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"
>> ___
>> 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"
> 
> If I am am understanding correctly, Dan and Nikolai say that just
> running 'ifconfig' brings the lagg back to life. Why would that make a
> difference at all? Running ifconfig with no parameters shouldn't be
> changing anything.
> 

I see the same lagg behavior change going from 9.2->10.0, but for me the
test is slightly different. My wired and wireless networks use different
IP address ranges, so I need to re-run dhclient on lagg0, but I can't
get an address on it. In fact, dhclient doesn't work at all with a lagg
interface when it is only backed by my wireless card.
Without a lagg interface, I can get addresses on both wired and wireless
cards individually and act dual-homed just fine.

- Nikolai Lifanov

___
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: libinit idea

[Nikolai Lifanov]

On 2014-02-23 13:17, David Chisnall wrote:

On 23 Feb 2014, at 18:11, Allan Jude  wrote:


sysrc solves this nicely, it is in base now, and is great for
programmatically adding, removing and changing lines in rc.conf style
files. It is also in ports for older versions of FreeBSD where it is 
not

in base.


The problem is, there is no such thing as an rc.conf style file.
rc.conf is just a shell script.  If you only edit it with sysrc, or
you are careful to preserve the structure, then it's fine.  There is
absolutely nothing stopping you, however, from writing arbitrarily
complex shell scripts inside rc.conf.  Sure, it's a terrible idea to
do so, but when has that ever stopped anyone?

An rc-replacement could enforce this by only accepting purely
declarative files for configuration, guaranteeing that if they were
syntactically valid they would also be machine editable, no matter
what the user does to them.

David



Just my $0.02:

I don't believe our current RC is broken. It's faster than most, it 
supports an early-late divider, virtual targets (NETWORK, etc.), 
dependencies, etc.
Rewriting scripts (units) in C has a non-trivial cost to customization 
for end users. I have custom, packaged, RC scripts in /usr/local that 
are pretty easy to add and maintain. Shell script logic can go there and 
not in rc.conf proper. The rcorder program provides a pretty good idea 
for when these can be run, and, as already pointed out, sysrc can be 
used to add/remove/configure these on clusters of (automatically) 
managed machines. If all scripts a properly written, "service foo 
status" can also provide something that can be acted upon by 
configuration management systems.
Serialization is great (libnv), but it's just gravy. The only feature I 
see that's missing is (SMF-style) service management, but for hardware 
events, like losing a network link or a disk, can be plugged in to devd 
configuration, also easily. Also, in real-life deployments, shutting 
down service dependencies is not practical either. For example, if 
postfix crashes, I don't want to stop postgey or dovecot. I just want to 
nanny postfix back up rather than trying to bring up the whole stack. 
Also, forking a shell does not have any significant cost to it when 
bringing up something like MySQL, since it's a small fraction of where 
the system spends its time to bring up a useful service.


Rewriting scripts in C doesn't provide service management or give any 
on-demand (inetd, read: launchd) functionality.


- Nikolai Lifanov

___
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: libinit idea

[Nikolai Lifanov]

On 2014-02-23 13:47, David Chisnall wrote:

On 23 Feb 2014, at 18:31, Freddie Cash  wrote:

The main developer for systemd is very anti-portability and 
anti-!Linux. He

had actively rejected patches that made his projects work on non-Linux
systems. In order to port systemd to a non-Linux system, he wants you 
to

first implement every Linux feature that systemd uses.

systemd is a non-starter, and not with considering.


I don't think that's a relevant discussion.  The license would likely
preclude systemd from making it into the base system anyway.  Please
let's not be too negative about the author of systemd: he's
responsible for more people switching from Linux to FreeBSD than any
other single individual I can think of and I would strongly encourage
him to continue.



I also noticed this.


The relevant question is whether it does anything in a way that is
sufficiently sensible to merit a FreeBSD service management
infrastructure doing it in the same (or a similar) way.

Oh, two things missing from my original list:

- Service jails should be able to run without an init process, with
just the required libraries installed and the host machine's init
system starting the jail and the service process(es) inside it.



Isn't this a bit too complicated? If there is an init script under 
$jail/usr/local/etc/rc.d, then the host init will need to find it, which 
can be even more complicated if rc search path in the jail is customized 
(prefixed if it's managed by a different department, for example). Host 
init will have to read the jail configuration, parse it too, and then 
manage children and pids of the jailed services, including reparenting, 
all within a jail context. Then the admin in that jail would need to be 
able to restart services, affecting host init, which opens a whole new 
can of worms. If init program is skinny and not too complicated, which 
it is, there is no tangible overhead. And if a jail really needs a 
single simple service, init process in the jail can *be* that, like 
jexec myjail /bin/sh -c somestuff (or even /usr/local/bin/myservice -c 
myservice conf).



- The init system should use process descriptors, not pids, for
tracking processes, preventing issues with pid reuse and so on (and
removing the need to write pid files).  If process descriptors do not
provide the required functionality (e.g. the ability to trace forked
children) then this should be added.



This is a good idea.


David

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

___
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: libinit idea

[Nikolai Lifanov]

On 02/24/14 13:00, Don Lewis wrote:
> On 24 Feb, Thomas Mueller wrote:
>> from Don Lewis:
>>
>>> I've got a Fedora server here that has systemd and I've come to
>>> dislike it.  It seems to be one of those "Do not open.  No user
>>> serviceable parts inside." sorts of things.
>>   
>>> I was never able to get it to start NUT properly.
>>   
>>> More often than not, it fails to come up multi-user.  The machine has
>>> a large number of disks (mostly JFS and XFS) attached to it, and even
>>> after what I think should be a clean shutdown, it seems to want to
>>> fsck a bunch of them. Unfortunately, there seems to be some sort of
>>> timeout on that, so a bunch get skipped and then don't get mounted. 
>>> I have to manually fsck everything in single user mode.  Then if I
>>> reboot, it
>>> *might* come up properly.  I haven't been able to find any knobs to
>>> adjust the timeout.  Sometimes, there is just a message that says
>>> something like "an error occurred" at the top of the screen, just
>>> before the prompt for the single-user password, with no clue as to
>>> what it is unhappy about.
>>
>>> Emergency shutdown can also be a problem.  If I'm around when the
>>> power fails, I manually try to shut down the machine before the UPS
>>> battery runs down.  I don't have the screen on the UPS, so I hit the
>>> power button and cross my fingers that the machine will make it
>>> through the clean shutdown sequence in time.  It seems to take
>>> forever (many minutes) and I have no idea what the heck it is
>>> spending all of its time on.
>>
>>> The documentation seems to be very sparse.
>>
>>> My plan is to migrate this function to a FreeBSD server.
>>
>> This looks scandalously slow.  It reminds me of the time with OS/2
>> Warp 4 in the late 1990s when I had to close Netscape web browser in
>> preparation for shutdown, and it took 15 minutes because it was a hog
>> for memory, by late 1990s standards.  I had 20 MB RAM, not bad for
>> those days.
>>
>> What would happen if you typed at the command prompt
>> shutdown -r now
>> or
>> shutdown -p now
>> ?
>> Would it take seemingly forever?
> 
> In Linux-land "shutdown -h now" does what our "shutdown -p now" does.
> For whatever reason, doing shutdown that way seems faster.  That's not
> so handy for me in the power loss case because the machine is running X
> and is most likely sitting in the screensaver.  Switching to another
> vty, doing a root login, and typing in the shutdown command is a lot of
> typing to get right while flying blind without a monitor.
> 
> There might also be a slowdown due to the network being down, though
> it's hard to tell in my case.  I'm also not using NFS, which would be
> the obvious culprit.
> 
> I forgot to mention that the command line tools are feel cumbersome.  To
> restart a service:
>   FreeBSD:   /etc/rc.d/foo restart
>   Old Linux: /etc/init.d/foo restart
>   Systemd:   systemctl restart foo.service
> seems worse that that when I'm actually typing it ...
> 

The Handbook-recommended invocation, which also works on linux, is
"service foo restart".

>> Would it take seemingly forever?
>>
>> I would like to try systemd in Linux, can't say at this stage whether
>> I'll like it, hate it, or somewhere in between.
> 
> There's no substitute for firsthand experience.
> 

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

svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 04/01/14 12:02, Ryan Stone wrote:
> Author: rstone
> Date: Tue Apr  1 16:02:02 2014
> New Revision: 264011
> URL: http://svnweb.freebsd.org/changeset/base/264011
> 
> Log:
>   Add support for PCIe ARI
>   

With the changes between r264007-264011, my 4-port RocketRAID 640 card
in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
passthrough, tried looking for these disks with various tools, but no
luck. There is no trace of them being available in dmesg, etc.

I narrowed it down to that range of revisions, and
going back to r264006 makes the disks show up again.

- Nikolai Lifanov
___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 12:06, Benjamin Kaduk wrote:
> On Thu, 3 Apr 2014, David Wolfskill wrote:
> 
>> And on my laptop, I had no problems (using AHCI).  The build machine,
>> though, starts OK, then comes to an inglorious end:
>>
>> Trying to mount root from ufs:/dev/aacd0s4a [rw]...
>> mountroot: waiting for device /dev/aacd0s4a ...
>> Mounting from ufs:/dev/aacd0s4a failed with error 19.
>>
> [...]
>>
>> mountroot>
>>
>>
>> So... I have serial console access; is there any debugging I might
>> do to help figure out what's wrong?  Or is what's wrong already
>> known?
>>
>> I have been able to reboot from this point to one of the other
>> slices; I could probably also unload the default kernel & load
>> yesterday's (err... make that "the day before's" -- yesterday's
>> didn't build -- @r263983).
> 
> I'm also having some trouble booting (into single user mode, so as to
> run the installworld), at r264039.  It seems that ciss never attaches,
> so my da0 (which is supposed to be on ciss0) does not appear.  My
> kernel.old is much older, __FreeBSD_version 115, but does boot. 
> However, attempting to boot kernel.old in either single-user mode or
> verbse mode also drops me to mountroot> .  That would seem to indicate
> some hardware problem or timing issues more than a problem with the code
> itself, so I had been holding off on posting until I could get more
> information.
> 
> Unfortunately, my serial console is not working at the moment, so
> getting more information is a bit challenging.  Diffing the dmesg from
> the good and bad boots would probably be helpful for you to do.
> 
> -Ben

I reported a similar problem on freebsd-current@ earlier today.
Fortunately, my boot zpool is still fine, but a RocketRAID controller
only shows 2/4 disks, which just happens to be a full leg of another
raid10-like zpool.

Try reverting revisions r264007-264013. This fixes the problem for me.

- Nikolai Lifanov
___
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: svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 04/03/14 08:58, Nikolai Lifanov wrote:
> On 04/01/14 12:02, Ryan Stone wrote:
>> Author: rstone
>> Date: Tue Apr  1 16:02:02 2014
>> New Revision: 264011
>> URL: http://svnweb.freebsd.org/changeset/base/264011
>>
>> Log:
>>   Add support for PCIe ARI
>>   
> 
> With the changes between r264007-264011, my 4-port RocketRAID 640 card
> in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
> passthrough, tried looking for these disks with various tools, but no
> luck. There is no trace of them being available in dmesg, etc.
> 
> I narrowed it down to that range of revisions, and
> going back to r264006 makes the disks show up again.
> 
> - Nikolai Lifanov
> 

I updated to r264073 with revisions r264007-264013 reverted, and all my
disks show up. Could you look into this please? I'll provide any
information that can be helpful.

- Nikolai Lifanov

___
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: svn commits r264007-264011: disks missing

[Nikolai Lifanov]

On 2014-04-03 12:23, Konstantin Belousov wrote:

On Thu, Apr 03, 2014 at 12:17:13PM -0400, Nikolai Lifanov wrote:

On 04/03/14 08:58, Nikolai Lifanov wrote:
> On 04/01/14 12:02, Ryan Stone wrote:
>> Author: rstone
>> Date: Tue Apr  1 16:02:02 2014
>> New Revision: 264011
>> URL: http://svnweb.freebsd.org/changeset/base/264011
>>
>> Log:
>>   Add support for PCIe ARI
>>
>
> With the changes between r264007-264011, my 4-port RocketRAID 640 card
> in JBOD mode just lost (?) 2 out of 4 disks. I disabled bhyve pci
> passthrough, tried looking for these disks with various tools, but no
> luck. There is no trace of them being available in dmesg, etc.
>
> I narrowed it down to that range of revisions, and
> going back to r264006 makes the disks show up again.
>
> - Nikolai Lifanov
>

I updated to r264073 with revisions r264007-264013 reverted, and all 
my

disks show up. Could you look into this please? I'll provide any
information that can be helpful.


I think verbose dmesg from failing and running kernel should be good
for the start.


Sure, here!

http://lifanov.com/files/freebsd/bugs/dmesg.broken.txt
http://lifanov.com/files/freebsd/bugs/dmesg.working.txt

- Nikolai Lifanov

___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 14:05, Ryan Stone wrote:
> Can somebody please confirm whether setting hw.pci.enable_ari=0 in the
> loader fixes the issue or not.  That will help me to figure out if the
> issue is with ARI or if I have somehow broken PCI enumeration in
> general (I suspect the later).
> __

I already tried it.
I can confirm that it does not help.

- Nikolai Lifanov


___
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: Boot fails @r264070

[Nikolai Lifanov]

On 04/03/14 14:25, Nikolai Lifanov wrote:
> On 04/03/14 14:05, Ryan Stone wrote:
>> Can somebody please confirm whether setting hw.pci.enable_ari=0 in the
>> loader fixes the issue or not.  That will help me to figure out if the
>> issue is with ARI or if I have somehow broken PCI enumeration in
>> general (I suspect the later).
>> __
> 
> I already tried it.
> I can confirm that it does not help.
> 
> - Nikolai Lifanov
> 

In fact, here is what it looks like: the disk discovery skips the first
2 and enumerates the rest. Thankfully, this isn't my boot pool and
rebooting without ARI changes discovers every disk and imports it correctly.

$ sysctl hw.pci.enable_ari
hw.pci.enable_ari: 0
$ zpool status data
  pool: data
 state: UNAVAIL
status: One or more devices could not be opened.  There are insufficient
replicas for the pool to continue functioning.
action: Attach the missing device and online it using 'zpool online'.
   see: http://illumos.org/msg/ZFS-8000-3C
  scan: none requested
config:

NAME STATE READ WRITE CKSUM
data UNAVAIL  0 0 0
  mirror-0   UNAVAIL  0 0 0
820204606399244410   UNAVAIL  0 0 0  was /dev/ada0
7129954888383586426  UNAVAIL  0 0 0  was /dev/ada1
  mirror-1   ONLINE   0 0 0
ada0 ONLINE   0 0 0
    ada1 ONLINE   0 0 0

- Nikolai Lifanov

___
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: buildworld of HEAD failing under 8.1-RELEASE

[Nikolai Lifanov]

On 05/02/2013 02:28 PM, Ryan Stone wrote:
> I am getting the following error when trying to build HEAD on an
> 8.1-RELEASE build machine (i386 jail on an amd64 host):
> 
> ===> lib/clang/libllvmanalysis (all)
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:
> In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*,
> llvm::ArrayRef, const llvm::TargetLibraryInfo*)':
> /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310:
> error: 'log2' was not declared in this scope
> *** [ConstantFolding.o] Error code 1
> 1 error
> *** [all] Error code 2
> 1 error
> *** [cross-tools] Error code 2
> 1 error
> *** [_cross-tools] Error code 2
> 1 error
> *** Error code 2
> 1 error
> 
> Is there anything that I can do other than build on another machine?  I
> don't control the build machines at $WORK so I'm not sure whether I can get
> them upgraded. :(
> ___
> 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"
> 

I think, per http://svnweb.freebsd.org/base/head/UPDATING?view=co
You need to bootstrap clang by building a recent version WITHOUT_CLANG
and then removing the version.

- Nikolai Lifanov

___
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: Cannot build ports on fresh 10.0

[Nikolai Lifanov]

On 06/04/13 18:07, hiren panchasara wrote:

On Tue, Jun 4, 2013 at 2:42 PM,   wrote:

I installed a new VM with 10.0 today from this .iso:

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/amd64/10.0/FreeBSD-10.0-CURRENT-amd64-20130601-r251213-release.iso

And I'm behind a firewall and I'm not sure I can use pkg(1); my one attempt
failed:

# pkg install m4
Updating repository catalogue
Repository catalogue is up-to-date, no need to fetch fresh copy
pkg: Package 'm4' was not found in the repositories

So I'm building from source.  But the configure step of various ports fails
like so:

checking whether make sets $(MAKE)... yes
checking build system type... Invalid configuration
`amd64-portbld-freebsd10.0': machine `amd64-portbld' not recognized
configure: error: /bin/sh libltdl/config/config.sub
amd64-portbld-freebsd10.0 failed
===>  Script "configure" failed unexpectedly.
Please report the problem to autoto...@freebsd.org [maintainer] and attach
the "/usr/ports/devel/libtool/work/libtool-2.4.2/config.log" including the
output of the failure of your make command. Also, it might be a good idea to
provide an overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1


_Probably_ similar to this?
http://lists.freebsd.org/pipermail/freebsd-ports/2013-June/084040.html

cheers,
Hiren


Any ideas what could be wrong?  It's a fresh install with default options,
so it seems hard to believe I managed to screw something up already.
Posting on -current since this happens to many of the ports when I try to
build them.

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

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



What you see has been fixed in ports r319875.
You can sync your tree to past that and try again.
Also, you can try the same proxy settings from libfetch.

- Nikolai Lifanov

___
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: https://svn0.us-east.freebsd.org/base/head is not on 1.8 yet?

[Nikolai Lifanov]

On 06/20/13 10:32, Anton Shterenlikht wrote:

  svn --version
svn, version 1.8.0 (r1490375)
compiled Jun 20 2013, 09:21:02 on amd64-portbld-freebsd10.0

# svn up
Updating '.':
svn: E17: Unrecognized URL scheme for 
'https://svn0.us-east.freebsd.org/base/head'

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



You need SERF option, since NEON is gone.
Read /usr/ports/UPDATING

- Nikolai Lifanov

___
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: FUSE not work.

[Nikolai Lifanov]

dy  -Wno-error-parentheses-equality  -c fuse_vfsops.c
cc -Oz -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe
-Qunused-arguments -Qunused-parameter -Wformat -Wformat-security
-D_KERNEL -DKLD_MODULE -nostdinc  -I../include -I. -I@ -I@/contrib/altq
-fno-common  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse
-msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -Qunused-arguments -fstack-protector
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions  -Wmissing-include-dirs
-fdiagnostics-show-option  -Wno-error-tautological-compare
-Wno-error-empty-body  -Wno-error-parentheses-equality  -c fuse_vnops.c
In file included from fuse_vnops.c:36:
@/vm/vm_pager.h:126:2: warning: implicit declaration of function
'rw_assert' is invalid in C99 [-Wimplicit-function-declaration]
 VM_OBJECT_ASSERT_WLOCKED(object);
 ^
@/vm/vm_object.h:226:2: note: expanded from macro
'VM_OBJECT_ASSERT_WLOCKED'
 rw_assert(&(object)->lock, RA_WLOCKED)
 ^
In file included from fuse_vnops.c:36:
@/vm/vm_pager.h:126:2: error: use of undeclared identifier 'RA_WLOCKED'
@/vm/vm_object.h:226:29: note: expanded from macro
'VM_OBJECT_ASSERT_WLOCKED'
 rw_assert(&(object)->lock, RA_WLOCKED)
^
In file included from fuse_vnops.c:36:
@/vm/vm_pager.h:143:2: error: use of undeclared identifier 'RA_WLOCKED'
 VM_OBJECT_ASSERT_WLOCKED(object);
 ^
@/vm/vm_object.h:226:29: note: expanded from macro
'VM_OBJECT_ASSERT_WLOCKED'
 rw_assert(&(object)->lock, RA_WLOCKED)
^
In file included from fuse_vnops.c:36:
@/vm/vm_pager.h:167:2: error: use of undeclared identifier 'RA_WLOCKED'
 VM_OBJECT_ASSERT_WLOCKED(object);
 ^
@/vm/vm_object.h:226:29: note: expanded from macro
'VM_OBJECT_ASSERT_WLOCKED'
 rw_assert(&(object)->lock, RA_WLOCKED)
^
In file included from fuse_vnops.c:36:
@/vm/vm_pager.h:190:2: error: use of undeclared identifier 'RA_WLOCKED'
 VM_OBJECT_ASSERT_WLOCKED(m->object);
 ^
@/vm/vm_object.h:226:29: note: expanded from macro
'VM_OBJECT_ASSERT_WLOCKED'
 rw_assert(&(object)->lock, RA_WLOCKED)
^
fuse_vnops.c:3397:3: warning: implicit declaration of function
'VM_OBJECT_LOCK' is invalid in C99 [-Wimplicit-function-declaration]
 VM_OBJECT_LOCK(vp->v_object);
 ^
fuse_vnops.c:3398:3: warning: implicit declaration of function
'vm_page_lock_queues' is invalid in C99 [-Wimplicit-function-declaration]
 vm_page_lock_queues();
 ^
fuse_vnops.c:3406:4: warning: implicit declaration of function
'vm_page_unlock_queues' is invalid in C99 [-Wimplicit-function-declaration]
 vm_page_unlock_queues();
 ^
fuse_vnops.c:3407:4: warning: implicit declaration of function
'VM_OBJECT_UNLOCK' is invalid in C99 [-Wimplicit-function-declaration]
 VM_OBJECT_UNLOCK(vp->v_object);
 ^
5 warnings and 4 errors generated.
*** Error code 1

Stop.
make: stopped in
/usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0/fuse_module
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/fusefs-kmod/work/fuse4bsd-498acaef33b0
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/fusefs-kmod
*** Error code 1

Stop.
make: stopped in /usr/ports/sysutils/fusefs-kmod

===>>> make failed for sysutils/fusefs-kmod
===>>> Aborting update

===>>> Killing background jobs
Terminated
Terminated

===>>> You can restart from the point of failure with this command line:
portmaster  sysutils/fusefs-kmod

===>>> Exiting

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


You don't need sysutils/fusefs-kmod, since FreeBSD 10 includes FUSE in 
base. Reverse dependencies (sysutils/fusefs-curlftpfs, etc.) will 
correctly skip building it.


This ought to use logic like that from emulators/virtio-kmod/Makefile.

- Nikolai Lifanov

___
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: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present

[Nikolai Lifanov]

On 08/08/13 14:10, O. Hartmann wrote:

The most recent CURRENT doesn't work with the x11/nvidia-driver (which
is at 319.25 in the ports and 325.15 from nVidia).

After build- and installworld AND successfully rebuilding port
x11/nvidia-driver, the system crashes immediately after a reboot as
soon the kernel module nvidia.ko seems to get loaded (in my case, I
load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't
load cleanly everytime when loaded from /boot/loader.conf).

The crash occurs on systems with default compilation options set while
building world and with settings like -O3 -march=native. It doesn't
matter.

FreeBSD and the port x11/nvidia-driver has been compiled with CLANG.

Most recent FreeBSD revision still crashing is r254097.

When vmcore is saved, I always see something like

savecore: reboot after panic: vm_radix_insert: key 23c078 is already
present


Does anyone has any idea what's going on?

Thanks for helping in advance,

Oliver



I don't know what might be going on, but another piece of data:
I can say that it works on r254097 with -O2 -march=corei7-avx

- Nikolai Lifanov

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