Re: More CARP issues under 12 (maybe not CARP after all)

2019-02-04 Thread Pete French
> > To point out the obvious, booting a 12.0 kernel with 11.0 userland to 
> > multiuser mode is seriously unsupported. You really need to boot to 
> > single user and install 12.0 userland to really expect things to work.
>
> Yes, good point. This has worked on every other machine I have upgraded 
> from 11 to 12, which is why I didnt think of that, but then all the 
> motherboards are slightly different.

So, I went back to this, and di it properly. Booted single user mode,
which worked, then installed world, mergemaster, and rebooted single
user mode.

...and I get a kernel panic as I did before. So it wasn't the 11 world with
the 12 kernel after all. Panic is reproduced below. I am somewhat stuck
now though - where do I go from here ?

Feeding entropy
lo0: link state changed to UP
carp: demoted by 240 to 240 (interface down)


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x28
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80ca1621
stack pointer   = 0x28:0xfe4da740
frame pointer   = 0x28:0xfe4da760
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock (0))
trap number = 12
panic: page fault
cpuid = 0
time = 1549292394
KDB: stack backtrace:
#0 0x80be8d57 at kdb_backtrace+0x67
#1 0x80b9d293 at vpanic+0x1a3
#2 0x80b9d0e3 at panic+0x43
#3 0x8107384f at trap_fatal+0x35f
#4 0x810738a9 at trap_pfault+0x49
#5 0x81072ece at trap+0x29e
#6 0x8104ee55 at calltrap+0x8
#7 0x80ca1526 at ether_output+0x6b6
#8 0x80d0c824 at arprequest+0x4c4
#9 0x80d0e47c at garp_rexmit+0xbc
#10 0x80bb7169 at softclock_call_cc+0x129
#11 0x80bb7649 at softclock+0x79
#12 0x80b613a4 at ithread_loop+0x1d4
#13 0x80b5e2d2 at fork_exit+0x82
#14 0x8104fe3e at fork_trampoline+0xe
Uptime: 11s


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


devel/jenkins upgrade glitch (was: Re: Minor 11.1 -> 11.2 upgrade glitch)

2019-02-04 Thread Marc Branchaud

On 2018-09-17 11:07 a.m., Marc Branchaud wrote:

Hi all,

I have a ZFS dataset mounted under /usr/local/jenkins.  I've made this 
the home directory of my jenkins user, so that directory has to be owned 
by jenkins.


 # cd /usr/local
 # ls -ld jenkins
 drwxr-xr-x  20 jenkins  jenkins  75 Sep 17 10:48 jenkins

After upgrading from 11.1 to 11.2, the directory ended up owned by root:

 drwxr-xr-x  20 root  jenkins  75 Sep 17 10:48 jenkins


Some follow-up info...

I have contacted devel/jenkins's maintainer, Li-Wen Hsu, and have opened 
a new bug:

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

Li-Wen reports that he can't reproduce the problem in 12.0 or CURRENT, 
with pkg 1.10.5_5.  (I am also using pkg 1.10.5_5, but on 11.2.)


A very similar (possibly identical) bug in was fixed in 2014:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193670

The issue was also in devel/jenkins-lts, also fixed in 2014:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194274

M.


Only the directory ownership changed -- all the contents were still 
owned by jenkins.


Not a big deal, but I did have a moment of dread when jenkins failed to 
start after the upgrade.


So is this a bug, or is there some policy that everything immediately 
under /usr/local should be owned by root?


     M.

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