Re: Question about 'gptzfsboot'
On 2019-04-29 15:24, Ian Lepore wrote: > > I can't say anything at all about drm or other video driver issues, I'm > just not knowledgeable about that stuff at all. > > The only thing I was getting at was that the changes I made in r346675 > might make this error stop happening: > >gptzfsboot: error 1 LBA 18446744072709551608 >gptzfsboot: error 1 LBA 1 >gptzfsboot: No ZFS pools located, can't boot > > Emphasis on the "might"... that appears to be an error during probing > for zfs, and I made some fixes related to probing for zfs. > Ian I saw this gptzfsboot issue 3 times in a row after re-activating r346885 but have not seen it again after at least 12 reboots this afternoon. It looks like there is an issue with the DRM update or changes to the kernel between r346544 and r346885 that is causing a separate problem for me. Thanks for looking into this. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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
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-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"
Re: Question about 'gptzfsboot'
On 2019-04-29 14:58, Toomas Soome wrote: > > It means you have different issues - one is about gptzfsboot causing boot > problems and apparently it got fixed when you did update the bootcode (the > boot partition is global). But also you got bitten by DRM update, and since > you had old BE around, you were able to load old kernel. > > Now the question is, is that gptzfsboot issue really fixed or is it just the > “warm boot” fix you were seeing earlier too. > Toomas: After activating the snapshot made for r346885, I got the same sort of gptzfsboot errors that I had seen previously. After my third attempt, I was finally given the prompt for my Geli password and proceeded to the boot menu. I selected item #3 and went to the loader menu. I selected booting from kernel.old and got a successful startup. I have rebooted this laptop another dozen times this afternoon and had not had any more gptzfsboot issues since the three observed when re-activating r346885. It looks like the changes made by Ian Lepore did not solve my problem with gptzfsboot. I will probably start another thread about my issue with the DRM update. Thanks for the assistance. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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
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-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: Question about 'gptzfsboot'
On Mon, 2019-04-29 at 14:47 -0400, Thomas Laus wrote: > On 2019-04-29 14:27, Thomas Laus wrote: > > It was more than a broken console. All of the other 2 computers > > that I > > upgraded to r346885 were essentially 'dead'. I could not even > > remotely > > login to them via ssh. All of them required a hard power button > > reset > > to get into single user mode to let me comment out the rc.conf line > > that > > loads the DRM driver. The computer could successfully boot without > > DRM > > activation but would go to a black console screen again with > > 'startx'. > > This also required a hard power button shutdown. I rolled back to > > r346544 and everything worked again like before. > > > > My disastrous update to r346885 included installing a new > > gptzfsboot and > > pmbr in the drive boot record. I did not try booting an older > > kernel > > using the new gptzfsboot. I was concerned about the lack of ssh > > login > > when the computers lost their console, so I just rolled back my > > system > > to the last snapshot made a week ago. > > > > Ian: > > I re-activated the r346885 BEADM snapshot and booted from my > 'kernel.old' from r346544 and everything came up OK including 'X'. > > I don't know what that means. It might be that I have a DRM issue > instead of a gptzfsboot problem? Everything except for the kernel is > now running CURRENT r346885. I am not using the updated > drm-current-kmod because I am using the r346544 kernel.old. > > Tom > > I can't say anything at all about drm or other video driver issues, I'm just not knowledgeable about that stuff at all. The only thing I was getting at was that the changes I made in r346675 might make this error stop happening: gptzfsboot: error 1 LBA 18446744072709551608 gptzfsboot: error 1 LBA 1 gptzfsboot: No ZFS pools located, can't boot Emphasis on the "might"... that appears to be an error during probing for zfs, and I made some fixes related to probing for zfs. -- Ian ___ 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: Question about 'gptzfsboot'
> On 29 Apr 2019, at 21:47, Thomas Laus wrote: > > On 2019-04-29 14:27, Thomas Laus wrote: >> It was more than a broken console. All of the other 2 computers that I >> upgraded to r346885 were essentially 'dead'. I could not even remotely >> login to them via ssh. All of them required a hard power button reset >> to get into single user mode to let me comment out the rc.conf line that >> loads the DRM driver. The computer could successfully boot without DRM >> activation but would go to a black console screen again with 'startx'. >> This also required a hard power button shutdown. I rolled back to >> r346544 and everything worked again like before. >> >> My disastrous update to r346885 included installing a new gptzfsboot and >> pmbr in the drive boot record. I did not try booting an older kernel >> using the new gptzfsboot. I was concerned about the lack of ssh login >> when the computers lost their console, so I just rolled back my system >> to the last snapshot made a week ago. >> > Ian: > > I re-activated the r346885 BEADM snapshot and booted from my > 'kernel.old' from r346544 and everything came up OK including 'X'. > > I don't know what that means. It might be that I have a DRM issue > instead of a gptzfsboot problem? Everything except for the kernel is > now running CURRENT r346885. I am not using the updated > drm-current-kmod because I am using the r346544 kernel.old. > It means you have different issues - one is about gptzfsboot causing boot problems and apparently it got fixed when you did update the bootcode (the boot partition is global). But also you got bitten by DRM update, and since you had old BE around, you were able to load old kernel. Now the question is, is that gptzfsboot issue really fixed or is it just the “warm boot” fix you were seeing earlier too. rgds, toomas > Tom > > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > ___ > 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"
Re: Question about 'gptzfsboot'
On 2019-04-29 14:27, Thomas Laus wrote: > It was more than a broken console. All of the other 2 computers that I > upgraded to r346885 were essentially 'dead'. I could not even remotely > login to them via ssh. All of them required a hard power button reset > to get into single user mode to let me comment out the rc.conf line that > loads the DRM driver. The computer could successfully boot without DRM > activation but would go to a black console screen again with 'startx'. > This also required a hard power button shutdown. I rolled back to > r346544 and everything worked again like before. > > My disastrous update to r346885 included installing a new gptzfsboot and > pmbr in the drive boot record. I did not try booting an older kernel > using the new gptzfsboot. I was concerned about the lack of ssh login > when the computers lost their console, so I just rolled back my system > to the last snapshot made a week ago. > Ian: I re-activated the r346885 BEADM snapshot and booted from my 'kernel.old' from r346544 and everything came up OK including 'X'. I don't know what that means. It might be that I have a DRM issue instead of a gptzfsboot problem? Everything except for the kernel is now running CURRENT r346885. I am not using the updated drm-current-kmod because I am using the r346544 kernel.old. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Question about 'gptzfsboot'
On 2019-04-29 11:14, Ian Lepore wrote: > > I'm fighting my own video driver troubles (seems like a lot of that > going around lately); on an upgrade of a machine from 11-stable to 12- > stable I lost my console. > > But, a broken kernel and/or userland shouldn't affect your ability to > use the new boot components. That is, you can use gptzfsboot and > loader that contain my fixes, and use them to load an older kernel that > has working video drivers. > Ian: It was more than a broken console. All of the other 2 computers that I upgraded to r346885 were essentially 'dead'. I could not even remotely login to them via ssh. All of them required a hard power button reset to get into single user mode to let me comment out the rc.conf line that loads the DRM driver. The computer could successfully boot without DRM activation but would go to a black console screen again with 'startx'. This also required a hard power button shutdown. I rolled back to r346544 and everything worked again like before. My disastrous update to r346885 included installing a new gptzfsboot and pmbr in the drive boot record. I did not try booting an older kernel using the new gptzfsboot. I was concerned about the lack of ssh login when the computers lost their console, so I just rolled back my system to the last snapshot made a week ago. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Question about 'gptzfsboot'
On 2019-04-29 10:33, Thomas Laus wrote: > Updating to r346885 turned out to be a disaster! There were changes to > DRM between FreeBSD 13.0-CURRENT r346544 and r346885. The desktop that > I use for a build machine because it is much faster than any of my other > PC's installed kernel and world without any problems including starting > 'X'. I had to update the drm-current-kmod port on my build PC. Nothing > was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do so. > DRM on my build computer did not start until the update and then worked > as expected. > > I did the same on my Dell laptop and it crashed on the first boot right > after loading DRM-kmod. I removed the line in rc.conf that activates > the kernel module and my laptop booted into multiuser. When I started > 'X' it crashed just like before. The screen was black and I could not > login remotely via SSH. Nothing in any system log. The Xorg log shows > this and stops: > Ian: I updated my other desktop PC's (Intel Atom D510 and Dell AMD Sempron) and received the same black screen, not responsive, no log events just like my laptop with CURRENT r346885 and the DRM kmod update from ports. The only computer that had success was my Intel i5 Skylake. I did not try updating my other laptop since r346885 had issues on three computers. Recovery also required a BEADM rollback to the last successful snapshot. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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"
RTL8821CU USB WiFi
Hi Is anyone working on adding support for RTL8811CU & RTL8821CU chipsets? ___ 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 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-sta...@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-current@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-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: Question about 'gptzfsboot'
On Mon, 2019-04-29 at 10:33 -0400, Thomas Laus wrote: > > On 2019-04-28 22:27, Ian Lepore wrote: > > > > > > If you're using gptzfsboot, I guess you're using zfs? I just > > > fixed a > > > problem with probing disks for zfs volumes a few days ago > > > (r346675). > > > There is even some small chance it fixes this problem, because > > > one of > > > the things I noticed was that in one of the disk structures in > > > loader, > > > the "slice offset" value was sometimes a bit random-looking, like > > > it > > > was being initialized with whatever garbage was laying around in > > > memory. It actually makes some sense that the "garbage" might be > > > different between a firstboot after power-on and a reboot. > > > > > > So all in all, it wouldn't hurt to update both gptzfsboot and > > > loader > > > (gpart bootcode -b and -p) to see if there's a fix lurking in my > > > zfs > > > probe changes. > > > > > > > I'll build and update my laptop OS this morning and report back to > > this > > thread if I have any additional issues. > > > > Ian: > > Updating to r346885 turned out to be a disaster! There were changes > to > DRM between FreeBSD 13.0-CURRENT r346544 and r346885. The desktop > that > I use for a build machine because it is much faster than any of my > other > PC's installed kernel and world without any problems including > starting > 'X'. I had to update the drm-current-kmod port on my build > PC. Nothing > was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do > so. > DRM on my build computer did not start until the update and then > worked > as expected. > > I did the same on my Dell laptop and it crashed on the first boot > right > after loading DRM-kmod. I removed the line in rc.conf that activates > the kernel module and my laptop booted into multiuser. When I > started > 'X' it crashed just like before. The screen was black and I could > not > login remotely via SSH. Nothing in any system log. The Xorg log > shows > this and stops: > > 40.979]compiled for 1.18.4, module version = 2.4.0 > [40.979]Module class: X.Org Video Driver > [40.979]ABI class: X.Org Video Driver, version 20.0 > [40.979] (II) intel: Driver for Intel(R) Integrated Graphics > Chipsets: > i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, > 865G, > 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, > Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, > Q35, > Q33, > GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 > [40.981] (II) intel: Driver for Intel(R) HD Graphics > [40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics > [40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics > [40.981] (II) modesetting: Driver for Modesetting Kernel Drivers: > kms > [40.981] (II) scfb: driver for wsdisplay framebuffer: scfb > [40.981] (II) VESA: driver for VESA chipsets: vesa > [40.981] (--) Using syscons driver with X support (version 2.0) > [40.981] (--) using VT number 9 > > I had to recover my system using beadm to rollback to the last > CURRENT > snapshot from a week ago. > > Tom > > I'm fighting my own video driver troubles (seems like a lot of that going around lately); on an upgrade of a machine from 11-stable to 12- stable I lost my console. But, a broken kernel and/or userland shouldn't affect your ability to use the new boot components. That is, you can use gptzfsboot and loader that contain my fixes, and use them to load an older kernel that has working video drivers. -- Ian ___ 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
> -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-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
> -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-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
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: Question about 'gptzfsboot'
> On 2019-04-28 22:27, Ian Lepore wrote: >> >> If you're using gptzfsboot, I guess you're using zfs? I just fixed a >> problem with probing disks for zfs volumes a few days ago (r346675). >> There is even some small chance it fixes this problem, because one of >> the things I noticed was that in one of the disk structures in loader, >> the "slice offset" value was sometimes a bit random-looking, like it >> was being initialized with whatever garbage was laying around in >> memory. It actually makes some sense that the "garbage" might be >> different between a firstboot after power-on and a reboot. >> >> So all in all, it wouldn't hurt to update both gptzfsboot and loader >> (gpart bootcode -b and -p) to see if there's a fix lurking in my zfs >> probe changes. >> > I'll build and update my laptop OS this morning and report back to this > thread if I have any additional issues. > Ian: Updating to r346885 turned out to be a disaster! There were changes to DRM between FreeBSD 13.0-CURRENT r346544 and r346885. The desktop that I use for a build machine because it is much faster than any of my other PC's installed kernel and world without any problems including starting 'X'. I had to update the drm-current-kmod port on my build PC. Nothing was in /usr/src/UPDATING or /usr/ports/UPDATING about the need to do so. DRM on my build computer did not start until the update and then worked as expected. I did the same on my Dell laptop and it crashed on the first boot right after loading DRM-kmod. I removed the line in rc.conf that activates the kernel module and my laptop booted into multiuser. When I started 'X' it crashed just like before. The screen was black and I could not login remotely via SSH. Nothing in any system log. The Xorg log shows this and stops: 40.979]compiled for 1.18.4, module version = 2.4.0 [40.979]Module class: X.Org Video Driver [40.979]ABI class: X.Org Video Driver, version 20.0 [40.979] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [40.981] (II) intel: Driver for Intel(R) HD Graphics [40.981] (II) intel: Driver for Intel(R) Iris(TM) Graphics [40.981] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics [40.981] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [40.981] (II) scfb: driver for wsdisplay framebuffer: scfb [40.981] (II) VESA: driver for VESA chipsets: vesa [40.981] (--) Using syscons driver with X support (version 2.0) [40.981] (--) using VT number 9 I had to recover my system using beadm to rollback to the last CURRENT snapshot from a week ago. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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
> > > > > 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-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 14:19, Lev Serebryakov wrote: I'm not very interested in packetized base for "big servers" which contains full FreeBSd installation 'Big servers' may have a full FreeBSD installation in the base system, but they may also have hundreds of jails that want the absolute minimum required for the service that they're exporting. FreeBSD is currently suffering quite a lot from the lack of any solid story here. The vast majority of cloud deployments are now using some combination of Docker and Kubernetes or equivalents to spin up a large number of VMs and an even larger number of microservice containers within them. This should be something that FreeBSD is ideal for - jails preform better and provide a more coherent interface than the mess of cgroups and seccomp-bpf that Linux containers use. It *ought* to be trivial to create a jail that has basically nothing other than the core libraries (and maybe a shell) and is managed from the outside. Even the few FreeBSD core utilities that support jails don't really work like this (for example, I can use pkg to install something in a jail, but doing so implicitly installs a copy of the pkg tool inside the jail and invokes that). 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: 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-sta...@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-current@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-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
> > 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-current@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-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 Mon, Apr 29, 2019 at 9:53 AM Warner Losh wrote: > > > On Mon, Apr 29, 2019 at 7:50 AM Lev Serebryakov wrote: > >> On 29.04.2019 16:39, k...@ixsystems.com wrote: >> >> > >> > This should be very doable with this package base. We use it for >> FreeNAS in a similar manner, where we disable a couple dozen things from >> base, resulting in a much more stripped down userland-base package. By >> default we also break out the doc/tests/debug bits into their own >> userland-* packages, for same reasons, to keep image nice and small. >> > >> Ok, after >> >> >> # tar tf FreeBSD-HEAD-pkgbase-x64-20190426.iso | grep All >> dist/FreeBSD:13:amd64/latest/All >> dist/FreeBSD:13:amd64/latest/All/ca_root_nss-3.43_1.txz >> dist/FreeBSD:13:amd64/latest/All/jq-1.6.txz >> dist/FreeBSD:13:amd64/latest/All/kernel-20190420203550_1.txz >> dist/FreeBSD:13:amd64/latest/All/oniguruma-6.9.1.txz >> dist/FreeBSD:13:amd64/latest/All/pkg-1.10.5_5.txz >> dist/FreeBSD:13:amd64/latest/All/userland-20190420203550.txz >> dist/FreeBSD:13:amd64/latest/All/userland-base-20190420203550_7.txz >> dist/FreeBSD:13:amd64/latest/All/userland-docs-20190420203550.txz >> dist/FreeBSD:13:amd64/latest/All/userland-lib32-20190420203550.txz >> # >> >> I was under impression, that there is only 3 userland packages, not >> 100+ :-) >> > > It's a tradeoff... 100+ packages is super granular, but also a PITA to > manage. 3 package installs quite a bit faster than the 100+ packages due to > a large fixed cost in pkg per package, but isn't granular enough to tailor > for NanoBSD systems. > > Warner > > Correct. Its all in the FAQ, there are about a dozen available packages: https://trueos.github.io/pkgbase-docs/#which-base-packages-are-available Really you only need a few of them on typical system, userland(meta-pkg)/userland-base/userland-docs/kernel > -- >> // Lev Serebryakov >> >> ___ 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 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current 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
On Mon, Apr 29, 2019 at 7:50 AM Lev Serebryakov wrote: > On 29.04.2019 16:39, k...@ixsystems.com wrote: > > > > > This should be very doable with this package base. We use it for FreeNAS > in a similar manner, where we disable a couple dozen things from base, > resulting in a much more stripped down userland-base package. By default we > also break out the doc/tests/debug bits into their own userland-* packages, > for same reasons, to keep image nice and small. > > > Ok, after > > > # tar tf FreeBSD-HEAD-pkgbase-x64-20190426.iso | grep All > dist/FreeBSD:13:amd64/latest/All > dist/FreeBSD:13:amd64/latest/All/ca_root_nss-3.43_1.txz > dist/FreeBSD:13:amd64/latest/All/jq-1.6.txz > dist/FreeBSD:13:amd64/latest/All/kernel-20190420203550_1.txz > dist/FreeBSD:13:amd64/latest/All/oniguruma-6.9.1.txz > dist/FreeBSD:13:amd64/latest/All/pkg-1.10.5_5.txz > dist/FreeBSD:13:amd64/latest/All/userland-20190420203550.txz > dist/FreeBSD:13:amd64/latest/All/userland-base-20190420203550_7.txz > dist/FreeBSD:13:amd64/latest/All/userland-docs-20190420203550.txz > dist/FreeBSD:13:amd64/latest/All/userland-lib32-20190420203550.txz > # > > I was under impression, that there is only 3 userland packages, not > 100+ :-) > It's a tradeoff... 100+ packages is super granular, but also a PITA to manage. 3 package installs quite a bit faster than the 100+ packages due to a large fixed cost in pkg per package, but isn't granular enough to tailor for NanoBSD systems. Warner > -- > // Lev Serebryakov > > ___ 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
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-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 16:39, k...@ixsystems.com wrote: > > This should be very doable with this package base. We use it for FreeNAS in a > similar manner, where we disable a couple dozen things from base, resulting > in a much more stripped down userland-base package. By default we also break > out the doc/tests/debug bits into their own userland-* packages, for same > reasons, to keep image nice and small. > Ok, after # tar tf FreeBSD-HEAD-pkgbase-x64-20190426.iso | grep All dist/FreeBSD:13:amd64/latest/All dist/FreeBSD:13:amd64/latest/All/ca_root_nss-3.43_1.txz dist/FreeBSD:13:amd64/latest/All/jq-1.6.txz dist/FreeBSD:13:amd64/latest/All/kernel-20190420203550_1.txz dist/FreeBSD:13:amd64/latest/All/oniguruma-6.9.1.txz dist/FreeBSD:13:amd64/latest/All/pkg-1.10.5_5.txz dist/FreeBSD:13:amd64/latest/All/userland-20190420203550.txz dist/FreeBSD:13:amd64/latest/All/userland-base-20190420203550_7.txz dist/FreeBSD:13:amd64/latest/All/userland-docs-20190420203550.txz dist/FreeBSD:13:amd64/latest/All/userland-lib32-20190420203550.txz # I was under impression, that there is only 3 userland packages, not 100+ :-) -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
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
This should be very doable with this package base. We use it for FreeNAS in a similar manner, where we disable a couple dozen things from base, resulting in a much more stripped down userland-base package. By default we also break out the doc/tests/debug bits into their own userland-* packages, for same reasons, to keep image nice and small. -- 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: Lev Serebryakov Sent: Monday, April 29, 2019 9:20 AM To: k...@ixsystems.com; freebsd-current@freebsd.org; freebsd-pkgb...@freebsd.org; freebsd-hack...@freebsd.org Subject: Re: CFT: FreeBSD Package Base On 28.04.2019 22:52, k...@ixsystems.com wrote: > 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. Is it too coarse, isn't it? I'm not very interested in packetized base for "big servers" which contains full FreeBSd installation, but I have several NanoBSD installations, which have more than 100 "WITHOUT_XXX" options in src.conf. I want to have packetized base to create such images via `pkg' Not all these options could be converted to packages, options like WITHOUT_KERBEROS is more build option, but about 2/3 of these options turn off some file-based features, like sendmail, PPP, toolchain or bzip2. IMHO, to be really useful packets in base should be based on these src.conf options to have ability to skip unneeded "optional" base components (including, for example, man pages!). And one more, not covered with src.conf WITHOUT_XXX: static libraries and header files, of course! -- // Lev Serebryakov ___ 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 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current
Re: CFT: FreeBSD Package Base
On 28.04.2019 22:52, k...@ixsystems.com wrote: > 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. Is it too coarse, isn't it? I'm not very interested in packetized base for "big servers" which contains full FreeBSd installation, but I have several NanoBSD installations, which have more than 100 "WITHOUT_XXX" options in src.conf. I want to have packetized base to create such images via `pkg' Not all these options could be converted to packages, options like WITHOUT_KERBEROS is more build option, but about 2/3 of these options turn off some file-based features, like sendmail, PPP, toolchain or bzip2. IMHO, to be really useful packets in base should be based on these src.conf options to have ability to skip unneeded "optional" base components (including, for example, man pages!). And one more, not covered with src.conf WITHOUT_XXX: static libraries and header files, of course! -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
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-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
Cc: list trimmed to relevant. Very long essey below, be warned.
On Sun, Apr 28, 2019 at 03:52:21PM -0400, k...@ixsystems.com 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.
>
>
>
> 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
>
>
>
>
>
> FAQ
>
> -
>
> https://trueos.github.io/pkgbase-docs/
>
I do not know what are design decisions for trueos pkgbase are, but I
do know something about in-tree split and why some packaging decisions
where made. I cannot attend your WG, but I believe the reasoning used
for the in-tree is important enough to represent it intact from the
source. I have to start with some explanatory long text to put it into
the proper perspective.
There are two knots of interdependinces which are critical for correctness
of any upgrade where the target system cannot be simply discarded on failure:
1. C runtime
2. Minimal boot path to prompt.
Let me elaborate both, starting from point 1, which is typically very obscure
despite having the fundamental nature for anything related to upgrades.
The basic execution environment for any program executed by the FreeBSD
kernel is formed by combination of kernel' syscall interface and some
system userspace code which makes the expected environment over the
bare-bone image state after execve. The environment is typically named
C runtime environment since C language ABI is directly tied into it,
and normal C programs only get whatever is provided by the C runtime
unless additional libraries are linked in. Trully, it is not just C
runtime, any other execution environment on top of the OS is based on
this one, but since almost every 'advanced' language runtime is backed
by C language and its runtime, the name stuck.
FreeBSD C runtime, arguably, is provided by the following four objects:
/libexec/ld-elf.so.1
/lib/libc.so.7
/lib/libthr.so.3
/lib/libm.so.5
There, we do *guarantee* that the external ABI of the whole pack of
these four objects is backward compatible, i.e. if the binary was
compiled against set if base libraries at earlier date (may be also
on earlier branch), then the binary behaviour would be same when
executed on newer C runtime pack. This is not trivial to achieve,
besides technical measures that helps there, like backward-compatible
syscall interface, symbol versioning, providing fall-back code for
older interface, a lot of overhead in the development is enforced, like
carefull reviews of the changes, the policy and related discipline of
versioning, following published ABI standards, and so on.
But, internal ABI of the C runtime pack, i.e. interfaces which make rtld
work with libc and libthr, or way by which libthr, when loaded, makes
libc thread-aware, are not stable, and more, they are often changed
in backward-incompatible way. Requiring backward-compatibility there
would stop our ability to evolve the system. Answering some questions in
advance, yes, rtld delves into libc, libthr patches libc on load, libc
has hooks to control some libthr behaviour.
The only provision that we make is that ld-elf.so.1 is required to work
with older libc/libthr combination, but even then libc and libthr must
be built from the same sources with the same options set.
Now, returning to pkgbase, if you look at what libs are packed into clibs,
you see:
ld-elf.so.1
libc.so.7 (and modules like iconv tables or nss, if any)
libthr.so.3
libdl.so.1
libgcc{, _eh, _s}.so.1
libm.so.5
libedit.so.7
libncurses{, w}.so.8
libc++.so.1
It adds very popular libs like libncurses/libedit, and C++ runtime. The
basic reasoning is that this package is small and chances of something
going wrong while installing it are small as result. Put it other way,
the small clibs package organization makes it highly probable that
system is left in the consistent state (either all new libs, or all old
libs) after the upgrade, whetever the outcome is.
If the C runtime pack is not split from the whole 700MB+ update blob, libthr
update has almost certain chance to occur long after or before libc update,
so failures do tend to leave inconsistent rtld/libc/libthr set. At best,
it gives you strange glitches, at worst you get unusable system that cannot
be repaired without
Re: Question about 'gptzfsboot'
On 2019-04-28 22:27, Ian Lepore wrote: > > If you're using gptzfsboot, I guess you're using zfs? I just fixed a > problem with probing disks for zfs volumes a few days ago (r346675). > There is even some small chance it fixes this problem, because one of > the things I noticed was that in one of the disk structures in loader, > the "slice offset" value was sometimes a bit random-looking, like it > was being initialized with whatever garbage was laying around in > memory. It actually makes some sense that the "garbage" might be > different between a firstboot after power-on and a reboot. > > So all in all, it wouldn't hurt to update both gptzfsboot and loader > (gpart bootcode -b and -p) to see if there's a fix lurking in my zfs > probe changes. > I'll build and update my laptop OS this morning and report back to this thread if I have any additional issues. Thanks Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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 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-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
___ 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"
