Re: CFT: FreeBSD Package Base
In message <292eadc6-3662-ec43-1175-53fc25248...@quip.cz>, Miroslav Lachman wri tes: > David Chisnall wrote on 2019/04/30 10:22: > > On 29/04/2019 21:12, Joe Maloney wrote: > >> With CFT version you chose to build, and package individual components > >> such as sendmail with a port option. That does entirely solve the > >> problem of being able to reinstall sendmail after the fact without a > >> rebuild of the userland (base) port but perhaps base flavors could > >> solve that problem assuming flavors could extend beyond python. > > > > This sounds very much like local optimisation. It's now easy to create a > > custom base image. Great. But how do I express dependencies in ports > > on a specific base configuration? This is easy if I depend on a specific > > base package, but how does this work in your model? For example, if I > > have a package that depends on a library that is an optional part of the > > base system, how do I express that pkg needs to either refuse to install > > it, or install a userland pkg that includes that library in place of my > > existing version as part of the install process? > > > > More importantly for the container use case, if I want to take a > > completely empty jail and do pkg ins nginx (for example), what does the > > maintainer of the nginx port need to do to express the minimum set of > > the base system that needs to be installed to allow nginx to work? > > > > One of the goals for the pkg base concept was to allow this kind of use > > case, easily creating a minimal environment required to run a single > > service. With a monolithic base package set, you're going to need some > > mechanism other than packages to express the specific base subset > > package that you need and I think that you need to justify why this > > mechanism is better than using small individual packages. > > Will it not be maintainer's nightmare to take care of all the > dependencies on the base packages for each port we have in the ports tree? No more than it is today. Remember, people have been doing this sort of thing for decades. If the folks at Red Hat, Oracle (formerly Sun), and IBM can do it, I'm sure we can too. The dependency lists will be longer. We may require dependency lists that allow the choice of one of many prereqs or coreqs. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: CFT: FreeBSD Package Base
David Chisnall wrote on 2019/04/30 10:22: On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. This sounds very much like local optimisation. It's now easy to create a custom base image. Great. But how do I express dependencies in ports on a specific base configuration? This is easy if I depend on a specific base package, but how does this work in your model? For example, if I have a package that depends on a library that is an optional part of the base system, how do I express that pkg needs to either refuse to install it, or install a userland pkg that includes that library in place of my existing version as part of the install process? More importantly for the container use case, if I want to take a completely empty jail and do pkg ins nginx (for example), what does the maintainer of the nginx port need to do to express the minimum set of the base system that needs to be installed to allow nginx to work? One of the goals for the pkg base concept was to allow this kind of use case, easily creating a minimal environment required to run a single service. With a monolithic base package set, you're going to need some mechanism other than packages to express the specific base subset package that you need and I think that you need to justify why this mechanism is better than using small individual packages. Will it not be maintainer's nightmare to take care of all the dependencies on the base packages for each port we have in the ports tree? Miroslav Lachman ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Mon, Jan 21, 2019 at 6:13 AM Lev Serebryakov wrote: > On 21.01.2019 15:59, Toomas Soome wrote: > > > Is too complicated? Boot1.efi doesn't allow that, but loader.efi > does. > loader.efi lives on ESP partition, do I understand it right? So, it > could not be damaged with "bad" upgrade? > >>> > >>> It could, unless the backup is created. > >> Does it live on code (root) FS or ESP? I understand, that when you > >> upgrade ESP partition, you could ruin it, but typically root FS is > >> upgraded much more often than ESP/boot0/boot1 parts. > > > > If you are using boot1.efi, the loader.efi is in OS /boot/loader.efi > annd boot1.efi is stored to ESP and will execute loader.efi as bios boot2 > programs do. > So, Warner's advice to use > > set currdev=diskXpY: > boot > > with loader.efi is not direct replacement to choosing boot partition > via boot0 now (as "boot1.eif doesn't allow that" and /boot/loader.efi > could be broken with unsuccessful upgrade), am I right? > Yes. And after my latest fixes, you can add 'set currdev=diskXpY' to ESP's /efi/freebsd/loader.env as well. boot1.efi is really super limited and tries too much DWIM to be useful, so it's being retired in favor of loader.efi. > > we will drop boot1.efi (it is already dropped in illumos btw), and will > only use loader.efi - and in this case, the loader.efi is installed to ESP > and will only start the kernel. > Ok, I need to wait for it. > I think all the features are there. You can install loader.efi as you used to install boot1.efi and have it work as well or better than boot1.efi. > > But then again, if you are using stock (generic) OS on embedded system, > you are already doing it wrong and will get into the trouble sooner or > later:) > I can not say, is NanoBSD "stock" or not :-) > One of the big reasons I did the latest changes was to make it possible for NanoBSD to work better. Warner ___ 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: GPT boot has less features than legacy MBR-based one (Was: UEFI, loader.efi and /boot.config)
On Fri, 2019-01-18 at 21:24 +0300, Lev Serebryakov wrote: > On 18.01.2019 21:14, Toomas Soome wrote: > > > errm.. you press a key and enter device and or loader path. if it is not > > working - the code is there to be fixed. > > And loader looks to "bootme" attribute and try to boot from partition > which has one, even if it is loaded from other partition itself. > I am catching up, very late, on this old thread. What Toomas was describing does work, but it was broken for a long time. It got fixed in r341071 last November. I hate the syntax, but at the gptboot boot prompt (boot:) you can enter "da(D,P)" and gptboot will run loader(8) from that drive number D, partition number P, and (after r341071) it will pass that info properly so that loader(8) will attempt to load the kernel from the same drive/partition. IMO, it would be nice if "currdev syntax" worked too, so you could just enter disk3p4 or similar. I may look into adding that to the code. -- Ian > > GPT does not have the concept of active partition. > > It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have > any tools to set these attributes, AFAIK. Same for UEFI boot code. > ___ 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: r346941 boot environment in loader broken?
Can you bisect to find the changed that broke it? Warner On Tue, Apr 30, 2019, 6:35 AM Andrey Fesenko wrote: > In loader not work change boot environment, sub menu open, change not > work, simple reset menu. > ___ > 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" > ___ 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"
r346941 boot environment in loader broken?
In loader not work change boot environment, sub menu open, change not work, simple reset menu. ___ 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: CFT: FreeBSD Package Base
On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. This sounds very much like local optimisation. It's now easy to create a custom base image. Great. But how do I express dependencies in ports on a specific base configuration? This is easy if I depend on a specific base package, but how does this work in your model? For example, if I have a package that depends on a library that is an optional part of the base system, how do I express that pkg needs to either refuse to install it, or install a userland pkg that includes that library in place of my existing version as part of the install process? More importantly for the container use case, if I want to take a completely empty jail and do pkg ins nginx (for example), what does the maintainer of the nginx port need to do to express the minimum set of the base system that needs to be installed to allow nginx to work? One of the goals for the pkg base concept was to allow this kind of use case, easily creating a minimal environment required to run a single service. With a monolithic base package set, you're going to need some mechanism other than packages to express the specific base subset package that you need and I think that you need to justify why this mechanism is better than using small individual 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"
