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
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 fl
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: Call for testing: patch that helps Wine on 6.x
Tijl Coosemans wrote: On Friday 13 July 2007 20:08:59 Volker wrote: On 07/11/07 20:42, John Baldwin wrote: This patch attempts to remove a gross hack with a slightly less gross hack in order to avoid clobbering data in signal info that Wine needs. In 7 this was fixed by a major change to how the kernel manages signals internally, and that change is too large to be MFC'd, hence this lighter weight patch. It has already been tested by the folks working on Wine, but I would like a bit more widespread testing before I commit it. Please test this patch and let me know if anything breaks. Note that this patch is only for i386. http://www.FreeBSD.org/~jhb/patches/sig_eva.patch I've patched and recompiled world + kernel using your patch. I can confirm it does not hurt but what does it good (my wine already ran fine despite some DDE and performance issues)? What to look for especially - any specific test procedures? Could you try Mozilla Firefox (for Windows) with and without this patch? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] !DSPAM:1,46af5d3e20761655515052! I just gave FireFox 2.0.0.6 a shot using FBSD 6-Stable and all the various patches on the Wiki page. It loaded and ran just fine on my end. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
Marc G. Fournier wrote: --On Tuesday, July 31, 2007 12:19:23 -0700 Kris Moore [EMAIL PROTECTED] wrote: I just gave FireFox 2.0.0.6 a shot using FBSD 6-Stable and all the various patches on the Wiki page. It loaded and ran just fine on my end. as user root? or a regular user? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 :) I learned my lesson, I ran it as regular user this time. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
'k, now I'm curious ... you have all the kernel patches in place, and you can now run 'make tests' as a regular user without any problems? I just updated my kernel, so am going to work tonight on plugging in the OS patches and building a new wine here (just got back from camping, still catching up on things) ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 I'm not sure all the tests run properly since I didn't run through them yet. I'll try it out tomorrow morning though. All I tried was FireFox for Windows and installed StarCraft. Both worked just fine here. (I did a spawn of Starcraft since the safedisc support isn't working as far as I know) -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Issues with Bootloader Vista
Hey guys, We've released our 1.4 BETA of PC-BSD this week, and one of the issues which has come up is the broken support for dual-booting with a Vista system. Apparently the FreeBSD boot loader messes up some of Vista's boot process. Here's what one of our users tracked it down to: ... If a user wises to re size the Vista partition then dual boot the user maybe surprised to find Vista will fail to boot from the BSD boot loader with the following error message: The file /Windows/system32/winload.exe can not be found or is corrupt. This is due to the BSD boot loader overwriting a UUID in the MBR the Vista OS uses to boot for some reason as it was not in the Beta or the RC. ... Is this a known issue, or something we may have fixed in 6-Stable soon? If so it would be great if I could find a fix before we release a final version down the road. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Momchil Ivanov wrote: On Wednesday 18 July 2007 19:34:06 Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // Just a dumb question: what does umount -f does? And doing something like that when a fs goes away shouldn`t fix it? If the problem is in general with a file system, regardless of the provider, then what does one do when a mounted smbfs becomes unavailable due to remote host down, no route to host or some other network related problems? Same question for NFS mounted filesystems? !DSPAM:1,469e538b20763944420674! Wow, quite a thread going on over this issue. I'll throw my 2cents into the ring also :) From a desktop perspective, it makes total sense to not have the system crash just because a USB disk was unplugged while mounted. When a new end user does this for the first time and the system crashes, usually the first thing they assume is that it's a bug. Then somebody like me comes around and tells them to unmount it first. Then usually the next thing they say is something along the lines of That's so early 90's, why can't you guys get your act together? I can understand requiring unmounting for devices such as CD's or internal IDE / SCSI hard drives. With a CD at least you can physically lock the drive bay to prevent the user from ejecting until unmounted first. However, with a USB the ballgame changes, the whole concept is to be hot-swappable, plugin and unplug at will. If a normal desktop user copies a file to a USB disk and the file transfer dialog is done, then they should be able to unplug it, without a total system crash. That being said, I think it would be a good idea to at least have the kernel / HAL or some process maybe warn the user that they should unmount the USB disk first, to prevent data loss at minimum. But I think this can be improved, so you don't have to deal with an entire system panic :P When that happens you gotta reboot, fsck, and run the risk of something really being corrupted on the drive :( -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removing external usb hdd without unmounting causes reboot?
Jeremy Chadwick wrote: On Wed, Jul 18, 2007 at 11:54:19AM -0700, Kris Moore wrote: That being said, I think it would be a good idea to at least have the kernel / HAL or some process maybe warn the user that they should unmount the USB disk first, to prevent data loss at minimum. But I think this can be improved, so you don't have to deal with an entire system panic :P When that happens you gotta reboot, fsck, and run the risk of something really being corrupted on the drive :( So there's two issues here: 1) Kernel panics when a device (regardless of type (USB, SATA, etc.)) is removed from the system with filesystems mounted, 2) Concern over data loss when device is removed. As I mentioned earlier in the thread, Windows addresses #2 by marking all filesystems on USB storage devices (thumb drives, HDDs, etc.) as synchronous (e.g. mount -o sync). The impact is slow I/O, but it's safe. It seems like we'd be able to implement such a transparent feature into the subsystem where filesystems mounted from USB devices would use synchronous I/O (mount -o sync). I don't know how this would be coded, since there would have to be some way to figure out a physical device type (USB mass storage devices show up as /dev/daXXX). Providing an override option for those who know what they're doing, (umount /mnt then physically remove device) would be nice too. This would alleviate concerns over data loss, would it not? This sounds like an excellent idea to me. If something along these lines were implemented, it would be very helpful for us on the desktop end of things. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
I've been testing with the wine patch, including the signal patch from wiki.freebsd.org/Wine and it seems to run fine. I've been using the box for testing, development and such, no problems that I can see so far. -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Call for testing: patch that helps Wine on 6.x
John Baldwin wrote: On Friday 13 July 2007 02:08:59 pm Volker wrote: On 07/11/07 20:42, John Baldwin wrote: This patch attempts to remove a gross hack with a slightly less gross hack in order to avoid clobbering data in signal info that Wine needs. In 7 this was fixed by a major change to how the kernel manages signals internally, and that change is too large to be MFC'd, hence this lighter weight patch. It has already been tested by the folks working on Wine, but I would like a bit more widespread testing before I commit it. Please test this patch and let me know if anything breaks. Note that this patch is only for i386. http://www.FreeBSD.org/~jhb/patches/sig_eva.patch John, I've patched and recompiled world + kernel using your patch. I can confirm it does not hurt but what does it good (my wine already ran fine despite some DDE and performance issues)? What to look for especially - any specific test procedures? I'm not as familiar with what it fixes for wine, but it fixes one part of the siginfo for signals to not contain garbage. I've been testing it along with the 6-signal patch on the wiki.freebsd.org/Wine page. I think the signal patch is the more critical one, which fixes a lot of wine's past woes. Did you need people to test that one as well? -- Kris Moore PC-BSD Software http://www.pcbsd.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
