Re: Followup on packaging base with pkg(8)

[Ngie Cooper]

On Thu, May 19, 2016 at 1:31 PM, Glen Barber  wrote:
> Dear FreeBSD community:

...

> Thank you to everyone who supported this effort, and we hope you will
> continue to support and test the forward development of packaging the
> base system with pkg(8).

Thank you too both bapt and gjb. This is a non-trivial effort to
achieve and what's been done so far is a really good first milestone.

I think it's a good idea to get beta feedback for 11.x... It'll allow
the design to get a wider audience and allows it to get some runtime
beyond CURRENT, that way it can mature and improve before too many of
the pieces are put in a place that it'll be hard to change once things
have been setup in a production way.

Thank you again!
-Ngie
___
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: Followup on packaging base with pkg(8)

[Michael Gmelin]

> On 19 May 2016, at 23:29, jungle Boogie  wrote:
> 
>> On 19 May 2016 at 13:31, Glen Barber  wrote:
>> Given the state of this highly-disruptive change to the base system, we
>> need to take the best interest of the FreeBSD community into primary
>> consideration, as a whole.
>> 
>> We have arrived at the difficult decision to treat packaged base as
>> a "beta" feature for 11.0-RELEASE, and continue with freebsd-update(8)
>> as the primary binary upgrade mechanism for this release.
> 
> 
> This is a very sensible solution.
> I think we can all agree we'd rather have something known to work over
> an unknown, lightly tested highly friction change.
> 
> Keep up the great work and rest easier knowing pkg will be a beta thing. :)
> 

Same here, thank you so much for your hard work on something that will be a big 
step forward and also for being realistic enough to not forcing things before 
they're ready!

- Michael



___
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: Followup on packaging base with pkg(8)

[jungle Boogie]

On 19 May 2016 at 13:31, Glen Barber  wrote:
> Given the state of this highly-disruptive change to the base system, we
> need to take the best interest of the FreeBSD community into primary
> consideration, as a whole.
>
> We have arrived at the difficult decision to treat packaged base as
> a "beta" feature for 11.0-RELEASE, and continue with freebsd-update(8)
> as the primary binary upgrade mechanism for this release.


This is a very sensible solution.
I think we can all agree we'd rather have something known to work over
an unknown, lightly tested highly friction change.

Keep up the great work and rest easier knowing pkg will be a beta thing. :)

Thanks!

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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: Followup on packaging base with pkg(8)

[Kirk McKusick]

Glen,

I realize that you have put an enormous amount of effort into
getting the packaging of base with pkg(8) into the 11.0 release
and am sorry to hear that it needs to be delayed. But having
watched the mailing lists during these efforts I realize that
it is a much more difficult problem than it would at first
appear to be. Thank-you for your efforts to date and I look
forward to the transition (hopefully in the 11.1 release) as
I believe it will be a huge step forward.

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

Followup on packaging base with pkg(8)

[Glen Barber]

Dear FreeBSD community:

Early this year, it was announced [1] that FreeBSD 11.0-RELEASE would
ship not only with the ability to package the base system with pkg(8),
but the intent to use pkg(8) as the primary binary upgrade mechanism for
the base system.

Despite the schedule adjustment for 11.0-RELEASE to allow additional
time to resolve several issues prior to the merge to head, too many
issues remained.  Following the merge to head, many more issues were
discovered, some resolved, but many without a clear, non-disruptive
solution.

Given the state of this highly-disruptive change to the base system, we
need to take the best interest of the FreeBSD community into primary
consideration, as a whole.

We have arrived at the difficult decision to treat packaged base as
a "beta" feature for 11.0-RELEASE, and continue with freebsd-update(8)
as the primary binary upgrade mechanism for this release.

Development on this change will continue in head and stable/11 (when it
is branched), however, with the target goal of transitioning to pkg(8)
for the base system for 11.1-RELEASE.

We fully intend to do this in a way that does not constitute a POLA
violation, especially on an established -STABLE branch.  The details on
how we will attempt this transition are still to be determined, however
all technical, solvable details.  But we will ensure as best as we can
to avoid violating POLA for the transition while the remaining issues
are resolved.

At this point, the risks far outweigh the benefits, especially taking
into consideration some of the more recent fallout of several changes.

Thank you to everyone who supported this effort, and we hope you will
continue to support and test the forward development of packaging the
base system with pkg(8).

Thank you.

[1] https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-January/00.html

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: boot broken on VMWare somewhere between r300069 and r300176

[O. Hartmann]

On Thu, 19 May 2016 14:04:59 +0300
Andriy Gapon  wrote:

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

We updated several systems of different ages and CPU generations
(around 10) to 300158. Bare metal. The systems all failed to boot, they
got stuck after the USB system has been probed (according to the kernel
messages). Some boxes get stuck after the message of the generation of
the UUID occured. Pushing the Powerbutton performs a clean shutdown,
although - so te system seems still alive, but usually the power is
turning off - this time, the box is stuck with the uptime message.

On random reboots some of the boxes boot. But the desaster then starts.
The network is highly unstable and flaky - while I can ping hosts or
resolve their IP by a DNS, I can not login via ssh, the webservices of
the webserver of the machines in question are inaccessible as well as
their databases (PostgreSQL) as well as ssh.

And it is more frustrating: I can't update or go back with svn
(either /usr/bin/svn or /usr/local/bin/svn) within the sources to
avoid this mess. In all cases, svn "times out".

Accessing the web from clients with the broken CURRENT code also ends
up in a wild guess game: sometimes the connection to services can be
established, sometimes not and I see a timeout. With svn
in /usr/src, on one box I could obtain a poor fragment of the code via
"svn update -r 35" (35 was in my case the starting point when
everything was up an running and working).

In short words: reverting back to r300113 isn't possible on the most
systems!

This problem has been present immediately after 300158 has been
introduced and build-world/build-kernel has been performed and the
fact, that different hardware, including NICs, has been affected, does
not narrow down the problem to a specific NIC, CPU type or hardware.
And that leads me to the question whether the code injected into
CURRENT gets tested - or not. If there would be a test, I guess the
problem would have revealed itself immediately.

I boot via UEFI as well as BIOS - the problem is with both.

In such a case as described with a nonworking svn, how am I supposed
to revert to the supposedly working revision r300113?

Kind regards and thanks in advance for your suggestions,

O. Hartmann 


P.S.

I'm using IPFW on all systems. Disabling IPFW (ipfw disable firewall) seems to 
releafe
the symptoms a bit - no matter whether custom scripts were used or the settings 
from
rc.conf.


pgpiWgUnpJr8J.pgp
Description: OpenPGP digital signature

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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

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

 Boot with r300062 works fine.
>>>
>>> A wild guess (not really), try to revert r300113
>>
>> Tried that, conflict on reverting this single revision and an error
>> compiling kernel. (No more details, sorry, busy at work for now)
>>
> 
> Alexander has committed a fix, so upgrading to the latest version can be a
> better strategy now.

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

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

Re: boot broken on VMWare somewhere between r300069 and r300176

[Andriy Gapon]

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

Alexander has committed a fix, so upgrading to the latest version can be a
better strategy now.

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

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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

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

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

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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

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

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

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

Re: boot broken on VMWare somewhere between r300069 and r300176

[Andriy Gapon]

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

A wild guess (not really), try to revert r300113

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

Re: boot broken on VMWare somewhere between r300069 and r300176

[Konstantin Belousov]

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

Break into ddb and show the 'ps' command output.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: boot broken on VMWare somewhere between r300069 and r300176

[Boris Samorodov]

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

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

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

Re: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Conrad Meyer wrote:
> On Wed, May 18, 2016 at 5:19 PM, Don Lewis  wrote:
>>
>> It looks to me like r299512 is changing the format of the client
>> identifier by inserting the struct hardware hlen field into it.
> 
> Yes.  The problem with r299512 is that it assumed the client_id was
> actually a valid struct hardware, as the array's size suggested, when
> in fact it has nothing to do with that struct.
> 
>>  That's
>> not valid if htype is non-zero the way I interpret RFC 2132.  On the
>> other hand, I would think that the server would interpret the client ID
>> as an opaque cookie, so I wouldn't think it would make a difference
>> (other than thinking this is a new client) unless your server is
>> configured to look for specific client IDs.
> 
> That seems like a pretty reasonable use of the client identifier.  Or
> less reasonably but still expected, only allowing client identifiers
> of exactly 6 bytes.

See section 9.14 in RFC 2132.  It's not a hard requirement because the
RFC uses MAY and SHOULD, but if the first byte of the ID is 1, then the
remainder of the ID should be a 6 byte ethernet MAC address.  If the
first byte is 0, then the ID is free form.

>> I think that r299512 is mostly incorrect and should be reverted.  The
>> problem reported by CID 1008682 is an overrun of hw_address.haddr.
>> struct hardware looks like this:
>>
>> struct hardware {
>> u_int8_t htype;
>> u_int8_t hlen;
>> u_int8_t haddr[16];
>> };
>>
>> I think the correct fix is just this:
>>
>> size_t hwlen = MIN(ip->hw_address.hlen,
>> sizeof(ip->hw_address.haddr));
>>
>> The old code was wrong because sizeof(client_ident)-1 is the
>> same as sizeof(struct hardware)-1, when it should be -2 to exclude both
>> htype and hlen from the calculation.
> 
> Yep.  Or equivalently, I've defined the length of client_ident in
> terms of sizeof(haddr) + 1.  The result is the same.
> 
>> The fix for CID 1305550 looks correct.
> 
> Maybe; though I reverted it too.  Really I think hlen > sizeof(haddr)
> is invalid, but I'm not familiar enough with dhclient.c to insert that
> check in the right place.  I think throwing in MIN() in an ad-hoc
> fashion maybe isn't the best approach.

If the MIN() is omitted, then Coverity might be able to figure out that
hlen is never greater than sizeof(haddr) and the code is clean.  Just
adding the MIN() might make Coverity think that hlen is not well known
and that it needs to evaluate the code with hlen values that either pass
or fail the comparison.

hlen appears to be set by the code in the AF_LINK section of
discover_interfaces().  Note that Coverity isn't flagging the memcpy()
there, even though it has know way of knowing the relationship between
the length passed to memcpy() there and sizeof(hlen).  Even with a
sanity check there, I think that is too far removed from the code in
make_discover() for it to draw any conclusions about whether hlen still
meets the constraint.

I think the best thing to do is to remove both instances of MIN() and
optionally add an assert() before
if (!options[DHO_DHCP_CLIENT_IDENTIFIER]) {
where it will protect both memcpy() calls.

BTW, the location of
char client_ident[sizeof(struct hardware)];
violates style(9).

___
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: r299512 breaks dhclient on some networks

[Don Lewis]

On 18 May, Ian FREISLICH wrote:
> On 05/18/16 20:19, Don Lewis wrote
>> It looks to me like r299512 is changing the format of the client
>> identifier by inserting the struct hardware hlen field into it.  That's
>> not valid if htype is non-zero the way I interpret RFC 2132.  On the
>> other hand, I would think that the server would interpret the client ID
>> as an opaque cookie, so I wouldn't think it would make a difference
>> (other than thinking this is a new client) unless your server is
>> configured to look for specific client IDs.
> 
> It's not that the server isn't working.  The client is discarding the
> server's offer for whatever reason.

There may be some other place in the code that validates the response
and that calculates the client ID the old way.  When it sees the
response with the new client ID, it doesn't match and the client
discards the response because it thinks the response is for some other
host.

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

boot broken on VMWare somewhere between r300069 and r300176

[K. Macy]

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

Thanks in advance.

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

Jenkins build is back to normal : FreeBSD_HEAD_sparc64 #74

[jenkins-admin]

See 

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