Slightly worse than that. In the El Capitan Beta 2, you can no longer set boot-args unless you boot into recovery. This is making everything into a huge hassle for the users, all because apple doesn't want to support /Library/Filesystems/
Lund Matt Bauer wrote: > Just tried again with rootless=0 and no luck. It looks like KEXT in > /Library/Extensions work fine. I think DiskArbitration just needs to look > in /Library/Filesystems which I’m sure it will do in the next beta. > > Matt Bauer > >> On Jun 12, 2015, at 7:47 AM, William T McVay <putahcr...@me.com >> <mailto:putahcr...@me.com>> wrote: >> >> Hi, Lund and Matt, >> >> Wasn't there a mention of disabling System Integrity constraints while >> booted into the rescue partition "for just such an emergency"? >> >> Tom >> >> W. T. McVay >> Putah Creek Development >> >> Sent from my iPad >> >> On Jun 11, 2015, at 11:15 PM, Matt Bauer <m...@ciderapps.com >> <mailto:m...@ciderapps.com>> wrote: >> >>> I can confirm the same behavior with my filesystem. Nothing in >>> /Library/Filesystems is loaded. I’ve open rdar://21352744 for this. >>> >>> Matt Bauer >>> >>>> On Jun 10, 2015, at 8:26 PM, Jorgen Lundman <lund...@lundman.net >>>> <mailto:lund...@lundman.net>> wrote: >>>> >>>> >>>> Hello list, >>>> >>>> So we finally have got to the point where /System is locked down on 10.11 >>>> El Capitan. That is all well, but for one issue. Where can we put the >>>> filesystem bundles now? >>>> >>>> What used to go into /System/Library/Filesystems/zfs.fs/ >>>> >>>> This location is now rootless, and we can not add to it. There does appear >>>> to be some changes to diskarbitrationd, with a call to >>>> CFCopySearchPathForDirectoriesInDomains() followed by >>>> CFArrayAppendValue("/Filesystems") ... >>>> >>>> But the obvious "/Library/Filesystems/" appear not to be searched. >>>> >>>> Lund >>>> >>>> -- >>>> Jorgen Lundman | <lund...@lundman.net <mailto:lund...@lundman.net>> >>>> Unix Administrator | +81 (0)90-5578-8500 (work) >>>> Shibuya-ku, Tokyo | +81 (0)80-2090-5800 (cell) >>>> Japan | +81 (0)3 -3375-1767 (home) >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Filesystem-dev mailing list (Filesystem-dev@lists.apple.com >>>> <mailto:Filesystem-dev@lists.apple.com>) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/filesystem-dev/matt%40ciderapps.com >>>> >>>> This email sent to m...@ciderapps.com <mailto:m...@ciderapps.com> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Filesystem-dev mailing list (Filesystem-dev@lists.apple.com >>> <mailto:Filesystem-dev@lists.apple.com>) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/filesystem-dev/putahcreek%40mac.com >>> >>> This email sent to putahcr...@mac.com <mailto:putahcr...@mac.com> > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/filesystem-dev/lundman%40lundman.net > > This email sent to lund...@lundman.net > -- Jorgen Lundman | <lund...@lundman.net> Unix Administrator | +81 (0)90-5578-8500 (work) Shibuya-ku, Tokyo | +81 (0)80-2090-5800 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
