Re: Packaging the FreeBSD base system with pkg(8)
> On Jan 28, 2016, at 08:06, Slawa Olhovchenkovwrote: ... > 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. There might be points in time where seamless upgrades are not possible, and instead you need to hop from release to release (this is not ideal, but it could happen). For instance, at $work we're allowing upgrades from version X to Y, and Y to Z, but not direct upgrades from X to Z. Part of the rationale behind this change is, deprecation of platforms and the change in upgrade framework, which requires upgrading from blessed releases proven to work with the new framework. Thanks, -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: Packaging the FreeBSD base system with pkg(8)
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 system using pkg(8). > > > The majority of the initial implementation has provided much of the core > > > functionality to make this possible, however much work still needs to be > > > done. > > > > (snip) > > > > Would the base system all be one package? > > multiple packages with meta packages to represent the whole base so you have > the > best of both world :) > > > > In Linux, everything is part of a package, even the kernel, but something > > comparable to FreeBSD or NetBSD base system would have many packages. > > > > Will it be possible to upgrade base system with portmaster or portupgrade, > > and would that be better than the current procedure in UPDATING? > > No but one will be able to simply run pkg upgrade (and built himself the > packages) > > > > Would pkg then be able to show a package's required shared libraries > > including shared libraries from the base system? I was recently stung by > > pkg not showing required shared libraries from the base system. > > 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 > https://www.youtube.com/watch?v=v7px6ktoDAI > > for a bigger view of what happened (note that some detail my have change a > bit, > the overall remains the same) 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. ___ 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: Packaging the FreeBSD base system with pkg(8)
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 > >> https://www.youtube.com/watch?v=v7px6ktoDAI > >> > >> for a bigger view of what happened (note that some detail my have change a > >> bit, > >> the overall remains the same) > > > > 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. > > ___ > > 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" > > > > According to our current release schedule, FreeBSD 18.0 will not come > out for 35 years (2051). Schedule may be changed. How you calculate this? As I see next mayor release gone in 2 year. 18-11=7, 14 years, in 2030. Ok, let 15.0 or 16. I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why I can't planed about 11 to 18 upgrade? > The general approach would appear to be just downloading new packages > and updating the system. For a drastic upgrade like that, you'd likely > have to build a newer version of pkg from ports. You kidding. Ports from 18.0 cant't be build on 11.0. This trivial expirence, ports tree incomatible change every 5-6 years. > The approach for offering an upgrade from 10.x to 11.0 will be the more > interesting endeavour. I am guess this is already study. My interests in long run. ___ 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: Packaging the FreeBSD base system with pkg(8)
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 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 still needs to be done. >>> >>> (snip) >>> >>> Would the base system all be one package? >> >> multiple packages with meta packages to represent the whole base so you have >> the >> best of both world :) >>> >>> In Linux, everything is part of a package, even the kernel, but something >>> comparable to FreeBSD or NetBSD base system would have many packages. >>> >>> Will it be possible to upgrade base system with portmaster or portupgrade, >>> and would that be better than the current procedure in UPDATING? >> >> No but one will be able to simply run pkg upgrade (and built himself the >> packages) >>> >>> Would pkg then be able to show a package's required shared libraries >>> including shared libraries from the base system? I was recently stung by >>> pkg not showing required shared libraries from the base system. >> >> 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 >> https://www.youtube.com/watch?v=v7px6ktoDAI >> >> for a bigger view of what happened (note that some detail my have change a >> bit, >> the overall remains the same) > > 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. > ___ > 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" > 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 likely have to build a newer version of pkg from ports. The approach for offering an upgrade from 10.x to 11.0 will be the more interesting endeavour. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Packaging the FreeBSD base system with pkg(8)
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 deal with. but yes the information would be available > > see: > https://www.youtube.com/watch?v=Br6izhH5P1I > and > https://www.youtube.com/watch?v=v7px6ktoDAI > > for a bigger view of what happened (note that some detail my have change > a bit, > the overall remains the same) > >>> > >>> 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. > >>> ___ > >>> 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" > >>> > >> > >> According to our current release schedule, FreeBSD 18.0 will not come > >> out for 35 years (2051). > > > > Schedule may be changed. > > How you calculate this? As I see next mayor release gone in 2 year. > > 18-11=7, 14 years, in 2030. > > Ok, let 15.0 or 16. > > I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why > > I can't planed about 11 to 18 upgrade? > > > > You are correct sorry, I was thinking of the 5 year lifecycle of each > release, not the 2 year cadence of new releases. > > Upgrading from an End-of-Life release is specifically not supported. Where is documented? Curently source based upgraded suported to last stable direct from 7.0. Last supported release now is 9.3. Upgrade to 7.0 supported from 5.3. Upgrade to 5.3 supported from, hmm, I think last 3-STABLE (or any 3.x?). Upgrade from 2.x to 3.x is aout-elf upgrade. As result, source upgrade supported in 3 step upgrade from any current elf release to last stable. Because ALL source history preserved. I think preserving all binary packages from previos releases is imposible. > It is not a burden that RE@ should have to deal with. Please distinguish 'not supported' and 'prohibited'. This position reduce to 'lost time to system upgrade? format C: and install any other OS with more liberal upgrade policy'. Time to system upgrade may be lost by multiple reasons, for example -- lost previos staff. ___ 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: Packaging the FreeBSD base system with pkg(8)
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://www.youtube.com/watch?v=Br6izhH5P1I and https://www.youtube.com/watch?v=v7px6ktoDAI for a bigger view of what happened (note that some detail my have change a bit, the overall remains the same) >>> >>> 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. >>> ___ >>> 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" >>> >> >> According to our current release schedule, FreeBSD 18.0 will not come >> out for 35 years (2051). > > Schedule may be changed. > How you calculate this? As I see next mayor release gone in 2 year. > 18-11=7, 14 years, in 2030. > Ok, let 15.0 or 16. > I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why > I can't planed about 11 to 18 upgrade? > You are correct sorry, I was thinking of the 5 year lifecycle of each release, not the 2 year cadence of new releases. Upgrading from an End-of-Life release is specifically not supported. It is not a burden that RE@ should have to deal with. >> The general approach would appear to be just downloading new packages >> and updating the system. For a drastic upgrade like that, you'd likely >> have to build a newer version of pkg from ports. > > You kidding. Ports from 18.0 cant't be build on 11.0. This trivial > expirence, ports tree incomatible change every 5-6 years. > >> The approach for offering an upgrade from 10.x to 11.0 will be the more >> interesting endeavour. > > I am guess this is already study. > My interests in long run. > -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFSROOT UEFI boot
On 28 January 2016 at 15:03, Tomoaki AOKIwrote: > 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 contains the disk that the BIOS booted. It passes through the ID of that pool to loader which uses that pool as the default for loading kernel and modules. I believe this is the correct behaviour. For gptzfsboot and zfsboot, it is possible to override by pressing space at the point where it is about to load loader. ___ 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: Packaging the FreeBSD base system with pkg(8)
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. Thanks again! On 1/27/16 2:33 PM, Glen Barber wrote: 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 still needs to be done. Over the past few weeks, there have been several inquiries on if this work is still targeted for the 11.0-RELEASE, as well as the status of the project branch (base/projects/release-pkg). The answer to the first question is: Yes. This is still targeted for 11.0-RELEASE, which was one of the requirements during discussion of the new support model announced early last year [1]. The status of the in progress work is a bit more complex to answer in a short email, but work on packaging the FreeBSD base system is indeed ongoing, and has been my primary focus over the past several weeks. I am finishing an initial list of outstanding items that need to be resolved before the project branch can feasibly merged back to head, which I will send to the new freebsd-pkgbase@ mailing list. People interested in discussion surrounding this topic are urged to subscribe: https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase Finally, I want to personally thank Baptiste Daroussin for all of his tireless efforts to get us to the point we are at now. Without his ideas and insights, as well as ensuring pkg(8) contained the necessary functionality, we would not be anywhere close to completing this work for the 11.0-RELEASE. [1] https://lists.freebsd.org/pipermail/freebsd-announce/2015-February/001624.html Thanks. Glen ___ 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: Packaging the FreeBSD base system with pkg(8)
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 Judewrote: > 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 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 still needs to > be > done. > >>> > >>> (snip) > >>> > >>> Would the base system all be one package? > >> > >> multiple packages with meta packages to represent the whole base so you > have the > >> best of both world :) > >>> > >>> In Linux, everything is part of a package, even the kernel, but > something comparable to FreeBSD or NetBSD base system would have many > packages. > >>> > >>> Will it be possible to upgrade base system with portmaster or > portupgrade, and would that be better than the current procedure in > UPDATING? > >> > >> No but one will be able to simply run pkg upgrade (and built himself the > >> packages) > >>> > >>> Would pkg then be able to show a package's required shared libraries > including shared libraries from the base system? I was recently stung by > pkg not showing required shared libraries from the base system. > >> > >> 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 > >> https://www.youtube.com/watch?v=v7px6ktoDAI > >> > >> for a bigger view of what happened (note that some detail my have > change a bit, > >> the overall remains the same) > > > > 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. > > ___ > > 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" > > > > 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 likely > have to build a newer version of pkg from ports. > > The approach for offering an upgrade from 10.x to 11.0 will be the more > interesting endeavour. > > -- > Allan Jude > > ___ 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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 09:45:16AM -0800, NGie Cooper wrote: > > > On Jan 28, 2016, at 09:38, Slawa Olhovchenkovwrote: > > > >> 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 package base from 18.0 and etc. > >> > >> This is an important question to ask and solve. There might be > >> points in time where seamless upgrades are not possible, and instead > >> you need to hop from release to release (this is not ideal, but it > >> could happen). > > > > I see two side of this problem: support in sofware and support in > > infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of > > base FreeBSD and live in ports -- this hops need to preserve (and > > testing?) packages collections for all past releases and don't move it > > to archive. And regular resigning package databases. And I miss > > somewere. > > > >> For instance, at $work we're allowing upgrades from version X to Y, > >> and Y to Z, but not direct upgrades from X to Z. Part of the > >> rationale behind this change is, deprecation of platforms and the > >> change in upgrade framework, which requires upgrading from blessed > >> releases proven to work with the new framework. > > > > This is common practic, yes. > > This is acceptably if possible got all necessary in time 18.0 for > > upgrade from 11.0. > > Yes. Given the hiccups going from pkg 1.4 to 1.6 with the plist > stuff, this is going to be more entertaining across interface > breaks; it might be that pkgng is at the point where it's stable > enough that interfaces won't change (unlikely, software tends to be > fluid), or backwards compatibility will need to be maintained for > older versions of pkgng. > 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 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? ___ 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: Packaging the FreeBSD base system with pkg(8)
> On Jan 28, 2016, at 08:09, Allan Judewrote: ... > 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 likely > have to build a newer version of pkg from ports. > > The approach for offering an upgrade from 10.x to 11.0 will be the more > interesting endeavour. I would actually say "don't do that (upgrade from 10 to 11 via pkg). Use freebsd-update instead, then upgrade to 11.1 or 12.0 via pkg". The rationale for this is that if you install the package from 10.x, and need to downgrade for whatever reason, you'll likely be dealing with a reinstall or a VM/zfs rollback as opposed to being able to install a downgraded base system/kernel package. Thanks, -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: Packaging the FreeBSD base system with pkg(8)
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 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 >> https://www.youtube.com/watch?v=v7px6ktoDAI >> >> for a bigger view of what happened (note that some detail my have change >> a bit, >> the overall remains the same) > > 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. > ___ > 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" > According to our current release schedule, FreeBSD 18.0 will not come out for 35 years (2051). >>> >>> Schedule may be changed. >>> How you calculate this? As I see next mayor release gone in 2 year. >>> 18-11=7, 14 years, in 2030. >>> Ok, let 15.0 or 16. >>> I am work from FreeBSD 2.0, I am use (now) installation with 5.4, why >>> I can't planed about 11 to 18 upgrade? >>> >> >> You are correct sorry, I was thinking of the 5 year lifecycle of each >> release, not the 2 year cadence of new releases. >> >> Upgrading from an End-of-Life release is specifically not supported. > > Where is documented? Curently source based upgraded suported to last > stable direct from 7.0. Last supported release now is 9.3. > Upgrade to 7.0 supported from 5.3. > Upgrade to 5.3 supported from, hmm, I think last 3-STABLE (or any 3.x?). > Upgrade from 2.x to 3.x is aout-elf upgrade. > As result, source upgrade supported in 3 step upgrade from any current > elf release to last stable. > Because ALL source history preserved. > I think preserving all binary packages from previos releases is imposible. > >> It is not a burden that RE@ should have to deal with. > > Please distinguish 'not supported' and 'prohibited'. > This position reduce to 'lost time to system upgrade? format C: and install > any other OS with more liberal upgrade policy'. > Time to system upgrade may be lost by multiple reasons, for example -- > lost previos staff. > I definitely meant 'not supported', and did not mean to imply prohibited. I believe RE@ is only required to maintain an upgrade path from older supported releases, to the newer supported releases. Everything else is best effort. SRC upgrades from 7.0 are not guaranteed, but we do our best to not break them unnecessarily. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Packaging the FreeBSD base system with pkg(8)
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 signature.asc Description: PGP signature
Re: Packaging the FreeBSD base system with pkg(8)
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 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. Initial email in this thread will about problems at upgrades, from my point of view and my expirence. I am currently try to upgrade systems by untar base.txz and see some inconsistence of packaging (boot/device.hints, var/db, var/log/sendmail.st, var/db/etcupdate) and etc. Sorry if this a different problem. For me -- all of this -- question of global design. Need administrativa about some questions: - how divide - how fresh install - how upgrade (on runnig system, from install media). - what packed to disk always - what got from internet - what about custom releases and src.conf I am don't know how currenly resolved this questions. Bundled with upgraded files fresh pkg (building for LAST-2 release) and preserving for 10+ years this files can resolve many issuse of upgrading outdated systems (by hop-to-hop or hop to hop+2). I am don't know about complexity this solution. > 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. I am ask for you check. This very complex task and need good planing. > But let's not get too far ahead of ourselves. > > Glen > ___ 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: Packaging the FreeBSD base system with pkg(8)
> On Jan 28, 2016, at 09:38, Slawa Olhovchenkovwrote: > >> 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 package base from 18.0 and etc. >> >> This is an important question to ask and solve. There might be >> points in time where seamless upgrades are not possible, and instead >> you need to hop from release to release (this is not ideal, but it >> could happen). > > I see two side of this problem: support in sofware and support in > infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of > base FreeBSD and live in ports -- this hops need to preserve (and > testing?) packages collections for all past releases and don't move it > to archive. And regular resigning package databases. And I miss > somewere. > >> For instance, at $work we're allowing upgrades from version X to Y, >> and Y to Z, but not direct upgrades from X to Z. Part of the >> rationale behind this change is, deprecation of platforms and the >> change in upgrade framework, which requires upgrading from blessed >> releases proven to work with the new framework. > > This is common practic, yes. > This is acceptably if possible got all necessary in time 18.0 for > upgrade from 11.0. Yes. Given the hiccups going from pkg 1.4 to 1.6 with the plist stuff, this is going to be more entertaining across interface breaks; it might be that pkgng is at the point where it's stable enough that interfaces won't change (unlikely, software tends to be fluid), or backwards compatibility will need to be maintained for older versions of pkgng. 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? Thanks! -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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 02:58:52PM -0500, Nikolai Lifanov wrote: > > > On January 28, 2016 1:23:22 PM EST, Glen Barberwrote: > >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? pkg has a merging mercanism (which one can disable if scared) which will automatically merge everything it can and live a file .new if a conflict happen (or merging disabled) Would be easy to write an etcupdate like that walk through /etc and propose a semi-interactive merging mechanism. Best regards, Bapt signature.asc Description: PGP signature
Re: Packaging the FreeBSD base system with pkg(8)
On January 28, 2016 1:23:22 PM EST, Glen Barberwrote: >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: Packaging the FreeBSD base system with pkg(8)
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 still needs to be > done. (snip) Would the base system all be one package? In Linux, everything is part of a package, even the kernel, but something comparable to FreeBSD or NetBSD base system would have many packages. Will it be possible to upgrade base system with portmaster or portupgrade, and would that be better than the current procedure in UPDATING? Would pkg then be able to show a package's required shared libraries including shared libraries from the base system? I was recently stung by pkg not showing required shared libraries from the base system. I just subscribed to freebsd-pkgb...@freebsd.org . Tom ___ 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: Packaging the FreeBSD base system with pkg(8)
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 much of the core > > functionality to make this possible, however much work still needs to be > > done. > > (snip) > > Would the base system all be one package? multiple packages with meta packages to represent the whole base so you have the best of both world :) > > In Linux, everything is part of a package, even the kernel, but something > comparable to FreeBSD or NetBSD base system would have many packages. > > Will it be possible to upgrade base system with portmaster or portupgrade, > and would that be better than the current procedure in UPDATING? No but one will be able to simply run pkg upgrade (and built himself the packages) > > Would pkg then be able to show a package's required shared libraries > including shared libraries from the base system? I was recently stung by pkg > not showing required shared libraries from the base system. 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 https://www.youtube.com/watch?v=v7px6ktoDAI for a bigger view of what happened (note that some detail my have change a bit, the overall remains the same) Best regards, Bapt > > I just subscribed to freebsd-pkgb...@freebsd.org . > > Tom > > ___ > freebsd-pkgb...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pkgbase > To unsubscribe, send any mail to "freebsd-pkgbase-unsubscr...@freebsd.org" signature.asc Description: PGP signature
Re: Packaging the FreeBSD base system with pkg(8)
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 mtree(8) metalog, or something else. Glen signature.asc Description: PGP signature
Re: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 09:28:32AM -0800, NGie Cooper wrote: > > > On Jan 28, 2016, at 08:06, Slawa Olhovchenkovwrote: > > > ... > > > 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. There might be > points in time where seamless upgrades are not possible, and instead > you need to hop from release to release (this is not ideal, but it > could happen). I see two side of this problem: support in sofware and support in infrastructure (ftp.freebsd.org and etc.). Because pkg is not part of base FreeBSD and live in ports -- this hops need to preserve (and testing?) packages collections for all past releases and don't move it to archive. And regular resigning package databases. And I miss somewere. > For instance, at $work we're allowing upgrades from version X to Y, > and Y to Z, but not direct upgrades from X to Z. Part of the > rationale behind this change is, deprecation of platforms and the > change in upgrade framework, which requires upgrading from blessed > releases proven to work with the new framework. This is common practic, yes. This is acceptably if possible got all necessary in time 18.0 for upgrade from 11.0. ___ 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: Packaging the FreeBSD base system with pkg(8)
On 28 Jan 2016, at 17:45, NGie Cooperwrote: > > 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 closer to the base system. Upgrades will do the same sort of thing that they do currently for ports: 1. First check if the version of pkg is the latest 2. If not, upgrade it 3. Do the real upgrade The package for package is simply a tarball. It may be advantageous to separate the pkg and pkg-static binaries into different packages, so that pkg can always install pkg-static and pkg-static can always update pkg. There is no guarantee that the pkg tool from X.Y can install any packages from X+n.Y.m other than the pkg-static binary, which can then upgrade the rest of the system. The provision of pkg-static prevents us from being in the situation that I encountered trying to upgrade a Debian system (and ending up with a mess requiring a full reinstall) where apt needed a newer glibc and the glibc package needed a newer apt to install it. We will always provide a pkg-static for every supported branch that can be installed by any earlier version of pkg (because it’s just extracting a single-file archive - and in the absolute worst case you can do this by hand) and can install newer packages. David ___ 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: Packaging the FreeBSD base system with pkg(8)
On Thu, Jan 28, 2016 at 05:56:31PM +, David Chisnall wrote: > On 28 Jan 2016, at 17:45, NGie Cooperwrote: > > > > 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 closer to the > base system. Upgrades will do the same sort of thing that they do currently > for ports: > > 1. First check if the version of pkg is the latest > 2. If not, upgrade it upgrade to latest version build for older release? > 3. Do the real upgrade > > The package for package is simply a tarball. It may be advantageous to > separate the pkg and pkg-static binaries into different packages, so that pkg > can always install pkg-static and pkg-static can always update pkg. > > There is no guarantee that the pkg tool from X.Y can install any packages > from X+n.Y.m other than the pkg-static binary, which can then upgrade the > rest of the system. > > The provision of pkg-static prevents us from being in the situation > that I encountered trying to upgrade a Debian system (and ending up > with a mess requiring a full reinstall) where apt needed a newer > glibc and the glibc package needed a newer apt to install it. We > will always provide a pkg-static for every supported branch that can > be installed by any earlier version of pkg (because it’s just > extracting a single-file archive - and in the absolute worst case > you can do this by hand) and can install newer packages. Even pkg-static build for 10.x can be fail to run on previos release. Builded svn-static on 9.x fail to run on 6.x, as result I build svn-static on 6.x (and run on 6.x-10.x). ___ 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: ZFSROOT UEFI boot
On 28/01/2016 16:22, Doug Rabson wrote: On 28 January 2016 at 15:03, Tomoaki AOKIwrote: 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 contains the disk that the BIOS booted. It passes through the ID of that pool to loader which uses that pool as the default for loading kernel and modules. I believe this is the correct behaviour. For gptzfsboot and zfsboot, it is possible to override by pressing space at the point where it is about to load loader. I believe I understand at least some of your issue now, could you please test the code on the following review to see if it fixes your issue please: https://reviews.freebsd.org/D5108 Regards Steve ___ 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: ZFSROOT UEFI boot
On Sun, 24 Jan 2016 18:39:08 + Steven Hartlandwrote: > 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. > > > > When I select Disk1 from UEFI firmware, bootx64.efi in Disk1 EFI > > partition is used and it searches /boot/loader.efi from Disk2 (in ZFS, > > if none, in UFS) only. > > And when I select Disk2, bootx64.efi in Disk2 EFI partition is used and > > it searches /boot/loader.efi from Disk1 only. > > > > > > In fact, this is a long-standing and living problem. > > At past, USB memstick with head memstick.img (UEFI enabled, but > > without root-on-ZFS support) booted fine, but after I added UFS2 > > partition in internal disk, the USB memstick didn't boot anymore. > > It searches /boot/loader.efi from internal UFS and fails as it was > > blank (only newfs'ed) at that time. Another USB memstick with stable/10 > > memstick.img is still fine, as it's still ancient BIOS based. > > > > Possibly, it's not a fault of boot1.efi but caused by differense in > > implementation of UEFI firmware. If that's it, different boot1.efi > > would be needed for each implementation. > > > > A bit more details of tests are as below. Not all combinations are > > covered, but would be sufficient to determine above conclusion. > > > > > > Common configurations for all tests: > >*Each disk has one EFI partition (p1), one freebsd-boot partition > > (p2), one swap partition (p3), one UFS partition (p4), and one > > ZFS pool (p5) with this order. > > > >*Each partition has different GEOM label. > > > >*In each disk, FreeBSD is installed as root on ZFS. No other OS. > > > >*stable/10 (r294614) is installed in Disk1. > > > >*head (r294567) is installed in Disk2. > > > >*ZFS-enabled boot1.efi (head r294567) is used as bootx64.efi. > > > > > > Set 1: Boot from Disk1 (select it in UEFI firmware). > > In all tests, /boot/loader.efi in Disk1 (both UFS and ZFS) > > are NOT searched at all. > Could you clarify what you mean by this? > > When looking performing the scan boot1 uses the following coding: > * "+" = partition probe success (potential boot partition) > * "." = partition probe unsupported (valid partition not detected) > * "x" = partition probe error (unexpected error) > > 1-1) Both UFS and ZFS has no /boot/loader.efi > > -> Fail to boot. Fall back to boot1 prompt. > This is expected I know.:-) Just done to see how boot1 errors are shown. 2-2, too. > > 1-2) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS > >is copied to UFS. > > -> head in Disk2 boots fine. > What do you mean by "whole /boot of Disk2 ZFS is copied to UFS"? Like below. #mount /dev/ada1p4 /mnt #cp -a /boot /mnt #umount /mnt Where /dev/ada[01]p4 is the UFS partition. > > 1-3) Same as 1-2, except its /boot/loader.efi is overwritten by the > >one of stable/10. > > -> head in Disk2 boots fine, as loader.efi loads kernel from > > /boot/kernel/kernel in UFS and kernel with zfs.ko can mount > > root on ZFS specified by vfs.root.mountfrom. > > > > 1-4) Disk2 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > >is copied to UFS and its /boot/loader.efi is overwritten by > >the one of head. > > -> stable/10 in Disk1 ZFS boots fine. > > > > 1-5) Disk2 ZFS only has /boot/loader.efi. > > -> head in Disk2 ZFS boots fine. > > > > 1-6) Both UFS and ZFS in Disk2 has /boot/loader.efi. > >(Mix of 1-4 and 1-5) > > -> head in Disk2 ZFS boots fine. > > > > > > Set 2: Boot from Disk2 (select it in UEFI firmware). > > In all tests, /boot/loader.efi in Disk2 (both UFS and ZFS) > > are NOT searched at all. > > > > 2-1) Both UFS and ZFS has no /boot/loader.efi > > -> Fail to boot. Fall back to boot1 prompt. > > ZFS pool in Disk2 is shown before one in Disk1. > > > > 2-2) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk2 ZFS > >is copied to UFS. > > -> head in Disk2 ZFS boots fine. > > > > 2-3) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > >is copied to UFS. > > -> stable/10 in Disk1 ZFS boots fine, as loader.efi loads > > kernel from /boot/kernel/kernel in UFS and kernel with zfs.ko > > can mount root on ZFS specified by vfs.root.mountfrom. > > > > 2-4) Disk1 UFS only has /boot/loader.efi, whole /boot of Disk1 ZFS > >is copied to UFS and its /boot/loader.efi is overwritten by > >the one of head. > > -> stable/10 in Disk1 ZFS boots fine. > > > > 2-5) Disk1 ZFS only has /boot/loader.efi of stable/10 itself. > > -> Fail to boot. Fall back to boot1 prompt. > > ZFS pool in Disk2 is shown before one in Disk1. > > > >