from Glen Barber:
> As many know, work has been in progress for quite some time to provide
> the ability to package and upgrade the FreeBSD base system using pkg(8).
> The majority of the initial implementation has provided much of the core
> functionality to make this possible, however much work
On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
> from Glen Barber:
>
> > As many know, work has been in progress for quite some time to provide
> > the ability to package and upgrade the FreeBSD base system using pkg(8).
> > The majority of the initial implementation has provided
On Sun, 24 Jan 2016 18:39:08 +
Steven Hartland wrote:
> On 24/01/2016 12:53, Tomoaki AOKI wrote:
> > Unfortunately, this (and its committed successor and original for UFS)
> > fails to boot in some situation, like below. OTOH, gptzfsboot (and
> > maybe gptboot for UFS, too) is OK.
> >
> > Whe
On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
> On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
> > from Glen Barber:
> >
> > > As many know, work has been in progress for quite some time to provide
> > > the ability to package and upgrade the FreeBSD base sy
On 2016-01-28 11:06, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
>
>> On Thu, Jan 28, 2016 at 12:46:39PM +, Thomas Mueller wrote:
>>> from Glen Barber:
>>>
As many know, work has been in progress for quite some time to provide
the a
On 28 January 2016 at 15:03, Tomoaki AOKI wrote:
> It's exactly the NO GOOD point. The disk where boot1 is read from
> should be where loader.efi and loader.conf are first read.
>
I just wanted to note that gptzfsboot and zfsboot behaves this way. Boot1
looks for loader in the pool which contain
On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> >> Yes, but but real usage of it would happen in a second step because of many
> >> rought edges to be deal with. but yes the information would be available
> >>
> >> see:
> >> https://www.youtube.com/watch?v=Br6izhH5P1I
> >> and
> >> h
On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
>
Yes, but but real usage of it would happen in a second step because of many
rought edges to be deal with. but yes the information would be available
see:
https://
This is going to be huge for FreeBSD. Thank you Glen, Bapt and I
believe Peter Wemm as well.
Having been engineering lead on multiple appliances based on FreeBSD
this is going to revolutionize and make life so much easier for future
appliance endeavors and general manageability of FreeBSD.
On Thu, Jan 28, 2016 at 12:04:00PM -0500, Allan Jude wrote:
> On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
> > On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> >
> Yes, but but real usage of it would happen in a second step because of
> many
> rought edges to be dea
> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov wrote:
...
> What about upgrade strongly outdated system?
> For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> pkg from 11.0 don't undertund package base from 18.0 and etc.
This is an important question to ask and solve. Th
> On Jan 28, 2016, at 08:09, Allan Jude wrote:
...
> According to our current release schedule, FreeBSD 18.0 will not come
> out for 35 years (2051).
>
> The general approach would appear to be just downloading new packages
> and updating the system. For a drastic upgrade like that, you'd like
On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
>
> > On Jan 28, 2016, at 08:06, Slawa Olhovchenkov wrote:
>
>
> ...
>
> > What about upgrade strongly outdated system?
> > For example 11.0 at time 18.0? I.e. packages for 11.0 don't available,
> > pkg from 11.0 don't undertund pac
On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
> The approach for offering an upgrade from 10.x to 11.0 will be the more
> interesting endeavour.
>
At present, the plan is to provide supported 10.x releases with the
knowledge of what is added/removed in 11.0-RELEASE, be it through
a
On 2016-01-28 12:25, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 12:04:00PM -0500, Allan Jude wrote:
>
>> On 2016-01-28 12:00, Slawa Olhovchenkov wrote:
>>> On Thu, Jan 28, 2016 at 11:09:56AM -0500, Allan Jude wrote:
>>>
>> Yes, but but real usage of it would happen in a second step be
> On Jan 28, 2016, at 09:38, Slawa Olhovchenkov wrote:
>
>> On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
>>
>>
>>> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov wrote:
>>
>>
>> ...
>>
>>> What about upgrade strongly outdated system?
>>> For example 11.0 at time 18.0? I.e. p
On 28 Jan 2016, at 17:45, NGie Cooper wrote:
>
> Also, consider that you're going to be allowing upgrades from older RELEASE
> versions of the OS which might be using a fixed copy of pkgng -- how are you
> going to support that?
I believe that the plan is to promote the pkg tool somewhat close
On Thu, Jan 28, 2016 at 09:45:16AM -0800, NGie Cooper wrote:
>
> > On Jan 28, 2016, at 09:38, Slawa Olhovchenkov wrote:
> >
> >> On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote:
> >>
> >>
> >>> On Jan 28, 2016, at 08:06, Slawa Olhovchenkov wrote:
> >>
> >>
> >> ...
> >>
> >>>
On Thu, Jan 28, 2016 at 05:56:31PM +, David Chisnall wrote:
> On 28 Jan 2016, at 17:45, NGie Cooper wrote:
> >
> > Also, consider that you're going to be allowing upgrades from older RELEASE
> > versions of the OS which might be using a fixed copy of pkgng -- how are
> > you going to suppo
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
On Thu, Jan 28, 2016 at 06:23:22PM +, 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 packa
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 i
On Thu, Jan 28, 2016 at 02:58:52PM -0500, Nikolai Lifanov wrote:
>
>
> 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):
On 28/01/2016 16:22, Doug Rabson wrote:
On 28 January 2016 at 15:03, Tomoaki AOKI wrote:
It's exactly the NO GOOD point. The disk where boot1 is read from
should be where loader.efi and loader.conf are first read.
I just wanted to note that gptzfsboot and zfsboot behaves this way. Boot1
look
That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
luck with that, Slawa, you'll need it! :)
On Thu, Jan 28, 2016 at 8:09 AM, Allan Jude wrote:
> On 2016-01-28 11:06, Slawa Olhovchenkov wrote:
> > On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
> >
> >>
25 matches
Mail list logo
