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

Re: [bmake] bmake sigint handling causing tty corruption

[Simon J. Gerraty]

Konstantin Belousov  wrote:
> I just find is somewhat strange that make initiates a new session.

In jobs mode it does - to ensure the child and all progeny can be killed
in one fell swoop.
In compat mode it does not, but that does not mean the child cannot do
so.

> Did you verified that enabling the wait code in make(1) fixes the issue ?

FWIW it is a reasonably simple patch to make to wait for child to exit
before self termination.

--sjg
___
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: Attn: CI/Jenkins people; Run bhyve instance for testing pf

[Nikos Vassiliadis]

On 07/18/2017 02:55 AM, Panagiotes Mousikides wrote:

Den 2017-07-16 kl. 21:11, skrev Alan Somers:

On Sun, Jul 16, 2017 at 2:44 PM, Panagiotes Mousikides
 wrote:

Hello everybody!

I am working on adding tests to the FreeBSD test suite for testing 
pf, the

network packet filter.

These tests need at least two machines running and connected to each 
other,

with one machine generating network traffic and the other running pf and
filtering the traffic.  I am looking for a way to fire off a bhyve 
instance

to serve as the second machine, the first being the actual machine I am
running the tests on. This should be done completely automatically, with
scripts to configure all network interfaces and to preferably also 
set up an

SSH server on the bhyve instance.

This bhyve instance could start off as running the latest stable 
version of

FreeBSD, or it could be configured to run a snapshot of the development
tree.  The aim is to have the desired version of FreeBSD that we want to
test running on it.  Ideally this would be done in such a way that we 
can
reuse the machine for further tests, instead of rebuilding everything 
from

scratch for each test.

What I am looking for is the best way to do this, preferably so that 
it can
be easily integrated into the CI work being done at Jenkins.  What do 
you

think?  Any input is welcome!

All the best,
Panagiotes

It's possible to setup CI systems that involve multiple machines
networked together.  I've done it.  But it's complicated, fragile, and
slow.  I advise you to consider very carefully whether you truly need
multiple VMs.  What about creating an epair(4)?  You could run pf on
epair0b and generate traffic from epair0a.  That would be faster than
spinning up VMs, and would be very easy to integrate into any other CI
system.  Would that work?

-Alan


Hi Alan!

Thank you for the tip about epair(4), it sounds really like an 
interesting approach to my problem.  I will look into it!


Best regards,
Panagiotes


Hi,

It would be great if you use vnet jails for that. I am not
sure regarding the per-vnet pf functionality but I have seen
many bug fixes hitting the tree since last year. You can ask
on freebsd-virtualizat...@freebsd.org or freebsd...@freebsd.org
to learn more about it.

Pf within a jail should behave more or less like the "normal" one.
Plus you will be testing per-vnet functionality, which the project
needs anyhow, in one go.

Best regards,
Nikos




___
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: [bmake] bmake sigint handling causing tty corruption

[Konstantin Belousov]

On Tue, Jul 18, 2017 at 11:57:00PM +0300, Dmitry Marakasov wrote:
> Hi!
> 
> Me and Ilya Arkhipov were investigating the cause of this bug:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215572
> 
> In short, when FreeBSD ports options dialog is interrupted by Ctrl+C,
> there's chance of sporadic terminal corruption. They are not always
> reproducible and seem to be dependent on a machine, shell, terminal,
> tmux used, but are not tied to any specific configuration.
> 
> The investigation led us to the following conclusion:
> 
> - the corruption is caused by dialog4ports program (which handles ports
>   options dialogs) not being able to restore terminal state on exit
> - dialog4ports does indeed try to restore terminal state, but the
>   corresponding ioctl (TIOCSETAW) fails with EIO
> - examining kern/tty.c suggests that this happens likely because the make
>   which is the session leader or something dies before dialog4ports
> - which led us to bmake as a culprit
> 
> Here's the ktrace of the problem (the process hierarchy here is make ->
> sh -> dialog4ports)
> 
> ---
> 78337 dialog4ports CALL  sigaction(SIGTSTP,0x800a80228,0)
> 78337 dialog4ports RET   sigaction 0
> 78337 dialog4ports CALL  clock_gettime(0xd,0x7fffde08)
> 78337 dialog4ports RET   clock_gettime 0
> 78337 dialog4ports CALL  gettimeofday(0x7fffdc90,0)
> 78337 dialog4ports RET   gettimeofday 0
> 78337 dialog4ports CALL  poll(0x7fffdca0,0x2,0x)
> 
> (make and sh receive SIGINT first)
> 
> 78265 make RET   wait4 RESTART
> 78335 sh   RET   wait4 -1 errno 4 Interrupted system call
> 78265 make PSIG  SIGINT caught handler=0x402530 mask=0x0 code=SI_KERNEL
> 78335 sh   PSIG  SIGINT caught handler=0x41b950 mask=0x0 code=SI_KERNEL
> 78265 make CALL  lstat(0x800ab9900,0x7fffd1f0)
> 78265 make NAMI  "do-config"
> 78335 sh   CALL  sigreturn(0x7fffd280)
> 78335 sh   RET   sigreturn JUSTRETURN
> 78265 make RET   lstat -1 errno 2 No such file or directory
> 78335 sh   CALL  wait4(0x,0x7fffd6ec,0,0)
> 78265 make CALL  sigaction(SIGINT,0x7fffd250,0x7fffd230)
> 78265 make RET   sigaction 0
> 78265 make CALL  kill(0x131b9,SIGINT)
> 78265 make RET   kill 0
> 78265 make CALL  sigreturn(0x7fffd2d0)
> 78265 make RET   sigreturn JUSTRETURN
> 
> (make kills itself)
> 
> 78265 make PSIG  SIGINT SIG_DFL code=SI_USER
> 
> (dialog4ports finally starts to process the signal)
> 
> 78337 dialog4ports RET   poll -1 errno 4 Interrupted system call
> 78337 dialog4ports PSIG  SIGINT caught handler=0x800855e00 mask=0x0 
> code=SI_KERNEL
> 78337 dialog4ports CALL  sigaction(SIGINT,0x7fffd7c0,0)
> 78337 dialog4ports RET   sigaction 0
> 78337 dialog4ports CALL  ioctl(0x1,TIOCGETA,0x7fffd770)
> 78337 dialog4ports RET   ioctl 0
> 78337 dialog4ports CALL  write(0x1,0x801676a00,0x17)
> 78337 dialog4ports GIO   fd 1 wrote 23 bytes
> 78337 dialog4ports RET   write 23/0x17
> 
> (this call should restore terminal state, but it fails)
> 
> 78337 dialog4ports CALL  ioctl(0x1,TIOCSETAW,0x80161604c)
> 78337 dialog4ports RET   ioctl -1 errno 5 Input/output error
> 78337 dialog4ports CALL  exit(0x1)

It is indeed likely that this is due to terminal access from the orphaned
process group.  To make it completely sure diagnostic, you need to look
at the terminal state and at the process state, including the process group,
process session and the orphaned state.

I just find is somewhat strange that make initiates a new session.
Shell should not create a new session, since passed arguments (a command
to execute) should make it non-interactive.

Did you verified that enabling the wait code in make(1) fixes the issue ?
___
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: Critique this plan?

[Matthew Seaman]

On 2017/07/20 11:22, Jeffrey Bouquet wrote:
>   It seems I've a brick wall [too many ports to use pkg effectively ] -- [ 
> 3551 ] 
> and too many need ' pkg lock ' in ' v11 ' for ino64 fixes, 12.0-CURRENT, and 
> quite a few
> others fail to build from ports, either compiler, so are also 'pkg lock ' or 
> in a few
> instances binaries/trees copied from other installs, so that my DESKTOP can 
> continue
> running a if it were 2003 Microsoft based, vs 2004 Freebsd January based, 
> where a reinstall
> seems in order OR, I should just sit and wait til 13.0-CURRENT and proceed 
> that way.

You're proposing to make a backup of your system in spare space on your
hard drive, and then install a pristine system and backport your various
changes to it in order to bring your system up to date?

Waiting for 13.0-CURRENT probably won't solve all your compilation and
package management problems, or at least, not all of them.  You'ld be
better off updating now, but trying to clean up all your local changes
as far as possible so that future upgrades are less traumatic.

> ..
>   Meantime, how is the following as a workaround
>   mv /usr/src /src-2017
>   mv /usr/obj /obj-2017
>   mkdir -p /usr/src
>   mkdir -p /usr/obj
>   cd /usr/src
>   bw, etc
> 
> or
> .
>  [ clean install ]
>  mount -t ufs /dev/gpt/2004root /mnt-root
>  mount -t ufs /dev/gpt/2004var  /mnt-var
>  mount -t ufs /dev/gpt/2004tmp  /mnt-tmp
>   mount -t ufs /dev/gpt/2004usr /mnt-usr
>  into which I surmise an installworld would fail as multiple DESTDIRS are 
> included. 

You can do:

mount -t ufs /dev/gpt/2004root /mnt
mount -t ufs /dev/gpt/2004var  /mnt/var
mount -t ufs /dev/gpt/2004tmp  /mnt/tmp
mount -t ufs /dev/gpt/2004usr  /mnt/usr

so your copy of your 2004 system is laid out below /mnt as it would be
when live.  If you also do:

mount -t devfs devfs /mnt/dev

then you can chroot into /mnt, although I'm not sure quite how useful
that would be to you.

> .
>   nullfs ?
> ...
>  Revert to all-in-one / system, no /var /tmp /usr?
> .
>  or some new install 
> .
>   None of these are plans as of yet, save proceeding without any upgrade 
> whatsoever.  I recall
> unpacking base.txz [etc] to fix a failing installworld in the recent past, so 
> any foolproof
> method of that would also be welcome.  But I suspect much would remain 
> undone, 
> initial *proper* setup of /etc/mail, /etc/groups, as well as the loss of 
> fine-tunings I've
> done over the past 13 years or so, if it were done preplanned as a 
> new-then-rsync-the-old
> system-over-it sort of reinstall  [ not looking forward to undoing years of 
> week-by-week
> this-rc  that-rc fixups...  newbie in so many areas who just copy-pasted 
> the
> work of others into this system, to excellent, usually effect.] 
> .. 

Yeah.  You've a lot of work ahead reviewing each of your changes and
porting what you need to the new version.

As a matter of routine system maintenance, it is good practice to try
and revert local changes and track updates to the default system when
possible -- ie. to adopt any upstream fixes as they become available.

>   Apologies for the email that went on three times longer [ more verbose  ] 
> than I planned, sort
> of making its Subject:a  misstatement of the body of the email.
> ..
> ...

If you're planning on working from a new install, my advice would be to
summarize what functionality you want from your system as a series of
bullet points and then only port whichever of your changes you need in a
directed fashion to achieve each of those points.  Do this as cleanly as
possible, so you can achieve your required functionality with the
minimum amount of configuration work / local patches.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

Critique this plan?

[Jeffrey Bouquet]

  It seems I've a brick wall [too many ports to use pkg effectively ] -- [ 3551 
] 
and too many need ' pkg lock ' in ' v11 ' for ino64 fixes, 12.0-CURRENT, and 
quite a few
others fail to build from ports, either compiler, so are also 'pkg lock ' or in 
a few
instances binaries/trees copied from other installs, so that my DESKTOP can 
continue
running a if it were 2003 Microsoft based, vs 2004 Freebsd January based, where 
a reinstall
seems in order OR, I should just sit and wait til 13.0-CURRENT and proceed that 
way.
..
  Meantime, how is the following as a workaround
  mv /usr/src /src-2017
  mv /usr/obj /obj-2017
  mkdir -p /usr/src
  mkdir -p /usr/obj
  cd /usr/src
  bw, etc

or
.
 [ clean install ]
 mount -t ufs /dev/gpt/2004root /mnt-root
 mount -t ufs /dev/gpt/2004var  /mnt-var
 mount -t ufs /dev/gpt/2004tmp  /mnt-tmp
  mount -t ufs /dev/gpt/2004usr /mnt-usr
 into which I surmise an installworld would fail as multiple DESTDIRS are 
included. 
.
  nullfs ?
...
 Revert to all-in-one / system, no /var /tmp /usr?
.
 or some new install 
.
  None of these are plans as of yet, save proceeding without any upgrade 
whatsoever.  I recall
unpacking base.txz [etc] to fix a failing installworld in the recent past, so 
any foolproof
method of that would also be welcome.  But I suspect much would remain undone, 
initial *proper* setup of /etc/mail, /etc/groups, as well as the loss of 
fine-tunings I've
done over the past 13 years or so, if it were done preplanned as a 
new-then-rsync-the-old
system-over-it sort of reinstall  [ not looking forward to undoing years of 
week-by-week
this-rc  that-rc fixups...  newbie in so many areas who just copy-pasted the
work of others into this system, to excellent, usually effect.] 
.. 
  Apologies for the email that went on three times longer [ more verbose  ] 
than I planned, sort
of making its Subject:a  misstatement of the body of the email.
..
...
___
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"