Re: ZFS...
Comments inline.. Michelle Sullivan http://www.mhix.org/ Sent from my iPad > On 30 Apr 2019, at 03:06, Alan Somers wrote: > >> On Mon, Apr 29, 2019 at 10:23 AM Michelle Sullivan >> wrote: >> >> I know I'm not going to be popular for this, but I'll just drop it here >> anyhow. >> >> http://www.michellesullivan.org/blog/1726 >> >> Perhaps one should reconsider either: >> >> 1. Looking at tools that may be able to recover corrupt ZFS metadata, or >> 2. Defaulting to non ZFS filesystems on install. >> >> -- >> Michelle Sullivan >> http://www.mhix.org/ > > Wow, losing multiple TB sucks for anybody. I'm sorry for your loss. > But I want to respond to a few points from the blog post. > > 1) When ZFS says that "the data is always correct and there's no need > for fsck", they mean metadata as well as data. The spacemap is > protected in exactly the same way as all other data and metadata. (to > be pedantically correct, the labels and uberblocks are protected in a > different way, but still protected). The only way to get metadata > corruption is due a disk failure (3-disk failure when using RAIDZ2), > or due to a software bug. Sadly, those do happen, and they're > devilishly tricky to track down. The difference between ZFS and older > filesystems is that older filesystems experience corruption during > power loss _by_design_, not merely due to software bugs. A perfectly > functioning UFS implementation will experience corruption during power > loss, and that's why it needs to be fscked. It's not just > theoretical, either. I use UFS on my development VMs, and they > frequently experience corruption after a panic (which happens all the > time because I'm working on kernel code). I know, which is why I have ZVOLs with UFS filesystems in them for the development VMs... in a perfect world the power would have been all good, the upses would not be damaged and the generator would not run out of fuel because of extended outage... in fact if it was a perfect world I wouldn’t have my own mini dc at home. > > 2) Backups are essential with any filesystem, not just ZFS. After > all, no amount of RAID will protect you from an accidental "rm -rf /". You only do it once... I did it back in 1995... haven’t ever done it again. > > 3) ZFS hotspares can be swapped in automatically, though they don't be > default. It sounds like you already figured out how to assign a spare > to the pool. To use it automatically, you must set the "autoreplace" > pool property and enable zfsd. The latter can be done with "sysrc > zfsd_enable="YES"". The system was originally built on 9.0, and got upgraded through out the years... zfsd was not available back then. So get your point, but maybe you didn’t realize this blog was a history of 8+ years? > > 4) It sounds like you're having a lot of power trouble. Have you > tried sysutils/apcupsd from ports? I did... Malta was notorious for it. Hence 6kva upses in the bottom of each rack (4 racks), cross connected with the rack next to it and a backup generator... Australia on the otherhand is a lot more stable (at least where I am)... 2 power issues in 2 years... both within 10 hours... one was a transformer, the other when some idiot took out a power pole (and I mean actually took it out, it was literally snapped in half... how they got out of the car and did a runner before the police or Ambos got there I’ll never know.) > It's fairly handy. It can talk to > a wide range of UPSes, and can be configured to do stuff like send you > an email on power loss, and power down the server if the battery gets > too low. > They could help this... all 4 upses are toast now. One caught fire, one no longer detects AC input, the other two I’m not even trying after the first catching fire... the lot are being replaced on insurance. It’s a catalog of errors that most wouldn’t normally experience. However it does show (to me) that ZFS on everything is a really bad idea... particularly for home users where there is unknown hardware and you know they will mistreat it... they certainly won’t have ECC RAM in laptops etc... unknown caching facilities etc.. it’s a recipe for losing the root drive... Regards, Michelle ___ 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"
Re: ZFS...
Michelle Sullivan http://www.mhix.org/ Sent from my iPad > On 30 Apr 2019, at 03:13, Kurt Jaeger wrote: > > Hi! > >> I know I'm not going to be popular for this, but I'll just drop it here >> anyhow. >> >> http://www.michellesullivan.org/blog/1726 > > With all due respect, I think if that filesystem/server you describe > has not kept with all those mishaps, I think it's not perfect, but > nothing is. The killer was the catalog of errors, where you have resolver in progress, and not one but two power failures...and just to let you know... one of the 6kva upses caught fire the other no longer recognizes AC input... so it was not your normal event. I had a good run with 8 years of running ZFS on this server. > >> Perhaps one should reconsider either: >> >> 2. Defaulting to non ZFS filesystems on install. > > I had more cases of UFS being toast than ZFS until now. I’ve toasted many, however I’ve always been able to get majority(if not all) of the data. > >> 1. Looking at tools that may be able to recover corrupt ZFS metadata, or > > Here I agree! Making tools available to dig around zombie zpools, > which is icky in itself, would be helpful! The one tool that I could think would be useful that is denied “because the data on disk is always right” is not a fact for zfs, but a zfs send with -AAA (like zdb) or a “zfs walk” tool that works similar to zfs send but where you can tell it to ignore the checksum errors (particularly in the structures of zfs rather than on the data itself) so you can send what’s left of your data to another box either in part or fully. Particularly as in my case all the tools tell me all the data is there and intact and it’s just the metadata that can’t be recovered/repaired. Regards, Michelle ___ 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"
Re: CFT: FreeBSD Package Base
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. Joe Maloney Quality Engineering Manager / iXsystems Enterprise Storage & Servers Driven By Open Source > On Apr 29, 2019, at 3:31 PM, Cy Schubert wrote: > > In message <201904291441.x3tefmid072...@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: >>> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < >>> freebsd-...@gndrsh.dnsmgr.net> wrote: >>> > > Correct, this is ZFS only. And it's something we're using specific to FreeNAS / TrueOS, which is why I didn't originally mention it as apart of our CFT. Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", calling this FreeBSD pkg base when it is not was wrong, and miss leading. >>> >>> Sorry, I disagree. >> Which is fine. >> >>> This pkg base is independent of the ZFS tool we're using >>> to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. >>> These base packages work the same as existing in-tree pkg base on UFS, no >>> difference. If anything are probably safer due to being able to update all >>> of userland in single extract operation, so you don't have out of order >>> extraction of libc or some such. >> >> You missed the major string change and focused on the edge, >> No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS? >> >> That was the major point of my statement, your miss leading the user >> community, you yourself said this would never be imported into FreeBSD >> base, so I see no reason that it should be called "FreeBSD package Base", >> as it is not, that is a different project. > > Taking the last comment on this thread to ask a question and maybe > refocus a little. > > The discussion about granularity begs the question, why pkgbase in the > first place? My impression was that it allowed people to select which > components they wanted to either create a lean installation or mix and > match base packages and ports (possibly with flavours to install in > /usr rather than $LOCALBASE) such that maybe person A wanted a stock > install while person B wanted to replace, picking a random example, BSD > tar with GNU tar. Isn't that the real advantage of pkgbase? > > If OTOH it's binary updates V 2.0, what's the point? I'm a little > rhetorical here but you get my point. If I want ipfw instead pf or > ipfilter instead of the others I should have the freedom. Similarly if > I want vim instead of vi I should have the choice to install vim as > /usr/bin/vi. Otherwise all the effort to replace binary updates makes > no sense. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: http://www.FreeBSD.org > > The need of the many outweighs the greed of the few. > > > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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"
Creating jails from packagebase
___ 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"
Re: CFT: FreeBSD Package Base
In message <201904291441.x3tefmid072...@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes: > > On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > > > > Correct, this is ZFS only. And it's something we're using specific to > > > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of > > > our CFT. > > > > > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", > > > calling this FreeBSD pkg base when it is not was wrong, > > > and miss leading. > > > > > > > Sorry, I disagree. > Which is fine. > > > This pkg base is independent of the ZFS tool we're using > > to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. > > These base packages work the same as existing in-tree pkg base on UFS, no > > difference. If anything are probably safer due to being able to update all > > of userland in single extract operation, so you don't have out of order > > extraction of libc or some such. > > You missed the major string change and focused on the edge, > No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS? > > That was the major point of my statement, your miss leading the user > community, you yourself said this would never be imported into FreeBSD > base, so I see no reason that it should be called "FreeBSD package Base", > as it is not, that is a different project. Taking the last comment on this thread to ask a question and maybe refocus a little. The discussion about granularity begs the question, why pkgbase in the first place? My impression was that it allowed people to select which components they wanted to either create a lean installation or mix and match base packages and ports (possibly with flavours to install in /usr rather than $LOCALBASE) such that maybe person A wanted a stock install while person B wanted to replace, picking a random example, BSD tar with GNU tar. Isn't that the real advantage of pkgbase? If OTOH it's binary updates V 2.0, what's the point? I'm a little rhetorical here but you get my point. If I want ipfw instead pf or ipfilter instead of the others I should have the freedom. Similarly if I want vim instead of vi I should have the choice to install vim as /usr/bin/vi. Otherwise all the effort to replace binary updates makes no sense. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
Re: ZFS...
Hi! > I know I'm not going to be popular for this, but I'll just drop it here > anyhow. > > http://www.michellesullivan.org/blog/1726 With all due respect, I think if that filesystem/server you describe has not kept with all those mishaps, I think it's not perfect, but nothing is. > Perhaps one should reconsider either: > > 2. Defaulting to non ZFS filesystems on install. I had more cases of UFS being toast than ZFS until now. > 1. Looking at tools that may be able to recover corrupt ZFS metadata, or Here I agree! Making tools available to dig around zombie zpools, which is icky in itself, would be helpful! -- p...@opsec.eu+49 171 3101372One year to go ! ___ 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"
Re: ZFS...
On Mon, Apr 29, 2019 at 10:23 AM Michelle Sullivan wrote: > > I know I'm not going to be popular for this, but I'll just drop it here > anyhow. > > http://www.michellesullivan.org/blog/1726 > > Perhaps one should reconsider either: > > 1. Looking at tools that may be able to recover corrupt ZFS metadata, or > 2. Defaulting to non ZFS filesystems on install. > > -- > Michelle Sullivan > http://www.mhix.org/ Wow, losing multiple TB sucks for anybody. I'm sorry for your loss. But I want to respond to a few points from the blog post. 1) When ZFS says that "the data is always correct and there's no need for fsck", they mean metadata as well as data. The spacemap is protected in exactly the same way as all other data and metadata. (to be pedantically correct, the labels and uberblocks are protected in a different way, but still protected). The only way to get metadata corruption is due a disk failure (3-disk failure when using RAIDZ2), or due to a software bug. Sadly, those do happen, and they're devilishly tricky to track down. The difference between ZFS and older filesystems is that older filesystems experience corruption during power loss _by_design_, not merely due to software bugs. A perfectly functioning UFS implementation will experience corruption during power loss, and that's why it needs to be fscked. It's not just theoretical, either. I use UFS on my development VMs, and they frequently experience corruption after a panic (which happens all the time because I'm working on kernel code). 2) Backups are essential with any filesystem, not just ZFS. After all, no amount of RAID will protect you from an accidental "rm -rf /". 3) ZFS hotspares can be swapped in automatically, though they don't be default. It sounds like you already figured out how to assign a spare to the pool. To use it automatically, you must set the "autoreplace" pool property and enable zfsd. The latter can be done with "sysrc zfsd_enable="YES"". 4) It sounds like you're having a lot of power trouble. Have you tried sysutils/apcupsd from ports? It's fairly handy. It can talk to a wide range of UPSes, and can be configured to do stuff like send you an email on power loss, and power down the server if the battery gets too low. Better luck next time, -Alan ___ 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"
ZFS...
I know I'm not going to be popular for this, but I'll just drop it here anyhow. http://www.michellesullivan.org/blog/1726 Perhaps one should reconsider either: 1. Looking at tools that may be able to recover corrupt ZFS metadata, or 2. Defaulting to non ZFS filesystems on install. -- Michelle Sullivan http://www.mhix.org/ ___ 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"
Re: CFT: FreeBSD Package Base
> On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > Correct, this is ZFS only. And it's something we're using specific to > > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of > > our CFT. > > > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", > > calling this FreeBSD pkg base when it is not was wrong, > > and miss leading. > > > > Sorry, I disagree. Which is fine. > This pkg base is independent of the ZFS tool we're using > to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. > These base packages work the same as existing in-tree pkg base on UFS, no > difference. If anything are probably safer due to being able to update all > of userland in single extract operation, so you don't have out of order > extraction of libc or some such. You missed the major string change and focused on the edge, No comment on calling iXsystems :stuff: FreeBSD instead of FreeNAS/TrueOS? That was the major point of my statement, your miss leading the user community, you yourself said this would never be imported into FreeBSD base, so I see no reason that it should be called "FreeBSD package Base", as it is not, that is a different project. > > > For UFS, there will need to be additional care taken when doing updates. > > > > > > -- > > > Kris Moore > > > Vice President of Engineering > > > iXsystems, Inc > > > Ph: (408) 943-4100 > > > Ph: (408) 943-4101 > > > The Groundbreaking TrueNAS M-Series - > > > Enterprise Storage & Servers Driven By Open Source > > > > > > -Original Message- > > > From: Goran Meki? > > > Sent: Monday, April 29, 2019 9:43 AM > > > To: Kris Moore > > > Cc: Emmanuel Vadot ; FreeBSD Stable < > > freebsd-stable@freebsd.org>; FreeBSD Current ; > > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; > > freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org > > > Subject: Re: CFT: FreeBSD Package Base > > > > > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > > > > We've written our own tool "sysutils/sysup" in GO which handles this. > > > > It performs updates using Boot-Environments to ensure that > > > > kernel/world are updated at same time. > > > > > > If I'm right, UFS doesn't support boot environments, so how would it > > work for UFS based installs? > > > > > > I personally feel GO is a bit ackward choice of language for something > > that practically should be part of base. At least I would expect OS > > update/upgrade not to require any external package. > > > > > > Regards, > > > meka > > > > > > ___ > > > freebsd-curr...@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to " > > freebsd-current-unsubscr...@freebsd.org" > > > > > > > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > -- Rod Grimes rgri...@freebsd.org ___ 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"
RE: CFT: FreeBSD Package Base
> -Original Message- > From: Matthias Apitz > Sent: Monday, April 29, 2019 10:50 AM > To: Emmanuel Vadot > Cc: Kris Moore ; FreeBSD Stable sta...@freebsd.org>; freebsd-...@freebsd.org; freebsd- > hack...@freebsd.org; FreeBSD Current ; > freebsd-pkgb...@freebsd.org; freebsd-po...@freebsd.org > Subject: Re: CFT: FreeBSD Package Base > > > Why this thread has to go to all these lists? I receive any mail 5 times! > > Matthias Fair point. I'll restrict my replies to the -pkgbase list from here on out, suggest others do the same. Sorry about the noise > -- > Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176- > 38902045 Public GnuPG key: http://www.unixarea.de/key.pub N € I N zur EU! > "Gegen das EU-Europa der Banken, Konzerne und Kriegstreiber. > Für ein soziales und friedliches Europa der Völker." DKP ___ 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"
RE: CFT: FreeBSD Package Base
> -Original Message- > From: Rodney W. Grimes > Sent: Monday, April 29, 2019 10:41 AM > To: Kris Moore > Cc: Rodney W. Grimes ; Goran Mekić > ; Emmanuel Vadot ; FreeBSD > Stable ; FreeBSD Current curr...@freebsd.org>; freebsd-pkgb...@freebsd.org; freebsd- > p...@freebsd.org; freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org > Subject: Re: CFT: FreeBSD Package Base > > > On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < > > freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > > > > > > > Correct, this is ZFS only. And it's something we're using specific > > > > to > > > FreeNAS / TrueOS, which is why I didn't originally mention it as > > > apart of our CFT. > > > > > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", calling > > > this FreeBSD pkg base when it is not was wrong, and miss leading. > > > > > > > Sorry, I disagree. > Which is fine. > > > This pkg base is independent of the ZFS tool we're using > > to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. > > These base packages work the same as existing in-tree pkg base on UFS, no > > difference. If anything are probably safer due to being able to update all > > of userland in single extract operation, so you don't have out of order > > extraction of libc or some such. > > You missed the major string change and focused on the edge, > No comment on calling iXsystems :stuff: FreeBSD instead of > FreeNAS/TrueOS? > > That was the major point of my statement, your miss leading the user > community, you yourself said this would never be imported into FreeBSD > base, so I see no reason that it should be called "FreeBSD package Base", > as it is not, that is a different project. > > -- > Rod Grimes rgri...@freebsd.org I think somehow you've missed the entire point here. This is being brought forth as a FreeBSD CFT in the hopes of upstream adoption. No misleading here whatsoever. The only thing that I wouldn't expect to be imported into base was this external tool we use on FreeNAS/TrueOS to handle our specific use-case of ZFS only. Total strawman here. Seriously, suggest you bother looking at it and reading further to get the full context. If anything this is far less invasive since it doesn't require lots of hacking on base, and can even be used to package old versions of FreeBSD if desired. The only thing I changed to make these images was a patch to bsdinstall to replace dist-file extraction with 'pkg install userland kernel pkg ...'. ___ 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"
Re: CFT: FreeBSD Package Base
Why this thread has to go to all these lists? I receive any mail 5 times! matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub N € I N zur EU! "Gegen das EU-Europa der Banken, Konzerne und Kriegstreiber. Für ein soziales und friedliches Europa der Völker." DKP signature.asc Description: PGP signature
Re: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 10:05:59 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot > wrote: > > > On Mon, 29 Apr 2019 09:25:05 -0400 > > Kris Moore wrote: > > > > > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > > > wrote: > > > > > > > > > > > Hi Kris, > > > > > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > > > wrote: > > > > > > > > > FreeBSD Community, > > > > > > > > > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > > > 13-current > > > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > > > which > > > > > will allow users to perform all updating via the 'pkg' command > > directly. > > > > > Rather than trying to answer all questions in this announcement, > > we've > > > > > created a FAQ page with more details. Please refer to this page, and > > let > > > > us > > > > > know if you have additional questions that we can include on that > > page > > > > going > > > > > forward. > > > > > > > > > > > > > While I appreciate the effort I have some doubt about your > > > > "re-implementation" of pkgbase. I don't see any improvement compared to > > > > what is in base currently, I even see downside of your implementation. > > > > > > > > - How do you plan with the need of updating kernel first, reboot and > > > > updating the rest of the userland after ? (Needed for major and minor > > > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > > > -HEAD branch). This is still a problem with the base pkgbase. > > > > > > > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > > > performs updates using Boot-Environments to ensure that kernel/world are > > > updated at same time. > > > > > > > Which could never be imported into FreeBSD. > > > > Not suggesting it should be. Just information on how we solved that problem > in our own appliance / platforms. For FreeBSD it would need some tooling > still to handle this style of updating, regardless of which pkg base is > used. > > And for what it's worth, FreeBSD is all the poorer for not being able to > bring modern language based tools into the base. Personally I'm hoping the > shift to base-packages makes this a moot point since the idea of 'what is > base' can be diluted to just a manifest of what gets installed out of box. > Just my 2C on the matter though :) > > > > > > > > > > > > > > - This is even worse because you are using the same repository for > > > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > > > to be updated and pkg use a new syscall or capsicum thing it will be > > > > updated first and couldn't proceed with the rest of the update (this is > > > > a supposition, I haven't personally tested). > > > > > > > > > > See above. > > > > You can selectively update os/kernel and reboot before doing rest. > > > > > > > > > > > > - It seems that multiple kernels isn't supported in your > > > > implementation, this is already supported in pkgbase but still need > > > > some love. This is an important point as it will allow user to choose > > > > easily the kernel that they want to use and will also allow us > > > > developper to push kernels with new features to help testing. > > > > > > > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll > > get > > > the Witness-enabled kernel installed alongside non-debugging one. > > > > Mhm no, the kernel-debug packages only add the debug file > > in /usr/lib/debug/boot/ > > I'm talking about installing multiple kernels in // > > (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like > > describe here : > > > > https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues > > in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on > 13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are the > /usr/lib/debug bits. I only see kernel-20190420203550_1.txz and kernel-debug-20190420203550.txz in https://pkg.trueos.org/pkg/freebsd-pkgbase/FreeBSD%3A13%3Aamd64/latest/All/ and kernel-debug only contain the debug files. If I'm not looking in the right directory please correct me. > > > > > > > > > > > I think that the only advantage that your solution offers is that if > > > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > > > files would be removed as they are in the userland-base package while > > > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > > > > will not be deleted in the user computer. > > > > > > > > > > > > > Correct, this is one of the things which prompted us to go this > > direction. > > > Being able to handle crazy mixed WITH/WITHOUT flags was important to us, > > > current pkg base did not handle that so gracefully. > > > > Can you give me more info on this ? What where the WITH/WITHOUT flags > > that causes
RE: CFT: FreeBSD Package Base
> > > > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on > > 13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are > > the /usr/lib/debug bits. > > I only see kernel-20190420203550_1.txz and kernel-debug- > 20190420203550.txz in https://pkg.trueos.org/pkg/freebsd- > pkgbase/FreeBSD%3A13%3Aamd64/latest/All/ > and kernel-debug only contain the debug files. > If I'm not looking in the right directory please correct me. > > > -- > Emmanuel Vadot Ahh, you are correct. I checked and those packages haven't pushed to the mirrors yet, Jenkins is still chewing on a build of them here. I was using the 12-stable packages yesterday which has these changes. They should be synced up to the mirrors in the next 24-48 hours. Sorry about the confusion. -- Kris Moore Vice President of Engineering iXsystems, Inc Ph: (408) 943-4100 Ph: (408) 943-4101 The Groundbreaking TrueNAS M-Series - Enterprise Storage & Servers Driven By Open Source ___ 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"
Re: Concern: ZFS Mirror issues (12.STABLE and firmware 19 .v. 20) [[UPDATE w/more tests]]
On Sun, Apr 28, 2019 at 4:03 PM Karl Denninger wrote: > On 4/20/2019 15:56, Steven Hartland wrote: > > Thanks for extra info, the next question would be have you eliminated > > that corruption exists before the disk is removed? > > > > Would be interesting to add a zpool scrub to confirm this isn't the > > case before the disk removal is attempted. > > > > Regards > > Steve > > > > On 20/04/2019 18:35, Karl Denninger wrote: > >> > >> On 4/20/2019 10:50, Steven Hartland wrote: > >>> Have you eliminated geli as possible source? > >> No; I could conceivably do so by re-creating another backup volume > >> set without geli-encrypting the drives, but I do not have an extra > >> set of drives of the capacity required laying around to do that. I > >> would have to do it with lower-capacity disks, which I can attempt if > >> you think it would help. I *do* have open slots in the drive > >> backplane to set up a second "test" unit of this sort. For reasons > >> below it will take at least a couple of weeks to get good data on > >> whether the problem exists without geli, however. > >> > Ok, following up on this with more data > > First step taken was to create a *second* backup pool (I have the > backplane slots open, fortunately) with three different disks but *no > encryption.* > > I ran both side-by-side for several days, with the *unencrypted* one > operating with one disk detached and offline (pulled physically) just as > I do normally. Then I swapped the two using the same paradigm. > > The difference was *dramatic* -- the resilver did *not* scan the entire > disk; it only copied the changed blocks and was finished FAST. A > subsequent scrub came up 100% clean. > > Next I put THOSE disks in the vault (so as to make sure I didn't get > hosed if something went wrong) and re-initialized the pool in question, > leaving only the "geli" alone (in other words I zpool destroy'd the pool > and then re-created it with all three disks connected and > geli-attached.) The purpose for doing this was to eliminate the > possibility of old corruption somewhere, or some sort of problem with > multiple, spanning years, in-place "zpool upgrade" commands. Then I ran > a base backup to initialize all three volumes, detached one and yanked > it out of the backplane, as would be the usual, leaving the other two > online and operating. > > I ran backups as usual for most of last week after doing this, with the > 61.eli and 62-1.eli volumes online, and 62-2 physically out of the > backplane. > > Today I swapped them again as I usually do (e.g. offline 62.1, geli > detach, camcontrol standby and then yank it -- then insert the 62-2 > volume, geli attach and zpool online) and this is happening: > > [\u@NewFS /home/karl]# zpool status backup > pool: backup > state: DEGRADED > status: One or more devices is currently being resilvered. The pool will > continue to function, possibly in a degraded state. > action: Wait for the resilver to complete. > scan: resilver in progress since Sun Apr 28 12:57:47 2019 > 2.48T scanned at 202M/s, 1.89T issued at 154M/s, 3.27T total > 1.89T resilvered, 57.70% done, 0 days 02:37:14 to go > config: > > NAME STATE READ WRITE CKSUM > backupDEGRADED 0 0 0 > mirror-0DEGRADED 0 0 0 > gpt/backup61.eli ONLINE 0 0 0 > 11295390187305954877 OFFLINE 0 0 0 was > /dev/gpt/backup62-1.eli > gpt/backup62-2.eliONLINE 0 0 0 > > errors: No known data errors > > The "3.27T" number is accurate (by "zpool list") for the space in use. > > There is not a snowball's chance in Hades that anywhere near 1.89T of > that data (thus far, and it ain't done as you can see!) was modified > between when all three disks were online and when the 62-2.eli volume > was swapped back in for 62.1.eli. No possible way. Maybe some > 100-200Gb of data has been touched across the backed-up filesystems in > the last three-ish days but there's just flat-out no way it's more than > that; this would imply an entropy of well over 50% of the writeable data > on this box in less than a week! That's NOT possible. Further it's not > 100%; it shows 2.48T scanned but 1.89T actually written to the other drive. > > So something is definitely foooged here and it does appear that geli is > involved in it. Whatever is foooging zfs the resilver process thinks it > has to recopy MOST (but not all!) of the blocks in use, it appears, from > the 61.eli volume to the 62-2.eli volume. > > The question is what would lead ZFS to think it has to do that -- it > clearly DOES NOT as a *much* smaller percentage of the total TXG set on > 61.eli was modified while 62-2.eli was offline and 62.1.eli was online. > > Again I note that on 11.1 and previous this resilver was a rapid > operation; whatever was actually changed got copied
Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 10:09 AM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > > Correct, this is ZFS only. And it's something we're using specific to > FreeNAS / TrueOS, which is why I didn't originally mention it as apart of > our CFT. > > Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", > calling this FreeBSD pkg base when it is not was wrong, > and miss leading. > Sorry, I disagree. This pkg base is independent of the ZFS tool we're using to wrangle boot-environments. Hence why it wasn't mentioned in the CFT. These base packages work the same as existing in-tree pkg base on UFS, no difference. If anything are probably safer due to being able to update all of userland in single extract operation, so you don't have out of order extraction of libc or some such. > > > For UFS, there will need to be additional care taken when doing updates. > > > > -- > > Kris Moore > > Vice President of Engineering > > iXsystems, Inc > > Ph: (408) 943-4100 > > Ph: (408) 943-4101 > > The Groundbreaking TrueNAS M-Series - > > Enterprise Storage & Servers Driven By Open Source > > > > -Original Message- > > From: Goran Meki? > > Sent: Monday, April 29, 2019 9:43 AM > > To: Kris Moore > > Cc: Emmanuel Vadot ; FreeBSD Stable < > freebsd-stable@freebsd.org>; FreeBSD Current ; > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; > freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org > > Subject: Re: CFT: FreeBSD Package Base > > > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > > > We've written our own tool "sysutils/sysup" in GO which handles this. > > > It performs updates using Boot-Environments to ensure that > > > kernel/world are updated at same time. > > > > If I'm right, UFS doesn't support boot environments, so how would it > work for UFS based installs? > > > > I personally feel GO is a bit ackward choice of language for something > that practically should be part of base. At least I would expect OS > update/upgrade not to require any external package. > > > > Regards, > > meka > > > > ___ > > freebsd-curr...@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > > > > -- > Rod Grimes > rgri...@freebsd.org > ___ 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"
Re: CFT: FreeBSD Package Base
> > Correct, this is ZFS only. And it's something we're using specific to FreeNAS > / TrueOS, which is why I didn't originally mention it as apart of our CFT. Then please it is "CFT: FreeNAS/TrueOS pkg base, ZFS only", calling this FreeBSD pkg base when it is not was wrong, and miss leading. > For UFS, there will need to be additional care taken when doing updates. > > -- > Kris Moore > Vice President of Engineering > iXsystems, Inc > Ph: (408) 943-4100 > Ph: (408) 943-4101 > The Groundbreaking TrueNAS M-Series - > Enterprise Storage & Servers Driven By Open Source > > -Original Message- > From: Goran Meki? > Sent: Monday, April 29, 2019 9:43 AM > To: Kris Moore > Cc: Emmanuel Vadot ; FreeBSD Stable > ; FreeBSD Current ; > freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; > freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org > Subject: Re: CFT: FreeBSD Package Base > > On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > > We've written our own tool "sysutils/sysup" in GO which handles this. > > It performs updates using Boot-Environments to ensure that > > kernel/world are updated at same time. > > If I'm right, UFS doesn't support boot environments, so how would it work for > UFS based installs? > > I personally feel GO is a bit ackward choice of language for something that > practically should be part of base. At least I would expect OS update/upgrade > not to require any external package. > > Regards, > meka > > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > -- Rod Grimes rgri...@freebsd.org ___ 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"
Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot wrote: > On Mon, 29 Apr 2019 09:25:05 -0400 > Kris Moore wrote: > > > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > > wrote: > > > > > > > > Hi Kris, > > > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > > wrote: > > > > > > > FreeBSD Community, > > > > > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > > 13-current > > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > > which > > > > will allow users to perform all updating via the 'pkg' command > directly. > > > > Rather than trying to answer all questions in this announcement, > we've > > > > created a FAQ page with more details. Please refer to this page, and > let > > > us > > > > know if you have additional questions that we can include on that > page > > > going > > > > forward. > > > > > > > > > > While I appreciate the effort I have some doubt about your > > > "re-implementation" of pkgbase. I don't see any improvement compared to > > > what is in base currently, I even see downside of your implementation. > > > > > > - How do you plan with the need of updating kernel first, reboot and > > > updating the rest of the userland after ? (Needed for major and minor > > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > > -HEAD branch). This is still a problem with the base pkgbase. > > > > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > > performs updates using Boot-Environments to ensure that kernel/world are > > updated at same time. > > > > Which could never be imported into FreeBSD. > Not suggesting it should be. Just information on how we solved that problem in our own appliance / platforms. For FreeBSD it would need some tooling still to handle this style of updating, regardless of which pkg base is used. And for what it's worth, FreeBSD is all the poorer for not being able to bring modern language based tools into the base. Personally I'm hoping the shift to base-packages makes this a moot point since the idea of 'what is base' can be diluted to just a manifest of what gets installed out of box. Just my 2C on the matter though :) > > > > > > > > - This is even worse because you are using the same repository for > > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > > to be updated and pkg use a new syscall or capsicum thing it will be > > > updated first and couldn't proceed with the rest of the update (this is > > > a supposition, I haven't personally tested). > > > > > > > See above. > You can selectively update os/kernel and reboot before doing rest. > > > > > > > - It seems that multiple kernels isn't supported in your > > > implementation, this is already supported in pkgbase but still need > > > some love. This is an important point as it will allow user to choose > > > easily the kernel that they want to use and will also allow us > > > developper to push kernels with new features to help testing. > > > > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll > get > > the Witness-enabled kernel installed alongside non-debugging one. > > Mhm no, the kernel-debug packages only add the debug file > in /usr/lib/debug/boot/ > I'm talking about installing multiple kernels in // > (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like > describe here : > > https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues > in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on 13-CURRENT) the Witness enabled kernel. os/kernel-debug-symbols are the /usr/lib/debug bits. > > > > > > > I think that the only advantage that your solution offers is that if > > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > > files would be removed as they are in the userland-base package while > > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > > > will not be deleted in the user computer. > > > > > > > > > Correct, this is one of the things which prompted us to go this > direction. > > Being able to handle crazy mixed WITH/WITHOUT flags was important to us, > > current pkg base did not handle that so gracefully. > > Can you give me more info on this ? What where the WITH/WITHOUT flags > that causes problems ? > I may have to pick Miwi's brain on this, but I believe some of the issues we saw were when introducing flags such as WITHOUT_RADIUS. Additionally there is a runtime problem to solve. I.E. if you change flags mid-stream, and user updates, there was no clean way on pkg-side to remove those already installed granular packages. Not without external tooling anyway. > > -- > Emmanuel Vadot > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe,
Re: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 09:25:05 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > wrote: > > > > > Hi Kris, > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > wrote: > > > > > FreeBSD Community, > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > 13-current > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > which > > > will allow users to perform all updating via the 'pkg' command directly. > > > Rather than trying to answer all questions in this announcement, we've > > > created a FAQ page with more details. Please refer to this page, and let > > us > > > know if you have additional questions that we can include on that page > > going > > > forward. > > > > > > > While I appreciate the effort I have some doubt about your > > "re-implementation" of pkgbase. I don't see any improvement compared to > > what is in base currently, I even see downside of your implementation. > > > > - How do you plan with the need of updating kernel first, reboot and > > updating the rest of the userland after ? (Needed for major and minor > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > -HEAD branch). This is still a problem with the base pkgbase. > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > performs updates using Boot-Environments to ensure that kernel/world are > updated at same time. > Which could never be imported into FreeBSD. > > > > - This is even worse because you are using the same repository for > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > to be updated and pkg use a new syscall or capsicum thing it will be > > updated first and couldn't proceed with the rest of the update (this is > > a supposition, I haven't personally tested). > > > > See above. > > > > - It seems that multiple kernels isn't supported in your > > implementation, this is already supported in pkgbase but still need > > some love. This is an important point as it will allow user to choose > > easily the kernel that they want to use and will also allow us > > developper to push kernels with new features to help testing. > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll get > the Witness-enabled kernel installed alongside non-debugging one. Mhm no, the kernel-debug packages only add the debug file in /usr/lib/debug/boot/ I'm talking about installing multiple kernels in // (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like describe here : https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > - Since you reduced the granularity on the userland bits it would mean > > that if we use your implementation for -p updates we would download the > > whole userland packages instead of just updating the package that was > > patched. For example with pkgbase, updating from 12.0 to 12.0p1 will > > only update the FreeBSD-runtime package. Yes this package is still big > > to download when you compare to what have changed but until pkg(8) have > > delta pkg supports (and if it will have support, I don't know if > > this is a wish or not) this is the best way to go. > > > > Correct, this is by design. We used the in-tree pkg base for nearly a year, > and found that the granularity didn't really offer any savings from a > download or time perspective. Updating 100+ packages took far longer than a > single one, due to all the meta operations. Additionally in real-world > usage, we found that base packages tended to all get updated at the same > time, which took far longer via pkg, since it had to go and perform 100+ > fetch operations just to download the base system bits. > But you never need to update 100+ packages on a proper pkgbase setup for -p updates. Again on a 12.0 to 12.0-p1 update only one package will be updated. > > > - I see that you are sorting the plist for kernel and userland based > > on the line length [1], why is that ? > > > Whoops! I'll fix :) > > > > > > I think that the only advantage that your solution offers is that if > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > files would be removed as they are in the userland-base package while > > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > > will not be deleted in the user computer. > > > > > Correct, this is one of the things which prompted us to go this direction. > Being able to handle crazy mixed WITH/WITHOUT flags was important to us, > current pkg base did not handle that so gracefully. Can you give me more info on this ? What where the WITH/WITHOUT flags that causes problems ? > Additionally we've > added some additional features, such as being able to 'pkg install os/src' > to get system sources used in exact build, as well as being able to rebuild > your local world
RE: CFT: FreeBSD Package Base
Correct, this is ZFS only. And it's something we're using specific to FreeNAS / TrueOS, which is why I didn't originally mention it as apart of our CFT. For UFS, there will need to be additional care taken when doing updates. -- Kris Moore Vice President of Engineering iXsystems, Inc Ph: (408) 943-4100 Ph: (408) 943-4101 The Groundbreaking TrueNAS M-Series - Enterprise Storage & Servers Driven By Open Source -Original Message- From: Goran Mekić Sent: Monday, April 29, 2019 9:43 AM To: Kris Moore Cc: Emmanuel Vadot ; FreeBSD Stable ; FreeBSD Current ; freebsd-pkgb...@freebsd.org; freebsd-...@freebsd.org; freebsd-hack...@freebsd.org; freebsd-po...@freebsd.org Subject: Re: CFT: FreeBSD Package Base On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > We've written our own tool "sysutils/sysup" in GO which handles this. > It performs updates using Boot-Environments to ensure that > kernel/world are updated at same time. If I'm right, UFS doesn't support boot environments, so how would it work for UFS based installs? I personally feel GO is a bit ackward choice of language for something that practically should be part of base. At least I would expect OS update/upgrade not to require any external package. Regards, meka ___ 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"
Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 09:25:05AM -0400, Kris Moore wrote: > We've written our own tool "sysutils/sysup" in GO which handles this. It > performs updates using Boot-Environments to ensure that kernel/world are > updated at same time. If I'm right, UFS doesn't support boot environments, so how would it work for UFS based installs? I personally feel GO is a bit ackward choice of language for something that practically should be part of base. At least I would expect OS update/upgrade not to require any external package. Regards, meka signature.asc Description: PGP signature
Re: CFT: FreeBSD Package Base
On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot wrote: > > Hi Kris, > > On Sun, 28 Apr 2019 15:52:21 -0400 > wrote: > > > FreeBSD Community, > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > 13-current > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > which > > will allow users to perform all updating via the 'pkg' command directly. > > Rather than trying to answer all questions in this announcement, we've > > created a FAQ page with more details. Please refer to this page, and let > us > > know if you have additional questions that we can include on that page > going > > forward. > > > > While I appreciate the effort I have some doubt about your > "re-implementation" of pkgbase. I don't see any improvement compared to > what is in base currently, I even see downside of your implementation. > > - How do you plan with the need of updating kernel first, reboot and > updating the rest of the userland after ? (Needed for major and minor > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > -HEAD branch). This is still a problem with the base pkgbase. > We've written our own tool "sysutils/sysup" in GO which handles this. It performs updates using Boot-Environments to ensure that kernel/world are updated at same time. > - This is even worse because you are using the same repository for > base and pkg so if a user pkg update and both kernel and pkg(8) needs > to be updated and pkg use a new syscall or capsicum thing it will be > updated first and couldn't proceed with the rest of the update (this is > a supposition, I haven't personally tested). > See above. > - It seems that multiple kernels isn't supported in your > implementation, this is already supported in pkgbase but still need > some love. This is an important point as it will allow user to choose > easily the kernel that they want to use and will also allow us > developper to push kernels with new features to help testing. > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll get the Witness-enabled kernel installed alongside non-debugging one. > - Since you reduced the granularity on the userland bits it would mean > that if we use your implementation for -p updates we would download the > whole userland packages instead of just updating the package that was > patched. For example with pkgbase, updating from 12.0 to 12.0p1 will > only update the FreeBSD-runtime package. Yes this package is still big > to download when you compare to what have changed but until pkg(8) have > delta pkg supports (and if it will have support, I don't know if > this is a wish or not) this is the best way to go. > Correct, this is by design. We used the in-tree pkg base for nearly a year, and found that the granularity didn't really offer any savings from a download or time perspective. Updating 100+ packages took far longer than a single one, due to all the meta operations. Additionally in real-world usage, we found that base packages tended to all get updated at the same time, which took far longer via pkg, since it had to go and perform 100+ fetch operations just to download the base system bits. > - I see that you are sorting the plist for kernel and userland based > on the line length [1], why is that ? Whoops! I'll fix :) > > I think that the only advantage that your solution offers is that if > we remove a componant of base (rcmds for example in 12-CURRENT) those > files would be removed as they are in the userland-base package while > for pkgbase the FreeBSD-rcmd package will be deleted in the repo and > will not be deleted in the user computer. > Correct, this is one of the things which prompted us to go this direction. Being able to handle crazy mixed WITH/WITHOUT flags was important to us, current pkg base did not handle that so gracefully. Additionally we've added some additional features, such as being able to 'pkg install os/src' to get system sources used in exact build, as well as being able to rebuild your local world / kernel packages using ports "make config" framework is super handy. > > > > > Additionally, I will be hosting a Package Base working group at BSDCan > 2019, > > and welcome user and developer attendance to discuss this and other > ongoing > > package work: > > > > > > > > https://wiki.freebsd.org/DevSummit/201905/PackageBase > > > > I will be present and looking forward to work with you on this. > > Cheers, > > P.S. : FYI I'm working on pkgbase currently and I will have some > patches to commit soon (bsdinstall support, memstick creation that > install a pkgbase aware installaton etc ...). > Great! Looking forward to discussion then! > > [1] : > > https://github.com/trueos/trueos-ports/blob/trueos-master/os/userland-base/Makefile#L35 > > -- > Emmanuel Vadot > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To
Re: CFT: FreeBSD Package Base
Hi Kris, On Sun, 28 Apr 2019 15:52:21 -0400 wrote: > FreeBSD Community, > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current > using "TrueOS-inspired" packaged base. These are stock FreeBSD images which > will allow users to perform all updating via the 'pkg' command directly. > Rather than trying to answer all questions in this announcement, we've > created a FAQ page with more details. Please refer to this page, and let us > know if you have additional questions that we can include on that page going > forward. > While I appreciate the effort I have some doubt about your "re-implementation" of pkgbase. I don't see any improvement compared to what is in base currently, I even see downside of your implementation. - How do you plan with the need of updating kernel first, reboot and updating the rest of the userland after ? (Needed for major and minor upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and -HEAD branch). This is still a problem with the base pkgbase. - This is even worse because you are using the same repository for base and pkg so if a user pkg update and both kernel and pkg(8) needs to be updated and pkg use a new syscall or capsicum thing it will be updated first and couldn't proceed with the rest of the update (this is a supposition, I haven't personally tested). - It seems that multiple kernels isn't supported in your implementation, this is already supported in pkgbase but still need some love. This is an important point as it will allow user to choose easily the kernel that they want to use and will also allow us developper to push kernels with new features to help testing. - Since you reduced the granularity on the userland bits it would mean that if we use your implementation for -p updates we would download the whole userland packages instead of just updating the package that was patched. For example with pkgbase, updating from 12.0 to 12.0p1 will only update the FreeBSD-runtime package. Yes this package is still big to download when you compare to what have changed but until pkg(8) have delta pkg supports (and if it will have support, I don't know if this is a wish or not) this is the best way to go. - I see that you are sorting the plist for kernel and userland based on the line length [1], why is that ? I think that the only advantage that your solution offers is that if we remove a componant of base (rcmds for example in 12-CURRENT) those files would be removed as they are in the userland-base package while for pkgbase the FreeBSD-rcmd package will be deleted in the repo and will not be deleted in the user computer. > > Additionally, I will be hosting a Package Base working group at BSDCan 2019, > and welcome user and developer attendance to discuss this and other ongoing > package work: > > > > https://wiki.freebsd.org/DevSummit/201905/PackageBase > I will be present and looking forward to work with you on this. Cheers, P.S. : FYI I'm working on pkgbase currently and I will have some patches to commit soon (bsdinstall support, memstick creation that install a pkgbase aware installaton etc ...). [1] : https://github.com/trueos/trueos-ports/blob/trueos-master/os/userland-base/Makefile#L35 -- Emmanuel Vadot ___ 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"
Re: CFT: FreeBSD Package Base
On 29/04/2019 11:52, Christoph Moench-Tegeder wrote: This situation should be improved. Given that etcupdate is in all supported releases, we can even update UPDATING and the Handbook. So, does anyone have a pointer to the official procedure? Basically run: # etcupdate towards the end of your standard update-from-src process. Pretty much all the available arguments to etcupdate have sane defaults, so it's quite likely you can just run the bare command. (Obv. check the man page for details though) It will automatically do a 3-way merge between the latest sources, the sources from the previous time you ran etcupdate and your deployed configuration in /etc Most of the time, that's all you need to do. Occasionally however etcupdate will run into a merge conflict. When that happens etcupdate will display a SVN-like status report showing the conflicting files and refuse to do anything until the conflicts have been resolved. Which you do by: # etcupdate resolve That's an interactive process which runs through all of the conflicts and allows you to examine the differences and select either your own or the upstream version, or to just edit the files and merge the conflicts manually. Should be pretty familiar if you've ever used git or svn... Once everything has been marked as resolved, etcupdate reverts back to the usual behaviour and will automatically merge in any new updates as far as possible. Most of the time using etcupdate just boils down to a single, non-interactive command to keep everything up to date during the update process. Much less faff than using mergemaster. Occasionally you may need to run: # etcupdate -p before you 'make buildworld' -- that's in exactly the same circumstances where you'ld previously have run 'mergemaster -p' and it does the same job: apply any necessary changes to allow your build to succeed. The times you need to do this should be flagged in UPDATING. Cheers, Matthew ___ 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"
FreeBSD Continuous Weekly Report 2019-04-28
(bcc -current and -stable for more audience) FreeBSD CI Weekly Report 2019-04-28 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2019-04-22 to 2019-04-28. During this period, we have: * 2358 builds (96.9% passed, 3.1% failed) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 436 test runs (34.9% passed, 59.4% unstable, 5.7% exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 9 doc buils (100% passed) (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/s/ByfvuSs54 and archive is available at http://hackfoldr.org/freebsd-ci-report/, any help is welcome. ## Fixed tests * https://ci.freebsd.org/job/FreeBSD-head-amd64-test/ * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.fragmentation.v6 * sys.netpfil.pf.icmp.cve_2019_5598 * sys.netpfil.pf.set_tos.v4 https://bugs.freebsd.org/237305 * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.kern.coredump_phnum_test.coredump_phnum https://svnweb.freebsd.org/changeset/base/346542 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.netmap.ctrl-api-test.main * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * common.ip.t_dtrace_contrib.tst_ipv4localsctp_ksh * common.ip.t_dtrace_contrib.tst_localsctpstate_ksh https://svnweb.freebsd.org/changeset/base/346854 ## Failing Tests * https://ci.freebsd.org/job/FreeBSD-head-i386-test/ * sys.opencrypto.runtests.main * sys.netpfil.pf.forward.v6 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * https://ci.freebsd.org/job/FreeBSD-stable-12-i386-test/ * sys.opencrypto.runtests.main * lib.libc.regex.exhaust_test.regcomp_too_big * lib.libregex.exhaust_test.regcomp_too_big * sys.kern.coredump_phnum_test.coredump_phnum MFC pending: https://svnweb.freebsd.org/changeset/base/346542 * sys.netpfil.pf.forward.v6 * usr.bin.procstat.procstat_test.command_line_arguments * lib.libc.sys.sendfile_test.fd_positive_shm_v4 * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4 * sys.netpfil.pf.forward.v4 * sys.netpfil.pf.set_tos.v4 * https://ci.freebsd.org/job/FreeBSD-stable-11-amd64-test/ * (flaky) usr.bin.procstat.procstat_test.environment * https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/ * usr.bin.procstat.procstat_test.kernel_stacks * local.kyua.* (31 cases) * local.lutok.* (3 cases) * lib.libc.sys.sendfile_test.fd_positive_shm_v4 * lib.libc.sys.sendfile_test.hdtr_negative_bad_pointers_v4 ## Failing Tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ There are ~60 failing cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details ## Disabled Tests * lib.libc.sys.mmap_test.mmap_truncate_signal https://bugs.freebsd.org/211924 * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * usr.bin.procstat.procstat_test.command_line_arguments https://bugs.freebsd.org/233587 * usr.bin.procstat.procstat_test.environment https://bugs.freebsd.org/233588 ## Closed Issues * https://bugs.freebsd.org/237305 Multiple sys.netpfil.pf.* tests failing on ^/head and ^/stable/12 because of TypeError with scapy library reading interfaces from bpf ## Oepn Issues * https://bugs.freebsd.org/237077 possible race in build: /usr/src/sys/amd64/linux/linux_support.s:38:2: error: expected relocatable expression * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 ### Cause build fails * [233735: Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory](https://bugs.freebsd.org/233735) * [233769: Possible build race: ld: error: unable to find library -lgcc_s](https://bugs.freebsd.org/233769) ### Others [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) ___ 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"
Re: CFT: FreeBSD Package Base
## Christoph Moench-Tegeder (c...@burggraben.net): > in a few entries without any detail. The Handbook (chapter 25.3) only ^ 23.5, of course. Regards, Christoph -- Spare Space ___ 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"
Re: CFT: FreeBSD Package Base
## Lars Engels (lars.eng...@0x20.net): > > What are the plans to get rid of the hellscape known as “mergemaster”? > > Is there anything exciting and new there either in base or any of the > > ixSystems projects? > > There's /usr/sbin/etcupdate in base. Unfortunately, the official documentation on upgrades does not mention etcupdate at all. The release notes point to freebsd-update for binary upgrades, and to /usr/src/UPDATING for source-based upgrades. UPDATING only documents the mergemaster procedure; etcupdate is only mentioned in a few entries without any detail. The Handbook (chapter 25.3) only documents mergemaster. Even after speed-reading etcupdate(8) I'm not sure how the two-step invocation of mergemaster has to be mapped to etcupdate - I feel I'd be inventing my own procedure here (and, of course, if it breaks I get to keep all the pieces). This situation should be improved. Given that etcupdate is in all supported releases, we can even update UPDATING and the Handbook. So, does anyone have a pointer to the official procedure? Regards, Christoph -- Spare Space ___ 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"
Re: CFT: FreeBSD Package Base
On Sun, Apr 28, 2019 at 09:29:37PM -0400, Charles Sprickman via freebsd-stable wrote: > > > What are the plans to get rid of the hellscape known as “mergemaster”? > Is there anything exciting and new there either in base or any of the > ixSystems projects? There's /usr/sbin/etcupdate in base. ___ 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"
